Date: Mon, 29 Aug 2005 08:40:21 GMT From: Yar Tikhiy <yar@comp.chem.msu.su> To: freebsd-doc@FreeBSD.org Subject: Re: docs/85355: [patch] Error in the pin numbers of the described connector in the Handbook (serial). Message-ID: <200508290840.j7T8eLPd002901@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/85355; it has been noted by GNATS. From: Yar Tikhiy <yar@comp.chem.msu.su> To: "Gary W. Swearingen" <garys@opusnet.com> Cc: jpeg@thilelli.net, bug-followup@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508290840.j7T8eLPd002901>