A number of EIA standards have been established for higher speeds and longer distances using twisted-pair (balanced) technology. Balanced transmission make possible higher speeds, and can 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.
High speed serial ports (over 460.8 kbps) will often support both EIA-232 and EIA-485/EIA-422 modes. At such high speeds EIA-232 is not of much use (except for a very short cable).
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). Since EIA-423 is not much of an improvement over EIA-232, it is seldom used except on old Mac computers.
EIA-422 is twisted pair (known as "balanced" or "differential) and is (per specs) exactly 100 times as fast as EIA-423 (which in turn is somewhat faster than EIA-232). Apple's Mac computer used it prior to mid-1998 with its EIA-232/EIA-422 port. The Mac used a small round "mini-DIN-8" connector and named these serial ports as "modem port", "printer port", and/or "GeoPort".
Mac also provided conventional 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. 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.
This is like EIA-422 (balanced = differential). It is half-duplex. It's not just point-to-point but is like ethernet or the USB since all devices (nodes) on it share the same "bus". It may be used for a multidrop LAN (up to 32 nodes or more). Unfortunately, Linux currently doesn't support this and you can only use it under Linux only for point-to-point where it behaves like EIA-232. So read further only if you are curious about how its features would work if only Linux supported them.
Since many nodes share the same twisted pair, there's a need to use the electrical tri-state mode. Thus, besides the 0 and 1 binary states, there is also an open circuit state to permit other nodes to use the twisted pair line. Instead of a transmitter keeping a 1-state voltage on the line during line idle, the line is open circuited and all nodes just listen (receive mode).
The most common architecture is master/slave. The master polls the slaves to see if they have anything to send. A slave can only transmit just after it's been polled. But EIA-485 is just an electrical specification and doesn't specify any protocol for the master/slave interaction. In fact, it doesn't even specify that there must be a master and slaves. So various protocols have been used. Based on a discussion of 485 on the linux-serial mailing list in March 2003, it seems likely that none of these master/slave protocols are currently supported by Linux.
There is an alternative implementation where two pair of wires are used for sending data. One pair is only for the Master to send to the Slaves. Since no one transmits on this line except the master, there is no need for it to be tri-state. Thus the Master may just be EIA-232 but the slaves must still be EIA-485. See http://www.hw.cz/english/docs/rs485/rs485.html for more details.
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.
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. For Linux there are PCI cards supporting HSSI. The companies that sell the cards often provide (or point you to) a Linux driver. A howto or the like is needed for this topic.
The Universal Serial Bus (USB) is being built into PCI chips. Newer PC's have them. It is 12 Mbps (with 200 Mbps planned) over a twisted pair with a 4-pin connector (2 wires are power supply). It also is limited to short distances of at most 5 meters (depends on configuration). Linux supports the bus, although not all devices that can plug into the bus are supported.
It is synchronous and transmits in special packets like a network. Just like a network, it can have several devices physically attached to it, including serial ports. 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.
For serial ports on the USB bus, there are numerous configuration options to use when compiling the kernel. They all start with: CONFIG_USB_SERIAL. Each one is usually for a certain brand/model of serial port, although generic is also an option. See the Configuration Help file in the kernel documentation.
For documentation, see the USB directory in /usr/share/doc/kernel ... and look at the file: usb-serial.txt. The modules that support usb serial devices are found in the modules tree: kernel/drivers/usb/serial. It would be nice to have a HOWTO on the USB. See also http://www.linux-usb.org and/or http://.www.qbik.ch/usb/.
Firewire (IEEE 1394) is something like the USB only faster (800 Mbps is planned). The protocol on the bus is claimed to be more efficient than USB's. It uses two twisted pair for data plus two power conductors (6 conductors in all). A variants uses only 4 conductors. You may compile firewire support into the Linux kernel. Like USB, it's also limited to short distances.
Sound cards often have a 15-pin game port connector used for MIDI. They are for connecting a musical keyboard to a PC so that you can create musical recordings. You could also connect a MIDI sound system. The MIDI standard uses 31250 baud (1M/32) which is not available on an ordinary serial port. Some MIDI devices are designed so that they can be connected directly to an ordinary serial port.
Besides the 15-pin connector, a 5-pin DIN connector is also a MIDI standard but the flow of sound is only one way thru it so for bidirectional sound you need 2 of them. Breakout cables often have a 15-pin connector on one end and 2 or more 5-pin connectors on the other end. The /dev/midi00 is for MIDI.
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.
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 with each byte framed 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. There is often a separate wire or channel for sending the clock signal. The clock signal might also be embedded in the transmitted bytes. Asynchronous bytes may be sent out erratically with various time intervals between bytes (like someone typing characters at a keyboard).
When a file is being sent thru the async serial port, the flow of bytes will likely be at the speed of the port (say 115.2k) which is a constant rate. This flow may frequently start and stop due to flow control. Is this sync or async? Ignoring the flow control stops, it might seem like sync since it's a steady flow. But it's not because there is no clock signal and the bytes could have been sent erratically since they are framed by start/stop bits.
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 are transmitted synchronously.
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 in chips for 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 USRT chip or the equivalent where the "S" stands for Synchronous. A USART chip supports both synchronous and asynchronous. Since sync is a niche market, a sync serial port is likely to be quite expensive.
SCC stands for "Serial Communication Controller" or "Serial Controller Chip". It's likely old terminology and since it doesn't say "sync" or "async" it might support both.
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 data bytes in packets resulting in synchronous operation over the phone line.