PC World 1999 August

home *** CD-ROM | disk | FTP | other *** search

/ PC World 1999 August / PCWorld_1999-08_cd.bin / doc / HOWTO / Serial-HOWTO < prev next >

Wrap

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

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