لطفا منتظر باشید ...
Publisher22.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
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
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 (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 (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 (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 (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, 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).
|
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.
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.
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 .
