Teensyduino 1.56 Beta #1

Status
Not open for further replies.
Might help to give it much more RAM.
I think the file is arduino.l4j.ini ini. Maybe Defragster wants to test this, too.
 
@Paul good long run here {1.74 hours} - just spotted garbage - then to blank and a 'wait' that recovered. Time stamps below give an idea of the time involved for recover to running (about 1.5 minutes).
Only USB1 input involved to generate - did not do any USB input :
Code:
6159.51==secs last lps calc USB1::	just saw Garbage
count=646004527, lines/sec=425091	Send sec =[B]6182.39[/B]
 >> Call by USB==1 or USB1==2 :: 2
[B]lps hits to =25000 = 2930[/B]
lps hits to =50000 = 201
lps hits to =75000 = 212
lps hits to =100000 = 449
lps hits to =125000 = 261
lps hits to =150000 = 262
lps hits to =175000 = 246
lps hits to =200000 = 230
lps hits to =225000 = 212
lps hits to =250000 = 138
lps hits to =275000 = 144
lps hits to =300000 = 153
lps hits to =325000 = 173
lps hits to =350000 = 113
lps hits to =375000 = 91
lps hits to =400000 = 163
lps hits to =425000 = 84
lps hits to =450000 = 91
lps hits to =475000 = 6
6277.51==secs last lps calc USB1::	stall completed
count=646910564, lines/sec=409554	Send sec =[B]6277.67[/B]
 >> Call by USB==1 or USB1==2 :: 2
[B][COLOR="#FF0000"]lps hits to =25000 = 3045[/COLOR][/B] [U]// this is 115 added counts under 25K lps - out of 118 seconds between "6159.51" and "6277.51==secs last lps calc "[/U]
lps hits to =50000 = 201
lps hits to =75000 = 212
lps hits to =100000 = 449
lps hits to =125000 = 261
lps hits to =150000 = 262
lps hits to =175000 = 246
lps hits to =200000 = 230
lps hits to =225000 = 212
lps hits to =250000 = 138
lps hits to =275000 = 144
lps hits to =300000 = 153
lps hits to =325000 = 173
lps hits to =350000 = 114
lps hits to =375000 = 91
lps hits to =400000 = 163
lps hits to =425000 = 85
lps hits to =450000 = 92
lps hits to =475000 = 6

Might help to give it much more RAM.
I think the file is arduino.l4j.ini ini. Maybe Defragster wants to test this, too.

Not sure it is starved for RAM but will see about that on next restart.
 
There is still a bug. Got garbage, and then this, when I closed the window.
Code:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at processing.app.FifoDocument.free(FifoDocument.java:168)
	at processing.app.TeensyPipeMonitor.window_close(TeensyPipeMonitor.java:222)
	at processing.app.TeensyPipeMonitor$3.windowClosing(TeensyPipeMonitor.java:98)
	at java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:350)
	at java.awt.Window.processWindowEvent(Window.java:2054)
	at javax.swing.JFrame.processWindowEvent(JFrame.java:305)
	at java.awt.Window.processEvent(Window.java:2013)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	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:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	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:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	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)
Null pointer exception.
 
Only IDE crash seen here was when the IDE SerMon was tested instead of T_sermon.

Running well about another half hour (not caught any garbage flashes in periph vision 2nd screen}- speeds tending higher - 400K+ then followed by some 1 lps's.
These below over this 134 seconds added : #47 under 25K and #22 over 400K:
Code:
8471.50==secs last lps calc USB1::	
count=877512825, lines/sec=425303	Send sec =8483.06
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 4553
lps hits to =50000 = 222
lps hits to =75000 = 231
lps hits to =100000 = 465
lps hits to =125000 = 282
lps hits to =150000 = 283
lps hits to =175000 = 263
lps hits to =200000 = 251
lps hits to =225000 = 228
lps hits to =250000 = 156
lps hits to =275000 = 166
lps hits to =300000 = 171
lps hits to =325000 = 195
lps hits to =350000 = 136
lps hits to =375000 = 111
lps hits to =400000 = 178
lps hits to =425000 = 212
lps hits to =450000 = 360
lps hits to =475000 = 8

8605.50==secs last lps calc USB1::	
count=889692441, lines/sec=21968	Send sec =8605.74
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 4650
lps hits to =50000 = 222
lps hits to =75000 = 233
lps hits to =100000 = 466
lps hits to =125000 = 284
lps hits to =150000 = 284
lps hits to =175000 = 264
lps hits to =200000 = 253
lps hits to =225000 = 229
lps hits to =250000 = 157
lps hits to =275000 = 166
lps hits to =300000 = 171
lps hits to =325000 = 197
lps hits to =350000 = 136
lps hits to =375000 = 112
lps hits to =400000 = 179
lps hits to =425000 = 222
lps hits to =450000 = 372
lps hits to =475000 = 8

Stalled or just a minute pause again? ... just after this was posted ... waiting ... :
Code:
9063.50==secs last lps calc USB1::	white after pause
count=937660963, lines/sec=424695	Send sec =9115.32
 >> Call by USB==1 or USB1==2 :: 2
 
Let it sit about 937 seconds between updates?

Opps Autoscroll was left OFF ... The 'count' was running and where it was was blank ...

Going to leave this Dual Serial version run next few hours. It is running against the updated teensy_serialmon, but with posted changes that still failed on TD.156b1 version. Stats won't know when PC gets garbage, but if it stops I'll know when and see if it wakes on USB input - but seems like it may stay running?

JVM memory not changed. Did a Win 11 restart 28 hours ago, and WiFi has been destroyed to 'Not available'. Only this production T_4.1 online.

Code:
[B][U]9063.50[/U][/B]==secs last lps calc USB1::	white after pause
count=937660963, lines/sec=424695	Send sec =9115.32
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 4967
lps hits to =50000 = 226
lps hits to =75000 = 236
lps hits to =100000 = 471
lps hits to =125000 = 291
lps hits to =150000 = 290
lps hits to =175000 = 264
lps hits to =200000 = 255
lps hits to =225000 = 231
lps hits to =250000 = 163
lps hits to =275000 = 168
lps hits to =300000 = 176
lps hits to =325000 = 200
lps hits to =350000 = 138
lps hits to =375000 = 114
lps hits to =400000 = 185
lps hits to =425000 = 267
lps hits to =450000 = 412
lps hits to =475000 = 9
[B][U]10001.50[/U][/B]==secs last lps calc USB1::	???
count=1305140466, lines/sec=434713	Send sec =10001.70
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 5066
lps hits to =50000 = 226
lps hits to =75000 = 236
lps hits to =100000 = 471
lps hits to =125000 = 292
lps hits to =150000 = 290
lps hits to =175000 = 264
lps hits to =200000 = 255
lps hits to =225000 = 231
lps hits to =250000 = 163
lps hits to =275000 = 168
lps hits to =300000 = 176
lps hits to =325000 = 200
lps hits to =350000 = 139
lps hits to =375000 = 114
lps hits to =400000 = 185
lps hits to =425000 = 369
lps hits to =450000 = 1147
lps hits to =475000 = 9

View attachment 26029
 
@Paul - was the stall in sermon what was triggered to continue when a 'Send' went out?

If so that says it wasn't the Teensy sketch having any effect.

Code:
14189.50==secs last lps calc USB1::	night running 2
count=1556330840, lines/sec=435608	Send sec =14211.25
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 8592
lps hits to =50000 = 236
lps hits to =75000 = 247
lps hits to =100000 = 484
lps hits to =125000 = 301
lps hits to =150000 = 302
lps hits to =175000 = 278
lps hits to =200000 = 266
lps hits to =225000 = 246
lps hits to =250000 = 174
lps hits to =275000 = 185
lps hits to =300000 = 187
lps hits to =325000 = 208
lps hits to =350000 = 149
lps hits to =375000 = 123
lps hits to =400000 = 191
lps hits to =425000 = 412
lps hits to =450000 = 1591
lps hits to =475000 = 17
 
Is it possible to use a win7 usbser.sys ? Or to emaulate an other device which has own drivers? FTDI or such?
 
@Paul - was the stall in sermon what was triggered to continue when a 'Send' went out?

The main teensy_serialmon thread uses WIN32 MsgWaitForMultipleObjects() to wait for any of 3 things:

1: Data received from Teensy
2: Data received from Arduino (actually an event signaled by another thread which receives from Arduino)
3: USB device change events

#1 is done using WIN32 ReadFile with Overlapped IO. If no data is available to read, at least by my understanding of WIN32 Overlapped IO, ReadFile is supposed to return false and GetLastError() gives ERROR_IO_PENDING. When data later arrives, Windows will signal the hEvent handle within the OVERLAPPED struct ReadFile() was given. It almost always does exactly that, as you can see dozens to hundreds of millions of lines are successfully received before the stall happens.

But once in a blue moon, ReadFile was returning true, indicating data received without waiting, but zero actual data. That makes no sense (at least to me) so I wasn't handling that case and the result was MsgWaitForMultipleObjects() would wait forever. But it was still waiting for any of the 3 events. Sending anything from the serial monitor would trigger case case #2. Once MsgWaitForMultipleObjects() terminated its wait, the rest of teensy_serialmon would recover.

The change on msg #73 adds an explicit check for this rare scenario before calling MsgWaitForMultipleObjects(). Normally I don't use the timeout feature of MsgWaitForMultipleObjects(), unless we're in the middle of a flurry of WM_DEVICECHANGE events (remember we're listening for more than just arrival of serial ports), which don't all arrive reliably on older versions of Windows, so a timeout in that scenario puts the whole program temporarily into a sort of polling mode for case #3. Now a timeout is also used in the rare ReadFile sucessful-but-zero-length case, so even though I don't understand why Windows does this, we quickly recover.
 
Last edited:
Here it is some time later and all is running well with no stalls and still running after 12 hours

Below is a second by second breakdown of the reported lines/second for 43336 seconds, in groups of 25,000
Code:
43336.50==secs last lps calc USB1::	Running fine Hours later
count=2992437855, lines/sec=423985	Send sec =43336.78
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 34119
lps hits to =50000 = 272
lps hits to =75000 = 280
lps hits to =100000 = 517
lps hits to =125000 = 344
lps hits to =150000 = 346
lps hits to =175000 = 319
lps hits to =200000 = 314
lps hits to =225000 = 281
lps hits to =250000 = 206
lps hits to =275000 = 213
lps hits to =300000 = 227
lps hits to =325000 = 244
lps hits to =350000 = 190
lps hits to =375000 = 177
lps hits to =400000 = 411
lps hits to =425000 = 1027
lps hits to =450000 = 3828
lps hits to =475000 = 21

The main teensy_serialmon thread uses WIN32 MsgWaitForMultipleObjects() to wait for any of 3 things:

1: Data received from Teensy
2: Data received from Arduino (actually an event signaled by another thread which receives from Arduino)
3: USB device change events

...

Great - that seems to explain the 'Send' workaround perfectly then.
Explains why use of Dual Serial USB1 worked to 2nd Sermon_TyComm without starting up Tsermon because the trouble wasn't in the Teensy.

Another 4 hours runtime - All Good:
Code:
58135.50==secs last lps calc USB1::	Running fine Hours later
count=3818608892, lines/sec=440312	Send sec =58139.13
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 46909
lps hits to =50000 = 281
lps hits to =75000 = 287
lps hits to =100000 = 525
lps hits to =125000 = 362
lps hits to =150000 = 356
lps hits to =175000 = 334
lps hits to =200000 = 324
lps hits to =225000 = 295
lps hits to =250000 = 222
lps hits to =275000 = 228
lps hits to =300000 = 234
lps hits to =325000 = 254
lps hits to =350000 = 198
lps hits to =375000 = 201
lps hits to =400000 = 554
lps hits to =425000 = 1368
lps hits to =450000 = 5181
lps hits to =475000 = 22
 
Last edited:
Updated 'Test' no stall teensy_serialmon seems to be running fine 96595 secs is 26.8 hrs and counting.
> this is using posted dual serial built code with the .availableForWrite() limiter.

Turned off Auto Scroll showing last line captured in the comment : count=4273113132, lines/sec=439160

Interesting that the GUI showing counts on USB at 4,273,113,132, and the USB1 showing 'actual current count' as 22,405,378 shows how much lag with lost/buffered data lines there are. Even a couple minutes later the GUI is showing 4,291,051,846

87% reported under 25K lps?

Code:
96467.51==secs last lps calc USB1::	[B]count=4273113132, lines/sec=439160[/B]
[B][U]count=22405378[/U][/B], lines/sec=426688	Send sec =96595.05
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 84042
lps hits to =50000 = 285
lps hits to =75000 = 290
lps hits to =100000 = 531
lps hits to =125000 = 370
lps hits to =150000 = 360
lps hits to =175000 = 338
lps hits to =200000 = 328
lps hits to =225000 = 297
lps hits to =250000 = 225
lps hits to =275000 = 231
lps hits to =300000 = 237
lps hits to =325000 = 254
lps hits to =350000 = 198
lps hits to =375000 = 227
lps hits to =400000 = 683
lps hits to =425000 = 1587
lps hits to =450000 = 5948
lps hits to =475000 = 36
 
There is still a bug. Got garbage, and then this, when I closed the window.
Code:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at processing.app.FifoDocument.free(FifoDocument.java:168)
	at processing.app.TeensyPipeMonitor.window_close(TeensyPipeMonitor.java:222)
	at processing.app.TeensyPipeMonitor$3.windowClosing(TeensyPipeMonitor.java:98)
	at java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:350)
	at java.awt.Window.processWindowEvent(Window.java:2054)
	at javax.swing.JFrame.processWindowEvent(JFrame.java:305)
	at java.awt.Window.processEvent(Window.java:2013)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	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:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	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:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	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)
Null pointer exception.

@Mcu32:

Speaking from personal knowledge & experience (I have 35+ years of experience developing & delivering multi-threaded, real-time, data intensive serial & network communications systems written in java and/or c/c++ for military customers - these programs run under RHEL7x to exchange & process multi-megabytes of data continuously without any losses or misses across multiple intefaces), this null pointer exception is meaningless. If/when a multi-threaded program (java or otherwise) is shutdown, there is a very high likelihood that one of the threads which is still running will try to access something that another of the threads that is already shutdown was providing. Getting a null pointer exception during runtime, now that's something to worry about. However, getting a null pointer exception while shutting down means absolutely nothing !! We see that behavior (exceptions during shutdown) in our java systems quite often & I can assure you that it is meaningless.

I've stayed on the sidelines observing these discussions on efforts to characterize the loss and/or corruption of data in the serial monitor, but now that I've poked my nose into it, I will take the opportunity to inject my two cents worth. For those (like me) who use the serial monitor as a debug tool, all serial monitor outputs are critically important. Any drops and/or corruption of the serial monitor data stream could/will impact the ability to troubleshoot. If it just so happens that the one message containing the critically important debug report was the one that was dropped and/or corrupted, then the ability to accurately debug is completely shot !! I believe that the serial monitor stress testing being done is very valuable & hardly a waste of time. Paul is to be commended for the efforts (both past & present) that he has put into improving both the performance & the reliability of the serial monitor capability. I appreciate everything that he can do to continue to improve both the performance and the reliability, as it directly (& positively) affects my ability to debug.

Mark J Culross
KD5RXT
 
Speaking from personal knowledge & experience (I have 35+ years of experience developing & delivering multi-threaded, real-time, data intensive serial & network communications systems written in java and/or c/c++ for military customers [...] We see that behavior (exceptions during shutdown) in our java systems quite often & I can assure you that it is meaningless.
If the military as your customer accepts null pointer exceptions, it freightens me very much.
I have no problem with the errormessage when closing the monitor. But it must be allowed to inform PJRC about it? Seems, not.

I AM a customer.

I've stayed on the sidelines observing these discussions on efforts to characterize the loss and/or corruption of data in the serial monitor, but now that I've poked my nose into it, I will take the opportunity to inject my two cents worth. For those (like me) who use the serial monitor as a debug tool, all serial monitor outputs are critically important. Any drops and/or corruption of the serial monitor data stream could/will impact the ability to troubleshoot. If it just so happens that the one message containing the critically important debug report was the one that was dropped and/or corrupted, then the ability to accurately debug is completely shot !! I believe that the serial monitor stress testing being done is very valuable & hardly a waste of time. Paul is to be commended for the efforts (both past & present) that he has put into improving both the performance & the reliability of the serial monitor capability. I appreciate everything that he can do to continue to improve both the performance and the reliability, as it directly (& positively) affects my ability to debug.
You're right if you're telling me here that the speed-test is meaningless. I say the same?
But it seems you did not get that there is a windows problem. Nobody says that the monitor can be fixed. Have I?
But, there is probably a way (a workaround) to at least reduce the amount of garbage. It affects almost all windows software that uses a serial connection to the Teensy (and other MCUs - if you googled a bit or read my links). So it must be allowed to talk about that?
Again, I don't get what you want.

But it seems not to be interesting for the others, too, as my Idea to use an other driver got ignored completely. So, if it's not interesting, there's no point in talking about it anyway.
 
Last edited:
If the military as your customer accepts null pointer exceptions, it freightens me very much.
I have no problem with the errormessage when closing the monitor.


Again, I don't get what you want.

@Mcu32:

I don't want anything from you except (maybe) to correctly understand the point I made. Here's a shaved-down version of my original post with just the pertinent info since you seem to have missed the point the first time:

If/when a multi-threaded program (java or otherwise) is shutdown, there is a very high likelihood that one of the threads which is still running will try to access something that another of the threads that is already shutdown was providing. Getting a null pointer exception during runtime, now that's something to worry about. However, getting a null pointer exception while shutting down means absolutely nothing !!

Your poor attempts to put words in my mouth (null pointer exceptions during runtime are OK) & thereby come to an invalid conclusion (my military customer accepts null pointer exceptions during runtime) certainly go unappreciated at this end. You can be frightened by your incorrect understanding all you want . . . that does not change the facts. Adding an exception handler for this does not change the fact that the serial monitor is shutting down. Do you really expect it to do something different (e.g. issue an error message) as it shuts down ?!?!? For what purpose ?? It's shutting down, after all !!

If as you say, you "have no problem with the errormessage [sic] when closing the monitor", then I'm not really sure why you posted the null exception like it was some kind of flaw in the serial monitor worthy of a change ?? I stand by my assessment: meaningless.

And your suggestion to use a different driver is just that: a suggestion. You sound like you think that there is an implied obligation to recognize your suggestion, or an implied intent to investigate it. Paul has written many times here in this forum that his time is very limited, so he (& he alone) decides where to spend his time. If there were infinite hours in every day, we could all run down every rabbit hole & investigate each of them fully & to our complete satisfaction. Reality sucks, but it also constrains what can actually be done. I might suggest that it could be more beneficial if *you* investigated the possibility of using a different driver as you have suggested & report your results (positive or negative) back here so that all can benefit, rather than just throwing rocks like it appears that you have.

Mark J Culross
KD5RXT
 
Last edited:
But it must be allowed to inform PJRC about it? Seems, not.

I saw your message about the null pointer exception. I have put it on my list of low priority issues.

Regarding that Java NPE, I've never personally seen it happen, despite opening and closing the serial monitor window hundreds of times. So when I do go to fix it, I'll be doing so without any reliable way to reproduce the issue for testing.

I do know exactly which code is involved - it was my attempt to work around an issue on MacOS where something was holding a reference to FifoDocument's buffer memory after the serial monitor was closed. Each time opening the serial monitor would allocate another huge chunk of memory, eventually causing the Arduino IDE to allocate too much memory for most Macs. Digging back into that code will involve more than just that NPE error... testing on MacOS with both the new and old builds will be needed to make sure I don't revert to that much worse memory leak problem affecting Mac users. I still don't know why that memory leak wasn't a problem on Linux and Windows, since they're supposedly all the same Java virtual machine. But setting that object reference to null was enough to get the Mac JRE to be able to garbage collect the memory.


But, there is probably a way (a workaround) to at least reduce the amount of garbage. It affects almost all windows software that uses a serial connection to the Teensy (and other MCUs - if you googled a bit or read my links). So it must be allowed to talk about that?
Again, I don't get what you want.

Sure, talk about this problem or any others here. That what this forum and especially these beta test threads about all about.

But please do not expect me to be able to write a response to every issue and every message. I do try to read every message, but often I fall behind. Sometimes the business side of PJRC takes most of my time. Other times I try to focus on 1 development, plus generally answering user tech support questions. I believe I've already mentioned at least once, maybe a couple times on this thread that I'm currently focusing on MTP and the lingering 1.07 bootloader issue causing spurious red LED blinks after uploading.


But it seems not to be interesting for the others, too, as my Idea to use an other driver got ignored completely.

Msg #84, right?

How would I know if copying USBSER.SYS from Windows 7 works or not? It might, but then you might end up with the even worse CDC serial bugs of Windows XP & 7 & 8. Or it might not work at all. The only way to know is if you try copying the file (and maybe others?) between different versions of Windows and see what happens.

But as far as ideas go, that's the sort of hack that obviously isn't very feasible for PJRC to integrate into Teensduino. If it works, at best we could merely document it on the website. There's no way a copy of Microsoft's driver is going to be put into the Teensyduino installer.

Likewise for suggesting emulating some other device... what sort of response where you expecting? Maybe someone will see that idea and chime in with knowledge of some other driver, but it won't be me. Remember, I'm a Linux user who occasionally also uses MacOS, but I really don't use Windows and I'm not at all familiar with what sort of drivers and software are available.

The 2 reasons we use CDC is the protocol is an open standard and every operating system has the driver installed by default. It's important for a device programmed on a computer with Arduino+Teensyduino installed to be able to "just work" when plugged into another machine without the software installation. Before Windows 10 the driver didn't auto-load, so an INF needed to be installed. The last thing I want to do is return to those bad-old-days where people had to install a "driver" (the end user perception of installing an INF to Windows). So if you want to seriously suggest emulating some other non-CDC device, just casually suggesting such a n idea without going to the leg-work of researching which other protocol would work and has a driver already installed on Windows isn't the sort of thing anyone should expect to get much attention. This thread has a lot of casual conversation and you really can expect those sort of casual ideas without useful details or research to get lost in all this noise.

But I can confirm the Java NPE absolutely is on my list of bugs to investigate. It would really help if you could give me a clearer idea of how to reproduce it, as I haven't see it appear on my Windows test machine.
 
kd5 got excited that I mentioned it. Have no Idea, why. As said, I don't care about the NPE, I just thought it might be interesting for you to know. I have no idea how to reproduce this reliably. I must have closed the window at exactly the right moment. I wouln'd care it it was NOT on your list.

About the other thing: Well, maybe someone wants to try it out.

p.s. I'll add KD5 to my ignore list. I am no longer willing to read unnecessary provocations.
 
...
For those (like me) who use the serial monitor as a debug tool, all serial monitor outputs are critically important. Any drops and/or corruption of the serial monitor data stream could/will impact the ability to troubleshoot. If it just so happens that the one message containing the critically important debug report was the one that was dropped and/or corrupted, then the ability to accurately debug is completely shot !! I believe that the serial monitor stress testing being done is very valuable & hardly a waste of time. Paul is to be commended for the efforts (both past & present) that he has put into improving both the performance & the reliability of the serial monitor capability. I appreciate everything that he can do to continue to improve both the performance and the reliability, as it directly (& positively) affects my ability to debug.

Mark J Culross
KD5RXT

Agreed! It is understood that SerMon is the primary way to detect and debug errors with Teensy. Sometimes it takes 100 bytes one time to show the existence or solution to a problem, other times hours of ponderous spew can hide or contain that critical info, so it has to work. Real solution to a given problem may take a logic analyzer or O-scope or other I/O based tools, but reliable SerMon feedback can be critical: before, during, and after that.


On this Windows 11 machine as noted ignored/observed for over a day:
> No faults or errors in T_sermon, it is still running to some degree
> with ponderous spew the UI lag is extreme, not a useful way to use SerMon - except to prove a known fix and see if others are needed.
> Not seen much in the way of 'Garbage' blocks passing - though eyeballs on it are a small part of the time running.


One more update on the long term test likely to end when I get back here:
Code:
131271.51==secs last lps calc USB1::	count=351971974, lines/sec=419964
count=388562095, lines/sec=427392	Send sec =132192.40
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 117959
lps hits to =50000 = 288
lps hits to =75000 = 290
lps hits to =100000 = 535
lps hits to =125000 = 371
lps hits to =150000 = 362
lps hits to =175000 = 341
lps hits to =200000 = 333
lps hits to =225000 = 298
lps hits to =250000 = 228
lps hits to =275000 = 232
lps hits to =300000 = 242
lps hits to =325000 = 256
lps hits to =350000 = 203
lps hits to =375000 = 245
lps hits to =400000 = 755
lps hits to =425000 = 1881
lps hits to =450000 = 6416
lps hits to =475000 = 36

Showing - with the Dual Serial USB1 output on Send on that USB1:
> obvious and hopefully accurate 1 sec recording of observed :: lpsSum[ count_per_second / 25000 ]++;
> Seconds from millis() of 132192.40 is 36.72 hours
> obscure #1: sketch count of 388,562,095 is way ahead of SerMon displayed line of 351,971,974. A diff of 36,590,121
> obscure #2: at point of USB1 Send seconds is 132192.40, BUT the seconds when lps last calculated is 131271.51?

Doing T_sermon 'Clear output' does SYNC seconds - though 'count' still not matching?:
Code:
[B]132739.51[/B]==secs last lps calc USB1::	'Clear output' : count=426080202, lines/sec=420954
count=440956119, lines/sec=427392	Send sec =[B]132740.05[/B]
 >> Call by USB==1 or USB1==2 :: 2
lps hits to =25000 = 119299
lps hits to =50000 = 289
lps hits to =75000 = 291
lps hits to =100000 = 535
lps hits to =125000 = 372
lps hits to =150000 = 362
lps hits to =175000 = 341
lps hits to =200000 = 333
lps hits to =225000 = 298
lps hits to =250000 = 228
lps hits to =275000 = 233
lps hits to =300000 = 242
lps hits to =325000 = 256
lps hits to =350000 = 203
lps hits to =375000 = 248
lps hits to =400000 = 766
lps hits to =425000 = 1931
lps hits to =450000 = 6476
lps hits to =475000 = 36

It seems in doing that - Tsermon still running but IDE has this memory note - not sure when it appeared as the window waas hidden:
Code:
...
"C:\\T_Drive\\Arduino_1.8.16_155\\hardware\\teensy/../tools/teensy_size" "R:\\Temp\\arduino_build_975700/USB-Serial-Print-Speed-Test-Avail.ino.elf"
Memory Usage on Teensy 4.1:
  FLASH: code:13788, data:1840, headers:8944   free for files:8101892
   RAM1: variables:13120, code:11120, padding:21648   free for local variables:478400
   RAM2: variables:24736  free for malloc/new:499552
C:\T_Drive\Arduino_1.8.16_155\hardware\teensy/../tools/teensy_post_compile -file=USB-Serial-Print-Speed-Test-Avail.ino -path=R:\Temp\arduino_build_975700 -tools=C:\T_Drive\Arduino_1.8.16_155\hardware\teensy/../tools -board=TEENSY41 -reboot -port=usb:0/140000/0/6/1/2 -portlabel=[no_device] Bootloader -portprotocol=Teensy 
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at sun.font.GlyphList.ensureCapacity(GlyphList.java:166)
	at sun.font.GlyphList.setFromGlyphVector(GlyphList.java:292)
	at sun.java2d.pipe.GlyphListPipe.drawGlyphVector(GlyphListPipe.java:136)
	at sun.java2d.SunGraphics2D.drawGlyphVector(SunGraphics2D.java:3003)
	at sun.font.ExtendedTextSourceLabel.handleDraw(ExtendedTextSourceLabel.java:193)
	at sun.font.Decoration.drawTextAndDecorations(Decoration.java:122)
	at sun.font.ExtendedTextSourceLabel.draw(ExtendedTextSourceLabel.java:197)
	at java.awt.font.TextLine.draw(TextLine.java:776)
	at java.awt.font.TextLayout.draw(TextLayout.java:2647)
	at sun.java2d.pipe.GlyphListPipe.drawChars(GlyphListPipe.java:111)
	at sun.java2d.pipe.ValidatePipe.drawChars(ValidatePipe.java:178)
	at sun.java2d.SunGraphics2D.drawChars(SunGraphics2D.java:3036)
	at sun.swing.SwingUtilities2.drawChars(SwingUtilities2.java:847)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:187)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:106)
	at javax.swing.text.PlainView.drawUnselectedText(PlainView.java:154)
	at javax.swing.text.PlainView.drawElement(PlainView.java:113)
	at javax.swing.text.PlainView.drawLine(PlainView.java:82)
	at javax.swing.text.PlainView.paint(PlainView.java:311)
	at javax.swing.plaf.basic.BasicTextUI$RootView.paint(BasicTextUI.java:1434)
	at javax.swing.plaf.basic.BasicTextUI.paintSafely(BasicTextUI.java:737)
	at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:881)
	at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:860)
	at javax.swing.JComponent.paintComponent(JComponent.java:780)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at sun.font.GlyphList.ensureCapacity(GlyphList.java:166)
	at sun.font.GlyphList.setFromGlyphVector(GlyphList.java:292)
	at sun.java2d.pipe.GlyphListPipe.drawGlyphVector(GlyphListPipe.java:136)
	at sun.java2d.SunGraphics2D.drawGlyphVector(SunGraphics2D.java:3003)
	at sun.font.ExtendedTextSourceLabel.handleDraw(ExtendedTextSourceLabel.java:193)
	at sun.font.Decoration.drawTextAndDecorations(Decoration.java:122)
	at sun.font.ExtendedTextSourceLabel.draw(ExtendedTextSourceLabel.java:197)
	at java.awt.font.TextLine.draw(TextLine.java:776)
	at java.awt.font.TextLayout.draw(TextLayout.java:2647)
	at sun.java2d.pipe.GlyphListPipe.drawChars(GlyphListPipe.java:111)
	at sun.java2d.pipe.ValidatePipe.drawChars(ValidatePipe.java:178)
	at sun.java2d.SunGraphics2D.drawChars(SunGraphics2D.java:3036)
	at sun.swing.SwingUtilities2.drawChars(SwingUtilities2.java:847)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:187)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:106)
	at javax.swing.text.PlainView.drawUnselectedText(PlainView.java:154)
	at javax.swing.text.PlainView.drawElement(PlainView.java:113)
	at javax.swing.text.PlainView.drawLine(PlainView.java:82)
	at javax.swing.text.PlainView.paint(PlainView.java:311)
	at javax.swing.plaf.basic.BasicTextUI$RootView.paint(BasicTextUI.java:1434)
	at javax.swing.plaf.basic.BasicTextUI.paintSafely(BasicTextUI.java:737)
	at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:881)
	at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:860)
	at javax.swing.JComponent.paintComponent(JComponent.java:780)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at sun.font.GlyphList.ensureCapacity(GlyphList.java:166)
	at sun.font.GlyphList.setFromGlyphVector(GlyphList.java:292)
	at sun.java2d.pipe.GlyphListPipe.drawGlyphVector(GlyphListPipe.java:136)
	at sun.java2d.SunGraphics2D.drawGlyphVector(SunGraphics2D.java:3003)
	at sun.font.ExtendedTextSourceLabel.handleDraw(ExtendedTextSourceLabel.java:193)
	at sun.font.Decoration.drawTextAndDecorations(Decoration.java:122)
	at sun.font.ExtendedTextSourceLabel.draw(ExtendedTextSourceLabel.java:197)
	at java.awt.font.TextLine.draw(TextLine.java:776)
	at java.awt.font.TextLayout.draw(TextLayout.java:2647)
	at sun.java2d.pipe.GlyphListPipe.drawChars(GlyphListPipe.java:111)
	at sun.java2d.pipe.ValidatePipe.drawChars(ValidatePipe.java:178)
	at sun.java2d.SunGraphics2D.drawChars(SunGraphics2D.java:3036)
	at sun.swing.SwingUtilities2.drawChars(SwingUtilities2.java:847)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:187)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:106)
	at javax.swing.text.PlainView.drawUnselectedText(PlainView.java:154)
	at javax.swing.text.PlainView.drawElement(PlainView.java:113)
	at javax.swing.text.PlainView.drawLine(PlainView.java:82)
	at javax.swing.text.PlainView.paint(PlainView.java:311)
	at javax.swing.plaf.basic.BasicTextUI$RootView.paint(BasicTextUI.java:1434)
	at javax.swing.plaf.basic.BasicTextUI.paintSafely(BasicTextUI.java:737)
	at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:881)
	at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:860)
	at javax.swing.JComponent.paintComponent(JComponent.java:780)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at sun.font.GlyphList.ensureCapacity(GlyphList.java:166)
	at sun.font.GlyphList.setFromGlyphVector(GlyphList.java:292)
	at sun.java2d.pipe.GlyphListPipe.drawGlyphVector(GlyphListPipe.java:136)
	at sun.java2d.SunGraphics2D.drawGlyphVector(SunGraphics2D.java:3003)
	at sun.font.ExtendedTextSourceLabel.handleDraw(ExtendedTextSourceLabel.java:193)
	at sun.font.Decoration.drawTextAndDecorations(Decoration.java:122)
	at sun.font.ExtendedTextSourceLabel.draw(ExtendedTextSourceLabel.java:197)
	at java.awt.font.TextLine.draw(TextLine.java:776)
	at java.awt.font.TextLayout.draw(TextLayout.java:2647)
	at sun.java2d.pipe.GlyphListPipe.drawChars(GlyphListPipe.java:111)
	at sun.java2d.pipe.ValidatePipe.drawChars(ValidatePipe.java:178)
	at sun.java2d.SunGraphics2D.drawChars(SunGraphics2D.java:3036)
	at sun.swing.SwingUtilities2.drawChars(SwingUtilities2.java:847)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:187)
	at javax.swing.text.Utilities.drawTabbedText(Utilities.java:106)
	at javax.swing.text.PlainView.drawUnselectedText(PlainView.java:154)
	at javax.swing.text.PlainView.drawElement(PlainView.java:113)
	at javax.swing.text.PlainView.drawLine(PlainView.java:82)
	at javax.swing.text.PlainView.paint(PlainView.java:311)
	at javax.swing.plaf.basic.BasicTextUI$RootView.paint(BasicTextUI.java:1434)
	at javax.swing.plaf.basic.BasicTextUI.paintSafely(BasicTextUI.java:737)
	at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:881)
	at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:860)
	at javax.swing.JComponent.paintComponent(JComponent.java:780)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
	at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1353)
	at processing.app.inputPipeListener.update_gui(TeensyPipeMonitor.java:321)
	at processing.app.inputPipeListener.run(TeensyPipeMonitor.java:284)
Caused by: java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
 
@Paul

On a different note than Serial Monitor been using the locked T4.1 extensively testing MTP/LittleFS/UsbMscFat integration stuff. Have not seen any issues with uploading and flashing LEDs etc. All goes as expected.
 
@Paul

On a different note than Serial Monitor been using the locked T4.1 extensively testing MTP/LittleFS/UsbMscFat integration stuff. Have not seen any issues with uploading and flashing LEDs etc. All goes as expected.
Me sort of same. Have also done some testing with T, T4 locked and T3.6

So far so good.

Although one thing I still want to track down... Recently I have been running into times where Windows won't shut down. I will get a popup saying something
like: Task Host Window Prevents Shut Down in Windows.

have no idea yet if at all related to Teensy stuff or MTP stuff, or Something completely different...

Will experiment more soon.
 
It seems in doing that - Tsermon still running but IDE has this memory note - not sure when it appeared as the window waas hidden:

hmmmm.,...quite possible that a solution might be somewhere hidden in the useless casual posts here. probably.
Just add it to your list of low priority issues.
 
Last edited:
hmmmm.,...quite possible that a solution might be somewhere hidden in the useless casual posts here. probably.
Just add it to your list of low priority issues.

As for that : Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Hard to say. Just saw it and posted for Paul's review in case it adds something.
> Odd thing is IDE didn't get 'killed off' and T_SerMon still actively running. So some dumb non-fatal JAVA issue (maybe PJRC controllable?) - with the large amount of memory for USB buffering, that is still using the default Memory Start and Max settings in that INI.
- noted before only latest IDE 'JAVA' issue was not testing T_sermon - But these two other 'wholly terminating IDE':: dying building Code4Code.ino large 3MB INO, and using the IDE SerMon dying quickly in earlier lines/sec testing.

Paul's quite good at tracking things for when they get a 'time slice' - unfortunately PJRC task list has had over 18 months of (more than usual and newly unusual) outside events controlling high priority event insertion :(
> and issues that have details and repro at hand make sense for higher priority because they are more likely to have a possible/efficient solution and a productive use of time leading to a fix - like the just found issue for a STALL under Windows.
 
p.s. I'll add KD5 to my ignore list. I am no longer willing to read unnecessary provocations.

@Mcu32 (aka FrankB):

Thank-you, I am happy to be on the receiving end of your ignore list. Now, if only you would be no longer willing to *write* unnecessary provocations, that would truly be an accomplishment.

You should also work on being more careful about using the correct userID when you post . . . merely deleting (or whatever you do to) your quick-to-reply posts as FrankB does not remove the e-mail notifications that easily reveal your true identity.

Mark J Culross
KD5RXT

P.S. I will happily "Forget it"
 
As for that : Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Hard to say. Just saw it and posted for Paul's review in case it adds something.
I have the impression that the memory requirement has increased somewhat with the last IDE versions. I have had this message several times now. Since the change of the setting however no more, but that does not have to mean anything. I just leave it like this and see if the message comes again.
 
Ok, running the "1MB" test in a loop now. I inserted a 3 secs delay after each 1MB packet. Also, this gives a terminal the time to print it's buffer.
TY still shows a slow speed - but I havn't seen any garbage so far. So those "bursts" with a pause in between seems to be a Windows-workaround for such speedtests and makes them run more reliable. Even the original monitor seems to run pretty stable. However, it starts fast with 25MBIT and after a few packets it slows down to 1MBit.
 
Last edited:
Status
Not open for further replies.
Back
Top