On Wed, Apr 07, 1999 at 06:22:40PM -0700, William Chops Westfield wrote: > > What you say is true of IBM and other "true half duplex" rs232 systems or > others fully obeying the rs232 spec. This represents approximately 0.05% of > existing asynchronous communications equipment, nearly all of which is full > duplex (removing the need for "spec" RTS/CTS behavior.) > > In any case, RTS is not used (never) to means DTE is ready to receive. > > Sure. Except for about 2 billion modems, printers, terminal servers and > other async serial devices that implement "hardware flow control" using > RTS/CTS. Asserting RTS/CTS means "ready to receive" (buffers not full), and > this will typically stop transmission of the other side at the hardware > level. Sorry spec writers, you were overruled by expedience. There is > no "hardware flow control" in rs232. It was needed, it was added. (and it's > just like IBM to claim it doesn't exist :-) Well, yes and no [he says somewhat timidly to someone who works where they make terminal servers]. This is probably true of many asynch applications, but often in those cases, there is no DCE -- in the case of a system and a printer, or a hardwired terminal attached to a terminal server, one has DTE-DTE communications, not DTE-DCE communications as the protocol is designed. If one was using DTE-DCE communciations, the CTS would be connected to CTS and RTS to RTS. The DTE would be input on CTS and output on RTS, and the DCE the other way around -- input on RTS and output on CTS. Then, the terminal can tell the modem when it wants to send, and the modem can tell the terminal when it *can* send. This all works just fine and dandy. But in DTE-DTE communications, both sides want to output on RTS and input on CTS. So you connect RTS to CTS and CTS to RTS. On the hardwired terminal, the terminal still believes that it is talking to a modem. Thus, when it has stuff to send, it asserts RTS. The terminal server also believes that it is talking to a modem, and it sees what it thinks is CTS asserted. This of course just doesn't make any damned sense. "I want to send you something so go ahead and send me something??" And the terminal server, if it wants to be hard-nosed about the protocol, is going to be a little annoyed about seeing a CTS when it never did an RTS. No, there really isn't any way to reconcile this other than to hack at the protocol and make something up. If we use modems on both ends, then we have DTE-DCE-DCE-DTE communications and four pairs of signals to work with. In straight DTE-DTE connections, there are only two pairs, and there isn't really any good way to implement the full, as-intended protocol. Thus, in some equipment you'll have separate configuration settings for "use modem signals" and "RTS/CTS flow control". They are different protocols. Which, unfortunately, only serves to make more confusing something that is already hellaciously confusing. FWIW, I found another good description of RS-232, better than the previous. This one is at CAMI research, which sells automated cable test equipment: http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html --Bob -- ============================================================ Bob Drzyzgula It's not a problem bob@drzyzgula.org until something bad happens ============================================================