SCO RTSFLOW (was re: Help Telebit and SCO RTS/CTS Setup)

[Uwe Doering]

gandrews at netcom.COM (Greg Andrews) writes:

>In article <LVQPHKW at geminix.in-berlin.de> gemini at geminix.in-berlin.de (Uwe Doering) writes:
>>gandrews at 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.

I don't agree. The term `half duplex' applies to the link between the
two DCEs, that is, the modems. The link between the modem and the
computer is, of course, full duplex, as there are individual data lines
in the cable for receiving and transmitting. RTS signals the modem
that the computer _likes_ to send some data. The _modem_ then decides
when the actual direction switch on the DCE <-> DCE link will occure.
If the switch is completed the modem signals the computer via CTS
that it may send data.

But this in no way implies that the modem has to stop the data
transfer to the computer immediately when the computer raises RTS.
It is the modem's decision when the transmission direction is
switched. The computer can only request the modem to switch
direction, but it can't force it to do so. Therefore, RTS has
no direct (and immediate) influence on the receiver data flow,
and can't be used to throttle it immediately in order to prevent
a receiver buffer overflow.

>>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.

Well, as I said, I don't know what other "features" SCO has built into
their sio driver. But even if we discuss this issue for three more
weeks, you still won't be able to convince sio to do full duplex
RTS/CTS flow control, as it isn't designed to do that. That's a fact.

     Uwe
-- 
Uwe Doering  |  INET : gemini at geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini