🚀 go-pugleaf

In article <453@ll-xn.ARPA>, singer@ll-xn.ARPA (Matthew R. Singer) writes:
> 
> Does any know of any bugs in the TOS rs232 handler regarding the
> usage of CTS/RTS flow control?  ... when CTS/RTS is enable via the
> RSCONF call, the system appears to hang as soon as io to the AUX
> device begins.

This problem also appears with the Avatex modem and most printers you
might try to drive over the RS-232C port.  It is due to an ST hardware
limitation.  The chips that handle the RS-232C interfaces treat these
signals as EDGE-TRIGGERED.  The Avatex (and obviously the US Robotics)
modem asserts CTS as a CONTINUOUS signal until its buffering fills up
(because the ST is sending characters faster than the modem can ship
them over the phone line).  It does not flicker or toggle CTS for every
character.  This is a legitimate RS-232C behavior, I believe.

The reason for the lock-up behavior is that the ST hardware will only
generate an interrupt for the software to handle for the FIRST
character in outgoing buffer-full.  The modem will continue to wait for
the next character, with CTS asserted, and the ST will continue to wait
for an interrupt to ship out the next character, because its interface
hardware is waiting for a TRANSITION on the CTS signal, not a logic
level.

I think this might be fixable even without a hardware change, but would
require more messing around with the device registers and interrupt
handlers than I care to deal with.  I avoid the problem by running at
1200 baud, which never overruns the capabilities of my modem's
buffering or line quality, and simply don't use RTS/CTS flow control.

Stu Friedberg  {seismo, allegra}!rochester!stuart  stuart@cs.rochester.edu