Talk:Serial Ports

From OSDev.wiki
Latest comment: 15 years ago by Troy martin in topic Category
Jump to navigation Jump to search

Detection

This section needs details on exactly how to detect serial ports using legacy device techniques. It also doesn't mention IRG 3/4, if im not mistaken... do these not report incoming data or is that a BIOS thing? --Tyler 06:51, 9 January 2007 (CST)

Baud rate

I'm not SerialPorts guru, but bauds is usually symbols per second on the wire, and afaik, each symbol on a RS-232 line will only carry 1 bit, so the baud rate (here) is more likely to be the bitrate than the byte-per-second speed ... note however than modems typically send many bits per baud (because you may have more than 2 waveforms used), but not necessarily 8 of them ... Someone should check the specs and confirm/correct. - PypeClicker (copy from osfaq - Combuster 04:05, 20 January 2007 (CST))

Pages to convert

PLEASE mark the page as converted next time, you had me do almost everything a second time. - Combuster 04:40, 20 January 2007 (CST)

Category

This page current only has one category - network hardware... The page doesn't just cover networking with serial ports though. Suggest adding another relevant category? --pcmattman 03:36, 4 April 2009 (UTC)Reply

I added it to Common Devices. --Troy Martin 16:35, 4 April 2009 (UTC)Reply

Sending Data Example

Under the "Example Code" section, under "Sending Data," it has return inb(PORT + 5) & 0x20; as the body for is_transmit_empty - is that meant to be return inb(PORT + 5) & 0x2;? --Retrocat 21:29, 26 May 2018 (CDT)

Should the article be updated to be a little more generalised?

Should this article be updated to provide a more general view of serial/uart communication hardware? It seems to be very x86-centric and doesn't provide a very generalised view of the topic. For my personal perspective, I've put in a little more time working with UART communication in embedded systems than with serial ports in X86 systems, but I've created simple 8250 compatible drivers before. 'uart' redirects to this article, should it not be the other way around? It doesn't tell the reader much about what specific kind of controller hardware that x86 uses or where to find datasheets for it. My suggestions specifically is just that the wording be changed slightly to reflect that the article deals specifically with the 8250/16550 UART on x86 systems. I think this would be helpful not only because it is more technically correct, but because it will encourage the reader to think in the correct terms: That what they are doing is writing a driver for a specific piece of hardware. I'm happy to make the changes myself if anyone agrees. --Ajxs 04:00, 27 August 2019 (CDT)

+1, although "changed slightly" may not be the best way. This page starts out covering serial ports in general, but then gets 8250-specific, and then x86 specific. Instead, it should be three separate pages - I was going to do precisely this, especially 1) below, but then it got all too big:

  1. Serial ports in general:
    1. What a serial port is for;
    2. Synchronous vs Asynchronous;
    3. Common standards, including RS-232, RS-422 and RS-485.
  2. The 8250/16450/16550/16650/16x60 UARTs:
    1. The various registers (some hat-tip to x86 port convention is appropriate here);
    2. The FIFOs in the later versions
  3. The standard COM ports on the x86
    1. Their conventional port assignments
    2. When the PIC should get the EOI

--John Burger 22:04, 26 August 2019 (CDT)

As stated above, I'd be happy to help. Perhaps we could divide the work among ourselves.
I'd be happy to begin work on a generalised 'uart' page if you think that would be a helpful place to start. You seem very knowledgeable on the subject, if you could suggest any points to be sure that I addressed that would be appreciated. I think that a 'uart' page should address the basic concept of what a UART is. I feel addressing the topic within the context of hardware would be a good place to start. Then providing some helpful practical information on how this relates to x86 osdev. --Ajxs 04:00, 27 August 2019 (CDT)
By all means. To that end, I've started a page called "Communications". I envisage this to be a "Level 0" page used to descend down the complex hierarchy of communications standards. We can link the "Serial Ports" and "UART" pages to this. I'll be writing a more general "Serial Port" page soon. --John Burger 00:42, 28 August 2019 (CDT)
I've written a draft UART page, which can be found here User:Ajxs/uart. Any review would be appreciated. I've decided not to include any specific programming information, preferring to introduce more specific articles related to programming an individual implementation. Currently I haven't done any such introduction, simply linked to this article in the 'related articles' section. If you're happy with this, I'll move this to the UART page. --Ajxs 00:44, 31 August 2019 (CDT)
A concise summary of the topic. By all means submit it! --John Burger 07:23, 2 September 2019 (CDT)
Thank you! Done! From here I'll try and formulate a good way to rewrite the programming parts of this page to introduce the 16550 specifically. I'll make any edits in a personal page to allow for more possibility of review. Thanks again from another Australian osdever! --Ajxs 07:35, 2 September 2019 (CDT)

Modem control register use in initialization code

The initialization code provided sets the RTS and DSR bits in the Modem control register. Is there any significance of this to the article? The article does not go into any detail about modem control, so this could potentially be removed. The comment also suggests: "IRQs enabled, RTS/DSR set". From reading the 16550D datasheet, none of the bits in the modem control register seem to correspond to IRQ generation. Can this line be removed? It seems pretty harmless but it looks like it's been copied from a different context, and risks being blindly copied into others. --Ajxs 22:48, 4 October 2019 (CDT)