stefan@wheaton.UUCP (Stefan Brandle ) (05/26/90)
In article <50054@ames.arc.nasa.gov> schoch@trident.arc.nasa.gov (Steve Schoch) writes: >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). I'm not quite whether the CTS stuff works properly for flow control (we use XON/XOFF for flow control and CTS/RTS for determining modem/VAX status) but system calls do exist to help manipulate this stuff. >Does Ultrix support such an operation mode for these boards? If so, >what is the ioctl I can use to turn it on. See below. Example below chopped from a program we concocted locally when we are toggling our modem when switching a modem line from outbound to inbound. We run this program as part of a shell script that changes the line status in /etc/ttys to `on', does a `kill -HUP 1' and enables dtr on that line. (We're not using modem control while calling out -- uucico catches on fast enough when our connection dies!) This should give you an idea of where to look. We are currently using this on a machine that's still under Ultrix 2.0, but the 3.0 manual entry looks the same so should work. ================================================================================ #include <sys/file.h> #include <sgtty.h> /* this only permantly sets modem controls if executed as root - see (4) tty */ ... file = open(argv[1],O_RDWR+O_NDELAY); ... if (ioctl(file,TIOCMODEM,1) != 0) printf("problems in setting modem\n"); printf("clearing dtr\n"); if (ioctl(file,TIOCCDTR) != 0) printf ("problems in clearing dtr\n"); printf("sleeping \n"); sleep(3); /* giving the modem time to finish reseting --AT&D3 */ printf("setting dtr\n"); if (ioctl(file,TIOCSDTR) != 0) printf("problems in setting dtr\n"); ... Hope this helps, -stefan -- ---------------------------------------------- MA Bell: (708) 260-4110 --------- Stefan Brandle UUCP: ...!{obdient,uunet!tellab5}!wheaton!stefan Wheaton College or stefan@wheaton.UUCP Wheaton, IL 60187 "But I never claimed to be sane!"
vixie@decwrl.dec.com (Paul A Vixie) (05/28/90)
[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@wrl.dec.com> Palo Alto, California ...!decwrl!vixie