On Fri, Sep 23, 2022 at 2:59 AM Brian White <b.kenyo...@gmail.com> wrote:
> > I believe all the right chip does is help, and make more code more likely > to make it through > Chip/driver wise the two things I've observed: You can configure the FTDI driver buffering threshold on Windows all the way down to 1 byte, which I think is what we want. This is really about decreasing transmit latency on the Windows side in case of a sensitive receiver on the Model T side... that is, TS-DOS. The prolific drive has bugs under the Windows API, last I checked. There is a facility under Win32 and the .Net Framework for reading a block of data with a timeout. It works with the FTDI, it doesn't work with Prolific. I believe it is a driver issue. I can work around it in software, and have, but just generally spec it out of commercial projects because it is not correct. On Linux, I've never really noticed a difference between Prolific and FTDI. But my experience is the same as yours, that software flow control does not work with our laptop. Linux is too slow to react to a flow-off presumably since it is in-band in the data and gets buffered, and overwhelms the tiny 64-byte, interrupt driven receive buffer on the Model T. And as Mike mentions, USB, Wifi-Serial add create even more overhead and burstiness. I could imagine some low level hardware scheme (specific hardware+driver+configuration) overcoming the buffering of XON/XOFF specifically, in the wired case... but this is the first I've heard of it. And it really seems like it would have to be configured. Hardware isn't normally involved in software flow control. -- John.
