🚀 go-pugleaf

In <10276@uhccux.uhcc.Hawaii.Edu> robin@uhunix1.uhcc.Hawaii.Edu (Robin Amano) writes:

>In article <1990Nov13.184339.4756@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>>In article <1990Nov10.013730.28838@julius.cs.uiuc.edu> totty@flute.cs.uiuc.edu (Brian Totty) writes:
>>>	I want to send flow control information back to a sender across
>>>	an RS232 serial cable.  What signal is appropriate for this?
>>
>>There is no, repeat no, standard convention for this.  You have to find
>>out exactly what your sender is willing to accept, if anything.  It is
>>common to use CTS and RTS for this.  DSR and DTR are also used.  None of
>>these lines was originally intended for this purpose.

>Those used above are usually used for hardware handshaking, where you toggle
>the line high or low.  For this you would normally have to use 4 wires (tx, rx
>gnd, and a control line(like one mentioned above)).  Xon Xoff is another way
>of sending flow control information using only 3 wires.  Because it is software
>controlled you use only (tx, rx, and gnd).  Normally you would send a DC3 or
>CTRL S to signal the computer to stop sending data, and a DC1 or a CTRL Q to
>resume flow of data.


1. Although this refers to V.24 instead of RS232: The CCITT Standard
   says:
   "Circuit 106 - Ready for sending [this refers to pin 5]
    Direction: From DCE
    Signals on this circuit indicate whether the DCE is prepared to
    accept data signals for transmission on the data channel or for
    maintenance test purposes under control of the DTE.
    The ON condition indicates that the DCE is prepared to accept data
    signals from the DTE.
    The OFF condition indicates that the DCE is not prepared to accept
    data signals from the DTE
   "
   IMHO this indicates that CTS is indeed meant to allow for hardware
   flow control.

2. There are (at least) two levels of flow control:
   - RTS/CTS: Hardware flow control; with proper setup (internals of the
     UART chip, this would allow instantaneous stopping of output (i.e.
     after finishing of the current character)
   - XON/XOFF: Software flow control; as this is done by software, one
     usually cannot guarantee that no more than n characters are sent
     after issuing the XOFF, the "receiver" wants the "sender" to stop,
     the "receiver" sends XOFF, the "sender" receives this and
     eventually tells it's driver to shut up, this might take some time
     (interrupt latency, scheduling of the protocol task which handles
     XON/XOFF, actually detecting the XOFF, somehow telling the driver
     to shut up, the driver detecting this, ...
     To do this fast may prove to be VERY difficult, especially when the
     "driver" is on an intelligent serial card! Some 100 bytes may still
     be output!
   There are more levels: on top of these two one can put a protocol where
   messages are sent back and forth (e.g. look at S/HDLC's RNR/RR, I
   know, S/HDLC uses synchronous transmission and is transparent, but
   this is only an example, or look at the XMODEM protocol)

--
=======
| Josef Moellers		| c/o Siemens Nixdorf Informatonssysteme AG |
|  USA: mollers.pad@nixdorf.com	| Abt. PXD-S14				    |
| !USA: mollers.pad@nixdorf.de	| Heinz-Nixdorf-Ring			    |