Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!apple!netcom!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO RTSFLOW (was re: Help Telebit and SCO RTS/CTS Setup)
Summary: Half dux RTS/CTS *does* control mdoem--->computer flow.
Keywords: RTS/CTS Hardware Flow Telebit RS-232 Unix 386 SCO
Message-ID: <1991Apr7.024322.4465@netcom.COM>
Date: 7 Apr 91 02:43:22 GMT
References: <TMPP9FB@geminix.in-berlin.de> <1991Apr5.230009.16835@netcom.COM> <LVQPHKW@geminix.in-berlin.de>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 43

In article <LVQPHKW@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes:
>gandrews@netcom.COM (Greg Andrews) writes:
>
>>Then why does RTS stay high all the time at slower speeds?  If it behaved
>>consistently, then the modem could simply be configured to use half duplex
>>flow control (S58=1 S68=255) and be done with it.
>
>Yes, but half duplex flow control, per definition, is only for one
>direction (computer -> modem). This won't help you with receiving
>data.
>

I'm afraid that's not the case.  Half duplex data flow is defined as
data flow in one direction at a time.  Half duplex RTS/CTS signals when
the computer is ready to receive, and when it is ready to transmit.
By definition, when the computer is ready to transmit, it is not ready
to receive.  When RTS is asserted, the computer is signalling a 'ready
to transmit' state, which means 'NOT ready to receive'.  It does control
the modem ---> computer data flow.  Data is sent to the computer only
when RTS is off.

>
>>Unfortunately, in my version of SCO Unix (3.2.0 according to the kernel),
>>RTS stays on all the time when getty is using the B9600 or slower entries
>>in /etc/gettydefs.  That violates the rules for half duplex RTS/CTS.  RTS 
>>should be low while the computer is not transmitting.
>
>One detail I remember now is that the RTS/CTSFLOW flags have a meaning
>only if CLOCAL is cleared. That is, as far as I know, you can't use
>these flags on a dialout line (tty1a, tty1b etc.) because it has CLOCAL
>always set. And therefore RTS is always high. But I may be wrong here.
>And maybe there are other strange interactions between flags in the sio
>driver. I don't know.
>

That may be true for dialout, but the inconsistent behavior of RTSFLOW
I reported was observed on dial-in, where CLOCAL is not set.

-- 
.------------------------------------------------------------------------.
|  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
|                 |   Internet: gandrews@netcom.COM                      |
`------------------------------------------------------------------------'