Teensyduino 1.44 has been released.
https://www.pjrc.com/teensy/td_download.html
The main new feature is support for Arduino 1.8.7. The Ports menu speed was improved.
Linux 64 bit ARM (aarch64) is now supported. Download Arduino 1.8.7 for AARCH64 (link is missing from Arduino's site).
The Audio library wavetable data format was changed slightly after 1.44-beta2, but otherwise 1.44 is identical to 1.44-beta2.
This is what happen pretty often, java again...Originally Posted by Paul
Now I was able to copy and save report before mac go down.
Problem exist from 1.8.5 and 1.41
When appear, Arduino hang, I can't do nothing because affect system too, and very often itself restart computer, with welcome screen after reset - "kernel panic"
Very weird
Much more often when I have open serial monitor
Code:Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68) at java.lang.StringBuffer.<init>(StringBuffer.java:128) at processing.app.AbstractMonitor.<init>(AbstractMonitor.java:70) at processing.app.AbstractTextMonitor.<init>(AbstractTextMonitor.java:49) at processing.app.TeensyMonitor.<init>(TeensyMonitor.java:46) at cc.arduino.packages.MonitorFactory.newMonitor(MonitorFactory.java:54) at processing.app.Editor.handleSerial(Editor.java:2257) at processing.app.EditorToolbar.mousePressed(EditorToolbar.java:383) at java.awt.Component.processMouseEvent(Component.java:6530) at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) at java.awt.Component.processEvent(Component.java:6298) at java.awt.Container.processEvent(Container.java:2238) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2296) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4897) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4531) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4475) at java.awt.Container.dispatchEventImpl(Container.java:2282) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68) at java.lang.StringBuffer.<init>(StringBuffer.java:128) at processing.app.AbstractMonitor.<init>(AbstractMonitor.java:70) at processing.app.AbstractTextMonitor.<init>(AbstractTextMonitor.java:49) at processing.app.TeensyMonitor.<init>(TeensyMonitor.java:46) at cc.arduino.packages.MonitorFactory.newMonitor(MonitorFactory.java:54) at processing.app.Editor.handleSerial(Editor.java:2257) at processing.app.EditorToolbar.mousePressed(EditorToolbar.java:383) at java.awt.Component.processMouseEvent(Component.java:6530) at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) at java.awt.Component.processEvent(Component.java:6298) at java.awt.Container.processEvent(Container.java:2238) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2296) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4897) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4531) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4475) at java.awt.Container.dispatchEventImpl(Container.java:2282) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
@Paul: Downloaded and install released TD 1.44 on IDE 1.87 and no issues. Compiled a sketch and it worked to SerMon.
@Diodac - is this also being seen on IDE 1.87 and TD 1.44? It would need to be to be investigated or resolved.
IDE 1.8.5 was out for many months and not seen notices of this. Perhaps a clean install of the current release will either fix a problem local to your system - lots of notes about security and protection in that listing after 'out of memory' - perhaps other system software ( antivirus ) is interfering. Or it may have been resolved.
I saw something similar to Diodac's problem before, but that was on a Mac with an outdated OSX version and multiple old java runtimes (and software needing these) installed which seemed to lead to conflicts although Arduino should in theory bring its own independent runtime.
Updating the OS and all the java based applications, removing unneeded old java runtimes (some were already cleaned away automatically during the OSX update), completely removing before and re-installing Arduino and Teensyduino afterwards did the job.
It could be interesting to know if that problem appears for Diodac only when a Teensy processor is selected in the boards menu or if it happens with Arduino boards, too...
I not tested jet 1.8.7 with other types of board, I have somewhere couple Mega's, Uno's if I find spare time, will try it.
Regarding crash it happened on released 1.44 with Teensy 3.2
I cleaned now my system from any junks, and older java and so on, I will see.
By the way, pieces useful commands for someone who want clean Java from OS X:
Run these commands if you want to remove Java plugins:
And "advanced" for "nuke" Java from systemCode:Run these commands if you want to remove Java plugins: sudo rm -rf /Library/Java/JavaVirtualMachines/* sudo rm -rf /Library/PreferencePanes/JavaControlPanel.prefPane sudo rm -rf /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin sudo rm -rf /Library/LaunchAgents/com.oracle.java.Java-Updater.plist sudo rm -rf /Library/PrivilegedHelperTools com.oracle.java.JavaUpdateHelper sudo rm -rf /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist sudo rm -rf /Library/Preferences/com.oracle.java.Helper-Tool.plist
Code:Some useful commands for delete Java sudo rm -rf /System/Library/Frameworks/JavaVM.framework sudo rm -rf /Library/Java/JavaVirtualMachines/* sudo rm -rf /var/db/receipts/com.oracle.jdk8u65.bom sudo rm -rf /var/db/receipts/com.oracle.jdk8u65.plist sudo rm -rf /var/db/receipts/com.oracle.jre.bom sudo rm -rf /var/db/receipts/com.oracle.jre.plist sudo rm -rf /var/root/Library/Preferences/com.oracle.javadeployment.plist sudo rm -rf ~/Library/Preferences/com.oracle.java.JavaAppletPlugin.plist sudo rm -rf ~/Library/Preferences/com.oracle.javadeployment.plist sudo rm -rf /Library/Java/* sudo rm -rf /Library/PreferencePanes/Java* sudo rm -rf /Library/Internet\ Plug-Ins/Java* sudo rm -rf ~/.oracle_jre_usage Done! Bye bye old useless Java! If you want totally kill Java on your Mac, use these commands, but after you need to update OS if want install Java again. sudo rm -rf /usr/bin/java sudo rm -rf /usr/bin/javac sudo rm -rf /usr/bin/javadoc sudo rm -rf /usr/bin/javah sudo rm -rf /usr/bin/javap sudo rm -rf /usr/bin/javaws
I've put this on my list of bugs to investigate.
Can you give me a little more info about your Macintosh? Which version of MacOS are you running? With Mac model do you have, and how much memory is installed?
The other important detail is exactly what you selected in the Ports menu. Since 1.42, there are 2 sections in the Ports menu. Here's a screenshot:
Even though the serial monitor looks similar (one has the baud rate drop-down, the other doesn't) these two use completely different ways to access Teensy. They use different Java code.
From the Java error you posted, my guess is you were using the "Serial ports" section, not the "Teensy" section. But this does involve a bit of guesswork on my part.
The key point is to understand these 2 similar-looking options have completely different code and access the data from Teensy in a very different way. To even begin to look into what's going so wrong with the code when running on your Mac, I need to know very clearly which one you're really using.
Which Java software you have installed elsewhere on your Mac is probably *not* important. Arduino has a copy of the Java JRE inside its application bundle. So unless you've modified your copy of Arduino, it's almost certainly using its own included copy of Java and not any other copy that may be installed elsewhere on your Mac.
Last edited by PaulStoffregen; 09-23-2018 at 06:29 PM.
Process: Arduino [465]
Path: /Applications/Arduino.app/Contents/MacOS/Arduino
Identifier: cc.arduino.Arduino
Version: 1.8.7 (1.8.7)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Arduino [465]
User ID: 501
Date/Time: 2018-09-16 03:56:25.561 +0100
OS Version: Mac OS X 10.11.6 (15G22010)
Report Version: 11
Time Awake Since Boot: 23000 seconds
System Integrity Protection: enabled
Crashed Thread: 25 Java: EventThread /dev/cu.usbmodem4275401
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
I have 8GB RAM and used Java 1.8 dedicated for OS X by Oracle.
Regarding to the ports, that one what you recommend, literally not working for me. I used it but java problem raised and occurred much often. Moreover always after couple minutes getting lost connection. When I use “not dedicated” serial Teensy then working better but java anyway make problems but not frequently like before.
Regarding java version and Arduino relationships. In my opinion exists dependence’s
First
I deleted all installed Java copies and problems still exist.
Second
When I erase all java files, folders literally I kill java on my MacBook then install fresh Arduino, wow Arduino even not starting because asking for java. It’s ridiculous.
Next step I had done, format C and install everything again and install dedicated old good SE runtime 1.6
Now Arduino starting and working pretty stable with Teensyduino 1.44 and java problems still exist but really rarely come out. Of course on “not dedicated” serial because other still not working correctly and making problems like before.
I have full Arduino/java crash report from my system when it’s happened last time. But there is some “sensitive ” data and binary images from my machine and processing. I happy to send it to Paul but I’m not pretty sure that is safe and good idea for publishing these reports without control in internet space.
Why staying with outdated macOS?
In msg #6, I asked you which selection you made from the Tools > Ports menu. I have gave a screenshot with red arrow overlay to explain the different selections.
As nearly as I can tell, you *still* have not said which Port selection was used. Why do you withhold this critically important information?
I only use the Java exception trace, similar to the one you posted on msg #2. Please post only that part.
Do not post Apple's binary process dumps here. I will *not* use them. The reality is I do not have any way to investigate a MacOS kernel panic. I am not a kernel developer. Even if I was, I do not work for Apple. While Apple does publish some stuff as open source, I have no access to key info needed to debug a MacOS kernel crash, even if I had the knowledge & experience to use such info. I simply can not meaningfully investigate a MacOS kernel panic. Only Apple can do that!
About solving this problem, first I would suggest using the other Ports menu selection. I *still* have to guess, because you will not tell us which one you really used, but from this error my guess is you selected the "Serial ports" section. This really looks like Java was accessing the serial device.
If you select the "Teensy" section, a completely different access to the port is used. Instead of Java using the JSSC library to access the port, a native "teensy_serialmon" program is run. You should be able to see it if you run "top" in Terminal. This program communicates with Java through stdin/stdout/stderr pipes, which means Java is not doing any hardware access at all.Crashed Thread: 25 Java: EventThread /dev/cu.usbmodem4275401
I would also agree with Theremingenieur, Apple published rather buggy serial drivers 3 years ago with El Capitan. Back when 10.11 was new, many people using Arduino and Teensy and other boards experienced many problems. Apple (mostly) fixed these bugs with Sierra. If your machine is able to upgrade, you should. However, I do know some hardware from 2008 or earlier (like the "cheese grater" MacPro 3,1) can't upgrade beyond 10.11 without unofficial hacks.
But even if you have one of those very old macs that can't upgrade, you certainly *CAN* clearly answer the question of msg #6. You *can* select the "Teensy" port instead of the "Serial port" from the Ports menu, and check that the "teensy_serialmon" is actually running and doing the communication.
at java.awt.EventDispatchThread.pumpEvents(EventDispa tchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThre ad.java:82)
I saidAs nearly as I can tell, you *still* have not said which Port selection was used. Why do you withhold this critically important information?
I tested both of them, and:Regarding to the ports, that one what you recommend, literally not working for me. I used it but java problem raised and occurred much often. Moreover always after couple minutes getting lost connection. When I use “not dedicated” serial Teensy then working better but java anyway make problems but not frequently like before.
In menu "top" position
Attachment 14856
And this one not working for me, many java problems when I open serial monitor after max 5 minutes lots of lags, stop working Arduino , and crash system with restart Mac itself :\
Fortunately I was able get this, after problem with "top" port before restart:
Code:Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3664) at java.lang.StringBuffer.toString(StringBuffer.java:669) at processing.app.AbstractMonitor.consumeUpdateBuffer(AbstractMonitor.java:164) at processing.app.AbstractMonitor.actionPerformed(AbstractMonitor.java:170) at javax.swing.Timer.fireActionPerformed(Timer.java:313) at javax.swing.Timer$DoPostEvent.run(Timer.java:245) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
About Serial ports:
I prefer to use "bottom" port, working better for me. Java problem occurs rarely , not 20times at day like with "top" port when I used.About solving this problem, first I would suggest using the other Ports menu selection. I *still* have to guess, because you will not tell us which one you really used, but from this error my guess is you selected the "Serial ports" section. This really looks like Java was accessing the serial device.
I had pretty old MacBook Pro (13-inch, Mid 2009) but 8GB ram and SSD, theoretically I can upgrade to Sierra but in practice not really. Although App Store prompt for upgrade my Mac, I tied but without success. I need use some hacks for that. Any way I need buy next one more powerful. But to this time I need get proper working Tensyduino on El Cap.I would also agree with Theremingenieur, Apple published rather buggy serial drivers 3 years ago with El Capitan. Back when 10.11 was new, many people using Arduino and Teensy and other boards experienced many problems. Apple (mostly) fixed these bugs with Sierra. If your machine is able to upgrade, you should. However, I do know some hardware from 2008 or earlier (like the "cheese grater" MacPro 3,1) can't upgrade beyond 10.11 without unofficial hacks.
Windows 10, with Teensy serial monitor open (Raw HID), but nothing prints (Sketch prints in setup() a few lines, only), so there should'nt be any workload :
There are two tasks with more than 30%... noisy fans.
Edit: Arduino 1.8.7
err.. one task... but still 30% when doing nothing
Last edited by Frank B; 10-02-2018 at 08:59 PM.
Probably I resolve my problems. I got to proper work 1.8.7 and java problem not occurred so far and working on “top” and “bottom” port.
Just I go to recovery mode, turn of protection password and from terminal I deleted all java sh@&€t even SE runtime every where possible, next reset PRAM and so on, restart Mac, install fresh Arduino and
Teensyduino. Now all working together without problems.
Hi Paul, I'm poking around the Wire libraries for Teensy 3.x for user option choice for I2C over CANquitto, and noticed that i2c_t3.h has Wire3 declared but Wire.h throws a compile error, only Wire,Wire1,Wire2 are initialized from Wire.h, T3.6 has Wire3 in the back of the board
Tony
Yes, to use Wire3 on Teensy 3.6 you would need to edit this in WireKinetis.h to uncomment the WIRE_IMPLEMENT_WIRE3 define.
Likewise for Teensy LC, Wire1 is not defined by default.Code:// Teensy 3.6 #elif defined(__MK66FX1M0__) #define WIRE_IMPLEMENT_WIRE #define WIRE_IMPLEMENT_WIRE1 #define WIRE_IMPLEMENT_WIRE2 //Wire3 is seldom used on Teensy 3.6 //#define WIRE_IMPLEMENT_WIRE3 #define WIRE_HAS_START_INTERRUPT #define WIRE_HAS_STOP_INTERRUPT
Unlike LC, we do have quite a lot of RAM on 3.6, so maybe Wire3 should be enabled by default? As far as I can really, this is the first time it's come up in the ~2 years we've been shipping Teensy 3.6....Code:// Teensy LC #if defined(__MKL26Z64__) #define WIRE_IMPLEMENT_WIRE //Wire1 consumes precious memory on Teensy LC //#define WIRE_IMPLEMENT_WIRE1 #define WIRE_HAS_STOP_INTERRUPT
that spammer who posted here i messaged him on facebook to stop flooding the forums and reported him, he “viewed” my message within a minute and never responded. He’s definately doing it on purpose
Cleaned and banned. Added his IP to the "IPs to block list". It was already put there by defragster, but it seems that Paul didn't find the time to process the list for a few days.
I'm going through the last few weeks of IPs right now (fell a little behind on this lately while working on Teensy4).... most are from India, Pakistan & Russia, adding more netblock to the forum's IP bans.
FWIW, that user who just posted 6 messages was from New Delhi, India connecting through "Empower Digital Networks" ASN #135772. This was almost certainly a case of professional spam operations hiring low-wage workers from India to post as many messages as possible, defeating anti-bot measures by using real people to do the dirty work. All 4096 of Empower Digital Networks IP numbers are now be blocked from ever accessing this forum.
Not sure what to do with this - I just saw it in Task Manager - no idea how it got there? I'm on Newest ( now pulled Win 10 1809.55 update ) with IDE 1.8.7 and TD 1.44 - except it is Frank_B's core for 256 MHz T_3.6. I of course am using TyCommander as Programmer and SerMon - and I have two T_3.6's online. Since booting 10 days and 14 hours ago I have closed and opened the IDE a few times Before and after pulling in the 256 MHz code.
What I see is this with orphaned ? T_ports::
And the Java Part:
I closed the IDE and the T_ports survived and I just ended them.
The only thing that comes to mind is I was doing DryStone and had TyCommander push the same HEX to BOTH T_3.6's at once. Wich looks like this in the console - perhaps that triggered this?
Though I closed the above and redid the compile and dual upload and it created no spare T_ports - so those must have survived prior IDE restarts::
"T:\\arduino-1.8.7_144_TYC\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_441718/DHRYSTONE.ino.elf"
Sketch uses 39568 bytes (3%) of program storage space. Maximum is 1048576 bytes.
Global variables use 15488 bytes (5%) of dynamic memory, leaving 246656 bytes for local variables. Maximum is 262144 bytes.
T:\TyComm\TyCommanderC.exe upload --autostart --wait --multi T:\TEMP\arduino_build_441718/DHRYSTONE.ino.TEENSY36.hex
upload@2649050-Teensy Uploading to board '2649050-Teensy' (Teensy 3.6)
upload@2649050-Teensy Triggering board reboot
upload@2272540-Teensy Uploading to board '2272540-Teensy' (Teensy 3.6)
upload@2272540-Teensy Triggering board reboot
upload@2649050-Teensy Firmware: DHRYSTONE.ino.TEENSY36.hex
upload@2272540-Teensy Firmware: DHRYSTONE.ino.TEENSY36.hex
upload@2649050-Teensy Flash usage: 39 kiB (3.8%)
upload@2272540-Teensy Flash usage: 39 kiB (3.8%)
upload@2649050-Teensy Uploading...
upload@2272540-Teensy Uploading...
upload@2649050-Teensy Sending reset command
upload@2272540-Teensy Sending reset command
The logical consequence would be dropping Windows support... No, just kidding...
Pretty sure this would happen on Mac and Linux too, if you force quit or "kill -9" the java process.
I rewrote teensy_ports for 1.44, using stdout rather than a localhost socket. It's no long able to detect when the Arduino process goes away. Another low priority issue for the list.....
However, the stdout change did (hopefully) fix the lag that could be caused on some machines when you clicked the Tools menu.
…The logical consequence would be dropping Windows support... No, just kidding...Still never funny ….
Windows is the best!Though my machine has shown a couple of anomalies since I got the 1809 Oct release - not related to why they say they pulled it though …
Paul- re post #18 - they were normal IDE Quit exits. i.e. Ctrl+Q. The taskman 'end tasks' were only done to clear the processes to look for repro.
I was going to say that TyComm was open throughout … but one time in the last days it did freeze (before second T_3.6) … I ended a program with loop() { … while(1); } … I realized that was UGLY WRT to USB - so I made it "while(1){yield()}" - but on that upload it needed to be killed - IIRC. { Should have tried a button press? }
This is similar to what happened back a couple releases - and the first I saw any sign of anything like it.
<edit>: Now that those spare T_ports are gone my IDE is running better - also after restarting and multiple uploads. I would hit Ctrl+U and my machine would do nothing for a few seconds before console showed any Compile action. Now it is started as it should. And at this point TaskMan shows no orphans.
<edit 2>: Frank's Dhrystone code is active and change empty loop to this and it does not repro:: void loop(void) { while(1);}. Also closed IDE and upload again is fine. Something odd happened.
never funny, but possibly trueMicrosoft has stopped the rollout of the Windows 10 October 2018 Update, just days after it started it during the company’s Surface event last week. The move comes after a number of people reported that the upgrade left them without some of their files, with document deletions becoming more and more widespread as the time rolled on.
Microsoft paused the rollout, saying “we have paused the rollout of the Windows 10 October 2018 Update (version 1809) for all users as we investigate isolated reports of users missing some files after updating.”
Hey Tim, thats the release you got! lol
I'm working in the IT domain for 30+ years, now. As a developer, as an administrator, as almost everything, in heterogenous environments (DOS/Novell/Win/Mac/Linux). Sorry to say that, but in my long term experience, I never saw a less reliable OS than all Windows releases since 2.0. Even the old MS-DOS 4.01 with himem.sys drivers was more stable.
Yes running that release on 4 machines here and put it on a few others. I have slow but costly broadband - and update numerous computers so I pull the ISO or bootable USB copies of install and KB updates as they appear.
The Oct release came as 1809.17763.1 on 10/2/2018. Still only one update 1809.17763.55 on 10/9/2018 and no updated news from MSFT since 10/9.
Anomalies are slight and maybe just passing? I used a Flash with write protect switch when getting said downloads and other tools to touch infected machines, on ejecting that (or others?) all instances of File Explorer have gone away more than once. And File open folder browsing sometimes fails as well. Not related to the published setup issue - but it never happened to me before.
To bring this back to prior posts - after another 2.6 days uptime (13d4hr) and multiple compiles and one or more IDE restarts and now with 5 active T_3.6's - TaskMan shows no indications of orphaned T_ports or other issues.
*Also I'm working in the IDE and with the VisualTeensy layer ( by @luni - very cool) on MSFT Visual (studio) Code. All is functioning well using TyCommander - and also TeensyLoader for upload by accident and confirmed on purpose with no side effects.
Pretty sure the orphaned teensy_ports issue is 100% my doing. Windows frustrates me on many occasions, but I can't blame Microsoft for that one. It's my fault. Unless those lingering instances seem to be causing problems (very unlikely), I'll probably delay fixing it until late 2019.
Maybe I should also mention the single instance behavior teensy_ports had in 1.42 was changed for 1.43. Now one instance per Arduino IDE instance is used. I redesigned the stuff that needed the single instance. The new way performs better (no lag on Arduino's Tools menu) and overall uses a simpler approach.
I personally use Linux as my primary desktop, partly because it's so stable, but mainly because I've been using Unix since the late 1980s. But just 2 weeks ago I was reminded that Linux isn't indestructible. While working on Teensy4's USB stack, I somehow managed to crash the USB hub driver or some internal kernel process. Lots of errors and some segfault stuff got logged. Amazingly the system stayed up, but I had to reboot to get USB fully working again.
Posting Permissions
Reply With Quote