Talk:Serial port/Archive 1

Archive 1

Infobox cruft

I really really hate the infobox. Just what articles are encrufted by this...thing? What purpose does it serve? Why must we spend so much time cluttering up pages with things like this when 1,000,000 articles don't even have *references*? --Wtshymanski 17:52, 11 October 2006 (UTC)

Look at the inaccuracy of this specimen. Invented 1969? Don't think so, computers had serial ports before Revision C of RS-232. Superseeded? Maybe "Superceded" ? Or are we talking about wheat? Anyway, a USB port is incompatible with RS 232 and so the two are not interchangeable. Width 5-9 bits? In a serial port? That's a character frame, anyway - and often 10 bits, or more, depending on how you count the start/stop bits. Speed 115 kbits? That's not RS-232 - some IBM PC serial ports do this, but it's hardly standard. "Style Serial" conveys *nothing* to the reader. Hotplugging is a PC-centric concept and unexplained in the article. What does "external" mean in this context? Horrible, horrible...away with it. --Wtshymanski 17:58, 11 October 2006 (UTC)

Address and IRQ

Eh? This information used to be here. Where's the link that says where it went? Jim.henderson 22:56, 3 February 2007 (UTC)

A list of port addresses and IRQs for ONE possible computer type does not belong here. And, as anyone who ever tried to get two serial cards to share an IRQ (in an IBM-compatible machine with the so-called "ISA" IO bus), serial ports can't share the same IRQ if you actually expect to use both at the same time. Where are the port addresses for, oh, say, a Kaypro 10 or a Power Mac? And are these even meaningful in the context of PCMCIA adapters and "virtual" ports? --Wtshymanski 15:36, 11 February 2007 (UTC)

Thank you; the former is an excellent question. Kindly include this information in the section, or links to Wikipedia pages or external sites that answer the question. So far, we have found a small table with information useful for dealing with the majority of serial ports, but yes, this is a matter in which more would be better. If it gets to be a lot of data, then the section should be broken out into its own article with a link, but thus far it is small. As for the latter question, alas, I do not understand the relevance, but assuming it is relevant it should also be included in this article or a linked one. Jim.henderson 02:01, 12 February 2007 (UTC)

Could we please have some more pictures?

I'm just a reader and I'm finding it a bit difficult to tell the difference between a parallel and series port, and I thought Wikipedia would be better off with some better/more pics (there isn't any picture of a parallel port, to distinguish the two).

I think maybe diagrams would be more useful than pictures - you can't tell by looking at a connector on the back of a box if the connector is used for a serial port or a parallel port - and the ever-loving IBM PC confounded the issue by using the same family of connectors for serial, parallel, video, joystick and network connectors - so appearances were less than useful. There's a bit-serial diagram at Asynchronous start-stop but we need a diagram showing both together, I suppose.. --Wtshymanski 03:20, 14 April 2006 (UTC)

For PC's it's almost guaranteed that a male D-25 or D-9 is a serial port, while a female DE-25 is a parallel port. The Joystick port on typical PC's was always D-15, and video the D-9 size but with 15 pins.--Bert490 05:49, 15 July 2006 (UTC)

Added a better image, I suggest the old one be removed, it's very hard to see what it is. --DuLithgow 14:10, 24 May 2006 (UTC)

You are right: can't see the pins on the old one. I removed it after transferring the DE-9 link.--Bert490 05:49, 15 July 2006 (UTC)

I added a picture of my PCI-E card but I have used that picture on 2 articles already. Towel401 22:11, 11 November 2007 (UTC)

Trying to clean this up

There is a lot of technical stuff here that sort of belongs to the RS-232 article, this article seems to have covered the role in modern personal computers fairly well, so I am tempted to move all the technical stuff over to RS-232 but keeping the 'settings' section might be useful for people trying to configure their serial port. Also there is a lot of duplicated information between the Serial port, serial cable and RS-232 article that could be gotten rid of Towel401 (talk) 22:28, 23 November 2007 (UTC)

Agree. The stuff that is actually discussed in the standard should be in the RS 232 article. Not all serial ports are RS 232! How start/stop communications works in general, and history, should be in asynchronous communication. The serial cable article ought not to exist since it overlaps RS 232, serial port, and asynchronous communications - part it out over all three and save anything that belongs. Port addresses and IRQs belong in the IBM PC article, if talking about the specific example of an IBM PC serial port. This article should be careful to distinguish between "serial ports" in general and details which are specific to one particular type, such as the IBM PC and its descendants. --Wtshymanski (talk) 22:45, 23 November 2007 (UTC)

Networking configuration

I tought it should be mentioned that this port is used for initial configuration of networking devices such as routers or switches. I don't know about all the manufacturers of this sort of product, but Cisco uses this method. —Preceding unsigned comment added by 89.37.122.102 (talk) 00:21, 9 November 2008 (UTC)

people need to watch this

there was a paragraph in the intro that basically said the opposite of the hardware section. People should not edit a article before they have read the article **GRR**.Scientus (talk) 12:16, 20 December 2008 (UTC)

75 bps

04:38, 18 September 2012‎ Jeh (talk | contribs)‎ . . (25,199 bytes) (+1)‎ . . (→‎Speed: 75 was commonly offered but never commonly used with computers, not even in the minicomputer era. 110 was commonly used with model 33 TTYs, not so much on IBM PCs and progeny but on 8-bit micros) (undo)

75 bps was in fact used on microcomputers as part of the V.23 standard (1200 bps downlink, 75 bps uplink). This was before rate adaption on modems were common, so the UART had to be able to operate "split speed". Hpa (talk) 18:02, 18 September 2012 (UTC)

Crude rate adaption was pretty common at that time, more so than split speed UARTs. Many (and I would guess most) devices used in the UK for accessing these 1200/75 services like Prestel were using 1200 on the RS232 link. Some used 300bps, as Prestel didn't need more than 1k as a page buffer, so this could be handled in the modem, for the benefit of a slow terminal.

Last time I saw 75 baud or speeds <300 was with mechanical teleprinters, modems emulating mechanical teleprinters and amateur radio RTTY services (these are down to 45 or 50 baud). That was in the '80s, so 75bps isn't entirely out of scope for this article. Andy Dingley (talk) 18:14, 18 September 2012 (UTC)

You definitely used fancier modems than I did... at least in Sweden the modems that common people could affort were simple physical layer devices. The micros on the Swedish market at least tended to support split speed, although one often had to move a jumper. Ah, the days of truly horrid user interfaces. Hpa (talk) 18:51, 18 September 2012 (UTC)

Probably "more specialised" modems, rather than "fancier". I'm talking about the 1980s, before widespread personal computers, and before PC meant PC quite so rigidly. As the modems were very specific to Prestel, and had to make it work with display devices, computers or terminals that may not support split-rate, putting more smarts into the modem wasn't so unusual. Andy Dingley (talk) 19:19, 18 September 2012 (UTC)

"Connector" infobox

After attempting to correct some of the errors here I've concluded that it just isn't useful here any more than it was at RS-232.

• EIA did not "invent" the serial port, nor the DB25 or DE9 connectors. They simply published a series of relevant standards. The article on D-sub connectors will tell you that Cannon invented them, but that isn't who invented the serial port, which was a subject of progressive development.

• Putting the picture of a DE9 in the infobox suggests that the stuff in the infobox is only about the DE9. But the article is about serial ports. The pictured connector is of course not the only connector used for serial ports. It isn't even the only connector ever used for serial ports on PCs. Is this article only about modern serial ports on PCs? If so, they certainly weren't invented in 1962.

• You could probably denote Intel as the "inventor" of the de facto standard PC serial port host-controller interface (with their 550 chip) and IBM for the port assignments, IRQ, etc., but that belies all previous usage of serial ports, and ignores all subsequent development such as the integration into "Super IO" chips, then the south bridge, and in SOC, in the CPU.

• There are serial ports on DB25 connectors with more than 9 (or even 10) active pins, and there are DE9 and DB25 connectors used for things other than async serial ports, synchronous serial being one close example. The infobox pretends that such "serial ports" don't exist.

To correctly and completely address these and similar issues in the limited entries possible in the infobox would mean altogether too many "it depends" or "variable" designations. Granted some of these issues pertain to the article as well, but those can be fixed easily as text is much more free-form. The issues with the infobox can't be fixed afaict. Accordingly, I've deleted it. Jeh (talk) 00:08, 24 December 2012 (UTC)

Thanks for being so nice and deleting everything I add, but most of your concerns have already been addressed in articles like USB - multiple manufacturers, multiple connectors (A, B, Mini A, Mini B, etc), multiple pin-outs, and YET on the USB page they managed to use an infobox then so can the serial port page. I mean if on one article, then why not on another? And being so intelligent about serial ports, why don't you improve the content instead of deleting it outright? I'm trying to bring up the "most usual" kind of data into the infobox format to keep things simple. Please help instead of simply deleting. Wikipedia is anyways meant to document the majority, so even if a small number of serial ports are wierd thats off scope and we can focus on the general case. --- Tom Jenkins ^(reply) 05:10, 24 December 2012 (UTC)

And about the designers/manufacturers, like USB, or any other interface where there were multiple, we write all of them. The DE9 connector as the main picture is fine because serial ports were usually like that, at least in modern PCs. The other connectors are noted in the infobox. I added "standard only" beside EIA to document that they only designed the standard, not the interface itself. Add anything you like -- Tom Jenkins ^(reply) 06:31, 24 December 2012 (UTC)

Also note how pins are recorded in the USB infobox "4: 1 supply, 2 data, 1 ground (pre-3.0); 9 (USB 3.0); 11 (powered USB 3.0); 5 (Micro-USB)" .. they document everything, even if it looks ugly. We can do the same for serial ports. -- Tom Jenkins ^(reply) 06:35, 24 December 2012 (UTC)

For someone who professes on your user page to have a "passion for precise and descriptive writing" you seem to be remarkably content with posting content that is full of imprecision here. (Your spelling could use attention, too.) Perhaps the infobox at USB is better because it was put together by someone who is actually well familiar with the subject? Of course it is also the case that USB was designed in a fairly short time by a small group, as opposed to the series of developments by widely separate and disparate groups that led to the modern serial port, so on the USB infobox we do not need to have things like "number of wires: Oh, anywhere from two to 25" under a picture of a 9-pin connector.

I think infoboxes are just fine on articles like those for the 50 US states, where the subject of every article they're used on has a well-defined and consistent set of properties that apply to every state, each property having a well-defined value (population, area, etc.). I don't believe that is the case for either connectors or protocols, except for the simplest possible (therefore mostly unhelpful) properties. A proper list of, for example, "invented" dates here (starting with 1952 for the DB25 connector) would leave the reader having to read the article anyway for the answer relevant to his or her query, so how did the infobox help? (And as for being helpful, the date that a long-obsolete version of the standard was first adopted is just about the least helpful date I can think of here.)

Yes, the USB infobox lists pinouts for various types of USB connector—and I personally think that's a misapplication of an infobox. Again, such data belongs in the article text or in a table. If an infobox needs much of anything more than

Property or characteristic: Single value

for more than a few of its items, then that is evidence that the entire "infobox" concept is broken for that usage.

The same applies to many of the other properties here, so I see no point in this infobox at all; practically every entry will end up with "several possible answers, depending on what you're really asking; you'll have to read the article".

Nor by the way is a serial port simply a "connector", it is much more than that, so I don't believe the "connector" infobox is appropriate here in the first place.

Accordingly it is my honest opinion that the best way to improve the article on this point is to not have this or any other infobox I can imagine. Not every article needs an infobox, and not every infobox is a good idea in the first place. And no, WP is not meant to "document the majority," it is meant to document what is verifiable.

Re my "deleting" your work, of course it is easily recoverable as you know full well. Beyond that, please note the wording at the top of the Edit page: "Work submitted to Wikipedia can be edited, used, and redistributed—by anyone..." Editing includes "deleting". If you don't want your words mercilessly changed or even deleted, then Wikipedia is the wrong place for them. Jeh (talk) 06:47, 24 December 2012 (UTC)

Many serial ports are not RS232

Whoever deleted the connector infobox yet again with the reason that "many serial ports are not RS232", if you read the article, you'll find that the ENTIRE article is pretty much talking about RS232, and so the connector infobox with RS232 information is prefectly apt.

Not to mention that 99% of the serial ports in the world are RS232, and I don't know where you are getting contrary information from. Please refrain from deleting something just because it irritates you.

There is no reason to delete the connector infobox from the USB article just because Sony Ericsson USB connectors are "not really USB standard". Same goes here on the serial port article. If most of the serial ports in the world are RS232, then its perfectly right to use an RS232 infobox. -- Tom Jenkins ^(reply) 09:40, 25 December 2012 (UTC)

First, yes, nearly all PC serial ports violate the RS232 standard in one way or another.

More generally: When there is not consensus for a change - and there certainly is not for the addition of this infobox - the article is supposed to remain in its pre-change form until consensus to adopt the change is reached. I am therefore deleting the infobox again. Please discuss your desired changes here, and with something more substantive than you have before. Jeh (talk) 12:39, 25 December 2012 (UTC)

You and the other guy that reverted it are the only members of the "consensus". As I said before, the infobox is present on the USB article, and I'm using the same philosophy to place the infobox on this article. After all, its your opinion that infoboxes are "bad" and "not perfect" on articles like USB, DESPITE the fact that the USB article has one. I'm going to revert it because you don't really have any reasons apart from the fact that "serial ports are broken", when they do function quite well in real life. After all, why would millions of devices be built for serial ports (a decade ago) if they were all "broken"?? -- Tom Jenkins ^(reply) 18:00, 25 December 2012 (UTC)

A long-standing existing form of the page is assumed to have consensus of the community; you don't simply change consensus by making a change. And when there is a dispute (as there is here) the promoter of new content is most certainly not supposed to persist in forcing your change into the article. Your brief edit comment does not answer any of the objections raised, and "other articles have it, why not this" is tantamount to the childish protest that "Johnny did it too!"

Nor did I say "infoboxes are bad", just that they aren't the right thing everywhere. Wikipedia is supposed to be more about prose than tables or lists, and when an infobox raises more questions than it answers, there's a problem.

My argument, very clearly stated above, has nothing to do with "serial ports are broken" but rather that the multi-valued nature of the "answers" in this infobox—if corrected, and we certainly don't want it to be grossly inaccurate or incomplete as it is now—would be more confusing than helpful. (And, yes, this is probably true of the one in USB and certainly true of the one you added to parallel port as well. What is your response to these points?

Since you are clearly simply going to add it back again if removed, I'm leaving it be for now (I'm not interested in edit-warring) but that does not constitute my approval of a new consensus to keep it. Jeh (talk) 21:36, 25 December 2012 (UTC)

I removed it. It's not needed. Glider87 (talk) 04:08, 26 December 2012 (UTC)

TomJenkins, you have once again added the infobox despite the evident dispute. "The USB article has one" is not a valid point (as I stated above) and you have not addressed my concerns; you simply misstated them. Jeh (talk) 21:44, 26 December 2012 (UTC)

Look, I've worked with serial ports long enough to know they follow "some semblance" of standardized and they do function pretty well indeed. Now if you're saying you are the expert or serial ports, and you have issues with the infobox, so well we're supposed to delete the infobox because you are saying its not really standardized? With all due respect show some references, some books, papers or whatever to support your point. Because a trivial search on "serial port" or "rs232" shows lots of info stating that PCs do in fact comply with some standard. If there are specific points you don't agree with, show refs regarding those and we can modify/delete the infobox points that are complicated. Just deleting the whole thing sounds a bit extreme IMHO. -- Tom Jenkins ^(reply) 04:15, 27 December 2012 (UTC)

Extreme? I'd say that your persistently adding it back in after three different editors say it's not wanted is extreme. Please review WP:BRD: "(Be) bold, Revert, Discuss". Ok, you were bold in adding the infobox. (An alternative is to discuss your proposed changes first.) Objections arose and it was reverted. Your next move should not have been to simply re-add it but rather to discuss the dispute. That isn't "extreme", that's accepted Wikipedia procedure. Perhaps you should learn more about that. But here's a key point: Not everything you contribute to Wikipedia will be accepted by the community. If you can't live with that, you probably shouldn't contribute to Wikipedia.

Now you have again ignored my argument. I never said the reason I thought the infobox was not suitable was that serial ports are not well standardized. (They're not, despite what you find in a "trivial search", but that's beside the point.) My objection is that the multivalued and vague nature of the correct "answers" for the modern serial port make the infobox useless for this article, and a simplified set of answers (such as you have provided) would be misleading. Speaking of that, I continue to be surprised that someone like you, who professes such interest in "precision" on your user page, would not just add such misleading material to an article but then so vigorously defend it. Jeh (talk) 04:54, 27 December 2012 (UTC)

Reverted "History" section

I just reverted a "History" section that was recently added by Ray Van De Walker (talk · contribs). Here's why.

The serial port was originally included on personal computers in order to drive 
modems, printers and miscellaneous equipment 
such as paper-tape punches and readers. 

Serial ports were originally included to attach to teleprinters, often the Teletype ASR33. The original personal computers did not have anything like the modern concept of a full-frame video display and dedicated keyboard port, serial video display terminals were very expensive, and the ASR33 got you a (slow) paper tape and reader along with the keyboard and printer. When dedicated printers showed up in the early home computer market they generally used parallel ports, not serial, as parallel ports were significantly cheaper (not needing a UART). Punched tape readers and punches (except for those attached to the ASR33, which did not require an additional port beyond that used by the ASR33) also generally used parallel ports, not serial. They're inherently parallel devices after all.

Much of the historic confusion in regard to the serial port(s) on a PC concern 
whether the port is being used as if it were a teleprinter (i.e. to attach the 
PC to a modem), or as if it were a modem, communicating to a teleprinter (i.e. 
to a printer).

Even when you connect to a printer your serial port is still "being used as if it were" what you're calling a teleprinter, or as RS-232 calls it, a DTE. Citation is needed for claims of "historic confusion" and why such confusion existed.

The RS232 interface was designed to attach teleprinters to modems. 
Since teleprinters were derived directly from Telex machines, which in turn were 
developed from telegraphs, serial ports have many features that resemble
historic telegraph lines.  

One, a Telex machine is a teleprinter. "Telex" was simply the name of a particular message exchange network that used teleprinters; the same or similar teleprinters were used on the competing TWX network. Two, "resembling historic telegraph" lines is not even close to correct. Teleprinters of the pre-personal computing era were almost exclusively current loop devices, not RS-232, and there were no control signals. Historic telegraph lines used a simple DC source, neither current loop nor bipolar voltage-driven.

For example, the "space" state is +12 Volts, and the "mark"
state is any voltage below +3 Volts. 

Actually in RS-232 the spec calls for -3 through -15 as mark and +3 through +15 as space, with the range from +3 to -3 "undefined." RS-232 transmitters are supposed to assert voltages in slightly narrower ranges. On teleprinter circuits, mark and space were denoted by the presence and absence of current, respectively... so electrically, RS-232 really doesn't resemble a teleprinter circuit.

This feature means that an idle serial port has to be powered.  If it is unpowered, 
near ground, it is not functioning, and attached equipment can detect that fact. 
(The feature is called "break detection" because it literally detects broken wires.)

This is not really historical information, but anyway... unfortunately, most (I'd say "all" but I obviously have not looked at every type ever made) current and recent RS-232 receivers do not emit a signal that uniquely identifies the "near ground" (undefined) condition (between -3 and +3). It would certainly be possible to design an RS-232 line receiver that could do that, but they don't. Now... if your assumption of "any voltage below +3 is mark" were correct, this would not permit break detection, because a disconnected line would be seen as continuous "marking", which would be indistinguishable from a connected but idle line (a stop bit of infinite length, with no start bit ever seen). To permit break detection, the "undefined" range -3 to +3 must be reported by the receiver as space, not mark. Then (assuming we're talking about an async serial data input pin) an unconnected pin is detected as a framing error (a start bit with no stop bit within the character time) by the UART.

In sum... It is clear from the number of errors that you cannot have used reliable sources for this material. If you want to add historical information (or any other information), please find some WP:RS and work from those - and reference them in your text. Thank you. Jeh (talk) 05:39, 22 October 2013 (UTC)

Disputed addition: "Hard drive serial interface" links

98.208.32.105 (talk · contribs) added this bullet item to the "Common applications for serial ports" section:

• IDE hard drive [1] [2] repair [3] [4]

Originally this was added with the misleading comment "serial ATA". Thinking that the IP had confused "serial port" with "serial ATA", I reverted with the comment "SATA has nothing to do with the serial port described here". The IP reinstated with the comment "the hard drive serial terminal interface has little to do with SATA". (Yes, redlinked, which should have told him or her something.)

What we have here are four links that do have something to do with serial ports being used in some manner relating to hard drives. My first comment is that the presence of such an item in a list in this section would lead anyone not familiar with the subject to believe that these links are describing a hard drive interfaced through a serial port, and that this was furthermore a common use for serial ports, or perhaps a common way to interface a hard drive... as is indicated by the section title.

Reality, however, is different:

• Hard drives are, of course, not commonly interfaced through serial ports.
• The first link is describing an experimenter's project interfacing an "IDE" hard drive to a homebrew (perfboard) 8051 microcontroller. Note that the interface to the drive is via the hard drive's standard parallel ATA connector, via an 82C55 interface chip; there is no evidence of a "hard drive serial terminal interface". The 82C55 is decidedly not a serial interface, but rather provides a parallel interface to 24 pins. Yes, there is a serial interface on the 8051 board but it has nothing directly to do with the interface to the hard drive. Based on the description it appears to be used to give commands to and get responses from a program running on the 8051.
• The second link describes how to program an "IDE" hard drive via the usual parallel ATA interface. The author does show a home-built "controller card" that allows experimental manipulation of the drive. Still, the drive is interfaced via its Parallel ATA connector, not serial. If this is "serial interface to a hard drive," then using a computer with an ATA hard drive, a PS/2 mouse and keyboard, and a VGA video interface is by analogy a "PS/2 and VGA interface to a hard drive." Yes, you can (by typing or mouse-clicking) get a program running on the computer to cause the disk to read and write data, but that does not mean the disk drive is interfaced via an RS-232 serial port, nor even that the actual data from the drive will necessarily be available on the RS-232 port.
• The third and fourth links do use a serial port to interface to a hard drive... not to its primary interface, but to its debug or maintenance port. They describe how to use this technique to reset a particular error condition that occurs on one particular make and model of Parallel ATA drive. An RS-232 to TTL level translator is required, and one of the two sets of instructions also requires partial disassembly of the drive! Note that the disk drive in question still transfers data over its parallel ATA connector.

Absolutely none of these homebrew projects can be considered "common" uses, which is the subject of this section. WP:FRINGE and WP:UNDUE apply. In addition the pages linked appear to be self-published, i.e. not reliable sources.

The first two examples are IMO not supportable in any form: The drives in the examples are interfaced via their parallel ATA connectors, despite the presence of a serial port "command and response" interface somewhere in the project. Really this is not much different from using any computer that has a hard drive as well as a serial port for a CLI console device.

However I would support the addition of another section immediately following this one, titled something like "Development, debug, and maintenance ports". The latter two links could go in a list item there ("ATA drive maintenance ports"), along with some of the items now in the "common" section that are really not all that common, such as firmware updates to routers (almost always done over an Ethernet connection now) and debugging connections. Use of JTAG, ICSP, and similar ports could also appear in the list of examples in that section. While we're at it we might want to identify the "once, but no longer, common" uses appearing in the list and move them to a separate list, so identified. Jeh (talk) 08:08, 23 October 2013 (UTC)

In fact the redlink was meant to indicate the previous comment was not to be taken literally, in a less subtle manner so that the next editor might stop to check the external links instead of reverting. I have a Seagate drive that I need to recover data from; I knew the serial interface existed, but didn't know its capabilities (a very slow transfer might be better than nothing). Finding useful information about controlling a hard drive over a serial port is very difficult, since:

• Google cannot simply be told "this use of serial with hard drive refers only to the serial port, not to serial ATA"
• some people only want to operate a custom hard drive controller via serial port, as in the first two links
• the details of the TX/RX interface vary by manufacturer, and are generally not disclosed
• although some Seagate drives (probably their newer SATA drives) offer a fairly rich serial interface, attempting to use it is very likely to cause severe, irreparable damage

It seems worth noting on Wikipedia, at least in passing, that the serial port has applications regarding hard drives, and can even interface with them directly in some circumstances. A section on general maintenance uses could address this well. 98.208.32.105 (talk) 01:19, 24 October 2013 (UTC)

"Next editor might stop to check the external links"—I did check the links and neither had anything to do with "serial ATA", which was the entirety of your first edit comment. You can hardly blame anyone for thinking you meant the interface commonly known as "SATA" when you wrote "serial ATA".

"Interface with them directly" is very much stretching a point. Your first two links describe homebrew projects; these show that considerable hardware (well beyond a simple connector adapter, for example) must be built to make a bridge between a serial port and a hard drive... and that such hardware does not commonly exist, so it must be homebuilt and custom firmware written to run it. So this is hardly a matter of "interfacing directly." (And btw, such a device would not be able to read or write anything that your computer can't already access on the drive via a regular PATA interface.)

By way of contrast, there have been commercial products of hard drive interfaces that work from parallel ports. Adaptec even made a parallel port to SCSI(-1) adapter; I used to own a couple, and the Parallel port article mentions them. But a homebrew project doesn't qualify... at least that is my opinion. We do have guidelines about what should and shouldn't be included in WP, particularly in regards to external links. "It's useful" or "a few other people might want to know about it" or even "it took me a long time to find it" just aren't sufficient. Those links also fail WP:ELNO item 11.

As stated above, I do think the service interface merits inclusion, as it is something the drive comes with and is on a par with JTAG, etc. Your links on that point also fail WP:ELNO item 11, but it will probably be possible to find a WP:RS for this. Jeh (talk) 07:24, 24 October 2013 (UTC)

Standard for use of male vs. female connectors - EIA-574

This page doesn't cover the conventions for male and female connectors as used on DTE and DCE. While there is considerable variability, there is also the EIA-574 standard. There is a page on the EIA standards but the link for 574 redirects to the RS232 page which then links back to this page saying "See serial port (pinouts) for non-standard variations including the popular DE-9 connector.". The standard is "DCE devices should have a female DB-9 connector, and DTE devices should have a male DB-9 connector." according to this commercial page. — Preceding unsigned comment added by GeorgeDishman (talk • contribs) 10:26, 28 January 2014 (UTC)

Hello George, at 2016-04-03 the digi.com link gives "page error". DB-9 is a 25 pin shell with 9 pins installed. Correct? Regards, PeterEasthope (talk) 23:28, 3 April 2016 (UTC)

Huh? In the "Male and female" section here appears: "Usually, if a DE-9 or DE-25 connectors is male, it is likely to be a DTE, but if it is female, it is likely to be a DCE." This is also mentioned at RS-232. The "is it DB-9 or DE-9" issue has been discussed before. See the talk page archives at D-subminiature. Briefly: The original manufacturer, Cannon, used different letters to refer to different shell sizes. Their term is DE-9. We do note in that article that they're sometimes called DB-9. Jeh (talk) 01:31, 4 April 2016 (UTC)

Motherboards with Internal Serial Ports rather than ones showing from the back.

What are these ports specifically called? I used to have a picture that showed an adapter for these as well, but lost it after I reformatted my computer. basically, the conenctor on the motherboard was a thin strip of pins, which were connected to a PCI bracket looking serial port (one with an OUT and IN connector.) The connection to the PCI bracket looked like scsi tape to be honest. 71.87.114.122 (talk) 09:43, 29 September 2010 (UTC)

What you're calling "SCSI tape" is flat cable, used for a great many things besides serial ports and (parallel) SCSI. It's also used for legacy parallel ports, floppy interfaces, Parallel ATA, etc. The connector on the motherboard is simply called a "header," or sometimes "header pins." Although there are commonly-used pinouts for these for serial ports (such that just clamping insulation displacement connectors on the cable, one mating with the header and the other the DE-9, will give the right results) there is no formal standard for them. otoh, there ARE formal standards for the headers for the headers for the floppy and Parallel ATA interfaces. And... now that I have sinned along with you, I will mention that the talk page is for discussing improvements to the article, rather than general discussion of the article topic. :) Jeh (talk) 11:20, 29 September 2010 (UTC)

Sometimes discussions of the topic in talk pages are useful for deciding what should, and should not, go in to the article. I try not to worry too much about it. Gah4 (talk) 21:46, 18 October 2016 (UTC)

combine with serial communications

Please see the discussion at serial communications on whether these two pages should be combined. Fpahl 14:56, 14 Sep 2004 (UTC)

serial communications discusses the more general case, and so should be kept separate. It might be that some parts should be moved to keep the distinction. Gah4 (talk) 23:26, 18 October 2016 (UTC)

Line disciplines

Can anyone tell me what is meant by line discipline? Maybe this can be reworked into the article? —The preceding unsigned comment was added by Bvankuik (talk • contribs) 04:42, 23 February 2006 (UTC).

A "line discipline" is a concept on many Unix-like systems. On a serial port, or something such as a pseudo terminal or the system console of a personal computer or workstation, there's a low-level driver that controls the hardware (for a serial port) or the other entity (for a pseudo-terminal or console), which supplies a sequence of bytes received from the port or device and accpets a sequence of bytes to be sent to the port or device; it doesn't do any formatting, line-editing (erase, kill, etc. characters), and so on. A "line discipline" module can be installed on that device; it's another piece of operating system kernel code that implements formatting (converting line feed to carriage return/line feed on output, expanding tabs, etc.), and input processing (converting carriage return to line feed on input, line-editing, etc.) for the standard "tty" line discipline, and that can implement other things if the serial port isn't being used for a terminal. For example, on older Sun workstations, the keyboard and mouse were attached to serial ports, and a special line discipline was used to implement the protocols the keyboard and mouse used, and SLIP and the Point-to-Point Protocol (PPP) are often implemented as line disciplines if they're being run on a serial port.

Some systems, such as derivatives of UNIX System V, use pushable STREAMS modules rather than line disciplines for this purpose.

This information doesn't belong in this article, as it's a software concept specific to a particular family of operating systems. Guy Harris 00:38, 12 October 2006 (UTC)

That isn't what I first thought of for line discipline. There are signals other than the data lines that are part of RS-232, and similar standards. Some of those relate to handshaking on half duplex lines, systems that are not commonly used today, but were when the standards were made. DCD is allows for systems to detect when the remote end hangs up on a dial-up line, to automatically log them out. RTS and CTS allow for true half-duplex communications, where data can only flow one direction at a time. The modems have to arbitrate this, and RTS/CTS allow the hosts to control and follow it. There are some other related signals which I have forgotten by now. Gah4 (talk) 23:31, 18 October 2016 (UTC)

Half of a bit?

Can anybody extend the section "Stop bits" under "Configuration" to explain how the one-and-a-half of a bit works? Thanks in advance, 194.28.49.131 (talk) 10:39, 16 July 2013 (UTC)

Simple: the transmitter holds the marking condition for at least 1.5 bit times before starting the next character, i.e. before starting a start bit. Even with more conventional 1 or 2 stop bits the actual "stop bit time" doesn't have to be an integral number of bit times. The next character frame (that is, the next start bit) can begin (i.e. the line can go to the spacing condition) at any time after the required number of stop bit times. So you might see 1.7, 2.3, or 3.14159 stop bits, depending on how busy the code is that's driving the transmitter. The receiver doesn't care. To the receiver a deliberate 1.5 stop bits is no different than one stop bit, but with a sender that needed an extra half a bit time to start sending the next character. Jeh (talk) 04:28, 22 October 2013 (UTC) (added material Jeh (talk) 22:40, 18 October 2016 (UTC) )

More specifically, for asynchronous communication in general, the receiver has to use a clock that is some multiple of the bit rate to accurately time the beginning of the incoming character. Common is 16 times, though some do 64. The receiver detects the transition at the beginning of the start bit, waits half a bit time, verifies the start bit (and not noise), then latches the bit value in the center of each data bit. That allows for variation in the clock rate between devices. (Synchronous communication does't have this requirement.) The stop bit is needed to allow for a new transition at the next start bit. I still find this amazing, but early serial devices mechanically encoded and decoded the data, using electromagnetic clutches and rotating machinery. Some added delay is needed to allow the mechanics to reset for the next character. As far as I know, electronic receivers can always accept input with one stop bit. Transmitters will generate whatever they are programmed to generate. Anything greater than one bit time is just additional delay between characters. Gah4 (talk) 22:04, 18 October 2016 (UTC)

Right, although it would be possible for an electronic receiver to enforce two stop bits and signal a framing error if it only saw one, I don't think anyone actually did that.

And a "break" is just holding the line at the spacing condition for more than a character time. We normally used two character times.

Yep, teletypewriters (up to the ASR35 and ASR38) were electromechanical. If you think that's amazing, look up what a Selectric (also electromechanical) goes through for every typed character. btw the Selectric-based IBM 2741 and IBM 1050 terminals spec'd 1.5 stop bits for their serial comms, at a total bit rate of 134.5 b/s. The extra half a stop bit was needed to give the machine time to complete a print cycle, and the overall rate (about 14.1 char/s) was chosen to match the machine's cycle time, so that the main clutch could be kept engaged continuously. This is why this bit rate and stop bit setting were available in many computer manufacturers' serial port hardware. (I never actually saw a VMS machine with a 2741 attached, but it could have been!) Jeh (talk) 22:40, 18 October 2016 (UTC)

Yes, I was using 2741s years before I saw an ASR-33. I always thought that the 2741 electrically timed its bits, but the connection to the printing unit is electromechanical. Also, the 2741 locks the keyboard so you can't type when the computer is typing. That would really mess things up. Most UARTs sense framing error if the input isn't zero (space) for the stop bit. That is usually used for the break signal on systems that use one. Some terminal time it, others send it as long as you hold the button down. Gah4 (talk) 23:56, 18 October 2016 (UTC)

Multi-topic first section

Moving stuff here, needs work. I get the impression that the FOLDOC material mentions the PC as a special case, and at any rate USB / Firewire are the current standards.

---

Usually, the expression "serial port" refers to the old PC "serial port" used for mice. (what's the proper name for this?)

connected to peripherals which communicate using a serial (bit-stream) protocol. The most common type of serial port is a 25-pin D-type connector carrying EIA-232 signals. Smaller connectors (e.g. 9-pin D-type) carrying a subset of EIA-232 are often used on personal computers. The serial port is usually connected to an integrated circuit called a UART which handles the conversion between serial and parallel data.

The serial port can be used to connect terminals (VDUs or teletypewriters, TTYs), printers, modems and other serial peripherals. Two computers can also be connected together directly via their serial ports. — Preceding unsigned comment added by Tarquin (talk • contribs) 23:17, 7 October 2002 (UTC)

Picture with a numbered pins

Suggestion, one can add more information on this article by replacing the current pictures with one that have numbered pins —The preceding unsigned comment was added by Wk muriithi (talk • contribs) 10:55, 27 January 2007 (UTC).

That's something that should be handled in D-subminiature. Doesn't look like it is. ~Kvng (talk) 20:15, 10 May 2020 (UTC)

"Byte" versus "Word"

It is my humble view that it would be more appropriate to refer to the smallest unit of data as "word" rather than "byte", as bytes intuitively indicates the smallest data unit in computers, which can be individually addressed and which typically has a fixed size for a specific computer setup, whereas "word" sets it aside for data communication devices, where the smallest data unit may assume different sizes for different communiaction sessions. Alan Turing 13:02, 7 March 2007 (UTC).

We describe serial ports as character based and in Serial_port#Data_bits assert that 8 bits, a byte, is the most frequently used character size and proceed to talk about bytes from there on. This is not a fully pedantic approach but I think it works. ~Kvng (talk) 20:38, 10 May 2020 (UTC)

DTE and DCE acronyms not explained

The acronyms DTE and DCE are first used in the section titles "connectors". They are not explained. What do they mean? —Preceding unsigned comment added by 213.224.27.206 (talk) 11:37, 5 April 2011 (UTC)

DTE (data terminal equipment) and DCE (data communications equipment) go back to the earlier days of serial communication. There were terminals, and modems to connect them to, and the pinouts are designed for straight though connection. It was only later that the idea of connection DTE (terminals) to DTE (computers) came up, and all the problems arose. Modems are pretty reliably DCE. Just about everything else is pretty reliably DTE, but it is worth checking to be sure. A null modem swaps the appropriate lines to connect DTE to DTE. Gah4 (talk) 23:41, 18 October 2016 (UTC)

We have acronym definitions and links to Data terminal equipment and Data circuit-terminating equipment in Serial_port#DTE_and_DCE so I think we're good now. ~Kvng (talk) 20:38, 10 May 2020 (UTC)

Bad link

I'd just like to point out the the link for D-Type connector in the Connectors section goes here (http://wiki.riteme.site/wiki/D-subminiature) I was hoping for a page on the D-type connector. :o\ I'd have a go at linking to the right page but I'm not sure if I know how to find it.

Kotch5 (talk) 16:38, 12 January 2012 (UTC)

The link does go to the article that describes the connector traditionally used for serial ports (D-subminiature) and that article is correctly named. I don't know of any other sort of connector that would be called "D-Type". If anything the text in the article should be changed from "D-Type" to "D-subminiature". What kind of connector do you think "D-type" refers to, if not a "D-subminiature"? Jeh (talk) 17:51, 12 January 2012 (UTC)

I have edited to use D-subminiature throughout. ~Kvng (talk) 20:38, 10 May 2020 (UTC)

Yost issues

I have noticed that there may be a couple of errors (before the edits I made) in the pinouts.

• The claim that Cisco uses Yost seems to be partially contradicted by [5] - specifically the CTS/RTS pinout seems to be reversed versus Yost.
• The Yost pinout given seems to be the DCE pinout, not the DTE pinout, per [6], but I don't know enough about Yost to know if that is relevant.

Hpa (talk) 19:29, 4 February 2012 (UTC)

I have added [7] as a reference to the pinout table. The table appears to match now. ~Kvng (talk) 20:38, 10 May 2020 (UTC)

Signal descriptions weak

The article does not adequately describe in detail what the various signals do and their levels. TxD, RTS, etc, what do they do? Logic levels? Wire voltage levels? For example, CTS, Clear To Send, means what when its high, what when its low? — Preceding unsigned comment added by 174.48.68.93 (talk) 16:34, 20 March 2016 (UTC)

Hmmm. I suspect that those should be in the RS-232 article, but maybe they aren't there. Gah4 (talk) 23:59, 18 October 2016 (UTC)

Is RS-232#Data_and_control_signals good enough? ~Kvng (talk) 17:37, 11 May 2020 (UTC)