Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!decwrl!vixie From: vixie@decwrl.dec.com (Paul A Vixie) Newsgroups: comp.unix.ultrix Subject: Re: RTS/CTS handshaking on a tty Message-ID: Date: 28 May 90 01:05:34 GMT References: : <50054@ames.arc.nasa.gov> Sender: vixie@decwrl.dec.com Organization: DEC Western Research Lab Lines: 32 In-reply-to: schoch@trident.arc.nasa.gov's message of 23 May 90 23:48:28 GMT [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 Palo Alto, California ...!decwrl!vixie