Ian Dall <Ian.Dall@dsto.defence.gov.au> writes:
> I have made a lot of progress understanding the problem with flow
> control. First, I have added flow control to the ring buffer so that
> it never overruns if CRTSCTS is set. Instead, it backs up in the rx
> fifo and the duart automatically de-assert RTS. This seems to work.  I
> can arrange an input stream from another machine (my Sun3) and cat the
> relevant tty. When I suspend cat, the RTS light on my rs232 tester
> changes colour. Resume cat and the RTS light changes back. So far so
> good.

Good, that is a great start.

> If I cat /dev/tty01 > /dev/null, it chuggs away OK with the RTS light
> occasionally flashing. So, the auto RTS really is working and RTS
> really does stop the flow from the Sun (which is of course, the other
> side of the picture). The trouble is, I still get the occasional fifo
> overrun. I have come to the conclusion that this is because the Sun
> detects changes in CTS with a status change interrupt which it may not
> process quick enough. The scn2681 family doesn't deassert RTS until
> the fifo is full *and* it has received the start bit for the next
> character. That means the other end has one character time to detect
> the CTS before it sends the next character.

Not so good.  It would be better if it would assert when the fifo
fills, rather than waiting for a start bit to signal.  Even better
if it could accept a character or two after flow control was
asserted.  If someone has it set for both RTS/CTS *and* XON/XOFF
flow control, a deadlock can arise if you can't take an extra
character while things are stopped.  Actually, it will happen with
just XON/XOFF unless care is taken to allow a character to arrive
while flow control has things stopped, but that specific case should
be higher up than the interrupt routine.  Running both flow control
protocols at the same time may require some interrupt help though,
I'm not sure...  Also consider that other UARTS/hosts may empty
their small fifos before alerting the system that flow control is
in use.

When I was working for Dallas Semiconductor, we had a 2400bps modem
the size of a 30 pin memory SIMM, and a DAA (Phone/modem chip
interface) card that was the same size.  We purchased some code to
support MNP5/V.42bis for the poor thing, but their DTE interface
code left something to be desired.  As I remember, when we told it
to stop either by XON/XOFF or RTS/CTS, it would slow down a lot,
but still send a few characters for HUNDREDS of milliseconds!  Long
after it knew good and well that it shouldn't.  Needless to say,
a couple of us engineers were not impressed at all.  But management
thought we had wasted enough time porting the junk, and had spent
enough money that we were going to use it, NOT re-write it.

It was my understanding that several modem manufactures use that
code, as they had an 8051 port that we used, and a Z80, 68000, C,
etc.  port as well.  If my understanding and memory are correct,
I doubt you will ever solve the problem with such a broken device
on the other end, but it would be better if the device had 2 or 3
character times to detect the flow control.