Serial Ports
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.
Pin |
Function |
Mnemonic |
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 |
7 |
Signal ground |
GND |
8 |
Carrier detect |
CD |
20 |
Data terminal
ready |
DTR |
22 |
Ring indicator |
RI |
Table -3 Common Pins on the DB25 Connector
Pin |
Function |
Mnemonic |
1 |
Carrier detect |
CD |
2 |
Receive |
RXD or RX |
3 |
Transmit |
TXD or TX |
4 |
Data terminal
ready |
DTR |
5 |
Signal ground |
GND |
6 |
Data set ready |
DSR |
7 |
Request to send |
RTS |
8 |
Clear to send |
CTS |
9 |
Ring indicator |
RI |
Table -4 Pins on DB9 Connector
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.
|