res@colnet.uucp (Rob Stampfli) (05/25/91)
There is an involved discussion going on right now in comp.sys.3b1 about why some people are having problems making hardware flow control work, specifically with the Unix-PC. Generally, there seems to be two implementations of hardware flow control, as shown in the following excerpt from "Managing UUCP and Usenet" by O'Reilly & Associates (brackets mine). My question is, which of the two implementations are modems currently designed to work with? Which does Unix provide? If the half-duplex standard is the way things *really* work, how can the data coming from a modem be likewise controlled. Basically, a short tutorial on hardware flow control, as employed by Unix and current generation modems, would be helpful to me, and I would predict, to a number of other readers. I am looking for someone who knows the facts, and not just speculating. From "Managing UUCP and Usenet": "In the RS-232 standard, [ hardware ] 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 [ computer ] asserts RTS when it wants to send data. The DCE [ modem ] 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 meanings than they do for half-duplex communications. "When 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 RTS or CTS drops at any time, this tells the sending system that the receiver is not ready for more data... Thanks in advance, -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
root@zswamp.uucp (Geoffrey Welsh) (05/28/91)
In a letter to All, Rob Stampfli (res@colnet.uucp ) wrote: >Generally, there seems to be two implementations of hardware flow control, I'd suspect that there are more, since many manufacturers have embellished the RS-232 standard to suit their own tastes. > "However, in the full-duplex variations, RTS/CTS is used >as a kind of > throttle. The signals have the opposite meanings than >they do for > half-duplex communications. > "When 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 RTS or CTS drops at any time, >this tells the > sending system that the receiver is not ready for more >data... This is in fact how high-speed dialup async modems use the RTS and CTS lines. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
tnixon@hayes.uucp (05/28/91)
In article <1991May25.061834.4893@colnet.uucp>, res@colnet.uucp (Rob Stampfli) writes: > There is an involved discussion going on right now in comp.sys.3b1 about > why some people are having problems making hardware flow control work, > specifically with the Unix-PC. Generally, there seems to be two > implementations of hardware flow control, as shown in the following excerpt > from "Managing UUCP and Usenet" by O'Reilly & Associates (brackets mine). > > My question is, which of the two implementations are modems currently > designed to work with? Which does Unix provide? I can't tell you what Unix provides, but I can tell you what today's error control modems do. It is as "Managing UUCP and Usenet" describes for "full duplex". If the modem is ready to accept data, it asserts CTS; if it is unable to receive data, it turns off CTS. When the DTE is ready to accept data, it turns on RTS; when it is unable to accept data, it turns off RTS. RTS and CTS are totally independent in this scheme -- each controls flow coming from the opposite direction, and neither depends on the other (unlike the half-duplex use of the signals). I should note, for completeness (since I am actively involved in standards committees) that when "RTS" is used this way, it really _isn't_ "RTS", but "RTR". That is, not "Request to Send", but "Ready To Receive". The use of this signal for flow control purposes is described by CCITT V.24 as circuit number 133. We've defined it as appearing on the SAME PIN AS RTS, since (a) you never use both the RTS and RTR function at the same time, and (b) most DTEs are able to drive that pin as an output, so it is convenient to use it instead of some other pin. CCITT V.42 specifically calls out the use of RTR/CTS flow control, _not_ RTS/CTS. Note that the use of CTS for flow control _is_ permitted under the standardized definitions of the circuit. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net