Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!hayes!tnixon From: tnixon@hayes.uucp Newsgroups: comp.dcom.modems Subject: Re: Hardware Flow Control Message-ID: <4032.2861e0cd@hayes.uucp> Date: 21 Jun 91 11:19:41 GMT References: <42910619180524.0004025717NB2EM@mcimail.com> Organization: Hayes Microcomputer Products, Norcross, GA Lines: 85 In article <42910619180524.0004025717NB2EM@mcimail.com>, HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM (MikeB) writes: > I'm curious how exactly the RTS/CTS handshaking flow control works between a > PC and a modem. From what I've seen the following is true: > > o The CTS is asserted when the modem buffer is full (256 bytes?). CTS is normally high -- after all, it stands for "Clear to Send". When the modem buffer fills past a certain point (usually 75%, not completely full, to allow some time for the PC to react to the change in state), the modem drops CTS. Then, when the buffer empties to a certain point (usually 25%; you never use the same "on" and "off" point, or the signal would be constantly bouncing up and down), CTS is reasserted, allowing data to flow once again. As for the buffer size itself, this varies widely from manufacturer to manufacturer. Hayes uses 256-byte buffers on the DTE (PC) interface, in order to avoid having large amounts of data buffered up in one modem that can't be effectively stopped by a cancel request from the other DTE. Other manufacturers have used much larger buffers, on the theory that this makes it more possible for them to support DTEs that don't properly support flow control (but, in that situation, you WILL, sometime, lose data anyway!) > o If a PC asserts RTS, it causes the *remote* modem to stop sending data > although a few bytes still get through. "RTS" is a misnomer in this case. It is called that only because the function being performed by the signal is assigned to the same pin as the RTS (Request to Send) signal. But when the pin is being used for flow control, it is more properly known as RFR (Ready for Receiving). The signal, again, is normally on. When the PC's buffer fills to a certain point (I won't repeat the discussion above, but the details of on/off points are the same), it drops RFR. This stops the LOCAL MODEM from delivering more data to the PC. In most modems, there is NO direct transfer of this signal to the remote modem. Instead, what happens is that the stoppage of flow to the local PC causes data to build up the local modem's buffers. When those buffers reach a certain point, the local modem signals the remote modem through a particular frame in the error control protocl (RNR [Receive Not Ready] in LAPM), which stops more data from coming across the phone line. The remote DTE may still be delivering data to the remote modem, so when the remote modem's buffers fill to a certain point, it stops flow from the remote DTE (either by sending XOFF or dropping CTS, depending on which form of flow control is being used). So, yes, by dropping RTS, the local DTE can _eventually_ stop the flow of data from the remote modem and DTE, but it is all the buffers in the receive path becoming full rather than any immediate transfer of flow control status to the remote. I should note that SOME modems DO flow off the remote modem with RNR as soon as the local DTE drops RFR, but that is not generally considered to be the most efficient way to manage the link. > o There is no way to signal the local modem to stop sending data. Sure there is, as I described above. > For a programmer > writing a modem interface protocol, what is the best to way to handle > hardware flow control? As I stated above. When CTS changes state (on or off), you should get a Modem Status Change interrupt. If CTS has gone off, you should suspend data transmission (completing any character already in the process of being sent or already in UART buffer). When CTS goes back on, resume data transmission. On the receive side, when your receive buffer fills to a particular point (say, 75% of full), drop RTS to cause the modem to suspend delivering data, and when it gets down to a lower point (say, 25%), reassert RTS to cause the modem to resume delivering data to you. -- Toby -- 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 tnixon%hayes@uunet.uu.net