This article introduces the RS-422 and RS-485 interfaces and explains why you might want to use them in your designs.

Related Information

 

Most of us are familiar with RS-232—that sturdy but awkward standard that is forever bound to our memories of the increasingly obsolete PC serial port. You may be less familiar with RS-422 and RS-485, which are indeed (as the names imply) related to RS-232.

However, don’t make the mistake of assuming that these newer standards share the characteristics that make RS-232 so incompatible with modern electronic systems. RS-422 and RS-485 are major improvements on the RS-232 theme, and one or the other just might be a good choice for your next digital communication link.

 

First: RS-422 vs. RS-485

These two standards are typically grouped together because they have so much in common. But they are certainly not identical, and RS-422 and RS-485 devices are not completely interchangeable. First, I’ll discuss the prominent differences between the two standards. Then, for the rest of the article, we can simplify by referring to them as “RS-422/485.”

Both RS-422 and RS-485 allow for multiple devices on a bus (i.e., you’re not limited to one transmitter and one receiver). However, RS-422 can be used only for a multi-drop bus—i.e., a differential pair can have multiple receivers but only one transmitter.

 

With RS-422 and a single differential pair, one-way transmission (from master to slaves) is all you get. If a slave must have the ability to respond to the master, you need another differential pair (and this pair as well will have only one active transmitter).

 

The maximum number of receivers on a two-wire RS-422 bus is ten (well, sort of . . . see the “unit loads” discussion below).

With RS-485, on the other hand, you can have an actual multi-point system, where “point” instead of “drop” indicates that one differential pair can support multiple transmitters as well as multiple receivers.

 

This RS-485 bus provides bidirectional communication, but it’s half-duplex. You need a second differential pair if you want full-duplex.

 

RS-485 also increases the bus capacity to 32 devices.

(Actually, it’s not that simple—the standard specifies a maximum of 32 “unit loads,” and you can actually connect far more than 32 devices by using RS-485 ICs that present to the bus only a small fraction of a unit load. It’s a bit complicated, and honestly this is the point at which I start to lose interest. . . . But if you’re more dedicated than I am, you can read more here.)

A fully decked out RS-485 bus is a seriously high-performance interface. In addition to the benefits discussed later in this article, you can have numerous transceivers all sharing the same two wires, and any device on the bus can send data to any other device on the bus.

Another important point is that RS-485 is an extension of RS-422. In other words, RS-485 adds or enhances functionality but does not conflict with anything in the RS-422 standard. So an RS-485 device can be used in an RS-422 network, but RS-422 devices are not necessarily compatible with an existing RS-485 network.

 

The Basics

RS-422/485 is a four- or two-wire, full- or half-duplex, differential, moderate-speed serial communication interface that supports a multi-drop (RS-422) or multi-point (RS-485) bus architecture. Here is some commentary on these characteristics:

  • You can’t transmit and receive at the same time over the same differential pair, so the two-wire version is limited to half-duplex. Full-duplex operation is possible when the bus includes two differential pairs.
  • Though a basic RS-422/485 transceiver doesn’t limit you to a specific serial-data format, the obvious choice here is a UART (universal asynchronous receiver/transmitter), because in general we’re working with one differential pair between transmitter and receiver—we don’t have extra lines for a slave-select signal (as in SPI) or a clock (as in I²C).
  • Information is transmitted via balanced differential signals. Thus, RS-422/485 provides all the benefits associated with differential signaling—improved noise immunity, reduced generation of EMI (electromagnetic interference), lower power consumption, higher speed. You can read more about differential signaling here.

 

         

Differential output waveforms generated by an RS-422/485 transmitter from Maxim Integrated.

 

  • Perhaps “moderate speed” is a bit too generous in this age of 5 gigabit/second USB connections. And actually, you can’t specify a single maximum data rate for RS-422/485 because system variables influence the frequency limit at which communication becomes unreliable.
    • The dominant variable here is cable length; this app note from Texas Instruments says that the data rate multiplied by the cable length in meters should be no greater than 108. So according to this rule of thumb, a bus with a very short cable could handle 100 Mbps, but this app note from Maxim indicates that a more reasonable upper limit is something like 50 Mbps. But then again, Intersil and Linear Technology sell RS-422/485 transceivers advertised at 100 Mbps, so it’s fair to assume that this data rate is feasible if you have the right IC and favorable bus conditions.

 

I Like It, and You Might Too

RS-422/485 characteristics—long cable lengths, robustness against noise, etc.—make it an excellent choice for industrial applications. However, part of my goal with this article is to demonstrate that RS-422/485 is a good option for many electronic and electromechanical systems, even if you don’t need all the functionality that it offers. My favorable view of RS-422/485 is based primarily on three considerations: design simplicity, excellent support from ICs and app notes, and noise performance.

 

Keep It Simple

Despite years of experience with various different serial communication protocols, UART is still my favorite. It’s simple and reliable, it requires minimal interconnections, and I wouldn’t be surprised to find that it is supported by every microcontroller on the market. It may be a little primitive, but you can always write some firmware to implement whatever flow control or device identification or error checking is required in your particular application.

Anyways, my point here is that I like to use UART whenever I can, and RS-422/485 is a great physical layer for UART communication.

 

Support from the Experts

It is easy to incorporate RS-422/485 into your design: just about all you need is a translator/transceiver IC, and there are many to choose from. These devices translate typical logic signals into RS-422/485 differential signals, and they handle whatever other pesky details are needed to ensure conformance with the RS-422/485 standard. And if you aren’t sure about how exactly to design your particular communication bus, you will find plenty of guidance in app notes and data sheets.

 

Noise

Noise concerns are not limited to industrial plants and avionics equipment. Noise sources are everywhere, and it’s always a good idea to incorporate a little robustness into your designs—especially if you have something like a brushed DC motor right next to your circuit board. RS-422/485, in conjunction with some shielded twisted-pair cabling, is an effective yet relatively painless way to design noise resistance into any electronic system.

 

Conclusion

I hope that this article has given you a clear idea of what RS-422/485 is and why it might be a good communication interface for your next system. In a future article I’ll discuss RS-422/485 electrical characteristics and implementation details.

 

Comments

1 Comment


  • kb1kenobe 2016-12-09

    Thanks, Robert, for the overview. I hope many AAC readers are compelled to incorporate RS-485/422 in their projects. As a long-time designer of industrial systems primarily using RS-485 half-duplex topology, I hope you’ll cover some of the application pitfalls in your upcoming articles. When properly implemented, RS-485/422 networks are field proven robust worldwide in critical control applications. When good practices are not applied, the networks can be anything but robust and extremely difficult to debug - particularly in the field. Interesting as well is the fact that there exists conflicting information, some from “experts” on the internet, about what good application practices should be. Regards, Ken