|
|
| HowTo Linux Zone | Linux Zone Home | E-Mail Me | The Linux Serial HOWTO David S.Lawyer bf347@lafn.org original by Greg Hankins
v2.00 May 1999
This document describes serial port features other than those which
should be covered by Modem-HOWTO, PPP-HOWTO, Serial-Programming-HOWTO,
or Text-Terminal-HOWTO. It lists info on multiport serial cards. It
contains technical info about the serial port itself in more detail
than found in the above HOWTOs and should be best for troubleshooting
when the problem is the serial port itself. It doesn't yet cover PnP
serial ports but this is covered in Modem-HOWTO. If you are dealing
with a Modem, PPP (used for Internet access on a phone line), or Text-
Terminal, those HOWTOs should be consulted first.
______________________________________________________________________
Table of Contents
1. Introduction
1.1 Copyright, Disclaimer, & Credits
1.1.1 Copyright
1.1.2 Disclaimer
1.1.3 Credits
1.2 Release Notes
1.3 New Versions of this Serial-HOWTO
1.4 Related HOWTO's re the Serial Port
1.5 Feedback
1.6 What is a Serial Port?
2. How It Works --Overview
2.1 Transmitting
2.2 Receiving
2.3 The Large Serial Buffers
3. Serial Port Basics
3.1 What is a Serial Port ?
3.1.1 Introduction
3.1.2 Pins and Wires
3.1.3 RS-232 or EIA-232, etc.
3.2 I/O Address & IRQ
3.3 Interrupts
3.4 Data Flow (Speeds)
3.5 Flow Control
3.5.1 Flow Control Explained by an Example
3.5.2 Symptoms of No Flow Control
3.5.3 Hardware vs. Software Flow Control
3.6 Data Flow Path, Buffers
3.7 Complex Flow Control Example
4. Is the Serial Port Obsolete?
4.1 Introduction
4.2 EIA-232 Cable Is Low Speed & Short Distance
4.3 Inefficient Interface to the Computer
5. Multiport Serial Boards/Cards
5.1 Standard PC Serial Boards
5.2 Dumb Multiport Serial Boards (with 8250/16450/16550A UART's)
5.3 Intelligent Multiport Serial Boards
6. Configuring the I/O Address, IRQ, and Name
6.1 Introduction
6.2 Set I/O Address & IRQ
6.3 Can I Use More Than Two Serial Devices? Interrupt Conflicts
6.3.1 Choosing Serial IRQs (required only if your kernel version < 2.2)
6.3.2 Setting Serial Device Addresses
6.3.3 Giving the IRQ and IO Address to Setserial
6.4 Can Linux Configure The Serial Devices Automagically?
6.5 Notes For Multiport Boards
6.6 Devices: modem, mouse
6.7 The cua Device
6.8 Serial Port Devices and Numbers in the /dev directory
6.8.1 Creating Devices In the /dev Directory
6.9 Notes For Dumb Multiport Boards
6.10 Notes For Intelligent Multiport Boards
7. Interesting Programs You Should Know About
7.1 Serial Monitoring/Diagnostics Programs
7.2 Changing Interrupt Priority
7.3 What is Setserial ?
7.3.1 Introduction
7.3.2 Probing
7.3.3 Boot-time Configuration
7.3.4 IRQs
7.4 What is isapnp ?
8. Speed (Flow Rate)
8.1 Can't Set a High Enough Speed
8.2 Higher Serial Throughput
9. Communications Programs And Utilities
9.1 List of Software
9.2 kermit and zmodem
10. Serial Tips And Miscellany
10.1 Line Drivers
10.2 Known Defective Hardware
10.2.1 Problem with IBM 8514 Video Board
10.2.2 Problem with AMD Elan SC400 CPU (PC-on-a-chip)
10.3 What Are Lock Files ?
11. Troubleshooting
11.1 Serial Electrical Test Equipment
11.1.1 Breakout Gadgets, etc.
11.1.2 Measuring Voltages
11.1.3 Taste Voltage
11.2 Serial Monitoring/Diagnostics
11.3 My Serial Port is Physically There but Can't be Found
11.4 Slow: Text appears on the screen slowly after long delays
11.5 The Startup Screen Show Wrong IRQs for the Serial Ports.
12. Interrupt Problem Details
12.1 Mis-set Interrupts
12.2 Interrupt Conflict
12.3 Resolving Interrupt Problems
13. What Are UARTs?
14. Pinout and Signals
14.1 Pinout
14.2 Signals May Have No Fixed Meaning
14.3 Cabling Between Serial Ports
14.4 RTS/CTS and DTR/DSR Flow Control
14.4.1 The DTR and DSR Pins
14.5 Preventing a Port From Opening
15. Voltage Waveshapes
15.1 Voltage for a Bit
15.2 Voltage Sequence for a Byte
15.3 Parity Explained
15.4 Forming a Byte (Framing)
15.5 How "Asynchronous" is Synchronized
16. Other Serial Devices (not async EIA-232)
16.1 Successors to EIA-232
16.2 EIA-422-A (balanced) and EIA-423-A (unbalanced)
16.3 EIA-485
16.4 EIA-530
16.5 EIA-612/613
16.6 The Universal Serial Bus (USB)
16.7 Synchronization & Synchronous
16.7.1 Defining Asynchronous vs Synchronous
16.7.2 Synchronous Communication
17. Other Sources of Information
17.1 Books
17.2 Serial Software
17.3 Linux Documents
17.4 Usenet newsgroups:
17.5 Serial Mailing List
17.6 Internet
______________________________________________________________________
1. Introduction
This HOWTO covers basic info on the Serial Port and multiport serial
cards. Information specific to modems and text-terminals has been
moved to Modem-HOWTO and Text-Terminal-HOWTO. Info on getty has been
also moved to these HOWTOs since mgetty and uugetty are best for
modems while agetty is best for text-terminals. In the future, some
general info on getty troubleshooting will be put in this HOWTO. If
you are dealing with a modem, text terminal, or printer, then you may
not need to consult this HOWTO. But if you are using the serial port
for some other device, using a multiport serial card, trouble-shooting
the serial port itself, or want to understand more technical details
of the serial port, then you may need to use this HOWTO as well as
some of the other HOWTOs. (See ``Related HOWTO's'') This HOWTO lists
info on various multiport serial cards since they may be used for
either modems or text-terminals. This HOWTO addresses Linux running
on Intel x86 hardware, although it might work for other architectures.
1.1. Copyright, Disclaimer, & Credits
1.1.1. Copyright
Copyright (c) 1993-1997 by Greg Hankins, 1998-1999 by David S. Lawyer.
This document may be distributed under the terms set forth in the LDP
license at http://metalab.unc.edu/LDP/COPYRIGHT.html. This document
may not be distributed in modified form without consent of the author
(unless after a good faith effort the author can't be contacted).
1.1.2. Disclaimer
While I haven't intentionally tried to mislead you, there are likely a
number of errors in this document. Please let me know about them.
Since this is free documentation, it should be obvious that I cannot
be held legally responsible for any errors.
1.1.3. Credits
Most of the original Serial-HOWTO was written by Greg Hankins.
gregh@cc.gatech.edu He also rewrote many contributions by others in
order to maintain continuity in the writing style and flow. He wrote:
"Thanks to everyone who has contributed or commented, the list of
people has gotten too long to list (somewhere over one hundred).
Special thanks to Ted T'so for answering questions about the serial
drivers." Approximately half of v2.00 is from Greg Hankins HOWTO and
the other half is by David Lawyer.
1.2. Release Notes
This is a major revision which has removed info on Terminals and
Modems from the old Serial-HOWTO and put such info into:
· Text-Terminal-HOWTO
· Modem-HOWTO
I still haven't checked out the info on multiport cards to see if
it's up-to-date. More info has been added on how the serial port
works, the electrical properties of the serial port,
troubleshooting, and some brief info on non-RS-232 serial ports.
Much of this info was lifted directly from the above HOWTOs. The
fact that this HOWTO was pieced together from various sources has
resulted in a certain lack of integration. This will hopefully be
improved on in future versions.
1.3. New Versions of this Serial-HOWTO
New versions of the Serial-HOWTO will be available to browse and/or
download at LDP mirror sites. For a list of mirror sites see:
<http://metalab.unc.edu/LDP/mirrors.html>. Various formats are
available. If you only want to quickly check the date of the latest
version look at: <http://metalab.unc.edu/LDP/HOWTO/Serial-
HOWTO.html>.
1.4. Related HOWTO's re the Serial Port
Modems, Text-Terminals, some printers, and other peripherals run off
the serial port. Get these HOWTOs from the nearest mirror site as
explained above.
· Modem-HOWTO is about installing and configuring modems
· Printing-HOWTO has info on using a serial printer
· Serial-Programming-HOWTO helps you write C programs (or parts of
them) that handle the serial port. You may program the equivalent
of "stty ...", open ports in various modes, and more.
· Text-Terminal-HOWTO is about how they work, how to install
configure, and repair them.
1.5. Feedback
Please send me any questions, comments, suggestions, or additional
material. I'm always eager to hear about what you think about this
HOWTO. I'm also always on the lookout for improvements! Tell me
exactly what you don't understand, or what could be clearer. You can
reach me at name="bf347@lafn.org (David Lawyer)"> via email.
1.6. What is a Serial Port?
The conventional serial port (not the newer USB port) is a very old
I/O port. Almost all PC's have them. But Macs (Apple Computer) after
mid 1998 (with colored cases) only have the USB port. The common
specification is RS-232 (or EIA-232). The connector for the serial
port is often seen as one or two 9-pin connectors (in some cases
25-pin) on the back of a PC. But the serial port is is more than just
that. It includes the associated electronics which must produce
signals conforming to the EIA-232 specification. See ``Voltage
Waveshapes''. One pin is used to send out data bytes and another to
receive data bytes. Another pin is a common signal ground. The other
"useful" pins are used mainly for signalling purposes with a steady
negative voltage meaning "off" and a steady positive voltage meaning
"on".
The UART (Universal Asynchronous Receiver-Transmitter) chip does most
of the work. Today, the functionality of this chip is usually built
into another chip. See ``What Are UARTs?'' These have improved over
time and old models (several years old) are now obsolete.
The serial port was originally designed for connecting modems but it's
used to connect many other devices also such as mice, text-terminals,
some printers, etc. to a computer. You just plug these devices into
the serial port using the correct cable. Many internal modems card
have a built-in serial port so when you install one inside your PC
it's as if you just installed another serial port in your PC.
2. How It Works --Overview
2.1. Transmitting
Transmitting is sending bytes out of the serial port away from the
computer. What follows is an explanation of how older obsolete serial
ports work (with only 1-byte hardware buffers). Once you understand
the old ones it will be easy to understand the more modern ones. When
the computer wants to send a byte out the serial port the CPU sends
the byte on the bus inside the computer to the I/O address of the
serial port. The serial port takes the byte, and sends it out one bit
at a time (a serial bit-stream) on the transmit pin of the serial
connector. For what a bit (and byte) look like electrically see
``Voltage Waveshapes''.
Here's a replay of the above in some more (but not full) detail. Most
of the work at the serial port is done by the UART chip (or the like).
The device driver program, running on the CPU, sends a byte to the
serial's I/O address. This byte goes into a 1-byte transmit buffer in
the serial port. When the port is ready to transmit it, it moves this
byte to its transmit shift register and sends it out the transmit pin
bit-by-bit. Now the transit buffer is empty and another byte may be
put in it while the original byte is being transmitted from the
transmit shift register. Once a byte is completely transmitted, the
port takes another byte out of its transmit buffer and sends that bit-
by-bit also. It continues doing this as long as it finds a new byte
in the transmit buffer.
But that's not the whole story. In order for there not to be any gaps
in transmission, the CPU must keep the 1-byte transmit buffer supplied
with bytes. It does this by utilizing interrupts. As soon as a byte
has been moved out of the 1-byte transmit buffer (and is about to be
transmitted from the transmit shift register), the transmit buffer is
empty and needs another byte. The serial port then issues an
interrupt to say it is ready for the next byte. The interrupt is
actually a voltage put on a dedicated wire used only by that serial
port (although in some cases the same wire may be shared by more than
one port).
The device driver is notified about the interrupt and checks registers
at I/0 addresses to find out what has happened. It finds out that the
serial's transmit buffer is empty and waiting for another byte. So if
there are more bytes to send, it sends the next byte to the serial's
I/0 address. This next byte should arrive when the previous byte is
still in the transmit shift register and still being transmitted bit-
by-bit. This new byte goes into the transmit buffer but it can't be
moved into the transmit shift register until the previous byte there
has been completely sent out. When the last bit has been sent out the
following 3 things happen almost simultaneously:
1. Another new byte is moved from the transmit buffer into the
transmit shift register
2. The transmission of this new byte (bit-by-bit) begins
3. Another interrupt is issued to tell the device driver to send
another byte to the transmit buffer.
We thus say the serial port is interrupt driven. Each time the serial
port issues an interrupt, the CPU sends it another byte. Once a byte
has been sent to the transmit buffer by the CPU, then the CPU is free
to pursue some other activity until it gets the next interrupt. The
serial port transmits bits at a fixed rate which is selected by the
user. It's sometimes called the baud rate. The serial port adds
extra bits to each byte so there are often 10 bits sent per byte. At
a rate (also called speed) of 19,200 bits per second (bps), there are
thus 1,920 bytes/sec (and also 1,920 interrupts/sec).
Doing all this is a lot of work for the CPU. This is true for many
reasons. First, just sending one 8-bit byte at a time over a 32-bit
data bus (or even 64-bit) is not a very efficient use of bus width.
Also, there is a lot of overhead in handing each interrupt. When the
interrupt is received, the device driver only knows that something
caused an interrupt at the serial port but doesn't know that it's
because a character has been sent. The device driver has to make
various checks to find out what happened. The same interrupt could
mean that a character was received, one of the control lines changed
state, etc.
One improvement over the above has been the enlargement of the buffer
size of the serial port. Most serial ports today have 16-byte buffers
instead of just 1-byte buffers. This means that when the CPU gets an
interrupt it gives the serial port up to 16 new bytes to transmit.
This is fewer interrupts to service but data must still be transferred
one byte at a time over a wide bus.
2.2. Receiving
Receiving bytes by a serial port is similar to sending them only it's
in the opposite direction. It's also interrupt driven. For the
obsolete type of serial port with 1-byte buffers, when a byte is fully
received it goes into the 1-byte receive buffer. Then the port gives
the CPU an interrupt to tell it to pick up that byte so that the
serial port will have room for storing the byte which is currently
being received. For newer serial ports with 16-byte buffers, this
interrupt may be sent after 14 bytes are in the receive buffer. The
CPU then stops what it was doing, runs the interrupt service routine,
and picks up 14 or more bytes from the port. It will be more than 14
if any additional bytes arrive after the interrupt was issued. But if
3 or more new bytes have arrived, then the 16 byte buffer will overrun
since it can't store 17 (14 + 3) or more bytes.
2.3. The Large Serial Buffers
We've talked about small (1 or 16 byte) serial port buffers in the
hardware but there are also much larger buffers in main memory. When
the CPU takes a byte (or say 14 bytes) out of the receive buffer of
the hardware, it puts it into a huge (say 8K-byte) receive buffer in
main memory. Then a program that is getting bytes from the serial
port takes the bytes it's receiving out of that large buffer (using a
"read" statement in the program). A similar situation exists for
bytes that are to be transmitted. When the CPU needs to fetch some
bytes to be transmitted it takes them out of a large (8K-byte)
transmit buffer in main memory and puts them into the small transmit
buffer (1 or 16 bytes) in the hardware.
3. Serial Port Basics
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
much of what was said in the previous section ``How It Works
--Overview'' but in greater detail.
3.1. What is a Serial Port ?
3.1.1. Introduction
The serial port is an I/O (Input/Output) device. An I/O device is 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 and receive bytes from the receive pin.
The other pins are for control purposes and ground.
The serial port is much more than just a connector. It converts the
data from the 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 (and
conversely).
Most of the electronics of the serial port is found in a computer chip
(or a section of a chip) known as a UART. For more details on UARTs
see the section ``What Are UARTs? How Do They Affect Performance?''.
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.
3.1.2. Pins and Wires
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
connects to a wire. Besides the single 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. There are still
more wires which are for control purposes (signalling) only and not
for sending bytes. All of these signals could have been sent on a
single wire, but instead, there is a separate dedicated wire for every
type of signal. Some (or all) 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 are is a wire 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.
3.1.3. RS-232 or EIA-232, etc.
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)''
3.2. I/O Address & IRQ
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 what wire (IRQ number)
the serial port is to 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.
The serial ports are labeled ttyS0, ttyS1, etc. (corresponding to
COM1, COM2, etc. in DOS/Windows). Which one of these names refers to
certain physical serial port is determined by the I/O address stored
inside the hardware chip of the physical port. This mapping of names
(such as ttyS1) to I/O addresses and IRQ's may be set by the
"setserial" command. ``What is Setserial''. This does not set the
I/O address and IRQ on the hardware itself (which is set by jumpers or
by plug-and-play software).
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. If the address
matches, then the I/O device reads the data on the data bus.
3.3. Interrupts
When the serial port gets a byte (or sometimes after it gets say 8 or
14 bytes) it signals the CPU to fetch it (them) by sending an
electrical signal known as an interrupt on a dedicated conductor. It
will also send this interrupt if there is an unexpected delay while
waiting for the next byte to arrive (known as a timeout).
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 modems) 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 overflow (overrunning) may occur
(bytes will be lost). 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.
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 (part of the
serial driver software) to service the serial port called an interrupt
service routine (or interrupt handler). 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 I/O 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.
3.4. Data Flow (Speeds)
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.
3.5. Flow Control
Flow control means the ability to stop the flow of bytes in a wire.
It also includes provisions to restart the flow without any loss of
bytes. Flow control is needed for modems to allow a jump in flow
rates.
3.5.1. Flow Control Explained by an Example
For example, consider the case where you connect a 36.6k modem to your
serial port that simply sends and receives bytes over the phone line
at exactly 36.6k bits per second (bps). 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
is at 115.2k bps. However the flow from your modem out the phone line
is at best 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 eventually overrun (run out of storage space) unless the 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 (the
modem's) 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 this case 33.6k) which is
significantly less than the "on" flow rate of 115.2k bps. This is
"start-stop" flow control.
The above is a simple example of flow control for flow from the
computer to a modem , but there is also flow control which is used for
the opposite direction of flow: from a modem to a computer. This is
the essence of flow control but there are many more details to
explain.
Note that the transmit buffer in the modem as mentioned above is in
addition to the two transmit buffers of the serial port: the small
hardware buffer and the large one in main memory. Flow control
protects certain buffers from overflowing. The small hardware buffers
are not protected in this way but rely instead on a fast response to
the interrupts they issue.
3.5.2. Symptoms of No Flow Control
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.
3.5.3. Hardware vs. Software Flow Control
For modems, it's best to use "hardware" flow control that uses two
dedicated "modem control" wires to send the "stop" and "start" voltage
signals. See ``RTS/CTS, DTR and DTR/DSR Hardware Flow Control''.
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 thru
the modem since binary data will likely contain the control characters
DC1 and DC3 used for flow control.
3.6. Data Flow Path, Buffers
In addition to the pair of 16-byte serial port buffers (in the
hardware) 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.
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 hardware for transmission. Once in that transmit
buffer, there is no way to stop them from being transmitted. They are
then transmitted out of the serial port. 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 outgoing serial flow 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".
3.7. Complex Flow Control Example
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 Rube Goldberg (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.
4. Is the Serial Port Obsolete?
4.1. Introduction
The answer is yes, the serial port is obsolete but it's still needed,
especially for Linux. The serial port has many shortcomings but
almost all new PC's seem to come with them them. Linux supports
ordinary telephone modems only if they work thru a serial port.
The serial port must pass data between the computer and the external
cable. Thus it has two interfaces and both of these interfaces are
slow. First we'll consider the interface via external cable to the
outside world.
4.2. EIA-232 Cable Is Low Speed & Short Distance
The conventional EIA-232 serial port is inherently low speed and is
severely limited in distance. Ads often read "high speed" but it can
only work at "high speed" over very short distances such as to a modem
located right next to the computer. Compared to a network card, even
this "high speed" is low speed. All of the serial cable wires use a
common ground return wire so that twisted-pair technology (needed for
high speeds) can't be used without additional hardware. More modern
interfaces for serial ports exist but they are not very popular. See
``Successors to EIA-232''.
It is somewhat tragic that the RS-232 standard from 1969 did not use
twisted pair technology which could operate about a hundred times
faster. Twisted pairs have been used in telephone cables since the
late 1800's. In 1888 (over 110 years ago) the "Cable Conference"
reported its support of twisted-pair (for telephone systems) and
pointed out its advantages. But over 80 years after this approval by
the "Cable Conference", RS-232 failed to utilize it. Since RS-232
was originally designed for connecting a terminal to a low speed modem
located nearby, the need for high speed and longer distance
transmission was apparently not recognized.
4.3. Inefficient Interface to the Computer
To communicate with the computer, any I/O device needs to have an
address so that the computer can write to it and read from it. For
this purpose many I/O devices (such as serial ports) use a special
type of address known as an I/O addresses (sometimes called an I/O
port). It's actually a range of addresses and the lower address in
this range is the base address. If someone only says (or writes)
"address" it likely really means "base address"
Instead of using I/O, addresses some (non-serial) I/O devices read and
write directly from/to main memory. This provides more bandwidth
since the serial I/O system only moves a byte at a time. There are
various ways to read/write directly to main memory. One way is called
shared memory I/O (where the shared memory is usually on the same card
as the I/O device). Other methods are DMA (direct memory access) on
the ISA bus and what is about the same as DMA (only much faster):
"bus mastering" on the PCI bus. These methods are a lot faster than
those used for the serial port. Thus the conventional serial port
with it's interrupt driven (every 14 bytes) interface and single bytes
transfers on a bus which could accommodate 4 (or 8) bytes at a time is
not suited for very high speed I/O.
5. Multiport Serial Boards/Cards
5.1. Standard PC Serial Boards
Standard PC serial boards (COM1 - COM4) can be used to, to connect
external serial devices (modems, serial mice, etc...). Since PC's no
longer come with them (but have the chips for this purpose mounted on
the motherboard), they are hard to find in retail stores. An internal
modem for the ISA bus may include a built-in serial port.
Note: due to address conflicts, you cannot use COM4 and IBM8514 video
board (or clones) simultaneously. This is due to a bug in the IBM8514
board.
5.2. Dumb Multiport Serial Boards (with 8250/16450/16550A UART's)
They are also called "serial adapters".
* => "setserial" shows details of configuring
· AST FourPort and clones (4 ports) *
· Accent Async-4 (4 ports) *
· Arnet Multiport-8 (8 ports)
· Bell Technologies HUB6 (6 ports)
· Boca BB-1004 (4 ports), BB-1008 (8 ports), BB-2016 (16 ports; See
the mini-howto) *
· Boca IOAT66 or? ATIO66 (6 ports, Linux doesn't support it's IRQ
sharing ?? Uses odd-ball 10-cond RJ45-like connectors)
· Boca 2by4 (4 serial ports, 2 parallel ports)
· Byterunner (claims low prices)
· Computone ValuePort V4-ISA (AST FourPort compatible) *
· Digi PC/8 (8 ports)
· GTEK BBS-550 (8 ports; See the mini-howto)
· HUB-6 See Bell Technologies.
· Longshine LCS-8880, Longshine LCS-8880+ (AST FourPort compatible) *
· Moxa C104, Moxa C104+ (AST FourPort compatible) *
· PC-COMM (4 ports)
· Sealevel Systems <http://www.sealevel.com> COMM-2 (2 ports), COMM-4
(4 ports) and COMM-8 (8 ports)
· SIIG I/O Expander 2S IO1812 (4 ports)
· STB-4COM (4 ports)
· Twincom ACI/550
· Usenet Serial Board II (4 ports) *
In general, Linux will support any serial board which uses a 8250,
16450, 16550, 16550A, 16650 (or compatible) UART, or an internal modem
which emulates one of the above UARTs.
Note: the BB-1004 and BB-1008 do not support DCD and RI lines, and
thus are not usable for dialin modems. They will work fine for all
other purposes. Hayes ESP is supported after kernel version 2.1.15.
5.3. Intelligent Multiport Serial Boards
Make sure that a Linux compatible driver is available. This list is a
little out of date.
· Comtrol RocketPort (36MHz ASIC; 4, 8, 16 or 32 ports)
contact: info@comtrol.com or http://www.comtrol.com
driver status: supported by Comtrol
driver location: ftp://tsx-11.mit.edu/pub/linux/packages/comtrol
· Computone IntelliPort II (16MHz 80186; 4, 8, or 16 ports),
IntelliPort II EXpandable (20MHz 80186; 16 - 64 ports)
contact: Michael H. Warfield, mhw@wittsend.atl.ga.us
driver status: pre-ALPHA
· Cyclades Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),
Cyclom-Z (25MHz MIPS R3000; 8 - 128 ports)
contact: sales@cyclades.com or http://www.cyclades.com
driver status: supported by Cyclades
driver location: ftp://ftp.cyclades.com/pub/cyclades and included
in Linux kernel since version 1.1.75
· Decision PCCOM8 (8 ports)
contact: pccom8@signum.se
driver location: ftp://ftp.signum.se/pub/pccom8
· Digi PC/Xi (12.5MHz 80186; 4, 8, or 16 ports),
PC/Xe (12.5/16MHz 80186; 2, 4, or 8 ports),
PC/Xr (16MHz IDT3041; 4 or 8 ports),
PC/Xem (20MHz IDT3051; 8 - 64 ports)
contact: sales@dgii.com or http://www.dgii.com
driver status: supported by Digi
driver location: ftp://ftp.dgii.com/drivers/linux and included in
Linux kernel since version 2.0
· Digi COM/Xi (10MHz 80188; 4 or 8 ports)
contact: Simon Park, si@wimpol.demon.co.uk
driver status: ALPHA
note: Simon is often away from email for months at a time due to
his job. Mark Hatle, fray@krypton.mankato.msus.edu has graciously
volunteered to make the driver available if you need it. Mark is
not maintaining or supporting the driver.
· Equinox SuperSerial Technology (30MHz ASIC; 2 - 128 ports)
contact: sales@equinox.com or http://www.equinox.com
driver status: supported by Equinox
driver location: ftp://ftp.equinox.com/library/sst
· GTEK Cyclone (16C654 UARTs; 6, 16 and 32 ports),
SmartCard (24MHz Dallas DS80C320; 8 ports),
BlackBoard-8A (16C654 UARTs; 8 ports),
PCSS (15/24MHz 8032; 8 ports)
contact: spot@gtek.com or http://www.gtek.com
driver status: supported by GTEK
driver location: ftp://ftp.gtek.com/pub
· Hayes ESP (COM-bic; 1 - 8 ports)
contact: Andrew J. Robinson, arobinso@nyx.net or
http://www.nyx.net/~arobinso
driver status: Will be supported by Linux kernel (1998). Also
supported by author
driver location: http://www.nyx.net/~arobinso and included in Linux
kernel since version 2.1.15. Setserial 2.15+ supports.
· Maxpeed SS (Toshiba; 4, 8 and 16 ports)
contact: info@maxpeed.com or http://www.maxpeed.com
driver status: supported by Maxpeed
driver location: ftp://maxpeed.com/pub/ss
· Moxa C218 (12MHz 80286; 8 ports),
Moxa C320 (40MHz TMS320; 8 - 32 ports)
contact: info@moxa.com.tw or http://www.moxa.com.tw
driver status: supported by Moxa
driver location: ftp://ftp.moxa.com.tw/drivers/c218-320/linux
· SDL RISCom/8 (Cirrus Logic CD180; 8 ports)
contact: sales@sdlcomm.com or http://www.sdlcomm.com
driver status: supported by SDL
driver location: ftp://ftp.sdlcomm.com/pub/drivers
· Specialix SX (25MHz T225; 8? - 32 ports),
SIO/XIO (20 MHz Zilog Z280; 4 - 32 ports)
contact: <mailto:R.E.Wolff@BitWizard.nl>
driver status: BETA / Supported by Specialix
driver location: <http://www.BitWizard.nl/specialix/>
old driver location:
ftp://metalab.unc.edu/pub/Linux/kernel/patches/serial
· Stallion EasyIO-4 (4 ports), EasyIO-8 (8 ports), and
EasyConnection (8 - 32 ports) - each with Cirrus Logic CD1400
UARTs,
Stallion (8MHz 80186 CPU; 8 or 16 ports),
Brumby (10/12 MHz 80186 CPU; 4, 8 or 16 ports),
ONboard (16MHz 80186 CPU; 4, 8, 12, 16 or 32 ports),
EasyConnection 8/64 (25MHz 80186 CPU; 8 - 64 ports)
contact: sales@stallion.com or http://www.stallion.com
driver status: supported by Stallion
driver location: ftp://ftp.stallion.com/drivers/ata5/Linux and
included in linux kernel since 1.3.27
A review of Comtrol, Cyclades, Digi, and Stallion products was printed
in the June 1995 issue of the Linux Journal. The article is available
at http://www.ssc.com/lj/issue14.
6. Configuring the I/O Address, IRQ, and Name
6.1. Introduction
Configuring can be divided into two parts: The low level configuring
is done by assigning the port an I/O address, an IRQ number and a name
(such as ttyS1). It's done by setting jumpers (or using plug-and-play
methods to do the equivalent) and by the "setserial" program. That's
the topic of this section.
The high level configuring uses the "stty" program (or the equivalent
done by an application program). It assigns the serial port a speed
(baud rate), sets up the possible translation of certain characters
sent to the serial port, etc. It's covered (but not in detail) by the
manual page "stty". The meaning of some of the settings used by the
stty command are sometimes better explained in the "termios" manual
page.
In simple cases the serial ports configure themselves without the user
doing anything. Communication programs that use the serial port often
do the high level configuring. If you have a valid name for a serial
port such as /dev/ttyS1, then the low level configuring has already
been done. It often is done automatically by a call to "setserial"
which is made by a startup file which runs each time you start your
computer. Major distributions of Linux provide such a file with the
"setserial" command residing in it. See ``Boot-time Configuration''.
6.2. Set I/O Address & IRQ
See ``I/O Address & IRQ'' for an explanation of what these are. Each
serial port must have an I/O address, and an interrupt (IRQ). There
are the four serial ports corresponding to COM1 - COM4:
ttyS0 (COM1) address 0x3f8 IRQ 4
ttyS1 (COM2) address 0x2f8 IRQ 3
ttyS2 (COM3) address 0x3e8 IRQ 4
ttyS3 (COM4) address 0x2e8 IRQ 3
When Linux boots, the kernel may detect at least the first two serial
ports and display a message to that effect. Notice that by default
these devices have overlapping IRQs. Unless you use kernel 2.2 or
better you cannot use all of the ports in this default configuration,
and you must reassign different IRQs. See section ``Can I Use More
Than Two Serial Devices?'' on setting IRQs.
6.3.
Can I Use More Than Two Serial Devices? Interrupt Conflicts
You don't need to read this section, unless you want to use three or
more serial devices... (assuming you don't have a multiport board).
The number of serial ports you can use may be limited by the number of
port I/O addresses available (and prior to kernel 2.2 by the
availability of IRQs). These limits are not a Linux limitation, but a
limitation of the PC architecture. Each serial device must be
assigned it's unique I/O address range (and prior to kernel 2.2 its
unique IRQ). Unless you are using a multiport board designed for
interrupt sharing or using a kernel version 2.2 or better, Linux is
not designed to share interrupts. If you try to share an interrupt
when you shouldn't it may work out OK provided the two devices are not
operating at the same time. Otherwise, one device may work OK but the
other one will not and the program using it will hang (or be very
slow).
Multiport serial boards (at least the "intelligent" ones) are
specially designed to have multiple serial ports that share the same
IRQ for all serial ports on the board. This is one of the reasons why
they need special drivers (some of which are built into Linux). Linux
gets data from them by using a different I/O address for each port on
the board.
6.3.1. Choosing Serial IRQs (required only if your kernel version <
2.2)
Even if your kernel version is 2.2 or greater, you may want to set up
IRQs to avoid conflicts with other devices, or get slightly greater
efficiency by avoiding the sharing of IRQs. Your PC may normally come
with ttyS0 and ttyS2 at IRQ 4, and ttyS1 and ttyS3 at IRQ 3. You can
see what the driver thinks the assigned IRQs are by typing: setserial
-g /dev/ttyS*. These are not necessarily the same as set in the
hardware.
Looking at /proc/interrupts will show which IRQs are being used by
programs currently running. To use more than two serial devices, you
will have to reassign an interrupt. One choice is to reassign an
interrupt from your parallel port (provided it's not already taken by
a sound card). Your PC normally comes with IRQ 5 and IRQ 7 set up as
interrupts for your parallel ports, but few people use two parallel
ports. You can reassign one of the interrupts to a serial device, and
still happily use a parallel port. You will need the setserial
program to do this. In addition, you may have to set the jumpers on
your boards, or use plug-and-play methods.
You should set things up so that there is one, and only one interrupt
for each serial device unless you have kernel 2.2 or later. Here is
how Greg set his up in /etc/rc.d/rc.serial - you should do it in a
file which runs upon startup:
/sbin/setserial /dev/ttyS0 irq 3 # my serial mouse
/sbin/setserial /dev/ttyS1 irq 4 # my Wyse dumb terminal
/sbin/setserial /dev/ttyS2 irq 5 # my Zoom modem
/sbin/setserial /dev/ttyS3 irq 9 # my USR modem
Standard IRQ assignments:
IRQ 0 Timer channel 0 (May mean "no interrupt". See below.)
IRQ 1 Keyboard
IRQ 2 Cascade for controller 2
IRQ 3 Serial port 2
IRQ 4 Serial port 1
IRQ 5 Parallel port 2, Sound card
IRQ 6 Floppy diskette
IRQ 7 Parallel port 1
IRQ 8 Real-time clock
IRQ 9 Redirected to IRQ2
IRQ 10 not assigned
IRQ 11 not assigned
IRQ 12 not assigned
IRQ 13 Math coprocessor
IRQ 14 Hard disk controller 1
IRQ 15 Hard disk controller 2
IRQ 0 is special for the serial port. It tells the driver that there
is no interrupt for it and the driver then will use polling methods.
This is quite inefficient but can be tried if there is an interrupt
conflict or mis-set interrupt. The advantage of assigning this is
that you don't need to know what interrupt is set in the hardware. It
should be used only as a temporary expedient until you are able to
find a real interrupt to use.
There is really no Right Thing to do when choosing interrupts. Just
make sure it isn't being used by the motherboard, or any other boards.
2, 3, 4, 5, or 7 is a good choice. ``not assigned'' means that
currently nothing standard uses these IRQs. Also note that IRQ 2 is
the same as IRQ 9. You can call it either 2 or 9, the serial driver
is very understanding. If you have a serial board with a 16-bit bus
connector, you can also use IRQ 10, 11, 12 or 15.
Just make sure you don't use IRQs 1, 6, 8, 13 or 14! These are used
by your mother board. You will make her very unhappy by taking her
IRQs. When you are done, double-check /proc/interrupts when programs
that use interrupts are being run and make sure there are no
conflicts.
6.3.2. Setting Serial Device Addresses
Next, you must set the port address. Check the manual on your board
for the jumper settings or use plug-and-play methods (See Plug-and-
Play-HOWTO). There can only be one serial device at each address.
Your ports will usually come configured as follows:
ttyS0 address 0x3f8
ttyS1 address 0x2f8
ttyS2 address 0x3e8
ttyS3 address 0x2e8
Choose which address you want each serial device to have and set the
jumpers (or use plug-and-play) accordingly. Greg had his modem on
ttyS2, his mouse and printer on ttyS1, and his text-terminal on ttyS0.
6.3.3. Giving the IRQ and IO Address to Setserial
Now you need to edit the "setserial" command which is run each time
you start linux. If it uses the autoconfig option then it will show
the type of uart found. If it reports "unknown" there may be no uart
there. When you reboot, Linux should display the IRQ and IO addresses
the serial that driver the serial driver thinks is correct (It may be
wrong).
If you look at the boot-time messages on the screen, the IRQ Linux
first reports may not correspond to the IRQ you gave to setserial. In
this case wait and see if you see the same message later with the
correct IRQ. The first message is when running setserial was
initiated by the kernel and not by the setserial command in a file.
Linux does not normally do any IRQ detection when it boots, because
IRQ detection is dicey and can be fooled. You can check /proc/ioports
to see what I/O port addresses are in use by currently running
processes after Linux boots.
6.4. Can Linux Configure The Serial Devices Automagically?
Yes. If it's not already set up like this (or close to it) you may
set Linux up to detect and set up the serial devices automatically on
startup. If needed add the line:
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
to your /etc/rc.d/rc.serial or /etc/rc.boot/0setserial file. Do this
for every serial port you want to auto configure. Be sure to give a
device name that really does exist on your machine.
6.5. Notes For Multiport Boards
For board addresses, and IRQs, look at the rc.serial or
/etc/rc.boot/0setserial that comes with the setserial program. It has
a lot of detail on multiport boards, including I/O addresses and
device names.
6.6. Devices: modem, mouse
On some installations, two extra devices will be created, /dev/modem
for your modem and /dev/mouse for your mouse. Both of these are
symbolic links to the appropriate device in /dev which you specified
during the installation (unless you have a bus mouse, then /dev/mouse
will point to the bus mouse device).
There has been some discussion on the merits of /dev/mouse and
/dev/modem. I discourage the use of these links. In particular, if
you are planning on using your modem for dialin you may run into
problems because the lock files may not work correctly if you use
/dev/modem. Use them if you like, but be sure they point to the right
device. However, if you change or remove this link, some applications
(minicom for example) might need reconfiguration.
6.7. The cua Device
Each ttyS device has a corresponding cua device. It is planned to
abolish cua so it's best to use ttyS instead (unless you know cua is
required). There is a difference between cua and ttyS but a savvy
programmer can make a ttyS port behave just like a cua port so there
is no real need for the cua anymore. Except that some older programs
may need to use the cua.
What's the difference? The main difference between cua and ttyS has
to do with what happens in a C_program when an ordinary "open" command
tries to open the port. If a cua port has been set to check modem
control signals, the port can be opened even if the DCD modem control
signal says not to. Astute programming can force a ttyS port to
behave this way also. Thus a cua port can be easily opened for
dialing out on a modem even when the modem fails to assert DCD (since
no one has called into it and it's not connected). That's why cua was
once used for dial-out and ttyS used for dial-in.
6.8. Serial Port Devices and Numbers in the /dev directory
/dev/ttyS0 major 4, minor 64 /dev/cua0 major 5, minor 64
/dev/ttyS1 major 4, minor 65 /dev/cua1 major 5, minor 65
/dev/ttyS2 major 4, minor 66 /dev/cua2 major 5, minor 66
/dev/ttyS3 major 4, minor 67 /dev/cua3 major 5, minor 67
Note that all distributions should come with ttyS devices already made
correctly (and possibly with cua devices also). You can verify this
by typing:
linux% ls -l /dev/cua*
linux% ls -l /dev/ttyS*
6.8.1. Creating Devices In the /dev Directory
If you don't have a device, you will have to create it with the mknod
command. Example, suppose you needed to create devices for ttyS0:
linux# mknod -m 666 /dev/ttyS0 c 4 64
linux# mknod -m 666 /dev/cua0 c 5 64
You can use the MAKEDEV script, which lives in /dev. This simplifies
the making of devices. For example, if you needed to make the devices
for ttyS0 you would type:
linux# cd /dev
linux# ./MAKEDEV ttyS0
This should also set the correct permissions.
6.9. Notes For Dumb Multiport Boards
The devices your multiport board uses depends on what kind of board
you have. Some of these may be listed in detail in rc.serial or in
0setserial. These files may be in the setserial package. I highly
recommend getting the latest version of setserial if you are trying to
use multiport boards. You will probably need to create these devices.
Either use the mknod command, or the MAKEDEV script. Devices for
multiport boards are made by adding ``64 + port number''. So, if you
wanted to create devices for ttyS17, you would type:
linux# mknod -m 666 /dev/cua17 c 5 81
linux# mknod -m 666 /dev/ttyS17 c 4 81
Note that ``64 + 17 = 81''. Using the MAKEDEV script, you would type:
linux# cd /dev
linux# ./MAKEDEV ttyS17
Note: the SIIG manual for the IO1812 listing for COM5-COM8 is wrong.
They should be COM5=0x250, COM6=0x258, COM7=0x260, and COM8=0x268.
Note: the Digi PC/8 Interrupt Status Register is at 0x140.
Note: for an AST Fourport, you might need to specify skip_test in
rc.serial.
6.10. Notes For Intelligent Multiport Boards
Read the information that comes with the driver. These boards use
special devices, and not the standard ones. This information varies
depending on your hardware.
7. Interesting Programs You Should Know About
Most info on getty has been moved to Modem-HOWTO with a little info on
the use of getty with directly connected terminals now found in Text-
Terminal-HOWTO.
7.1. Serial Monitoring/Diagnostics Programs
A few Linux programs will monitor the modem control lines and indicate
if they are positive (1) or negative (0).
· statserial
· modemstat (only works on Linux PC consoles. Will coexist with
command line)
· serialmon (doesn't monitor RTS, CTS, DSR but logs other functions)
You may already have them. If not, download them from Serial
Software <http://metalab.unc.edu/pub/Linux/system/serial/>. As of
June 1998, I know of no diagnostic program in Linux for the serial
port.
7.2. Changing Interrupt Priority
· irqtune will give serial port interrupts higher priority to improve
performance.
· hdparm for hard-disk tuning may help some more.
7.3. What is Setserial ?
7.3.1. Introduction
setserial is a program which allows you to tell the device driver
software the I/O address of the serial port, which IRQ is set in the
port's hardware, etc. With appropriate options, it can also probe (at
a given I/O address) for a serial port but you must guess the I/O
address (or it may use whatever address the driver thinks your
/dev/ttySx is at). Setserial does not set either IRQ's nor I/O
addresses in the serial port hardware itself. You must tell setserial
the identical values that have been set in the hardware. It's set in
the hardware either by jumpers or by plug-and-play. Do not just
invent some values that you think would be nice to use. However, if
you know the I/O address but don't know the IRQ you may command
setserial to attempt to determine it.
You can see a list of possible commands to use (but not the one-letter
options such as -v for verbose --which you should normally use when
troubleshooting) by typing setserial with no arguments. Note that
setserial calls an I/O address a "port". If the argument to setserial
is for example just /dev/ttyS1, then you'll see some info about how
that device driver is configured for that port. But this doesn't tell
you if the hardware actually has these values set in it. If fact, you
can run setserial and assign a purely fictitious I/O address, any IRQ,
and whatever uart type you would like to have. Then the next time you
type "setserial ..." it will display these bogus values without
complaint. Note that assignments made by setserial are lost when the
PC is powered down so it is usually run automatically somewhere each
time that Linux is booted.
7.3.2. Probing
In order to try to find out if you have a certain piece of serial
hardware you must first know its I/O address (or the device driver
must have an I/O address for it, likely previously set by setserial).
To try to detect the physical hardware use the -v (verbose) and
autoconfig command to setserial. If the resulting message shows a
uart type such as 16550A, then you're OK. If instead it shows
"unknown" for the uart type, then there is likely no serial port at
all at that I/O address. Some cheap serial ports don't identify
themselves correctly so if you see "unknown" you still might have
something there. See the file in which "setserial" is run at boot-
time. Besides auto-probing for uart type, setserial can auto-probe
for IRQ's but this doesn't always work right either.
7.3.3. Boot-time Configuration
There should be a file somewhere that runs setserial early at boot-
time before any process uses the serial port. If it's not run at
boot-time then your Linux system will automatically configure only
ttyS{0-3} using the default IRQs of 4 and 3 (with the default IRQ
conflicts). In 1998 it was (temporarily ?) changed to only ttyS{0-1}.
So if you have more than 2 serial ports, or want to have control over
how the ports are configured you should configure using setserial. In
fact, your distribution may have set things up so that the setserial
program runs automatically at boot-time. It's claimed that Redhat 6.0
failed to provide for this.
The file that runs setserial at boot-time is likely somewhere in the
/etc directory-tree. You might use "locate" to find a file named:
rc.serial, or 0setserial (Debian), etc. If no such file exists you
may need to create it and make sure that it gets run at boot-time. If
such a file is supplied, it should contain a number of commented-out
examples. By uncommenting some of these and/or modifying them, you
should be able to set things up correctly. Make sure that you are
using a valid path for setserial, and a valid device name. You could
do a test by executing this file manually (just type its name as the
super-user) to see if it works right. Testing like this is a lot
faster than doing repeated reboots to get it right. Of course you can
also test a single setserial command by just typing it on the command
line.
The file most commonly used to run setserial at boot-time is
/etc/rc.d/rc.serial. The Debian distribution uses
/etc/rc.boot/0setserial. Another file some have used is
/etc/rc.d/rc.local but it's not a good idea to use this since it may
not be run early enough. It's been reported that other processes may
try to open the serial port before rc.local runs resulting in serial
communication failure.
7.3.4. IRQs
By default, both ttyS0 and ttyS2 share IRQ 4, while ttyS0 and ttyS3
share IRQ 3. But sharing serial interrupts is not permitted unless
you have kernel 2.2 or better. If you don't have this modern kernel
but only have two serial ports ttyS0 and ttyS1 you're still OK since
IRQ sharing conflicts don't exist for non-existent devices.
But if you do have more than 2 serial ports, then for kernels < 2.2
such sharing may be dangerous if the two devices with the same IRQ are
being used at the same time. If you add an internal modem and retain
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
it both on your modem card (or serial port) and then use setserial to
assign it to your device driver. If IRQ 5 is not being used for a
sound card, this may be one you can use for a modem. To set the IRQ
in hardware you may need to use isapnp, a PnP BIOS or patch Linux to
make it PnP. To help you determine which spare IRQ's you might have,
type "man setserial" and search for say: "IRQ 11".
7.4. What is isapnp ?
isapnp is a program to configure Plug-and-Play (PnP) devices on the
ISA bus including internal modems. It comes in a package called
"isapnptools" and includes another program, "pnpdump" which finds all
your ISA PnP devices and shows you options for configuring them in a
format which may be added to the PnP configuration file:
/etc/isapnp.conf. The isapnp command may be put into a startup file
so that it runs each time you start the computer and thus will
configure ISA PnP devices. It is able to do this even if your BIOS
doesn't support PnP. See Plug-and-Play-HOWTO.
8. Speed (Flow Rate)
By "speed" we really mean the "data flow rate" but almost everybody
incorrectly calls it speed. The speed is measured in bits/sec (or
baud). Speed is set using the "stty" command or by a program which
uses the serial port.
8.1. Can't Set a High Enough Speed
You need to find out the highest speed supported by your hardware. As
of late 1998 most hardware only supported speeds up to 115.2K bps. If
you have a application program that doesn't show high enough speeds
in its menu, then there are some options you can give to the setserial
command so that a low speed command from the communication program
will actually result in a higher speed. With these options, when you
set the speed for 38400 the actual speed will be higher. See the man
page for "setserial" and search for speed_hi, spd_cust, baud_base, and
divisor. Note that you must set baud_base to the actual maximum speed
of the hardware. This speed is usually lower than the frequency of
the crystal oscillator in the hardware since the crystal frequency is
often divided by 16 in the hardware to give the maximum clock speed
for bit pulses. The reason the crystal frequency needs to be higher
is so that its full clock signal can be used to take several samples
of a bit pulse at the highest speed. If your software doesn't permit
typing in a speed of 230400 to an application program but your
physical serial port supports 230400 then you could try the following:
setserial /dev/ttyS2 spd_cust baud_base 230400 divisor 1
Then to get a speed of 230400 you must claim to the application
program that the speed is 38400. See the man page for setserial for
more info about this.
If you use setserial test it on the command line first, and then when
you have it working, put it into /etc/rc.d/rc.serial or
/etc/rc.boot/0setserial so that they are run at startup. Make sure
that you are using a valid path for setserial, and a valid device
name. You can check the settings of a serial port by running:
setserial -a /dev/ttyS3
8.2. Higher Serial Throughput
If you are seeing slow throughput and serial port overruns on a system
with (E)IDE disk drives, you can get hdparm. This is a utility that
can modify (E)IDE parameters, including unmasking other IRQs during a
disk IRQ. This will improve responsiveness and will help eliminate
overruns. Be sure to read the man page very carefully, since some
drive/controller combinations don't like this and may corrupt the
filesystem.
Also have a look at a utility called irqtune that will change the IRQ
priority of a device, for example the serial port that your modem is
on. This may improve the serial throughput on your system. The
irqtune FAQ is at http://www.best.com/~cae/irqtune.
9. Communications Programs And Utilities
9.1. List of Software
Here is a list of some communication software you can choose from,
available via FTP, if they didn't come with your distribution.
· ecu - a communications program
· C-Kermit <http://www.columbia.edu/kermit/> - portable, scriptable,
serial and TCP/IP communications including file transfer,
character-set translation, and zmodem support
· minicom - telix-like communications program
· procomm - procomm-like communications program with zmodem
· seyon - X based communication program
· xc - xcomm communication package
· term and SLiRP offer TCP/IP functionality using a shell account.
· screen is another multi-session program. This one behaves like the
virtual consoles.
· callback is where you dial out to a remote modem and then that
modem hangs up and calls you back (to save on phone bills).
· mgetty+fax handles FAX stuff, and provides an alternate ps_getty.
· ZyXEL is a control program for ZyXEL U-1496 modems. It handles
dialin, dialout, dial back security, FAXing, and voice mailbox
functions.
· SLIP and PPP software can be found at
ftp://metalab.unc.edu/pub/Linux/system/network/serial.
9.2. kermit and zmodem
To use zmodem with kermit, add the following to your .kermrc:
define rz !rz < /dev/ttyS3 > /dev/ttyS3
define sz !sz \%0 > /dev/ttyS3 < /dev/ttyS3
Be sure to put in the correct port your modem is on. Then, to use it,
just type rz or sz <filename> at the kermit prompt.
10. Serial Tips And Miscellany
Here are some serial tips you might find helpful...
10.1. Line Drivers
For a text terminal, the EIA-232 speeds are fast enough but the usable
cable length is often too short. Balanced technology could fix this.
The common method of obtaining balanced communication with a text
terminal is to install 2@ line drivers in the serial line to convert
unbalanced to balanced (and conversely). They are a specialty item
and are expensive if purchased new.
10.2. Known Defective Hardware
10.2.1. Problem with IBM 8514 Video Board
The address of this board (and it's clones) is allegedly 0x2e8, the
same as the address of ttyS3. That is bad news if you try to use
ttyS3 at this address. Another story is that Linux will not detect
your internal modem on ttyS3 but that you can use setserial to put
ttyS3 at this address and the modem pill work fine.
10.2.2. Problem with AMD Elan SC400 CPU (PC-on-a-chip)
This has a race condition between an interrupt and a status register
of the UART. An interrupt is issued when the UART transmitter
finishes the transmission of a byte and the UART transmit buffer
becomes empty (waiting for the next byte). But a status register of
the UART doesn't get updated fast enough to reflect this. As a
result, the interrupt service routine rapidly checks and determines
(erroneously) that nothing has happened. Thus no byte is sent to the
port to be transmitted and the UART transmitter waits in vain for a
byte that never arrives. If the interrupt service routine had waited
just a bit longer before checking the status register, then it would
have been updated to reflect the true state and all would be OK.
There is a proposal to fix this by patching the serial driver. But
Should linux be patched to accommodate defective hardware, especially
if this patch may impair performance of good hardware?
10.3. What Are Lock Files ?
A lock file is simply a file saying that a particular device is in
use. They are kept in /var/lock. Formerly they were in
/usr/spool/uucp. Linux lock files are named LCK..name, where name is
either a device name, or a UUCP site name. Certain processes create
these locks so that they can have exclusive access to devices. For
instance if you dial out on your modem, a lock will appear telling
other processes that someone is using the modem already. Locks mainly
contain the PID of the process that has locked the device. Most
programs look at the lock, and try to determine if that lock is still
valid by checking the process table for the process that has locked
the device. If the lock is found to be valid, the program (should)
exit. If not, some programs remove the stale lock, and use the
device, creating their own lock in the process. Other programs just
exit and tell you that the device is in use.
Having the same physical serial port known by two different device
names (such as ttyS0 and cua0) could cause problems. The lock
checking software is aware of ttyS vs. cua but it will make things
simpler in this regard by the planned elimination of cua. See ``The
cua Device''. In other cases, assigning an alternate name to the same
device is asking for trouble.
11. Troubleshooting
See Modem-HOWTO for troubleshooting related to modems or getty for
modems.
11.1. Serial Electrical Test Equipment
11.1.1. Breakout Gadgets, etc.
While a multimeter (used as a voltmeter) may be all that you need for
just a few terminals, simple special test equipment has been made for
testing serial port lines. Some are called "breakout ... " where
breakout means to break out conductors from a cable. These gadgets
have a couple of connectors on them and insert into the serial cable.
Some have test points for connecting a voltmeter. Others have LED
lamps which light when certain modem control lines are asserted
(turned on). Still others have jumpers so that you can connect any
wire to any wire. Some have switches.
Radio Shack sells (in 1998) a "RS-232 Troubleshooter" or "RS-232 Line
Tester" which checks TD, RD, CD, RTS, CTS, DTR, and DSR. A green
light means on (+12 v) while red means off (-12 v). They also sell a
"RS-232 Serial Jumper Box" which permits connecting the pins anyway
you choose.
11.1.2. Measuring Voltages
Any voltmeter or multimeter, even the cheapest that sells for about
$10, should work fine. Trying to use other methods for checking
voltage is tricky. Don't use a LED unless it has a series resistor to
reduce the voltage across the LED. A 470 ohm resistor is used for a
20 ma LED (but not all LED's are 20 ma). The LED will only light for
a certain polarity so you may test for + or - voltages. Does anyone
make such a gadget for automotive circuit testing?? Logic probes may
be damaged if you try to use them since the TTL voltages for which
they are designed are only 5 volts. Trying to use a 12 V incandescent
light bulb is not a good idea. It won't show polarity and due to
limited output current of the UART it probably will not even light up.
To measure voltage on a female connector you may plug in a bent paper
clip into the desired opening. The paper clip's diameter should be no
larger than the pins so that it doesn't damage the contact. Clip an
alligator clip (or the like) to the paper clip to connect up.
11.1.3. Taste Voltage
As a last resort, if you have no test equipment and are willing to
risk getting shocked (or even electrocuted) you can always taste the
voltage. Before touching one of the test leads with your tongue, test
them to make sure that there is no high voltage on them. Touch both
leads (at the same time) to one hand to see if they shock you. Then
if no shock, wet the skin contact points by licking and repeat. If
this test gives you a shock, you certainly don't want to use your
tongue.
For the test for 12 V, Lick a finger and hold one test lead in it.
Put the other test lead on your tongue. If the lead on your tongue is
positive, there will be a noticeable taste. You might try this with
flashlight batteries first so you will know what taste to expect.
11.2. Serial Monitoring/Diagnostics
A few Linux programs will monitor the modem control lines and indicate
if they are positive (1) or negative (0). See section ``Serial
Monitoring/Diagnostics''
11.3. My Serial Port is Physically There but Can't be Found
For the PCI bus look at /proc/pci. Check the BIOS menus. If it's a
PnP serial port, try "pnpdump --dumpregs" and/or see Plug-and-Play-
HOWTO.
Here are some common mistakes people make:
· setserial: They run it (without the "autoconfig" option) or see it
displayed on the screen at boot-time, and erroneously think that
the result shows how their hardware is actually configured.
· /proc/interrupts: When their serial device isn't in use they don't
see its interrupt there, and erroneously conclude that their serial
port can't be found (or doesn't have an interrupt set).
· /proc/ioports: People think this shows the hardware configuration
when it only shows about the same data (possibly erroneous) as
setserial.
You may probe for the serial port using "setserial" with the
"autoconfig" argument at the I/O address you think the serial port is
at. If it shows "unknown" for UART type there may be nothing there.
See ``What is Setserial''.
11.4. Slow: Text appears on the screen slowly after long delays
This may happen with a modem, terminal, or printer. In most cases
only a few words appear and then there is a long wait of many seconds
for the next batch of a few words. For obsolete serial ports, instead
of a few words there is only a single character. You may type but
what you type doesn't appear on the screen. After a delay of many
seconds you may see what you typed (or part of it).
It's likely slow because interrupt are not working. This may be due
to either an ``Interrupt Conflict'' or a ``Mis-set Interrupts''. It's
a conflict when two devices try to use the same IRQ. It's mis-set if
the device driver listens for the wrong IRQ. In either case things
will work very slowly (or seemingly not at all). You could get "input
overrun" error messages (or find them in logs).
Make sure there are no IRQs being illegally shared. Check all your
boards (serial, ethernet, SCSI, etc...). Make sure the jumper (or
PnP) settings, and the setserial parameters are correct for all your
serial devices. Also check /proc/ioports and /proc/interrupts and
/proc/pci for conflicts.
11.5. The Startup Screen Show Wrong IRQs for the Serial Ports.
Linux does not do any IRQ detection on startup. It only does serial
device detection. Thus, disregard what it says about the IRQ, because
it's just assuming the standard IRQs. This is done, because IRQ
detection is unreliable, and can be fooled. But when setserial
changes the IRQ's, you should see this on the startup screen.
So, even though I have my ttyS2 set at IRQ 5, I still see
tty02 at 0x03e8 (irq = 4) is a 16550A
at first when Linux boots. You have to use setserial to tell Linux
the IRQ you are using.
12. Interrupt Problem Details
While the section ``Troubleshooting'' lists problems by symptom, this
section explains what will happen if interrupts are set incorrectly.
This section helps you understand what caused the symptom, what other
symptoms might be due to the same problem, and what to do about it.
12.1. Mis-set Interrupts
If you don't understand what an interrupt does see ``Interrupts''. If
a serial port has one IRQ set in the hardware but a different one set
in the device driver, the device driver will not receive any
interrupts sent by the serial port. Since the serial port uses
interrupts to tell its driver when it needs service (fetching bytes
from it's 16-byte receive buffer or putting another 16-bytes in its
transmit buffer) one might expect that the serial port would not work
at all.
But it still may work anyway --sort of. Why? Well, besides the
interrupt method of servicing the port there's a slow polling method
that doesn't need interrupts. The way it works is that every so often
the device driver checks the serial port to see if it needs anything
such as if it has some bytes that need fetching from its receive
buffer. If interrupts don't work, the serial driver falls back to
this polling method. But this polling method was not intended to be
used a substitute for interrupts. It's so slow that it's not
practical to use and may cause buffer overruns. Its purpose may have
been to get things going again if just one interrupt is lost or fails
to do the right thing. It's also useful in showing you that
interrupts have failed.
For the 16-byte transmit buffer, 16 bytes will be transmitted and then
it will wait until the next polling takes place (several seconds
later) before the next 16 bytes is sent out. Thus transmission is
very slow and in small chunks. Receiving is slow too since bytes that
are received by the receive buffer are likely to remain there for
several seconds until it is polled.
This explains why it takes so long before you see what you typed.
When you type say AT to a modem, the AT goes out the serial port to
the modem. The modem then echos the AT back thru the serial port to
the screen. Thus the AT characters have to pass twice thru the serial
port. Normally this happens so fast that AT seems to appear on the
screen at the same time you hit the keys on the keyboard. With
polling delays thru the serial port, you don't see what you typed
until many seconds later.
What about overruns of the 16-byte receive buffer? This will happen
with an external modem since the modem just sends to the serial port
at high speed which is likely to overrun the 16-byte buffer. But for
an internal modem, the serial port is on the same card and it's likely
to check that this receive buffer has room for more bytes before
putting received bytes into it. In this case there will be no overrun
of this receive buffer, but text will just appear on your screen in
16-byte chunks at intervals of several seconds.
Even with an external modem you might not get overruns. If just a few
characters (under 16) are sent you don't get overruns since the buffer
likely has room for them. But attempts to send a larger number of
bytes from your modem to your screen may result in overruns. However,
more than 16 (with no gaps) can get thru OK if the timing is right.
For example, if 32 bytes were received (and no more bytes followed),
the polling might just happen after the first 16 bytes had been
received. Then there would be space for the next 16 bytes so that 32
bytes gets thru OK. Similar conditions might pass between 16 to 31
bytes thru OK. But it's also likely that only an occasional 16-byte
chunk will get thru and huge gaps of missing data will be lost.
If you have an obsolete serial port with only a 1-byte buffer (or it's
been incorrectly set to work like a 1-byte buffer) then the situation
will be much worse than described above and only one character will
occasionally make it thru the port. Every character received causes
an overrun (and is lost) except for the last character received. This
character is likely to be just a line-feed since this is often the
last character to be transmitted in a burst of characters sent to your
screen. Thus you may type AT<return> to the modem but never see AT on
the screen. All you see several seconds later is that the cursor
drops down one line (a line feed). This has happened to me with a
16-byte FIFO buffer that was behaving like a 1-byte buffer.
When a communication program starts up, it expects interrupts to be
working. It's not geared to using this slow polling-like mode of
operation. Thus all sorts of mistakes may be made such as setting up
the serial port and/or modem incorrectly. It may fail to realize when
a connection has been made. If a script is being used for login, it
may fail (caused by timeout) due to the polling delays.
12.2. Interrupt Conflict
When two devices have the same IRQ number it's called sharing
interrupts. Under some conditions this sharing works out OK.
Starting with kernel version 2.2, serial ports may share interrupts
with other serial ports. Devices on the PCI bus may share the same
IRQ interrupt with other devices on the PCI bus. In other cases where
there is potential for conflict, there should be no problem if no two
devices with the same IRQ are ever "in use" at the same time. More
precisely, "in use" really means "open" (in programmer jargon). In
cases other than the exceptions mentioned above (unless special
software permits sharing), sharing is not allowed and conflicts arise
if sharing is attempted.
Even if two processes with conflicting IRQs run at the same time, one
of the devices will likely have its interrupts sent to its device
driver and may work OK. The other device will not have its interrupts
sent to the correct driver and will likely behave just like a process
with mis-set interrupts. See ``Mis-set Interrupts'' for more details.
12.3. Resolving Interrupt Problems
If you are getting a very slow response as described above, then find
out what
13. What Are UARTs?
UARTs (Universal Asynchronous Receiver Transmitter) are serial chips
on your PC motherboard (or on an internal modem card). The UART
function may also be done on a chip that does other things as well.
On older computers like many 486's, the chips were on the disk I/O
controller card. Still older computer have dedicated serial boards.
The UART's purpose is to convert bytes from the PC's parallel bus to a
serial bit-stream. The cable going out of the serial port is serial
and has only one wire for each direction of flow. The serial port
sends out a stream of bits, one bit at a time. Conversely, the bit
stream that enters the serial port via the external cable is converted
to parallel bytes that the computer can understand. UARTs deal with
data in byte sized pieces, which is conveniently also the size of
ASCII characters.
Say you have a terminal hooked up to your PC. When you type a
character, the terminal gives that character to it's transmitter (also
a UART). The transmitter sends that byte out onto the serial line,
one bit at a time, at a specific rate. On the PC end, the receiving
UART takes all the bits and rebuilds the (parallel) byte and puts it
in a buffer.
There are two basic types of UARTs: dumb UARTS and FIFO UARTS. Dumb
UARTs are the 8250, 16450, early 16550, and early 16650. They are
obsolete but if you understand how they work it's easy to understand
how the modern ones work with FIFO UARTS ( late 16550, 16550A, 16c552,
late 16650, 16750, and 16950).
There is some confusion regarding 16550. Early models had a bug and
worked properly only as 16450's. Later models with the bug fixed were
named 16550A but many manufacturers did not accept the name change and
continued calling it a 16550. Most all 16550's in use today are like
16550A's. Linux will report it as being a 16550A even though your
hardware manual (or a label note) says it's a 16550. A similar
situation exists for the 16650 (only it's worse since the manufacturer
allegedly didn't admit anything was wrong). Linux will report a late
16650 as being a 16650V2. If it reports it as 16650 it is bad news
and only is used as if it had a one-byte buffer.
To understand the differences between dumb and FIFO (First In, First
Out queue discipline) first let's examine what happens when a UART has
sent or received a byte. The UART itself can't do anything with the
data passing thru it, it just receives and sends it. For the original
dumb UARTS, the CPU gets an interrupt from the serial device every
time a byte has been sent or received. The CPU then moves the
received byte out of the UART's buffer and into memory somewhere, or
gives the UART another byte to send. The 8250 and 16450 UARTs only
have a 1 byte buffer. That means, that every time 1 byte is sent or
received, the CPU is interrupted. At low transfer rates, this is OK.
But, at high transfer rates, the CPU gets so busy dealing with the
UART, that is doesn't have time to adequately tend to other tasks. In
some cases, the CPU does not get around to servicing the interrupt in
time, and the byte is overwritten, because they are coming in so fast.
This is called an "overrun" or "overflow".
That's where the FIFO UARTs are useful. The 16550A (or 16550) FIFO
chip comes with 16 byte FIFO buffers. This means that it can receive
up to 14 bytes (or send 16 bytes) before it has to interrupt the CPU.
Not only can it wait for more bytes, but the CPU then can transfer all
14 (or more) bytes at a time. Although the interrupt threshold
(trigger level) may be set at 8 instead of 14, this is still a
significant advantage over the other UARTs, which only have 1 byte
buffers. The CPU receives less interrupts, and is free to do other
things. Data is not lost, and everyone is happy.
While most PC's only have a 16550 with 16-byte buffers, better UARTS
have even larger buffers. Note that the interrupt is issued slightly
before the buffer get full (at say a "trigger level" of 14 bytes for a
16-byte buffer). This allows room for a few more bytes to be received
during the time that the interrupt is being serviced. The trigger
level may be set to various permitted values by kernel software. A
trigger level of 1 will be almost like a dumb UART (except that it
still has room for 15 more bytes after it issues the interrupt).
If you type something while visiting a BBS, the characters you type go
out thru the serial port. Your typed characters that you see on the
screen are what was echoed back thru the telephone line thru your
modem and then thru your serial port to the screen. If you had a
16-byte buffer on the serial port which held back characters until it
had 14 of them, you would need to type many characters before you
could see what you typed (before they appeared on the screen). This
would be very confusing but there is a "timeout" to prevent this.
Thus you normally see a character on the screen just as soon as you
type it.
The "timeout" works like this for the receive UART buffer: If
characters arrive one after another, then an interrupt is issued only
when say the 14th character reaches the buffer. But if a character
arrives and the next character doesn't arrive soon thereafter, then an
interrupt is issued. This happens even though there are not 14
characters in the buffer (there may only be one character in it).
Thus when what you type goes thru this buffer, it acts almost like a
1-byte buffer even though it is actually a 16-byte buffer (unless your
typing speed is a hundred times faster than normal). There is also
"timeout" for the transmit buffer as well.
Here's a list of UARTs. TL is Trigger Level
· 8250, 16450, early 16550: Obsolete with 1-byte buffers
· 16550, 16550A, 16c552: 16-byte buffers, TL=1,4,8,14
· 16650: 32-byte buffers. Speed up to 460.8 Kbps
· 16750: 64-byte buffer for send, 56-byte for receive. Speed up to
921.6 Kbps
· Hayes ESP: 1K-byte buffers.
The obsolete ones are only good for modems no higher than 14.4k (DTE
speeds up to 38400 bps). For modern modems you need at least a 16550
(and not an early 16550). For V.90 56k modems, it may be a several
percent faster with a 16650 (especially if you are downloading
uncompressed files). The main advantage of the 16650 is its larger
buffer size as the extra speed isn't needed unless the modem
compression ratio is high. Some 56k internal modems may come with a
16650 ??
Non-UART, and intelligent multiport boards use DSP chips to do
additional buffering and control, thus relieving the CPU even more.
For example, the Cyclades Cyclom, and Stallion EasyIO boards use a
Cirrus Logic CD1400 RISC UART, and many boards use 80186 CPUs or even
special RISC CPUs, to handle the serial I/O.
Most newer PC's (486's, Pentiums, or better) come with 16550A's
(usually called just 16550's). If you have something really old the
chip may unplug so that you may be able to upgrade by buying a 16550A
chip and replacing your existing 16450 UART. If the functionality has
been put on another type of chip, you are out of luck. If the UART is
socketed, then upgrading is easy (if you can find a replacement). The
new and old are pin-to-pin compatible. It may be more feasible to
just buy a new serial board on the Internet (few retail stores stock
them today).
14. Pinout and Signals
14.1. Pinout
PINOUT of the SERIAL PORT (--> direction is out of PC)
(Note DCD is sometimes labeled CD)
Pin # Pin # Acronym Full-Name Direction What-it-May-Do/Mean
9-pin 25-pin
3 2 TxD Transmit Data --> Transmits byte out of PC
2 3 RxD Receive Data <-- Receives bytes into PC
7 4 RTS Request To Send --> RTS/CTS flow control
8 5 CTS Clear To Send <-- RTS/CTS flow control
6 6 DSR Data Set Ready <-- I'm ready to communicate
4 20 DTR Data Terminal Ready--> I'm ready to communicate
1 8 DCD Data Carrier Detect<-- Modem connected to another
9 22 RI Ring Indicator <-- Telephone line ringing
5 7 Signal Ground
14.2. Signals May Have No Fixed Meaning
Only 3 of the 9 pins have a fixed assignment: transmit, receive and
signal ground. This is fixed by the hardware and you can't change it.
But the other signal lines are controlled by software and may do (and
mean) almost anything at all. However they can only be in one of two
states: asserted (+12 volts) or negated (-12 volts). Asserted is "on"
and negated is "off". For example, Linux software may command that
DTR be negated and the hardware only carries out this command and puts
-12 volts on the DTR pin. A modem (or other device) that receives
this DTR signal may do various things. If a modem has been configured
a certain way it will hang-up the telephone line when DTR is negated.
In other cases it may ignore this signal or do something else when DTR
is negated (turned off).
It's like this for all the 6 signal lines. The hardware only sends
and receives the signals, but what action (if any) they perform is up
to the Linux software and the configuration/design of devices that you
connect to the serial port. However, most pins have certain functions
which they normally perform but this may vary with the operating
system and the device driver configuration. Under Linux, one may
modify the source code to make these signal lines behave differently
(some people have).
14.3. Cabling Between Serial Ports
A cable from a serial port always connects to another serial port. A
modem or other device that connects to the serial port has a serial
port built into it. For modems, the cable is always straight thru:
pin 2 goes to pin 2, etc. The modem is said to be DCE (Data
Communications Equipment) and the computer is said to be DTE (Data
Terminal Equipment). Thus for connecting DTE-to-DCE you use straight-
thru cable. For connecting DTE-to-DTE you must use a null-modem cable
and there are many ways to wire such cable (see examples in Text-
Terminal-HOWTO).
There are good reasons why it works this way. One reason is that the
signals are unidirectional. If pin 1 sends a signal out of it (but is
unable to receive any signal) then obviously you can't connect it to
pin 1 of the same type of device. If you did, they would both send
out signals on the same wire to each other but neither would be able
to receive any signal. There are two ways to deal with this
situation. One way is to have a two different types of equipment
where pin 1 of the first type sends the signal to pin 1 of the second
type (which receives the signal). That's the way it's done when you
connect a PC (DTE) to a modem (DCE). There's a second way to do this
without having two different types of equipment: Connect pin 1 (a
sending pin) to a receiving pin (not pin 1) on same type of equipment.
That's the way it's done when you connect 2 PC's together or a PC to a
terminal (DTE-to-DTE). The cable used for this is called a null-modem
cable.
The serial pin designations were originally intended for connecting a
dumb terminal to a modem. The terminal was DTE (Data Terminal
Equipment) and the modem was DCE (Data Communication Equipment).
Today the PC is usually used as DTE instead of a terminal (but real
terminals may still be used this way). The names of the pins are the
same on both DTE and DCE. The words: "receive" and "transmit" are in
this case from the point of view of the PC (DTE). The transmit pin
from the PC transmits to the "transmit" pin of the modem (but actually
the modem is receiving the data from this pin so from the point of
view of the modem it would be a receive pin).
The serial port was originally intended to be used for connecting DTE
to DCE which makes cabling simple: just use a straight-thru cable.
Thus when one connects a modem one seldom needs to worry about which
pin is which. But people wanted to connect DTE to DTE (for example a
computer to a terminal) and various ways were found to do this by
fabricating various type of special cables. In this case what pin
connects to what pin becomes more important.
14.4. RTS/CTS and DTR/DSR Flow Control
This is "hardware" flow control. Flow control was previously
explained in the ``Flow Control'' subsection but the pins and voltage
signals were not. Linux only supports RTS/CTS flow control at present
(but a special driver may exist for a specific application which
supports DTR/DSR flow control). Only RTS/CTS flow control will be
discussed since DTR/DSR flow control works the same way. To get
RTS/CTS flow control one needs to either select hardware flow control
in an application program or use the command:
enables RTS/CTS hardware flow control in the Linux device driver.
Then when a DTE (such as a PC) wants to stop the flow into it, it
negates RTS. Negated "Request To Send" (-12 volts) means "Request NOT
To Send to me" (stop sending). When the PC is ready for more bytes it
asserts RTS (+12 volts) and the flow of bytes to it resumes. Flow
control signals are always sent in a direction opposite to the flow of
bytes that is being controlled. DCE equipment (modems) works the same
way but sends the stop signal out the CTS pin. Thus it's RTS/CTS flow
control using 2 lines.
On what pins is this stop signal received? That depends on whether we
have a DCE-DTE connection or a DTE-DTE connection. For DCE-DTE it's a
straight-thru connection so obviously the signal is received on a pin
with the same name as the pin it's sent out from. It's RTS-->RTS (PC
to modem) and CTS<--CTS (modem to PC). For DTE-to-DTE the connection
is also easy to figure out. The RTS pin always sends and the CTS pin
always receives. Assume that we connect two PCs (PC1 and PC2)
together via their serial ports. Then it's RTS(PC1)-->CTS(PC2) and
CTS(PC1)<--RTS(PC2). In other words RTS and CTS cross over. Such a
cable (with other signals crossed over as well) is called a "null
modem" cable. See ``Cabling Between Serial Ports''
What is sometimes confusing is that there is the original use of RTS
where it means about the opposite of the previous explanation above.
This original meaning is: I Request To Send to you. This request was
intended to be sent from a terminal (or computer) to a modem which, if
it decided to grant the request, would send back an asserted CTS from
its CTS pin to the CTS pin of the computer: You are Cleared To Send to
me. Note that in contrast to the modern RTS/CTS bi-directional flow
control, this only protects the flow in one direction: from the
computer (or terminal) to the modem. This original use appears to be
little used today on modern equipment (including modems).
14.4.1. The DTR and DSR Pins
Just like RTS and CTS, these pins are paired. For DTE-to-DTE
connections they are likely to cross over. There are two ways to use
these pins. One way is to use them as a substitute for RTS/CTS flow
control. The DTR pin is just like the RTS pin while the DSR pin
behaves like the CTS pin. Although Linux doesn't support DTR/DSR flow
control, it can be obtained by connecting the RTS/CTS pins at the PC
to the DSR/DTR pins at the device that uses DTR/DSR flow control. DTR
flow control is the same as DTR/DSR flow control but it's only one-way
and the DSR pin is not used. Many text terminals and some printers
use this type of flow control.
The normal use of DTR and DSR is as follows: A device asserting DTR
says that its powered on and ready to operate. For a modem, the
meaning of a DTR signal from the PC depends on how the modem is
configured. To send a DTR signal manually from a PC using the stty
command set the baud rate to 0. Negating DTR is sometimes called
"hanging up" but it doesn't always do this.
14.5. Preventing a Port From Opening
If "stty -clocal" (or getty is used with the "local" flag negated)
then a serial port can't open until DCD gets an assert (+12 volts)
signal.
15. Voltage Waveshapes
15.1. Voltage for a Bit
At the EIA-232 serial port, voltages are bipolar (positive or negative
with respect to ground) and should be about 12 volts in magnitude
(some are 5 or 10 volts). For the transmit and receive pins +12
volts is a 0-bit (sometimes called "space") and -12 volts is a 1-bit
(sometimes called "mark"). This is known as inverted logic since
normally a 0-bit is both false and negative while a one is normally
both true and positive. Although the receive and transmit pins are
inverted logic, other pins (modem control lines) are normal logic with
a positive voltage being true (or "on" or "asserted") and a negative
voltage being false (or "off" or "negated"). Zero voltage has no
meaning (except it usually means that the unit is powered off).
A range of voltages is allowed. The specs say the magnitude of a
transmitted signal should be between 5 and 15 volts but must never
exceed 25 V. Any voltage received under 3 V is undefined (but some
terminals will accept a lower voltage as valid). One sometimes sees
erroneous claims that the voltage is commonly 5 volts (or even 3
volts) but it's usually 11-12 volts. If you are using a EIA-422 port
on a Mac computer as an EIA-232 (requires a special cable) or EIA-423
then the voltage will actually be only 5 V. The discussion here
assumes 12 V.
Note that normal computer logic normally is just a few volts (5 volts
was once the standard) so that if you try to use test equipment
designed for testing 3-5 volt computer logic (TTL) on the 12 volts of
a serial port, it may damage the test equipment.
15.2. Voltage Sequence for a Byte
The transmit pin (TxD) is held at -12 V (mark) at idle when nothing is
being sent. To start a byte it jumps to +12 V (space) for the start
bit and remains at +12 V for the duration (period) of the start bit.
Next comes the low-order bit of the data byte. If it's a 0-bit
nothing changes and the line remains at +12 V for another bit-period.
If it's a 1-bit the voltage jumps from +12 to -12 V. After that comes
the next bit, etc. Finally, a parity bit may be sent and then a -12 V
(mark) stop bit. The line remains at -12 V (idle) until the next
start bit. Note that there is no return to 0 volts and thus there is
no simple way (except by a synchronizing signal) to tell where one bit
ends and the next one begins for the case where 2 consecutive bits are
the same polarity (both zero or both one).
A 2nd stop bit would also be -12 V, just the same as the first stop
bit. Since there is no signal to mark the boundaries between these
bits, the only effect of the 2nd stop bit is that the line must remain
at -12 V idle twice as long. The receiver has no way of detecting the
difference between a 2nd stop bit and a longer idle time between
bytes. Thus communications works OK if one end uses one stop bit and
the other end uses 2 stop bits, but using only one stop bit is
obviously faster. In rare cases 1 1/2 stop bits are used. This means
that the line is kept at -12 V for 1 1/2 time periods (like a stop bit
50% wider than normal).
15.3. Parity Explained
Characters are normally transmitted with either 7 or 8 bits (of data).
An additional parity bit may (or may not) be appended to this
resulting in a byte length of 7, 8 or 9 bits. Some terminal emulators
and older terminals do not allow 9 bits. Some prohibit 9 bits if 2
stop bits are used (since this would make the total number of bits too
large: 12 bits total).
The parity may be set to odd, even or none (mark and space parity may
be options on some terminals). With odd parity, the parity bit is
selected so that the number of 1-bits in a byte, including the parity
bit, is odd. If a such a byte gets corrupted by a bit being flipped,
the result is an illegal byte of even parity. This error will be
detected and if it's an incoming byte to the terminal an error-
character symbol will appear on the screen. Even parity works in a
similar manner with all legal bytes (including the parity bit) having
an even number of 1-bits. During set-up, the number of bits per
character usually means only the number of data bits per byte (7 for
true ASCII and 8 for various ISO character sets).
A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
0). For mark parity, the parity bit is always a one-bit. For space
parity it's always a zero-bit. Mark or space parity only wastes
bandwidth and should be avoided when feasible. "No parity" means that
no parity bit is added. For terminals that don't permit 9 bit bytes,
"no parity" must be selected when using 8 bit character sets since
there is no room for a parity bit.
15.4. Forming a Byte (Framing)
In serial transmission of bytes via EIA-232 ports, the low-order bit
is always sent first. Serial ports on PC's use asynchronous
communication where there is a start bit and a stop bit to mark the
beginning and end of a byte. This is called framing and the framed
byte is sometimes called a frame. As a result a total of 9, 10, or 11
bits are sent per byte with 10 being the most common. 8-N-1 means 8
data bits, No parity, 1 stop bit. This adds up to 10 bits total when
one counts the start bit. One stop bit is almost universally used.
At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
used but today the 2nd stop bit is used only in very unusual
situations (or by mistake since it seemingly still works OK that way).
15.5. How "Asynchronous" is Synchronized
The EIA-232 serial port as implemented on PC is asynchronous which in
effect means that there is no "clock" signal sent with "ticks" to mark
when each bit is sent.. There are only two states of the transmit (or
receive) wire: mark (-12 V) or space (+12 V). There is no state of 0
V. Thus a sequence of 1-bits is transmitted by just a steady -12 V
with no markers of any kind between bits. For the receiver to detect
individual bits it must always have a clock signal which is in
synchronization with the transmitter clock. Such a clock would
generate a "tick" in synchronization with each transmitted (or
received) bit.
For asynchronous transmission, synchronization is achieved by framing
each byte with a start bit and a stop bit (done by hardware). The
receiver listens on the line for a start bit and when it detects one
it starts its clock ticking. It uses this clock tick to time the
reading of the next 7, 8 or 9 bits. (It actually is a little more
complex than this since several samples of a bit are often taken and
this requires additional timing ticks.) Then the stop bit is read,
the clock stops and the receiver waits for the next start bit. Thus
async is actually synchronized during the reception of a single byte
but there is no synchronization between one byte and the next byte.
16. Other Serial Devices (not async EIA-232)
16.1. Successors to EIA-232
A number of EIA standards have been established for higher speeds and
longer distances using twisted-pair (balanced) technology. Balanced
transmission can sometimes be a hundred times faster than unbalanced
EIA-232. For a given speed, the distance (maximum cable length) may
be many times longer with twisted pair. But PC-s keep being made with
the "obsolete" EIA-232 since it works OK with modems and mice since
the cable length is short. If this appears in the latest version of
this HOWTO, please let me know if any of the non-EIA-232 listed below
are supported by Linux.
16.2. EIA-422-A (balanced) and EIA-423-A (unbalanced)
EIA-423 is just like the unbalanced EIA-232 except that the voltage is
only 5 volts. Since this falls within EIA-232 specs it can be
connected to a EIA-232 port. Its specs call for somewhat higher
speeds than the EIA-232 (but this may be of little help on a long run
where it's the unbalance that causes interference).
Apple's Mac computer prior to mid-1998 with its EIA-232/EIA-422 Port
provided twisted-pairs (balanced) for transmit and receive (when used
as a 422). It is (per specs) exactly 100 times as fast as EIA-423
(which in turn is somewhat faster than EIA-232) The Mac used a small
round "mini-DIN-8" connector. It also provided conventional EIA-232
but at only at 5 volts (which is still legal EIA-232). To make it
work like at EIA-232 one must use a special cable which (signal)
grounds RxD+ (one side of a balanced pair) and use RxD- as the receive
pin. While TxD- is used as the transmit pin, for some reason TxD+
should not be grounded. See Macintosh Communications FAQ
<http://www.modemshop.com/csm-comm-faq.html>. However, due to the
fact that Macs (and upgrades for them) cost more than PC's, they are
not widely as host computers for Linux.
16.3. EIA-485
This is like EIA-422 (balanced). It is half-duplex. It's not just
point-to-point but may be used for a multidrop LAN (up to 32 nodes).
There are no connector specs
16.4. EIA-530
EIA-530-A (balanced but can also be used unbalanced) at 2Mbits/s
(balanced) was intended to be a replacement for EIA-232 but few have
been installed. It uses the same 25-pin connector as EIA-232.
16.5. EIA-612/613
The High Speed Serial Interface ( HSSI = EIA-612/613) uses a 50-pin
connector and goes up to about 50 Mbits/s but the distance is limited
to only several meters.
16.6. The Universal Serial Bus (USB)
The Universal Serial Bus (USB) is being built into PCI chips. New
PC's have them. It is 12 Mbits/s over a twisted pair with a 4-pin
connector (2 wires are power supply) but it also is limited to short
distances of at most 5 meters (depends on configuration).
Another HOWTO is needed for it. Work is underway for supporting it in
Linux (but no HOWTO). It is synchronous and transmits in special
packets like a network. Just like a network, it can have several
devices attached to it. Each device on it gets a time-slice of
exclusive use for a short time. A device can also be guaranteed the
use of the bus at fixed intervals. One device can monopolize it if no
other device wants to use it. It's not simple to describe in detail.
16.7. Synchronization & Synchronous
Beside the asynchronous EIA-232 (and others) there are a number of
synchronous serial port standards. In fact EIA-232 includes
synchronous specifications but they aren't normally implemented for
serial ports on PC's. But first we'll explain what a synchronous
means.
16.7.1. Defining Asynchronous vs Synchronous
Asynchronous (async) means "not synchronous". In practice, an async
signal is what the async serial port sends and receives which is a
stream of bytes each delimited by a start and stop bit. Synchronous
(sync) is most everything else. But this doesn't explain the basic
concepts.
In theory, synchronous means that bytes are sent out at a constant
rate one after another (in step with a clock signal tick ).
Asynchronous bytes may be sent out erratically with various time
intervals between bytes (like someone typing characters at a
keyboard).
There are certain situations that need to be classified as either sync
or async. The async serial port often sends out bytes in a steady
stream which would make this a synchronous case but since they still
have the start/stop bits (which makes it possible to send them out
erratically) its called async. Another case is where data bytes
(without any start-stop bits) are put into packets with possible
erratic spacing between one packet and the next. This is called sync
since the bytes within each packet must be transmitted synchronously.
16.7.2. Synchronous Communication
Did you ever wonder what all the unused pins are for on a 25-pin
connector for the serial port? Most of them are for use in
synchronous communication which is seldom implemented on PC's. There
are pins for sync timing signals as well as for a sync reverse
channel. The EIA-232 spec provides for both sync and async but PC's
use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
a 16450, 16550A, or 16650 and can't deal with sync. For sync one
needs a USART chip or the equivalent where the "S" stands for
Synchronous. Since sync is a niche market, a sync serial port is
likely to be quite expensive.
Besides the sync part of the EIA-232, there are various other EIA
synchronous standards. For EIA-232, 3 pins of the connector are
reserved for clock (or timing) signals. Sometimes it's a modem's task
to generate some timing signals making it impossible to use
synchronous communications without a synchronous modem (or without a
device called a "synchronous modem eliminator" which provides the
timing signals).
Although few serial ports are sync, synchronous communication does
often take place over telephone lines using modems which use V.42
error correction. This strips off the start/stop bits and puts the
date bytes in packets resulting in synchronous operation over the
phone line.
17. Other Sources of Information
17.1. Books
1. Axleson, Jan: Serial Port Complete, Lakeview Research, Madison, WI,
1998.
2. Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE
Computer Society Press, Los Alamitos, CA, 1996.
3. Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
4. Levine, Donald: POSIX Programmer's Guide
<http://www.ora.com/catalog/posix/>, (ISBN 0-937175-73-0; O'Reilly)
5. Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
6. Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall, 1991.
7. Stevens, Richard W.: Advanced Programming in the UNIX Environment
<http://heg-
school.aw.com/cseng/authors/stevens/advanced/advanced.nclk>, (ISBN
0-201-56317-7; Addison-Wesley)
8. Tischert, Michael & Bruno Jennrich: PC Intern, Abacus 1996.
Chapter 7: Serial Ports
Notes re books:
1. "... Complete" has hardware details (including register) but the
programming aspect is Window oriented.
2. "Physical Layer ..." covers much more than just EIA-232.
17.2. Serial Software
It's best to use the nearest mirror site, but here's the main sites:
Serial Software <ftp://metalab.unc.edu/pub/Linux/system/serial/> for
Linux software for the serial ports including getty and port monitors.
Serial Communications
<ftp://metalab.unc.edu/pub/Linux/apps/serialcomm> for communication
programs.
· irqtune will give serial port interrupts higher priority to improve
performance. Using hdparm for hard-disk tuning may help some more.
· modemstat and statserial show the current state of various modem
control lines. See ``Serial Monitoring/Diagnostics''
17.3. Linux Documents
· man pages for: setserial(8) stty
· Modem-HOWTO: modems on the serial port
· PPP-HOWTO: help with PPP (using a modem on the serial port)
· Printing-HOWTO: for setting up a serial printer
· Serial-Programming-HOWTO: for some aspects of serial-port
programming
· Text-Terminal-HOWTO: how they work and how to install and configure
· UPS-HOWTO: setting up UPS sensors connected to your serial port
· UUCP-HOWTO: for information on setting up UUCP
17.4. Usenet newsgroups:
· comp.os.linux.answers
· comp.os.linux.hardware: Hardware compatibility with the Linux
operating system.
· comp.os.linux.networking: Networking and communications under
Linux.
· comp.os.linux.setup: Linux installation and system administration.
17.5. Serial Mailing List
The Linux serial mailing list. To join, send email to
majordomo@vger.rutgers.edu, with ``subscribe linux-serial'' in the
message body. If you send ``help'' in the message body, you get a
help message. The server also serves many other Linux lists. Send
the ``lists'' command for a list of mailing lists.
17.6. Internet
· Serial Suite <ftp://scicom.alphadec.com/pub/linux> by Vern Hoxie is
a collection of blurbs about the care and feeding of the Linux
serial port plus some simple programs.
· A white paper discussing serial communications and multiport serial
boards is available from Cyclades at http://www.cyclades.com.
END OF Serial-HOWTO
| HowTo Linux Zone | Linux Zone Home | E-Mail Me | Copyright 1999 Linux Zone
