New Versions of this Serial-HOWTO
New versions of the Serial-HOWTO will be available to
@@ -150,7 +158,7 @@ sites see: .
Various formats are available. If you only want to quickly check the
date of the latest version look at and compare
-it to this version: v2.23 November 2004 .
+it to this version: v2.24 February 2006 .
New in Recent Versions
For a full revision history going back to the time I started
@@ -159,6 +167,9 @@ maintaining this HOWTO, see the source file (in linuxdoc format) at
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz">.
+- v2.24 Feb. 2006: Serial Laplink HOWTO (connecting 2 PCs via the
+serial line), Fixed typos found by Charles Brockman. Messages with
+"ttyS01" now show it as "ttyS1"
- , etc.
- v2.23 Nov. 2004: typo fixed, Quick Help added, Serial ports on
motherboard likely ISA or LPC
- v2.22 Dec. 2003: revised Complex Flow Control Example, more on devfs
@@ -201,10 +212,12 @@ what you don't understand, or what could be clearer. You can reach me
via email at
.
What is a Serial Port?
- The conventional serial port (not the newer USB port, or HSSI
-port) is a very old I/O port. Almost all Desktop PC's have them.
+
The conventional serial port (not the newer USB port, or Firewire
+port) is a very old I/O (Input/Output) port. Most Desktop PC's have
+them. For laptops, they're not likely to be present on newer models.
Macs (Apple Computer) after mid-1998 only have the USB port. However,
-it's possible, to put a conventional serial port device on the USB.
+it's possible, to put a conventional serial port device on the USB bus
+which is on all modern PCs (including laptops and Macs).
Each serial port has a "file" associated with it in the /dev
directory. It isn't really a file but it seems like one. For
@@ -257,7 +270,9 @@ They could be shown in a menu dealing with Resources, Plug-and-Play,
Peripherals, Ports, etc. Some old BIOSs setups (before 1995 ?) didn't
deal with the serial ports. Make sure the ports you need are not
disabled and note how they are configured (like 3F8 IRQ 4). You may
-need to change the configuration to prevent conflicts.
+need to change the configuration to prevent conflicts. There could be
+a shortage of IRQs if the BIOS has reserved some IRQs that it didn't
+need to reserve.
For serial ports to be found, either the kernel must have been
compiled with serial support, or serial support must be provided by a
@@ -275,11 +290,11 @@ understand since it's similar. The first explanation given here will
be grossly oversimplified. Then more detail will be added in later
explanations. When the computer wants to send a byte out the serial
port (to the external cable) 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 cable connector. For what a
-bit (and byte) look like electrically see [.
+the computer to the I/O (Input Output) address of the serial port.
+I/O is often written as just IO. 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 cable connector. For what a bit (and byte) look
+like electrically see ][.
Here's a replay of the above in a little more detail (but still very
incomplete). Most of the work at the serial port is done by the UART
@@ -416,7 +431,7 @@ Feb. '02 4k buffer -> 8k
Feb. '03: UARTs with auto flow control. Rewrite of Flow Control.
Mar. '03: Flip buffer (the 4th buffer)
Apr. '03: flow control clarity, RTS -> CTS re modems
-Nov. '04: Better clarity re Data Flow
+Nov. '04: Better clarity re Data Flow, Winmodem support
-->
@@ -455,9 +470,7 @@ transmit pin (and conversely).
Most of the electronics of the serial port is found in a computer chip
(or a part of a chip) known as a UART. For more details on UARTs
see the section
-
-][
-But you may want to finish this section first so that you will
+][ 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.
@@ -549,7 +562,7 @@ corresponds to say ttyS1 depends both on what the serial driver thinks
(per setserial) and what is set in the hardware. If a mistake has
been made, the physical port may not correspond to any name (such as
ttyS2) and thus it can't be used. See ][ for more details>
+Port Devices /dev/ttyS2, etc."> for more details.
] Interrupts
@@ -604,7 +617,7 @@ the serial port. That program is called an interrupt service routine
happened at the serial port and then deals with the problem such a
transferring bytes from (or to) the serial port's hardware buffer.
This program can easily find out what has happened since the serial
-port has registers at IO addresses known to the the serial driver
+port has registers at IO addresses known to 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.
@@ -957,12 +970,12 @@ See [ for more info on
] Is the Serial Port Obsolete?
Introduction
- The answer is yes, but ... The serial port is somewhat obsolete
-(and often called a "legacy" device, 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. Linux supports ordinary analog modems
-only if they work thru a serial port (although the port may be built
-into the modem).
+
The serial port is somewhat obsolete (and often called a "legacy"
+device, but it's still important, especially for Linux. The serial port
+has many shortcomings but most new PC's (except for laptops and Macs)
+seem to come with them. Some PC's, called "legacy-free" don't have
+serial ports. Linux supports ordinary analog modems only if they work
+thru a serial port (although the port may be built into the modem).
The physical serial port on the back of a PC, must pass data between
the computer and an external cable. Thus it has two interfaces: the
@@ -993,16 +1006,18 @@ 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. The result was that since
-the serial port couldn't handle high speeds new types of serial
+the serial port couldn't handle high speeds, new types of serial
interfaces were devised that could: Ethernet, USB, Firewire, etc.
- Inefficient Interface to the Computer (in some cases)
+ Inefficient PCI Interface to the Computer (in some cases)
- The serial port communicates with the computer via the PCI bus (or
-the LPC or ISA bus). The PCI bus is now 32 or 64 bits wide, but the
-serial port only sends a byte at a time (8 bits wide) which is a waste
-of PCI bus bandwidth. Not so for the LPC bus which has only a 4-bit
-wide bus and thus provides an efficient interface.
+
The serial port communicates with the computer via the PCI bus,
+the LPC bus, X-bus, or ISA bus. The PCI bus is now 32 or 64 bits wide,
+but the serial port only sends a byte at a time (8 bits wide) which is
+a waste of PCI bus bandwidth. Not so for the LPC bus which has only a
+4-bit wide bus and thus provides an efficient interface. The ISA bus
+is usually 16-bits wide and the efficiency is intermediate as compared
+to efficient LPC and inefficient PCI.
Multiport Serial Boards/Cards/Adapters
Intro to Multiport Serial
@@ -1260,7 +1275,7 @@ There are many different brands, each of which often offers many
different cards. No attempt is currently being made to list all the
cards here (and many listed are obsolete). But all major brands and
websites should be shown here so it something is missing let me know.
-Go the the webpage shown for more information. These websites often
+Go the webpage shown for more information. These websites often
also have info (ads) on related hardware such as modem pools, remote
access servers (RASs), and terminal servers. Where there is no
webpage, the cards are likely obsolete. If you would like to put
@@ -1499,7 +1514,7 @@ assigning each port an IO address, IRQ, and name (such as ttyS2). This
IO-IRQ pair must be set in both the hardware and told to the serial
driver. We might just call this "io-irq" configuring for short. The
"setserial" program is sometimes used to tell the driver. PnP
-methods, jumpers, etc, are used to set the I0 and IRQ in the hardware.
+methods, jumpers, etc, are used to set the IO and IRQ in the hardware.
Details will be supplied later. If you need to configure but don't
understand certain details it's easy to get into trouble. See [
@@ -1536,26 +1551,26 @@ the card inserts into (usually a PCI slot). But if the serial port is
built into the motherboard it may not be clear what bus it's on. For
old motherboards that have ISA bus slots, it's likely on the ISA bus
and may not even be Plug-and-Play. But even if all your slots are
-PCI, the serial port is not likely to be PCI. It may still be ISA, or
-it might be on a LPC bus (also called a "LPC interface"). LPC is
-common on laptop computers. Type "lspci" to see if it shows "LPC".
-Unfortunately, the LPC bus has no standard Plug-and-Play method for
-low-level configuring devices on it. One way to deal with it is to
-hope that the BIOS can configure them. Some Linux developers are
-aware of the problem (in late 2004) and Linux may support LPC better
-in the future.
+PCI, the serial port is likely to be on either the ISA bus or LPC bus
+(also called a "LPC interface"). LPC is common on laptop computers.
+Type "lspci" to see if it shows "LPC". Unfortunately, the LPC bus has
+no standard Plug-and-Play method for low-level configuring devices on
+it. One way to deal with it is to hope that the BIOS can configure
+them using ACPI. Some Linux developers are aware of the problem (in
+late 2004) and Linux may support the LPC bus better in the future.
+To see if you have a LCP bus, type "lspci" and look for a LPC bridge.
] IO & IRQ Overview
For a serial port to work properly it first must be given both an
IO address and an IRQ. For old hardware (of mid 1990s), jumpers on a
-card or the a saved BIOS setting does it. For newer hardware the BIOS
+card or the saved BIOS setting does it. For newer hardware the BIOS
or Linux must set them at boot-time, and the new hardware doesn't
-remember how it was set once it's powered Enabling hardware it gives
-it both an IRQ and an IO address. Without an IO address, it can't be
-used. Without an IRQ it will need to use inefficient polling methods
-for which one must set the IRQ to 0 in the serial driver. In olden
-days IRQs and IO addresses were set by jumpers or switches on a serial
-port card. Today these are set by digital signals sent to the
+remember how it was set once it's powered down. Enabling hardware
+gives it both an IRQ and an IO address. Without an IO address, it
+can't be used. Without an IRQ it will need to use inefficient polling
+methods for which one must set the IRQ to 0 in the serial driver. In
+olden days IRQs and IO addresses were set by jumpers or switches on a
+serial port card. Today these are set by digital signals sent to the
hardware by the BIOS or Linux. It all should get configured
automatically (provided the BIOS has not been previously set up to
disable it) so that you only need to read this if you're having
@@ -1610,9 +1625,9 @@ then you need to do it if you:
Starting with kernel 2.2 you may be able to use more that 2 serial
ports without doing any low-level configuring by sharing interrupts.
-All PCI ports should support this but for ISA, it only works for some
+All PCI ports should support this but for ISA it only works for some
hardware. It may be just as easy to give each port a unique interrupt
-if they is available. See [
The low-level configuring (setting the IRQ and IO address) seems to
@@ -1667,17 +1682,16 @@ While kernel 2.2 supported PCI in general, it had no support for PCI
serial ports (although some people got them working anyway). Starting
with kernel 2.4, the serial driver will read the id number digitally
stored in the serial hardware to determine how to support it (if it
-knows how). It should assign an I/O address to it, determine it's
+knows how). It should assign an I/O address to it, determine its
IRQ, etc. So you don't need to use "setserial" for it.
There is a possible problem if you don't use the device filesystem.
-The driver may assign the port to say "]
-cd /dev and then ./MAKEDEV ttyS4
-For the device filesystem, the driver should create the device
-tts/1
+The driver may assign the port to say tt/ttyS4 per a boot-time
+message (use
+cd /dev; ./MAKEDEV ttyS4
+For the device filesystem, the driver should create the device tts/1
- Which Connector on the Back of my PC is ttyS1, etc?
+ Which Connector on the Back of my PC is ttyS1, etc?
Inspect the connectors
Inspecting the connectors may give some clues but is often not
definitive. The serial connectors on the back side of a PC are
@@ -2412,27 +2431,28 @@ this may be easy. If you also have an internal modem, a program like
wvdial may be able to tell you what port it's on (unless it's a PnP
that hasn't been enabled yet). A report from setserial (at
boot-time or run by you from the command line) should help you
-identify the non-modem port.
+identify the non-modem ports.
-If you have two serial connectors it may be more difficult.
-First check manuals (if any) for your computer. Look at the
-connectors for meaningful labels. You might even want to take off the
-PC's cover and see if there are any meaningful labels on the card
-where the internal ribbon cables plug in. Labels (if any) are likely
-to say something like "serial 1", "serial 2" or A, B. Which com port it
-actually is will depend on jumper or PnP settings (sometimes shown in
-a CMOS setup menu). But 1 or A are more likely to be ttyS0 with 2 or
-B ttyS1.
+If you have two serial ports it may be more difficult. You could have
+only one serial connector but actually have 2 ports, one of which
+isn't used (but it's still there electronically). First check manuals
+(if any) for your computer. Look at the connectors for meaningful
+labels. You might even want to take off the PC's cover and see if
+there are any meaningful labels on the card where the internal ribbon
+serial cables plug in. Labels (if any) are likely to say something like
+"serial 1", "serial 2" or A, B. Which com port it actually is will
+depend on jumper or PnP settings (sometimes shown in a BIOS setup
+menu). But 1 or A are more likely to be ttyS0 with 2 or B ttyS1.
Send bytes to the port
Labels are not apt to be definitive so here's another method. If
the serial ports have been configured correctly per setserial, then
you may send some bytes out a port and try to detect which connector
-(if any) it's coming out of. One way to send such a signal is to copy
-a long text file to the port using a command like: cp my_file_name
-/dev/ttyS1. A voltmeter connected to the DTR pin (see Serial-HOWTO
-for Pinout) will display a positive voltage as soon as you give the
-copy command.
+(if any) they are coming out of. One way to send such a signal is to
+copy a long text file to the port using a command like: cp
+my_file_name /dev/ttyS1. A voltmeter connected to the DTR pin (see
+Serial-HOWTO for Pinout) will display a positive voltage as soon as
+you give the copy command.
The transmit pin should go from several volts negative to a voltage
fluctuating around zero after you start sending the bytes. If it doesn't
@@ -2455,17 +2475,17 @@ may be a good way to test it as the repeating test messages halt when
the jumper is removed.
As a jumper you could use a mini (or micro) jumper cable (sold in some
-electronic parts stores) with mini alligator clips. A scrap of paper
-may be used to prevent the mini clips from accidentally touching the
-metal of the connector. Metal paper clips can sometimes be bent to
-use as jumpers. Whatever you use as a jumper take care not to bend or
-excessively scratch the pins. To receive something from a port, you
-can go to a virtual terminal (Alt-F2 for example) and type something
-like "cp /dev/ttyS2 /dev/tty". Then at another virtual terminal you
-may send something to ttyS2 (or whatever) by "echo test_message >
-/dev/ttyS2". Then go back to the receive virtual terminal and look
-for the test_message. See [ for more info.
+electronic parts stores) with mini alligator clips. A small scrap of
+paper may be used to prevent the mini clips from making electrical
+contact where it shouldn't. Metal paper clips can sometimes be bent
+to use as jumpers. Whatever you use as a jumper take care not to bend
+or excessively scratch the pins. To receive something from a port,
+you can go to a virtual terminal (for example Alt-F2 and login) and
+type something like "cp /dev/ttyS2 /dev/tty". Then at another virtual
+terminal you may send something to ttyS2 (or whatever) by "echo
+test_message > /dev/ttyS2". Then go back to the receive virtual
+terminal and look for the test_message. See ][ for more info.
] Connect a device to the connector
Another way to try to identify a serial port is to connect some
@@ -2473,16 +2493,22 @@ physical serial device to it and see if it works. But a problem here
is that it might not work because it's not configured right. A serial
mouse might get detected at boot-time if connected.
+You may put a device, such as a serial mouse (use 1200 baud), on a port
+and then use minicom to communicate with that port. Then by clicking
+on the mouse, or otherwise sending characters with the device, see if
+minicom displays them. It not reconfigure minicom to use the other
+serial port, but keep the device connected to the same port.
+
Missing connectors
If the software shows that you have more serial ports than you
have connectors for (including an internal modem which counts as a
serial port) then you may have a serial port that has no connector.
-Some motherboards come with a serial port with no cable or serial DB
-connector. Someone may build a PC from this and omit the connector.
-There may be a "serial" connector and label on the motherboard but no
-ribbon cable connects to its pins. To use this port you must get a
-ribbon cable and connector. I've seen different wiring arrangements for
-such ribbon cables so beware.
+Some motherboards come with a serial port with no cable or external
+serial DB connector. Someone may build a PC from this and decide not
+to use this serial port. There may be a "serial" connector and label
+on the motherboard but no ribbon cable connects to its pins. To use
+this port you must get a ribbon cable and connector. I've seen
+different wiring arrangements for such ribbon cables so beware.
Creating Devices In the /dev directory
@@ -2502,8 +2528,8 @@ device for ttyS0 you would just type:
linux# MAKEDEV ttyS0
-If the above command doesn't work (and your are the root user), look
-for the MAKEDEV script in the the /dev directory and run it.
+If the above command doesn't work (and you are the root user), look
+for the MAKEDEV script in the /dev directory and run it.
This handles the devices creation and should set the correct permissions.
For making multiport devices see [ can snoop
+ on serial line traffic (via a wiretap) and also send/receive on a
+ serial line.
]- The "file": /proc/tty/driver/serial lists those that are
asserted (positive voltage)
-
- modemstat (Only works correctly on Linux PC consoles. Status
+
- modemstat (Only works correctly on Linux PC consoles.) Status
monitored in a tiny window. Color-coded and compact. Must kill
it (a process) to quit.
- statserial (Info displayed on entire screen)
@@ -2550,6 +2579,7 @@ June 2001 OK to use setserial with Laptops
Nov. 2002 Debian's /var/lib/serial.conf
Nov. 2003 Major revision. Plug-and-play dominates
May 2004 Old Debian 1999 bug reported by me removed (fixed in 1999)
+Feb.2005 Where config files reside
/var/lib/setserial/autoserial.conf
-->
This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
@@ -2561,25 +2591,35 @@ If you have a Laptop (PCMCIA) don't use .
Introduction
-/usr/doc/setserial.../ or /usr/share/doc/setserial .
@@ -2679,13 +2721,11 @@ Note that setserial calls an IO address a "port". If you type:
setserial -g /dev/ttyS*
-you'll see some info about how the device driver is configured for
-your ports. Note that where it says "UART: unknown" it
-probably means that no uart exists. In other words, you probably have
-no such serial port and the other info shown about the port is
-meaningless and should be ignored. If you really do have such a
-serial port, setserial doesn't recognize it and that needs to be
-fixed.
+You'll see some info about how the device driver is configured for
+your ports. In many cases you'll see some ports displayed with what
+appears at first glance to be erroneous IRQs and addresses. But if
+you also see: "UART: unknown" just ignore the entire line
+since no serial port exists at that address.
If you add -a to the option -g you will see more info although few
people need to deal with (or understand) this additional info since
@@ -2712,8 +2752,14 @@ resources with setserial.
off, a configuration file may restore them when the PC is started
up again. In newer versions, what you change by setserial might get
automatically saved to a configuration file. When
- Don't use this file at all. At each boot, the serial driver
@@ -2771,7 +2817,8 @@ IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into a
-configuration file such as
/etc/serial.conf or
+distribution-specific configuration file such as
+/etc/serial.conf or /etc/sysconfig/serial or
/var/lib/setserial/autoserial.conf for Debian. This will be
used next time you start Linux.
@@ -2817,10 +2864,11 @@ things up. It may also depends on the runlevel.
Before modifying a configuration file, you can test out a "proposed"
.
+saved somewhere such as /etc/serial.conf (or autoserial.conf or
+serial) when you shutdown. So if it worked OK (and solved your
+problem) then there's no need to modify any configuration file. See
+[.
] Edit a script (required prior to version 2.15)
@@ -2842,9 +2890,9 @@ using it.
The script /etc/rc.d/rc.serial was commonly used in the past.
The Debian distribution used /etc/rc.boot/0setserial .
Another file once used was /etc/rc.d/rc.local but it's may
-not have run early enough. It's was reported that other processes may
+not have run early enough. It was reported that other processes may
try to open the serial port before rc.local ran resulting in serial
-communication failure. Later on it's most likely was found in
+communication failure. Later on it most likely was found in
/etc/init.d/ but wasn't normally intended to be edited.
If such a file was supplied, it likely contained a number of
@@ -2857,12 +2905,12 @@ Testing like this was a lot faster than doing repeated reboots to get
it right.
For versions >= 2.15 (provided your distribution implemented the
-change, Redhat didn't as first) it may be more tricky to do since the
+change, Redhat didn't at first) it may be more tricky to do since the
file that runs setserial on startup, /etc/init.d/setserial or the like
was not intended to be edited by the user. See [.
-An example line in such a script was"
+An example line in such a script was:
]
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
@@ -2883,16 +2931,17 @@ cases it didn't work right due to the hardware.
Prior to setserial version 2.15 (1999), the way to configure
setserial was to manually edit the shell-script that ran setserial at
boot-time. See [. Today the script and configuration file are two
-different files instead of one. This shell-script is not edited but
-gets its data from a configuration file such as
-]/etc/serial.conf (or
+version 2.15)">. This was simple, but the simple and clear method has
+been changed to something that is unnecessarily complex. Today the
+script and configuration file are two different files instead of one.
+This shell-script is not edited but gets its data from a configuration
+file such as /etc/serial.conf (or
/var/lib/setserial/autoserial.conf ).
Furthermore you may not even need to edit serial.conf (or the like)
because using the "setserial" command on the command line may
automatically cause serial.conf to be edited appropriately. This was
-done so that you don't need to edit any file in order to set up (or
+done so that you may not need to edit any file in order to set up (or
change) what setserial does each time that Linux is booted.
What often happens is this: When you shut down your PC the script
@@ -2909,19 +2958,23 @@ don't shut down normally (someone turns the power off, etc.) and the
changes don't get saved. Suppose you experiment with "setserial" and
forget to run it a final time to restore the original state (or make a
mistake in restoring the original state). Then your "experimental"
-settings are saved. There's an option to avoid this in Debian known
-as "AUTOSAVE-ONCE" which will be discussed later on.
+settings are saved. And worst of all, unless you know which options
+were set in the configuration file, you don't know what will happen.
+One option in Debian (and likely other distributions) is known as
+"AUTOSAVE-ONCE" which saves changes only for the first time you make
+them with the setserial command.
-If you manually edit serial.conf, then your editing is destroyed when
-you shut down because it gets changed back to the state of setserial
-at shutdown. There is a way to disable the changing of serial.conf at
-shutdown and that is to remove "###AUTOSAVE###" or the like from first
-line of serial.conf. In the Debian distribution, the removal of
-"###AUTOSAVE###" from the first line was once automatically done after
-the first time you shutdown just after installation. To retain this
-effect the "AUTOSAVE-ONCE" option was created which only does a save
-when time the system is shut down for the first time (just after you
-install or update the setserial program).
+If the option "###AUTOSAVE###" is set and you manually edit
+serial.conf, then your editing is destroyed when you shut down because
+it gets changed back to the state of setserial at shutdown. There is
+a way to disable the changing of serial.conf at shutdown and that is
+to remove "###AUTOSAVE###" or the like from first line of serial.conf.
+In the Debian distribution, the removal of "###AUTOSAVE###" from the
+first line was once automatically done after the first time you
+shutdown just after installation. To retain this effect the
+"AUTOSAVE-ONCE" option was created which only does a save when time
+the system is shut down for the first time (just after you install or
+update the setserial program).
The file most commonly used to run setserial at boot-time (in
conformance with the configuration file) is now /etc/init.d/setserial
@@ -2952,7 +3005,7 @@ Debian labeled obsolete files with "...pre-2.15".
ttyS3 share IRQ 3. But while sharing serial interrupts (using them in
running programs) is OK for the PCI bus, it's not permitted for the
ISA bus unless you: 1. have kernel 2.2 or better, and 2. you've
-complied in support for this, and 3. your serial hardware supports it.
+compiled in support for this, and 3. your serial hardware supports it.
See
[
@@ -2962,9 +3015,9 @@ since IRQ sharing conflicts don't exist for non-existent devices.
If you add a legacy internal modem (without plug-and-play) and retain
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
-it both on your serial port (or modem card) and then use setserial to
+it in your serial port (or modem card) 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 serial port for a modem.
+sound card, this could be used for a modem.
] Laptops: PCMCIA
If you have a Laptop, read PCMCIA-HOWTO for info on the serial
@@ -2983,18 +3036,20 @@ the driver is configured for PCMCIA cards.
Stty
+In Serial and Text-Terminal
+Feb. 2005: Put redirection info into Obsolete section
+-->
Introduction
"man stty" or "info stty" .
@@ -3025,17 +3080,18 @@ that you don't need stty.
One may write C programs which change the stty configuration, etc.
Looking at some of the documentation for this may help one better
understand the use of the stty command (and its many possible
-arguments). Serial-Programming-HOWTO is useful. The manual page:
-termios contains a description of the C-language structure (of type
-termios) which stores the stty configuration in computer memory. Many
-of the flag names in this C-structure are almost the same (and do the
-same thing) as the arguments to the stty command.
+arguments). Serial-Programming-HOWTO may be useful but it's outdated.
+The manual page: termios contains a description of the C-language
+structure (of type termios) which stores the stty configuration in
+computer memory. Many of the flag names in this C-structure are
+almost the same (and do the same thing) as the arguments to the stty
+command.
Flow control options
To set hardware flow control use "crtscts". For software flow
control there are 3 settings: ixon, ixoff, and ixany.
-ixany: Mainly for terminals. Hitting any key will restarts the flow
+ixany: Mainly for terminals. Hitting any key will restart the flow
after a flow-control stop. If you stop scrolling with the "stop
scroll" key (or the like) then hitting any key will resume scrolling.
It's seldom needed since hitting the "scroll lock" key again will do
@@ -3050,64 +3106,24 @@ when its buffers in main memory are nearly full. It protects the
device where the port is located from being overrun.
For a slow dumb terminal (or other slow device) connected to a fast
-PC, it's unlikely the the PC's port will be overrun. So you seldom
+PC, it's unlikely the PC's port will be overrun. So you seldom
actually need to enable ixoff. But it's often enabled "just in case".
Using stty at a "foreign" terminal
- Using = 1.17 and stty >=
-2.0) there is a better method using the -F option. This will work
-when the old redirection method fails. Even with the latest versions
-be warned that if there is a terminal on ttyS2 and a shell is running
-on that terminal, then what you see will likely be deceptive and
-trying to set it will not work. See [ to understand it.
+]How do you use stty to view or set a terminal other than the
+terminal you are currently using? It's usually impossible to do it if
+the foreign terminal is in use and has a shell running on it. In
+other cases for dealing with say ttyS2 while typing at another
+terminal (such as tty1) use stty -F /dev/ttyS2 ... (or
+--file instead of F). If ... is -a it displays all the stty settings
+(-a means all).
-The new method is ``stty -F /dev/ttyS2 ...'' (or --file instead of F).
-If ... is -a it displays all the stty settings. The old redirection
-method (which still works in later versions) is to type ``stty ... <
-/dev/ttyS2''. If the new method works but the old one hangs, it
-implies that the port is hung due to a modem control line not being
-asserted. Thus the old method is still useful for troubleshooting.
-See the following subsection for details.
-
- Old redirection method
- Here's a problem with the old redirection operator (which doesn't
-happen if you use the newer -F option instead). Sometimes when trying
-to use stty, the command hangs and nothing happens (you don't get a
-prompt for a next command even after hitting <return>). This is
-likely due to the port being stuck because it's waiting for one of the
-modem control lines to be asserted. For example, unless you've set
-"clocal" to ignore modem control lines, then if no CD signal is
-asserted the port will not open and stty will not work for it (unless
-you use the newer -F option). A similar situation seems to exist for
-hardware flow control. If the cable for the port doesn't even have a
-conductor for the pin that needs to be asserted then there is no easy
-way to stop the hang.
-
-One way to try to get out of the above hang is to use the newer -F
-option and set "clocal" and/or "crtscts" as needed. If you don't have
-the -F option then you may try to run some program (such as minicom) on
-the port that will force it to operate even if the control lines say
-not to. Then hopefully this program might set the port so it doesn't
-need the control signal in the future in order to open: clocal or
--crtscts. To use "minicom" to do this you likely will have to
-reconfigure minicom and then exit it and restart it. Instead of all
-this bother, it may be simpler to just reboot the PC.
-
-The old redirection method makes ttyS2 the standard input to stty.
-This gives the stty program a link to the "file" ttyS2 so that it may
-"read" it. But instead of reading the bytes sent to ttyS2 as one
-might expect, it uses the link to find the configuration settings of
-the port so that it may read or change them. Some people tried to use
-``stty ... > /dev/ttyS2'' to set the terminal. This will not do it.
-Instead, it takes the message normal displayed by the stty command for
-the terminal you are on (say tty1) and sends this message to ttyS2.
-But it doesn't change any settings for ttyS2.
+But if the foreign terminal (ttyS2 in this example) has a shell
+running on it, then what you see will likely be deceptive and trying
+to set it will not work. This problem exists for virtual terminals
+also such as dealing with tty3 from tty1, etc. See [ to
+understand it.
] Two interfaces at a terminal
When using a shell (such as bash) with command-line-editing
@@ -3119,29 +3135,30 @@ hit the <return> key, the command-line-editor is exited and the
terminal interface is changed to the nominal "cooked" interface
(cooked mode) for the terminal. This cooked mode lasts until the next
prompt is sent to the terminal (which is only a small fraction of a
-second). Note that one never gets to type anything to this cooked
-mode but what was typed in raw mode gets executed while in cooked
-mode.
+second). Note that one never gets to type any command in this cooked
+mode but what was typed in raw mode on the command line gets read by
+the shell while in cooked mode.
When a prompt is sent to the terminal, the terminal goes from "cooked"
-to "raw" mode (just like it does when you start an editor since you
-are starting the command-line editor). The settings for the "raw"
-mode are based only on the basic settings taken from the "cooked"
-mode. Raw mode keeps these setting but changes several other settings
-in order to change the mode to "raw". It is not at all based on the
-settings used in the previous "raw" mode. Thus if one uses stty to
-change settings for the raw mode, such settings will be permanently
-lost as soon as one hits the <return> key at the terminal that
-has supposedly been "set".
+to "raw" mode (just like it does when you start an editor such as vim.
+The prompt signals starting the command-line editor. The settings for
+the "raw" mode are based only on the basic stty settings taken from the
+"cooked" mode. Raw mode keeps these setting but changes several other
+settings in order to change the mode to "raw". It is not at all based
+on the settings used in the previous "raw" mode. Thus if one uses
+stty to change settings for the raw mode, such settings will be
+permanently lost as soon as one hits the <return> key at the
+terminal that has supposedly been "set".
Now when one types stty to look at the terminal interface, one may
either get a view of the cooked mode or the raw mode. You need to
-figure out which one you're looking at. It you use stty from another
-(foreign) terminal then you will see the raw mode settings. Any
-changes made will only be made to the raw mode and will be lost when
-someone presses <return> at the terminal you tried to "set".
-But if you type a stty command at your terminal (without the -F option
-or redirection) and then hit <return> it's a different story.
+figure out which one you're looking at. It you use stty from a
+foreign terminal (other than the terminal you are currently typing
+at) then you will see the raw mode settings. Any changes made will
+only be made to the raw mode and will be lost when someone presses
+<return> at the foreign terminal you tried to "set". But if you
+type a stty command to view/change the configuration of the terminal
+you are using, and then hit <return> it's a different story.
The <return> puts the terminal in cooked mode. Your changes are
saved and will still be there when the terminal goes back into raw
mode (unless of course it's a setting not allowed in raw mode).
@@ -3177,6 +3194,53 @@ so that the low level stuff is done first. If you have directories in
the /etc tree where every file in them is executed at boot-time
(System V Init) then you could create a file named "stty" for this
purpose.
+
+ Obsolete redirection method
+Prior to about 2000 you needed to use the redirection operator "<"
+if you wanted to use stty on a foreign terminal. For example to use
+stty on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2.
+After 2000 (provided your version of setserial is >= 1.17 and stty >=
+2.0) a better method was created using the -F option: stty -F
+/dev/ttyS2. This will work when the old redirection method fails.
+
+The old redirection example above makes ttyS2 the standard input to
+stty. This gives the stty program a link to the "file" ttyS2 so that
+it may "read" it. But instead of reading the bytes sent to ttyS2 as
+one might expect, it uses the link to find the configuration settings
+of the port so that it may read or change them. In olden days, some
+people tried to use ``stty ... > /dev/ttyS2'' to set the terminal.
+This didn't work. Instead, it takes the message normal displayed
+by the stty command for the terminal you are on (say tty1) and sends
+this message to ttyS2. But it doesn't change any settings for ttyS2.
+
+Here's a problem with the old redirection operator (which doesn't
+happen if you use the newer -F option instead). Sometimes when trying
+to use stty, the command hangs and nothing happens (you don't get a
+prompt for a next command even after hitting <return>). This is
+likely due to the port being stuck because it's waiting for one of the
+modem control lines to be asserted. For example, unless you've set
+"clocal" to ignore modem control lines, then if no CD signal is
+asserted the port will not open and stty will not work for it (unless
+you use the newer -F option). A similar situation seems to exist for
+hardware flow control. If the cable for the port doesn't even have a
+conductor for the pin that needs to be asserted then there is no easy
+way to stop the hang.
+
+One way to try to get out of the above hang is to use the newer -F
+option and set "clocal" and/or "crtscts" as needed. If you don't have
+the -F option then you may try to run some program (such as minicom) on
+the port that will force it to operate even if the control lines say
+not to. Then hopefully this program might set the port so it doesn't
+need the control signal in the future in order to open: clocal or
+-crtscts. To use "minicom" to do this you likely will have to
+reconfigure minicom and then exit it and restart it. Instead of all
+this bother, it may be simpler to just reboot the PC.
+
+The obsolete redirection method (which still works in later versions)
+is to type ``stty ... < /dev/ttyS2''. If the new method using -F
+works but the obsolete one hangs, it implies that the port is hung due
+to a modem control line not being asserted. Thus the obsolete
+redirection method might still useful for troubleshooting.
@@ -3191,11 +3255,23 @@ 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.
- What is slattach?
- It's "serial line attach". It puts the serial line into a
-networking mode. You can thus network two computers together via a
-serial line using, for example, the slip protocol. But for the ppp
-protocol, you need to start pppd on the serial line.
+ Connecting two PCs together via serial ports
+This is where you run a serial cable (crossover type = null-modem
+type) between the serial ports of two PCs. Then how do you use this
+line? One way is for one PC to run login on the serial line and for
+the other PC to run say minicom to emulate a terminal. See
+Text-Terminal-HOWTO. There is no network protocol used in this case
+and no error detection.
+
+The other method is to run a network protocol on the line. For
+example, to use PPP in combination with TCP/IP see Serial Laplink
+HOWTO. Although this HOWTO doesn't mention the old program "slattach"
+(serial line attach) it can put the serial line into a networking mode
+using the protocol you select. Protocols for slattach include PPP or
+SLIP (an older protocol widely used prior to PPP).
+
+The Debian package, net-tools, contains slattach. SLIP is provided as
+a kernel module or can be built into the kernel (2.2, 2.4, or 2.6).
Speed (Flow Rate)
@@ -3209,7 +3285,7 @@ uses the serial port. See [
section is unique to each HOWTO.
Feb. 2003,
-->
-] Speeds over 115.2k
+ Speeds over 115.2kbps
The top speed of 115.2k has been standard since the mid 1990's.
But by the year 2000, most new serial ports supported higher speeds of
230.4k and 460.8k. Some also support 921.6k. Unfortunately Linux
@@ -3387,14 +3463,14 @@ ahead and use the port anyway (after removing the stale lock-files).
Unfortunately, there may be some programs that don't do this and give
up by telling you that a device is already in use when it really isn't.
-When there were only lockfiles with device names, the following
-problem could arise: If the same device has two different
-names then two different processes could each use a different name for
-the same device. This results in lockfiles with different names that
-actually are the same device. Formerly each physical serial port was
-known by two different device names: ttyS0 and cua0. To solve this
-lockfile alias problem, 3 methods have been used. It may be overkill
-since any one of these methods would have fixed the problem.
+If the lockfile only uses device names, the following problem could
+arise: If the same device has two different names then two different
+processes could each use a different name for the same device. This
+results in lockfiles with different names that actually are the same
+device. Formerly each physical serial port was known by two different
+device names: ttyS0 and cua0. To solve this lockfile alias problem, 3
+methods have been used. It may be overkill since any one of these
+methods would have fixed the problem.
- The lock checking software was made aware of ttyS vs. cua.
@@ -3404,9 +3480,11 @@ since any one of these methods would have fixed the problem.
Using alternate names such as /dev/modem for /dev/ttyS2 may cause
-problems with older versions. For dumb terminals, lockfiles are not
-used since this would not permit someone else to send a message to
-your terminal using the write or talk program.
+problems if one program opens /dev/ttyS2 while another program opens
+/dev/modem. This problem was supposedly fixed around 2000, but is
+still present in 2005. For dumb terminals, lockfiles are not used
+since this would not permit someone else to send a message to your
+terminal using the write or talk program.
Lock-Files if you use devfs
The abandoned device-filesystem (devfs) has the /dev directory with
@@ -3414,7 +3492,6 @@ subdirectories. As of late 2001, there were problems with lockfiles.
For example, the lockfile mechanism considered dev/usb/tts/0 and
/dev/tts/0 to be the same device with name "0". Ditto for all other
devices that had the same "leaf" name.
-
Also, if some applications use the old name for a device and other
applications use the devfs name for the same device, then the
lockfiles will have different names. But the serial driver should
@@ -3503,26 +3580,31 @@ prompt.
Serial Tips And Miscellany
- Serial Module
+ Serial Modules
Often the serial driver is provided as a module. Parameters may
-be supplied to certain modules in /etc/modules.conf. Since kernel 2.2
-you don't edit this file but use the program update-modules to change
-it. The info that is used to update modules.conf is put in
-/etc/modutils/. The Debian/GNU Linux has a file here named
-/etc/modutils/setserial which runs the serial script in /etc/init.d/
-every time the serial module is loaded or unloaded. When the serial
-module is unloaded this script will save the state of the module in
-/var/run/setserial.conf. Then if the module loads again this saved
-state is restored. When the serial module first loads at boot-time,
-there's nothing in /var/run/setserial.conf so the state is obtained
-from /etc/serial.conf. So there are two files that save the state.
-Other distributions may do something similar.
+be supplied to certain modules in /etc/modules.conf or
+/etc/modprobe.conf. Since kernel 2.2 you don't edit this file but use
+the program update-modules to change it. The info that is used to
+update modules.conf is put in /etc/modutils/.
+
+The Debian/GNU Linux has a file named /etc/modutils/setserial which
+runs the serial script in /etc/init.d/ every time the serial module is
+loaded or unloaded. When the serial module is unloaded this script
+will save the state of the module in /var/run/setserial.conf. Then if
+the module loads again this saved state is restored. When the serial
+module first loads at boot-time, there's nothing in
+/var/run/setserial.conf so the state is obtained from
+/etc/serial.conf. So there are two files that save the state. Other
+distributions may do something similar.
+
+The module, parport_serial is for PCI cards that contain both serial
+and parallel ports.
One may modify the serial driver by editing the source code. Much of
the serial driver is found in the file serial.c. For info
regarding writing of programs for the serial port see
Serial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie but
-it's not at LDP and it's not now available.
+that revision is not at LDP.
Serial Console (console on the serial port)
See the kernel documentation in: Documentation/serial-console.txt.
@@ -3533,7 +3615,7 @@ Text-Terminal-HOWTO.
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
+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.
@@ -3683,45 +3765,59 @@ Jan. '03: LSR safety check error
Feb. '03: Interrupts may be shared on PCI Bus
June '03: Wvdial: busy message due to lockfile permissions
Dec. '03: Scanport can also detect an enabled PnP port
+Feb. '04: Cannot open /dev/ttyS?
+Feb. '05: Revised "Serial Port Can't be Found", /proc tree
+May '05<>Linux Creates an Interrupt Conflict (your PC has an ISA slot)
-->
(The following subsections are in both the Serial and Modem HOWTOs)
- My Serial Port is Physically There but Can't be Found
+ Serial Port Can't be Found
- If a physical device (such as a modem) doesn't work at all it's
-often because it's disabled and has no address (PnP hasn't enabled it)
-or that it is enabled but is not at the I/O address that setserial
-thinks it's at. Thus it can't be found.
+
There are 3 possibilities:
+
+- Your port is disabled since both the BIOS and Linux failed to
+enable it. It has no IO address.
+
- Your port is enabled and has an IO address but it has no ttyS
+device number (like ttyS14) assigned to that address so the modem
+can't be used. You may need to use "setserial" to assign a ttyS
+number to it.
+
- Your port does have a ttyS number assigned to it (like ttyS14)
+but you don't know which physical connector it is (on the back of your
+PC).
+
+See
[
+
+]
First check BIOS messages at boot-time (and possibly the BIOS menu for
-the serial port). Then for the PCI bus use lspci. If this shows
+the serial port). Then for the PCI bus type lspci -v. If this shows
something like "LPC Bridge" then your port is likely on the LPC bus
which is not well supported by Linux yet (but the BIOS might find it)
?? If it's an ISA bus PnP serial port, try "pnpdump --dumpregs"
and/or see Plug-and-Play-HOWTO. If the port happens to be enabled
-then the following two paragraphs may help find it:
+then the following two paragraphs may help find the IO port:
+
+ Scanning/probing legacy ports
+This is mainly for legacy non-PCI ports and ISA ports that are not
+Plug-and-Play.
Using "scanport" (Debian only ??) will scan all enabled bus ports and
may discover an unknown port that could be a serial port (but it
-doesn't probe the port). It could hang your PC. You may try probing
-with setserial. See [.
+doesn't probe the port). It could hang your PC. If you suspect that
+your port may be at a certain address, you may try manually probing
+with setserial, but it's a slow tedious task if you have several
+addresses to probe. See ][.
-If nothing seems to get thru the port it may be accessible but have a
-bad interrupt. See ][. Use ]setserial -g
-to see what the serial driver thinks and check for IRQ and I0 address
-conflicts. Even if you see no conflicts the driver may have incorrect
-information (view it by "setserial") and conflicts may still exist.
-
-If two ports have the same IO address then probing it will erroneously
-indicate only one port. Plug-and-play detection will find both ports
-so this should only be a problem if at least one port is not
-plug-and-play. All sorts of errors may be reported/observed for
-devices illegally "sharing" a port but the fact that there are two
-devices on the same a port doesn't seem to get detected (except
-hopefully by you). In the above case, if the IRQs are different then
-probing for IRQs with setserial might "detect" this situation by
-failing to detect any IRQ. See [.
+]Linux Creates an Interrupt Conflict (your PC has an ISA slot)
+If your PC has a BIOS that handles ISA (and likely PCI too) then
+if you find a IRQ conflict, it might be due to a shortage of free
+IRQs. The BIOS often maintains a list of reserved IRQs, reserved for
+legacy ISA cards. If too many are reserved, the BIOS may not be able
+to find a free IRQ and will erroneously assign an IRQ to the serial
+port that creates a conflict. So check to see if all the reserved
+IRQs are really needed and if not, unreserve an IRQ that the serial
+port can use. For more details, see Plug-and-Play-HOWTO.
Extremely Slow: Text appears on the screen slowly after long delays
@@ -3787,7 +3883,7 @@ id="set_serial" name="What is Setserial"> for more info. If you
really do have an obsolete serial port, lying about it to setserial
will only make things worse.
-The Startup Screen Show Wrong IRQs for the Serial Ports.
+The Startup Screen Shows Wrong IRQs for the Serial Ports
For non-PnP ports, Linux does not do any IRQ detection on startup.
When the serial module loads it only does serial device detection.
@@ -3818,6 +3914,19 @@ programs change the permissions when they run but restore them when
the program exists normally. But if someone pulls the plug on your
PC it's an abnormal exit and correct permissions may not be restored.
+ "Cannot open /dev/ttyS?"
+Unless stty is set for clocal, the CD pin may need to be asserted
+in order to open a serial port. If the physical port is not connected
+to anything, or if it's connected to something that is not powered on
+(such an external modem) then there will be no voltage on CD
+from that device. Thus the "cannot open" message. Either set clocal
+or connect the serial port connector to something and power it on.
+
+Even if a device is powered on and connected to a port, it may
+sometimes prevent opening the port. An example of this is where the
+device has negated CD and the CD pin on your PC is negated (negative
+voltage).
+
"Operation not supported by device" for ttyS?
This means that an operation requested by setserial, stty, etc.
couldn't be done because the kernel doesn't support doing it.
@@ -3977,8 +4086,10 @@ troubleshooting:
name="What is Setserial">
- "stty" shows and sets the configuration of a port (except for
that handled by "setserial").
- See the section
- "modemstat" or "statserial" will show the current state of
- various modem signal lines (such as DTR, CTS, etc.)
+ See the section
- "modemstat" or "statserial" or "watch head
+/proc/tty/driver/serial" will show the current state of various modem
+signal lines (such as DTR, CTS, etc.). The one in /proc also shows
+byte flow and errors.
- "irqtune" will give serial port interrupts higher
priority to improve performance.
- "hdparm" for hard-disk tuning may help some more.
@@ -4091,19 +4202,19 @@ 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
+interrupt method of servicing the port there's an undocumented 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. Don't confuse this slow polling method with
-the fast polling method that operates on ports that have their
-IRQs set to 0.
+the fast polling method that operates on ports that have their IRQs
+set to 0.
For the 16-byte transmit buffer, 16 bytes will be transmitted and then
it will wait until the next polling takes place (several seconds
@@ -4119,7 +4230,8 @@ 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 slow
polling delays at the serial port, you don't see what you typed
-until many seconds later.
+until perhaps 15 seconds later. Even then, you don't often see all
+you typed but only the first several characters.
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
@@ -4780,9 +4892,9 @@ topic.
The Universal Serial Bus (USB)
The Universal Serial Bus (USB) is being built into PCI chips.
-Newer PC's have them. It is 12 Mbps (with 200 Mbps planned) over a
-twisted pair with a 4-pin connector (2 wires are power supply). It
-also is limited to short distances of at most 5 meters (depends on
+Newer PC's have them. It was originally 12 Mbps but is now 480 Mbps
+over a twisted pair with a 4-pin connector (2 wires are power supply).
+It also is limited to short distances of at most 5 meters (depends on
configuration). Linux supports the bus, although not all devices that
can plug into the bus are supported.
@@ -4929,12 +5041,11 @@ Notes re books:
Serial Software
- It's best to use the nearest mirror site, but here's the main
-sites:
- If it's not available in your Linux distribution try:
+ for Linux software for the serial ports
including getty and port monitors.
- for communication programs.
@@ -4989,31 +5100,56 @@ meaning of "stty" commands, etc.
-
Includes info about PCI support.
+
+-
Serial-Programming-HOWTO (not yet available
+from the Linux Documentation Project). It's now on my website:
+
+See also:
+-
+
- A white paper discussing serial communications and multiport
serial boards was available from Cyclades at
.
+
+-
- Appendix: Obsolete Hardware (prior to 1990) Info
+ Appendix A: Obsolete Hardware/Software
-Replacing obsolete UARTS
+Replacing pre 1990 UARTS
Many 486 PCs (old) and all Pentiums (or the like) should have
modern 16550As (usually called just 16550's) with FIFOs. 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 built into 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
+something really old (pre 1990), 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 built into 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 card on
the Internet (few retail stores stock them today) or find a used one.
-
END OF Serial-HOWTO
-