RS-232 In the Modern World

In this post I’d like to talk about one of the communications protocols I often reach for when doing an embedded microcontroller design: RS-232.

I’ve watched people sneer at RS-232 as being “too old”, “obsolete”, or “too slow”. I have to wonder how these attitudes arose. What are these opinions are based on? Whatever it is, I don’t think they are based on facts.

Serial data interfaces have been around for a long time, from the early 20 mA current loop type used on Teletype machines in the 1950s and 1960s to the high-speed SPI and I2C formats in use today for chip-to-chip communications. Even USB and Ethernet are serial interfaces. RS-232 appeared almost 45 years ago as a direct descendant of the 20 mA current loop. Instead of using a change in current for signaling, RS-232 used a voltage. Early RS-232 was slow, 300 baud (about 30 character per second) was common. The speed kept edging upwards over the years, and today RS-232 implementations can be found that will run at 115,000 baud (11,500 characters per second) or even faster. But some people still find this to be too slow, and I’ll talk about that in a moment.

While it’s true that USB is faster than RS-232, and Ethenet is faster yet, I think part of the source of the bad attitudes towards RS-232 is due to a lack of understanding as to how USB and Ethernet actually work. These are not simple communications protocols. USB and Ethernet both require a lot of code behind the scenes to make it easy for a user to simply plug in a cable and start communicating. While it might not be a big issue in a PC with many gigabytes of RAM, that code takes up space in a memory-constrained microcontroller. It is true that we can now purchase microcontroller units (MCUs) with built-in USB, and Ethernet can be implemented with a single outboard IC, but there still needs to be code to interact with the interface hardware.

RS-232 doesn’t require much at all in the way of code or hardware. In fact, it doesn’t even require a special IC to implement a serial interface. Sending and receiving serial data can be done entirely in a small amount of code. Asynchronous serial (i.e. just data send and data receive, no clock signal) does need a special IC to implement the timing recovery logic, but these have now been around decades and most modern microcontrollers include a UART (universal asynchronous receiver-transmitter) on the chip with the other peripheral functions like timers, counters, A/D converters, and so on. From a software perspective using an RS-232 interface generally involves writing data to a specific address and reading data back from another address. There are no device drivers, no MAC addresses, no virtual ports, or much of anything else. It’s just data in, data out, and how fast it can move depends not only on the speed of the physical connection, but also on how fast the CPU can read or write the data to or from the interface.

So why all the bad attitudes towards RS-232? Let’s consider the “it’s too slow” argument first, since this is really the only one that has any validity. If you are trying to move lots of data between a mass storage device and memory in a computer system, then yes, RS-232 is too slow. It was never intended to do that, although I’ve seen people try it. If, on the other hand, you just want to move small amounts of data between a remote sensing device and a master controller, then RS-232 makes perfect sense. The only real drawback is RS-232’s limited range (about 15 feet or around 5 meters). There is another serial protocol that overcomes this, RS-485, and I’ll look at that in a moment.

For a classic example of an application where RS-232 is fast enough to get the job done, consider the now obsolete data terminal. These devices generally consisted of a video display and a keyboard, although some of the older types used an integrated printer and keyboard. The typical data speed for these terminals was 9600 baud (about 960 characters per second), and they were more than fast enough to keep up with a human at the keyboard.

For many years the data terminal was the face of the computer, and the modern flat-screen monitor and USB keyboard are their direct descendants. Early PCs used a form of synchronous (clocked) serial I/O for the keyboard and RS-232 for a mouse. In fact, the keyboard and mouse are still serial devices, only now the serial data is handled by a USB or Bluetooth connection.

RS-232 is not bound to a particular physical connector format. The USB standard, on the other hand, defines connector types (but you can always ignore this if you want to). The hardware handshake signals defined in the RS-232 standard are also optional. This means that an RS-232 interface can be implemented with just three wires: TxD (transmit data), RxD (receive data), and ground. If you only want to send serial data, as is the case with a digital multi-meter I own, you can dispense with the RxD line. You can route the signals through just about any type of connector you want, or you could even just solder the wires at each end of the connection.

USB was designed to allow users to easily connect things like keyboards, mice, printers, scanners, cameras, audio input/output, joysticks, and flash memory devices to a host computer and not have to worry about things like baud rates, handshake signals, DTE versus DCE, and so on. USB may be relatively fast, but it also has some inherent limitations in terms of how many things can be connected. These include slow-downs due to different data transfer rates, single-duplex operation, and complexity in implementation. It is not a cure-all for interface challenges.

Ethernet can transfer data at very high speeds (up to 1GHz or higher), but it is also complex to implement and the supporting infrastructure doesn’t come cheap (bridges, routers, gateways, servers, and so on). Wireless Ethernet (i.e. the 802.11 formats) eliminates the needs for wires and cable, but it is also complex to work with and requires supporting infrastructure. Just connecting two Ethernet devices usually involves a hub or switch of some type (although you can get “inverted” cables for machine-to-machine use). Wireless Ethernet can be implemented between just two machines, but one of them has to take on the role of gateway hotspot and set up up an ad hoc network. None of that is trivial, and it can be downright maddening to get things to talk to one another.

If the speed limits of RS-232 are really a problem then there is an alternative: RS-485, RS-232’s more sophisticated cousin. It is a differential electrical interface with the ability to implement addressing so that multiple devices can share the same channel in a multi-drop arrangement. Because it is differential in nature and relies on the polarity inversion of a balanced pair of signal lines it is not as susceptible to noise and voltage drops as RS-232. The maximum length of an RS-485 channel without relay boosters is about 1.2 Km (4000 feet) or so at a data rate of around 100 Kbits/second. At 10 m the data rate can be as high as 35 Mbits/second. For comparison, 10BASE-T Ethernet tops out at about 10 Mbits/second, and 35 Mb/s is comparable with the average performance that can be expected from a consumer-grade broadband channel. Physically RS-485 (and the older RS-422 as well, for that matter) consists of differential drivers and receivers to convert standard logic-level signals into the differential voltages on the channel and back again. An RS-485 interface is almost as easy to build as an RS-232 interface.

Lastly, serial interfaces can be as minimalist as you need or want. You can dispense with all the protocol hardware and just connect the UART of one MCU IC directly to another for a solid and reliable point-to-point interface. You can even push the serial data through a pair of optoisolators (one for each data direction) if you need electrical isolation.

But back to RS-232. If you need a quick and easy way to communicate with an MCU, be it an Ardunio, an MSP-430 board, or a PIC-based design, don’t overlook the humble serial interface. USB is good for what it was designed to do, but it isn’t a cure-all. It also limits your options in terms of what you can connect to a microcontroller-based device. RS-232, on the other hand, will work with a vast array of devices, including that ancient notebook PC you might have tucked away in a closet somewhere. Why not put it to work and let it be the user interface for an MCU device? Or, just to be a bit weird, how about connecting a printer to your Arduino or PIC? Many older dot-matrix printers have an RS-232 interface, and adding a second serial interface to an MCU for a printer is straightforward (it’s called a “bit-banger” should you want to look it up).

RS-232 and its relatives are still just as useful and relevant today as they were 45 years ago. Don’t paint yourself into a corner by snubbing the older tech in favor of the shiny new stuff. Take advantage of all those years of accumulated experiences and give your designs some options.

If you want to learn more about RS-232 or RS-485 there are some good articles on Wikipedia. There also are extensive write-ups in my books “Real World Instrumentation” and “Practical Electronics: Components and Techniques“.


0 Responses to “RS-232 In the Modern World”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: