GPWRDCS@gp.govt.nz (Don Stokes, GPO) (09/17/89)
In article <870.251007A2@zswamp.fidonet.org>, Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) writes: > > From: tjfs@tadtec.uucp (Tim Steele) > > Message-ID: <TJFS.89Sep13124529@tadtec.tadtec.uucp> > > > I have incredibly bigoted opinions on the RS232 "standard". The > > We all do. Everyone who has worked extensively with RS-232 "conforming" > devices does. No kidding! > > > Although the standard doesn't say anything about connectors, there is > > a common "de facto" standard using 25 pin D connectors, with the > > female connector on the modem and the male connector on the terminal. > > The practice of putting the male connector on the DTE came in with the IBM > PC; all micros I saw before that had female RS-232 connectors, regardless of > "sexual preference". Hmmm - all DEC gear I've ever seen have had male connectors on the DTE interface. But yes, most non-DEC terminals, particuarly the more ancient stuff has had female connectors. Personally, I think the current trend makes more sense, as one can daisy-chain modem cables to one's heart's content without having to find gender-benders all the time, > > a) Cables that don't connect all 25 wires. Of course, the standard > > They're not bad; what I hate are machines (e.g. Amiga 1000) which do stupid > things with lines the designers THOUGHT wouldn't be used (all A1000 power > supply voltages can be accessed through the serial port; this has blown > several modems that I know of...) I have never connected all lines in an RS232 line in my life. Quite simply, if one needs only 3, 7 or whatever lines in a cable, one uses a 3, 7 or whatever core cable (or near approximation) - dealling with 25-core cables is too much like wrestling snakes, or has insulation that is too thin, or more often than not, both. 12-core is bad enough. I use 3 cores in my cables if I can get away with it. > > specifies more wires than you "really" need... indeed, with an > > intelligent modem such as a TrailBlazer you can get away with just > > Transmit & Receive Data and Signal Ground (that's 2, 3 and 7). Most > > of the other pins exist either so the DTE can tell the DCE something > > "extra" (like "Use high speed" or "I'm ready for your data") or vice > > versa (like "I can see carrier"). There are also a few pins for > > synchronous operation, and even some spare ones! > > Ideally the TBit (and other high-speed modems) should be using the RTS and > CTS lines for hardware handshaking, and all modems should have the DTR and DCD > lines connected. These all provide unambiguous information more quickly than > would be possible via characters in the data stream (XON/XOFF, NO CARRIER, the > "+++" escape sequence, etc.). > > Ironically, I'm fairly sure that this is not how the EIA defined the RTS > and CTS lines' use in the RS-232 spec. I think RTS/CTS are intended for half-duplex modems, certainly the behaviour is rather different for hdx than fdx, in that with hdx modems, the RTS is dropped as soon as data transmission stops, which is somewhat incompatible with the fdx arrangement where the RTS line acts as the other device's CTS line. In a hdx modem, the RTS line determines whether a transmit carrier is generated. Depends what you are doing - my general rule is that the more handshake lines there are, the more sources of problems there are :-). XON/XOFF can be very reliable - eg most DEC comms gear will react to an XOFF in just as much time as it takes to respond to loss of CTS (and in my experience, is more likely to work). XON/XOFF is sufficiently simple that it can be hardware implemented, and reasonably easily in software. Modem control is another kettle of fish. For an originating modem attached to an interactive terminal, there is no major problem - I am usually quite happy with three-core cables. For an answering modem, or originating modem that must run unattended, DCD & DTR should be present to allow accurate detection of carrier loss, and a bulletproof way of dropping the carrier. > > b) Misunderstandings between DCE and DTE about the use of various > > pins. For example, one end may expect to hardware handshake using > > RTS/CTS whereas the other end may be expecting to use XON/XOFF inband > > signalling. > > Easy solution: be prepared to do all. > Just to drive everyone up the nearest wall, I've come across a few devices that use DTR as their flow control line... Don Stokes / / vuwcomp!windy!gpwd!don Systems Programmer /GP/ Government Printing Office PSI%0530147000028::DON __________________/ /__Wellington, New Zealand___________don@gp.govt.nz________ It is morally wrong to allow naive users to keep their money.
Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) (09/18/89)
> From: GPWRDCS@gp.govt.nz (Don Stokes, GPO) > Message-ID: <328@gp.govt.nz> > I have never connected all lines in an RS232 line in my life. Quite > simply, if one needs only 3, 7 or whatever lines in a cable, one uses a > 3, 7 or whatever core cable (or near approximation) - dealling with > 25-core cables is too much like wrestling snakes, or has insulation that > is too thin, or more often than not, both. 12-core is bad enough. I use > 3 cores in my cables if I can get away with it. If the software and hardware support it, I always prefer to go 9-line for short cabling (computer <--> modem): pins one thorugh eight plus twenty (this provides signal and chassis ground, RxD, TxD, RTS, CTS, DSR, DTR, & DCD. Of course, for wiring terminals from one building to another, you can get away with 4-conductor (GND, RxD, TxD, and the terminal's DTR wired to the host's DCD), but I've always been frustrated by the lack of immediacy that gives me with modem control and the roadblocks that result if I use that kind of setup with a driver that demands fuller hardware handshaking (like the INT 14H drivers in the IBM PC). > I think RTS/CTS are intended for half-duplex modems, certainly the > behaviour is rather different for hdx than fdx, in that with hdx modems, > the RTS is dropped as soon as data transmission stops, which is somewhat > incompatible with the fdx arrangement where the RTS line acts as the > other device's CTS line. In a hdx modem, the RTS line determines > whether a transmit carrier is generated. Yes - full duplex modems use RTS as a signal to the computer/terminal that they're ready to accept data and the terminal/host uses CTS to indicate the same to the modem; that's not how the Request-To-Send and Clear-To-Send lines work in the EIA spec. It is, however, how every late-model 9600+ bps modem uses them. Let's not forget that the specified DSR/DTR handshake has also been overriden by the use of DTR as a hook control on most modems. > Depends what you are doing - my general rule is that the more handshake > lines there are, the more sources of problems there are :-). XON/XOFF > can be very reliable - eg most DEC comms gear will react to an XOFF in > just as much time as it takes to respond to loss of CTS (and in my > experience, is more likely to work). XON/XOFF is sufficiently simple > that it can be hardware implemented, and reasonably easily in software. I prefer to avoid it because binary transfers could easily contain the XOFF or XON character and, if the driver dumbly takes that as an indication that it shouldn't send until it gets an XON, then the transfer locks up. This may not be a concern with terminals (although downloadable character sets and advanced graphics are changing that), but it's vital with modems. I prefer to keep the control signals out of the data path because that allows use of short, simple drivers that rely on unambiguous signals. It may also result in faster operation, since the driver no longer has to process the data in any way, merely pass it on... > Modem control is another kettle of fish. For an originating modem > attached to an interactive terminal, there is no major problem - I am > usually quite happy with three-core cables. For an answering modem, or > originating modem that must run unattended, DCD & DTR should be present > to allow accurate detection of carrier loss, and a bulletproof way of > dropping the carrier. OK, then, we don't disagree... much, anyway. > Just to drive everyone up the nearest wall, I've come across a few > devices that use DTR as their flow control line... Ah, but that's EIA spec! We can't complain that RTS/CTS handshaking as used by recent modems breaks from spec if we're going to complain that some equipment out there CONFORMS to spec, can we? <grin> -- Geoffrey Welsh - via FidoNet node 1:221/171 UUCP: {{uunet!}watmath!xenitec!}zswamp!171.0!Geoffrey.Welsh ARPA: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org