Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!phri!roy From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.dcom.modems Subject: RS-232C Message-ID: <2853@phri.UUCP> Date: Sun, 16-Aug-87 10:51:06 EDT Article-I.D.: phri.2853 Posted: Sun Aug 16 10:51:06 1987 Date-Received: Sun, 16-Aug-87 22:45:11 EDT References: <192@caeco.UUCP> <2849@phri.UUCP> <1102@gilsys.UUCP> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 79 Original-Subject: Fast (12KBaud) UUCP 'g' transfer rates over Voice-Grade Lines In article <2849@phri.UUCP> I asserted that RS-232 has no flow control. BTW, I meant RS-232C; I should have been more specific. To be honest, I don't even know what RS-232A and RS-232B are. In article <1102@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: > That's an interesting comment, Roy. I find it difficult to accept, as > every RS-232 interface standard document I have ever seen includes the RTS > and CTS [...] If there is no handshaking defined, **WHAT IN THE WORLD ARE > THESE LINES DEFINED FOR**??????? Before I launch into this, I should warn people that I am not an RS-232C guru, so I may be messing up a bit on the details. This has all been hashed over in the past, and by people more expert than myself. It might be a good idea to go through your archives and find the old discussions and/or buy the official standard and read it carefully. RS-232C was published back in the days when half-duplex connections were much more common. The RTS/CTS lines are intended to be used to negotiate line turn-around in a half-duplex connection. When the the DTE (Data Terminal Equipment, i.e. computer or terminal) wants to send something it asserts RTS (Request To Send). When the DCE (Data Communications Equipment, i.e. modem) is ready to accept this transmission, it asserts CTS (Clear To Send). DTR (Data Terminal Ready) and DSR (Data Set Ready) are used to negotiate answering and hanging up the phone. When a DTE is ready to accept a connection (e.g. Unix has finished booting and getty is running), the DTE asserts DTR. When a call comes in to the DCE, it looks to see if DTR is asserted, and if it is, answers the call and asserts DSR. The DTE, when it sees DSR asserted, knows that a connection is completed and starts doing work (e.g. getty's open(2) on the tty line returns). When the DTE wants to break the connection (i.e. you logout), it negates DTR which tells the DCE to drop the phone line. If the connection gets broken (i.e. you just hang up the phone), the DCE negates DSR (or is there were CD comes in? see next paragraph) which tells the DTE that it's all over. Note that DTR and DSR should never change during the course of a connection; only at the start and end of one. RI (Ring Indicator) is used by the DCE to tell the DTE that the phone is ringing. I'm not sure why this is needed; presumably the DTE could wait to see RI before asserting DTR if there was some reason why keeping DTR asserted for a long period of time was a bad idea. CD (Carrier Detect) is used by the DCE to tell the DTE that there is carrier; I'm not sure how this differs from DSR. Add in TD (Transmit Data) and RD (Receive Data) and a couple of grounds (signal and chassis ground; not to be confused or inter-connected) and you've used 10 pins. There are another 15, all of which have defined meanings, most of which most people don't care about. Also, most people in the Unix or (generic) PC world will never see a half-duplex connection in their lives. Since hardware flow-control is indeed a good thing to have in many situations, some manufacturers have taken it upon themselves to implement hardware flow control in all sorts of interesting, non-standard ways. RTS/CTS handshake seems to be the most common, but I've seen DTR/DSR handshaking as well (even worse). Now, as I've said before, if you do RTS/CTS handshaking, you havn't implemented RS-232C. That's not to say that you havn't implemented something potentially good, just that you havn't followed the standard. Along the same lines, lots of manufacturers have taken it upon themselves to decide that a DB-25 takes up too much space given that most of the pins aren't used any more (when's the last time you saw a secondary channel or the clock lines used?) and used smaller connectors. DEC seems to like DB-9's, while Apple has gone off and adopted those mini DIN connectors and other people are using full-size DIN plugs. Other manufacturers have also decided that since most printer and terminal connections are not going to have modems in the line anyway, they should just go ahead and put DCE ports on their computers and let people use straight cables. And keeping track of proper sex is just hopeless. With all that in mind, I think what we need is a new standard which implements hardware handshaking, smaller connectors, etc. Until such a standard is adopted, however, fie on manufacturers who make up their own and call it RS-232C. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016