For the most part, all PC computers, even laptops are sold with at least one serial port and desktop machines or servers typically have two. These can be built into the motherboard, as part of a serial/parallel card, or as part of an “all-in-one” card that has serial ports, parallel ports, games ports, and even hard disk and floppy controllers. (Note: I have been told that newer laptops, particularly those from Compaq and IBM have only USB and no serial ports!)
As the name implies, serial device communicate serially. That is, each byte is split into 8 bits, which are sent one after the other. At the pyhsical level, what this means is that voltage on the transmit pin (line) is toggled to indicate the bits: negative is a 1 bit, and a positive voltage is a 0 bit. On the receiving end, the serial port accept the data on the receive pin and recognizes the voltage and therefore whether the bit is a 0 or 1.
Agreeing on the speed at which the voltage is toggled, is an import apect of the communication. The speed of the change determine how many bits per second can be sent, which is thus the speed of the serial port or serial device. A mouse will communicate with speeds between 1,200 and 9,600 bps, whereas modems can reach as high as 115,200 bps.
Deciding on speed is not the only thing used with serial communication to data arrives correctly. In some cases, like with modems, additional pins are used to say that one side is read to send the data (using the RTS pin) and the other side says that they are clear to send (CTS). Here a voltage of +12 is used for the respective signal. Other kinds of devices uses the pins data terminal ready (DTR) and data set ready (DSR). This has the same functionality, but just uses different pins. Typically, serial terminal use the DTR and DSR pins
Regardless of what pair of pins are used, this mechanism is used to ensure that data only flows when the appropriate side is ready. That is, it is used to control the flow and such a mechanism is thus called “flow control”. Since it the hardware that is used to control the flow, using pins like this is logically called hardware flow control. In other cases, such as when there is no phyiscal connection, you can use “software flow control”, which uses special “control characters”. For example, pressing the control key (CTRL) and the the “s” key (CTRL-S) you can stop the flow. Pressing CTRL-Q, you can start it up again.
With modems, you will typically find that a couple of other pins are used as well: ring indicator (RI) pin and the carrier detect (CD) pin. These indicate (respectively) an incoming call and that a the carrier signal has been detected.
A serial board is an expansion card that translates bus signals in which at least eight bits arrive simultaneously into signals that send single bits at a time. These bits are encapsulated into groups of one byte. The encapsulation contains other signals that represent the start and end of the byte, as well as a parity bit. Additionally, the number of bits used to represent data can be either 7 or 8.
Parity is the mechanism by which single-bit errors can be detected during transmission. The number of bits set to one is counted and based on whether even or odd parity is used, and the parity bit is set. For example, if even parity is used and there are three bits set, then the parity bit is also set to make the total number of bits set an even number. However, if odd parity is used, the number of bits set is already odd, therefore the parity bit is left unset. When you use some other means to detect errors, you can turn parity off, and you are said to be using no parity. This is the default for modems in Linux.
Serial communication parameters must be agreed upon by both ends. These parameters are often referred to in triples, such as 8-1-N (read as eight-one-none). In this instance, there are eight data bits, 1 stop bit, and no parity is used. This is the default for Linux systems.
One key element of a serial board is the Universal Asynchronous Receiver-Transmitter, or UART. The transmitter portion takes a byte of parallel data written by the serial driver to the card and transmits it one bit at a time (serially). The receiver does just the opposite: It takes the serial bits and converts them into parallel data that is sent down the bus and is read by the serial driver.
Originally, Linux only provided drivers for standard serial ports; intelligent boards are often installed to allow many more logins (or other connections) to the system. The most significant difference is that intelligent serial boards (often referred to as smart serial boards) have a built-in CPU, which allows it to take all responsibility for processing the signals away from the system CPU.
In the newer versions, you can find drivers for commercial multiport boards, such as the Stallion Easy IO, which allows you to quickly extend the number of serial ports on your system as the drivers are built in. Stallion is very supportive of the Linux world and even advertises the fact that their boards run on Linux.
In addition, intelligent serial boards can better buffer incoming signals that keep them from getting lost. With non-intelligent boards, the system may be so busy that it does not get around in time to read characters off the board. Although the 16550 UART, common on most serial boards today, contains 16-byte buffers, this is often not enough. Under heavy load, the serial driver does not react fast enough and the characters are overwritten.
Serial board performance is also increased by intelligent boards. Because signals are buffered and sent in large chunks, there is less overhead on a per-character basis. With non-intelligent boards, single characters are often transmitted, so the per-character overhead is much larger. In fact, most non-intelligent boards generate and interrupt the associated overhead with each character.
It is possible to obtain supported serial boards that have multiple ports. Although such boards have multiple UARTs, they do not have the performance of intelligent boards, though they do provide a low-cost alternative. For a discussion on the device nodes used for such boards, see the section on the device directory.
The pin assignments mentioned above and the commincation protocol (among other thinfs) is known as the RS-232 standard. RS-232 is easily effected by electrical noise, and thus has some limits the length and speed at which it can communicate. The longer the cable the slower the connection must be to ensure communication is not disrupted.
Originally designed to connect mainframe computers to modems, the RS-232 standard is used exclusively for serial port connections on PCs. Two kinds of devices are considered with RS-232: Data Terminal Equipment (DTE) and Data Communication Equipment (DCE). DTE is the serial port side and DCE is the modem side.
Two types of connections are used: DB25 (with 25 pins) and DB9 (with 9 pins). Although they both serve the same basic function, the numbering of the pins is slightly different. Table 0-3 lists the main pins of the DB25 connector, their functions, and a mnemonic that is commonly used to refer to them. Table 0-4 lists the pins for the DB9 connector. The physical layout of the pins is shown in Figure 0-13.
|2||Transmit||TXD or TX|
|3||Receive||RXD or RX|
|4||Request to send||RTS|
|5||Clear to send||CTS|
|6||Data set ready||DSR|
|20||Data terminal ready||DTR|
|2||Receive||RXD or RX|
|3||Transmit||TXD or TX|
|4||Data terminal ready||DTR|
|6||Data set ready||DSR|
|7||Request to send||RTS|
|8||Clear to send||CTS|
Figure – The Physical Layout of Pins on Serial Cables
Note that on a DB25 connector, pin 1 is chassis ground, which is different from signal ground. Chassis ground ensures that both serial connectors are operating at the same electric potential and keeps you from getting a shock.
To communicate properly, the DTE device must say that it is ready to work by sending a signal on the DTR line. The DCE device must do the same on the DSR line.
One side indicates that it has data by sending a signal on the RTS line (it is requesting to send data). If ready, the other side says that it is ready by sending a signal on the CTS line (the sender is clear to send the data). What happens when the receiving side can’t keep up (that is, if the sending side is sending too fast)? If the receiving side needs to stop (perhaps a buffer is full), it stops the CTS signal (meaning the sender is no longer clear to send the data). This causes the sending side to stop. This process is referred to as hardware handshaking, hardware flow control, or RTS/CTS flow control.
Problems arise when connecting other types of devices. Some devices, such as printers, are themselves DTE devices. If you tried to connect a standard RS-232 cable, TX is connected to TX, RX is connect to RX, DSR is connected to DSR, and DTR is connected to DTR. The result is that nothing happens. The solution is a cross-over cable, which internally swaps the appropriate signals and makes sure they go to the right place.
If you have a terminal, things are easier. First, though the data is going in both directions, the data coming from the terminal will never exceed the speed of the serial port (I’d like to see you type 240 characters per second). Data heading toward the terminal is displayed on the screen, which will display it as quickly as it comes. Therefore, you only need three signals: send, transmit, and ground.
If the terminal displays the data too fast for you to read, you can stop it by sending an XOFF character back to the system. This is usually Ctrl+S and unless it is turned off, it will stop incoming data. To turn the flow of data back on again, send the system an XON (Ctrl+Q) character. This type of flow control is called software flow control or XON/XOFF flow control. In some cases, depending on how the terminal is configured, sending any character restarts the flow.