RTS/CTS handshaking on a tty

[Paul A Vixie]

[Steve Schoch]
>> I have a micro-vax with a DZV (dz0) and a DHV (dhu0) running Ultrix
>> 3.1.  I would like to use a port on one of these boards with hardware
>> flow control (when CTS goes low to the VAX, the VAX should stop sending
>> data until CTS goes high again).

If you have "flags 0x00" in your config file for this interface, or at
least you have the appropriate bit of flags for the port in question set
to zero, then this behaviour is the default.  In dhustart(), there's a
comment to the effect of "also, do not transmit if no CTS".  The logic
so described is not conditional on any mode bits.  The DHU (or lookalike)
board will generate an interrupt whenever CTS changes state, and the driver
tracks it as well as calling dhustart() whenever it changes from off->on.

The only thing you can't do is have the DHU board control inbound flow
using RTS.  The hardware can't do it, and by the time the driver gets
control after a receive interrupt, it can empty the fifo in less than
one baud time so there's no point in controlling RTS from software.  This
is really too bad, since Telebits run marvelously with hardware handshake.

The only reason this logic is present in DEC's serial line device drivers
is to support half-duplex modems than use CTS to control ownership of the
shared wires.  It happens to work really, really well if you tell your
Telebit to use CTS/RTS handshake, it's just that the system will always
show RTS so only CTS is meaningful.

Paul Vixie
DEC WRL
--
Paul Vixie
DEC Western Research Lab	<vixie at wrl.dec.com>
Palo Alto, California		...!decwrl!vixie