PC World 1999 August/PCWorld_1999-08_cd.bin/doc/HOWTO/Serial-HOWTO

Text File | 1999-05-24 | 121KB | 2,773 lines

  The Linux Serial HOWTO
  David S.Lawyer   [e-mail] 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.
  [e-mail] 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="[e-mail] (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: [e-mail] 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, [e-mail]
     driver status: pre-ALPHA

  ╖  Cyclades Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),
     Cyclom-Z (25MHz MIPS R3000; 8 - 128 ports)
     contact: [e-mail] 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: [e-mail]
     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: [e-mail] 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, [e-mail]
     driver status: ALPHA
     note: Simon is often away from email for months at a time due to
     his job.  Mark Hatle, [e-mail] 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: [e-mail] 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: [e-mail] 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, [e-mail] 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: [e-mail] 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: [e-mail] 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: [e-mail] 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:[e-mail]>
     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: [e-mail] 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
  [e-mail], 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