RAF@NIHCU.BITNET ("Roger Fajman") (02/18/88)
> 1 chassis gnd <-> chassis gnd 1 > 2 txd <-> rxd 3 > 3 rxd <-> txd 2 > 4 rts <-> cts 5 > 5 cts <-> rts 4 > 7 sig gnd <-> sig gnd 7 > 6 & 8 (dsr & dcd) <-> dtr 20 > 20 dtr <-> (dsr & dcd) 6 & 8 Crossing pins 4 and 5 (Request To Send and Clear To Send, respectively) makes no sense to me. If these pins are actually used, the DTE should raise Request To Send when it wants to transmit and wait for Clear To Send before it does. Thus passing one side's RTS to the other's CTS isn't very meaningful. Jumpering them at each end of the cable makes sense, if you really don't want to use them for flow control. However, my favorite arrangement is as follows: 1 Protective Ground <-> 1 Protective Ground 2 Transmitted Data -> 3 Received Data 3 Received Data <- 2 Transmitted Data 5 Clear To Send -| 6 Data Set Ready |- <- 20 Data Terminal Ready 8 Carrier Detect -| |- 5 Clear To Send 20 Data Terminal Ready -> -| 6 Data Set Ready |- 8 Carrier Detect 7 Signal Ground <-> 7 Signal Ground With this arrangement, if one of the devices turns off DTR to stop the flow of data (as many devices can do), the other device will see it as CTS, DSR, and CD all going off. If it pays attention to any RS232 line for flow control, it is likely to be one of those.
brianb@marque.mu.edu (Brian Bebeau) (02/18/88)
In article <8802180550.AA09815@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes:
:
:Crossing pins 4 and 5 (Request To Send and Clear To Send,
:respectively) makes no sense to me. If these pins are actually
:used, the DTE should raise Request To Send when it wants to transmit
:and wait for Clear To Send before it does. Thus passing one side's
:RTS to the other's CTS isn't very meaningful.
: However, my favorite arrangement is as
:follows:
:
:5 Clear To Send -|
:6 Data Set Ready |- <- 20 Data Terminal Ready
:8 Carrier Detect -|
:
:With this arrangement, if one of the devices turns off DTR to stop
:the flow of data (as many devices can do), the other device will see
:it as CTS, DSR, and CD all going off. If it pays attention to any
:RS232 line for flow control, it is likely to be one of those.
No, this doesn't make much sense to me. It's been my experience that
most DTE devices specify DTR as being *always* on, therefore useless
for hardware flow control. If the DTE implements RS-232 properly,
RTS-CTS crossed over will work properly for hardware flow control.
At least it always did when I was working for a modem manufacturer.
---------------------------------------------------------------------------
Brian Bebeau Marquette University
DOMAIN: brianb@marque.mu.edu
UUCP: {rutgers,ihnp4,harvard}!uwvax!marque!brianb
{rutgers,uunet}!marque!brianb
ARPA: brianb%marque.uucp@csd1.milw.wisc.edu
BITNET: 6877BEBE@MUCSD
---------------------------------------------------------------------------cabo@tub.UUCP (Carsten Bormann) (02/23/88)
In article <40@marque.mu.edu> brianb@marque.UUCP (Brian Bebeau) writes:
()
() It's been my experience that
() most DTE devices specify DTR as being *always* on, therefore useless
() for hardware flow control. If the DTE implements RS-232 properly,
() RTS-CTS crossed over will work properly for hardware flow control.
This is complete nonsense.
Can you guys please read the standards before writing such postings?
The internationally relevant CCITT recommendation V.24 (called RS-232
in the US) does not provide for flow-control signalling in any form.
Period.
(Warning: If you disagree, you don't have any idea about serial
communications standards. No need to make another incorrect posting.)
Now, as flow-control is sometimes desirable, some manufacturers have
decided to bend the specification a little. What you need for
flow-control is two additional lines: Let's call them Input Ready (IR)
and Output Ready (OR), both from the DTE point of view.
The lines for flow-control are not there in V.24 (and I bet in RS-232,
although I don't have a copy of the latest version RS-232-D). Adding
them to the boards (and to the chips) creates considerable costs. But
you can take any pair of RS-232 signalling lines and REINTERPRET them
as IR and OR. Now, what signalling lines look like they are not so
useful and can thus be stolen?
DTR and DCD are needed to signal that a connection is wanted and is
present, resp., so typically we don't want to steal these lines
(actually, the CCITT recommendation V.24 prescribes the use of DSR for
the purpose for which DCD is used most of the time nowadays, but I
don't want to pick nits here).
RTS/CTS only really make sense in a half-duplex application, so in our
full-duplex world they make good candidates for IR/OR. This becomes
even more handy as CTS already has semantics somewhat similar to OR in
the standard (but not for flow control, but for signalling from the
modem to the terminal that the modem is in a sending state and has been
in this state long enough that it is likely that the remote modem is in
sync), so many chips already implicitly support OR semantics on the CTS
pin. The only pin whose semantics are completely changed is the old
RTS pin, which in its RTS semantics means that you want the modem to
prepare for sending, and now in the IR semantics is used to signal the
modem that you are ready for receiving!
Modems that understand V.24 don't have OR/IR pins. Modems that have
OR/IR pins (which is very useful for ``smart'' modems) on pin 5/4 don't
support V.24 (at least not RTS/CTS). Do things become clearer?
Let's close this up with a few examples.
If you want to build a NULL MODEM (according to V.24), you wire:
FGnd 1-------1 FGnd
TxD 2--->---3 RxD
RxD 3---<---2 TxD
RTS 4\__>___8 DCD
CTS 5/
DSR 6---<--20 DTR
SGnd 7-------7 SGnd
DCD 8___<__/4 RTS
\5 CTS
DTR 20--->---6 DSR
This arrangement EXACTLY behaves like a pair of V.24-conforming modems
(with the exceptions of missing time delays and no connection to pin
22, Ring Indicator, which I normally connect to pin 6).
Now, most US modems use pin 8 (DCD) for what V.24 calls DSR (pin 6),
so for US applications we modify this into:
FGnd 1-------1 FGnd
TxD 2--->---3 RxD
RxD 3---<---2 TxD
RTS 4\
CTS 5/
DCD' 8---<--20 DTR
SGnd 7-------7 SGnd
/4 RTS
\5 CTS
DTR 20--->---8 DCD'
The name DCD' tries to express that this pin is not used in quite the
same meaning as intended by V.24.
If we want to include flow-control, we LEAVE THE REALM OF V.24, and get
(assuming that we actually reinterpret pin 4 for IR and pin 5 for OR)
the following wiring:
FGnd 1-------1 FGnd
TxD 2--->---3 RxD
RxD 3---<---2 TxD
IR 4--->---5 OR
OR 5---<---4 IR
DCD* 8---<--20 DTR
SGnd 7-------7 SGnd
DTR 20--->---8 DCD*
Note that this picture does NOT include any pins labeled RTS or CTS,
as there are no such pins in this picture.
After reading comp.dcom.modems for some time, I get the impression this
posting needs to be repeated every two weeks.
Yours for better understanding of standards,
--Carsten
--
Carsten Bormann, <cabo@tub.UUCP> <cabo@db0tui6.BITNET> <cabo@tub.BITNET>
Communications and Operating Systems Research Group
Technical University of Berlin (West, of course...)
Path: ...!pyramid!tub!cabo from the world, ...!unido!tub!cabo from Europe only.dave@onfcanim.UUCP (Dave Martindale) (03/04/88)
In article <40@marque.mu.edu> brianb@marque.UUCP (Brian Bebeau) writes: > >No, this doesn't make much sense to me. It's been my experience that >most DTE devices specify DTR as being *always* on, therefore useless >for hardware flow control. If the DTE implements RS-232 properly, >RTS-CTS crossed over will work properly for hardware flow control. >At least it always did when I was working for a modem manufacturer. Please note that RTS-CTS flow control is NOT a "proper" implementation of RS-232. RTS is supposed to be used by the DTE to request that the (half-duplex) modem switch into transmit mode, and CTS was a reply from the modem indicating that it was now configured and stable ready for transmission. With full-duplex modems, this pair of functions isn't needed, and the wires are often used for flow control, and if both the DTE and modem support this then it's useful. If you interconnect two DTE's that both use RTS/CTS flow control, then crossing RTS/CTS in the null modem cable is good. If the devices conform to the RS232 standard, though, you want to connecte pin 4 to pin 5 by a short jumper at each end. Finally, most "real computers" DO implement DTR. If they only implement two modem control signals, it will be DTR and either carrier detect or DSR. When making a null modem cable, it is useful to include DTR, crossed to DSR and CXR at the other end, so the machine on one end can tell when the one on the other end has gone away or wants to talk.