This is copied from
You don't have to understand the
basics to use the serial port But understanding it may help to determine what
is wrong if you run into problems. This section not only presents new topics
but also repeats some of what was said in the previous section How
the Hardware Transfers Bytes but in greater detail.
The serial port is an I/O
(Input/Output) device.
An I/O device is just a way to get
data into and out of a computer. There are many types of I/O devices such as
serial ports, parallel ports, disk drive controllers, ethernet boards,
universal serial buses, etc. Most PC's have one or two serial ports. Each has a
9-pin connector (sometimes 25-pin) on the back of the computer. Computer
programs can send data (bytes) to the transmit pin (output) and receive bytes
from the receive pin (input). The other pins are for control purposes and
ground.
The serial port is much more than
just a connector. It converts the data from parallel to serial and changes the
electrical representation of the data. Inside the computer, data bits flow in
parallel (using many wires at the same time). Serial flow is a stream of bits
over a single wire (such as on the transmit or receive pin of the serial
connector). For the serial port to create such a flow, it must convert data
from parallel (inside the computer) to serial on the transmit pin (and
conversely).
Most of the electronics of the
serial port is found in a computer chip (or a part of a chip) known as a UART.
For more details on UARTs see the section
What Are
UARTS? But you may want to finish this section first so that you will
hopefully understand how the UART fits into the overall scheme of things.
Old PC's used 25 pin connectors but
only about 9 pins were actually used so today most connectors are only 9-pin.
Each of the 9 pins usually connects to a wire. Besides the two wires used for
transmitting and receiving data, another pin (wire) is signal ground. The
voltage on any wire is measured with respect to this ground. Thus the minimum
number of wires to use for 2-way transmission of data is 3. Except that it has
been known to work with no signal ground wire but with degraded performance and
sometimes with errors.
There are still more wires which
are for control purposes (signalling) only and not for sending bytes. All of
these signals could have been shared on a single wire, but instead, there is a
separate dedicated wire for every type of signal. Some (or all) of these
control wires are called "modem control lines". Modem control wires
are either in the asserted state (on) of +12 volts or in the negated state
(off) of -12 volts. One of these wires is to signal the computer to stop
sending bytes out the serial port cable. Conversely, another wire signals the
device attached to the serial port to stop sending bytes to the computer. If
the attached device is a modem, other wires may tell the modem to hang up the
telephone line or tell the computer that a connection has been made or that the
telephone line is ringing (someone is attempting to call in). See section Pinout
and Signals for more details.
The serial port (not the USB) is
usually a RS-232-C, EIA-232-D, or EIA-232-E. These three are almost the same
thing. The original RS (Recommended Standard) prefix became EIA (Electronics
Industries Association) and later EIA/TIA after EIA merged with TIA
(Telecommunications Industries Association). The EIA-232 spec provides also for
synchronous (sync) communication but the hardware to support sync is almost
always missing on PC's. The RS designation is obsolete but is still widely
used. EIA will be used in this howto. Some documents use the full EIA/TIA
designation. For info on other (non-EIA-232) serial ports see the section Other
Serial Devices (not async EIA-232)
Since the computer needs to
communicate with each serial port, the operating system must know that each
serial port exists and where it is (its I/O address). It also needs to know
which wire (IRQ number) the serial port must use to request service from the
computer's CPU. It requests service by sending an interrupt on this wire. Thus
every serial port device must store in its non-volatile memory both its I/O
address and its Interrupt ReQuest number: IRQ. See Interrupts. For the
PCI bus it doesn't work exactly this way since the PCI bus has its own system
of interrupts. But since the PCI-aware BIOS sets up chips to map these PCI
interrupts to IRQs, it seemingly behaves just as described above except that
sharing of interrupts is allowed (2 or more devices may use the same IRQ
number).
I/O addresses are not the same as
memory addresses. When an I/O addresses is put onto the computer's address bus,
another wire is energized. This both tells main memory to ignore the address
and tells all devices which have I/O addresses (such as the serial port) to
listen to the address to see if it matches the device's. If the address
matches, then the I/O device reads the data on the data bus.
The serial ports are named ttyS0,
ttyS1, etc. (and usually correspond respectively to COM1, COM2, etc. in
DOS/Windows). The /dev directory has a special file for each port. Type
"ls /dev/ttyS*" to see them. Just because there may be (for example)
a ttyS3 file, doesn't necessarily mean that there exists a physical serial port
there.
Which one of these names (ttyS0,
ttyS1, etc.) refers to which physical serial port is determined as follows. The
serial driver (software) maintains a table showing which I/O address
corresponds to which ttyS. This mapping of names (such as ttyS1) to I/O
addresses (and IRQ's) may be both set and viewed by the "setserial"
command. See What
is Setserial. This does not
set the I/O address and IRQ in the hardware itself (which is set by jumpers or
by plug-and-play software). Thus what physical port corresponds to say ttyS1
depends both on what the serial driver thinks (per setserial) and what is set
in the hardware. If a mistake has been made, the physical port may not
correspond to any name (such as ttyS2) and thus it can't be used. See Serial
Port Devices /dev/ttyS2, etc. for more details>
When the serial port receives a
number of bytes (may be set to 1, 4, 8, or 14) into its FIFO buffer, it signals
the CPU to fetch them by sending an electrical signal known as an interrupt on
a certain wire normally used only by that port. Thus the FIFO waits for a
number of bytes and then issues an interrupt.
However, this interrupt will also
be sent if there is an unexpected delay while waiting for the next byte to
arrive (known as a timeout). Thus if the bytes are being received slowly (such
as someone typing on a terminal keyboard) there may be an interrupt issued for
every byte received. For some UART chips the rule is like this: If 4 bytes in a
row could have been received, but none of these 4 show up, then the port gives
up waiting for more bytes and issues an interrupt to fetch the bytes currently
in the FIFO. Of course, if the FIFO is empty, no interrupt will be issued.
Each interrupt conductor (inside
the computer) has a number (IRQ) and the serial port must know which conductor
to use to signal on. For example, ttyS0 normally uses IRQ number 4 known as
IRQ4 (or IRQ 4). A list of them and more will be found in "man
setserial" (search for "Configuring Serial Ports"). Interrupts
are issued whenever the serial port needs to get the CPU's attention. It's important
to do this in a timely manner since the buffer inside the serial port can hold
only 16 (1 in old serial ports) incoming bytes. If the CPU fails to remove such
received bytes promptly, then there will not be any space left for any more
incoming bytes and the small buffer may overflow (overrun) resulting in a loss
of data bytes. There is no Flow Control to
prevent this.
Interrupts are also issued when the
serial port has just sent out all 16 of its bytes from its small transmit
buffer out the external cable. It then has space for 16 more outgoing bytes.
The interrupt is to notify the CPU of that fact so that it may put more bytes
in the small transmit buffer to be transmitted. Also, when a modem control line
changes state an interrupt is issued.
The buffers mentioned above are all
hardware buffers. The serial port also has large buffers in main memory. This
will be explained later
Interrupts convey a lot of
information but only indirectly. The interrupt itself just tells a chip called
the interrupt controller that a certain serial port needs attention. The
interrupt controller then signals the CPU. The CPU runs a special program to
service the serial port. That program is called an interrupt service routine
(part of the serial driver software). It tries to find out what has happened at
the serial port and then deals with the problem such a transferring bytes from
(or to) the serial port's hardware buffer. This program can easily find out
what has happened since the serial port has registers at IO addresses known to
the the serial driver software. These registers contain status information
about the serial port. The software reads these registers and by inspecting the
contents, finds out what has happened and takes appropriate action.
Data (bytes representing letters,
pictures, etc.) flows into and out of your serial port. Flow rates (such as 56k
(56000) bits/sec) are (incorrectly) called "speed". But almost
everyone says "speed" instead of "flow rate".
It's important to understand that
the average speed is often less than the specified speed. Waits (or idle time)
result in a lower average speed. These waits may include long waits of perhaps
a second due to Flow
Control. At the other extreme there may be very short waits (idle time) of
several micro-seconds between bytes. If the device on the serial port (such as
a modem) can't accept the full serial port speed, then the average speed must
be reduced.
Flow control means the ability to
slow done the flow of bytes in a wire. For serial ports this means the ability
to stop and then restart the flow without any loss of bytes. Flow control is
needed for modems to allow a jump in instantaneous flow rates.
For example, consider the case
where you connect a 36.6k external modem via a short cable to your serial port.
The modem sends and receives bytes over the phone line at 36.6k bits per second
(bps). Assume it's not doing any data compression or error correction. You have
set the serial port speed to 115,200 bits/sec (bps), and you are sending data
from your computer to the phone line. Then the flow from the your computer to your
modem over the short cable is at 115.2k bps. However the flow from your modem
out the phone line is only 33.6k bps. Since a faster flow (115.2k) is going
into your modem than is coming out of it, the modem is storing the excess flow
(115.2k -33.6k = 81.6k bps) in one of its buffers. This buffer would soon
overrun (run out of free storage space) unless the high 115.2k flow is stopped.
But now flow control comes to the
rescue. When the modem's buffer is almost full, the modem sends a stop signal
to the serial port. The serial port passes on the stop signal on to the device
driver and the 115.2k bps flow is halted. Then the modem continues to send out
data at 33.6k bps drawing on the data it previous accumulated in its buffer.
Since nothing is coming into the buffer, the level of bytes in it starts to
drop. When almost no bytes are left in the buffer, the modem sends a start
signal to the serial port and the 115.2k flow from the computer to the modem
resumes. In effect, flow control creates an average flow rate in the short
cable (in this case 33.6k) which is significantly less than the "on"
flow rate of 115.2k bps. This is "start-stop" flow control.
In the above simple example it was
assumed that the modem did no data compression. This would be true when the
modem is sending a file which is already compressed and can't be compressed
further. Now let's consider the opposite extreme where the modem is compressing
the data with a high compression ratio. In such a case the modem might need an
input flow rate of say 115.2k bps to provide an output (to the phone line) of
33.6k bps (compressed data). The compression ratio is 3.43 (115.2/33.6) which
is much higher than average. In this case the modem is able to compress and the
115.2 bps PC-to-modem flow and send the same data out on the phone line at
33.6bps. There's no need for flow control here. But such a high compression
ratio rarely happens so that most of the time flow control is needed to slow
down the flow on the 115.2 bps PC-to-modem cable. The flow is stopped and
started so that the average flow is usually well under the "on" flow
of 115.2 bps.
In the above example the modem was
an external modem. But the same situation exists (as of late 2000) for most
internal modems. There is still a speed limit on the PC-to-modem speed even
though this flow doesn't take place over an external cable. This makes the
internal modems compatible with the external modems.
In the above example of flow
control the flow was from the computer to a modem. But there is also flow control
which is used for the opposite direction of flow: from a modem (or other
device) to a computer. Each direction of flow involve 3 buffers: 1. in the
modem 2. in the UART chip (called FIFOs) 3. in main memory managed by the
serial driver. Flow control protects certain buffers from overflowing. The
small UART FIFO buffers are not protected in this way but rely instead on a
fast response to the interrupts they issue. FIFO stand for "First In,
First Out" which is the way it handles bytes. All the 3 buffers use the
FIFO rule but only one of them also uses it as a name. This is the essence of
flow control but there are still some more details.
Understanding flow-control theory
can be of practical use. The symptom of no flow control is chunks of data
missing from files sent without the benefit of flow control. This is because
when overflow happens, it's usually more than just a few bytes that overflow
and are lost. Often hundreds or even thousands of bytes get lost, and all in
contiguous chunks.
If feasible it's best to use
"hardware" flow control that uses two dedicated "modem
control" wires to send the "stop" and "start" signals.
Software flow control uses the main
receive and transmit wires to send the start and stop signals. It uses the
ASCII control characters DC1 (start) and DC3 (stop) for this purpose. They are
just inserted into the regular stream of data. Software flow control is not
only slower in reacting but also does not allow the sending of binary data
unless special precautions are taken. Since binary data will likely contain DC1
and DC3, special means must be taken to distinguish between a DC3 that means a
flow control stop and a DC3 that is part of the binary code. Likewise for DC1.
Much has been explained about this
including flow control, a pair of 16-byte FIFO buffers (in the UART), and a
pair of larger buffers inside a device connected to the serial port (such as a
modem. But there is still another pair of buffers. These are large buffers
(perhaps 8k) in main memory also known as serial port buffers. When an
application program sends bytes to the serial port
they first get stashed in the the
transmit serial port buffer in main memory. The pair consists of both this
transmit buffer and a receive buffer for the opposite direction of byte-flow.
Here's an example diagram for the case of browsing the Internet with a browser.
Transmit data flow is left to right while receive flow is right to left.
application 8k-byte 16-byte 1k-byte tele-
BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
program buffer buffer buffer line
The serial device driver takes out
say 16 bytes from this transmit buffer, one byte at a time and puts them into
the 16-byte transmit buffer in the serial UART for transmission. Once in that
transmit buffer, there is no way to stop them from being transmitted. They are
then transmitted to the modem or other device connected to the serial port
which also has a fair sized (say 1k) buffer. When the device driver (on orders
from flow control) stops the flow of outgoing bytes from the computer, what it
actually stops is the flow of outgoing bytes from the large transmit buffer in
main memory. Even after this has happened and the flow to the device connected
to the serial port has stopped, an application program may keep sending bytes
to the 8k transmit buffer until it becomes fill.
When it gets fill, the application
program can't send any more bytes to it (a "write" statement in a
C_program blocks) and the application program temporarily stops running and
waits until some buffer space becomes available. Thus a flow control
"stop" is ultimately able to stop the program that is sending the
bytes. Even though this program stops, the computer does not necessarily stop
computing. It may switch to running other processes while it's waiting at a
flow control stop. The above was a little oversimplified since there is another
alternative of having the application program itself do something else while it
is waiting to "write".
For many situations, there is a
transmit path involving several links, each with its own flow control. For example,
I type at a text-terminal connected to a PC with a modem to access a BBS. For
this I use the application program "minicom" which deals with 2
serial ports: one connected to a modem and another connected to the
text-terminal. What I type at the text terminal goes into the first serial port
to minicom, then from minicom out the second serial port to the modem, and then
onto the telephone line to the BBS. The text-terminal has a limit to the speed
at which bytes can be displayed on its screen and issues a flow control
"stop" from time to time to slow down the flow. What happens when
such a "stop" is issued? Let's consider a case where the
"stop" is long enough to get thru to the BBS and stop the program at
the BBS which is sending out the bytes.
Let's trace out the flow of this
"stop" (which may be "hardware" on some links and
"software" on others). First, suppose I'm "capturing" a
long file from the BBS which is being sent simultaneously to both my
text-terminal and a to file on my hard-disk. The bytes are coming in faster
than the terminal can handle them so it sends a "stop" out its serial
port to the first serial port on my PC. The device driver detects it and stops
sending bytes from the 8k serial buffer (in main memory) to the terminal. Now
minicom still keeps sending out bytes for the terminal into this 8k buffer.
When this 8k transmit buffer (on
the first serial port) is full, minicom must stop writing to it. Minicom stops
and waits. But this also causes minicom to stop reading from the 8k receive buffer
on the 2nd serial port connected to the modem. Flow from the modem continues
until this 8k buffer too fills up and sends a different "stop" to the
modem. Now the modem's buffer ceases to send to the serial port and also fills
up. The modem (assuming error correction is enabled) sends a "stop
signal" to the other modem at the BBS. This modem stops sending bytes out
of its buffer and when its buffer gets fill, another stop signal is sent to the
serial port of the BBS. At the BBS, the 8-k (or whatever) buffer fills up and
the program at the BBS can't write to it anymore and thus temporarily halts.
Thus a stop signal from a text
terminal has halted a programs on a BBS computer. What a complex sequence of
events! Note that the stop signal passed thru 4 serial ports, 2 modems, and one
application program (minicom). Each serial port has 2 buffers (in one direction
of flow): the 8k one and the hardware 16-byte one. The application program may
have a buffer in its C_code. This adds up to 11 different buffers the data is
passing thru. Note that the small serial hardware buffers do not participate
directly in flow control.
If the terminal speed limitation is
the bottleneck in the flow from the BBS to the terminal, then its flow control
"stop" is actually stopping the program that is sending from the BBS
as explained above. But you may ask: How can a "stop" last so long
that 11 buffers (some of them large) all get filled up? It can actually happen
this way if all the buffers were near their upper limits when the terminal sent
out the "stop".
But if you were to run a simulation
on it you would discover that it's usually more complicated than this. At an
instant of time some links are flowing and others are stopped (due to flow
control). A "stop" from the terminal seldom propagates back to the
BBS neatly as described above. It may take a few "stops" from the
terminal to result in one "stop" at the BBS. To understand what is
going on you really need to observe a simulation which can be done for a simple
case with coins on a table. Use only a few buffers and set the upper level for
each buffer at only a few coins.
Does one really need to understand
all this? Well, understanding this explained to me why capturing text from a
BBS was loosing text. The situation was exactly the above example but
modem-to-modem flow control was disabled. Chunks of captured text that were
supposed to also get to my hard-disk never got there because of an overflow at
my modem buffer due to flow control "stops" from the terminal. Even
though the BBS had a flow path to the hard-disk without bottlenecks, the
overflow due to the terminal happened on this path and chunks of text were lost
and never even made it to the hard-disk. Note that the flow to the hard-disk
passed thru my modem and since the overflow happened there, bytes intended for
the hard-disk were lost.
The device driver for the serial
port is the software that operates the serial port. It is now provided as a
serial module. >From kernel 2.2 on, this module will normally get loaded
automatically if it's needed. In earlier kernels, you had to have kerneld running in order to do auto-load
modules on demand. Otherwise the serial module needed to be explicitly listed
in /etc/modules. Before modules became popular with Linux, the serial driver
was usually built into the kernel (and sometimes still is). If it's built-in
don't let the serial module load or else you will have two serial drivers
running at the same time. With 2 drivers there are all sorts of errors including
a possible "I/O error" when attempting to open a serial port. Use
"lsmod" to see if the module is loaded.
When the serial module is loaded it
displays a message on the screen about the existing serial ports (often showing
a wrong IRQ). But once the module is used by setserial
to tell the device driver the (hopefully) correct IRQ then you should see a
second display similar to the first but with the correct IRQ, etc. See Serial
Module See What
is Setserial for more info on setserial.