Re: Developing PLATOTerm64, Flow Control woes.

On 04/07/2018 21:01, Mike Stein wrote:
> But there's no reason why it can't send the XON/XOFF back to the sending system to tell it to pause after the next packet *as well as* using it for local handshaking with small enough frames to prevent overflow of the receiving RS232 device.

The other end may be using RTS/CTS, or not even be connected via RS232 
and so it would be extra work to cope with the XON/XOFF.

With the extra effort you don't gain any benefit at all.

If the other end is using XON/XOFF between it and it's bridge, then your 
XON/XOFF being sent throug are either benign or dangerous.

> The vendors of these devices promise that XON/XOFF works,

Right, if you configure it to use XON/XOFF locally and that filters it out.

As for whether they lie, at least some of them did. I used a lot of them 
in the 90's. One of them couldn't cope with sending two 0xff characters 
after each other, only one turned up. We had to change the protocol so 
that this couldn't happen.

> ..." if I've already queued 16 bytes to send to you and the transmit fifo is dumb then I can't send an xoff until you've received the other 16 bytes. "
Unless your UART supports XON/XOFF itself, or has some way of inserting 
characters at the head of the FIFO then it's always going to go at the 
end of the queue. It's just more latency because XON/XOFF is in band.
> Anyway, is any of this relevant to the OP's flow control issues?

Difficult to say for sure, because he was light on the details on his 
hardware so I've had to make some assumptions. Then made assumptions 
about what kind of problems I've seen when people use XON/XOFF 
incorrectly which could explain it.