David S.Lawyer [email protected]
original by Greg Hankins
v2.27 February 2011 This document is for the UART serial port. This port has mostlydisappeared from desktops and laptops is still used elsewhere such asfor embedded systems. It covers information other than that whichshould be covered by Modem-HOWTO, PPP-HOWTO, Serial-Programming-HOWTO,or Text-Terminal-HOWTO. It lists info on multiport serial cards. Itcontains technical info about the serial port itself in more detailthan found in the above HOWTOs and should be best for troubleshootingwhen the problem is the serial port itself. If you are dealing with aModem, PPP (used for Internet access on a phone line), or aText-Terminal, those HOWTOs should be consulted first. Programming the Serial Port. In this tutorial i am going to use C language to program the Serial port,compiler used is GCC. If you are interested to know more about the internals of the serial port you can refer “The Serial Programming Guide for POSIX Operating Systems” written by Michael R.Sweet. Basics: Serial communication with AVR microcontrollers. One of the distinguishing characteristics of beginner- friendly microcontroller platforms– Arduino Thanks to Node Serialport, that world is here. Node-Serialport provides a stream interface for the low-level serial port code necessary to controll.
This HOWTO covers basic info on the serial port which is missingon newer personal computers but is being used in recentembedded systems as well as for routers, point-of-sale equipment, etc.It includes multiport serial cards. It was written when the serialport was a major port for connecting a PC to modems and printers, etc.and the style of this article reflects this. If you're havingproblems with the serial port, want to understand how it works, orneed a detailed introduction to it before studying serial programming,this is one place to find out about it.
This HOWTO is about the original serial port which uses a UARTchip and is sometimes called a 'UART serial port' to differentiate itfrom the newer types of serial devices: Universal Serial Bus orFirewire. It's slowcompared to newer serial devices but can send text several timesfaster than you can read it. Information specific to devices whichuse serial ports: analog modems, text-terminals, infrared devices, anda few printers are found in Modem-HOWTO, Text-Terminal-HOWTO,Infrared-HOWTO, and Printing-HOWTO. Info on getty (the program thatruns the login process or the like) has been also moved to otherrelated HOWTOs since mgetty and uugetty are best for modems whileagetty is best for text-terminals. If you are dealing with a modem,text terminal, infrared device, or printer, then you may not need toconsult this HOWTO. But if you are using the serial port for someother device, using a multiport serial card, trouble-shooting theserial port itself, or want to understand more technical details ofthe serial port, then you may want to use this HOWTO as well as someof the other HOWTOs. (See Related HOWTO's) This HOWTO lists info on various multiport serial cards.This HOWTO addresses Linux running on PCs (ISA and/or PCI buses),although it might be valid for other architectures.
Copyright
Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2005 by David S.Lawyer mailto:[email protected]
Please freely copy and distribute (sell or give away) this documentin any format. Send any corrections and comments to the documentmaintainer. You may create a derivative work and distribute itprovided that you:
- If it's not a translation: Email a copy of your derivative work(in a format LDP accepts) to the author(s) and maintainer (could bethe same person). If you don't get a response then email the LDP(Linux Documentation Project): [email protected].
- License the derivative work in the spirit of this license or useGPL. Include a copyright notice and at least a pointer to thelicense used.
- Give due credit to previous authors and major contributors.
If you're considering making a derived work other than atranslation, it's requested that you discuss your plans with thecurrent maintainer.
Disclaimer
While I haven't intentionally tried to mislead you, there arelikely a number of errors in this document. Please let me know aboutthem. Since this is free documentation, it should be obvious that Icannot be held legally responsible for any errors.
Trademarks.
Any brand names (starts with a capital letter such as MS Windows)should be assumed to be a trademark). Such trademarks belong to theirrespective owners.
Credits
Most of the original Serial-HOWTO was written by Greg Hankins.mailto:[email protected] also rewrote many contributions by others in order to maintaincontinuity in the writing style and flow. He wrote: ``Thanks toeveryone who has contributed or commented, the list of people hasgotten too long to list (somewhere over one hundred). Special thanksto Ted Ts'o for answering questions about the serial drivers.'Approximately half of v2.00 was from Greg Hankins HOWTO and the otherhalf were additions by David Lawyer. Ted Ts'o has continued to behelpful. In Jan. 2006 'Charles Brockman' reviewed it for typos whichresulted in many typos being fixed.
New versions will be issued perhaps every year or two. They will beavailable to browse and/or download at LDP mirror sites see: http://www.tldp.org/mirrors.html. Various formats areavailable. If you only want to quickly check the date of the latestversion look at http://www.tldp.org/HOWTO/Serial-HOWTO.html and compare it tothis version: v2.27 February 2011 .
For a full revision history goingback to the time I started maintaining this HOWTO, see the source file(in linuxdoc format): (cvs) Serial-HOWTO.sgml
- TO do: explain use of udev for serial port for setting namesand permissions. Fix dead links.
- 2.27 Feb. 2011: The serial port is still widely used in embeddedsystems, etc., and is not really obsolete. Better definition ofinput, output. Deleted devfs names such as tts.
- 2.26 Nov. 2010 Changed EIA-232 to RS-232. PCI-e bus is serial. Noserial port on new PCs. I incorrectly wrote in this update that the serial port was obsolete and that this HOWTO is now mainly of historical interest.
- 2.25 Jan. 2007 picocom. devfs is obsolete. ser2net. Revisedparts on drivers as modules vs. built into kernel. Serial Programmingwikibook.
Modems, Text-Terminals, some printers, and other peripherals oftenused the serial port. Get these HOWTOs from the nearest mirror site asexplained above.
Modem-HOWTO
is about installing and configuring modemsPrinting-HOWTO
has info for serial printers using oldlpr commandLPRng-HOWTO
(not a LDP HOWTO, may come with software)has info for serial printing for 'Next Generation' lpr- Serial Programming is a wiki-bookon the Internet
Serial-Programming-HOWTO
helps you writeC programs that read and write to the serial portand/or check/set its state. A version written by Vern Hoxie but notsubmitted to LDP is at Internet section.Text-Terminal-HOWTO
is about how they work, how to installconfigure, and repair them. It includes a section on 'Make aTerminal the Console' which is useful for using a remote terminal tocontrol a server (via the serial port).Remote-Serial-Console-HOWTO
is about making atext-terminal be the console so it can display boot-time messages, etc.
Please send me any suggestions, correction or additionalmaterial. Tell me what you don't understand, or what could beclearer. You can reach me via email at
mailto:[email protected]
. The conventional serial port (not the newer USB port, or Firewireport) is a very old I/O (Input/Output) port. Until around 2006, mostnew desktop PC's had one, and old PC's from the 1990's sometimes had 2of them. Most laptops gave up them before the desktops did. Macs(Apple Computer) after mid-1998 only had the USB port. However, it'spossible, to put a conventional serial port device on the USB buswhich is on all modern PCs.
Each serial port has a 'file' associated with it in the /devdirectory. It isn't really a file but it seems like one. Forexample, /dev/ttyS0. Other serial ports are /dev/ttyS1, /dev/ttyS2,etc. But ports on the USB bus, multiport cards, etc. have differentnames.
The common specification for the conventional serial port is RS-232(or RS-232). So it's often called a 'RS-232 serial port'. Theconnector(s) for the serial port are often seen as one or two 9-pinconnectors (in some cases 25-pin) on the back of a PC. But the serialport is more than just connectors. It includes the associatedelectronics which must produce signals conforming to the RS-232specification. See Voltage Waveshapes.One pin is used to send out data bytes and another to receive databytes. Another pin is a common signal ground. The other 'useful'pins are used mainly for signalling purposes with a steady negativevoltage meaning 'off' and a steady positive voltage meaning 'on'.
The UART (Universal Asynchronous Receiver-Transmitter) chip does mostof the work. Today, the functionality of this chip is usually builtinto another chip. See What Are UARTs? Thesehave improved over time and old models (prior to say 1994) are usuallyvery obsolete.
The serial port was originally designed for connecting external modemsto a PC but it's used to connect many other devices also such as mice,text-terminals, some printers, etc. to a computer. You just plugthese devices into the serial port using the correct cable. Manyinternal modem cards have a built-in serial port so when you installone inside your PC it's as if you just installed another serial portin your PC.
This repeats more detailed information found elsewhere. If yourcomputer can't seem to find your serial port and you already knowsomething about hardware resources (addresses like 3F8 and IRQs like5) then try this: First, get into the BIOS (often called 'setup')when the computer is powered on by pressing certain keys. To find outwhat keys to press, watch the screen as your PC starts up. Ifthe words that flash by on the screen too fast to read, freeze them by holding down the 'pause' and 'shift' keys at the same time. Thenwhen read, hit any key to resume (cease pausing) and hold down thekey(s) required to enter the BIOS setup. You may have to try thisagain since there may be more than one screen which you can freezewith the 'pause' key. Also, look for messages about the serial portson these frozen screens.
Once in the BIOS menus, try to find menus dealing with the serial port.They could be shown in a menu dealing with Resources, Plug-and-Play,Peripherals, Ports, etc. Some old BIOSs setups (before 1995 ?) didn'tdeal with the serial ports. Make sure the ports you need are notdisabled and note how they are configured (like 3F8 IRQ 4). You mayneed to change the configuration to prevent conflicts. There could bea shortage of IRQs if the BIOS has reserved some IRQs that it didn'tneed to reserve.
For serial ports to be found, either the kernel must have beencompiled with serial support, or serial support must be provided by amodule. To check this look in the file /boot/config-2.6... and searchfor SERIAL. =m means it's a module and you may check to see themodules that are being used by typing: lsmod.
Below is an introduction to the topic, but for a more advancedtreatment of it see FIFOs.
Transmitting is sending bytes out of the serial port away from thecomputer (output). Once you understand transmitting, receiving(input) is easy to understand since it's similar. The firstexplanation given here will be grossly oversimplified. Then moredetail will be added in later explanations. When the computer wantsto send a byte out the serial port (to the external cable) the CPUsends the byte on the bus inside the computer to the I/O (InputOutput) 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 (aserial bit-stream) on the transmit pin of the serial cable connector.For what a bit (and byte) look like electrically see Voltage Waveshapes.
Here's a replay of the above in a little more detail (but still veryincomplete). Most of the work at the serial port is done by the UARTchip (or the like). To transmit a byte, the serial device driverprogram (running on the CPU) sends a byte to the serial port's I/Oaddress. This byte gets into a 1-byte 'transmit shift register' inthe serial port. From this shift register bits are taken from thebyte one-by-one and sent out bit-by-bit on the serial line. Then whenthe last bit has been sent and the shift register needs another byteto send, it could just ask the CPU to send it another byte. Thus wouldbe simple but it would likely introduce delays since the CPU might notbe able to get the byte immediately. After all, the CPU is usuallydoing other things besides just handling the serial port.
A way to eliminate such delays is to arrange things so that the CPUgets the byte before the shift register needs it and stores it in aserial port buffer (in hardware). Then when the shift register hassent out its byte and needs a new byte immediately, the serial porthardware just transfers the next byte from its own buffer to the shiftregister. No need to call the CPU to fetch a new byte.
The size of this serial port buffer was originally only one byte, buttoday it is usually 16 bytes (more in higher priced serial ports).Now there is still the problem of keeping this buffer sufficientlysupplied with bytes so that when the shift register needs a byte totransmit it will always find one there (unless there are no more bytesto send). This is done by contacting the CPU using an interrupt.
First we'll explain the case of the old fashioned one-byte buffer,since 16-byte buffers work similarly (but are more complex). When theshift register grabs the byte out of the buffer and the buffer needsanother byte, it sends an interrupt to the CPU by putting a voltage ona dedicated wire on the computer bus. Unless the CPU is doingsomething very important, the interrupt forces it to stop what it wasdoing and start running a program which will supply another byte tothe port's buffer. The purpose of this buffer is to keep an extrabyte (waiting to be sent) queued in hardware so that there will be nogaps in the transmission of bytes out the serial port cable.
Once the CPU gets the interrupt, it will know who sent the interruptsince there is a dedicated interrupt wire for each serial port (unlessinterrupts are shared). Then the CPU will start running the serialdevice driver which checks registers at I/0 addresses to find out whathas happened. It finds out that the serial's transmit buffer is emptyand waiting for another byte. So if there are more bytes to send, itsends the next byte to the serial port's I/0 address. This next byteshould arrive when the previous byte is still in the transmit shiftregister and is still being transmitted bit-by-bit.
In review, when a byte has been fully transmitted out the transmitwire of the serial port and the shift register is now empty thefollowing 3 things happen in rapid succession:
- The next byte is moved from the transmit buffer intothe transmit shift register
- The transmission of this new byte (bit-by-bit) begins
- Another interrupt is issued to tell the device driver to sendyet another byte to the now empty transmit buffer
Thus we say that the serial port is interrupt driven. Each time theserial port issues an interrupt, the CPU sends it another byte. Oncea byte has been sent to the transmit buffer by the CPU, then the CPUis free to pursue some other activities until it gets the nextinterrupt. The serial port transmits bits at a fixed rate which isselected by the user (or an application program). It's sometimescalled the baud rate. The serial port also adds extra bits to eachbyte (start, stop and perhaps parity bits) so there are often 10 bitssent per byte. At a rate (also called speed) of 19,200 bits persecond (bps), there are thus 1,920 bytes/sec (and also 1,920interrupts/sec).
Doing all this is a lot of work for the CPU. This is true for manyreasons. First, just sending one 8-bit byte at a time over a 32-bitdata 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 theinterrupt is received, the device driver only knows that somethingcaused an interrupt at the serial port but doesn't know that it'sbecause a character has been sent. The device driver has to makevarious checks to find out what happened. The same interrupt couldmean that a character was received, one of the control lines changedstate, etc.
A major improvement has been the enlargement of the buffer size of theserial port from 1-byte to 16-bytes. This means that when the CPUgets an interrupt it gives the serial port up to 16 new bytes totransmit. This is fewer interrupts to service but data must still betransferred one byte at a time over a wide bus. The 16-byte buffer isactually a FIFO (First In First Out) queue and is often called a FIFO.See FIFOs for details about the FIFO alongwith a repeat of some of the above info.
Receiving bytes by a serial port is similar to sending them onlyit's in the opposite direction. It's also interrupt driven. For theobsolete type of serial port with 1-byte buffers, when a byte is fullyreceived from the external cable it goes into the 1-byte receivebuffer. Then the port gives the CPU an interrupt to tell it to pickup that byte so that the serial port will have room for storing thenext byte which is currently being received. For newer serial portswith 16-byte buffers, this interrupt (to fetch the bytes) may be sentafter 14 bytes are in the receive buffer. The CPU then stops what itwas doing, runs the interrupt service routine, and picks up 14 to 16bytes from the port. For an interrupt sent when the 14th byte hasbeen received, there could be 16 bytes to get if 2 more bytes havearrived since the interrupt. But if 3 more bytes should arrive(instead of 2), then the 16-byte buffer will overrun. It also maypick up less than 14 bytes by setting it up that way or due totimeouts. See FIFOs for more details.
We've talked about small 16-byte serial port hardwarebuffers but there are also much larger buffers in main memory. Whenthe CPU takes some bytes out of the receive buffer of the hardware, itputs them into a much larger (say 8k-byte) receive buffer in mainmemory. Then a program that is getting bytes from the serial porttakes 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. Whenthe CPU needs to fetch some bytes to be transmitted it takes them outof a large (8k-byte) transmit buffer in main memory and puts them intothe small 16-byte transmit buffer in the hardware. And when a programwants to send bytes out the serial port, it writes them to this largetransmit buffer.
Both of these buffers are managed by the serial driver. But thedriver does more than just dealing with these buffers. It also doeslimited filtering (minor modifications) of data passing thru these buffersand listens for control certain characters. All this is configurableusing the Stty program.
You don't have to understand the basics to use the serial port Butunderstanding it may help to determine what is wrong if you run intoproblems. This section not only presents new topics but also repeatssome of what was said in the previous section How the Hardware Transfers Bytes but in greater detail.
Intro to Serial
The UART serial port (or just 'serial port for short' is an I/O (Input/Output) device.
An I/O device is just a way to get data into and out of a computer.There are many types of I/O devices such as the older serial ports andparallel ports, network cards, universal serial buses (USB), andfirewire etc.Most pre-2007 PC's have a serial port or two (on older PC's). Eachhas a 9-pin connector (sometimes 25-pin) on the back of the computer.Computer programs can send data (bytes) to the transmit pin (output)and receive bytes from the receive pin (input). The other pins arefor control purposes and ground.
The serial port is much more than just a connector. It converts thedata from parallel to serial and changes the electrical representationof the data. Inside the computer, data bits flow in parallel (usingmany wires at the same time). Serial flow is a stream of bits over asingle wire (such as on the transmit or receive pin of the serialconnector). For the serial port to create such a flow, it mustconvert data from parallel (inside the computer) to serial on thetransmit 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 UARTssee the sectionWhat Are UARTS? But you may want to finish this section first so that you willhopefully understand how the UART fits into the overall scheme ofthings.
Pins and Wires
Old PC's used 25 pin connectors but only about 9 pins wereactually used so later on most connectors were only 9-pin. Each ofthe 9 pins usually connects to a wire. Besides the two wires used fortransmitting and receiving data, another pin (wire) is signal ground.The voltage on any wire is measured with respect to this ground. Thusthe minimum number of wires to use for 2-way transmission of data is3. Except that it has been known to work with no signal ground wirebut with degraded performance and sometimes with errors.
There are still more wires which are for control purposes (signalling)only and not for sending bytes. All of these signals could have beenshared on a single wire, but instead, there is a separate dedicatedwire for every type of signal. Some (or all) of these control wiresare called 'modem control lines'. Modem control wires are either inthe asserted state (on) of +5 volts or in the negated state (off) of-5 volts. One of these wires is to signal the computer to stopsending bytes out the serial port cable. Conversely, another wiresignals the device attached to the serial port to stop sending bytesto the computer. If the attached device is a modem, other wires maytell the modem to hang up the telephone line or tell the computer thata connection has been made or that the telephone line is ringing(someone is attempting to call in). See sectionPinout and Signals for more details.
RS-232 (EIA-232, etc.)
The serial port (not the USB) is usually a RS-232-C, EIA-232-D, orEIA-232-E. These three are almost the same thing. The original RS(Recommended Standard) prefix officially became EIA (ElectronicsIndustries Association) and later EIA/TIA after EIA merged with TIA(Telecommunications Industries Association). The EIA-232 specprovides also for synchronous (sync) communication but the hardware tosupport sync is almost always missing on PC's. The RS designation iswas intended to become obsolete but is still widely used and will beused in this howto for RS-232. Other documents may use the fullEIA/TIA designation, or just EIA or TIA. For info on other(non-RS-232) serial ports see the section Other Serial Devices (not async RS-232)
Since the computer needs to communicate with each serial port, theoperating system must know that each serial port exists and where itis (its I/O address). It also needs to know which wire (IRQ number)the serial port must use to request service from the computer's CPU.It requests service by sending an interrupt voltage on this wire.Thus every serial port device must store in its non-volatile memoryboth its I/O address and its Interrupt ReQuest number: IRQ. See Interrupts. The PCI bus has its own system ofinterrupts. But since the PCI-aware BIOS sets up these PCI interruptsto map to IRQs, it seemingly behaves just as described above. Exceptthat sharing of PCI interrupts is allowed (2 or more devices may usethe same IRQ number).
I/O addresses are not the same as memory addresses. When an I/Oaddresses is put onto the computer's address bus, another wire isenergized. This both tells main memory to ignore the address andtells all devices which have I/O addresses (such as the serial port)to listen to the address sent on the bus to see if it matches thedevice's. If the address matches, then the I/O device reads the dataon the data bus.
The I/O address of a certain device (such as ttyS2) will actually be arange of addresses. The lower address in this range is the baseaddress. 'address' usually means just the 'base address'.
The serial ports are named ttyS0, ttyS1, etc. (and usuallycorrespond respectively to COM1, COM2, etc. in DOS/Windows). The /devdirectory has a special file for each port. Type 'ls /dev/ttyS*' tosee them. Just because there may be (for example) a ttyS3 file,doesn't necessarily mean that there exists a physical serial portthere.
Which one of these names (ttyS0, ttyS1, etc.) refers to whichphysical serial port is determined as follows. The serial driver(software) maintains a table showing which I/O address corresponds towhich ttyS. This mapping of names (such as ttyS1) to I/O addresses(and IRQ's) may be both set and viewed by the 'setserial' command.See What is Setserial. This does
not
set the I/O address and IRQ in the hardware itself (which isset by jumpers or by plug-and-play software). Thus which physical portcorresponds to say ttyS1 depends both on what the serial driver thinks(per setserial) and what is set in the hardware. If a mistake hasbeen made, the physical port may not correspond to any name (such asttyS2) and thus it can't be used. See Serial Port Devices /dev/ttyS2, etc. for more details.When the serial port receives a number of bytes (may be set to 1, 4,8, or 14) into its FIFO buffer, it signals the CPU to fetch them bysending an electrical signal known as an interrupt on a certain wirenormally used only by that port. Thus the FIFO waits until it hasreceived a number of bytes and then issues an interrupt.
However, this interrupt will also be sent if there is an unexpecteddelay while waiting for the next byte to arrive (known as a timeout).Thus if the bytes are being received slowly (such as from someonetyping on a terminal keyboard) there may be an interrupt issued forevery byte received. For some UART chips the rule is like this: If 4bytes in a row could have been received in an interval of time, butnone of these 4 show up, then the port gives up waiting for more bytesand issues an interrupt to fetch the bytes currently in the FIFO. Ofcourse, if the FIFO is empty, no interrupt will be issued.
Each interrupt conductor (inside the computer) has a number (IRQ) andthe serial port must know which conductor to use to signal on. Forexample, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). Alist of them and more will be found in 'man setserial' (search for'Configuring Serial Ports'). Interrupts are issued whenever theserial port needs to get the CPU's attention. It's important to dothis in a timely manner since the buffer inside the serial port canhold only 16 incoming bytes. If the CPU fails to remove such receivedbytes promptly, then there will not be any space left for any moreincoming bytes and the small buffer may overflow (overrun) resultingin a loss of data bytes.
There is no Flow Control to prevent this.
Interrupts are also issued when the serial port has just sent out allof its bytes from its small transmit FIFO buffer out the externalcable. It then has space for 16 more outgoing bytes. The interruptis to notify the CPU of that fact so that it may put more bytes in thesmall transmit buffer to be transmitted. Also, when a modem controlline changes state, an interrupt is issued.
The buffers mentioned above are all hardware buffers. The serial portalso has large buffers in main memory. This will be explained later
Interrupts convey a lot of information but only indirectly. Theinterrupt itself just tells a chip called the interrupt controllerthat a certain serial port needs attention. The interrupt controllerthen signals the CPU. The CPU then runs a special program to servicethe serial port. That program is called an interrupt service routine(part of the serial driver software). It tries to find out what hashappened at the serial port and then deals with the problem such atransferring bytes from (or to) the serial port's hardware buffer.This program can easily find out what has happened since the serialport has registers at IO addresses known to the serial driversoftware. These registers contain status information about the serialport. The software reads these registers and by inspecting thecontents, finds out what has happened and takes appropriate action.
Data (bytes representing letters, pictures, etc.) flows into andout 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 thanthe specified speed. Waits (or idle time) result in a lower averagespeed. These waits may include long waits of perhaps a second due toFlow Control. At the other extremethere may be very short waits (idle time) of several micro-secondsbetween bytes. If the device on the serial port (such as a modem)can't accept the full serial port speed, then the average speed mustbe reduced.
Flow control means the ability to slow down the flow of bytes in awire. For serial ports this means the ability to stop and thenrestart the flow without any loss of bytes. Flow control is neededfor modems and other hardware to allow a jump in instantaneous flow rates.
Example of Flow Control
For example, consider the case where you connect a 33.6k externalmodem via a short cable to your serial port. The modem sends andreceives bytes over the phone line at 33.6k bits per second (bps).Assume it's not doing any data compression or error correction. Youhave set the serial port speed to 115,200 bits/sec (bps), and you aresending data from your computer to the phone line. Then the flow fromthe your computer to your modem over the short cable is at 115.2k bps.However the flow from your modem out the phone line is only 33.6k bps.Since a faster flow (115.2k) is going into your modem than is comingout of it, the modem is storing the excess flow (115.2k -33.6k = 81.6kbps) in one of its buffers. This buffer would soon overrun (run outof free storage space) unless the high 115.2k flow is stopped.
But now flow control comes to the rescue. When the modem's buffer isalmost full, the modem sends a stop signal to the serial port. Theserial port passes on the stop signal on to the device driver and the115.2k bps flow is halted. Then the modem continues to send out dataat 33.6k bps drawing on the data it previous accumulated in itsbuffer. Since nothing is coming into this buffer, the number of bytesin 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 flowfrom the computer to the modem resumes. In effect, flow controlcreates an average flow rate in the short cable (in this case 33.6k)which is significantly less than the 'on' flow rate of 115.2k bps.This is 'start-stop' flow control.
In the above simple example it was assumed that the modem did no datacompression. This could happen when the modem is sending a filewhich is already compressed and can't be compressed further. Nowlet's consider the opposite extreme where the modem is compressing thedata with a high compression ratio. In such a case the modem mightneed an input flow rate of say 115.2k bps to provide an output (to thephone line) of 33.6k bps (compressed data). This compression ratio is3.43 (115.2/33.6). In this case the modem is able to compress the115.2 bps PC-to-modem flow and send the same data (in compressed form)out the phone line at 33.6bps. There's no need for flow control hereso long as the compression ratio remains higher than 3.43. But thecompression ratio varies from second to second and if it should dropbelow 3.43, flow control will be needed
In the above example, the modem was an external modem. But the samesituation exists (as of early 2003) for most internal modems. There isstill a speed limit on the PC-to-modem speed even though this flowdoesn't take place over an external cable. This makes the internalmodems compatible with the external modems.
In the above example of flow control, the flow was from the computer toa modem. But there is also flow control which is used for theopposite direction of flow: from a modem (or other device) to acomputer. Each direction of flow involves 3 buffers: 1. in the modem2. in the UART chip (called FIFOs) and 3. in main memory managed by theserial driver. Flow control protects all buffers (except the FIFOs)from overflowing.
Under Linux, the small UART FIFO buffers are not protected by flowcontrol but instead rely on a fast response to the interrupts theyissue. Some UART chips can be set to do hardware flow control toprotect their FIFOs but Linux (as of early 2003) doesn't seem tosupport it. FIFO stand for 'First In, First Out' which is the way ithandles bytes in a queue. All the 3 buffers use the FIFO rule butonly the one in the UART is named 'FIFO'. This is the essence of flowcontrol but there are still some more details.
Symptoms of No Flow Control
Understanding flow-control theory can be of practical use. Thesymptom of no flow control is that chunks of data missing from filessent without the benefit of flow control. When overflow happens,often hundreds or even thousands of bytes get lost, and all incontiguous chunks.
Hardware vs. Software Flow Control
If feasible, it's best to use 'hardware' flow control that uses twodedicated 'modem control' wires to send the 'stop' and 'start'signals. Hardware flow control at the serial port works like this:The two pins, RTS (Request to send) and CTS (Clear to send) are used.When the computer is ready to receive data it asserts RTS by putting apositive voltage on the RTS pin (meaning 'Request To Send to me').When the computer is not able to receive any more bytes, it negatesRTS by putting a negative voltage on the pin saying: 'stop sending tome'. The RTS pin is connected by the serial cable to another pin onthe modem, printer, terminal, etc. This other pin's only function isto receive this signal.
For the case of a modem, this 'other' pin will be the modem's RTS pin.But for a printer, another PC, or a non-modem device, it's usually aCTS pin so a 'crossover' or 'null modem' cable is required. Thiscable connects the CTS pin at one end with the RTS pin at the otherend (two wires since each end of the cable has a CTS pin). For amodem, a straight-thru cable is used.
For the opposite direction of flow a similar scheme is used. For amodem, the CTS pin is used to send the flow control signal to the CTSpin on the PC. For a non-modem, the RTS pin sends the signal. Thusmodems and non-modems have the roles of their RTS and CTS pinsinterchanged. Some non-modems such as dumb terminals may use otherpins for flow control such as the DTR pin instead of RTS.
Software flow control uses the main receive and transmit data wires tosend the start and stop signals. It uses the ASCII control charactersDC1 (start) and DC3 (stop) for this purpose. They are just insertedinto the regular stream of data. Software flow control is not onlyslower in reacting but also does not allow the sending of binary dataunless special precautions are taken. Since binary data will likelycontain DC1 and DC3 characters, special means must be taken todistinguish between a DC3 that means a flow control stop and a DC3that is part of the binary code. Likewise for DC1.
It's been mentioned that there are 3 buffers for each direction offlow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pairof larger buffers inside a device connected to the serial port (suchas a modem), and a pair of buffers (say 8k) in main memory. When anapplication program sends bytes to the serial port they first getstashed in the transmit serial port buffer in main memory. The othermember of this pair consists of a receive buffer for the oppositedirection of byte-flow. Here's an example diagram for the case ofbrowsing the Internet with a browser. Transmit data flow is left toright while receive flow is right to left. There is a separate bufferfor each direction of flow.
For the transmit case, the serial device driver takes out say 15 bytesfrom this transmit buffer (in main memory), one byte at a time andputs them into the 16-byte transmit buffer in the serial UART fortransmission. Once in that transmit buffer, there is no way to stopthem from being transmitted. They are then transmitted to themodem or (other device connected to the serial port) which also has afair sized (say 1k) buffer. When the device driver (on orders fromflow control sent from the modem) stops the flow of outgoing bytesfrom the computer, what it actually stops is the flow of outgoingbytes from the large transmit buffer in main memory. Even after thishas happened and the flow to the modem has stopped, an applicationprogram may keep sending bytes to the 8k transmit buffer until itbecomes full. At the same time, the bytes stored in the FIFO continueto be sent out. Bytes stored in the modem will continue to be sentout the phone line unless the modem has gotten a modem-to-modem flowcontrol stop from the modem at the other end of the phone line.
When the memory buffer gets full, the application program can't sendany more bytes to it (a 'write' statement in a C-program blocks) andthe application program temporarily stops running and waits until somebuffer space becomes available. Thus a flow control 'stop' isultimately able to stop the program that is sending the bytes. Eventhough this program stops, the computer does not necessarily stopcomputing since it may switch to running other processes while it'swaiting at a flow control stop.
The above was a little oversimplified in three ways. First, some UARTscan do automatic hardware flow control which can stop the transmissionout of the FIFO buffers if needed (not yet supported by Linux).Second, while an application process is waiting to write to thetransmit buffer, it could possibly perform other tasks. Third, theserial driver (located between the memory buffer and the FIFO) hasit's own small buffer (in main memory) used to process characters.
For many situations, there is a transmit path involving severallinks, each with its own flow control. For example, I type at atext-terminal connected to a PC and the PC (under my control) dialsout to another computer using a modem. Today, a 'text-terminal' islikely to be just another PC emulating a text-terminal. The main(server) PC, in addition to serving my text-terminal, could also havesomeone else sitting at it doing something else. Note that callingthis PC a 'server' is not technically correct but it does serve theterminal.
The text-terminal uses a command-line interface with no graphicaldisplay. Every letter I type at the text-terminal goes over theserial cable to my main PC and then over the phone line to thecomputer that I've dialed out to. To dial out, I've used thecommunication software: 'minicom' which runs on my PC.
This sounds like a simple data path. I hit a key and the byte thatkey generates flows over just two cables (besides the keyboard cable):1. the cable from my text-terminal to my PC and 2. the telephone linecable to some other computer. Of course, the telephone cable isactually a number of telephone system cables and includes switchesand electronics so that a single physical cable can transmit manyphone calls. But I can think of it like one cable (or one link).
Now, let's count the number and type of electronic devices eachkeystroke-byte has to pass thru. The terminal-to-PC cable has aserial port at each end. The telephone cable has both a serial portand a modem at each end. This adds up to 4 serial ports and 2 modems.Since each serial port has 2 buffers, and each modem one buffer, thatadds up to 10 buffers. And that's just for one direction of flow.Each byte also must pass thru the minicom software as well.
While there's just 2 cables in the above scenario, if external modemswere used there would be an additional cable between each modem andit's serial port. This makes 4 cables in all. Even with internalmodems it's like there is a 'virtual cable' between the modem and itsserial port. On all these 4 links (or cables), flow control takesplace.
Now lets consider an example of the operation of flow control.Consider the flow of bytes from the remote computer at the other endof the phone line to the screen on the text-terminal that I'm sittingat. A real text-terminal has a limit to the speed at which bytes canbe displayed on its screen and issues a flow control 'stop' from timeto time to slow down the flow. This 'stop' propagates in a directionopposite to the flow of bytes it controls. What happens when such a'stop' is issued? Let's consider a case where the 'stop' waits longenough before canceling it with a 'start', so that it gets thru tothe remote computer at the other end of the phone line. When it getsthere it will stop the program at the remote computer which is sendingout the bytes.
Let's trace out the flow of this 'stop' (which may be 'hardware' onsome links and 'software' on others). First, suppose I'm 'capturing'a long file from the remote computer which is being sentsimultaneously to both my text-terminal and to a file on my hard-disk.The bytes are coming in faster than the terminal can handle them so itsends a 'stop' out its serial port to a serial port on my PC. Thedevice driver detects it and stops sending bytes from the 8k PC serialbuffer (in main memory) to the terminal. But minicom still keepssending 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 thisalso causes minicom to stop reading from the 8k receive buffer on the2nd serial port connected to the modem. Flow from the modem continuesuntil this 8k buffer too fills up and sends a different 'stop' to themodem. Now the modem's buffer ceases to send to the serial port andalso fills up. The modem (assuming error correction is enabled) sendsa 'stop signal' to the other modem at the remote computer. This modemstops sending bytes out of its buffer and when its buffer gets full,another stop signal is sent to the serial port of the remote computer.At the remote computer, the 8-k (or whatever) buffer fills up and theprogram at the remote computer can't write to it anymore and thustemporarily halts.
Thus a stop signal from a text terminal has halted a program on aremote computer computer. What a long sequence of events! Notethat the stop signal passed thru 4 serial ports, 2 modems, and oneapplication program (minicom). Each serial port has 2 buffers (in onedirection of flow): the 8k one and the hardware 16-byte one. Theapplication program may have a buffer in its C_code. This adds up to11 different buffers the data is passing thru. Note that the smallserial hardware buffers do not participate directly in flow control.Also note that the two buffers associated with the text-terminal'sserial port are going to be dumping their contents to the screenduring this flow control halt. This leaves 9 other buffers that maybe getting filled up during the flow control halt.
If the terminal speed limitation is the bottleneck in the flow fromthe remote computer to the terminal, then its flow control 'stop' isactually stopping the program that is sending from the remote computeras explained above. But you may ask: How can a 'stop' last so longthat 9 buffers (some of them large) all get filled up? It seldomhappens, but it can actually happen this way if all the buffers werenear their upper limits when the terminal sent out the 'stop'.
But if you were to run a simulation on this you would discover that it'susually more complicated than this. At an instant of time some linksare flowing and others are stopped (due to flow control). A 'stop'from the terminal seldom propagates back to the remote computer neatly asdescribed above. It may take a few 'stops' from the terminal toresult in one 'stop' at the remote computer, etc. To understand whatis going on you really need to observe a simulation which can be donefor a simple case with coins on a table. Use only a few buffers andset the upper level for each buffer at only a few coins.
Does one really need to understand all this? Well, understanding thisexplained to me why capturing text from a remote computer was loosingtext. The situation was exactly the above example but modem-to-modemflow control was disabled. Chunks of captured text that were supposedto also get to my hard-disk never got there because of an overflow atmy modem buffer due to flow control 'stops' from the terminal. Eventhough the remote computer had a flow path to the hard-disk withoutbottlenecks, the same flow also went to a terminal which issued flowcontrol 'stops' with disastrous results for the branch of the flowgoing to a file on the hard-disk. The flow to the hard-disk passedthru my modem and since the overflow happened at the modem, bytesintended for the hard-disk were lost.
The device driver for the serial port is the software thatoperates the serial port. It is now provided as a serial module.From kernel 2.2 on, this module will normally get loaded automaticallyif it's needed. In earlier kernels, you had to have
kerneld
running in order to do auto-load modules on demand. Otherwise theserial module needed to be explicitly listed in /etc/modules. Beforemodules became popular with Linux, the serial driver was usually builtinto the kernel (and sometimes still is). If it's built-in don't letthe serial module load or else you will have two serial driversrunning at the same time. With 2 drivers there are all sorts oferrors including a possible 'I/O error' when attempting to open aserial port. Use 'lsmod' to see if the module is loaded.When the serial module is loaded it displays a message on the screenabout the existing serial ports (often showing a wrong IRQ). But oncethe module is used by
setserial
to tell the device driver the(hopefully) correct IRQ then you should see a second display similarto the first but with the correct IRQ, etc. SeeSerial ModuleSee What is Setserial for more info onsetserial
. The serial port istoday (2011) sort of obsolete on PCs (and often called a 'legacy'device) but it is still in use on some older computers and is used inimbedded systems, for communication with routers and point-of-saleequipment, etc. The serial port is slowand after about 2005 most new PC's no longer had them. Most laptopsand Macs discontinued them even earlier. During the era when some newPC's came with serial ports and others didn't, the PC's that didn'thave serial ports were euphemistically called 'legacy-free'. However,while PC's today no longer have serial ports, some do have them builtinto a 'legacy' modem (which plugs into a telephone line). Such a serial portonly works with the modem and can't be used for any other device. Thereason they have such a 'built in' serial port is that analog modemsare designed to only work thru a serial port.
The physical serial port on the back of a PC (including the chip itsconnected to inside the PC), must pass data between the computer andan external cable. Thus it has two interfaces: the serial-port-tocable and the serial-port-to-computer-bus. Both of these interfacesare slow. First we'll consider the interface via external cable tothe outside world.
The conventional RS-232 serial port is inherently low speed andis severely limited in distance. Ads often read 'high speed' but itcan only work at 'high speed' over very short distances such as to amodem located right next to the computer. Compared to a network card,even this 'high speed' is actually low speed. All of the RS-232serial cable wires use a common ground return wire so thattwisted-pair technology (needed for high speeds) can't be used withoutadditional hardware. More modern interfaces for serial ports existbut they are not standard on PC's like the RS-232 is. See Successors to RS-232. Some multiport serialcards support them.
It is somewhat tragic that the RS-232 standard from 1969 did not usetwisted pair technology which could operate about a hundred timesfaster. Twisted pairs have been used in telephone cables since thelate 1800's. In 1888 (over 120 years ago) the 'Cable Conference'reported its support of twisted-pair (for telephone systems) andpointed out its advantages. But over 80 years after this approval bythe 'Cable Conference', RS-232 failed to utilize it. Since RS-232was originally designed for connecting a terminal to a low speed modemlocated nearby, the need for high speed and longer distancetransmission was apparently not recognized. The result was that sincethe serial port couldn't handle high speeds, new types of serialinterfaces were devised that could: Ethernet, USB, Firewire, etc.The final outcome was the demise of the serial port which due to it'sancient technology became obsolete for high speed uses.
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 isa waste of PCI bus bandwidth. Not so for the LPC bus which has only a4-bit wide bus and thus provides an efficient interface. The ISA busis usually 16-bits wide and the efficiency is intermediate as comparedto efficient LPC and inefficient PCI.
Multiport serial cards install in slots in a PC on the ISA or PCIbus. They are also called '... adapters' or '... boards'. Each suchcard provides you with many serial ports. Today they are commonlyused for the control of external devices (including automation forboth industry and the home). They can connect to computer servers forthe purpose of monitoring/controlling the server from a remotelocation. They were once mainly used for connecting up many dumbterminals and/or modems to serial ports. Today, use of dumb terminalshas declined, and several modems (or digital modems) can now be builtinto an internal card. So multiport serial cards are not assignificant as they once were.
Each multiport card has a number of external connecters (DB-25 orRJ45) so that one may connect up a number of devices (modems,terminals, etc.). Each such physical device would then be connectedto its own serial port. Since the space on the external-facing partof the card is limited there is often not enough room for all theserial port connectors. To solve this problem, the connectors may beon the ends of cables which come out (externally) from the card(octopus cable). Or they may be on an external box (possibly rackmountable) which is connected by a cable to a multiport card.
Dumb multiport cards are not too much different than ordinary serialports. They are interrupt driven and the CPU of the computer doesmost all the work servicing them. They usually have a system ofsharing a single interrupt for all the ports. This doesn't decreasethe load on the CPU since the single interrupt will be sent to the CPUeach time any one port needs servicing. Such devices usually requirespecial drivers that you must either compile into the kernel or use asa module.
Smart boards may use ordinary UARTs but handle most interrupts fromthe UARTs internally within the board. This frees the CPU from theburden of handling all these interrupts. The board may save up bytesin its large internal FIFOs and transfer perhaps 1k bytes at a time tothe serial buffer in main memory. It may use the full bus width of 32bits for making data transfers to main memory (instead of transferringonly 8-bit bytes like dumb serial cards do). Not all 'smart' boardsare equally efficient. Many boards today are Plug-and-Play.
Introduction
For a multiport board to work, a special driver for it must be used.This driver may either be built into the kernel source code orsupplied as a module. For the 2.6 kernels on, most drivers aresupplied both ways: as a module or it can be built into the kernel.Take care not to both build support into the kernel and force themodule to load for a certain serial card. For older kernels, therewere often no modules for dumb serial multiport boards so support wasbuilt into the kernel.
Build (compile) support into the kernel?
A pre-compiled kernel may not have a driver for your multiport cardbuilt in. So then you must either compile the kernel yourself andbuild in the right driver, or insure that the module is available andloads. Of course if the driver doesn't come both ways (as acompile-time option and as a module) you have no such choice.
If you want to see what has already been compiled into an existingworking kernel, go the the /boot directory (or wherever the compiledkernel(s) reside) and look in the config... file.
In the 2.6 kernel there are many options to select from in theconfiguration file for compiling. Adding support for certainmultiport cards is listed under the headings 'Character devices' or'Serial drivers'. Old multiport cards had support as part of theserial driver and are found under 'Serial Drivers'. More advancedcards have their own driver found under 'Character devices'
For compiling kernel 2.6 you should select 'CONFIG_SERIAL_8250_EXTENDED'. (orjust 'CONFIG_SERIAL_EXTENDED' for 2.4). Then you will be asked morequestions about your serial ports with more options to select. If theresulting configuration is not quite right, then you may need to editthe kernel configuration file manually.
Using module support
A pre-compiled kernel may come with a pre-compiled module for theboard so that you don't need to recompile the kernel. This modulemust be loaded in order to use it and if there is installationsoftware for the driver, it should also set up Linux to load themodule (probably at boottime). Some of the modules to load atboottime are listed in /etc/modules or /etc/modules.confAlso certain parameters may need to be passedto the driver via entries in these files or via lilo's 'append'command or via grub's 'kernel' command. For kernel 2.6 (and 2.4) the(unloaded) modules should be found in
/lib/modules/.../kernel/drivers/char.
Getting info on multiport boards
The board's manufacturer should have info on their website.Unfortunately, info for old boards is sometimes not there but might befound somewhere else on the Internet (including discussion groups).You might also want to look at the kernel documentation in/usr/share/doc/linux-doc... (formerly kernel-doc in pre 2.6 kernels).For configuring the kernel or modules prior to compiling see:Configure.help and search for 'serial', etc. There are also kerneldocumentation files for certain boards including computone, hayes-esp,moxa-smartio, riscom8, specialix, stallion, and sx (specialix).
The serial ports your multiport board uses depends on what kind ofboard you have. Some have their own device names like /dev/ttyE27(Stallion) or /dev/ttyD2 (Digiboard), etc. For various other brands,see see devices.txt in the kernel documentation. Some use thestandard names like /dev/ttyS14 and may be found in configurationfiles that used as arguments to
setserial
. Such files may beincluded in a setserial or serial package. An installation script may do this for you. But if not, here'ssome examples of how to create a device name in the /dev directory.If you use udev, MAKEDEV will not create devices in the devicedirectory since this directory is only in memory and will be lost whenyou turn off the computer. Instead it will create the device indev/.static/dev directory.
For the names and numbers of other types of serial ports otherthan ttyS.. See devices.txt in the kernel documentation. Either usethe
mknod
command, or the MAKEDEV
script. Typing 'manmakedev' may show instructions on using it.Using the
MAKEDEV
script, you would first become the superuser(root) and type (for example) either:Or if the above doesn't work cd to /dev before giving the abovecommand>. Substitute whatever your port is for ttyS17.
Using
mknod
is a more complicated option since you need to knowthe major and minor device numbers. These numbers are in the'devices' file in the kernel documentation. For ttyS serial ports theminor number is: 64 + port number (=81 for the example below). Notethe 'major' number is always 4 for ttyS devices (and 5 for theobsolete cua devices). So, if you wanted to create a device forttyS17
using mknod
, you would type: In olden days, PCs came with a serial card installed. Later on,the serial function was put on the hard-drive interface card. In the1990s and early 2000s one or two serial ports were usually built intothe motherboard (on-board). Most of them (as of 2002) use a 16550 butsome use 16650 (32-byte FIFOs). But one may still buy the individualPC serial cards if they need more serial ports. They can be used toconnect external serial devices (modems, serial mice, etc...). Only atiny percentage of retail computer stores carry such cards. But onecan purchase them on the Internet. Before getting one for the PCIbus, make sure Linux supports it.
Here's a list of a few popular brands:
- Byte Runner (may order directly, shows prices) http://www.byterunner.com
- SIIG http://www.siig.com/products/io/
- Dolphin http://www.dolphinfast.com/sersol.html
Note: due to address conflicts, you may not be able to use /dev/ttyS3with a IBM8514 video card (and some others) simultaneously. See Avoiding IO Address Conflicts with Certain Video Boards
They are also called 'serial adapters'. Each port has its ownaddress. They often have a special method of sharing interrupts whichrequires that you compile support for them into the kernel.
* => The file that ran setserial in Debian shows some details ofconfiguring
# => See note below for this board
# => See note below for this board
- 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 Boca mini-howto revised in 2001) * #
- Boca IOAT66 or? ATIO66 (6 ports, Linux doesn't support its IRQsharing ?? Uses odd-ball 10-cond RJ45-like connectors)
- Boca 2by4 (4 serial ports, 2 parallel ports)
- Byte Runner http://www.byterunner.com
- Computone ValuePort V4-ISA (AST FourPort compatible) *
- Digi PC/8 (8 ports) #
- Dolphin http://www.dolphinfast.com/sersol/
- Globetek http://www.globetek.com/
- GTEK BBS-550 (8 ports; See the mini-howto)
- Hayes ESP (after kernel 2.1.15)
- HUB-6 See Bell Technologies.
- Longshine LCS-8880, Longshine LCS-8880+ (AST FourPort compatible) *
- Moxa C104, Moxa C104+ (AST FourPort compatible) *
- NI-SERIAL by National Instruments
- NetBus (2 ports)http://www.netbus.com using patch from http://lists.insecure.org/linux-kernel/2001/Feb/2809.htmlDiscontinued.
- PC-COMM (4 ports)
- Sealevel SystemsCOMM-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) *
- VScom (uses same driver as ByteRunner)
In general, Linux will support any serial board which uses a 8250,16450, 16550, 16550A, 16650, 16650V2, 16654, 16750, 16850, 16950, and16954. UART. See the latest man page for 'setserial' for a morecomplete list.
Notes:
AST Fourport: You might need to specify
skip_test
in rc.serial
.BB-1004 and BB-1008 do not support DCD and RI lines, and thus are notusable for dialin modems. They will work fine for all other purposes.
Digi PC/8 Interrupt Status Register is at 0x140.
SIIG IO1812 manual for the listing for COM5-COM8 iswrong. They should be COM5=0x250, COM6=0x258, COM7=0x260, andCOM8=0x268.
Make sure that a Linux-compatible driver is available and read theinformation that comes with it. These boards use special devices (inthe /dev directory), and not the standard ttyS ones. This informationvaries depending on your hardware. If you have updated info whichshould be shown here please email it to me.
Names of Linux driver modules are *.ko (*.o prior to kernel 2.6) butthese may not work for all models shown. See Modules (mostly for smart boards) The needed module may havebeen supplied with your Linux distribution. Also, parameters (such asthe io and irq often need to be given to the module so you need tofind instructions on this (possibly in the source code tree).
There are many different brands, each of which often offers manydifferent cards. No attempt is currently being made to list all thecards here (and many listed are obsolete and have bad internet linksto them which need to be fixed). But all major brands and websitesshould be shown here so it something is missing let me know. Go tothe webpage shown for more information. These websites often alsohave info (ads) on related hardware such as modem pools, remote accessservers (RASs), and terminal servers. Where there is no webpage, thecards are likely obsolete. If you would like to put together a betterlist, let me know.
- Chase Research, now Perle Systems Ltd (UK based, ISA/PCI cards)
webpage:http://www.perle.com
driver status: included in kernel 2.4+ for PCI only; otherwise supported byPerle
driver and manual location: http://www.perle.com/downloads/multi_port.shtml - Comtrol RocketPort (36MHz ASIC; 4, 8, 16, 32, up to 128 ports)
webpage:http://www.comtrol.com
driver status: supported by Comtrol. rocket.o
driver location:ftp://tsx-11.mit.edu/pub/linux/packages/comtrol
- Computone IntelliPort II (ISA, PCI and EISA busses up to 64ports)
webpage: http://www.computone.com
driver location: old patch at http://www.wittsend.com/computone/linux-2.2.10-ctone.patch.gz
mailing list: mailto:[email protected] with'subscribe linux-computone' in body
note: Old ATvantage and Intelliport cards are not supported by Computone - Connecttech
website:http://www.connecttech.com/
driver location: ftp://ftp.connecttech.com/pub/linux/ - Cyclades
Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),
Cyclom-Z (MIPS R3000; 8 - 64 ports)
website:http://www.cyclades.com/products/svrbas/zseries.php
driver status: supported by Cyclades
driver location:ftp://ftp.cyclades.com/pub/cyclades
and included in Linuxkernel since version 1.1.75: cyclades.o - Decision PCCOM (2-8 ports; ISA and PCI; aka PC COM)
ISA:
contact:mailto:[email protected]
driver location: (dead link)ftp://ftp.cendio.se/pub/pccom8
PCI:
drivers: http://www.decision.com.tw
driver status: Support in serial driver 5.03. For an earlier driver,there exists a patch for kernel 2.2.16 at http://www.qualica.com/serial/ and for kernels 2.2.14-2.2.17athttp://www.pccompci.com/mains/installing_pci_linux1.html - 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)
website:http://www.dgii.com
driver status: supported by Digi
driver location:ftp://ftp.dgii.com/drivers/linux
andincluded in Linux kernel since version 2.0. epca.o - Digi COM/Xi (10MHz 80188; 4 or 8 ports)
contact: Simon Park,[email protected]
driver status: ?
note: Simon is often away from email for months at a time due tohis job. Mark Hatle, mailto:[email protected] graciously volunteered to make the driver available if you needit. Mark is not maintaining or supporting the driver. - Equinox SuperSerial Technology (30MHz ASIC; 2 - 128 ports)
website:http://www.equinox.com
driver status: supported by Equinox
driver location:ftp://ftp.equinox.com/library/sst
- Globetek
website: http://www.globetek.com/products.shtml
driver location: http://www.globetek.com/media/files/linux.tar.gz - 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)
website:http://www.gtek.com
driver status: supported by GTEK
driver location:ftp://ftp.gtek.com/pub
- Hayes ESP (COM-bic; 1 - 8 ports)
website:http://www.nyx.net/~arobinso
driver status: Supported by Linux kernel (1998) since v. 2.1.15.esp.o. Setserial 2.15+ supports. Also supported by author
driver location:http://www.nyx.net/~arobinso
- Intelligent Serial Interface by Multi-Tech Systems
PCI: 4 or 8 port. ISA 8 port. DTE speed 460.8k. Discontinued
webpage: http://www.multitech.com/en_US/products/ - Maxpeed SS (Toshiba; 4, 8 and 16 ports)
website:http://www.maxpeed.com
driver status: supported by Maxpeed
driver location:ftp://maxpeed.com/pub/ss
- Microgate SyncLink ISA and PCI high speed multiprotocolserial. Intended for synchronous HDLC.
website: http://ww/microgate.com/products/sllinux/hdlcapi.htm
driver status: supported by Microgate: synclink.o - Moxa C218 (12MHz 80286; 8 ports),
Moxa C320 (40MHz TMS320; 8 - 32 ports)
website:http://www.moxa.com
driver status: supported by Moxa
driver locations:'>http://www.moxa.com/support/download/download.php3>
ftp://ftp.moxa.com/drivers/linux
(also from Taiwan at www.moxa.com.tw/...) where ... is the same asabove) - SDL RISCom/8 (Cirrus Logic CD180; 8 ports)
website: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)
webpage: Old link is broken. Out of business?
driver status: Was 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 withCirrus 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:[email protected]
orhttp://www.stallion.com
driver status: supported by Stallion
driver location:ftp://ftp.stallion.com/drivers/ata5/Linux
andincluded in linux kernel since 1.3.27. Moved: it's now at ?. - System Basewebsite: http://www.sysbas.com/
A review of Comtrol, Cyclades, Digi, and Stallion products wasprinted in the June 1995 issue of the Linux Journal. The articleis available at Review: Intelligent Multiport Serial Boards Besides thelisting of various brands of multiports found above in this HOWTOthere is Gary's Encyclopedia - Serial Cards. It's not as complete, but may havesome different links.
The following brands that formerly made boards for with Linuxsupport don't mention any Linux support as of 1 Jan. 2000. Let meknow if this changes.
A computer that has many serial ports (with many serial cablesconnected to it) is often called a server. Of course, most serversserve other functions besides just serving serial ports, and many donot serve serial ports at all (although they likely have a serial porton them). For example, a 'serial server' may have serial cables,each of which runs to a different (non-serial) server. The serialserver (perhaps called a 'console server') controls, via a console,all the other servers. The console may be physically located remotefrom the serial server, communicating with the server over a network.
There are two basic types of serial servers. One type is just anordinary computer (perhaps rack mounted) that uses multiport cards ona PCI bus (or the like). The other type is a proprietary server thatis a dedicated computer that serves a special purpose. Servers ofboth types may be called: serial servers, console servers, printservers, or terminal servers. They are not the same.
The terminal server was originally designed to provide many serialports, each connected to a dumb text-terminal. Today, a terminalserver often connects to graphic terminals over a fast network anddoesn't use serial ports since they are too slow. One network cabletakes the place of many serial cables and each graphic terminal usesfar more bandwidth than the text-terminals did. However, graphicterminals may be run in text mode to reduce the bandwidth required. Amore detailed discussion of terminal servers (serial port) is inText-Terminal-HOWTO. For networked terminal servers (not serial port)see Linux Terminal Server Project (LTSP)
(To-do: Discuss other types of serial servers, but the author knowslittle about them.)
In most cases configuring is automatically taken care of and youhave nothing to do. Linux should detect your serial ports, and loaddriver modules if needed. Then the driver should insure that IRQ andaddress space resources have been allocated. Finally, the applicationprogram which uses the serial port should set the port speed, etc.
For any of this to work, serial support must either be compiled intothe kernel (by you or by whoever compiled your kernel) or provided bymodules that are loaded into the kernel when you start to use theserial port. In most cases, if it hasn't been compiled into thekernel, a module(s) will do the job and Linux should hopefullyautomatically find and load the correct modules.
But if you have more than 4 (or perhaps 2) serial ports, then the kernelmust be told this as it doesn't seem to do it automatically. See Number of Serial Ports Supported, Kernel Configuration and. Serial Modules.
Once the proper support is in your kernel and modules, then The restof the configuring of the serial port should happen automatically.This is done by the serial driver software often with help from yourapplication software. But sometimes it doesn't get configured rightand then you need to do it yourself. Or perhaps you need to configureit in a special way, etc. This HOWTO only covers configuration of theserial port itself and not the configuring of any devices attached tothe port (such as a modem or printer).
Resource allocation (locating the hardware or low-level configuring)is assigning each port an IO address, IRQ, and name (such as ttyS2).This IO-IRQ pair must be set in both the hardware and become known to the serial driver. We might just call this 'io-irq'configuring for short. The 'setserial' program is sometimes used totell the driver io-irq info that an administrator has put in aconfiguration file or given as parameters to the setserial command.PnP methods, jumpers, etc, are used to set the IO and IRQ in thehardware. Details will be supplied later. If you need to configurebut don't understand certain details it's easy to get into trouble.See Locating the Serial Port: IO address IRQsWhat is Setserial
The second part (high-level configuring) is assigning it a speed (suchas 115.2k bits/sec), selecting flow control, etc. This is ofteninitiated by communication programs such as wvdial, PPP, minicom,picocom or by getty (which you may run on the port so that others maylog into your computer from an old-fashioned dumb terminal connectedto the port). However you will need to tell these programs what speedyou want, etc. by using a menu or a configuration file. Thishigh-level configuring may also be done manually with the
stty
program. stty
is also useful to view the current status ifyou're having problems. See the section SttyIf you need to find a serial port it often helps if you know whatbus it's on. If the serial port is on a card, you may know what busthe card inserts into such as a PCI slot. But if the serial port isbuilt into the motherboard it may not be clear what bus it's on. Forold motherboards that have ISA bus slots, it's likely on the ISA busand may not even be Plug-and-Play. But even if all your slots arePCI, the serial port is likely to be on either an 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 hasno standard Plug-and-Play method for low-level configuring devices onit. But according to the specs, the BIOS is supposed to do suchconfiguring (using ACPI ??). To see if you have a LPC bus, type'lspci' and look for a LPC bridge or the like.
For a serial port to work properly it first must be given both anIO address and an IRQ. For old hardware (of mid 1990s), jumpers on acard or a saved BIOS setting does it. For newer hardware the BIOSor Linux must set them at boot-time, and the new hardware doesn'tremember how it was set once it's powered down. Enabling the hardware(by using software) gives it both an IRQ and an IO address. Withoutan IO address, it can't be used. Without an IRQ it will need to useinefficient polling methods for which one must set the IRQ to 0 in theserial driver. Using digital signals sent to the hardware by the BIOSor Linux, it all should get configured automatically (provided theBIOS has not been previously set up to disable it). So you onlyneed to read this if you're having problems or if you want tounderstand how it works.
The driver must of course know both the IO address and IRQ so that itcan talk to the serial port chip. Modern serial port drivers (kernel2.4) try to determine this by PnP methods so one doesn't normally needto tell the driver (by using 'setserial'). A driver may also set anIO address or IRQ in the hardware. But unfortunately, there is somePCI serial port hardware that the driver doesn't recognize so youmight need to enable the port yourself. See PCI: Enabling a disabled port
For the old ISA bus, the driver also probes likely serial portaddresses to see if there are any serial ports there. This works forthe case of jumpers and sometimes works for a ISA PnP port when thedriver doesn't do ISA PnP (prior to kernel 2.4).
Locating the serial port by giving it an IRQ and IO address islow-level configuring. It's often automatically done by the serialdriver but sometimes you have to do it yourself. What follows repeatswhat was said above but in more detail.
The low-level configuring consists of assigning an IO address, IRQ,and names (such as ttyS2) . This IO-IRQ pair must be set inboth the hardware and told to the serial driver. And the driver needsto call this pair a name (such as ttyS2). We could call this 'io-irq'configuring for short. The modern way to do this is for the driver touse PnP methods to detect/set the IO/IRQ and then remember what itdid. An easy way for a driver to do this is for the driver to ask thekernel to enable the device and then the kernel tells the driver whatIO/IRQ it has used. The old way is using the 'setserial' program totell the driver. For jumpers, there is no PnP but the driver mightdetect the port if the jumpers are set to the usual IO/IRQ. If youneed to configure but don't understand certain details it's easy toget into trouble.
When Linux starts, an effort is made to detect and configure(low-level) the serial ports. Exactly what happens depends on yourBIOS, hardware, Linux distribution, kernel version, etc. If theserial ports work OK, there may be no need for you to do any morelow-level configuring.
If you're having problems with the serial ports, then you may need todo low-level configuring. If you have kernel 2.2 or lower, then you need to do it if you:
- Plan to use more than 2 ISA serial ports
- Are installing a new serial port (such as an internal modem)
- One or more of your serial ports have non-standard IRQs or IOaddresses
Starting with kernel 2.2 you may be able to use more than 2 serialports without doing any low-level configuring by sharing interrupts.All PCI ports should support this but for ISA it only works for somehardware. It may be just as easy to give each port a unique interruptif they are available. See Interrupt sharing and Kernels 2.2+
The low-level configuring (setting the IRQ and IO address) seems tocause people more trouble than the high-level stuff, although for manyit's fully automatic and there is no configuring to be done. Untilthe port is enabled and the serial driver knows the correct IRQ and IOaddress, the port will not usually not work at all.
A port may be disabled, either by the BIOS or by failure of Linux tofind and enable the port. For modern ports (provided the BIOS hasn'tdisabled them) manual PnP tools such as lspci should be able to findthem. Applications, and utilities such as 'setserial' and 'scanport'(Debian only ??) only probe IO addresses, don't use PnP tools, andthus can't detect disabled ports.
Even if an ISA port can be found by the probing done by the serialdriver it may work extremely slow if the IRQ is wrong. See Extremely Slow: Text appears on the screen slowly after long delays. PCI ports are less likely to get the IRQ wrong.
IO address, IRQs, etc. are called 'resources' and we are thusconfiguring certain resources. But there are many other types of'resources' so the term has many other meanings. In summary, thelow-level configuring consists of enabling the device, giving it aname (ttyS2 for example) and putting two values (an IRQ number and IOaddress) into two places:
- The device driver (done by PnP or '
setserial
') - Configuration registers of the serial port hardware itself,done by PnP software (or jumpers on legacy hardware).
You may watch the start-up (= boot-time) messages. They are usuallycorrect. But if you're having problems, your serial port may not showup at all or if you do see a message from 'setserial' it may notshow the true configuration of the hardware (and it is not necessarilysupposed to). See I/O Address & IRQ: Boot-time messages.
Introduction
If you have kernel 2.4 or better, then there should be support for PnPfor both the PCI and ISA buses (either built-in or by modules). SomePCI serial ports can be automatically detected and low-levelconfigured by the serial driver. Others may not be.
While kernel 2.2 supported PCI in general, it had no support for PCIserial ports (although some people got them working anyway). Startingwith kernel 2.4, the serial driver will read the id number digitallystored in the serial hardware to determine how to support it (if itknows how). It should assign an I/O address to it, determine itsIRQ, 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 tt/ttyS4 per a boot-timemessage (use
dmesg
to see it). But if you don't have a 'file'/dev/ttyS4 then the port will not work. So you will then need tocreate it, usingcd /dev; ./MAKEDEV ttyS4
More info on PCI
PCI ports are not well standardized. Some use main memory forcommunication with the PC. Some require special enabling of the IRQ.The output of 'lspci -vv' can help determine if one can be supported.If you see a 4-digit IO port, the port might work by just telling'setserial' the IO port and the IRQ. For example, if lspci shows IRQ 10, I/O at 0xecb8 and you decide toname it ttyS2 then the command is:
setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig
Note that the boot-time message 'Probing PCI hardware' means readingthe PnP configuration registers in the PCI devices which detects infoabout all PCI cards and on-board PCI devices. This is different thanthe probing of IO addresses by the serial driver which means readingcertain IO addresses to see if what's read looks like there's a serialport at that address.
Here are some common mistakes people make:
- setserial command: They run it (without the 'autoconfig' andauto_irq options) and think it has checked the hardware to see ifwhat it shows is correct (it hasn't).
- setserial messages: They see them displayed on the screen atboot-time (or by giving the setserial command) and erroneously thinkthat the result always shows how their hardware is actuallyconfigured.
- /proc/interrupts: When their serial device isn't in use theydon't see its interrupt there, and erroneously conclude that theirserial port can't be found (or doesn't have an interrupt set).
- /proc/ioports and /proc/tty/driver/serial: People think thisshows the actual hardware configuration when it only shows about thesame info (possibly erroneous) as setserial.
There are really two answers to the question 'What is my IO andIRQ?' 1. What the device driver thinks has been set (This is whatsetserial usually sets and shows.). 2. What is actually set in thehardware. Both 1. and 2. above should be the same. If they're not itspells trouble since the driver has incorrect info on the physicalserial port. In some cases the hardware is disabled so it has no IOaddress or IRQ.
If the driver has the wrong IO address it will try to send data to anon-existing serial port --or even worse, to some other device. If ithas the wrong IRQ the driver will not get interrupt service requestsfrom the serial port, resulting in a very slow or no response. SeeExtremely Slow: Text appears on the screen slowly after long delays. If it has the wrong model of UART thereis also apt to be trouble. To determine if both IO-IRQ pairs areidentical you must find out how they are set in both the driver andthe hardware.
Introduction
What the driver thinks is not necessarily how the hardware isactually set. If everything works OK then what the driver thinks islikely correct (set in the hardware) and you don't need to investigate(unless you're curious or want to become a guru). Ways to determinewhat the driver thinks include: boot-time messages I/O Address & IRQ: Boot-time messages, the/proc directory 'files' The /proc directory and setserial, and the 'setserial' command.
I/O Address & IRQ: Boot-time messages
In many cases your ports will automatically get low-levelconfigured at boot-time (but not always correctly). To see what ishappening, look at the start-up messages on the screen. Don't neglectto check the messages from the BIOS before Linux is loaded (noexamples shown here). These BIOS messages may be frozen by pressingthe Pause key (while holding down shift). It's often tricky to freezethem and you may need to hit Ctrl-Alt-Del while Linux is booting tostart rebooting and try again. What these messages display may changeas booting progresses and it's often tricky to freeze it at exactly theright words.
Use Shift-PageUp to scroll back to the messages after they haveflashed by. Shift-PageDown will scroll in the opposite direction.The
dmesg
command (or looking at logs in /var/log) will show onlythe first of these two messages. Here's an example of the start-upmessages (as of 2004, almost the same as for 1999). Note that inolder versions ttyS1 was displayed in these messages as ttyS01, etc.At first you see what was detected (but the irq is only a wild guess):
Note that ttyS0-ttyS2 were detected by probing the standard addresseswhile ttyS4 is a PCI port detected by probing the PCI configuration.Later setserial shows you what was saved in a configuration file(which you may edit), but it's not necessarily correct either:
Note that the configuration file only had ttyS1-2 in it so that ttyS0and ttyS4 were not affected by it. There is also a slightdiscrepancy: The first message shows ttyS2 at irq=4 while the secondshows it at irq=5. In most cases the second message is the correctone. But if you're having trouble, it may be misleading. Before readingthe explanation of all of this complexity in the rest of this section,you might just try using your serial port and see if it works OK. Ifso it may not be essential to read further.
The second message is from the
setserial
program being run atboot-time from a script in the /etc directory tree. It shows what thedevice driver thinks is the correct configuration. But this too couldbe wrong. For example, the irq could actually be set to irq=8 in thehardware (both messages wrong). The irq=5 could be there because theconfiguration file is incorrect. With old jumper-set serial ports Linux sometimes gets IRQs wrongbecause it doesn't by default probe for IRQs. It just assumes the'standard' ones (first message) or accepts what is in a configurationfile (second message). Neither of these is necessarily correct. Ifthe serial driver has the wrong IRQ, the serial port is very slow ordoesn't seem to work at all.
The first message is a result of Linux probing the ISA serial portaddresses but it doesn't probe for IRQs. If a port shows up here itexists but the IRQ may be wrong. Linux doesn't check IRQs becausedoing so is not foolproof. It just assumes the IRQs are as shownbecause they are the 'standard' values. You may check them manuallywith
setserial
using the autoconfig
and auto_irq
options but this isn't guaranteed to be correct either.The data shown by the BIOS messages (which you see at first beforeLinux is booted) are what is initially set in the hardware. If yourserial port is Plug-and-Play (PnP) then it's possible that 'isapnp' or'setpci' will run and change these settings. Look for messages aboutthis after Linux starts. The last serial port message shown in theexample above should agree with the BIOS messages (as possiblymodified by isapnp or setpci). If they don't agree then you eitherneed to change the setting in the port hardware or use setserial totell the driver what is actually set in the hardware.
Also, if you have Plug-and-Play (PnP) serial ports, they can only befound by PnP software unless the IRQ and IO has been set inside thehardware by Plug-and-Play software. Prior to kernel 2.4 this was acommon reason why the start-up messages did not show a serial portthat physically exists. A PnP BIOS may automatically low-levelconfigure them. PnP configuring will be explained later.
The /proc directory and setserial
Type 'setserial -g /dev/ttyS*'. There are some otherways to find this info by looking at 'files' in the /proc directory.Be warned that there is no guarantee that the same is set in thehardware.
/proc/ioports
will show the IO addresses that the drivers are using./proc/interrupts
shows the IRQs that are used by drivers ofcurrently running processes (that have devices open). It shows howmany interrupts have actually be issued./proc/tty/driver/serial
shows much of the above, plus thenumber of bytes that have been received and sent (even if the deviceis not now open).Note that for the IO addresses and IRQ assignments, you are only seeingwhat the driver thinks and not necessarily what is actually set in thehardware. The data on the actual number of interrupts issued andbytes processed is real however. If you see a large number ofinterrupts and/or bytes then it probably means that the device is (orwas) working. But the interrupts might be from another device. Ifthere are no bytes received (rx:0) but bytes were transmitted (tx:3749for example), then only one direction of flow is working (or beingutilized).
Sometimes a showing of just a few interrupts doesn't mean that theinterrupt is actually being physically generated by any serial port.Thus if you see almost no interrupts for a port that you're trying touse, that interrupt might not be set in the hardware. To view/proc/interrupts to check on a program that you're currently running(such as 'minicom') you need to keep the program running while youview it.
Introduction
If it's PCI or ISA PnP then what's set in the hardware has been doneby PnP methods. Even if nothing has been set or the port disabled,PnP ports may still be found by using 'lspci -v' or 'isapnp--dumpregs'. Ports disabled by jumpers (or hardware failures) arecompletely lost. See ISA PnP ports,PCI: What IOs and IRQs have been set?,PCI: Enabling a disabled port
PnP ports don't store their configuration in the hardware when thepower is turned off. This is in contrast to Jumpers (non-PnP) whichremain the same with the power off. That's why a PnP port is morelikely to be found in a disabled state than an old non-PnP one.
PCI: What IOs and IRQs have been set?
For PCI, the BIOS almost always sets the IRQ and may set the IOaddress as well. To see how it's set use 'lspci -vv' (best) or lookin /proc/bus/pci (or for kernels <2.2 /proc/pci). The modem'sserial port is often called a 'Communication controller'. Look forthis. If lspci shows 'I/O ports at ... [disabled]' then the serialport is disabled and the hardware has no IO address so it's lost andcan't be used. See PCI: Enabling a disabled port for how to enable it.
If more than one IO address is shown, the first one is more likely tobe it. You can't change the IRQ (at least not with 'setpci') Thisis because if one writes an IRQ it it's hardware register no action istaken on it. It's the BIOS that should actually set up the IRQs andthen write the correct value to this register for lspci to view. Ifyou must, change the IO address with 'setpci' by changing theBASE_ADDRESS_0 or the like.
PCI: Enabling a disabled port
If the port communicates via an IO address then 'lspci -vv' shouldshow 'Control: I/O+ ...' with + meaning that the IO address isenabled. If it shows 'I/O-' (and 'I/O ports at ... [disabled]') thenyou may need to use the setpci command to enable it. For example'setpci -d 151f:000 command=101'. 151f is the vendor id, and 000 isthe device id both obtained from 'lspci -n -v' or from /proc/bus/pcior from 'scanpci -v'. The 'command=101' means that 101 is put intothe command register which is the same as the 'Control' registerdisplayed by 'lspci'. The 101h sets two bits: the 1 sets I/O to + andthe 100 part keeps SERR# set to +. In this case only the SERR# bitof the Control register was initially observed to be + when the lspcicommand was run. So we kept it enabled to + by setting bit 8 (wherebit 0 is I/O) to 1 by the first 1 in 101. Some serial cards don't useSERR# so if you see SERR#- then there's no need to enable it so thenuse: command=1. Then you'll need to set up 'setserial' to tell thedriver the IO and IRQ.
Bit 8 is actually the 9th bit since we started counting bits from 0.Don't be alarmed that lspci shows a lot of - signs showing that thecard doesn't have many features available (or enabled). Serial portsare relatively slow and don't need these features.
Another way to enable it is to let the BIOS do it by telling the BIOSthat you don't have a plug-and-play operating system. Then the BIOSshould enable it when you start your PC. If you have MS Windows9x onthe same PC then doing this might cause problems with Windows (seePlug-and-Play-HOWTO).
ISA PnP ports
For an ISA Plug-and-Play (PnP) port one may try the
pnpdump
program (part of isapnptools
). If you use the --dumpregs optionthen it should tell you the actual IO address and IRQ set in the port.It should also find an ISA PnP port that is disabled. The address it'trys' is not the device's IO address, but a special address used forcommunicating with PnP cards.Finding a port that is not disabled (ISA, PCI, PnP, non-PnP)
Perhaps the BIOS messages will tell you some info before Linuxstarts booting. Use the shift-PageUp key to step back thru theboot-time messages and look at the very first ones which are from theBIOS. This is how it was before Linux started. Setserial can'tchange it but isapnp or setpci can. Starting with kernel 2.4, theserial driver can make such changes for many (but not all) serialports.
Using 'scanport' (Debian only ??) will probe all I/O ports and willindicate what it thinks may be serial port. After this you could tryprobing with setserial using the 'autoconfig' option. You'll need toguess the addresses to probe at (using clues from 'scanport'). SeeWhat is Setserial.
For a port set with jumpers, the IO ports and IRQs are set per thejumpers. If the port is not Plug-and-Play (PnP) but has been setup byusing a DOS program, then it's set at whatever the person who ran thatprogram set it to.
Exploring via MS Windows (a last resort)
For PnP ports, checking on how it's configured under DOS/Windowsmay (or may not) imply how it's under Linux. MS Windows stores itsconfiguration info in its Registry which is not used by Linux so theyare not necessarily configured the same. If you let a PnP BIOSautomatically do the configuring when you start Linux (and have toldthe BIOS that you don't have a PnP operating system when startingLinux) then Linux should use whatever configuration is in the BIOS'snon-volatile memory. Windows also makes use of the same non-volatilememory but doesn't necessarily configure it that way.
If you have Plug-and-Play ports then either a PnP BIOS or aserial driver may configure all your devices for you so then you maynot need to choose any IRQs. PnP software determines what it thinksis best and assigns them (but it's not always best). But if youdirectly use isapnp (ISA bus) or jumpers then you have to choose. Ifyou already know what IRQ you want to use you could skip this sectionexcept that you may want to know that IRQ 0 has a special use (see thefollowing paragraph).
IRQ 0 is not an IRQ
While IRQ 0 is actually the timer (in hardware) it has a specialmeaning for setting a serial port with setserial. It tells the driverthat there is no interrupt for the port and the driver then will usepolling methods. Such polling puts more load on the CPU but can betried if there is an interrupt conflict or mis-set interrupt. Theadvantage of assigning IRQ 0 is that you don't need to know whatinterrupt is set in the hardware. It should be used only as atemporary expedient until you are able to find a real interrupt touse.
Interrupt sharing, Kernels 2.2+
Sharing of IRQs is where two devices use the same IRQ. As ageneral rule, this wasn't allowed for the ISA bus. The PCI bus mayshare IRQs but one can't share the same IRQ between the ISA and thePCI bus. Most multi-port boards may share IRQs. Sharing is not asefficient since every time a shared interrupt is given a check must bemade to determine where it came from. Thus if it's feasible, it'snicer to allocate every device its own interrupt.
Prior to kernel 2.2, serial IRQs could not be shared with each otherexcept for most multiport boards. Starting with kernel 2.2 serialIRQs may be sometimes shared between serial ports. In order forsharing to work in 2.2 the kernel must have been compiled withCONFIG_SERIAL_SHARE_IRQ, and the serial port hardware must supportsharing (so that if two serial cards put different voltages on thesame interrupt wire, only the voltage that means 'this is aninterrupt' will prevail). Since the PCI bus specs permit sharing, anyPCI card should allow sharing.
What IRQs to choose?
The serial hardware often has only a limited number of IRQs. Alsoyou don't want IRQ conflicts. So there may not be much of a choice.Your PC may normally come with
ttyS0
and ttyS2
at IRQ 4, andttyS1
and ttyS3
at IRQ 3. Looking at/proc/interrupts
will show which IRQs are being used byprograms currently running. You likely don't want to use one ofthese. Before IRQ 5 was used for sound cards, it was often used for aserial port.Here is how Greg (original author of Serial-HOWTO) set his up in/etc/rc.d/rc.serial. rc.serial is a file (shell script) which runs atstart-up (it may have a different name or location). For versions of'setserial' after 2.15 it's not always done this way anymore but thisexample does show the choice of IRQs.
Standard IRQ assignments:
There is really no Right Thing to do when choosing interrupts. Try tofind one that isn't being used by the motherboard, or any otherboards. 2, 3, 4, 5, 7, 10, 11, 12 or 15 are possible choices. Notethat IRQ 2 is the same as IRQ 9. You can call it either 2 or 9, theserial driver is very understanding. If you have a very old serialboard it may not be able to use IRQs 8 and above.
Make sure you don't use IRQs 1, 6, 8, 13 or 14! These are used byyour motherboard. You will make her very unhappy by taking her IRQs.When you are done you might want to double-check
/proc/interrupts
when programs that use interrupts are beingrun and make sure there are no conflicts. Here's a problem with some old serial cards. The IO address ofthe IBM 8514 video board (and others like it) is allegedly 0x?2e8where ? is 2, 4, 8, or 9. This may conflict with the IO address of
ttyS3
at 0x02e8. Your may think that this shouldn't happen sincethe addresses are different in the high order digit (the leading 0 in02e8). You're right, but a poorly designed serial port may ignore thehigh order digit and respond to any address that ends in 2e8. That isbad news if you try to use ttyS3
(ISA bus) at this IO address.For the ISA bus you should try to use the default addresses shownbelow. PCI cards use different addresses so as not to conflict withISA addresses. The addresses shown below represent the first addressof an 8-byte range. For example 3f8 is really the range 3f8-3ff.Each serial device (as well as other types of devices that use IOaddresses) needs its own unique address range. There should be nooverlaps (conflicts). Here are the default addresses for commonlyused serial ports on the ISA bus:
Suppose there is an address conflict (as reported by
setserial -g/dev/ttyS*
) between a real serial port and another port whichdoes not physically exist (and shows UART: unknown). Such a conflictshouldn't cause problems but it sometimes does in older kernels. Toavoid this problem don't permit such address conflicts or delete/dev/ttySx if it doesn't physically exist. After it's set in the hardware don't forget to insure that it alsogets set in the driver by using
setserial
. For non-PnP serialports they are either set in hardware by jumpers or by running a DOSprogram ('jumperless') to set them (it may disable PnP). The rest ofthis subsection is only for PnP serial ports. Here's a list of thepossible methods of configuring PnP serial ports:- Using a PnP BIOS CMOS setup menu(usually only for externaldeviceson ttyS0 (Com1) and ttyS1 (Com2))
- Letting a PnP BIOS automatically configure a PnP serial portSee Using a PnP BIOS to IO-IRQ Configure
- Doing nothing if the serial driver recognized your card OK
- Using
isapnp
for a PnP serial port (non-PCI) - Using setpci (pciutils or pcitools) for the PCI bus
The IO address and IRQ must be set (by PnP) in their registers eachtime the system is powered on since PnP hardware doesn't remember howit was set when the power is shut off. A simple way to do this is tolet a PnP BIOS know that you don't have a PnP OS and the BIOS willautomatically do this each time you start. This might cause problemsin Windows (which is a PnP OS) if you start Windows with the BIOSthinking that Windows is not a PnP OS. See Plug-and-Play-HOWTO.
Plug-and-Play (PnP) was designed to automate this io-irq configuring,but for Linux it initially made life much more complicated. In modernLinux (2.4 kernels --partially in 2.2 kernels), each device driver hasto do its own PnP (using supplied software which it may utilize).There is unfortunately no centralized planning for assigning IOaddresses and IRQs as there is in MS Windows. But it usually worksout OK in Linux anyway.
Using a PnP BIOS to IO-IRQ Configure
While the explanation of how to use setpci or isapnp for io-irqconfiguring should come with such software, this is not the case ifyou want to let a PnP BIOS do such configuring. Not all PnP BIOS cando this. The BIOS usually has a CMOS menu for setting up the firsttwo serial ports. This menu may be hard to find. For an 'Award'BIOS it was found under 'chipset features setup' There is oftenlittle to choose from. For ISA serial ports, the first two portsnormally get set at the standard IO addresses and IRQs. See More on Serial Port Names
Whether you like it or not, when you start up a PC, a PnP BIOS startsto do PnP (io-irq) configuring of hardware devices. It may do the jobpartially and turn the rest over to a PnP OS (which Linux is in somesense) or if thinks you don't have a PnP OS it may fully configure allthe PnP devices but not configure the device drivers.
If you tell the BIOS that you don't have a PnP OS, then the PnP BIOSshould do the configuring of all PnP serial ports --not just the firsttwo. An indirect way to control what the BIOS does (if you haveWindows 9x on the same PC) is to 'force' a configuration underWindows. See Plug-and-Play-HOWTO and search for 'forced'. It'seasier to use the CMOS BIOS menu which may override what you'forced' under Windows. There could be a BIOS option that can set ordisable this 'override' capability.
If you add a new PnP device, the BIOS should PnP configure it. Itcould even change the io-irq of existing devices if required to avoidany conflicts. For this purpose, it keeps a list of non-PnP devicesprovided that you have told the BIOS how these non-PnP devices areio-irq configured. One way to tell the BIOS this is by running aprogram called ICU under DOS/Windows.
But how do you find out what the BIOS has done so that you set up thedevice drivers with this info? The BIOS itself may provide some info,either in its setup menus of via messages on the screen when you turnon your computer. See What is set in my serial port hardware?. Other ways of finding out is to use lspci forthe PCI bus or isapnp --dumpregs for the ISA bus. The cryptic resultsit shows you may not be clear to a novice.
Once you've set the IRQ and IO address in the hardware (or arrangedfor it to be done by PnP) you also need to insure that the 'setserial'command is run each time you start Linux. See the subsection Boot-time Configuration
See the section Stty. The 'stty' commandsets many things such as flow control, speed, and parity. The onlyone discussed in this section is flow control.
Configuring Flow Control: Hardware Flow Control is Usually BestSee Flow Control for an explanation ofit. It's usually better to use hardware flow control rather thansoftware flow control using Xon/Xoff. To use full hardware flowcontrol you must normally have two dedicated wires for it in the cablebetween the serial port and the device. If the device is on a card orthe motherboard, then it should always be possible to use hardwareflow control.
Many applications (and the getty program) give you an optionregarding flow control and will set it as you specify or it mightenable hardware flow control by default if you don't set it. It mustbe set both in the serial driver and in the hardware connected to theserial port. How it's set into this hardware is hardware dependent.Sometimes there is a certain 'init string' you send to the hardwaredevice via the serial port from your PC. For a modem, thecommunication program should set it in both places.
If a program you use doesn't set flow control in the serial driver,then you may do it yourself using the
or for old stty versions < 1.17:stty
command. Since thedriver doesn't remember the setting after you stop Linux, you couldput the stty command in a file that runs at start-up or when you login(such as /etc/profile for the bash shell). Here's what you would addfor hardware flow control for port ttyS2:crtscts
stands for a Control setting to use the RTS and CTS pins ofthe serial port for hardware flow control. Note that RTS+CTS almostspells: crtscts
and the initial 'c' means 'control'.Common serial port names are /dev/ttyS0, /dev/ttyS1, etc. Thenaround the year 2000 came the USB bus with names like /dev/ttyUSB0 and/dev/ttyACM1 (for the ACM modem on the USB bus). Multiport serialcard used somewhat differnt names (depending on the brand) such as/dev/ttyE5.
Since DOS provided for 4 serial ports on the old ISA bus:COM1-COM4, or ttyS0-ttyS3 in Linux, most serial ports on the newer PCIbus used higher numbers such as ttyS4 or ttyS14 (prior to kernel2.6.13). But since most PCs only came with one or two serial ports,ttyS0 and possibly ttyS1 (for the second port) the PCI bus can now usettyS2 (kernel 2.6.15 on). All this permits one to have both ISAserial ports and PCI serial ports on the same PC with no nameconflicts. 0-1 (or 0-3) are reserved for the old ISA bus (or thenewer LPC bus) and 2-upward (or 4-upward or 14-upward) are used forPCI, where older schemes are shown in parentheses . It's not requiredto be this way but it often is.
If you're using udev (which puts only the device you have on yourcomputer into the /dev directory at boottime) then there's an easy wayto change the device names by editing files in /etc/udev/. Forexample, to change the name of what the kernel detects as ttyS3 towhat you want to name it: ttyS14, add a line similar to this to/etc/udev/udev.rules
BUS'pci' KERNEL'ttyS3',NAME='ttyS14'
BUS'pci' KERNEL'ttyS3',NAME='ttyS14'
On-board serial ports on motherboards which have both PCI and ISAslots are likely to still be ISA ports. Even for all-PCI-slotmotherboards, the serial ports are often not PCI. Instead, they areeither ISA, on an internal ISA bus or on a LPC bus which is intendedfor slow legacy I/O devices: serial/parallel ports and floppy drives.
Devices in Linux have major and minor numbers. The serial portttySx (x=0,1,2, etc.) is major number 4. You can see this (and theminor numbers too) by typing: 'ls -l ttyS*' in the /dev directory. Tofind the device names for various devices, see the 'devices' file inthe kernel documentation.
There formerly was a 'cua' name for each serial port and it behavedjust a little differently. For example, ttyS2 would correspond tocua2. It was mainly used for modems. The cua major number was 5 andminor numbers started at 64. You may still have the cua devices inyour /dev directory but they are now deprecated. For details seeModem-HOWTO, section: cua Device Obsolete.
For creating the old devices in the device directory see:
Dos/Windows use the COM name while the messages from the serial driveruse ttyS00, ttyS01, etc. Older serial drivers (2001 ?) used justtty00, tty01, etc.
The tables below shows some examples of serial device names. TheIO addresses are the default addresses for the old ISA bus (not forthe newer PCI and USB buses).
For more info see the usb subdirectory in the kernel documentationdirectory for files: usb-serial, acm, etc.
On some installations, two extra devices will be created,
/dev/modem
for your modem and /dev/mouse
for amouse. Both of these are symbolic links to the appropriatedevice in /dev
.Historical note: Formerly (in the 1990s) the use of
/dev/modem
(as a link to the modem's serial port) wasdiscouraged since lock files might not realize that it was really say/dev/ttyS2
. The newer lock file system doesn't fall intothis trap so it's now OK to use such links.Inspect the connectors
Inspecting the connectors may give some clues but is often notdefinitive. The serial connectors on the back side of a PC areusually DB connectors with male pins. 9-pin is the most common butsome are 25-pin (especially older PCs like 486s). There may be one9-pin (perhaps ttyS0 ??) and one 25-pin (perhaps ttyS1 ??). For two9-pin ones the top one might be ttyS0.
If you only have one serial port connector on the back of your PC,this may be easy. If you also have an internal modem, a program likewvdial may be able to tell you what port it's on (unless it's a PnPthat hasn't been enabled yet). A report from setserial (atboot-time or run by you from the command line) should help youidentify the non-modem ports.
If you have two serial ports it may be more difficult. You could haveonly one serial connector but actually have 2 ports, one of whichisn't used (but it's still there electronically). First check manuals(if any) for your computer. Look at the connectors for meaningfullabels. You might even want to take off the PC's cover and see ifthere are any meaningful labels on the card where the internal ribbonserial 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 willdepend on jumper or PnP settings (sometimes shown in a BIOS setupmenu). 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. Ifthe serial ports have been configured correctly per setserial, thenyou may send some bytes out a port and try to detect which connector(if any) they are coming out of. One way to send such a signal is tocopy a long text file to the port using a command like: cpmy_file_name /dev/ttyS1. A voltmeter connected to the DTR pin (seeSerial-HOWTO for Pinout) will display a positive voltage as soon asyou give the copy command.
The transmit pin should go from several volts negative to a voltagefluctuating around zero after you start sending the bytes. If it doesn't(but the DTR went positive) then you've got the right port but it'sblocked from sending. This may be due to a wrong IRQ, -clocal beingset, etc. The command '
stty -F /dev/ttyS1 -a
' should showclocal (and not -clocal). If not, change it to clocal.Another test is to jumper the transmit and receive pins (pins 2 and 3of either the 25-pin or 9-pin connector) of a test serial port. Thensend something to each port (from the PCs keyboard) and see if it getssent back. If it does it's likely the port with the jumper on it.Then remove the jumper and verify that nothing gets sent back. Notethat if 'echo' is set (per stty) then a jumper creates an infiniteloop. Bytes that pass thru the jumper go into the port and come rightback out of the other pin back to the jumper. Then they go back inand out again and again. Whatever you send to the port repeats itselfforever (until you interrupt it by removing the jumper, etc.). Thismay be a good way to test it as the repeating test messages halt whenthe jumper is removed.
As a jumper you could use a mini (or micro) jumper cable (sold in someelectronic parts stores) with mini alligator clips. A small scrap ofpaper may be used to prevent the mini clips from making electricalcontact where it shouldn't. Metal paper clips can sometimes be bentto use as jumpers. Whatever you use as a jumper take care not to bendor excessively scratch the pins. To receive something from a port,you can go to a virtual terminal (for example Alt-F2 and login) andtype something like 'cp /dev/ttyS2 /dev/tty'. Then at another virtualterminal you may send something to ttyS2 (or whatever) by 'echotest_message > /dev/ttyS2'. Then go back to the receive virtualterminal and look for the test_message. See Serial Electrical Test Equipment for more info.
Connect a device to the connector
Another way to try to identify a serial port is to connect somephysical serial device to it and see if it works. But a problem hereis that it might not work because it's not configured right. A serialmouse might get detected at boot-time if connected.
You may put a device, such as a serial mouse (use 1200 baud), on a portand then use minicom or picocom to communicate with that port. Thenby clicking on the mouse, or otherwise sending characters with thedevice, see if they get displayed. It not you may have told picocomthe wrong port (such as ttyS0 instead of ttyS1) so try again.
Missing connectors
If the software shows that you have more serial ports than youhave connectors for (including an internal modem which counts as aserial port) then you may have a serial port that has no connector.Some motherboards come with a serial port with no cable or externalserial DB connector. Someone may build a PC from this and decide notto use this serial port. There may be a 'serial' connector and labelon the motherboard but no ribbon cable connects to its pins. To usethis port you must get a ribbon cable and connector. I've seendifferent wiring arrangements for such ribbon cables so beware.
If you don't use devfs (which automatically creates such devices) anddon't have a device 'file' that you need, you will have to create it.Use the
The MAKEDEV script is easier to use.See the man page for it. For example, if you needed to make thedevice for mknod
command or with the MAKEDEV shell script.Example, suppose you needed to create ttyS0
:ttyS0
you would just type:If the above command doesn't work (and you are the root user), lookfor 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 Making multiport devices in the /dev directory.
Most info on getty has been moved to Modem-HOWTO with a little info onthe use of getty with directly connected terminals now found inText-Terminal-HOWTO.
A few Linux programs (and one 'file') will monitor various modemcontrol lines and indicate if they are positive (1 or green) ornegative (0 or red).
- serlook can snoop on serial line traffic (via a wiretap) andalso send/receive on a serial line.
- The 'file': /proc/tty/driver/serial lists those that areasserted (positive voltage)
- modemstat (Only works correctly on Linux PC consoles.) Statusmonitored in a tiny window. Color-coded and compact. Must killit (a process) to quit.
- statserial (Info displayed on entire screen)
- serialmon (Doesn't monitor RTS, CTS, DSR but logs otherfunctions)
irqtune
will give serial port interrupts higherpriority to improve performance.hdparm
for hard-disk tuning may help some more.
This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. Thereare some minor differences, depending on which HOWTO it appears in.
Setserial problems with linmodems, laptops
If you have a Laptop (PCMCIA) don't use
setserial
until youread Laptops: PCMCIA.Introduction
setserial
is a program used for the user to communicate withthe serial device driver. You normally never need to use it, providedthat you only use the one or two serial ports that come as standardequipment with a PC. Even in other cases, most extra serial portsshould be auto-detected by modern kernels. Except you'll need to usesetserial if you have an old ISA serial port set by jumpers on thephysical hardware or if your kernel (such as 2.2 or older) doesn'tboth detect and set your add-on PCI serial ports.setserial
allows you (or a shell script) to talk to the serialsoftware. But there's also another program, tt/stty/, that also dealswith the serial port and is used for setting the port speed, etc.setserial
deals with the lower-level configuring of the serialport, such as dealing with IRQs (such as 5), port addresses (such as3f8), and the like. A major problem with it is that it can'tset or configure the serial port hardware: It can't set the IRQ orport addresses into the hardware. Furthermore, when it seeminglyreports the configuration of the hardware, it's sometimes wrong sinceit doesn't actually probe the hardware unless you specifically tell itto. Even then, it doesn't do the modern type of bus probing and somehardware may never be found by it. Still, what it shows is right mostall the time but if you're having trouble getting a serial port towork, then there's a fair chance it's wrong.In olden days, when the IRQ and port address was set by jumpers on theserial card, one would use
setserial
to tell the driver how thesejumpers were set. Today, when plug-and-play methods detect how thejumperless serial port is set, setserial
is not really neededanymore unless you're having problems or using old hardware.Furthermore, if the configuration file used by setserial
iswrong, then there's trouble. In this case, if you use setserial
to try to find out how the port is configured, it may just repeat theincorrect information in the configuration file.setserial
can sometimes be of help to find a serial port. But it's only of use if you know the port address and use the rightoptions. For modern ports, there's usually better ways to look forthem by plug-and-play methods.Thus the name
setserial
is somewhat of a misnomer since itdoesn't set the I/O address nor IRQ in the hardware, it just 'sets'them in the driver software. And the driver naively believes thatwhat setserial
tells it, even if it conflicts with what the driverhas found by using plug-and-play methods. Too bad that it fails toat least issue a warning message for such a conflict. Since thedevice driver is considered to be part of the kernel, the word'kernel' is often used in other documentation with no mention made ofany 'serial driver'. Some distributions (and versions) set things up so that
setserial
is run at boot-time by an initialization shell script (in the/etc directory tree). But the configuration file which this scriptuses may be either in the /etc tree or the /var tree. In some cases,if you want setserial
to run at boot-time, you may have to takesome action. setserial
will not work without either serialsupport built into the kernel or loaded as a module. The module mayget loaded automatically if you (or a script) attempt to usesetserial
.While
setserial
can be made to probe the hardware IO portaddresses to try to determine the UART type and IRQ, this hassevere limitations. See Probing. Itcan't set the IRQ or the port address in the hardware of PnP or PCIserial ports (but the plug-and-play features of the serial driver maydo this). It also can't directly read the PnP data stored inconfiguration registers in the hardware. But since the device drivercan read these registers and setserial tells you what the devicedriver thinks, it might be correct. Or it could be telling you whatsetserial
had previously (and perhaps erroneously) told thedriver. There's no way to know for sure without doing some otherchecks.The serial driver (for Linux Kernel 2.4+) looks for a few 'standard'legacy serial ports, for PnP ports on the ISA bus, and for allsupported port hardware on the PCI bus. If it finds your portscorrectly, then there's no need to use
setserial
. The driverdoesn't probe for the IRQs of old ISA serial ports set with jumpers onthe card and may get these wrong.Besides the man page for
setserial
, check out info in/usr/doc/setserial.../
or /usr/share/doc/setserial
.This should tell you how setserial is handled for your distribution ofLinux. While setserial
behaves the same in all distributions,the scripts for running it, how to configure such scripts (includingautomatic configuration), and the names and locations of the scriptfiles, etc., are all distribution-dependent. Serial module unload
If a serial module gets unloaded, the changes previously made by
setserial
will be forgotten by the driver. But while the driverforgets it, a script provided by the distribution may save it in afile somewhere so that it can the restored if the module is reloaded.Slow baud rates of 1200 or less
There once was a problem with slow serial printers (especially theold ones of the 1980s). The printing program would close the serialport at the 'end' of printing well before all the characters from thelarge serial buffer (in main memory) were sent to the printer. Theresult was a truncated print job that didn't print the last paragraphor last page, etc.
But the newer lprng print program (and possibly other printingprograms) keeps the port open until printing is finished so 'problemsolved', even if you're using an antique printer. Setserial canmodify the time that the port will keep operating after it's closed(in order to output any characters still in its buffer in main RAM).This is done by the 'closing_wait' option per the
setserial
manpage. For 'bad' software that closes the port too soon, it might alsobe needed at speeds above 1200 if there are a lot of 'flow control'waits. Giving the setserial
command
Remember, that
setserial
can't set any I/O addresses or IRQsin the hardware. That's done either by plug-and-play software (run bythe driver) or by jumpers for legacy serial ports. Even if you givean I/O address or IRQ to the driver via setserial
it will not setsuch values and assumes that they have already been set. If you giveit wrong values, the serial port will not work right (if at all).For legacy ports, if you know the I/O address but don't know the IRQyou may command setserial to attempt to determine the IRQ.
You can see a list of possible commands by just typing
You'll see some info about how the device driver is configured foryour ports. In many cases you'll see some ports displayed with whatappears at first glance to be erroneous IRQs and addresses. But ifyou also see: setserial
with no arguments. This fails to show you the one-letter options suchas -v for verbose which you should normally use when troubleshooting.Note that setserial calls an IO address a 'port'. If you type:'UART: unknown'
just ignore the entire linesince no serial port exists at that address. If you add -a to the option -g you will see more info although fewpeople need to deal with (or understand) this additional info sincethe default settings you see usually work fine. In normal cases thehardware is set up the same way as 'setserial' reports. But if you arehaving problems there is a good chance that
setserial
has it wrong.In fact, you can run 'setserial' and assign a purely fictitious I/Oport address, any IRQ, and whatever uart type you would like to have.Then the next time you type 'setserial ...' it will display thesebogus values you've supplied to the driver. They will also be officiallyregistered with the kernel as displayed (at the top of the screen) bythe 'scanport' command (Debian). Of course the serialport driver will not work correctly (if at all) if you attempt to usesuch a port. Thus, when giving parameters to setserial
, 'anythinggoes'. Well almost. If you assign one port a base address that isalready assigned (such as 3e8) it may not accept it. But if you use3e9 it will accept it. Unfortunately 3e9 is actually assigned since itis within the range starting at base address 3e8. Thus the moral ofthe story is to make sure your data is correct before assigningresources with setserial.Configuration file
While assignments made by setserial are lost when the PC is poweredoff, a configuration file may restore them when the PC is startedup again. In newer versions, what you change by setserial might getautomatically saved to a configuration file. When
setserial
runsit uses the info from the configuration file.Where this configuration file resides depends on your distribution.Look at the start-up scripts somewhere in the /etc/ tree (such as/etc/init.d/ or /etc/rc.d/) and read the startup script for 'serial'or 'setserial' or the like. It should show where the configurationfile(s) reside. In Debian there are 4 options for use of thisconfiguration file:
- Don't use this file at all. At each boot, the serial driveralone detects the ports and setserial doesn't ever run. ('kernel' option)
- Save what
setserial
reports when the system is firstshutdown and put it in the configuration file. After that, don't evermake any changes to the configuration file, even if someone has madechanges by running thesetserial
command on the command line andthen shuts down the system. ('autosave-once' option) - At every shutdown, save whatever
setserial
detects to theconfiguration file. ('autosave' option) - Manually edit the configuration file to set the configuration.Don't ever do any automatic saves to it. ('manual' option)
In olden days (perhaps before 2000), there wasn't any configurationfile and the configuration was manually set (hard coded) inside theshell script that ran
setserial
. See Edit a script (prior to version 2.15).Probing
You probe for a port with
setserial
only when you suspect thatit has been enabled (by PnP methods, the BIOS, jumpers, etc.).Otherwise setserial
probing will never find it since its addressdoesn't exist. A problem is where the software looks for a port atspecified I/O addresses. Prior to probing with 'setserial', one mayrun the 'scanport' (Debian) command to check all possible ports in onescan. It makes crude guesses as to what is on some ports but doesn'tdetermine the IRQ. It's a fast first start. It may hang your PC butso far it's worked fine for me. Note that non-Debian distributionsdon't seem to supply 'scanport'. Is there another scan program?With appropriate options,
setserial
can probe (at a given I/Oaddress) for a serial port but you must guess the I/O address. If youask it to probe for /dev/ttyS2 for example, it will only probe at theaddress it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2is at a different address, then it will probe at that address, etc.See ProbingThe purpose of such probing is to see if there is a uart there, and ifso, what its IRQ is. Use
If the resulting message shows a uart type such as 16550A, then you'reOK. If instead it shows '
setserial
mainly as a last resort asthere are faster ways to attempt it such as wvdialconf to detectmodems, looking at very early boot-time messages, or using pnpdump--dumpregs
, or lspci -vv. But if you want to detect hardwarewith setserial
use for example :setserial/dev/ttyS2 -v autoconfig
If the resulting message shows a uart type such as 16550A, then you'reOK. If instead it shows '
unknown
' for the uart type, then thereis supposedly no serial port at all at that I/O address. Some cheapserial ports don't identify themselves correctly so if you see'unknown
' you still might have a serial port there.Besides auto-probing for a uart type, setserial can auto-probe forIRQ's but this doesn't always work right either. In one case it firstgave the wrong irq but when the command was repeated it found thecorrect irq. In versions of setserial >= 2.15, the results of yourlast probe test could be automatically saved and put into adistribution-specific configuration file such as
/etc/serial.conf
or /etc/sysconfig/serial
or/var/lib/setserial/autoserial.conf
for Debian. This will beused next time you start Linux. It may be that two serial ports both have the same IO address set inthe hardware. Of course this is not normally permitted for the ISAbus but it sometimes happens anyway. Probing detects one serial portwhen actually there are two. However if they have different IRQs,then the probe for IRQs may show IRQ = 0. For me, it only did this ifI first used
setserial
to give the IRQ a fictitious value.Boot-time Configuration
While
setserial
may run via an initialization script,something akin to setserial
also runs earlier when the serialmodule is loaded (or when the kernel starts the built-in serial driverif it was compiled into the kernel). Thus when you watch the start-upmessages on the screen it may look like it ran twice, and in fact ithas. If the first message is for a legacy port, the IRQs shown may be wrongsince it didn't probe for IRQs. If there is a second report of serialports, it may the result of a script such as /etc/init.d/setserial.It usually does no probing and thus could be wrong about how thehardware is actually set. It only shows configuration data that gotsaved in a configuration files. The old method, prior to setserial2.15, was to manually write such data directly into the script.
When the kernel loads the serial module (or if the 'module equivalent'is built into the kernel) then all supported PnP ports are detected.For legacy (non-PnP) ports, only
ttyS{0-3}
are auto-detectedand the driver is set to use only IRQs 4 and 3 (regardless of whatIRQs are actually set in the hardware). No probing is done for IRQsbut it's possible to do this manually. You see this as a boot-timemessage just as if setserial
had been run.To correct possible errors in IRQs (or for otherreasons) there may be a script file somewhere that runs
setserial
. Unfortunately, if this file has some IRQs wrong, thekernel will still have incorrect info about the IRQs. This file isusually part of the initialization done at boot-time. Whether itruns or not depends on how you (and/or your distribution) have setthings up. It may also depends on the runlevel. Before modifying a configuration file, you can test out a 'proposed'
setserial
command by just typing it on the command line. In somecases the results of this use of setserial
will automatically getsaved somewhere such as /etc/serial.conf (or autoserial.conf orserial) when you shutdown. So if it worked OK (and solved yourproblem) then there's no need to modify any configuration file. SeeConfiguration method using /etc/serial.conf, etc..Edit a script (required prior to version 2.15)
This is how it was done prior to
setserial
2.15 (1999)The objective was to modify (or create) a script file in the /etctree that runs setserial at boot-time. Most distributions providedsuch a file (but it may not have initially resided in the /etc tree).So prior to version 2.15 (1999) it was simpler. All you did was edita script. There was no /etc/serial.conf file (or the like) toconfigure setserial. Thus you needed to find the file that runs'setserial' at boot time and edit it. If it didn't exist, you neededto create one (or place the commands in a file that ran early atboot-time). If such a file was currently being used it's likelywas somewhere in the /etc directory-tree. But Redhat <6.0 has supplied itin /usr/doc/setserial/ but you need to move it to the /etc tree beforeusing 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 maynot have run early enough. It was reported that other processes maytry to open the serial port before rc.local ran resulting in serialcommunication 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 ofcommented-out examples. By uncommenting some of these and/ormodifying them, you could set things up correctly. It was importantuse a valid path for
setserial
, and a validdevice 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 was a lot faster than doing repeated reboots to getit right.For versions >= 2.15 (provided your distribution implemented thechange, Redhat didn't at first) it may be more tricky to do since thefile that runs setserial on startup, /etc/init.d/setserial or the likewas not intended to be edited by the user. See Configuration method using /etc/serial.conf, etc..
An example line in such a script was:
or, if you wanted setserial to automatically determine the uart and theIRQ for ttyS3 you would have used something like this:
This was done for every serial port you wanted to auto configure,using a device name that really does exist on your machine. In somecases it didn't work right due to the hardware.
Configuration method using /etc/serial.conf, etc.
Prior to setserial version 2.15 (1999), the way to configuresetserial was to manually edit the shell-script that ran setserial atboot-time. See Edit a script (before version 2.15). This was simple, but the simple and clear method hasbeen changed to something that is unnecessarily complex. Today thescript and configuration file are two different files instead of one.This shell-script is not edited but gets its data from a configurationfile 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 mayautomatically cause serial.conf to be edited appropriately. This wasdone so that you may not need to edit any file in order to set up (orchange) what setserial does each time that Linux is booted.
What often happens is this: When you shut down your PC the scriptthat ran 'setserial' at boot-time is run again, but this time it onlydoes what the part for the 'stop' case says to do: It uses'setserial' to find out what the current state of 'setserial' is, andit puts that info into the serial configuration file such as
serial.conf
. Thus when you run 'setserial' to changethe serial.conf file, it doesn't get changed immediately but only whenand if you shut down normally.Now you can perhaps guess what problems might occur. Suppose youdon't shut down normally (someone turns the power off, etc.) and thechanges don't get saved. Suppose you experiment with 'setserial' andforget to run it a final time to restore the original state (or make amistake in restoring the original state). Then your 'experimental'settings are saved. And worst of all, unless you know which optionswere 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 makethem with the setserial command.
If the option '###AUTOSAVE###' is set and you manually editserial.conf, then your editing is destroyed when you shut down becauseit gets changed back to the state of setserial at shutdown. There isa way to disable the changing of serial.conf at shutdown and that isto remove '###AUTOSAVE###' or the like from first line of serial.conf.In the Debian distribution, the removal of '###AUTOSAVE###' from thefirst line was once automatically done after the first time youshutdown just after installation. To retain this effect the'AUTOSAVE-ONCE' option was created which only does a save when timethe system is shut down for the first time (just after you install orupdate the setserial program).
The file most commonly used to run setserial at boot-time (inconformance with the configuration file) is now /etc/init.d/setserial(Debian) or /etc/init.d/serial (Redhat), or etc., but it should notnormally be edited. For 2.15, Redhat 6.0 just had a file/usr/doc/setserial-2.15/rc.serial which you have to move to/etc/init.d/ if you want setserial to run at boot-time.
To disable a port, use
setserial
to set it to 'uart none'. Thiswill not be saved. The format of /etc/serial.conf appears to be justlike that of the parameters placed after 'setserial' on the commandline with one line for each port. If you don't use autosave, you mayedit /etc/serial.conf manually.In order to force the current settings set by setserial to be saved tothe configuration file (serial.conf) without shutting down, do whatnormally happens when you shutdown: Run the shell-script
/etc/init.d/{set}serial stop
. The 'stop' command will savethe current configuration but the serial ports still keep working OK.In some cases you may wind up with both the old and new configurationmethods installed but hopefully only one of them runs at boot-time.Debian labeled obsolete files with '...pre-2.15'.
IRQs
By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 andttyS3 share IRQ 3. But while sharing serial interrupts (using them inrunning programs) is OK for the PCI bus, it's not permitted for theISA bus unless you: 1. have kernel 2.2 or better, and 2. you'vecompiled in support for this, and 3. your serial hardware supports it.See
If you only have two serial ports, ttyS0 and ttyS1, you're still OKsince IRQ sharing conflicts don't exist for non-existent devices.
If you add a legacy internal modem (without plug-and-play) and retainttyS0 and ttyS1, then you should attempt to find an unused IRQ and setit in your serial port (or modem card) and then use setserial toassign it to your device driver. If IRQ 5 is not being used for asound card, this could be used for a modem.
Laptops: PCMCIA
If you have a Laptop, read PCMCIA-HOWTO for info on the serialconfiguration. For serial ports on the motherboard, setserial is usedjust like it is for a desktop. But for PCMCIA cards (such as a modem)it's a different story. The configuring of the PCMCIA system shouldautomatically run setserial so you shouldn't need to run it. If youdo run it (by a script file or by /etc/serial.conf) it might bedifferent and cause trouble. The autosave feature for serial.confshouldn't save anything for PCMCIA cards (but Debian did until2.15-7). Of course, it's always OK to use setserial to find out howthe driver is configured for PCMCIA cards.
Introduction
stty
does much of the configuration of the serial port butsince application programs (and the getty program) often handle this,you may not need to use it much. It's handy if you're having problemsor want to see how the port is set up. Try typing ``stty -a' at yourterminal/console to see how it's now set. Also try typing it withoutthe -a (all) for a short listing which shows how it's set differentthan 'normal' which is how it's set using the command 'sttysane'
. Don't try to learn all the setting unless you want tobecome a serial historian since many of the settings are only for slowantique dumb terminals of the 1970's. Most of the defaults shouldwork OK.stty
is documented in the man pages with a more detailed accountin the info pages. Type 'man stty'
or 'info stty'
.Many of the stty options start with an 'o' (output) or an 'i' (input).For example:
onlcr
. Output is the flow of bytes out of thecomputer while input is the flow of bytes into the computer. The'point of view' is the computer, not the serial port or the deviceconnected to the serial port. For example, received input data comesin on a cable and goes to the serial port chip. This chip, afterconverting the bits from the serial to parallel representation, thensends it (via a program read) to the large serial port buffer in maincomputer memory. Thus the chip has both input and output but sinceit's input data to the computer, its output is considered to be input.The situation is similar for output flowing thru this chip. The'input' and 'output' refer to the direction of flow with respect to thecomputer and not the serial port hardware (the chip).Whereas
setserial
only deals with actual serial ports, stty isused both for serial ports and for virtual terminals such as the standardLinux text interface on a PC monitor. For the PC monitor, many of thestty settings are meaningless. Changing the baud rate, etc. doesn'tappear to actually do anything.Here are some of the items stty configures: speed (bits/sec), parity,bits/byte, # of stop bits, strip 8th bit?, modem control signals, flowcontrol, break signal, end-of-line markers, change case, padding, beepif buffer overrun?, echo what you type to the screen, allow backgroundtasks to write to terminal?, define special (control) characters (suchas what key to press for interrupt). See the
stty
man or infopage for more details. Also see the man page: termios
whichcovers the same options set by stty but (as of mid 1999) coversfeatures which the stty man page fails to mention.With some implementations of getty (getty_ps package), the commandsthat one would normally give to stty are typed into a gettyconfiguration file: /etc/gettydefs. Even without this configurationfile, the getty command line may be sufficient to set things up sothat 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 betterunderstand the use of the stty command (and its many possiblearguments). Serial-Programming-HOWTO may be useful but it's outdated.The manual page: termios contains a description of the C-languagestructure (of type termios) which stores the stty configuration incomputer memory. Many of the flag names in this C-structure arealmost the same (and do the same thing) as the arguments to the sttycommand.
Flow control options
To set hardware flow control use 'crtscts'. For software flowcontrol there are 3 settings: ixon, ixoff, and ixany.
ixany: Mainly for terminals. Hitting any key will restart the flowafter a flow-control stop. If you stop scrolling with the 'stopscroll' key (or the like) then hitting any key will resume scrolling.It's seldom needed since hitting the 'scroll lock' key again will dothe same thing.
ixon: Enables the port to listen for Xoff and to stop transmittingwhen it gets an Xoff. Likewise, it will resume transmitting if it getsan Xon.
ixoff: enables the port to send the Xoff signal out the transmit linewhen its buffers in main memory are nearly full. It protects thedevice where the port is located from being overrun.
For a slow dumb terminal (or other slow device) connected to a fastPC, it's unlikely that the PC's port will be overrun. So you seldomactually need to enable ixoff. But it's often enabled 'just in case'.
Using stty at a 'foreign' terminal
How do you use stty to view or set a terminal other than theterminal you are currently using? It's usually impossible to do it ifthe foreign terminal is in use and has a shell running on it. Inother cases for dealing with say ttyS2 while typing at anotherterminal (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).But if the foreign terminal (ttyS2 in this example) has a shellrunning on it, then what you see will likely be deceptive and tryingto set it will not work. This problem exists for virtual terminalsalso such as dealing with tty3 from tty1, etc. See Two interfaces at a terminal tounderstand it.
Two interfaces at a terminal
When using a shell (such as bash) with command-line-editingenabled there are two different terminal interfaces (what you see whenyou type stty -a). When you type in modern shells at the command lineyou have a temporary 'raw' interface (or raw mode) where eachcharacter is read by the command-line-editor as you type it. Once youhit the <return> key, the command-line-editor is exited and theterminal interface is changed to the nominal 'cooked' interface(cooked mode) for the terminal. This cooked mode lasts until the nextprompt is sent to the terminal (which is only a small fraction of asecond). Note that one never gets to type any command in this cookedmode but what was typed in raw mode on the command line gets read bythe 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 such as vim.The prompt signals starting the command-line editor. The settings forthe 'raw' mode are based only on the basic stty settings taken from the'cooked' mode. Raw mode keeps these setting but changes several othersettings in order to change the mode to 'raw'. It is not at all basedon the settings used in the previous 'raw' mode. Thus if one usesstty to change settings for the raw mode, such settings will bepermanently lost as soon as one hits the <return> key at theterminal that has supposedly been 'set'.
Now when one types stty to look at the terminal interface, one mayeither get a view of the cooked mode or the raw mode. You need tofigure out which one you're looking at. It you use stty from aforeign terminal (other than the terminal you are currently typingat) then you will see the raw mode settings. Any changes made willonly be made to the raw mode and will be lost when someone presses<return> at the foreign terminal you tried to 'set'. But if youtype a stty command to view/change the configuration of the terminalyou are using, and then hit <return> it's a different story.The <return> puts the terminal in cooked mode. Your changes aresaved and will still be there when the terminal goes back into rawmode (unless of course it's a setting not allowed in raw mode).
This situation can create problems. For example, suppose you corruptyour terminal interface. To restore it you go to another terminal and'stty -F dev/ttyS1 sane' (or the like). It will not work! Of courseyou can try to type 'stty sane ...' at the terminal that is corruptedbut you can't see what you typed. All the above not only applies todumb terminals but to virtual terminals used on a PC Monitor as wellas to the terminal windows in X. In other words, it applies to almosteveryone who uses Linux.
Luckily, when you start up Linux, any file that runs stty at boot-timewill likely deal with a terminal (or serial port with no terminal)that has no shell running on it so there's no problem for this specialcase.
Where to put the stty command ?
Should you need to have
stty
set up the serial interface eachtime the computer starts up then you need to put the stty
commandin a file that will be executed each time the computer is started up(Linux boots). It should be run before the serial port is used(including running getty on the port). There are many possible placesto put it. If it gets put in more than one place and you only knowabout (or remember) one of those places, then a conflict is likely.So make sure to document what you do.One place to put it would be in the same file that runs setserial whenthe system is booted. The location is distribution and versiondependent. It would seem best to put it after the setserial commandso that the low level stuff is done first. If you have directories inthe /etc tree where every file in them is executed at boot-time(System V Init) then you could create a file named 'stty' for thispurpose.
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 usestty 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 tostty. This gives the stty program a link to the 'file' ttyS2 so thatit may 'read' it. But instead of reading the bytes sent to ttyS2 asone might expect, it uses the link to find the configuration settingsof the port so that it may read or change them. In olden days, somepeople tried to use ``stty ... > /dev/ttyS2' to set the terminal.This didn't work. Instead, it takes the message normal displayedby the stty command for the terminal you are on (say tty1) and sendsthis message to ttyS2. But it doesn't change any settings for ttyS2.
Here's a problem with the old redirection operator (which doesn'thappen if you use the newer -F option instead). Sometimes when tryingto use stty, the command hangs and nothing happens (you don't get aprompt for a next command even after hitting <return>). This islikely due to the port being stuck because it's waiting for one of themodem control lines to be asserted. For example, unless you've set'clocal' to ignore modem control lines, then if no CD signal isasserted the port will not open and stty will not work for it (unlessyou use the newer -F option). A similar situation seems to exist forhardware flow control. If the cable for the port doesn't even have aconductor for the pin that needs to be asserted then there is no easyway to stop the hang.
One way to try to get out of the above hang is to use the newer -Foption and set 'clocal' and/or 'crtscts' as needed. If you don't havethe -F option then you may try to run some program (such as minicom) onthe port that will force it to operate even if the control lines saynot to. Then hopefully this program might set the port so it doesn'tneed the control signal in the future in order to open: clocal or-crtscts. To use 'minicom' to do this you likely will have toreconfigure minicom and then exit it and restart it. Instead of allthis bother, it may be simpler to just reboot the PC or via using avirtual terminal kill the process using 'top' (or 'ps' to get theprocess number and then 'kill' to kill that process.
The obsolete redirection method (which still works in later versions)is to type ``stty ... < /dev/ttyS2'. If the new method using -Fworks but the obsolete one hangs, it implies that the port is hung dueto a modem control line not being asserted. Thus the obsoleteredirection method might still useful for troubleshooting.
isapnp
is a program to configure Plug-and-Play (PnP) deviceson the ISA bus including internal modems. It comes in a packagecalled 'isapnptools' and includes another program, 'pnpdump' whichfinds all your ISA PnP devices and shows you options for configuringthem in a format which may be added to the PnP configuration file:/etc/isapnp.conf. The isapnp command may be put into a startup fileso that it runs each time you start the computer and thus willconfigure ISA PnP devices. It is able to do this even if your BIOSdoesn't support PnP. See Plug-and-Play-HOWTO.This is where you run a serial cable (crossover type = null-modemtype) between the serial ports of two PCs. Then how do you use thisline? One way is for one PC to run login on the serial line and forthe other PC to run say minicom or picocom to emulate a terminal. SeeText-Terminal-HOWTO. There is no network protocol used in this caseand no error detection.
The other method is to run a network protocol on the line. Forexample, to use PPP in combination with TCP/IP see Serial LaplinkHOWTO. Although this HOWTO doesn't mention the old program 'slattach'(serial line attach) it can put the serial line into a networking modeusing the protocol you select. Protocols for slattach include PPP orSLIP (an older protocol widely used prior to PPP).
The Debian package, net-tools, contains slattach. SLIP is provided asa kernel module or can be built into the kernel (2.2, 2.4, or 2.6).
ser2net is a Linux program which will connect a network to theserial port. For example, someone connects to your PC via an ethernetport or fast modem using say telnet. Then (without ser2net) theycould remotely login to your PC and then run programs on your PC thatutilize a serial port on the PC. However, it might be better if theydidn't need to login and use your software, but instead couldimmediately connect to the serial port. ser2net running on your PCcan make this happen.
It could be like a bridge between the ethernet cable and the serialcable. The ethernet cable would have TCP/IP protocol on it but theserial port would just have the raw data taken out of the TCP/IPpackets. Optionally, you could use TCP/IP packets on the serial linetoo. Since an ethernet port has high bandwidth, it could communicatewith several serial ports at the same time and also have data flowingelsewhere as well.
To set up ser2net, you must specify which network ports (on theethernet) will connect to which serial ports. Then when networkpackets arrive at your PC over ethernet which are addressed to anetwork port you've tied to a serial port, the data in those packetsflows to the serial port. And conversely. Of course the networkdoesn't have to be ethernet. It could be a cable modem or DSL line,etc.
By 'speed' we really mean the 'data flow rate' but almost everybodyincorrectly calls it speed. The speed is measured in bits/sec (orbaud). Speed is set using the 'stty' command or by a program whichuses the serial port. See Stty
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 of230.4k and 460.8k. Some also support 921.6k. Unfortunately Linuxseldom uses these speeds due to lack of drivers. Thus such portsbehave just like 115.2k ports unless the higher speeds are enabled byspecial software. To get these speeds you need to compile the kernelwith special patches or use modules until support is built into thekernel's serial driver.
Unfortunately serial port manufacturers never got together on astandard way to support high speeds, so the serial driver needs tosupport a variety of hardware. Once high speed is enabled, a standardway to choose it is to set baud_base to the highest speed withsetserial (unless the serial driver does this for you). The softwarewill then use a divisor of 1 to set the highest speed. All this will hopefully be supported by the Linux kernel sometime in 2003.
A driver for the w83627hf chip (used on many motherboards such as the Tyan S2460) is at https://www.muru.com/linux/w83627hf/
A non-standard way that some manufacturers have implemented high speedis to use a very large number for the divisor to get the high speed.This number isn't really a divisor at all since it doesn't divideanything. It's just serves as a code number to tell the hardware whatspeed to use. In such cases you need to compile the kernel withspecial patches.
One patch to support this second type of high-speed hardware is calledshsmod (Super High Speed Mode). There are both Windows and Linuxversions of this patch. See http://www.devdrv.com/shsmod/. There is also a module for theVIA VT82C686 chip http://www.kati.fi/viahss/. Using itmay result in buffer overflow.
For internal modems, only a minority of them advertise that theysupport speeds of over 115.2k for their built-in serial ports.Does shsmod support these ??
How speed is set in hardware: the divisor and baud_base
Speed is set by having the serial port's clock change frequency.But this change happens not by actually changing the frequency of theoscillator driving the clock but by 'dividing' the clock's frequency.For example, to divide by two, just ignore every other clock tick.This cuts the speed in half. Dividing by 3 makes the clock run at 1/3frequency, etc. So to slow the clock down (meaning set speed), wejust send the clock a divisor. It's sent by the serial driver to aregister in the port. Thus speed is set by a divisor.
If the clock runs at a top speed of 115,000 bps (common), then hereare the divisors for various speeds (assuming a maximum speed of115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24(4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speedin the hardware by sending the hardware only a 'divisor' (a positiveinteger). This 'divisor' divides the 'maximum speed' of the hardwareresulting in a slower speed (except a divisor of 1 obviously tells thehardware to run at maximum speed).
There are exceptions to the above since for certain serial porthardware, speeds above 115.2k are set by using a very high divisor.Keep that exception in mind as you read the rest of this section.Normally, if you specify a speed of 115.2k (in your communicationprogram or by stty) then the serial driver sets the port hardware todivisor 1 which sets the highest speed.
Besides using a very high divisor to set high speed, the conventionalway to do it is as follows: If you happen to have hardware with amaximum speed of say 230.4k (and the 230.4k speed has been enabled inthe hardware), then specifying 115.2k will result in divisor 1. Forsome hardware this will actually give you 230.4k. This is double thespeed that you set. In fact, for any speed you set, the actual speedwill be double. If you had hardware that could run at 460.8k then theactual speed would be quadruple what you set. All the above assumesthat you don't use 'setserial' to modify things.
Setting the divisor, speed accounting
To correct this accounting (but not always fix the problem) youmay use 'setserial' to change the baud_base to the actual maximalspeed of your port such as 230.4k. Then if you set the speed (by yourapplication or by stty) to 230.4k, a divisor of 1 will be used andyou'll get the same speed as you set.
If you have very old software which will not allow you to tell it sucha high speed (but your hardware has it enabled) then you might want tolook into using the 'spd_cust' parameter. This allows you to tell theapplication that the speed is 38,400 but the actual speed for thiscase is determined by the value of 'divisor' which has also been setin setserial. I think it best to try to avoid using this kludge.
There are some brands of UARTs that uses a very high divisor to sethigh speeds. There isn't any satisfactory way to use 'setserial' (sayset 'divisor 32770') to get such a speed since then setserial wouldthen think that the speed is very low and disable the FIFO in theUART.
Crystal frequency is higher than baud_base
Note that the baud_base setting is usually much lower than thefrequency of the crystal oscillator since the crystal frequency of say1.8432 MHz is divided by 16 in the hardware to get the actual topspeed of 115.2k. The reason the crystal frequency needs to be higheris so that this high crystal speed can generate clock ticks to take anumber of samples of each bit to determine if it's a 1 or a 0.
Actually, the 1.8432 MHz 'crystal frequency' may be obtained from a18.432 MHz crystal oscillator by dividing by 10 before being fed tothe UART. Other schemes are also possible as long as the UARTperforms properly.
If you are seeing slow throughput and serial port overruns on asystem with (E)IDE disk drives, you can get
hdparm
. Thisis a utility that can modify (E)IDE parameters, including unmaskingother IRQs during a disk IRQ. This will improve responsivenessand will help eliminate overruns. Be sure to read the man page verycarefully, since some drive/controller combinations don't like thisand may corrupt the filesystem.Also have a look at a utility called
irqtune
that will changethe IRQ priority of a device, for example the serial port that yourmodem is on. This may improve the serial throughput on your system.The irqtune
FAQ is at http://www.best.com/~cae/irqtune When you are using a serial port, you may want to prevent othersfrom using it at the same time. However there may be cases where youdo want others to use it, such as sending you an important message ifyou are using a text-terminal.
There are various ways of preventing others (or other processes) fromusing your serial port when you are using it (locking). This shouldall happen automatically but it's important to know about this if itgives you trouble. If a program is abnormally exited or the PCis abruptly turned off (by pulling the plug, etc.) your serial portmight wind up locked. Even if the lock remains, it's usuallyautomatically removed when you want to use the serial port again.But in rare cases it isn't. That's when you need to understand whathappened.
One way to implement locking is to design the kernel to handle it butLinux thus far has shunned this solution (with an exception involvingthe cua device which is now obsolete). Two solutions used by Linuxis to:
- create lock-files
- modify the permissions and/or owners of devices such as /dev/ttyS2
If you use the new device-filesystem (devfs) then see the nextsection. A lock-file is simply a file created to mean that aparticular device is in use. They are kept in
/var/lock
.Formerly they were in /usr/spool/uucp
. Linux lock-files areusually named LCK..
name, where name may be a devicename, a process id number, a device's major and minor numbers, or aUUCP site name. Most processes (an exception is getty) create theselocks so that they can have exclusive access to devices. For instanceif you dial out on your modem, some lockfiles will appear to tellother processes that someone else is using the modem. In olderversions (in the 1990s) there was usually only one lockfile perprocess. Lock files contain the PID of the process that has lockedthe device. Note that if a process insists on using a device that islocked, it may ignore the lockfile and use the device anyway. This isuseful in sending a message to a text-terminal, etc.When a program wants to use a serial port but finds it locked withlock-files it should check to see if the lock-file's PID is still inuse. If it's not it means that the lock is stale and it's OK to goahead and use the port anyway (after removing the stale lock-files).Unfortunately, there may be some programs that don't do this and giveup by telling you that a device is already in use when it really isn't.
If the lockfile only uses device names, the following problem couldarise: If the same device has two different names then two differentprocesses could each use a different name for the same device. Thisresults in lockfiles with different names that actually are the samedevice. Formerly each physical serial port was known by two differentdevice names: ttyS0 and cua0. To solve this lockfile alias problem, 3methods have been used. It may be overkill since any one of thesemethods would have fixed the problem.
- The lock checking software was made aware of ttyS vs. cua.
- The device cua was deprecated
- Additional locks were created which use unique device numbersinstead of names.
Using alternate names such as /dev/modem for /dev/ttyS2 may causeproblems if one program opens /dev/ttyS2 while another program opens/dev/modem. This problem was supposedly fixed around 2000, but isstill present in 2005. For dumb terminals, lockfiles are not usedsince this would not permit someone else to send a message to yourterminal using the write or talk program.
In order to use a device, you (or the program you run if you have'set user id') needs to have permission to read and write the device'file' in the /dev directory. So a logical way to prevent others fromusing a device is to make yourself the temporary owner of the deviceand set permissions so that no one else can use it. A program may dothis for you. A similar method can be used with the group of thedevice file.
While lock files prevent other process from using the device, changingdevice file owners/permissions restricts other users (or the group)from using it. One case is where the group is permitted to write tothe port, but not to read from it. Writing to the port might justmean a message sent to a text-terminal while reading means destructivereading. The original process that needs to read the data may finddata missing if another process has already read that data. Thus aread can do more harm that a write since a read causes loss of datawhile a write only adds extra data. That's a reason to allow writesbut not reads. This is exactly the opposite of the case for ordinaryfiles where you allow others to read the file but not write (modify)it. Use of a port normally requires both read and write permissions.
A program that changes the device file attributes should undo thesechanges when it exits. But if the exit is abnormal, then a devicefile may be left in such a condition that it gives the error'permission denied' when one attempts to use it again.
Here is a list of some communication software you can choose from,available via FTP, if they didn't come with your Linux distribution.
ecu
- a communications program- C-Kermit -portable, scriptable, serial and TCP/IP communications including filetransfer, character-set translation, and zmodem support
gkermit
Tiny GPLed kermit run only from the command line.Can't connect to another computergtkterm
- a simple gtk terminal, X-basedminicom
- telix-like communications programpicocom
- like a small minicom but no automatic phone dialingpppd
- establishes a ppp connection on the serial lineseyon
- X based communication programxc
- xcomm communication packageterm
andSLiRP
offer TCP/IP functionality using ashell account.screen
is another multi-session program. This one behaveslike the virtual consoles.callback
is where you dial out to a remote modem and thenthat modem hangs up and calls you back (to save on phone bills).mgetty+fax
handles FAX stuff, and provides an alternateps_getty
.ZyXEL
is a control program for ZyXEL U-1496 modems. Ithandles dialin, dialout, dial back security, FAXing, and voicemailbox functions.- SLIP and PPP software (if not in your Linux distribution) can befound at
ftp://metalab.unc.edu/pub/Linux/system/network/serial
.
For use of kermit with modems see the Modem-HOWTO. One can runzmodem within the kermit program. To do this (for ttyS3), add thefollowing to your
Be sure to put in the correct port your modem is on. Then, to use it,just type .kermrc
file:rz
or sz <filename>
at the kermit
prompt. Often the serial driver is provided as a module(s) such asgeneric_serial.ko. Drivers for USB serial ports and multiport cardsare often provided as modules. Linux should automatically load anyneeded module, so in most cases you have nothing to do.
But sometimes you need to configure Linux to load certain modules orgives parameters to the module or to the kernel.
Such parameters may be supplied to certain modules on the command linefor the kernel or in /etc/modules, /etc/modules.conf or/etc/modprobe.conf. Since kernel 2.2 you don't edit the modprobe.conffile but use the program update-modules to change it. The info thatis used to update modules.conf is put in /etc/modutils/.
The Debian/GNU Linux has a file named /etc/modutils/setserial whichruns the serial script in /etc/init.d/ every time the serial module isloaded or unloaded. When the serial module is unloaded this scriptwill save the state of the module in /var/run/setserial.conf. Then ifthe module loads again this saved state is restored. When the serialmodule 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. Otherdistributions may do something similar.
Serial modules are found in subdirectories of
/lib/modules/.../kernel/drivers/
. For multiport cards, lookin the serial
subdirectory and/or char
. For USB serial,look in the usb/serial
subdirectory. The module,parport_serial is for PCI cards that contain both serial and parallelports. As a last resort, one may modify the serial driver by editing thesource code. Much of the serial driver is found in the file serial.c.For info regarding writing of programs for the serial port seeSerial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie butthat revision is not at LDP.
If you have more than 4 (or possibly 2) serial ports, then you mustinsure that the kernel knows this. It can be done by configuring thekernel when compiling or by a parameter given to the kernel when itstarts (boot-prompt or kernel command line).
The kernel configuration parameters:CONFIG_SERIAL_8250_RUNTIME_UARTS=4 and CONFIG_SERIAL_8250_NR_UARTS=4set the maximum number of ordinary serial ports (UARTs) equal to 4.If you have more than 4 ordinary serial ports, then you need to changethe 4 to whatever. But you may override this via the kernel commandline for example: nr_uarts=16 (if serial support built into thekernel) or 8250.nr_uarts=16 (if serial support is via a module). Theboot loader such as lilo or grub can be told to do this.
See the kernel documentation in: Documentation/serial-console.txt.Kernel 2.4+ has better documentation. See also 'Serial Console' inText-Terminal-HOWTO.
For a text terminal, the RS-232 speeds are fast enough but theusable cable length is often too short. Balanced technology couldfix this. The common method of obtaining balanced communication witha text terminal is to install 2 line drivers in the serial line toconvert unbalanced to balanced (and conversely). They are aspecialty item and are expensive if purchased new.
Normally flow control and/or application programs stop the flow ofbytes when its needed. But sometimes they don't. The problem is thatoutput to the serial port first passes thru the large serial bufferin the PC's main memory. So if you want to abort printing, whatever isin this buffer should be removed. When you tell an application programto stop printing, it may not empty this buffer so printing continuesuntil it's empty. In addition, your printer has it's own buffer whichneeds to be cleared. So telling the PC to stop printing may not workdue to these two buffers that continue to supply bytes for the printer.It's a problem with printer software not knowing about the serial portand that modem control lines need to be dropped to stop the printer.
One way to insure that printing stops is to just turn off the printer.With newer serial drivers, this works OK. The buffers are cleared andprinting doesn't resume. With older serial drivers, the PC's serialbuffer didn't clear and it would sometimes continue to print when theprinter was turned back on. To avoid this, you must wait a timespecified by setserial's closing_wait before turning the printer backon again. You may also need to remove the print job from the printqueue so it won't try to resume.
Avoiding IO Address Conflicts with Certain Video Boards
The IO address of the IBM 8514 video board (and others) isallegedly 0x?2e8 where ? is 2, 4, 8, or 9. This may conflict (butshouldn't if the serial port is well designed) with the IO address of
ttyS3
at 0x02e8 if the serial port ignores the leading 0 hexdigit when it decodes the address (many do). That is bad news if youtry to use ttyS3
at this IO address. Another story is that Linuxwill not detect your internal modem on ttyS3
but that you can usesetserial
to put ttyS3
at this address and the modemwill work fine.IO address conflict with ide2 hard drive
The address of ttyS2 is 3e8-3ef while hard drive ide2 uses 3eewhich is in this range. So when booting Linux you may see a reportof this conflict. Most people don't use ide2 (the 3rd hard drivecable) and may ignore this conflict message. You may have 2 harddrives on ide0 and two more on ide1 so most people don't need ide2.
Problem with AMD Elan SC400 CPU (PC-on-a-chip)
This has a race condition between an interrupt and a status registerof the UART. An interrupt is issued when the UART transmitterfinishes the transmission of a byte and the UART transmit bufferbecomes empty (waiting for the next byte). But a status register ofthe UART doesn't get updated fast enough to reflect this. As aresult, the interrupt service routine rapidly checks and determines(erroneously) that nothing has happened. Thus no byte is sent to theport to be transmitted and the UART transmitter waits in vain for abyte that never arrives. If the interrupt service routine had waitedjust a bit longer before checking the status register, then it wouldhave been updated to reflect the true state and all would be OK.
There is a proposal to fix this by patching the serial driver. ButShould linux be patched to accommodate defective hardware, especiallyif this patch may impair performance of good hardware?
See Modem-HOWTO for troubleshooting related to modems or getty formodems. For a Text-Terminal much of the info here will be of value aswell as the troubleshooting info in Text-Terminal-HOWTO.
Breakout Gadgets, etc.
While a multimeter (used as a voltmeter) may be all that you needfor just a few serial ports, simple special test equipment has beenmade for testing serial port lines. Some are called 'breakout ... 'where breakout means to break out conductors from a cable. Thesegadgets have a couple of connectors which connect to serial portconnectors (either at the ends of serial cables or at the back of aPC). Some have test points for connecting a voltmeter. Others haveLED lamps which light when certain modem control lines are asserted(turned on). The color of the light may indicate the polarity of thesignal (positive or negative voltage). Still others have jumpers sothat you can connect any wire to any wire. Some have switches.
Radio Shack sells (in 2002) a 'RS-232 Troubleshooter' (formerly called'RS-232 Line Tester') Cat. #276-1401. It checks TD, RD, CD, RTS, CTS,DTR, and DSR. A green light means on (+12 v) while red means off (-12v). They also sell a 'RS-232 Serial Jumper Box' Cat.#276-1403. This permits connecting the pins anyway you choose. Boththese items are under the heading of 'Peripheral hookup helpers'.Unfortunately, they are not listed in the index to the printedcatalog. They are on the same page as the D type connecters so lookin the index under 'Connectors, Computer, D-Sub'. A store chain named'Active Components' may have them.
Measuring voltages
Any voltmeter or multimeter, even the cheapest that sells forabout $10, should work fine. Trying to use other methods for checkingvoltage is tricky. Don't use a LED unless it has a series resistor toreduce the voltage across the LED. A 470 ohm resistor is used for a20 ma LED (but not all LED's are 20 ma). The LED will only light fora certain polarity so you may test for + or - voltages. Does anyonemake such a gadget for automotive circuit testing?? Logic probes maybe damaged if you try to use them since the TTL voltages for whichthey are designed are only 5 volts. Trying to use a 12 V incandescentlight bulb is not a good idea. It won't show polarity and due tolimited 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 paperclip into the desired opening. The paper clip's diameter should be nolarger than the pins so that it doesn't damage the contact. Clipan alligator clip (or the like) to the paper clip to connect up. Takecare not to touch two pins at the same time with any metal object.
Taste voltage
As a last resort, if you have no test equipment and are willing torisk getting shocked (or even electrocuted) you can always taste thevoltage. Before touching one of the test leads with your tongue, testthem to make sure that there is no high voltage on them. Touch bothleads (at the same time) to one hand to see if they shock you. Thenif no shock, wet the skin contact points by licking and repeat. Ifthis test gives you a shock, you certainly don't want to use yourtongue.
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 ispositive, there will be a noticeable taste. You might try this withflashlight batteries first so you will know what taste to expect.
A few Linux programs will monitor the modem control lines andindicate if they are positive (1) or negative (0). See section Serial Monitoring/Diagnostics
There are 3 possibilities:
- Your port is disabled since both the BIOS and Linux failed toenable it. It has no IO address.
- Your port is enabled and has an IO address but it has no ttySdevice number (like ttyS14) assigned to that address so the portcan't be used. As a last resort, you may need to use 'setserial' toassign 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 yourPC).See Which Connector on the Back of my PC is ttyS1, etc?
First check BIOS messages at boot-time (and possibly the BIOS menu forthe serial port). Then for the PCI bus type lspci -v. If this showssomething like 'LPC Bridge' then your port is likely on the LPC buswhich 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 enabledthen 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 notPlug-and-Play.
Using 'scanport' (Debian only ??) will scan all enabled bus ports andmay discover an unknown port that could be a serial port (but itdoesn't probe the port). It could hang your PC. If you suspect thatyour port may be at a certain address, you may try manually probingwith setserial, but it's a slow tedious task if you have severaladdresses to probe. See Probing.
If your PC has a BIOS that handles ISA (and likely PCI too) thenif you find a IRQ conflict, it might be due to a shortage of freeIRQs. The BIOS often maintains a list of reserved IRQs, reserved forlegacy ISA cards. If too many are reserved, the BIOS may not be ableto find a free IRQ and will erroneously assign an IRQ to the serialport that creates a conflict. So check to see if all the reservedIRQs are really needed and if not, unreserve an IRQ that the serialport can use. For more details, see Plug-and-Play-HOWTO.
It's likely mis-set/conflicting interrupts. Here are some of thesymptoms which will happen the first time you try to use a modem,terminal, or serial printer. In some cases you type something butnothing appears on the screen until many seconds later. Only the lastcharacter typed may show up. It may be just an invisible<return> character so all you notice is that the cursor jumpsdown one line. In other cases where a lot of data should appear onthe screen, only a batch of about 16 characters appear. Then there isa long wait of many seconds for the next batch of characters. Youmight also get 'input overrun' error messages (or find them in logs).
For more details on the symptoms and why thishappens see Interrupt Problem Details and/or Interrupt Conflictsand/or Mis-set Interrupts. If it involves Plug-and-Play devices, see also the Plug-and-Play-HOWTO.
As a quick check to see if it really is an interrupt problem, set theIRQ to 0 with 'setserial'. This will tell the driver to usepolling instead of interrupts. If this seems to fix the 'slow'problem then you had an interrupt problem. You should still try tosolve the problem since polling uses excessive computer resources.
Checking to find the interrupt conflict may not be easy since Linuxsupposedly doesn't permit any interrupt conflicts and will send you a/dev/ttyS?: Device or resource busy errormessage if it thinks you are attempting to create a conflict. But areal conflict can be created if 'setserial' has told the kernelincorrect info. The kernel has been lied to and thus doesn't thinkthere is any conflict. Thus using 'setserial' will not reveal theconflict (nor will looking at /proc/interrupts which bases its info on'setserial'). You still need to know what 'setserial' thinks so thatyou can pinpoint where it's wrong and change it when you determinewhat's really set in the hardware.
What you need to do is to check how the hardware is set by checkingjumpers or using PnP software to check how the hardware is actuallyset. For PnP run either 'pnpdump --dumpregs' (if ISA bus) or run'lspci' (if PCI bus). Compare this to how Linux (e.g. 'setserial')thinks the hardware is set.
An obvious reason is that the baud rate is set too slow. It'sclaimed that this once happened by trying to set the baud rate to aspeed higher than the hardware can support (such as 230400).
Another reason may be that whatever is on the serial port (such as amodem, terminal, printer) doesn't work as fast as you thought it did.
Another possible reason is that you have an obsolete serial port: UART8250, 16450 or early 16550 (or the serial driver thinks you do). See
What Are UARTS? Use 'setserial -g /dev/ttyS*'.If it shows anything less than a 16550A, this may be your problem.If you think that 'setserial' has it wrong check it out. See What is Setserial for more info. If youreally do have an obsolete serial port, lying about it to setserialwill only make things worse.
For non-PnP ports, Linux does not do any IRQ detection on startup.When the serial module loads it only does serial device detection.Thus, disregard what it says about the IRQ, because it's just assumingthe standard IRQs. This is done, because IRQ detection is unreliable,and can be fooled. But if and when setserial runs from a start-upscript, it changes the IRQ's and displays the new (and hopefullycorrect) state on on the startup screen. If the wrong IRQ is notcorrected by a later display on the screen, then you've got a problem.
So, even though I have my
at first when Linux boots. (Older kernels may show 'ttyS02' as'tty02' which is the same as ttyS2). You may need to usettyS2
set at IRQ 5, I still seesetserial
to tell Linux the IRQ you are using. See /dev/tty? Device or resource busy
Check the file permissions on this port with 'ls -l /dev/ttyS?'_If you own the ttyS? then you need read and write permissions: crwwith the c (Character device) in col. 1. It you don't own it then itwill work for you if it shows rw- in cols. 8 & 9 which means thateveryone has read and write permission on it. Use 'chmod' to changepermissions. There are more complicated (and secure) ways to getaccess like belonging to a 'group' that has group permission. Someprograms change the permissions when they run but restore them whenthe program exists normally. But if someone pulls the plug on yourPC it's an abnormal exit and correct permissions may not be restored.
Unless stty is set for clocal, the CD pin may need to be assertedin order to open a serial port. If the physical port is not connectedto anything, or if it's connected to something that is not powered on(such an external modem) then there will be no voltage on CDfrom that device. Thus the 'cannot open' message. Either set clocalor connect the serial port connector to something and power it on.
Even if a device is powered on and connected to a port, it maysometimes prevent opening the port. An example of this is where thedevice has negated CD and the CD pin on your PC is negated (negativevoltage).
This means that an operation requested by setserial, stty, etc.couldn't be done because the kernel doesn't support doing it.Formerly this was often due to the 'serial' module not being loaded.But with the advent of PnP, it may likely mean that there is no modem(or other serial device) at the address where the driver (andsetserial) thinks it is. If there is no modem there, commands (foroperations) sent to that address obviously don't get done. See What is set in my serial port hardware?
If the 'serial' module wasn't loaded but 'lsmod' shows you it's nowloaded it might be the case that it's loaded now but wasn't loadedwhen you got the error message. In many cases the module willautomatically loaded when needed (if it can be found). To forceloading of the 'serial' module it may be listed in the file:/etc/modules.conf or /etc/modules. The actual module should residein: /lib/modules/.../misc/serial.o.
Sometimes when it can't create a lockfile you get the erroneousmessage: '... Device or resource busy' instead of the one above.When a port is 'opened' by a program a lockfile is created in/var/lock/. Wrong permissions for the lock directory will not allow alockfile to be created there. Use 'ls -ld /var/lock' to see if thepermissions are OK. Giving rwx permissions for the root owner and thegroup should work, provided that the users that need to dialout belongto that group. Others should have r-x permission. Even with thisscheme, there may be a security risk. Use 'chmod' to changepermissions and 'chgrp' to change groups. Of course, if there is no'lock' directory no lockfile can be created there. For more info onlockfiles see What Are Lock Files
This means that someone else (or some other process) is supposedlyusing the serial port. There are various ways to try to find out whatprocess is 'using' it. One way is to look at the contents of thelockfile (/var/lock/LCK...). It should be the process id. If theprocess id is say 100 type 'ps 100' to find out what it is. Then ifthe process is no longer needed, it may be gracefully killed by 'kill100'. If it refuses to be killed use 'kill -9 100' to force it to bekilled, but then the lockfile will not be removed and you'll need todelete it manually. Of course if there is no such process as 100 thenyou may just remove the lockfile but in most cases the lockfile shouldhave been automatically removed if it contained a stale process id(such as 100).
This means that the device you are trying to access (or use) issupposedly busy (in use) or that a resource it needs (such as an IRQ)is supposedly being used by another device and can't be shared.This message is easy to understand if it only means that the device isbusy (in use). But it sometimes means that a needed resource is alreadyin use (busy). What makes it even more confusing is that in some casesneither the device nor the resources that it needs are actually'busy'.
In olden days, if a PC was shutdown by just turning off the power, abogus lockfile might remain and then later on one would get this bogusmessage and not be able to use the serial port. Software today issupposed to automatically remove such bogus lockfiles, but as of 2006there is still a problem with the 'wvdial' dialer program related tolockfiles. If wvdial can't create a lockfile because it doesn't havewrite permission in the /var/lock/ directory, you will see thiserroneous message. See Cannot create lockfile. Sorry
The following example is where interrupts can't be shared (at leastone of the interrupts is on the ISA bus). The ``resource busy' partoften means (example for
ttyS2
) ``You can't use ttyS2
sinceanother device is using ttyS2's interrupt.' The potential interruptconflict is inferred from what 'setserial' thinks. A more accurateerror message would be ``Can't use ttyS2
since the setserial data(and kernel data) indicates that another device is using ttyS2
'sinterrupt'. If two devices use the same IRQ and you start up onlyone of the devices, everything is OK because there is no conflict yet.But when you next try to start the second device (without quitting thefirst device) you get a '... busy' error message. This is because thekernel only keeps track of what IRQs are actually in use and actualconflicts don't happen unless the devices are in use (open). Thesituation for I/O address (such as 0x3f8) conflict is similar.This error is sometimes due to having two serial drivers: one a moduleand the other compiled into the kernel. Both drivers try to grab thesame resources and one driver finds them 'busy'.
There are two possible cases when you see this message:
- There may be a real resource conflict that is being avoided.
- Setserial has it wrong and the only reason
ttyS2
can't beused is that setserial erroneously predicts a conflict.
What you need to do is to find the interrupt setserial thinks
ttyS2
is using. Look at /proc/tty/driver/serial. You shouldalso be able to find it with the 'setserial' command for ttyS2
. Bug in old versions: Prior to 2001 there was a bug which wouldn't letyou see it with 'setserial'. Trying to see it would give the same'... busy' error message.
To try to resolve this problem reboot or: exit or gracefully kill alllikely conflicting processes. If you reboot: 1. Watch the boot-timemessages for the serial ports. 2. Hope that the file that runs'setserial' at boot-time doesn't (by itself) create the same conflictagain.
If you think you know what IRQ say
ttyS2
is using then you maylook at /proc/interrupts to find what else (besides another serialport) is currently using this IRQ. You might also want to doublecheck that any suspicious IRQs shown here (and by 'setserial') arecorrect (the same as set in the hardware). A way to test whether ornot it's a potential interrupt conflict is to set the IRQ to 0(polling) using 'setserial'. Then if the busy message goes away, itwas likely a potential interrupt conflict. It's not a good idea toleave it permanently set at 0 since it will put more load on the CPU. This means that communication with the serial port isn't workingright. It could mean that there isn't any serial port at the IOaddress that setserial thinks your port is at. It could also be aninterrupt conflict (or an IO address conflict). It also may mean thatthe serial port is in use (busy or opened) and thus the attempt toget/set parameters by setserial or stty failed. It will also happenif you make a typo in the serial port name such as typing 'ttys'instead of 'ttyS'.
LSR is the name of a hardware register. It usually means that there is no serial port at the address where the driver thinks yourserial port is located. You need to find your serial port andpossibly configure it. See Locating the Serial Port: IO address IRQs and/or What is Setserial
This is an overrun of the hardware FIFO buffer and you can'tincrease its size. Bug note (reported in 2002): Due to a bug in somekernel 2.4 versions, the port number may be missing and you will onlysee 'ttyS' (no port number). But if devfs notation such as 'tts/2'was being used, there was no bug. See Higher Serial Thruput.
There could be some other program running on the port. Use 'top'(provided you've set it to display the port number) or type 'ps-alxw'. Look at the results to see if the port is being used byanother program. Be on the lookout for the gpm mouse program whichoften runs on a serial port.
These are some of the programs you might want to use introubleshooting:
- 'lsof /dev/ttyS*' will list serial ports which are open.
- 'setserial' shows and sets the low-level hardware configurationof a port (what the driver thinks it is). See What is Setserial
- 'stty' shows and sets the configuration of a port (except forthat handled by 'setserial').See the section Stty
- 'modemstat' or 'statserial' or 'watch head/proc/tty/driver/serial' will show the current state of various modemsignal lines (such as DTR, CTS, etc.). The one in /proc also showsbyte flow and errors.
- 'irqtune' will give serial port interrupts higherpriority to improve performance.
- 'hdparm' for hard-disk tuning may help some more.
- 'lspci' shows the actual IRQs, etc. of hardware on the PCI bus.
- 'pnpdump --dumpregs' shows the actual IRQs, etc. of hardware forPnP devices on the ISA bus.
- Some 'files' in the /proc tree (such as ioports, interrupts,and tty/driver/serial).
Perhaps a baud mismatch. If one port sends at twice the speed thatthe other port is set to receive, then every two characters sent willbe received as one character. Each bit of this received characterwill be a sample of two bits of what is sent and will be wrong. Also,only half the characters sent seem to get received. For flow in thereverse direction, it's just the opposite. Twice as many charactersget received than were sent. A worse mismatch will produce even worseresults.
A speed mismatch is not likely to happen with a modem since the modemautodetects the speed. One cause of a mismatch may be due to serialport hardware that has been set to run at very fast speeds. It mayactually operate at a speed say 8 times that of which you (or anapplication) set it via software. See Very High Speeds
![Gcc Gcc](/uploads/1/2/6/2/126292861/804203533.jpeg)
While the section Troubleshootinglists problems by symptom, this section explains what will happen ifinterrupts are set incorrectly. This section helps you understand whatcaused the symptom, what other symptoms might be due to the sameproblem, and what to do about it.
The 'setserial' program will show you how serial driver thinks theinterrupts are set. If the serial driver (and setserial) has it rightthen everything regarding interrupts should be OK. Of course a/dev/ttyS must exist for the device and Plug-and-Play (or jumpers)must have set an address and IRQ in the hardware. Linux will notknowingly permit an interrupt conflict and you will get a 'Device orresource busy' error message if you attempt to do something that wouldcreate a conflict.
Since the kernel tries to avoid interrupt conflicts and gives you the'resource busy' message if you try to create a conflict, how caninterrupt conflicts happen? Easy. 'setserial' may have it wrong anderroneously predicts no conflict when there will actually be a realconflict based on what is set in the hardware. When this happensthere will be no '... busy' message but a conflict will physicallyhappen. Performance is likely to be extremely slow. Both deviceswill send identical interrupt signals on the same wire and the CPUwill erroneously think that the interrupts only come from one device.This will be explained in detail in the following sections.
Linux doesn't complain when you assign two devices the same IRQprovided that neither device is in use. As each device starts up(initializes), it asks Linux for permission to use its hardwareinterrupt. Linux keeps track of which interrupt is assigned to whom,and if your interrupt is already in use, you'll see this '... busy'error message. Thus if two devices use the same IRQ and you start uponly one of the devices, everything is OK. But when you next try tostart the second device (without quitting the first device) you get'... busy' error message.
The symptoms depend on whether or not you have a modern serial portwith FIFO buffers or an obsolete serial port without FIFO buffers.It's important to understand the symptoms for the obsolete ones alsosince sometimes modern ports seem to behave that way.
For the obsolete serial ports, only one character gets thru everyseveral seconds. This is so slow that it seems almost like nothing isworking (especially if the character that gets thru is invisible (sucha space or newline). For the modern ports with FIFO buffers youwill likely see bursts of up to 16 characters every several seconds.
If you have a modem on the port and dial a number, it seemingly maynot connect since the CONNECT message may not make it thru. But aftera long wait it may finally connect and you may see part of a loginmessage (or the like). The response from your side of the connectionmay be so delayed that the other side gives up and disconnects you,resulting in a NO CARRIER message.
If you use minicom, a common test to see if things are working is totype the simplest 'AT' command and see if the modem responds. Typingjust at<enter> should normally (if interrupts are OK) result inan immediate 'OK' response from the modem. With bad interrupts youtype at<enter> and may see nothing. But then after 10 secondsor so you see the cursor drop down one line. What is going on is thatthe FIFO is behaving like it can only hold one byte. The 'at' youtyped caused it to overrun and both letters were lost. But the final<enter> eventually got thru and you 'see' this invisiblecharacter by noticing that the cursor jumped down one line. If you wereto type a single letter and then wait about 10 seconds, you should seeit echo back to the screen. This is fine if your typing speed is lessthat one word per minute :-)
If you don't understand what an interrupt does see Interrupts. If a serial port has one IRQ setin the hardware but a different one set in the device driver, thedevice driver will not catch any interrupts sent by the serial port.Since the serial port uses interrupts to call its driver to servicethe port (fetching bytes from its 16-byte receive buffer or puttinganother 16-bytes in its transmit buffer) one might expect that theserial port would not work at all.
But it still may work anyway --sort of. Why? Well, besides theinterrupt method of servicing the port there's an undocumented slowpolling method that doesn't need interrupts. The way it works is thatevery so often the device driver checks the serial port to see if itneeds anything such as if it has some bytes that need fetching fromits receive buffer. If interrupts don't work, the serial driver fallsback to this polling method. But this polling method was not intendedto be used a substitute for interrupts. It's so slow that it's notpractical to use and may cause buffer overruns. Its purpose may havebeen to get things going again if just one interrupt is lost or failsto do the right thing. It's also useful in showing you thatinterrupts have failed. Don't confuse this slow polling method withthe fast polling method that operates on ports that have their IRQsset to 0.
For the 16-byte transmit buffer, 16 bytes will be transmitted and thenit will wait until the next polling takes place (several secondslater) before the next 16 bytes are sent out. Thus transmission isvery slow and in small chunks. Receiving is slow too since bytes thatare received by the receive buffer are likely to remain there forseveral 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 tothe modem. The modem then echos the AT back thru the serial port tothe screen. Thus the AT characters have to pass twice thru the serialport. Normally this happens so fast that AT seems to appear on thescreen at the same time you hit the keys on the keyboard. With slowpolling delays at the serial port, you don't see what you typeduntil perhaps 15 seconds later. Even then, you don't often see allyou typed but only the first several characters.
What about overruns of the 16-byte receive buffer? This will happenwith an external modem since the modem just sends to the serial portat high speed which is likely to overrun the 16-byte buffer. But foran internal modem, the serial port is on the same card and it's likelyto check that this 16-byte receive buffer has room for more bytesbefore putting received bytes into it. In this case there will be nooverrun of this receive buffer, but text will just appear on yourscreen in 16-byte chunks spaced at intervals of several seconds.
Even with an external modem you might not get overruns. If just a fewcharacters (under 16) are sent you don't get overruns since the bufferlikely has room for them. But attempts to send a larger number ofbytes from your modem to your screen may result in overruns. However,more than 16 (with no gaps) can get thru without overruns if thetiming is right. For example, suppose a burst of 32 bytes is sentinto the port from the external cable. The polling might just happenafter the first 16 bytes came in so it would pick up these 16 bytesOK. Then there would be space for the next 16 bytes so that entire 32bytes gets thru OK. While this scenario is not very likely, similarcases where 17 to 31 bytes make thru are more likely. But it's evenmore likely that only an occasional 16-byte chunk will get thru withpossible loss of data.
If you have an obsolete serial port with only a 1-byte buffer (or it'sbeen incorrectly set to work like a 1-byte buffer) then the situationwill be much worse than described above and only one character willoccasionally make it thru the port. Every character received causesan overrun (and is lost) except for the last character received. Thischaracter is likely to be just a line-feed since this is often thelast character to be transmitted in a burst of characters sent to yourscreen. Thus you may type AT<return> to the modem but never seeAT on the screen. All you see several seconds later is that thecursor drops down one line (a line feed). This has happened to mewith a 16-byte FIFO buffer that was behaving like a 1-byte buffer.
When a communication program starts up, it expects interrupts to beworking. It's not geared to using this slow polling-like mode ofoperation. Thus all sorts of mistakes may be made such as setting upthe serial port and/or modem incorrectly. It may fail to realize whena connection has been made. If a script is being used for login, itmay fail (caused by timeout) due to the polling delays.
When two devices have the same IRQ number it's called sharinginterrupts. Under some conditions this sharing works out OK.Starting with kernel version 2.2, ISA serial ports may, if thehardware is designed for this, share interrupts with other serialports. Devices on the PCI bus may share the same IRQ interrupt withother devices on the PCI bus (provided the software supports this).In other cases where there is potential for conflict, there should beno problem if no two devices with the same IRQ are ever 'in use' atthe same time. More precisely, 'in use' really means 'open' (inprogrammer jargon). In cases other than the exceptions mentionedabove (unless special software and hardware permit sharing), sharingis not allowed and conflicts arise if sharing is attempted.
Even if two processes with conflicting IRQs run at the same time, oneof the devices will likely have its interrupts caught by its devicedriver and may work OK. The other device will not have its interruptscaught by the correct driver and will likely behave just like aprocess with mis-set interrupts. See Mis-set Interrupts for more details.
If you are getting a very slow response as described above, thenone test is to change the IRQ to 0 (uses fast polling instead ofinterrupts) and see if the problem goes away. Note that the pollingdue to IRQ=0 is orders of magnitude faster than the slow 'polling' dueto bad interrupts. If IRQ=0 seems to fix the problem, then there waslikely something wrong with the interrupts. Using IRQ=0 is veryresource intensive and is only a temporary fix. You should try tofind the cause of the interrupt problem and not permanently use IRQ=0.
Check /proc/interrupts to see if the IRQ is currently in use by anotherprocess. If it's in use by another serial port you could try 'top'(type f and then enable the TTY display) or 'ps -e' to find out whichserial ports are in use. If you suspect that setserial has a wrongIRQ then see What is the current IO address and IRQ of my Serial Port ?
UARTs (Universal Asynchronous ReceiverTransmitter) are serial chips on your PC motherboard (or on aninternal modem card). The UART function may also be done on a chipthat does other things as well. On older computers like many 486's,the chips were on the disk IO controller card. Still older computerhave dedicated serial boards.
When PCs all had parallel bus architecture, the UART's purpose was toconvert bytes from the PC's parallel bus to a serial bit-stream. Thecable going out of the serial port is serial and has only one wire foreach direction of flow. The serial port sends out a stream of bits,one bit at a time. Conversely, the bit stream that enters the serialport via the external cable was converted to parallel bytes that thecomputer 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 a serial port on your PC. Whenyou type a character, the terminal gives that character to itstransmitter (also a UART). The transmitter sends that byte out ontothe serial line, one bit at a time, at a specific rate. On the PCend, the receiving UART takes all the bits and reconstruct the byte(parallel on older PCs) and puts it in a buffer. For newer PCs thatmight have a PCI-e serial port, the UART doesn't need to convertparallel-to-serial since the PCI-e 'bus' is already a serial line.But the PCI-e line carries an encoded signal which must be decoded andthen greatly slowed down to the speed of the RS-232 serial line.
Along with converting between serial and parallel, the UART does someother things as a byproduct (side effect) of its primary task. Thevoltage used to represent bits is also converted (changed). Extrabits (called start and stop bits) are added to each byte before it istransmitted. See the Serial-HOWTO section Voltage Waveshapes for details. Also, while the flow rate(in bytes/sec) on the parallel bus inside the computer is very high,the flow rate out the UART on the serial port side of it is muchlower. The UART has a fixed set of rates (speeds) which it can use atits serial port interface.
There are two basic types of UARTs: dumb UARTS and FIFO UARTS.Dumb UARTs are the 8250, 16450, early 16550, and early 16650. Theyare obsolete but if you understand how they work it's easy tounderstand how the modern ones work with FIFO UARTS ( late 16550,16550A, and higher numbers). Note that the driver for all of them isstill labeled a '8250' driver in Linux where you may see it in compileoptions if you compile your own kernel, etc.
There is some confusion regarding 16550. Early models had a bug andworked properly only as 16450's (no FIFO). Later models with the bugfixed were named 16550A but many manufacturers did not accept the namechange and continued calling it a 16550. Most all 16550's in usetoday are like 16550A's. Linux will report it as being a 16550A eventhough your hardware manual (or a label note) says it's a 16550. Asimilar situation exists for the 16650 (only it's worse since themanufacturer allegedly didn't admit anything was wrong). Linux willreport a late 16650 as being a 16650V2. If it reports it as 16650 itis 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 aUART has sent or received a byte. The UART itself can't do anythingwith the data passing thru it, it just receives and sends it. For theobsolete dumb UARTS, the CPU gets an interrupt from the serial deviceevery time a byte has been sent or received. The CPU then moves thereceived byte out of the UART's buffer and into memory somewhere, orgives the UART another byte to send. The obsolete 8250 and 16450UARTs only have a 1 byte buffer. That means, that every time 1 byteis sent or received, the CPU is interrupted. At low transfer rates,this is OK. But, at high transfer rates, the CPU gets so busy dealingwith the UART, that is doesn't have time to adequately tend to othertasks. In some cases, the CPU does not get around to servicing theinterrupt in time, and the byte is overwritten, because they arecoming in so fast. This is called an 'overrun' or 'overflow'.
FIFO UARTs help solve this problem. The 16550A (or 16550) FIFO chipcomes with 16 byte FIFO buffers. This means that it can receive up to14 bytes (or send 16 bytes) before it has to interrupt the CPU. Notonly can it wait for more bytes, but the CPU then can transfer all (14to 16) bytes at a time. This is a significant advantage over theobsolete UARTs, which only had 1 byte buffers. The CPU receives lessinterrupts, and is free to do other things. Data is rarely lost.Note that the interrupt threshold of FIFO buffers (trigger level) maybe set at less than 14. 1, 4 and 8 are other possible choices. As oflate 2000 there was no way the Linux user could set these directly(setserial can't do it). While many PC's only have a 16550 with16-byte buffers, better UARTS have even larger buffers.
Note that the interrupt is issued slightly before the buffer gets full(at say a 'trigger level' of 14 bytes for a 16-byte buffer). Thisallows room for a couple more bytes to be received before theinterrupt service routine is able to actually fetch all these bytes.The trigger level may be set to various permitted values by kernelsoftware. A trigger level of 1 will be almost like an obsolete UART(except that it still has room for 15 more bytes after it issues theinterrupt).
Now consider the case where you're on the Internet. It's just sentyou a short webpage of text. All of this came in thru the serialport. If you had a 16-byte buffer on the serial port which held backcharacters until it had 14 of them, some of the last severalcharacters on the screen might be missing as the FIFO buffer waited toget the 14th character. But the 14th character doesn't arrive sinceyou've been sent the entire page (over the phone line) and there areno more characters to send to you. It could be that these lastcharacters are part of the HTML formatting, etc. and are notcharacters to display on the screen but you don't want to lose formateither.
There is a 'timeout' to prevent the above problem. The 'timeout'works like this for the receive UART buffer: If characters arrive oneafter another, then an interrupt is issued only when say the 14thcharacter reaches the buffer. But if a character arrives and the nextcharacter doesn't arrive soon thereafter, then an interrupt is issuedanyway. This results in fetching all of the characters in the FIFObuffer, even if only a few (or only one) are present. There is also'timeout' for the transmit buffer as well.
You may wonder why the FIFO buffers are not larger. After all,memory is cheap and it wouldn't cost much more to use buffers in thekilo-byte range. The reason is flow control. Flow control stops theflow of data (bytes) on serial line when necessary. If a stop signalis sent to serial port, then the stop request is handled by software(even if the flow control is 'hardware'). The serial port hardwareknows nothing about flow control.
If the serial port buffer contains 64 bytes ready to send when itreceives a flow control signal to stop sending, it will send out the64 bytes anyway in violation of the stop request. There is nostopping it since it doesn't know about flow control. If the bufferwas large, then many more bytes would be sent in violation of flowcontrol's request to stop.
Here's a list of some 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;115.2 kbps standard, many support 230.4 or 460.8 kbps
- 16650: 32-byte buffers. 460.8 kbps
- 16750: 64-byte buffer for send, 56-byte for receive. 921.6 kbps
- 16850, 16C850: 128-byte buffers. 460.8 kbps or 1.5 mbps
- 16950
- Hayes ESP: 1k-byte buffers.
For V.90 56k modems, it may be a several percent faster with a 16650(especially if you are downloading large uncompressed files). Themain advantage of the 16650 is its larger buffer size as the extraspeed isn't needed unless the modem compression ratio is high. Some56k internal modems may come with a 16650 ??
Non-UART, and intelligent multiport boards use DSP chips todo additional buffering and control, thus relieving the CPUeven more. For example, the Cyclades Cyclom, and StallionEasyIO boards use a Cirrus Logic CD1400 RISC UART, and manyboards use 80186 CPUs or even special RISC CPUs, to handle theserial IO.
Many 486 PCs (old) and all Pentiums (or the like) should have at least16550As (usually called just 16550's) with FIFOs. Some bettermotherboards today (2000) even have 16650s. For replacing obsoleteUARTs with newer ones in pre 1990 hardware see the Appendix: Obsolete...
The pin numbers are often engraved in the plastic of theconnector but you may need a magnifying glass to read them.Note DCD is sometimes labeled CD. The numbering of the pins on afemale connector is read from right to left, starting with 1 in theupper right corner (instead of 1 in the upper left corner for the maleconnector as shown below). --> direction is out of PC.
Only 3 of the 9 pins have a fixed assignment: transmit, receiveand signal ground. This is fixed by the hardware and you can't changeit. 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 oftwo states: asserted (+12 volts) or negated (-12 volts). Asserted is'on' and negated is 'off'. For example, Linux software may commandthat DTR be negated and the hardware only carries out this command andputs -12 volts on the DTR pin. A modem (or other device) thatreceives this DTR signal may do various things. If a modem has beenconfigured a certain way it will hang up the telephone line when DTRis negated. In other cases it may ignore this signal or do somethingelse when DTR is negated (turned off).
It's like this for all the 6 signal lines. The hardware only sendsand receives the signals, but what action (if any) they perform is upto the Linux software and the configuration/design of devices that youconnect to the serial port. However, most pins have certain functionswhich they normally perform but this may vary with the operatingsystem and the device driver configuration. Under Linux, one maymodify the source code to make these signal lines behave differently(some people have).
A cable from a serial port always connects to another serial port.An external modem or other device that connects to the serial port hasa serial port built into it. For modems, the cable is always straightthru: pin 2 goes to pin 2, etc. The modem is said to be DCE (DataCommunications Equipment) and the computer is said to be DTE (DataTerminal Equipment). Thus for connecting DTE-to-DCE you usestraight-thru cable. For connecting DTE-to-DTE you must use anull-modem cable (also called a crossover cable). There are many waysto wire such cable (see examples in Text-Terminal-HOWTO subsection:'Direct Cable Connection')
There are good reasons why it works this way. One reason is that thesignals are unidirectional. If pin 2 sends a signal out of it (but isunable to receive any signal) then obviously you can't connect it topin 2 of the same type of device. If you did, they would both sendout signals on the same wire to each other but neither would be ableto receive any signal. There are two ways to deal with thissituation. One way is to have a two different types of equipmentwhere pin 2 of the first type sends the signal to pin 2 of the secondtype (which receives the signal). That's the way it's done when youconnect a PC (DTE) to a modem (DCE). There's a second way to do thiswithout having two different types of equipment: Connect pin sendingpin 2 to a receiving pin 3 on same type of equipment. That's the wayit's done when you connect 2 PCs together or a PC to a terminal(DTE-to-DTE). The cable used for this is called a null-modem cablesince it connects two PCs without use of a modem. A null-modem cablemay also be called a cross-over cable since the wires between pins 2and 3 cross over each other (if you draw them on a sheet of paper).The above example is for a 25 pin connector but for a 9-pin connectorthe pin numbers 2 and 3 are just the opposite.
The serial pin designations were originally intended for connecting adumb terminal to a modem. The terminal was DTE (Data TerminalEquipment) and the modem was DCE (Data Communication Equipment).Today the PC is usually used as DTE instead of a terminal (but realterminals may still be used this way). The names of the pins are thesame on both DTE and DCE. The words: 'receive' and 'transmit' arefrom the 'point of view' of the PC (DTE). The transmit pin from thePC transmits to the 'transmit' pin of the modem (but actually themodem is receiving the data from this pin so from the point of view ofthe modem it would be a receive pin).
The serial port was originally intended to be used for connecting DTEto DCE which makes cabling simple: just use a straight-thru cable.Thus when one connects a modem one seldom needs to worry about whichpin is which. But people wanted to connect DTE to DTE (for example acomputer to a terminal) and various ways were found to do this byfabricating various types of special null-modem cables. In this casewhat pin connects to what pin becomes significant.
This is 'hardware' flow control. Flow control was previouslyexplained in the Flow Controlsubsection but the pins and voltage signals were not. Linux onlysupports RTS/CTS flow control at present (but a special driver mayexist for a specific application which supports DTR/DSR flow control).Only RTS/CTS flow control will be discussed since DTR/DSR flow controlworks the same way. To get RTS/CTS flow control one needs to eitherselect hardware flow control in an application program or use thecommand:
stty -F /dev/ttyS2 crtscts (or the like). This enables RTS/CTShardware flow control in the Linux device driver.
stty -F /dev/ttyS2 crtscts (or the like). This enables RTS/CTShardware flow control in the Linux device driver.
Then when a DTE (such as a PC) wants to stop the flow into it, itnegates RTS. Negated 'Request To Send' (-12 volts) means 'request NOTto send to me' (stop sending). When the PC is ready for more bytesit asserts RTS (+12 volts) and the flow of bytes to it resumes. Flowcontrol signals are always sent in a direction opposite to the flow ofbytes that is being controlled. DCE equipment (modems) works the sameway but sends the stop signal out the CTS pin. Thus it's RTS/CTS flowcontrol using 2 lines.
On what pins is this stop signal received? That depends on whether wehave a DCE-DTE connection or a DTE-DTE connection. For DCE-DTE it's astraight-thru connection so obviously the signal is received on a pinwith the same name as the pin it's sent out from. It's RTS-->RTS (PCto modem) and CTS<--CTS (modem to PC). For DTE-to-DTE the connectionis also easy to figure out. The RTS pin always sends and the CTS pinalways receives. Assume that we connect two PCs (PC1 and PC2)together via their serial ports. Then it's RTS(PC1)-->CTS(PC2) andCTS(PC1)<--RTS(PC2). In other words RTS and CTS cross over. Such acable (with other signals crossed over as well) is called a 'nullmodem' cable. See Cabling Between Serial Ports
What is sometimes confusing is that there is the original use of RTSwhere it means about the opposite of the previous explanation above.This original meaning is: I Request To Send to you. This request wasintended to be sent from a terminal (or computer) to a modem which, ifit decided to grant the request, would send back an asserted CTS fromits CTS pin to the CTS pin of the computer: You are Cleared To Send tome. Note that in contrast to the modern RTS/CTS bi-directional flowcontrol, this only protects the flow in one direction: from thecomputer (or terminal) to the modem. This original use appears to belittle used today on modern equipment (including modems).
The DTR and DSR Pins
Just like RTS and CTS, these pins are paired. For DTE-to-DTEconnections they are likely to cross over. There are two ways to usethese pins. One way is to use them as a substitute for RTS/CTS flowcontrol. The DTR pin is just like the RTS pin while the DSR pinbehaves like the CTS pin. Although Linux doesn't support DTR/DSR flowcontrol, it can be obtained by connecting the RTS/CTS pins at the PCto the DSR/DTR pins at the device that uses DTR/DSR flow control. DTRflow control is the same as DTR/DSR flow control but it's only one-wayand only uses the DTR pin at the device. Many text terminals and someprinters use DTR/DSR (or just DTR) flow control. In the future, Linuxmay support DTR/DSR flow control. The software has already beenwritten but it's not clear when (or if) it will incorporated into theserial driver.
The normal use of DTR and DSR (not for flow control) is as follows: Adevice 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 howthe modem is configured. Negating DTR is sometimes called 'hangingup' but it doesn't always do this. One way to 'hang up' (negate DTR)is to set the baud rate to 0 using the command 'stty 0'. Trying to dothis from a 'foreign' terminal may not work due to the two-interfaceproblem. See Two interfaces at a terminal. For internal modem-serial_ports it worked OK with a portusing minicom but didn't work if the port was using wvdial. Why?
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.
At the RS-232 serial port, voltages are bipolar (positive ornegative with respect to ground) and should be about 12 volts inmagnitude (some are 5 or 10 volts). For the transmit and receivepins +12 volts is a 0-bit (sometimes called 'space') and -12 volts isa 1-bit (sometimes called 'mark'). This is known as inverted logicsince normally a 0-bit is both false and negative while a one isnormally both true and positive. Although the receive and transmitpins are inverted logic, other pins (modem control lines) are normallogic with a positive voltage being true (or 'on' or 'asserted') and anegative voltage being false (or 'off' or 'negated'). Zero voltagehas no meaning (except it usually means that the unit is powered off).
A range of voltages is allowed. The specs say the magnitude of atransmitted signal should be between 5 and 15 volts but must neverexceed 25 V. Any voltage received under 3 V is undefined (but somedevices will accept a lower voltage as valid). One sometimes seeserroneous claims that the voltage is commonly 5 volts (or even 3volts) but it's usually 11-12 volts. If you are using a EIA-422(RS-422) port on a Mac computer as an RS-232 (requires a specialcable) or EIA-423 (RS-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 voltswas once the standard) so that if you try to use test equipmentdesigned for testing 3-5 volt computer logic (TTL) on the 12 volts of aserial port, it may damage the test equipment.
The transmit pin (TxD) is held at -12 V (mark) at idle when nothingis being sent. To start a byte it jumps to +12 V (space) for thestart bit and remains at +12 V for the duration (period) of the startbit. Next comes the low-order bit of the data byte. If it's a 0-bitnothing 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 comesthe next bit (-12 V if a 1 or +12 V if a 0), etc., etc. After thelast data bit, a parity bit may be sent and then a -12 V (mark) stopbit. Then 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 simpleway (except by a synchronizing signal) to tell where one bit ends andthe next one begins for the case where 2 consecutive bits are the samepolarity (both zero or both one).
A 2nd stop bit would also be -12 V, just the same as the first stopbit. Since there is no signal to mark the boundaries between thesebits, the only effect of the 2nd stop bit is that the line must remainat -12 V idle twice as long. The receiver has no way of detecting thedifference between a 2nd stop bit and a longer idle time betweenbytes. Thus communications works OK if one end uses one stop bit andthe other end uses 2 stop bits, but using only one stop bit isobviously faster. In rare cases 1 1/2 stop bits are used. This meansthat the line is kept at -12 V for 1 1/2 time periods (like a stop bit50% wider than normal).
Characters are normally transmitted with either 7 or 8 bits ofdata. An additional parity bit may (or may not) be appended to thisresulting in a byte length of 7, 8 or 9 bits. Some terminal emulatorsand older terminals do not allow 9 bits. Some prohibit 9 bits if 2stop bits are used (since this would make the total number of bits toolarge: 12 bits total after adding the start bit).
The parity may be set to odd, even or none (mark and space parity maybe options on some terminals or other serial devices). With oddparity, the parity bit is selected so that the number of 1-bits in abyte, including the parity bit, is odd. If a such a byte getscorrupted by a bit being flipped, the result is an illegal byte ofeven parity. This error will be detected and if it's an incoming byteto the terminal an error-character symbol will appear on the screen.Even parity works in a similar manner with all legal bytes (includingthe parity bit) having an even number of 1-bits. During set-up, thenumber of bits per character usually means only the number of databits 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 logic0). For mark parity, the parity bit is always a one-bit. For spaceparity it's always a zero-bit. Mark or space parity (also known as'sticky parity') only wastes bandwidth and should be avoided iffeasible. The
stty
command can't set sticky parity but it'ssupported by serial hardware and can be dealt with by programming inC. 'No parity' means that no parity bit is added. For terminalsthat don't permit 9 bit bytes, 'no parity' must be selected when using8 bit character sets since there is no room for a parity bit. In serial transmission of bytes via RS-232 ports, the low-orderbit is always sent first (the bit-order). Serial ports on PC's useasynchronous communication where there is a start bit and a stop bitto mark the beginning and end of a byte. This is called framing andthe framed byte is sometimes called a frame. As a result a total of9, 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 10bits total when one counts the start bit. One stop bit is almostuniversally used. At 110 bits/sec (and sometimes at 300 bits/sec) 2stop bits were once used but today the 2nd stop bit is used only invery unusual situations (or by mistake since it still works OK thatway but wastes bandwidth).
Don't confuse this type of framing with the framing used for a packetof bytes on a network. The serial port just frames every byte. For anetwork, many bytes are framed into a packet (sometimes called aframe). For a network frame, instead of a start bit, there is asequence of bytes called a header. On a network that uses serialports (with modems), a report of a frame error usually refers to amulti-byte frame and not the serial port frame of a single byte.
The RS-232 serial port as implemented on PC is asynchronous whichin effect means that there is no 'clock' signal sent with 'ticks' tomark when each bit is sent.. There are only two states of thetransmit (or receive) wire: mark (-12 V) or space (+12 V). There isno state of 0 V. Thus a sequence of 1-bits is transmitted by just asteady -12 V with no markers of any kind between bits. For thereceiver to detect individual bits it must always have a clock signalwhich is in synchronization with the transmitter clock. Such a clockwould generate a 'tick' in synchronization with each transmitted (orreceived) bit.
For asynchronous transmission, synchronization is achieved by framingeach byte with a start bit and a stop bit (done by hardware). Thereceiver listens on the negative line for a positive start bit andwhen it detects one it starts its clock ticking. It uses this clocktick to time the reading of the next 7, 8 or 9 bits. (It actually isa little more complex than this since several samples of a bit arenormally taken and this requires additional timing ticks.) Then thestop bit is read, the clock stops and the receiver waits for the nextstart bit. Thus async is actually synchronized during the receptionof a single byte but there is no synchronization between one byte andthe next byte.
A number of EIA (or RS) standards have been established for higherspeeds and longer distances using twisted-pair (balanced) technology.Balanced transmission make possible higher speeds, and can be athousand times faster than unbalanced RS-232. For a given speed, thedistance (maximum cable length) may be many times longer with twistedpair. But PC's, prior to about 2004??, kept being made with thequasi-obsolete RS-232 since it works OK with modems and mice since thecable length is short.
High speed serial ports (over 460.8 kbps) will often support bothRS-232 and EIA-485/EIA-422 (RS-485/RS-422) modes . (Note that fornon-RS-232 I've used the 'EIA' designation instead of the morecommonly used 'RS' but they both mean the same thing.) At such highspeeds RS-232 is not of much use (except for a very short cable).
EIA-423 is just like the unbalanced RS-232 except that thevoltage is only 5 volts. Since this falls within RS-232 specs itcan be connected to a RS-232 port. Its specs call for somewhathigher speeds than the RS-232 (but this may be of little help on along run where it's the unbalance that causes interference). SinceEIA-423 is not much of an improvement over RS-232, it is seldom usedexcept on old Mac computers.
EIA-422 is twisted pair (known as 'balanced' or 'differential) and is(per specs) exactly 100 times as fast as EIA-423 (which in turn issomewhat faster than RS-232). Apple's Mac computer used it prior tomid-1998 with its RS-232/EIA-422 port. The Mac used a small round'mini-DIN-8' connector and named these serial ports as 'modem port','printer port', and/or 'GeoPort'.
Mac also provided conventional RS-232 but at only at 5 volts (whichis still legal RS-232). To make it work like at RS-232 one must usea special cable which (signal) grounds RxD+ (one side of a balancedpair) and use RxD- as the receive pin. While TxD- is used as thetransmit pin, for some reason TxD+ should not be grounded. See Macintosh Communications FAQ. However, due to the fact that Macs (andupgrades for them) cost more than PC's, they are not widely as hostcomputers for Linux.
This is like EIA-422 (balanced = differential). It ishalf-duplex. It's not just point-to-point but is like ethernet or theUSB since all devices (nodes) on it share the same 'bus'. It may beused for a multidrop LAN (up to 32 nodes or more). Unfortunately,Linux currently doesn't support this and you can only use it underLinux only for point-to-point where it behaves like RS-232. So readfurther only if you are curious about how its features would work ifonly Linux supported them.
Since many nodes share the same twisted pair, there's a need to usethe electrical tri-state mode. Thus, besides the 0 and 1 binarystates, there is also an open circuit state to permit other nodes touse the twisted pair line. Instead of a transmitter keeping a 1-statevoltage on the line during line idle, the line is open circuited andall nodes just listen (receive mode).
The most common architecture is master/slave. The master polls theslaves to see if they have anything to send. A slave can onlytransmit just after it's been polled. But EIA-485 is just anelectrical specification and doesn't specify any protocol for themaster/slave interaction. In fact, it doesn't even specify that theremust be a master and slaves. So various protocols have been used.Based on a discussion of 485 on the linux-serial mailing list in March2003, it seems likely that none of these master/slave protocols arecurrently supported by Linux.
There is an alternative implementation where two pair of wires are usedfor sending data. One pair is only for the Master to send to the Slaves.Since no one transmits on this line except the master, there is noneed for it to be tri-state. Thus the Master may just be RS-232 butthe slaves must still be EIA-485. Seehttp://www.hw.cz/english/docs/rs485/rs485.html for moredetails.
EIA-530-A (balanced but can also be used unbalanced) at 2Mbits/s(balanced) was intended to be a replacement for RS-232 but few havebeen installed. It uses the same 25-pin connector as RS-232.
The High Speed Serial Interface ( HSSI = EIA-612/613) uses a50-pin connector and goes up to about 50 Mbits/s but the distance islimited to only several meters. For Linux there are PCI cardssupporting HSSI. The companies that sell the cards often provide (orpoint you to) a Linux driver. A howto or the like is needed for thistopic.
The Universal Serial Bus (USB) is being built into PCI chips.Newer PC's have them. It was originally 12 Mbps but is now 480 Mbpsover 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 onconfiguration). Linux supports the bus, although not all devices thatcan plug into the bus are supported.
It is synchronous and transmits in special packets like a network.Just like a network, it can have several devices physically attachedto it, including serial ports. Each device on it gets a time-slice ofexclusive use for a short time. A device can also be guaranteed theuse of the bus at fixed intervals. One device can monopolize it if noother device wants to use it. It's not simple to describe in detail.
For serial ports on the USB bus, there are numerous configurationoptions to use when compiling the kernel. They all start with:CONFIG_USB_SERIAL. Each one is usually for a certain brand/model ofserial port, although generic is also an option. See theConfiguration Help file in the kernel documentation.
For documentation, see the USB directory in /usr/share/doc/kernel ...and look at the file: usb-serial.txt. The modules that support usbserial devices are found in the modules tree:kernel/drivers/usb/serial. It would be nice to have a HOWTO on theUSB. See also http://www.linux-usb.org and/or http://www.qbik.ch/usb/.
Firewire (IEEE 1394) is something like the USB only faster (800Mbps is planned). The protocol on the bus is claimed to be moreefficient than USB's. It uses two twisted pair for data plus twopower conductors (6 conductors in all). A variants uses only 4conductors. You may compile firewire support into the Linux kernel.Like USB, it's also limited to short distances.
Sound cards often have a 15-pin game port connector used for MIDI.They are for connecting a musical keyboard to a PC so that you cancreate musical recordings. You could also connect a MIDI soundsystem. The MIDI standard uses 31250 baud (1M/32) which is notavailable on an ordinary serial port. Some MIDI devices are designedso that they can be connected directly to an ordinary serial port.
Besides the 15-pin connector, a 5-pin DIN connector is also a MIDIstandard but the flow of sound is only one way thru it so forbidirectional sound you need 2 of them. Breakout cables often have a15-pin connector on one end and 2 or more 5-pin connectors on theother end. The /dev/midi00 is for MIDI.
Beside the asynchronous RS-232 (and others) there are a number ofsynchronous serial port standards. In fact RS-232 includessynchronous specifications but they aren't normally implemented forserial ports on PC's. But first we'll explain what a synchronousmeans.
Defining Asynchronous vs Synchronous
Asynchronous (async) means 'not synchronous'. In practice, anasync signal is what the async serial port sends and receives which isa stream of bytes with each byte framed by a start and stop bit.Synchronous (sync) is most everything else. But this doesn't explainthe basic concepts.
In theory, synchronous means that bytes are sent out at a constantrate one after another in step with a clock signal tick. There isoften a separate wire or channel for sending the clock signal. Theclock signal might also be embedded in the transmitted bytes.Asynchronous bytes may be sent out erratically with various timeintervals between bytes (like someone typing characters at akeyboard).
When a file is being sent thru the async serial port, the flow ofbytes will likely be at the speed of the port (say 115.2k) which is aconstant rate. This flow may frequently start and stop due to flowcontrol. Is this sync or async? Ignoring the flow control stops, itmight seem like sync since it's a steady flow. But it's not becausethere is no clock signal and the bytes could have been senterratically since they are framed by start/stop bits.
Another case is where data bytes (without any start-stop bits) are putinto packets with possible erratic spacing between one packet and thenext. This is called sync since the bytes within each packet aretransmitted synchronously.
Synchronous Communication
Did you ever wonder what all the unused pins are for on a 25-pinconnector for the serial port? Most of them are for use insynchronous communication which is seldom implemented in chips forPC's. There are pins for sync timing signals as well as for a syncreverse channel. The RS-232 spec provides for both sync and asyncbut PC's use a UART (Universal Asynchronous Receiver/Transmitter) chipsuch as a 16450, 16550A, or 16650 and can't deal with sync. For syncone needs a USRT chip or the equivalent where the 'S' stands forSynchronous. A USART chip supports both synchronous and asynchronous.Since sync is a niche market, a sync serial port is likely to be quiteexpensive.
SCC stands for 'Serial Communication Controller' or 'Serial ControllerChip'. It's likely old terminology and since it doesn't say 'sync'or 'async' it might support both.
Besides the sync part of the RS-232, there are various other EIAsynchronous standards. For RS-232, 3 pins of the connector arereserved for clock (or timing) signals. Sometimes it's a modem's taskto generate some timing signals making it impossible to usesynchronous communications without a synchronous modem (or without adevice called a 'synchronous modem eliminator' which provides thetiming signals).
Although few serial ports are sync, synchronous communicationdoes often take place over telephone lines using modems which useV.42 error correction. This strips off the start/stop bits and putsthe data bytes in packets resulting in synchronous operation over thephone line.
- Axleson, Jan: Serial Port Complete, Lakeview Research, Madison,WI, 1998.
- Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEEComputer Society Press, Los Alamitos, CA, 1996.
- Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
- Campbell, Joe: C Programmer's Guide to Serial Communications,2nd ed., Unknown Publisher, 1993.
- Levine, Donald: POSIX Programmer's Guide, O'Reilly, 1991.
- Nelson, Mark: Serial Communications Developer's Guide, 2nd ed.,Hungry Minds, 2000.
- Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
- Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall,1991.
- Stevens, Richard W.: Advanced Programming in the UNIX Environment,(ISBN 0-201-56317-7; Addison-Wesley)
- Tischert, Michael & Bruno Jennrich: PC Intern, Abacus 1996.Chapter 7: Serial Ports
Notes re books:
- '... Complete' has hardware details (including register) but theprogramming aspect is Window oriented.
- 'Physical Layer ...' covers much more than just RS-232.
If it's not available in your Linux distribution try:
Serial Software for Linux software for the serial portsincluding getty and port monitors.
Serial Communications for communication programs.
Serial Software for Linux software for the serial portsincluding getty and port monitors.
Serial Communications for communication programs.
irqtune
will give serial port interrupts higherpriority to improve performance. Usinghdparm
for hard-disk tuningmay help some more.modemstat
andstatserial
show the current state ofvarious modem control lines. See Serial Monitoring/Diagnostics
- man pages for:
setserial
andstty
- Low-Level Terminal Interface part of 'GNU C Library Referencemanual' (in libc (or glibc) docs package). It covers the detailedmeaning of 'stty' commands, etc.
- 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
The Linux serial mailing list. To join, send email to
[email protected]
, with ``subscribelinux-serial
' in the message body. If you send ``help
' inthe message body, you get a help message. The server also servesmany other Linux lists. Send the ``lists
' command for a listof mailing lists.- Linux Serial Driver home page Includes info about PCI support.
- Serial-Programming-HOWTO (not yet availablefrom the Linux Documentation Project). It's now on my website:http://www.lafn.org/~dave/linux/Serial-Programming-HOWTO.txtSee also: Serial-Programming-HOWTO by Peter Baumann
- A white paper discussing serial communications and multiportserial boards was available from Cyclades at
http://www.cyclades.com
.
Many 486 PCs (old) and all Pentiums (or the like) should havemodern 16550As (usually called just 16550's) with FIFOs. If you havesomething really old (pre 1990), the chip may unplug so that you maybe able to upgrade by finding a plug-in 16550A chip and replacing yourold existing 16450 UART. If the functionality has been built intoanother type of chip, you are out of luck. If the UART is socketed,then upgrading would be easy if you could find a replacement. The newand old are pin-to-pin compatible. It may be more feasible to justbuy a new serial card on the Internet (few retail stores stock themas of 2000) or find a used one.
Modern kernels should not allow the opening of ports with the sameIO address. But one may probe for ports even though they are notopen. If two ports have the same IO address then old fashionedprobing by sending commands to the address will erroneously indicateonly one port. But modem device detection at boot-time shoulddiscover both ports and report the conflict. In olden days, all sortsof errors were reported/observed for devices illegally attempting touse the same IO address. See Probing.
In the past, to get a certain serial port supported, one might needto modify the C source code, perhaps by adding a #define to it.Today, the use of parameters for modules or the kernel, or the use ofconfiguration options should handle all cases (except possible forantique hardware ??).
For a modem to transmit at nearly 56k requires that it be a specialdigital modem and have a digital connection to a digital phone line(such as a T1 line). Modems used with serial cards (the modems mayeither be on the serial card or on another card) normally have no suchdigital connection so they can't be used at the 56k speed, and thusare obsolete unless one doesn't need to send at 56k. In other wordsthey are obsolete for ISP servers but might be OK for small businessor home use.
A partial exception to the above are modem banks that connect tomultiport serial cards where the modem bank can access multiplexeddigital phone lines. Thus one could use a multiport serial card witha few 56k digital modems for sending at 56k. For both analog anddigital modems there is one modem on each serial port so there needsto be an external cable (modem bank to multiport) for each modem.This can lead to a large number of cables. So it's less clutter (andcheaper) to use internal modems without a multiport card. This makeseven this 'exception' obsolete for high volume work. It's somewhatanalogous to the lower cost of an internal modem for a desktop PC ascompared to the higher cost (and more cabling) for an external modem.See Modem-HOWTO: Modem Pools, Digital Modems.
The abandoned device-filesystem (devfs) has the /dev directorywith subdirectories. As of late 2001, there were problems withlockfiles. For example, the lockfile mechanism considereddev/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, ifsome applications use the old name for a device and other applicationsuse the devfs name for the same device, then the lockfiles will havedifferent names. But the serial driver should know they are the same.
Kernel 2.4 introduced the now obsolete optional 'device file system'(devfs) with a whole new set of names for everything. Some peopleused it but the majority probably didn't. But in 2003-4, it wasclaimed that devfs had unsolvable problems and starting with kernel2.6.12 it was replaced with 'udev' (kernels prior to 2.6.12 also coulduse udev but with some problems). Although udev doesn't provide allthe functionality of devfs, it does handle hot plugging. Also, theuse of udev isn't required to run Linux so some people don't use it.But many distributions install it by default.
Devfs was a good idea and was claimed to be more efficient than udev.But unfortunately, the author of devfs didn't maintain it for long andit allegedly became not too well maintained. So for better or worsewe now have udev instead although the debate of devfs vs. udev stillcontinues. For a detailed description of devfs see: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html Also seethe kernel documentation tree: filesystems/devfs.
The names of devices for the devfs can be used in udev, but usuallyare not and may not be simple to activate. Here's the devfs names forserial devices: ttyS1 becomes tts/1, ttyUSB1 becomes /usb/tts/1, andttyACM1 is /usb/acm/1. Note that the number 1 above is just anexample. It could be replaced by 0, 2, 3, 4, etc. Some more examplesof udev names: ttyS2 becomes tts/2 (Serial port), tty3 becomes vc/3(Virtual Console), ptyp1 becomes pty/m1 (PTY master), ttyp2 becomespty/s2 (PTY slave). 'tts' looks like a directory which containsdevices 'files': 0, 1, 2, etc. All of these new names were put in the/dev directory although optionally one may put them elsewhere.
For devfs, device names in the /dev directory are created automaticallyby the corresponding driver. Thus, if serial support comes from amodule and that module isn't loaded yet, there will not be any serialdevices in the /dev directory. This can be confusing: you physicallyhave serial ports but don't see them in the /dev directory. However,if a device name is requested (attempt to open it) by a communicationprogram and the serial module isn't loaded, the kernel is supposed totry to find a driver for it and create a name for it in the /devdirectory.
This works OK if it finds a driver. But suppose there is no driverfound for it. For example, if you try to use 'setserial' to configurea port that the driver failed to detect, it claims there is no suchport. How does one create a devfs port in this case?
For multiport devices for example, /dev/ttyF9 becomes /dev/ttf/9, orin a later version /dev/tts/F9. Substitute for F (or f) whateverletter(s) your multiport board uses for this purpose. A multiportdriver is supposed to create a devfs name similar to the above and putit into the /dev directory
END OF Serial-HOWTO