22.1 Serial Communications Overview
In serial communications, bits are transferred between devices one after the other in a series, hence the name. To communicate an eight bit-byte, the transmitting serial device breaks that byte into its component bits and then places those bits sequentially onto the serial communications interface. The receiving interface accepts the incoming bits, stores them temporarily in a buffer until all bits have been received, reassembles the bits into the original byte, and then delivers that byte to the receiving device.
Because any bit is indistinguishable from any other bit, serial interfaces must use some means to keep things synchronized between the transmitting and receiving interfaces. Otherwise, for example, if transmitted bit #4 were lost due to line noise or some other communication problem, the receiving interface would assume when it received bit #5 that that bit was bit #4, resulting in completely scrambled data. Two methods may be used to effect this synchronization:
22.1.1 Asynchronous Serial Framing
In asynchronous serial systems, data is broken into five- to eight-bit words, with seven- and eight-bit words by far most common. Seven-bit words are used for text-mode transfers, because seven bits accommodates the entire low-order ASCII character set. Eight-bit words are used for binary-mode transfers (and may be used for text-mode transfers), because eight bits allows the entire data byte to be transferred as a single unit.
When assembling the data to be transmitted, the serial interface adds control bits to the data block to create a frame. The frame begins with the start bit, a special double-length pulse that signals the receiving interface that transmitted data is about to begin arriving. Immediately following the start bit, the frame contains the data word, with the least significant bit first. Immediately following the final data bit, the frame may contain a parity bit. The frame ends with one or more required stop bits, which signal the receiving interface that the frame is complete. When assembled, the start bit, data bits, parity bit, and stop bit together make up one frame.
Line noise and similar problems can "flip" bits, converting a zero bit to a one bit or vice versa and thereby corrupting the data word. Using a parity bit is a primitive means of detecting a flipped bit. If parity is used, the transmitting device calculates the value for the parity bit based on the values of the data bits in the word. The receiving device calculates the value of the parity bit based on the data bits it receives, and compares that calculated parity bit against the received parity bit. If the two do not match, the receiving device knows that a transmission error occurred and requests retransmission of that frame. Serial devices may use one of five types of parity settings, only two of which are useful for detecting transmission errors:
Parity is such a primitive and unreliable means of detecting errors that using it simply wastes an otherwise valuable bit. Because it uses only one bit, parity can provide only limited error detection and no error correction. Parity detects single-bit errors, but cannot correct them because it doesn't know which data bit is wrong. Parity may also fail on multiple-bit errors. For example, if an even number of bits are flipped within one data word, parity cannot detect the error because calculated parity is identical for the original and corrupted data words. Finally, the parity bit itself may be flipped, resulting in a false error for a good data word.
In theory, you could correct the drawbacks of parity just by using more parity bits. For example, using three parity bits and a cyclic redundancy check (CRC) algorithm makes it possible both to detect and correct single- and multiple-bit errors in an eight-bit data word. In practice, no such CRC scheme is used in PC serial communications, primarily because of the additional overhead it would require. Instead, error detection and correction is performed in software by the serial devices, the device drivers, the operating system, and the application itself.
22.1.3 Asynchronous Frame Types
Many different asynchronous frame types can be created by using different combinations of data word length, parity type, and number of stop bits. Frame types are abbreviated using the number of data bits, the parity type, and the number of stop bits. For example, a frame that uses seven data bits, even parity, and one stop bit is abbreviated 7E1, and one that uses eight data bits, no parity, and one stop bit is abbreviated 8N1. These, incidentally, are the only two frame types commonly used in PC serial communications. The 7E1 frame type is still sometimes used for direct and dial-up serial connections to mainframes and for connections to old serial printers. The 8N1 frame type is used for nearly everything else.
22.1.4 Serial Data Transmission
A serial bit stream is actually placed on the wire as a rapidly changing series of voltages, with positive voltage used to represent logical zero, and negative voltage used to represent logical one. This serial bit stream is characterized by the nominal speed at which the bits are being sent, measured in bits per second, abbreviated bps and pronounced "bips." At higher data rates, the bit stream is specified in kilobits per second (Kbps or Kb/s) or megabits per second (Mbps or Mb/s).
Serial data rates between devices cannot be set at just any arbitrary value. Instead, they are incremented into standard fixed rates that you select from. The lowest rate used is 50 bps. For historical reasons, the upward progression in data rates is somewhat odd. The next standard rate is 75 bps, followed by 110 bps and 150 bps. From there, the standard data rates double for a while, to 300 bps, 600 bps, 1,200 bps, 2,400 bps, 4,800 bps, 9,600 bps, 19,200 bps, and 38,400 bps. Beyond 38,400, speeds are less standardized. On a de facto basis, the next step up is usually 57,200 bps ("56K"), followed by 115,200 bps. Note that not all serial communications hardware supports every available data rate, particularly non-standard intermediate rates. For communications to take place, the serial interfaces on both ends of the connections must be set to the same data rate.
Although the term baud is sometimes used interchangeably with bps when discussing data rates, the two are not synonymous. Baud refers to the number of state changes per second, while bps refers to the data rate. Each state change may communicate one or more bits of information. If only one bit is encoded per state change, baud and bps are synonymous. In the PC environment, this occurs only at 300 bps, where a 300 bps modem is also a 300 baud modem. Conversely, a 2,400 bps modem actually operates at 600 baud, with four bits encoded per baud, and a 14.4 Kbps v.32bis modem operates at 2,400 baud with six bits encoded per baud. Faster modems use various baud rates and encoding schemes to achieve higher bit rates. An ordinary telephone line can support a maximum baud rate of about 3,600 baud, which translates to a maximum data rate of about 56 Kb/s. Various FCC regulations reduce this theoretical maximum, so the actual maximum data rate achievable on a standard telephone line is about 53 Kb/s.
The original IBM PC and its clones implemented serial communications via software routines stored in BIOS. The slow performance of real-mode BIOS-based routines limited serial port speeds to 9,600 bps in early IBM PCs and to 19,200 bps in later PS/2 models. The bottleneck was the BIOS, however, and not the serial port hardware itself, so communications software vendors began to write software that ignored the BIOS and worked directly with the serial port hardware. By doing so, they were able to use the maximum data rate supported by the serial port hardware itself, typically 38.4 Kbps in older PCs through 115.2 Kbps in recent computers.
Operating systems like Windows 9X and Windows NT/2000/XP have formalized the process of working directly with serial hardware. They ignore the real-mode BIOS serial routines and provide their own high-efficiency drivers to allow serial communications to occur at the highest data rate supported by the serial hardware. This means that communications programs no longer need to incorporate direct serial access routines to ensure high performance. Instead, they simply use the routines provided by the operating system.
22.1.5 Flow Control
A serial interface may be configured as either DTE (Data Terminal Equipment) or DCE (Data Communications Equipment), which specifies which pins are used to transmit and receive data and control signals. Traditionally, serial ports are configured as DTE, and communications devices such as modems are configured as DCE. In practical terms, however, the DTE/DCE differentiation doesn't much matter. Any serial device, DTE or DCE, can communicate with any other serial device, DTE or DCE, so long as the proper cable is used to link them.
Ideally, a DCE would always be ready to receive data when the DTE was ready to send it. In the real world, that's not always the case. For example, a degraded telephone connection may render the local modem (DCE) incapable of sending data to the remote modem as fast as it is receiving data from the local DTE. DCE devices may be equipped with buffers to allow them to temporarily store a limited amount of data. This accommodates short-term mismatches between DTE-to- DCE data rate and DCE-to-DCE data rate, but does nothing to accommodate mismatches of long or permanent duration.
The methods used to accommodate such mismatches are called flow control. Using flow control, the DCE device notifies the DTE device to stop sending data temporarily. When the DCE device has cut down on the backlog, it notifies the DTE that it is again ready to receive data. Flow control may be implemented in two ways.