paul@frcs.UUCP (Paul Nash) (04/11/91)
I think that I have a problem. I need to talk from a TTY port on a 386 Unix box (Intel V.3.2) to a device that does hardware flow control. The output port (currently) uses the FAS drivers, but this software needs to be portable to machines that don't have such luxuries. When I openthe port, I use a TCSETA ioctl() to play with baud rates, etc. However, as far as I can tell, whether or not I set CLOCAL (which is the only relevant looking flag that I can find), dropping CTS doesn't halt the port. What am I doing wrong? Is there a hidden flag, or a hidden field in the termio struct, or a hidden ioctl call? Is there something else entirely that I should use for this? Is my break-out box broken? I have read the entire FM from cover to cover, in _both_ directions, about 10 times, and still can't find the answer. paul ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
chris@iosys.UUCP (Chris Martinus) (04/11/91)
In article <451@frcs.UUCP>, paul@frcs.UUCP (Paul Nash) writes: > I think that I have a problem. I need to talk from a TTY port on > a 386 Unix box (Intel V.3.2) to a device that does hardware flow > control. The output port (currently) uses the FAS drivers, but > this software needs to be portable to machines that don't have > such luxuries. > > When I openthe port, I use a TCSETA ioctl() to play with baud rates, > etc. However, as far as I can tell, whether or not I set CLOCAL > (which is the only relevant looking flag that I can find), dropping > CTS doesn't halt the port. What am I doing wrong? Is there a > hidden flag, or a hidden field in the termio struct, or a hidden > ioctl call? Is there something else entirely that I should use for > this? Is my break-out box broken? Uuuh... I dunno about V.3.2 of FAS drivers, but on V.4 if you want hardware flow control, use /dev/ttyhXX instead of /dev/ttyXX. Does this help at all? -- Chris Martinus chris@iosys
gemini@geminix.in-berlin.de (Uwe Doering) (04/14/91)
paul@frcs.UUCP (Paul Nash) writes: >I think that I have a problem. I need to talk from a TTY port on >a 386 Unix box (Intel V.3.2) to a device that does hardware flow >control. The output port (currently) uses the FAS drivers, but >this software needs to be portable to machines that don't have >such luxuries. There is no portable way to do hardware handshake under UNIX. The termio(7) man page author didn't think of it (this is the only explanation I have for that omission). And therefore, every vendor chose his own way of doing hardware flow control. Many implementations do hardware flow control transparently (as does FAS), so that a program doesn't know (and doesn't _have_ to know) that it actually uses a port with hardware handshake. On the other hand, SCO decided to do it non- transparently, that is, the program has to know about certain termio(7) flags and has to set them to enable hardware flow control. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
ed@mtxinu.COM (Ed Gould) (04/15/91)
>There is no portable way to do hardware handshake under UNIX. The >termio(7) man page author didn't think of it (this is the only >explanation I have for that omission). There is exactly one reason that the termio(7) page doesn't describe portable hardware flow control. That reason is that it doesn't exist. The man pages document *existing* systems. They are not specifications for something that doesn't exist. There is also a reason why the termio software doesn't specify or support hardware flow control. When that software was being developed, there was a wide variety of types of serial ports available. Some had provisions, for RTS/CTS flow control, but they were by far the exception, not the rule. Many ports had no modem-control support at all, some had only carrier detect, and some had full support for the signals. However, what "full support for the signals" meant was that the *software* could look at them. This is all consistent with the long-since-adopted EIA RS232C standard (note - industry standard, not one person's idea of how it should work). RS232C (while it may be outdated) does not have the notion of flow control, per se. It knows about line turnaround for half-duplex systems. That is what RTS (request to send, sent from the DTE - in this case the computer - to the modem) and CTS (clear to send, from the DCE - modem - to the computer) were designed for. Hardware flow control came along and coopted those signals for other purposes. There still exist half-duplex systems in the world. Would you suggest that hardware manufacturers abandon the standard that supports them in favor of an ad-hoc solution that works in some situations? That's not what I think standards are for. -- Ed Gould No longer formally affiliated with, ed@mtxinu.COM and certainly not speaking for, mt Xinu. "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
greg@cheers.Bungi.COM (Greg Onufer) (04/15/91)
gemini@geminix.in-berlin.de (Uwe Doering) writes: >There is no portable way to do hardware handshake under UNIX. The Extended General Terminal Interface (termiox) in S5R4 addresses this and several other issues. It's not portable, but it could be useful for guidance. Cheers!greg
rbj@uunet.UU.NET (Root Boy Jim) (04/16/91)
In article <1991Apr14.202750.22010@mtxinu.COM> ed@mtxinu.COM (Ed Gould) writes:
?[someone wrote:]
?>There is no portable way to do hardware handshake under UNIX. The
?>termio(7) man page author didn't think of it (this is the only
?>explanation I have for that omission).
Actually, it was tty(4). Termio came later.
?There is exactly one reason that the termio(7) page doesn't describe
?portable hardware flow control. That reason is that it doesn't
?exist. The man pages document *existing* systems. They are not
?specifications for something that doesn't exist.
Well, yes it does. In fact, many UARTS won't even transmit if
CTS isn't high.
?There is also a reason why the termio software doesn't specify or
?support hardware flow control. When that software was being
?developed, there was a wide variety of types of serial ports
?available. Some had provisions, for RTS/CTS flow control, but they
?were by far the exception, not the rule. Many ports had no
?modem-control support at all, some had only carrier detect, and
?some had full support for the signals. However, what "full support
?for the signals" meant was that the *software* could look at them.
They were cheap copys of the real thing. Sure, you can get by
with only three wires, but real hardware flow control would
have allowed us to use ^Q & ^S as emacs commands.
?This is all consistent with the long-since-adopted EIA RS232C
?standard (note - industry standard, not one person's idea of how
?it should work). RS232C (while it may be outdated) does not have
?the notion of flow control, per se. It knows about line turnaround
?for half-duplex systems. That is what RTS (request to send, sent
?from the DTE - in this case the computer - to the modem) and CTS
?(clear to send, from the DCE - modem - to the computer) were designed
?for. Hardware flow control came along and coopted those signals
?for other purposes.
For an extension of the same thing. CTS is, as you have mentioned,
"Clear To Send". What does "clear" mean? It could mean yes, you
have the link. But it could also mean, "there is buffer space"
available. It doesn't matter *why* CTS is high or low, just obey it.
?There still exist half-duplex systems in the world. Would you
?suggest that hardware manufacturers abandon the standard that
?supports them in favor of an ad-hoc solution that works in some
?situations?
Yes I would. UNIX doesn't *do* half-duplex. But all that equipment
should be destroyed (or at least don't bother me with it's details).
And BTW, I want the tilde bit and the all caps back in my terminal
info word; such things are just not important any longer.
?That's not what I think standards are for.
The key letter in that sentence is the one after the second `d'.
RS232 has been mutated in so many ways that anything is possible.
--
[rbj@uunet 1] stty sane
unknown mode: saneclewis@ferret.ocunix.on.ca (Chris Lewis) (04/19/91)
In article <1991Apr14.202750.22010@mtxinu.COM> ed@mtxinu.COM (Ed Gould) writes: >>There is no portable way to do hardware handshake under UNIX. The >>termio(7) man page author didn't think of it (this is the only >>explanation I have for that omission). >There is exactly one reason that the termio(7) page doesn't describe >portable hardware flow control. That reason is that it doesn't >exist. The man pages document *existing* systems. They are not >specifications for something that doesn't exist. >There is also a reason why the termio software doesn't specify or >support hardware flow control. When that software was being >developed, there was a wide variety of types of serial ports >available. Some had provisions, for RTS/CTS flow control, but they >were by far the exception, not the rule. Many ports had no >modem-control support at all, some had only carrier detect, and >some had full support for the signals. However, what "full support >for the signals" meant was that the *software* could look at them. There were a number of serial I/O systems back in "those" days that could support rudimentary hardware flow control enabling/disabling. I believe, for example, that several of the VAX serial port controllers had the capability - and were as programmable as some of the newest intelligent port cards. On the other hand, when I installed V6 on a PDP 11/23 (a 11/23 was pretty darn modern compared to V6), I had to use a wire-wrap gun to change the baud rate - stty() couldn't do it. (a "dj" if I recall correctly) I think the real reason was that nobody thought hardware flow control was all that important. After all, they didn't have 9600 baud modems then. In retrospect, something should have been specified even if it wouldn't work in many systems. After all, V7 had "phys()" (map physical memory), and TANDEM - neither of which worked on a significant portion of the machines it ran on. If something had been specified, we'd have a lot easier time now without having all of these mutually exclusive mechanisms that are done by vendor-specific kludges. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!