Putting Serial-Port Technology in Perspective, Part 1

Source: PC Mag May 12, 1992
Author: Douglas Boling

The serial and parallel ports through which your computer sends and receives data have evolved considerably since the early days of the IBM PC. Essentially, their roles remain unchanged. Parallel ports, which are easy to implement, continue to be the choice for high-speed data transfer over short distances. Serial ports, while more complex, provide communication over longer distances, especially when combined with an attached modem. New to many of today's serial and parallel ports, however, are such sophisticated features as embedded RAM queues and built-in direct memory access (DMA).

To put these developments in their proper context, I'll begin by reviewing basic serial communications concepts before turning to their specific implementations in today's PCs in the next issue. Then, in future Lab Notes, I'll discuss parallel port developments.


In its simplest form, data is transferred from sender to receiver one bit at a time through a single line or circuit. You can send any sequence of bits simply by setting the line to a specified voltage for a specified length of time for each successive bit. The port at the receiving end samples the voltage on the line at the predetermined intervals in order to read the bits. In theory, all that is needed is agreement between sender and receiver on the transmission rate and on the voltages that will represent the ON and OFF states of each bit. In practice, the challenge facing serial communications is that of maintaining coordination between the bits being sent and those being read.

To see how problems can arise, let's consider a hypothetical example in which two serial ports are connected, either directly or through a pair of modems. We'll assume that it had been agreed that the transmitting computer will send data to the receiving computer at the rate of one bit per second. For a 0 bit, the sender will set the line at the lower of two defined voltages for a period of 1 second. If the next bit is a 1, the sender will then raise the voltage on the line to the higher specified level for the next second.

The receiver in this example reads the bits by checking the voltage on the data line at successive intervals of 1 second. Suppose, however, that the receiver's clock happens to run slightly faster than the clock in the transmitting computer. In this case, the receiver will start checking the line earlier and earlier during the period when the data bit is on the line. Sooner or later, the receiver will sample the same bit twice, and thereafter the data received will be out of sync with the data sent.

One way to solve the synchronization problem is to tell the receiving computer precisely when it should sample the data line. This can be accomplished by means of a second line, called a clock line. After placing the data bit on the serial data line, the transmitting computer sends the receiving computer a signal on the clock line saying, in effect, "Read the data bit now." Since the transmitting clock dictates both the send and read rates, no synchronization problem can arise.

A Synchronous Serial Data Stream

Figure 1: In synchronous serial communication, a clock signal is on one line while the data is on another line. While this is highly efficient, it does require two lines.

The method of providing a clock signal on one line while the data is on another line is called synchronous serial communication, and this aspect of the setup used is diagrammed in Figure 1. Synchronous communication has a number of advantages. First, the data transmission itself is highly efficient, since every bit on the data line can represent a bit of data. Second, since the clock signal originates with the device transmitting the data, the transmission speed can be changed simply by adjusting the rate of the clock line and data line at the same time. The big disadvantage of synchronous serial communication, of course, is that it requires the extra clock line, doubling the number of lines needed to transmit the data.

An alternative way to synchronize serial ports is to encode clocking information into the format of the data being transmitted. This method, used for most PC-based serial equipment connections, is called asynchronous serial communication. Under this arrangement, the transmitter and receiver are set to the same nominal speed, and no extra clock line is provided. Transmission errors that would inevitably arise over the long term because of slight differences in nominal speed are precluded by having the receiver use the clocking information to synchronize itself to the transmitter each time the group of bits that constitutes a data word is read.

The encoded clocking information consists of a start bit and a stop bit. When the asynchronous serial link is not passing data, the data line is held in a known state, usually that of a logical 1. Having no data to send, the transmitter simply marks time by sending marking bits. To notify the receiving device that a data word is about to be sent, the transmitter sends a start bit, whose state is opposite to that of the marking bits. The data word, usually 7 or 8 bits, is sent immediately after the start bit.

An Asynchronous Serial Data Stream

Figure 2: This is an alternative to synchronous communication. An async line encodes the clocking information into the format of the data being transmitted. Note that the receiver synchronizes with the transmitter each time a start bit is received, on the edge between the marking bits and the start bit.

The receiver detects the change from the stream of marking bits to the start bit and synchronizes its checking of the data line with the start bit. The data word is then read. At the end of the data word, a stop bit is appended to the data. The stop bit has the same state as the marking bits; that is, its state is opposite that of the start bit. If the transmitter has another data word to send, it sends another start bit after the stop bit, thus indicating the beginning of the next word. Figure 2 shows an async serial data stream. The important point to note is that the receiver synchronizes with the transmitter each time a start bit is received. Even if the clock in the receiver is faster or slower than the transmitter, as long as the difference is not significant over the length of time it takes to send one data word, the difference in speed doesn't matter.


Although a direct cable connection between two computers' serial ports or between a computer and a serially driven printer is not unusual, most serial communications take place through a pair of modems, which can be connected directly to telephone lines. Instead of representing 0s and 1s by simple voltages, a modem converts them into modulations of an audio frequency at the sending end. These waveforms are demodulated and reconverted to digital form by the receiving modem. By using sophisticated modulation techniques, modems can send multiple bit patterns with each change in the line state. Such techniques make high-speed modems possible, but because of them a certain amount of confusion in the terminology has arisen.

The transmission speed of serial links can be expressed in terms of either baud rate or bits per second. While often carelessly spoken of as if they were the same, these two measurements are quite different. Bits per second is exactly that: the number of bits transmitted every second. Baud rate, on the other hand, is a measure of the number of changes in the state of the line per second. In a purely digital link, in which the data line state can directly represent only a 1 or a 0, the two rates are the same, for only one bit is transmitted with each change in the line. Because modems transmit data by means of tones that can each represent more than one bit of data, however, the baud rate of a modem can be much lower than the transmission speed measured in bits per second.

Adding modems to the serial communications system increases the complexity of the necessary interface wiring and introduces the need to detect and rectify transmission errors introduced by weak or noisy lines. One commonly used form of error checking is implemented in the data format by adding a parity bit after the data bits but before the stop bit.

Parity checking involves counting the total number of 1 bits in each data word and its parity bit. When even parity is used, the parity bit is set to 1 or 0 to make the total an even number. For example, if the data word sent was 00111010, the parity bit would be set to 0 for even 'parity, as there are four 1 bits in the data word. For an odd system parity, the bit is set to make the total odd. The receiving serial port also counts the 1 bits in each incoming data word plus its parity bit. If the number does not match the parity mode, then there was an error in transmission and at least one of the received bits is wrong. Note, however, that simple parity checking is by no means foolproof: If an even number of bits are changed during transmission, the error will not be detected.

Another use for the parity bit is sticky parity. The term is something of a misnomer, for in this mode the parity bit is not used for parity checking at all. Rather, it is always set to a known state, either 0 or 1. When sticky parity is used, the receiver will always see a known bit at the same point in each data word.

The basic disadvantage of asynchronous communication is that extra bits are added for each data word sent by the transmitter. Adding one start and one stop bit means that ten bits must be sent for every eight bits of data, reducing the effective data rate by 20 percent. The rate is reduced still further if a parity bit is added to the data word. Since most common serial transmission modes use about ten bits per byte, you can roughly translate bps to bytes per second (at maximum efficiency) by just dropping a zero.


The Recommended Standard 232 takes the general concepts of serial communications and fleshes them out with the necessary specifics. The standard defines what the voltages shall be for ON and OFF bits, which pins on what kinds of connectors are to be used to join serial equipment together, and precisely how the transmitting and receiving units will recognize each other as ready to handle data, to name a few examples.

RS-232 was originally adopted by the Electronics Industry Association (EIA) in 1960 to codify the procedures by which terminals would communicate with modems. The standard has evolved over the years, with the third revision, RS-232C, being set forth in 1969. Serial ports on the PC are designed to the RS-232C specification. In 1987 the standard was again revised to RS-232D, also known as EIA-232D. The changes made in the D revision extend the specification to define three additional test lines and the shape of the connector. Electrically, the connector recommended by RS-232D emulates the standard 25-pin connector used by PCs.

According to RS-232, the terminal (or these days the computer) is known as the data terminal equipment (DTE), and the modem connected to it is known as the data communication equipment (DCE). The standard specifies higher electrical levels to represent logical 0s and 1s than the 0- to 5-volt TTL levels used inside PCs. This ensures that the bits can be read at the end of the maximum cable length (which is also specified by the standard) between the DTE and DCE. Note that since RS-232 defines only two states, 0 and 1, the baud rate of a serial port is conveniently the same as the bits per second transmitted.

Because the cables between the serial port on the computer and the modem are relatively short, it is practical to use physically separate wires ("lines") in an RS-232 cable to handle control signals that must be encoded for modem-to-modem transmission over a telephone line wire pair. RS-232 specifies all the connections needed between the DTE and DCE to implement both synchronous and asynchronous communication. Since the serial ports on most PCs are strictly asynchronous, I'll discuss only those lines needed for asynchronous communication.

The asynchronous portion of the RS-232 spec requires two lines for data transmission, six lines to pass control information, and a signal ground. These nine lines, with their conventional abbreviations, are:

  • transmitted data (BA);
  • received data (BB);
  • request to send (RTS);
  • clear to send (CTS);
  • data set ready (DSR);
  • data terminal ready (DTR);
  • ring indicator (RI);
  • data carrier detect (DCD);
  • signal ground (AB).

The signal ground provides a reference point for the levels of the other signals. Figure 3 shows the proper pin assignments for both 25-pin and 9-pin serial port connectors.

Serial Port Pin Assignments 

Figure 3: This diagram shows the proper pin assignments for both the 25-pin and 9-pin serial port connectors.

Initiating a conversation between the computer (or terminal) and the modem is a process that consists of sending signals across the various control lines until both the modem and the computer are satisfied that each is ready to communicate. This handshaking, as it is called, ensures that both devices are ready when data transmission starts.

Specifically, when the computer (the DTE) wishes to initialize the link to the modem (the DCE), it sends the lower of the two predetermined voltages on its DTR line, indicating that it is able to start a conversation. The modem responds by sending the lower of the two voltages across its DSR line, indicating that it is able to receive. Usually, these lines are set to a lower voltage when the computer and modem are turned on.

When both units signal "ready," the computer sends the lower of the two predetermined voltages on its Request to Send (RTS) line. In the old days, the sending modem would then blindly place a carrier signal on the phone line. When it detected the carrier signal, the receiving modem would put the higher of the two predetermined voltages on its DCD and CTS lines.

Today, with intelligent modems such as the Hayes Smartmodem, a conversation can take place between the computer and modem. In this case, the DCD line is not raised with the CTS line. It is raised only after the modem has dialed a number and detected the proper carrier tone from the receiving modem. The last control line is a ring indicator line, which notifies the computer when another modem is calling its modem. Once all this handshaking has been completed, the data can be transmitted from the sending computer to its modem, then through the phone lines, and finally from the receiving modem to its computer.

One often confusing point about the RS-232 specification arises from the critical distinction it draws between the DTE (computer) and the DCE (modem). RS-232 specifies that lines are connected to the same pin number at each end of the cable. That is, pin 2 on the DTE connector is connected to pin 2 of the DCE connector, DTE pin 3 runs to DCE pin 3, and so on. Pin 2 is designated as the Transmit Data Line. Pin 3 is designated as the Receive Data Line. The designations transmit and receive are always referred to from the perspective of the DTE (the PC). The computer transmits data to the modem on the transmit line, pin 2, and receives data on the receive data line, pin 3. The modem or any other DCE must therefore transmit data on pin 3, the receive data line, and receive data on the transmit data line, pin 2.

If a serial connection is to be made between two computers configured as DTEs, a null modem must be used to ensure that both devices are transmitting and receiving on the proper Lines. A null modem -an adapter or a cable- swaps the appropriate lines between the two computers to allow data transmission as well as the proper handshaking.


The PC BIOS itself provides a serial-port interface, using interrupt 14h. The BIOS functions allow setting the baud rate and the configuration of the data word. The status of the serial port can also be read, and data can also be sent and received. Unfortunately, the limited support provided in the BIOS has forced programmers to bypass its services and write directly to the serial-port hardware or UART, which I will discuss next time.

Douglas Boling is a contributing editor to PC Magazine.

Putting Serial-Port Technology in Perspective, Part 2

Content created and/or collected by:
Louis F. Ohland, Peter H. Wendt, David L. Beem, William R. Walsh, Tatsuo Sunagawa, Tomáš Slavotínek, Jim Shorney, Tim N. Clarke, Kevin Bowling, and many others.

Ardent Tool of Capitalism is maintained by Tomáš Slavotínek.
Last update: 08 May 2024 - Changelog | About | Legal & Contact