Are there any alternatives to this ancient yet still popular way of communication?


8 Answers 8


It’s been more than 10 years, and we’re still using RS-232?

It's just a communications standard, and very bare-bones at that.

Your statement is not much different than, "It’s been more than 10 years, and we’re still using wires?" Despite optical and RF solutions being available, wire still has some very distinct advantages, just like RS-232.

The main advantages are

  • It's cheap
  • It's trivially easy to use
  • It uses fewer wires than parallel data transmission
  • It goes long distances (measured in hundreds of feet/tens of meters, rather than inches/cm for most TTL/CMOS signals)
  • It's widely used in many products
  • Compatibility issues are rare
  • It's standardized, and a UART is included on all but the most simple microcontrollers
  • Lots of converters are available to convert it to other standards (such as USB)
  • Uses trivial NRZ encoding, so it's easy to interpret even without a UART

Disadvantages include

  • Slow
  • Doesn't specify protocol or higher layers of the communications stack
  • Standard connectors are bulky
  • Doesn't supply power
  • No standard identification mechanism (ie, can't plug it in and have the host know what was plugged in and its capabilities)

Are there any alternatives to this ancient yet still popular way of communication?

There are certainly alternatives, but no competitors that have all the above advantages.

We could list off the thousands of communication standards one might use in place of RS-232, but the bottom line is that RS-232 hasn't been replaced or superceded. USB is the closest thing to it, but is severely limited in terms of distance, cost, ease of use, and included silicon on most microcontrollers.

USB has other significant advantages that RS-232 doesn't have, though. They aren't replacements for each other, and in fact happily coexist on many computers.

The key point is that RS-232 is a tool, and as such isn't intrinsically bad, or in need of replacement. It's getting less use these days as people want more advanced features, or faster speeds, or have some other requirement which RS-232 doesn't fulfill.

But that doesn't mean that it should or will go away, because there are still a lot of new applications where RS-232 is the perfect fit.


What do you mean - just 10 years. RS-232 was defined in 1962 and so is coming up to its 48th birthday.

RS-232 uses a simple asynchronous serial data transfer method that requires very little silicon, is easy to code in software and can be used on micros with minute amounts of RAM or program memory. It has also had the advantage in the past that all computers and dumb terminals had RS-232 interfaces so using it for debug output was a no-brainer.

If you needed higher speed or long distance transmission then you just replace the line drivers with RS-422 or RS-485 differential driver/receivers and no change to the software was needed.

Implementing USB on tiny micros is just not possible. The processing/memory/silicon overhead is just too costly.

SPI or I2C are possible (and used in some places) but the interface cards for your pc are unusual and expensive. I2C has a nasty lockup state that can make it die if the clock stops halfway through a slave data output cycle and the data bit is low.

  • \$\begingroup\$ Why do you say I2C "dies" in that scenario? It's true that starting a transmission when the previous state of the bus is unknown may require sending up to nine clocks, but that can be handled by having the i2c_start routine check the state of the data line and output up to nine clock pulses if it's low (stop outputting pulses as soon as it goes high). Even my 6502 I2C code does that. Is there some other problem condition you're thinking of? \$\endgroup\$
    – supercat
    Oct 26, 2011 at 22:49
  • \$\begingroup\$ That is the scenario and cure that I was referring to. If you are using an I2C or (Atmel)TWI integrated peripheral then you can have to remap the port pins in use and then manually toggle the clock line nine times to exit the lockup before reassigning the pin back to the I2C function. All a bit messy. \$\endgroup\$
    – uɐɪ
    Oct 27, 2011 at 7:16
  • \$\begingroup\$ That makes sense. I generally bit-bang I2C masters, so I don't often have to deal with that issue but I can see that for people using a hardware-supported I2C master it could be a problem. I was wondering whether you might be referring to a different "I2C lockup" problem I've observed when trying to run a full-speed (400KHz) I2C bus when one slave on the bus is a micro whose system clock is running in low-power (6MHz instead of 24MHz) mode. Because I2C supports handshaking, the only limits for how fast a bus can safely "try" to go, if the master supports handshake, ... \$\endgroup\$
    – supercat
    Oct 27, 2011 at 14:46
  • \$\begingroup\$ ...should be related the differential rise times of SCK/SDA (if e.g. SCK were to rise faster than SDA, releasing SDA and then releasing SCK too soon thereafter could cause a false start condition). It seems, however, that some slave I2C implementations won't handshake SCK pulses which aren't low for at a few of their internal clock cycles, and can get hosed if one tries to talk full-speed to other devices on the bus. Grr... \$\endgroup\$
    – supercat
    Oct 27, 2011 at 14:51
  • Very reliable.
  • Easy to implement.
  • Requires only 3 wires, most of the time.
  • Uses wide voltage swing.
  • It has many devices that have used it.
    • mice
    • printers I have at least one
    • modems
    • scanners
    • bar-code scanners
    • multi-meters
    • GPS units
    • various scientific equipment
  • Can be used to transfer data between two computers with only changing around a few wires. ( Just try that with USB )
  • Has been implemented in many different micro-controllers
  • Doesn't require expensive cable. Except in extreme circumstances, including high speeds.
  • You can easily make your own cable, without special tools.
  • Can be easily adapted for longer cable runs, by using RS-422 or RS-485 signalling.

Frankly with that record, I would be surprised if it ever goes away entirely.

  • 1
    \$\begingroup\$ The differential signalling is nonsense. \$\endgroup\$
    – starblue
    Feb 25, 2010 at 19:53
  • 1
    \$\begingroup\$ @community, @starblue just used a technique called "sarcasm". Sortof. \$\endgroup\$
    – Kortuk
    Mar 2, 2011 at 7:30

There are many alternatives. USB is the one that seems most commonly used nowadays. I2C is another.

RS-232 still exists for legacy reasons. If you can put up with the mishmash of different data rates, stop bits, parity settings and wiring configurations, it is actually quite a simple, solid and reliable interface for low data rate applications.

I listened to a podcast recently that discussed the handling of audio at a seminar. All of the audio pros still use XLR connectors and conventional microphone cables, a technology that's at least 50 years old, even though newer alternatives are available. They use it because it is stable, proven, reliable, and industry-standard.


Distinguish serial UART communication from the various voltage levels used to transmit it: RS232, RS485, LVDS.

Serial UART communication is reliable and simple.


A lot of systems will convert the RS-232 to USB using a converter IC. The ones that seem to be the most popular are the FTDI devices. FTDI sells a cable with a USB connector on one end and six pin header on the other (FTDI TTL-232R-3V3). This converts from a USB to RS232 at TTL levels

FTDI also makes an IC to perform the same function -- FTDI FT232RL. This is in an SMD package. You connect the data inputs to the USB connector and the outputs to an RS232 at TTL Levels. The cable is in the $15-$20 range. The IC is around $2.50 (100). The IC requires a half dozen passives. I also like to add a TVS IC.

It you need to get true RS232 levels you would need a driver IC.

More of the hobbyist parts are now starting to integrate USB into the low end controllers. RS232 will start to be used only where you need a large number of simple UARTs.

  • \$\begingroup\$ In practice you will find those converters are not without issue - for example, they expose the reality that USB is actually slower than typical serial baud rates for certain kind of query/response traffic! And no, "large numbers of UARTs" will not be the only justification - simplicity has far wider appeal than that. \$\endgroup\$ Mar 31, 2016 at 4:05

I'm a fan of USB <--> Serial IC's, handles all the dirty work of implementing USB, and you can pump up the bitrates to extreme levels (official RS232 tops out at what, 115k? I've seen USB<-->serial do several mbit/sec before)

  • \$\begingroup\$ Which devices do you use? \$\endgroup\$ Feb 26, 2010 at 0:06
  • 1
    \$\begingroup\$ RS232 can go significantly faster than 115k. I have run RS232 at MBAUD before, it is just a distance thing and clock error. \$\endgroup\$
    – Kortuk
    Mar 1, 2010 at 11:02

RS232 voltage-level signaling is becoming less common, as more and more devices are designed to plug into a USB port rather than an RS-232 port. The common async 8-N-1 signaling protocol, however, allows data to be sent full duplex with predictable timing and no byte stuffing. A byte can be started at any desired moment when the line is otherwise idle, and there is no danger of data underrun. Hardware to support 8-N-1 signaling is common and cheap, and while the protocol isn't entirely optimal, many changes that would make it better for some applications would make it worse for others. The only significant downside to 8-N-1 is that it requires that both sides of the communication have a stable clock which is a known (generally integer) multiple of the desired communications rate.

Incidentally, most async 8-N-1 hardware allows for at least one type of out-of-band signalling: the long break. While there are certainly times it would be helpful to have a few more types of out-of-band signaling, it's useful to have at least one.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.