NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/sysv386/12351

Internet Message Format | 1992-07-23 | 8.1 KB

Xref: sparky comp.unix.sysv386:12351 biz.sco.general:2669
Newsgroups: comp.unix.sysv386,biz.sco.general
Path: sparky!uunet!scorn!dionj
From: [e-mail] (Dion)
Subject: Re: SCO Unix Release 3.2 Version 4.0, RTSFLOW, CTSFLOW and CRTSFL
Reply-To: [e-mail]   (Dion)
Cc: [e-mail] [e-mail] [e-mail]
Organization: The Santa Cruz Operation, Inc.
Date: Mon, 20 Jul 1992 02:03:12 GMT
Message-ID: <[e-mail]>
Keywords: RTSFLOW CTSFLOW CRTSFL flow control
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (News admin)
Lines: 161


In response to a inquiries (see below) here are some comments on flow control.

Currently, the "stty -clocal rtsflow ctsflow -ixon -ixoff" stty(C)
settings on SCO Systems provide hardware flow control on modem
control ports according to the original, unidirectional convention:

Computer                                                Peripheral
 (DTE)   pin 4   ==== RTS - ready to send ===>>>  pin 4   (DCE)
         pin 5  <<<== CTS - ready to receive ==   pin 5

The RTS (Request To Send) line is asserted by the computer (DTE)
when it is ready to send data to the peripheral (DCE).  After the
data is sent, RTS is dropped until there is more data to send in
the sio driver's buffer.

The peripheral (DCE) then asserts the CTS (Clear To Send) line
when it is ready to receive data.  If the peripheral (DCE)
becomes busy, it drops CTS and the computer (DTE) stops sending
data until the peripheral (DCE) raises CTS again.

This scheme allows the peripheral to control the flow of data
from the computer, but not vice versa.  There is an implicit
(and outdated) assumption that the computer is faster than
the peripheral.


De facto Industry Standard RTS/CTS Flow Control
-----------------------------------------------
Many third-party vendors (including Arnet, Telebit, U.S. Robotics,
Computer Peripherals, Hayes, Digiboard, Computone, Specialix, and
Stallion among others) implement a newer, de facto standard for the
"stty rtsflow ctsflow" settings:

Computer                                                 Peripheral
 (DTE)   pin 4   ==== RTS - ready to receive ==>>> pin 4   (DCE)
         pin 5  <<<== CTS - ready to receive ====  pin 5

The computer (DTE) asserts RTS (Request To Send) when it is ready
to receive data from the peripheral (DCE).  The meaning of "Request
To Send" has changed, becoming a request for the peripheral to send
to the computer.  If the computer becomes busy, it drops RTS and the
peripheral stops sending data until the computer raises RTS again.

The CTS (Clear To Send) line is used as before.

The obvious advantage of this implementation is that it allows the
computer to control the flow of data from the peripheral.  There is
a possible disadvantage.  Some older peripherals may require that RTS
be raised in order to put them in a "ready to receive" state.

In SCO UNIX Release 3.2 Version 4.0 the "stty -clocal -rtsflow -ctsflow
crtsfl -ixon -ixoff" stty settings provides this newer, bidirectional
hardware flow control on modem control ports (uppercase devices such as
tty1A).


Possible Changes to SCO's RTS/CTS Flow Control
----------------------------------------------
SCO customers have suggested five changes to the current SCO
implementation of RTS/CTS hardware flow control.   These changes
will be considered for future releases of SCO operating systems.  The
comments of the technical community are welcomed on this topic.

(1) Make "stty rtsflow ctsflow" implement the newer, bidirectional flow
    control standard described above.  This would allow modem dialers and
    other programs to have binary compatibility with popular third-party
    serial drivers.  Currently, changing from a standard serial port to a
    port on an intelligent multiport card requires a change to the binary.

(2) Implement "stty rtsflow ctsflow" on non-modem control ports.  This
    would allow the convenient use of printers and other non-modem devices.
    Jumpering CD (Carrier Detect) high on the computer side can present a
    problem with certain styles of hardware.

(3) Allow the use of the clocal, ixon, and ixoff settings in conjunction with
    the rtsflow and ctsflow settings.  Other vendors don't require -clocal;
    and it's sometimes desirable to use hardware and software flow control
    together.

(4) Make sure the implementation is correct when the baud rate field
    (c_cflag & CBAUD) is equal to B0.  It should *not* change the
    divisor programmed into the SIO chip, but it *should* drop both RTS
    and DTR signals to that port.  The user thus has brute-force control
    of this pair of signals by switching baud rates between B0 and the
    desired baud rate.  This technique is used by some modem-control
    software in order to hang up modems without having to close the serial
    port (and thus being forced to reprogram all of the other termio states,
    etc.).

(5) Implement the RTS_TOG ioctl(S) call (found in <sys/termio.h>).  This
    ioctl allows programmers to take direct control of the RTS line if
    necessary.  If the integer argument to this ioctl is 0, RTS is
    lowered on the port; if it is 1, RTS is raised.  This ioctl is
    present in AT&T SVR3 and SVR4, and is supported by third-party
    serial drivers under SCO UNIX Release 3.2.


Additional useful information, thanks to
"Managing UUCP and Usenet" (O'Reilly & Associates, 1990, p.19)
-----------------------------------------------------------------------
"In the RS-232 standard, flow control is defined only for half-duplex
 connections-that is, for connections in which data can be transmitted
 only in one direction at a time.  However, the standard has been
 adapted, de facto, for full-duplex communications as well.

 In the half-duplex standard, the DTE asserts RTS when it wants to send
 data.  The DCE replies with CTS when it is ready, and the DTE begins
 sending data.  Unless RTS and CTS are both asserted, only the DCE can
 send data.

 However, in the full-duplex variations, RTS/CTS is used as a kind of
 "throttle."  The signals have the opposite meaning than they do for
 half-duplex communications.

 Whenever a DTE device is able to accept data, it asserts pin 4. Request
 to Send.  If the DCE is ready to accept data, it asserts pin 5, Clear to
 Send.  If the voltage on the RTS or CTS drops at any time, this tells the
 sending system that the receiver is not ready for more data: "Whoa!
 Hold on till I get my buffers cleared."  Since this flow control
 handshake is implemented in the serial port hardware, it is considerably
 more efficient and reliable than the CTRL-S/CTRL-Q  handshake that can be
 performed in software."
-----end of quote.

This reply was masterminded by Bela and Don in SCO's Support department.
We'd also like to thank Robert Lipe from Arnet who provided valuable
input for this write-up.  Also we thank the O'Reilly folks for the quote
from the Nutshell Handbook "Managing UUCP and Usenet" which explains the
two flavors of RTS/CTS flow control; half-duplex and full-duplex.
(contact: [e-mail] or ph. 800-338-6887)

Please direct any suggestions or comments to [e-mail], [e-mail],
and [e-mail].

Dion L. Johnson
SCO Engineering Technical Liaison       400 Encinal St.   Santa Cruz, CA 95061
Bangpath:                           ...{ucbvax!ucscc, decwrl, uunet}!sco!dionj
Domain:  [e-mail]    FAX: [phone]                  Tel: [phone]

re:
In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
>According to [e-mail] (Jochen Fahrner):
>>Now, in release 3.2v4, the sio driver also has bidirectional hardware
>>flow control. The new termio flag to switch this on is CRTSFL. They
>>also changed the behaviour of RTSFLOW/CTSFLOW.
>
>Thanks for the pointer; but I just read the termio(M) man page and I
>can't make head nor tail of it the flow control explanation.
>
>Does anyone out there understand:
>
>   1.  What RTSFLOW and CTSFLOW do, singly and in combination,
>         under (A) 3.2v2 and (B) 3.2v4?
>   2.  What CRTSFL does, compared to 1(A) and 1(B)?
>
>Please post some explanation.  I'm very confused.
>--
>Chip Salzenberg at Teltronics/TCT  <[e-mail]>, <[e-mail]>