On 26/9/22 15:52, John R. Hogerhuis wrote:
Enabled by default. Huh. Weird considering both ends are going to be sending their own xon xoff.
Not necessarily. How the Linux OS will respond to a program that has a port open to xon/xoff will depend on the type of port e.g. if it's a pty, it'll have that interface that responds to stty, and buffer locally. I don't think the flow control characters get passed through - it's gobbled up by either that terminal control layer (whose name temporarily escapes me, pre coffee) or, as it turns out, the ftdi chip. The process will be put to sleep if it fills its local buffer, unless the serial port was opened in blocking mode.
Maybe it's a lookahead to interrupt transmission at the hardware level if an xoff is received.
Interrupt as in paused - the transmitter just stops sending until it receives the start character. The chip would be implementing the same mechanism as it does for hardware flow control. Which is neat. I just wish it was better documented (still hunting for the exact documentation that enables/disables this, without resorting to their API). There must be some mechanism the USB uses stops sending as well, due to the potentially tiny buffers (which reminds me that I'm still waiting on my USB sniffer - another victim of the silicon shortage). Cheers, --dt
