defragster
Senior Member+
When enabled does the hardware assert the RTS on full FIFO? - or is that an interrupt response? At the conservative speed of 4Mbaud it takes 2us to get 8 bits. Even if it is hardware driven how much time (ns's I suppose) until the sender can see the change on CTS and stop on the 'next' byte? Pushing the RWFIFO interrupt from 4 to 5-6 bytes could be enough to allow the sketch to pull more from the buffer - and fewer interrupts would smooth the overall system flow - at 2us per byte the FIFO would fire every 8us? Of course at sane baud rates it would be 10 or 20 times that.
I'm working to get a demo - but I have no hardware monitoring - just USB spew - so the more I try to 'see', the more random the result. Note to self: We know 4M and 6Mbps work no problem with good wires and an attentive receiver. For RTS/CTS - Since baud 'speed' is all relative - a slow-mo wreck is still a wreck - it'd probably be better at 200Kbps with controlled delays/waits and USB seeming FAST for spew rather than another random avenue for causing the trouble. Even at 200Kbps 2K messages will go 12 per second with a stodgy pace of 40us per character so it takes delayMicroseconds(2520) before a 64byte buffer fills instead of 126us - set up an elapsedMicros and relax and watch it tick and save the racy edge conditions for after the fundamentals are seen to be working. Make the transmitter buffer bigger than the receiver buffer so sending won't block - but a 'lazy' [~delayMicroseconds(40) per byte] receiver will get overrun, especially since I decided to test out and in on two Teensy serial ports with two Teensy's.
I'm working to get a demo - but I have no hardware monitoring - just USB spew - so the more I try to 'see', the more random the result. Note to self: We know 4M and 6Mbps work no problem with good wires and an attentive receiver. For RTS/CTS - Since baud 'speed' is all relative - a slow-mo wreck is still a wreck - it'd probably be better at 200Kbps with controlled delays/waits and USB seeming FAST for spew rather than another random avenue for causing the trouble. Even at 200Kbps 2K messages will go 12 per second with a stodgy pace of 40us per character so it takes delayMicroseconds(2520) before a 64byte buffer fills instead of 126us - set up an elapsedMicros and relax and watch it tick and save the racy edge conditions for after the fundamentals are seen to be working. Make the transmitter buffer bigger than the receiver buffer so sending won't block - but a 'lazy' [~delayMicroseconds(40) per byte] receiver will get overrun, especially since I decided to test out and in on two Teensy serial ports with two Teensy's.