Configuring serial port

[dream21]

I am trying to configure serial port for my small kernel. I read all the details about the configuration of UART from this http://retired.beyondlogic.org/serial/serial.htm#14 tutorial but I am a bit confused. The tutorial does not tell you what are the default values that should be set to have a working serial port. I have looked at some code like this one

Code: Select all

	outportb(device + 1, 0x00);
	                                outportb(device + 3, 0x80); /* Enable divisor mode */
	                                outportb(device + 0, 0x03); /* Div Low:  03 Set the port to 38400 bps */
	                                outportb(device + 1, 0x00); /* Div High: 00 */
	                                outportb(device + 3, 0x03);
	                                outportb(device + 2, 0xC7);
	                                outportb(device + 4, 0x0B); 

Then from our linux kernel we get different values that are set.

What I mean to say is that is there any predefined protocol to set these values. Does the sequence matters in setting of values?

[Brendan]

Hi,

What I mean to say is that is there any predefined protocol to set these values.

There is no "standard default" that applies to all things that could be connected to a serial port.

More specifically; there are a large number of different things that may be attached to the serial port (serial mouse, fax modem, dumb terminal, ....) and every different thing is different; where differences are not limited to the protocol (baud rate, number of stop bits, parity, etc) itself but also include how (and if) flow control is done and how (and if) things like the RTS, CTS and DTR lines are used.

There is also no standard way to determine what kind of device is attached or if any device is attached (see note below).

The user has to tell the OS what is attached so it can start the driver for whatever the user thinks the attached device is, and that driver may know the correct protocol (and other details) or it may not (and user might have to tell the driver which protocol, etc).

Note: Originally nothing in a PC supported any kind of device auto-detection or auto-configuration (the end user had to tell the OS everything about the hardware). One piece at a time (possibly starting with IDE/ATA hard drives in the 1980s?) support for device auto-detection and/or auto-configuration was added; but it was an extremely slow process that took a few decades, mostly because it was a cultural change (e.g. breaking hardware manufacturer's established habits). In the 1990s Microsoft attempted to standardise device auto-detection and auto-configuration (to minimise or avoid end-user hassle) for hardware that was taking too long, via. a series of "Plug and Play" specifications (most people think "Plug an Play" was for ISA cards and don't realise that there were also specifications for things like devices attached to serial ports and parallel ports). Almost all of Microsoft's Plug and Play standards were "too little, too late" - by the time hardware manufacturers started to implement any of it the hardware itself became obsolete (replaced by things like PCI, USB, etc that were designed to support device auto-detection and auto-configuration from their beginnings); so very little hardware ever existed that actually supported any of Microsoft's Plug and Play standards. For reference; for devices attached to serial ports, Microsoft's Plug and Play specification was the "Plug and Play External COM Device Specification".

Does the sequence matters in setting of values?

No - you can mostly configure the serial port's registers in any order you like; as long as you don't enable any of its IRQs before you have an IRQ handler.


Cheers,

Brendan

[dream21]

Thanks a lot Brendan I am getting familiar with the concepts. Another question that arises in my mind is this piece of code

Code: Select all

inb(device + 5) & 0x20;

What is this XMTRDY flag and how it is able to send characters to serial port?

[Brendan]

Hi,

Thanks a lot Brendan I am getting familiar with the concepts. Another question that arises in my mind is this piece of code

Code: Select all

inb(device + 5) & 0x20;

What is this XMTRDY flag and how it is able to send characters to serial port?

From one of the many datasheets (a "PC16550D UART" datasheet):

"Bit 5 This bit is the Transmitter Holding Register Empty (THRE) indicator. Bit 5 indicates that the UART is ready to accept a new character for transmission. In addition this bit causes the UART to issue an interrupt to the CPU when the Transmit Holding Register Empty Interrupt enable is set high. The THRE bit is set to a logic 1 when a character is transferred from the Transmitter Holding Register into the Transmitter Shift Register. The bit is reset to logic 0 concurrently with the loading of the Transmitter Holding Register by the CPU. In the FIFO mode this bit is set when the XMIT FIFO is empty it is cleared when at least 1 byte is written to the XMIT FIFO."

Note that for normal operation you shouldn't need to care about this flag - your IRQ handler would use the "Interrupt identification register" to determine that the IRQ was caused by "transmitter holding register empty" (and then move a byte from your much larger buffer in RAM into the "transmitter holding register").

However; during initialisation your device driver should probably enable "loopback mode" and make sure that bytes you send match bytes you receive (to determine if the chip actually exists, and/or if the chip is faulty). If this is done before you setup/install an IRQ handler then you will need to poll the "Transmitter Holding Register Empty (THRE) indicator" flag.


Cheers,

Brendan

[dream21]

Thanks a lot Brendan. I think this should be on OsDev wiki. Do mind adding it?

[Brendan]

Hi,

Thanks a lot Brendan. I think this should be on OsDev wiki. Do mind adding it?

That wiki page needs to be split into one page for "serial communications" (the physical connectors, wires, pins, etc), one page for each category of "serial controller chip/UART" (e.g. one page for the 8250/16550 family, another page for USB to serial converters, another page for PL11 on ARM, etc), then a page for each common "end point type" (serial mouse, TTY/terminal, various UPS protocols, ...).

For the page for the 8250/16550 family, the wiki is missing lots of information; including warnings/advice on ISA IRQ sharing, the differences between different chips within the family (with/without FIFO, various bugs), how to detect and test the chips (including its features and bugs), how to use it properly (including "IRQ and not polling", and possibly some information on how to use "DMA mode" in more recent Intel Quark SoCs), etc.

I'm more of a "either do it right, or don't do it" kind of guy; and I'd rather wait until I'm re-acquainting myself with things I've forgotten for other reasons (e.g. until I'm writing serial port drivers anyway).

Fortunately; it's a wiki - you (or anyone else) can make a few changes/additions at any time.


Cheers,

Brendan

[dream21]

For the page for the 8250/16550 family, the wiki is missing lots of information; including warnings/advice on ISA IRQ sharing, the differences between different chips within the family (with/without FIFO, various bugs), how to detect and test the chips (including its features and bugs), how to use it properly (including "IRQ and not polling", and possibly some information on how to use "DMA mode" in more recent Intel Quark SoCs), etc.

I got your point and it's a wiki after all