[comp.unix.internals] Hardware flow control for TTY ports under V.3

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: sane

clewis@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!