Like all devices in a Unix system, serial ports are accessed through device special files, located in the /dev directory. There are two varieties of device files related to serial drivers, and there is one device file of each type for each port. The device will behave slightly differently, depending on which of its device files we open. We'll cover the differences because it will help you understand some of the configurations and advice that you might see relating to serial devices, but in practice you need to use only one of these. At some point in the future, one of them may even disappear completely.
The most important of the two classes of serial device has a major number of 4, and its device special files are named ttyS0, ttyS1, etc. The second variety has a major number of 5 and was designed for use when dialing out (calling out) through a port; its device special files are called cua0, cua1, etc. In the Unix world, counting generally starts at zero, while laypeople tend to start at one. This creates a small amount of confusion for people because COM1: is represented by /dev/ttyS0, COM2: by /dev/ttyS1, etc. Anyone familiar with IBM PC-style hardware knows that COM3: and greater were never really standardized anyway.
The cua, or "callout," devices were created to solve the problem of avoiding conflicts on serial devices for modems that have to support both incoming and outgoing connections. Unfortunately, they've created their own problems and are now likely to be discontinued. Let's briefly look at the problem.
Linux, like Unix, allows a device, or any other file, to be opened by more than one process simultaneously. Unfortunately, this is rarely useful with tty devices, as the two processes will almost certainly interfere with each other. Luckily, a mechanism was devised to allow a process to check if a tty device had already been opened by another device. The mechanism uses what are called lock files. The idea was that when a process wanted to open a tty device, it would check for the existence of a file in a special location, named similarly to the device it intends to open. If the file did not exist, the process created it and opened the tty device. If the file did exist, the process assumed that another process already had the tty device open and took appropriate action. One last clever trick to make the lock file management system work was writing the process ID (pid) of the process that had created the lock file into the lock file itself; we'll talk more about that in a moment.
The lock file mechanism works perfectly well in circumstances in which you have a defined location for the lock files and all programs know where to find them. Alas, this wasn't always the case for Linux. It wasn't until the Linux Filesystem Standard defined a standard location for lock files when tty lock files began to work correctly. At one time there were at least four, and possibly more, locations chosen by software developers to store lock files: /usr/spool/locks/, /var/spool/locks/, /var/lock/, and /usr/lock/. Confusion caused chaos. Programs were opening lock files in different locations that were meant to control a single tty device; it was as if lock files weren't being used at all.
The cua devices were created to provide a solution to this problem. Rather than relying on the use of lock files to prevent clashes between programs wanting to use the serial devices, it was decided that the kernel could provide a simple means of arbitrating who should be given access. If the ttyS device were already opened, an attempt to open the cua would result in an error that a program could interpret to mean the device was already being used. If the cua device were already open and an attempt was made to open the ttyS, the request would block; that is, it would be put on hold and wait until the cua device was closed by the other process. This worked quite well if you had a single modem that you had configured for dial-in access and you occasionally wanted to dial out on the same device. But it did not work very well in environments where you had multiple programs wanting to call out on the same device. The only way to solve the contention problem was to use lock files! Back to square one.
Suffice it to say that the Linux Filesystem Standard came to the rescue and now mandates that lock files be stored in the /var/lock directory, and that by convention, the lock filename for the ttyS1 device, for instance, is LCK..ttyS1. The cua lock files should also go in this directory, but use of cua devices is now discouraged.
The cua devices will probably still be around for some time to provide a period of backward compatibility, but in time they will be retired. If you are wondering what to use, stick to the ttyS device and make sure that your system is Linux FSSTND compliant, or at the very least that all programs using the serial devices agree on where the lock files are located. Most software dealing with serial tty devices provides a compile-time option to specify the location of the lock files. More often than not, this will appear as a variable called something like LOCKDIR in the Makefile or in a configuration header file. If you're compiling the software yourself, it is best to change this to agree with the FSSTND-specified location. If you're using a precompiled binary and you're not sure where the program will write its lock files, you can use the following command to gain a hint:
strings binaryfile | grep lock
If the location found does not agree with the rest of your system, you can try creating a symbolic link from the lock directory that the foreign executable wants to use back to /var/lock/. This is ugly, but it will work.
Minor numbers are identical for both types of serial devices. If you have your modem on one of the ports COM1: tHRough COM4:, its minor number will be the COM port number plus 63. If you are using special serial hardware, such as a high-performance multiple port serial controller, you will probably need to create special device files for it; it probably won't use the standard device driver. The Serial HOWTO should be able to assist you in finding the appropriate details.
Assume your modem is on COM2:. Its minor number will be 65, and its major number will be 4 for normal use. There should be a device called ttyS1 that has these numbers. List the serial ttys in the /dev/ directory. The fifth and sixth columns show the major and minor numbers, respectively:
$ ls -l /dev/ttyS* 0 crw-rw---- 1 uucp dialout 4, 64 Oct 13 1997 /dev/ttyS0 0 crw-rw---- 1 uucp dialout 4, 65 Jan 26 21:55 /dev/ttyS1 0 crw-rw---- 1 uucp dialout 4, 66 Oct 13 1997 /dev/ttyS2 0 crw-rw---- 1 uucp dialout 4, 67 Oct 13 1997 /dev/ttyS3
If there is no device with major number 4 and minor number 65, you will have to create one. Become the superuser and type:
# mknod -m 666 /dev/ttyS1 c 4 65 # chown uucp.dialout /dev/ttyS1
The various Linux distributions use slightly differing strategies for who should own the serial devices. Sometimes they will be owned by root, and other times they will be owned by another user. Most distributions have a group specifically for dial-out devices, and any users who are allowed to use them are added to this group.
Some people suggest making /dev/modem a symbolic link to your modem device so that casual users don't have to remember the somewhat unintuitive ttyS1. However, you cannot use modem in one program and the real device filename in another. Their lock files would have different names and the locking mechanism wouldn't work.
RS-232 is currently the most common standard for serial communications in the PC world. It uses a number of circuits for transmitting single bits, as well as for synchronization. Additional lines may be used for signaling the presence of a carrier (used by modems) and for handshaking. Linux supports a wide variety of serial cards that use the RS-232 standard.
Hardware handshake is optional, but very useful. It allows either of the two stations to signal whether it is ready to receive more data, or if the other station should pause until the receiver is done processing the incoming data. The lines used for this are called Clear to Send (CTS) and Request to Send (RTS), respectively, which explains the colloquial name for hardware handshake: RTS/CTS.
The other type of handshake you might be familiar with is called XON/XOFF handshaking. XON/XOFF uses two nominated characters, conventionally Ctrl-S and Ctrl-Q, to signal to the remote end that it should stop and start transmitting data, respectively. While this method is simple to implement and okay for use by dumb terminals, it causes great confusion when you are dealing with binary data, as you may want to transmit those characters as part of your data stream, and not have them interpreted as flow control characters. It is also somewhat slower to take effect than hardware handshake. Hardware handshake is clean, fast, and recommended in preference to XON/XOFF when you have a choice.
In the original IBM PC, the RS-232 interface was driven by a UART chip called the 8250. PCs around the time of the 486 used a newer version of the UART called the 16450. It was slightly faster than the 8250. Nearly all Pentium-based machines have been supplied with an even newer version of the UART called the 16550. Some brands (most notably internal modems equipped with the Rockwell chip set) use completely different chips that emulate the behavior of the 16550 and can be treated similarly. Linux supports all of these in its standard serial port driver.[1]
[1] Note that we are not talking about WinModem© here! WinModems have very simple hardware and rely completely on the main CPU of your computer instead of dedicated hardware to do all of the hard work. If you're purchasing a modem, it is our strongest recommendation to not purchase such a modem; get a real modem, though if you're stuck with a WinModem, there's hope! Check out http://linmodems.org for drivers, instructions, and the LINMODEM HOWTO.
The 16550 was a significant improvement over the 8250 and the 16450 because it offered a 16-byte FIFO buffer. The 16550 is actually a family of UART devices, comprising the 16550, the 16550A, and the 16550AFN (later renamed PC16550DN). The differences relate to whether the FIFO actually works; the 16550AFN is the one that is sure to work. There was also an NS16550, but its FIFO never really worked either.
The 8250 and 16450 UARTs had a simple 1-byte buffer. This means that a 16450 generates an interrupt for every character transmitted or received. Each interrupt takes a short period of time to service, and this small delay limits 16450s to a reliable maximum bit speed of about 9,600 bps in a typical ISA bus machine.
In the default configuration, the kernel checks the four standard serial ports, COM1: through COM4:. The kernel is also able to automatically detect what UART is used for each of the standard serial ports and will make use of the enhanced FIFO buffer of the 16550, if it is available.