Faster Serial Monitor code for T4

[Defragster]

The Teensy 4 Serial USB at 480 Mbps is capable of 300K+ lines per second now versus about 27K from a T_3.6 to Windows. Paul is going to come up with more speed at some point - but he got the SerMon in IDE up to steady 250K. And TyCommander Sermon is about 150K and swings more as it does the logging and buffer swap.

Not that it directly relates - but he posted on the Blog the way he does the buffering - giving some size info and what he went through in the IDE to get to that.

Where his lines were about 32 chars - that is 8 MB/sec - so at those speeds even logging direct to disk may bottleneck at times.

[Koromix]

This is something I want to work in January. The plan is to finally do #5 (VT-100) and this at the same time, because we have to do a custom VT-100 widget anyway. We'll ditch the slow Qt text editor we are using now.

In the meantime, I will release 0.9 (after finishing up #43). And then for 1.0 will focus on VT-100 and a faster serial monitor.
Hopefully, RTC programming will come either in 0.9 or 1.0. That depends on how hard the reverse-engineering is.

[luni64]

The plan is to finally do #5 (VT-100)

Yay...
Looking forward to this one. That will be a game changer for simple apps or quick testing...

[Defragster]

Will VT-100 be a separate Window? Would be nice to have scrolling SPEW area and also the positional terminal output area - maybe VT100 accounts for that.

Quick update in this post : https://forum.pjrc.com/threads/57325-Teensy-4-0-Serial-available()-stops-incrementing?p=222951&viewfull=1#post222951

TyCommander is kicking tSerMon Butt now with speed recent changes and more robust T4 Receive! I had to put in delays as noted in that post - but TyComm at 600K lines per second ( where a T_3.6 can only hit 27K lps ) and it has been running 30 minutes at output rates that kill tSerMon in about 30 seconds! Within 10 seconds tSermon cannot get a single SEND character out to Teensy - TyComm was running about 1 second delay as buffer filled - then 5 seconds after maybe 15 minutes and now it is maybe 9 seconds before the Send hits T4 and it updates display - then that new data appears on screen - so as fast as the screen is scrolling it is having more data buffered in the background - so 9 seconds later it hits the screen - where it starts instantaneous - like on a T_3.6 - but degrades, which is what I suppose makes the app crash when it is so far behind it runs out of buffer space. It is now 15 seconds - so as it loses ground it loses more ground managing larger buffers - or backlog of buffers from USB.

So when you get to it - that posted sketch may be a good test to prove against - with adjustable delays as noted in the post.

EDIT : ODD UPDATE : having the T_3.6 running at the same time at 27K lps - makes the T4 rate go from 200 K to 400 K and before restarting it was showing 600K. Not sure if the added trigger from second Teensy moves it faster - or if it is dumping buffers?

[Defragster]

< Oh - not going to call this a bug - maybe a feature > When SERIAL is disabled in TyComm on a Teensy. Hitting SEND does a Connect and Send, the send is not disabled - but that may be handy

[miracuruzrh]

Hi. I would like to ask also for higher baud rates. I have also a teensy (4.1)
I have set baudrates this way -> Serial.begin(500000); and would like to use it with TyCommander.
Wondering if TyCommander is still actively maintained, as this topic is a bit older?

[Defragster]

@miracuruzrh When a Teensy is on USB it does not matter what the baud rate setting Parameter is. It always connects at device fastest speed depending on whether it is 12 Mbps or 480 Mbps with the T_4.x family.

In Teensy code that speed parameter is not even used, in fact the Serial.begin() is not even needed. When USB Type in build includes USB - it will automatically connect to a host