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
============================================================