totty@flute.cs.uiuc.edu (Brian Totty) (11/10/90)
I want to send flow control information back to a sender across an RS232 serial cable. What signal is appropriate for this? Do I use CTS (clear to send), or one of these "secondary" signal lines? All I want to do is to be able to temporarily tell the sender not to send my UART data is some relatively standard way. I am using a direct null-modem connection and can get a full 25 pin cable. Thanks For Any Help! --- Bri P.S. Any pointers to good, accessible RS232 docs would be great too... / Brian Totty o o /__ __ o 1304 W. Springfield Avenue o / / / / Urbana, IL 61801 \_/ "We have corn in /__/ / / totty@cs.uiuc.edu Massachusetts too!"
bender@oobleck.Eng.Sun.COM (Michael Bender) (11/10/90)
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? > Do I use CTS (clear to send), or one of these "secondary" signal > lines? All I want to do is to be able to temporarily tell the sender > not to send my UART data is some relatively standard way. I am > using a direct null-modem connection and can get a full 25 pin > cable. I've used CTS/RTS. My computer monitors CTS, and when it goes low, the data transfer from my system is paused, until CTS goes high again. RTS is asserted normally, and when my system detects it's input buffers getting full, is deasserts RTS. mike -- Won't look like rain, Won't look like snow, | DOD #000007 Won't look like fog, That's all we know! | AMA #511250 We just can't tell you anymore, We've never made oobleck before! | MSC #298726
henry@zoo.toronto.edu (Henry Spencer) (11/14/90)
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. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
robin@uhunix1.uhcc.Hawaii.Edu (Robin Amano) (11/14/90)
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. -- ---------------------------------------------------------------- Robin Amano | Internet: robin@uhunix.uhcc.hawaii.edu UHCC | 2565 The Mall | Honolulu, HI 96822
josef@nixdorf.de (Moellers) (11/15/90)
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 |
henry@zoo.toronto.edu (Henry Spencer) (11/17/90)
In article <josef.658656371@peun11> josef@nixdorf.de (Moellers) writes: > "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 ... > " > IMHO this indicates that CTS is indeed meant to allow for hardware > flow control. Sort of kind of. The trouble is that RTS is not symmetrical with it. The way it works is that you raise Request To Send to indicate that you wish to send data, and the modem replies with Clear To Send to indicate that you should go ahead. This is meant for half-duplex modems that have to know when they should be talking and when they should be silent. The reason for the feedback path is that it can take them a noticeable fraction of a second to establish outgoing carrier. "DCE" is standardese for "modem". The standards don't envision the possibility of directly connecting two computers (etc.) at all; they were written strictly in terms of computer/terminal-to-modem hookups. And the notion of flow control never appears in them at all. Actually, I believe RS-232D (yes, RS-232C is obsolete) explicitly identifies an optional symmetrical-flow-control role for RTS and CTS. However, almost nobody is aware of RS-232D yet, and nobody really implements RS-232D, any more than they really implemented RS-232C. The general answer is still "you have to find out what your particular device wants". -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry