docs/85355: [patch] Error in the pin numbers of the described connector in the Handbook (serial).

[Yar Tikhiy]

The following reply was made to PR docs/85355; it has been noted by GNATS.

From: Yar Tikhiy <yar at comp.chem.msu.su>
To: "Gary W. Swearingen" <garys at opusnet.com>
Cc: jpeg at thilelli.net, bug-followup at FreeBSD.org
Subject: Re: docs/85355: [patch] Error in the pin numbers of the described connector in the Handbook (serial).
Date: Mon, 29 Aug 2005 12:30:36 +0400

 On Sat, Aug 27, 2005 at 08:40:20PM +0000, Gary W. Swearingen wrote:
 >  Julien Gabel <jpeg at thilelli.net> writes:
 >  
 >  > +	  <para>If you like making your own cables, you can construct a
 >  > +	    null-modem cable for use with terminals.  This table shows the RS-232C
 >  
 >  "for asyncronous communications with terminals".  (I'm not sure what
 >  "terminals" include, but synchronous comm needs more wires.)
 
 It might be reasonable to tell that in general, a null-modem cable
 is for connecting a DTE directly to another DTE.  AFAIK, null-modem
 cables can be constructed for synchronous comms, too.  Then, the
 topic can be narrowed down to async comms.
 
 >  > +	    signal names and the pin numbers on a DB-25 connector.  More information
 >  > +	    and collection of cable descriptions may be found in the <ulink
 >  > +	    url="http://www.hardwarebook.net/cable/index.html">Hardware Book</ulink>.</para>
 
 To me, www.hardwarebook.net doen't seem the definite resource.
 IMHO, if the topic is rather wide, the reader should better be
 hinted to do a (re)search on the Net instead of pointed to a single
 resource, which is likely to become incomplete, outdated, or down.
 
 >  I'd add: The standard also calls for a straight-through pin 1 to pin 1
 >  "protective ground" line, but it is often omitted.  Some terminals can
 >  get by using only pins 2, 3, and 7, while others, especially printers,
 >  require other configurations than the example here.  Synchronous
 >  communications, for example, requires more lines to be used.
 
 Perhaps, we can spend a paragraph on giving the reader some insight
 into null-modem design principles, eh?  In particular, the 3-wire
 cable, for which we happen to have some entries in /etc/gettytab,
 will provide data lines, but won't support flow control (RTS, CTS)
 or modem control (DTR, DSR, DCD).  So the reader could understand
 *why* he may or may not need the simpler or the more complex cable
 design.  I myself once spent some time making a 8-wire null-modem
 cable only to find out that my terminak didn't support flow control
 in the first place :-)
 
 Apropos, has there ever been a DTE printer?  I think that printers
 or sync comms shouldn't belong there if it were told above that we
 would deal with async DTE-DTE comms only in this section.
 
 >  > +		  <entry>8</entry>
 >  > +		  <entry>DCD</entry>
 >  
 >  That design (after the fix) seems to be the most popular, but a book
 >  "RS-232 Made Easy" uses several pages developing and justifying a
 >  generic null-modem design like that, except he has 4 & 5 going to 8
 >  and vice versa.  I probably used in at least one of my cables.  Oh,
 >  well; that's life with RS-232.
 
 We may show two or three different designs in the handbook if we
 can tell the reader about their merits.  The problem with the design
 currently in the handbook is that it is erroneous *and* bogus.  I'd
 suggest adding another row to the table so that it becomes evident
 that DTR on this side is connected to DSR+DCD on the other side
 while DTR on the other side is connected to DSR+DCD on this side.
 An RS-232 null-modem cable should be symmetric, to my mind.
 
 -- 
 Yar