v2.24 February 2006
This document describes the UART serial port features other than those which should be covered by Modem−HOWTO, PPP−HOWTO, Serial−Programming−HOWTO, or Text−Terminal−HOWTO. It lists info on multiport serial cards. It contains technical info about the serial port itself in more detail than found in the above HOWTOs and should be best for troubleshooting when the problem is the serial port itself. If you are dealing with a Modem, PPP (used for Internet access on a phone line), or a Text−Terminal, those HOWTOs should be consulted first.
Serial HOWTO
17. Troubleshooting
22. Other Serial Devices (not async EIA−232)
23. Other Sources of Information
24. Appendix A: Obsolete Hardware/Software
1. Introduction
This HOWTO covers basic info on the Serial Port and multiport serial cards. It contains much more information in it than most people need to know and most people are able to use the serial port without reading this HOWTO. But if you're having problems or just want to understand how it works, this is one place to find out about it.
This HOWTO is about the slow original serial port which uses a UART chip and is sometimes called a "UART serial port" to differentiate it from the newer types of serial devices: Universal Serial Bus or Firewire. Information specific to devices which use serial ports: modems, text−terminals, infrared devices, and a few printers are found in Modem−HOWTO, Text−Terminal−HOWTO, Infrared−HOWTO, and Printing−HOWTO. Info on getty (the program that runs the login process or the like) has been also moved to other HOWTOs since mgetty and uugetty are best for modems while agetty is best for text−terminals. If you are dealing with a modem, text terminal, infrared device, or printer, then you may not need to consult this HOWTO. But if you are using the serial port for some other device, using a multiport serial card, trouble−shooting the serial port itself, or want to understand more technical details of the serial port, then you may want to use this HOWTO as well as some of the other HOWTOs. (See Related HOWTO's ) This HOWTO lists info on various multiport serial cards. This HOWTO addresses Linux running on PCs (ISA and/or PCI buses), although it might be valid for other architectures.
22. Other Serial Devices (not async EIA−232)
1.1 Copyright, Disclaimer, & Credits
Copyright
Copyright (c) 1993−1997 by Greg Hankins, (c) 1998−2005 by David S. Lawyer mailto:dave@lafn.org
Please freely copy and distribute (sell or give away) this document in any format. Send any corrections and comments to the document maintainer. You may create a derivative work and distribute it provided that you:
If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.
Disclaimer
While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally responsible for any errors.
Trademarks.
Any brand names (starts with a capital letter such as MS Windows) should be assumed to be a trademark). Such trademarks belong to their respective owners.
Credits
Most of the original Serial−HOWTO was written by Greg Hankins. mailto:gregh@twoguys.org He also rewrote many contributions by others in order to maintain continuity in the writing style and flow. He wrote: ``Thanks to everyone who has contributed or commented, the list of people has gotten too long to list (somewhere over one hundred). Special thanks to Ted Ts'o for answering questions about the serial drivers.'' Approximately half of v2.00 was from Greg Hankins HOWTO and the other half were additions by David Lawyer. Ted Ts'o has continued to be helpful. In Jan. 2006 "Charles Brockman" reviewed it for typos which resulted in many typos being fixed.
1.2 New Versions of this Serial−HOWTO
New versions of the Serial−HOWTO will be available to browse and/or download at LDP mirror sites. For a list of mirror sites see: http://www.tldp.org/mirrors.html . Various formats are available. If you only want to quickly check the date of the latest version look at http://www.tldp.org/HOWTO/Serial−HOWTO.html and compare it to this version: v2.24 February 2006 .
1.1 Copyright, Disclaimer, & Credits
For a full revision history going back to the time I started maintaining this HOWTO, see the source file (in linuxdoc format) at http://www.ibiblio.org/pub/linux/docs/HOWTO/other−formats/sgml/Serial−HOWTO.sgml.gz .
1.4 Related HOWTO's re the Serial Port
Modems, Text−Terminals, some printers, and other peripherals often use the serial port. Get these HOWTOs from the nearest mirror site as explained above.
1.5 Feedback
Please send me any suggestions, or additional material. Tell me what you don't understand, or what could be clearer. You can reach me via email at mailto:dave@lafn.org .
The conventional serial port (not the newer USB port, or Firewire port) is a very old I/O (Input/Output) port. Most Desktop PC's have them. For laptops, they're not likely to be present on newer models. Macs (Apple Computer) after mid−1998 only have the USB port. However, it's possible, to put a conventional serial port device on the USB bus which is on all modern PCs (including laptops and Macs).
Each serial port has a "file" associated with it in the /dev directory. It isn't really a file but it seems like one. For example, /dev/ttyS0 (or /dev/tts/0 for the Device File System). Other serial ports are /dev/ttyS1,
1.3 New in Recent Versions
/dev/ttyS2, etc. But ports on the USB bus, multiport cards, etc. have different names.
The common specification for the conventional serial port is RS−232 (or EIA−232). So it's often called a "RS−232 serial port". The connector(s) for the serial port are often seen as one or two 9−pin connectors (in some cases 25−pin) on the back of a PC. But the serial port is more than just connectors. It includes the associated electronics which must produce signals conforming to the RS−232 specification. See Voltage Waveshapes . One pin is used to send out data bytes and another to receive data bytes. Another pin is a common signal ground. The other "useful" pins are used mainly for signalling purposes with a steady negative voltage meaning "off" and a steady positive voltage meaning "on".
The UART (Universal Asynchronous Receiver−Transmitter) chip does most of the work. Today, the functionality of this chip is usually built into another chip. See What Are UARTs? These have improved over time and old models (prior to say 1994) are usually obsolete.
The serial port was originally designed for connecting external modems to a PC but it's used to connect many other devices also such as mice, text−terminals, some printers, etc. to a computer. You just plug these devices into the serial port using the correct cable. Many internal modem cards have a built−in serial port so when you install one inside your PC it's as if you just installed another serial port in your PC.
2. Quick Help
This repeats more detailed information found elsewhere. If your computer can't seem to find your serial port and you already know something about hardware resources (addresses like 3F8 and IRQs like 5) then try this: First, get into the BIOS (often called "setup") when the computer is powered on by pressing certain keys. To find out what keys to press, freeze the first words that flash by on the screen by holding down the "pause" and "shift" keys at the same time. Then hit any key to resume (cease pausing) and hold down the key(s) required to enter the BIOS setup. You may have to try this again since there may be more than one screen which you can freeze with the "pause" key. Also, look for messages about the serial ports on these frozen screens.
Once in the BIOS menus, try to find menus dealing with the serial port. They could be shown in a menu dealing with Resources, Plug−and−Play, Peripherals, Ports, etc. Some old BIOSs setups (before 1995 ?) didn't deal with the serial ports. Make sure the ports you need are not disabled and note how they are configured (like 3F8 IRQ 4). You may need to change the configuration to prevent conflicts. There could be a shortage of IRQs if the BIOS has reserved some IRQs that it didn't need to reserve.
For serial ports to be found, either the kernel must have been compiled with serial support, or serial support must be provided by a module.
3. How the Hardware Transfers Bytes
Below is an introduction to the topic, but for a more advanced treatment of it see FIFOs .
3.1 Transmitting
Transmitting is sending bytes out of the serial port away from the computer. Once you understand transmitting, receiving is easy to understand since it's similar. The first explanation given here will be grossly oversimplified. Then more detail will be added in later explanations. When the computer wants to send a byte out the serial port (to the external cable) the CPU sends the byte on the bus inside the computer to the I/O (Input Output) address of the serial port. I/O is often written as just IO. The serial port takes the byte, and
1.6 What is a Serial Port?
sends it out one bit at a time (a serial bit−stream) on the transmit pin of the serial cable connector. For what a bit (and byte) look like electrically see Voltage Waveshapes .
Here's a replay of the above in a little more detail (but still very incomplete). Most of the work at the serial port is done by the UART chip (or the like). To transmit a byte, the serial device driver program (running on the CPU) sends a byte to the serial port"s I/O address. This byte gets into a 1−byte "transmit shift register" in the serial port. From this shift register bits are taken from the byte one−by−one and sent out bit−by−bit on the serial line. Then when the last bit has been sent and the shift register needs another byte to send it could just ask the CPU to send it another byte. Thus would be simple but it would likely introduce delays since the CPU might not be able to get the byte immediately. After all, the CPU is usually doing other things besides just handling the serial port.
A way to eliminate such delays is to arrange things so that the CPU gets the byte before the shift register needs it and stores it in a serial port buffer (in hardware). Then when the shift register has sent out its byte and needs a new byte immediately, the serial port hardware just transfers the next byte from its own buffer to the shift register. No need to call the CPU to fetch a new byte.
The size of this serial port buffer was originally only one byte, but today it is usually 16 bytes (more in higher priced serial ports). Now there is still the problem of keeping this buffer sufficiently supplied with bytes so that when the shift register needs a byte to transmit it will always find one there (unless there are no more bytes to send). This is done by contacting the CPU using an interrupt.
First we'll explain the case of the old fashioned one−byte buffer, since 16−byte buffers work similarly (but are more complex). When the shift register grabs the byte out of the buffer and the buffer needs another byte, it sends an interrupt to the CPU by putting a voltage on a dedicated wire on the computer bus. Unless the CPU is doing something very important, the interrupt forces it to stop what it was doing and start running a program which will supply another byte to the port's buffer. The purpose of this buffer is to keep an extra byte (waiting to be sent) queued in hardware so that there will be no gaps in the transmission of bytes out the serial port cable.
Once the CPU gets the interrupt, it will know who sent the interrupt since there is a dedicated interrupt wire for each serial port (unless interrupts are shared). Then the CPU will start running the serial device driver which checks registers at I/0 addresses to find out what has happened. It finds out that the serial's transmit buffer is empty and waiting for another byte. So if there are more bytes to send, it sends the next byte to the serial port's I/0 address. This next byte should arrive when the previous byte is still in the transmit shift register and is still being transmitted bit−by−bit.
In review, when a byte has been fully transmitted out the transmit wire of the serial port and the shift register is now empty the following 3 things happen almost simultaneously:
Thus we say that the serial port is interrupt driven. Each time the serial port issues an interrupt, the CPU sends it another byte. Once a byte has been sent to the transmit buffer by the CPU, then the CPU is free to pursue some other activity until it gets the next interrupt. The serial port transmits bits at a fixed rate which is selected by the user (or an application program). It's sometimes called the baud rate. The serial port also adds extra bits to each byte (start, stop and perhaps parity bits) so there are often 10 bits sent per byte. At a rate (also called speed) of 19,200 bits per second (bps), there are thus 1,920 bytes/sec (and also 1,920
3.1 Transmitting
interrupts/sec).
Doing all this is a lot of work for the CPU. This is true for many reasons. First, just sending one 8−bit byte at a time over a 32−bit data bus (or even 64−bit) is not a very efficient use of bus width. Also, there is a lot of overhead in handing each interrupt. When the interrupt is received, the device driver only knows that something caused an interrupt at the serial port but doesn't know that it's because a character has been sent. The device driver has to make various checks to find out what happened. The same interrupt could mean that a character was received, one of the control lines changed state, etc.
A major improvement has been the enlargement of the buffer size of the serial port from 1−byte to 16−bytes. This means that when the CPU gets an interrupt it gives the serial port up to 16 new bytes to transmit. This is fewer interrupts to service but data must still be transferred one byte at a time over a wide bus. The 16−byte buffer is actually a FIFO (First In First Out) queue and is often called a FIFO. See FIFOs for details about the FIFO along with a repeat of some of the above info.
3.2 Receiving
Receiving bytes by a serial port is similar to sending them only it's in the opposite direction. It's also interrupt driven. For the obsolete type of serial port with 1−byte buffers, when a byte is fully received from the external cable it goes into the 1−byte receive buffer. Then the port gives the CPU an interrupt to tell it to pick up that byte so that the serial port will have room for storing the next byte which is currently being received. For newer serial ports with 16−byte buffers, this interrupt (to fetch the bytes) may be sent after 14 bytes are in the receive buffer. The CPU then stops what it was doing, runs the interrupt service routine, and picks up 14 to 16 bytes from the port. For an interrupt sent when the 14th byte has been received, there could be 16 bytes to get if 2 more bytes have arrived since the interrupt. But if 3 more bytes should arrive (instead of 2), then the 16−byte buffer will overrun. It also may pick up less than 14 bytes by setting it that way or due to timeouts. See FIFOs for more details.
We've talked about small 16−byte serial port hardware buffers but there are also much larger buffers in main memory. When the CPU takes some bytes out of the receive buffer of the hardware, it puts them into a much larger (say 8k−byte) receive buffer in main memory. Then a program that is getting bytes from the serial port takes the bytes it's receiving out of that large buffer (using a "read" statement in the program). A similar situation exists for bytes that are to be transmitted. When the CPU needs to fetch some bytes to be transmitted it takes them out of a large (8k−byte) transmit buffer in main memory and puts them into the small 16−byte transmit buffer in the hardware.