I havent tried flow control, I don’t have those bytes available. My data stream is around 6800bps, each packet is 22 bytes - i shouldn’t need flow control to a computer through a FT232RL (which can handle much much higher than 115200). Production would only be about 200bps, over radios on 2400baud. I want to get the firmware all sorted before i start testing wireless first.
I’m not loosing any bytes, the “lost” packets are actually packets where the bytes are wrong, so they are discarded.
For me, flush time is very clearly determined. It doesn’t really matter how much data i dump - it delays the code by 3ms. This is unacceptably slow from a commercial firmware build IMO. 3ms delay is about 345bytes worth of time at 115200 - I can’t believe an ARM7 is this slow to flush a buffer.
Chris Seto and myself have been noticing issues with data quality coming out of the serial ports for awhile now, but this is the first time i’ve actually noticed it for sure, as i have a data packet that is identical except for 24 bits of information which includes a timestamp, and 8 bits for the packetid.
I’ve tried with multiple ft232RL’s, and i’ve tried with 10ms delays between sending data - i still get corrupt bytes though, and flush is slow.