Hardware flow control in SunOS 4.1

[James Warner Adams]

>From: casey at gauss.llnl.gov (Casey Leedom)
>
>If full receiver buffers can't trigger lowering RTS, the problem sounds
>like it's with the Sun hardware, not the signalling mechanism.
>
>But problems like this aren't unique to Sun.  Unix tty drivers have never
>been very good.  One of the reasons we finally gave up entirely on hooking
>our high speed modem pool to a Unix machine and bought a good terminal
>server instead.

This has come up a number of times on the net.  The "problem" is not any
individual's fault, just that different people were designing to different
standards.

The UNIX tty drivers are based on the canonical RS-232 interface spec
which specifies RTS/CTS be used to reverse the direction of a half-duplex
modem link.  The proper behavior here is that RTS only be asserted in
response to a request to send data to the DCE (modem).  The transmission
is then blocked until the DCE asserts CTS, indicating that the line is in
the transmit direction.  There is no provision for flow control in the
receive direction.

Since few current modems use half-duplex line protocols which are
signalled to the DTE in this fashion, modem manufacturers decided to use
these lines to implement the bidirectional flow control you discussed.
CCITT is presently revising the standard to replace the old half-duplex
application with this protocol, but until this is accomplished and device
drivers are written to the new standard, the only solution is to use a
replacement driver, a communications front-end processor, or simply set
the speed low enough that the CPU/serial port can handle it.

       Jim Adams              Department of Physiology and Biophysics
adams at ucunix.san.uc.edu     University of Cincinnati College of Medicine      
Anatidaephobia:  The fear that somewhere, somehow, a duck is watching you.