22.1 Serial Communications Overview
In serial communications, bits are transferred between devices one after the other in a series, whence 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:
- Synchronous serial communication
-
Synchronous serial communication is so called because the transmitting and receiving interfaces are synchronized to a common clock reference. Because both interfaces always "know what time it is," they are always in step, and always know which bit is on the wire at any particular time. Synchronous serial communication methods are common in mainframe and minicomputer environments, but are little used in PC communications. Synchronous serial communications are normally used in the PC environment only to support specialized devices, which are usually bundled with the appropriate synchronous adapter and cable. Therefore, this book will have no more to say about synchronous serial communication.
- Asynchronous serial communication
-
Asynchronous serial communication is the method commonly used in the PC environment. It is called asynchronous because the transmitting and receiving interfaces do not share a common clock reference. The transmitting interface may begin sending data at an arbitrary time, and the receiving interface is always "listening" for data. Because no shared time reference exists, the transmitting interface must embed markers into the data stream to alert the receiving interface that a block of data is about to arrive, and to indicate the beginning and end of the actual data block. These markers take the form of additional control bits sent before and after the actual data bits. Adding these control bits is called framing the data, and the control bits themselves are called framing bits.
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 accommodate 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 using 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.
22.1.2 Parity
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:
- Even parity
-
Even parity (E) sets the parity bit to one or zero to force the total number of one-bits in the data word plus the parity bit to an even number. For example, if a byte contains the seven data bits 1-1-0-1-0-0-1 (four one-bits, which is an even number), the parity bit is set to zero for even parity, leaving the total number of one-bits in the eight-bit byte at four, an even number. Conversely, if a byte contains the seven data bits 1-1-0-1-0-1-1 (five one-bits, which is an odd number), the parity bit is set to one for even parity, forcing the total number of one-bits in the eight-bit byte to six, again an even number. Even parity with seven-bit data words was commonly used years ago for dial-up and direct serial connections to mainframes (including dial-up connections from PCs to CompuServe mainframes), but is otherwise little used.
- Odd parity
-
Odd parity (O) sets the parity bit on or off to force the total number of one-bits in the data word plus the parity bit to an odd number. O parity is seldom used in PC communications.
- Mark parity
-
Mark parity (M) always sets the parity bit to one (Mark). This setting provides no error detection, and simply uses the parity bit as a wasted "filler" bit. Some mainframe environments still use Mark parity.
- Space parity
-
Space parity (S) always sets the parity bit to zero (Space). This setting provides no error detection, and simply uses the parity bit as a wasted "filler" bit. Some mainframe environments still use Space parity.
- None
-
None, or no, parity (N) allocates all eight bits in the byte to data, leaving no space available for a parity bit. The N parity setting is used for nearly all PC serial communications.
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 Kb/s 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, typically 38.4 Kb/s in older PCs through 115.2 Kb/s or higher in recent computers.
Operating systems such as 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 Data Terminal Equipment (DTE) or Data Communications Equipment (DCE), 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.
- Software flow control
-
With software flow control, the DCE embeds special control characters into the data stream to notify the DTE to pause or resume sending data. The most common software flow control method is XON/XOFF. The resume character, ASCII 17 (0x11), is also called XON, DC1, or Ctrl-Q. The pause character, ASCII 19 (0x13), is also called XOFF, DC3, or Ctrl-S. A similar but less commonly used software flow control method is ETX/ACK, which uses ETX (ASCII 3, 0x03, or Ctrl-C) as the pause character and ACK (ASCII 6, 0x06, or Ctrl-F) as the resume character. Software flow control does not work well at speeds higher than about 9,600 bps, and so is seldom used for general-purpose communications nowadays.
- Hardware flow control
-
With hardware flow control, the DCE and DTE use signals asserted on standard EIA-232D pins (usually some combination of RTS, CTS, DSR, DTR, and CD) to control data flow. Because the need for flow control was not envisioned when RS-232 was designed, the standard does not define any hardware flow control method. This means that, in theory at least, all hardware flow control methods are proprietary. In practice, various ad hoc workarounds for hardware flow control have become so well established that they are considered de facto standards. Windows uses RTS/CTS, which it refers to simply as hardware flow control.
