kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (06/07/89)
In article <1989Jun6.163942.15568@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >What most people mean by "RTS/CTS" flow control is using one line for flow >control in one direction and the other for the other direction. At least >that's my impression. [...] The >signals are meant for coordinating with half-duplex modems, which must >be told when to transmit and when to listen. [...] >Unless things have changed since I learned this, RTS and CTS >thus are not flow-control signals at all. Note that this is theory, as >opposed to the facts of how they are actually used by many devices... >-- I think that is about right, but since people have, over the ages, adapted RS-232 interfaces quite readily, I think it is fair to say that RTS and CTS have meaning in the context of full-duplex operation and that this is different than in the context of half-duplex operation. In the context of full duplex interfaces RTS/CTS is hardware based flow control and I know that to be true in the course of application, having used it repeatedly over the years when software flow control did not work for one reason or another. Of course, some interfaces use CTS to mean the same as CD or DSR. The vendor has to cooperate a little here. So, if you will accept this premise we can move the discussion on to the important issue of, when hardware flow control is activated, must the other side stop immediately, or should we allow the rest of the bits in the ASCII character in transit to come thru? :-) Sound like a fun problem to debug? One reason I prefer s/w flow control, the argument about stopping in the middle of a character doesn't usually arise. Kent England, Boston U
guy@auspex.auspex.com (Guy Harris) (06/09/89)
> In the context of full duplex interfaces RTS/CTS is hardware >based flow control Well, it depends on the interface. I could easily imagine a system where the, well, *hardware* didn't support "full-duplex RTS/CTS flow control" (by which I assume people mean "if CTS is high, you may send, otherwise you may not send; if you're ready to receive, raise RTS, otherwise lower RTS - CTS and RTS cross over in the connection between the machines") but the software did. None of the serial port interfaces with which I've worked support full-duplex RTS/CTS flow control in hardware; for instance, the Z8530 SCC chip used by Sun's CPU serial ports and ALM-2 board, and the Signetics 2661 EPCI used on the Systech MTI boards, do not. They support the form of "flow control" to which Henry was referring, and which was not, as I understand it, intended as flow control but was intended as a way to control a half-duplex modem (but which is, in practice, often used for flow control). I am told that AT&T has a serial port chip that supports full-duplex RTS/CTS flow control; the person who told me that no longer remembers how it figures out that the host is incapable of receiving any more characters, and therefore that it should drop RTS. (I hope nobody's using "hardware flow control" to simply mean "out-of-band flow control", as opposed to "in-band" flow control such as XON/XOFF flow control. Said usage is quite unfortunate, as out-of-band flow control is not necessarily done in hardware (and sometimes can't be done in hardware, cf. the above chips and full-duplex RTS/CTS flow control), and, depending on your definition of "hardware", in-band flow control can be done in hardware (consider a "smart" serial port board that does it for you, and doesn't require the host's driver to do so. A better term for "out-of-band flow control" is "out-of-band flow control".)
ron@motmpl.UUCP (Ron Widell) (06/16/89)
In article <32466@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
< In the context of full duplex interfaces RTS/CTS is hardware
<based flow control and I know that to be true in the course of
<application, having used it repeatedly over the years when software
<flow control did not work for one reason or another. Of course, some
<interfaces use CTS to mean the same as CD or DSR. The vendor has to
<cooperate a little here.
< So, if you will accept this premise we can move the discussion
<on to the important issue of, when hardware flow control is activated,
<must the other side stop immediately, or should we allow the rest of
<the bits in the ASCII character in transit to come thru? :-) Sound
<like a fun problem to debug? One reason I prefer s/w flow control,
<the argument about stopping in the middle of a character doesn't
<usually arise.
<
< Kent England, Boston U
On every uart of which I am aware, the CTS input is an enable for
transferring the transmit buffer to the shift register. When CTS
is true, the character in the transmit buffer will be loaded into
the parallel load shift register after the last bit (plus the stop
bit[s]) has been shifted out. When CTS is false, this parallel load
will be disabled, but the operation of the shift register will not
be affected.
Things can certainly change when synchronous protocols are involved,
e.g. the hardware handshake *could* (but usually doesn't) stop the
clock.
BTW, why must the characters be ASCII :-)?
--
Ron Widell, Field Applications Eng. |UUCP: {...}mcdchg!motmpl!ron
Motorola Semiconductor Products, Inc., |Voice:(612)941-6800
9600 W. 76th St., Suite G | I'm from Silicon Tundra,
Eden Prairie, Mn. 55344 -3718 | what could I know?