The word "serial" in terms of computers might bring several things to mind. In modern times, it might be the universal serial bus (USB). Not too long ago, it might have brought to mind a 9-pin connector on the back of your desktop – or the even bigger 25-pin connector a bit before that. Different, still, the term might bring up memories of modems, printers, or peripherals connected to specialty computers. If you look at early mainframes, the serial port was the main interface to a text terminal and thus the human interface to the computer.

Some of these usages have been superseded by newer or different technologies, but serial is still alive and well. Although not as common on today's computer equipment, serial communication is far from gone, and its availability can provide some interesting possibilities for talking to unique hardware.

Basic Principles

In the simplest sense, an electric circuit used for communication just uses a completed circuit to represent a 1 and a broken circuit to represent a 0. See the "Telegraphy" sidebar for how this worked in real life for years. The limitation of a simple telegraphy circuit is that for each signal you want to send, you need a dedicated wire.

The serial protocol expands slightly on the simple telegraphy circuit. It now relies on timing to determine when to see whether the current signal is LOW or HIGH. When you're setting up a serial connection, you'll either receive or agree on a couple of parameters that define this timing; for example, 9600,8,N,1 specifies 9600 baud (the speed), 8 data bits, no parity bit, and 1 stop bit, which makes one character of data look like Figure 1.

Figure 1: The signal flow of one 8N1 character on a serial line. The top graph shows proper timing, and the lower graph shows timing that is a little bit off. You can see already, though, how this can change the value received on the other end.

At a slower speed, say 1 baud, you receive 1 bit every second. Here's how the sequence works if I'm receiving data: I start by watching for the line to go active or HIGH. The start bit is always 1 and is not a part of the data. When I receive a start bit, I start my stopwatch and wait 1.5 seconds, at which point I'm about halfway through the next data bit. That gives the line time to stabilize electrically before I read it. As each second passes, I look and see what the state of the line is. If it is HIGH, I write down a 1. If it is not active (open circuit, or LOW), I write down a 0. This process continues until all 8 bits are received.

After all the bits for one character are received, at least one bit's worth of the LOW state will occur before the next character starts. It's important to note that timing is specific to each character. Nothing in the standard says that characters must arrive in a specific timing. After a complete character is received, the line may be idle for an indefinite period of time.

The parity parameter in the first example was (N)one. The other choices are (E)ven and (O)dd. Parity, which is error checking built in to the protocol, adds an extra bit after the start bit that makes the total number of 1s even or odd, depending on the way the parameter is selected.

Regardless of how you send the bits, the timing is what ensures your data gets from one end to the other.

In the simplest sense, the electrical representation of LOW and HIGH can be line switching between Ground and V+. When V+ happens to be 5V, it is often referred to as TTL serial. Depending on the equipment (e.g., a Raspberry Pi), this might also be 3.3V.

You'll also hear terms like RS-232, RS-422, and RS-485 [1] [2]. RS stands for "recommended standard" and defines connectors, pinouts, and electrical characteristics about how these signals are handled. The common RS-232 protocol used in almost all x86 computers for serial communications calls for a negative voltage of at least -3V but no more than -15V to represent a 1 and a positive voltage of at least +3V but no more than +15V to represent a 0, with respect to signal ground.

Serial on the Desktop

As I mentioned previously, until recently, desktop PCs usually included a 9-pin serial port. Even if it is not brought out to the back panel, you can probably still find a header for one on the motherboard. In the early days of PCs, serial ports were used for input devices like mice or digitizer tablets; to connect to other specialty hardware like scales, cash drawers, or industrial equipment; to synchronize your personal digital assistant; and for a modem to talk to the outside world.

Today, you might have to order a USB dongle to get a serial port on your computer. They're readily available and come in many flavors. The most common is still RS-232, but you can also get them for RS-485 or even more specialty types, like SPI or I2C. The most common USB-to-serial adapter may already be hiding in plain sight on your workbench.

Serial on an Arduino

Every Arduino [3] with a USB port has a USB-to-serial adapter built in. After you program your Arduino, the serial port can be used to talk with a PC and external devices. I often use this capability to get the best of both worlds. I can connect sensors, buttons, and input devices along with relays, servos, and other custom outputs to the Arduino and use the computer to display a large GUI, talk on the network, or do more complex processing than the Arduino can do on its own. The trade-off is that I have to maintain two sets of code: one on the computer and another on the Arduino.

With a few parts (Table 1), you can build a very simple serial-controlled device with two input devices, a button and a slide switch, and two outputs, an LED, and a servo (Figure 2). The LED can be on or off, and the servo can move to any position between 0 and 180 degrees.

Figure 2: The Arduino wired up to an LED, a servo, a push button, and a slide switch.