[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-serial
Subject:    Re: Enabling auto RS485 half-duplex control
From:       Theodore Tso <tytso () mit ! edu>
Date:       2008-12-19 4:10:42
Message-ID: 20081219041042.GA20215 () mit ! edu
[Download RAW message or body]

On Thu, Dec 18, 2008 at 03:51:36PM +0000, Grant Edwards wrote:
> Yes there are.  The standard is that RTS is asserted when one
> whishes to transmit (and de-asserted when one has finished
> transmitting). Optionally, one waits for CTS to be asserted
> before transmitting.  Isn't that the definition of RTS and CTS
> that's in the standard?

There's a standard, which is not necessarily well adhered to.  Heck,
full-duplex RTS/CTS standard was used by thousands if not millions of
modems in flagrent violation of the RS-232 standard for some 10 years
or more before TIA-232-E was released and bowed to reality.

I know I received all sorts of requests for very strange
implementations of half-duplex, with people sending me product specs
with all manner of requirements, both in terms of which RS-232 lines
were used (which may have been confusions caused by the fact that many
systems ship with random and wondrous DB9->DB25 cables, or strange
DTE/DCE conversion cables), but also in terms of mutually exclusive
requirements in terms of minimum and maximum turnaround times.

Someday when I'm board I can try to dig the requests out of the
archives, but I can definitely say that people asked for very strange
things, much of which was not in the standard (and as I pointed out,
until 1990 traditional full-duplex RTS/CTS hardware flow control was
not recognized by the RS-232 standard either).

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]