@Paul
Pulled Github\CORES for new USB code. Got fresh copy of
github.com/PaulStoffregen/USB-Serial-Print-Speed-Test
Not sure if this helps - other than yes - it can RUN faster USB to PC it looks to have at least DOUBLED prior test here - if the T4 @600 MHz is all consumed with printing - it can overwhelm the PC, but T4_USB can also get STALLED in the process until the PC's USB stack is tickled 'Deja-Vu'.
Also shows that a delayMicroseconds( 2 ) per loop is enough to have T4_USB to PC persist at a rate on the PC that is a bit faster that before these github code changes.
Windows 10 - Opened IDE 1.8.9 T_SerMon and I numbers like this and then is halts any updates - even with AutoScroll on.
This run I pushed Program on a second T4 - thinking I was restarted the T4 under test:
Code:
count=47705587, lines/sec=438034
count=47705588, lines/sec=438034
count=47705589, lines/sec=438034
// ...
count=47882144, lines/sec=438034
count=47882145, lines/sec=438034
count=47882146, lines/sec=438034
count
After running to a freeze pushing Program on 2nd T4 again I can see number like this for a second or so:
Code:
count=20437490, lines/sec=506759
count=20437491, lines/sec=506759
c
So 'Deja-Vu' - if I do anything on USB - add remove Teensy - it picks up again. Even putting another T4 into Bootloader, or just pushing button again when in bootloader.
It is quitting close to the same point each time from a fresh start after upload:
Run #1:
Code:
count=10401760, lines/sec=0
c
Run #2
Code:
count=10397381, lines/sec=0
count=10397382,
I added a 'delayMicroseconds( 1 );' to the loop and it runs this far on a fresh start after Upload:
Code:
count=25685282, lines/sec=377090
count=25685283, l
Run#2:
Code:
count=11002308, lines/sec=378085
count=11002
Run #3
Code:
count=11932522, lines/sec=378034
count=11932523, l
Pushing to
delayMicroseconds( 2 ); in loop() seems to get toward a steady state with this lower lines/sec count that is just above what T4 was showing before when it was ~225K lps on last testing.
This are snippets from an uninterrupted test - so it only 'STALLS' above when there is a 'backup'? - Code is functional T4>PC in steady state
Code:
count=54556500, lines/sec=271626
count=54556501, lines/sec=271626
// …
count=125881099, lines/sec=270751
count=125881100, lines/sec=270751
// …
count=328396175, lines/sec=269904
count=328396176, lines/sec=269904
// …
count=405324087, lines/sec=269784
count=405324088, lines/sec=269784
// USER Stopped T4 while still running
Another run with delayMicroseconds( 2 ) gave this and stalled::
Code:
count=52981933, lines/sec=271604
and another:
Code:
count=21389847, lines/sec=273002
Misc Notes for ref on T4 loop() cycle rate and ...:
>> With delayMicroseconds( 2 ) in loop() the loop count is MAX 457,216 with only printing the count once per second. Yields Print count of 270K lps.
>> Removing delayMicroseconds( 2 ) from loop() the loop count is MAX 7,519,378 with only printing the count once per second. Short Term Yield of Print count of 440K to 500K lps.
>> Putting a void yield() {} in the sketch does not affect above cases of stalling
>> TaskMan shows JAVA overall using 13 to 21% of CPU, and T_SerMon is under 0.3 to 1.1%, and memory used after this time is 277MB.
>> TyCommander as SerMon is still slow limited 140K to 230K - so it seems to keep running, even with no delayMicroseconds() in loop(), somehow it properly slows the T4's USB stream without Stalls though.