6
\$\begingroup\$

In comparing the physical layer of CAN and RS485, I am trying to find the advantages of either one over the other. I found out that they are quite similar. Both are good in terms of common mode rejection and both need protection against ESD and overvoltage. I found just one significant advantage of CAN over RS485 (regarding the physical layer) in which CAN has a fault tolerant mode which enables it to maintain the connection between CANbus nodes through just 1 data wire even though there is one data wire shorted or opened or both data wires are shorted together.

Away from collision avoidance and the message priority system that CAN has,

1. Does RS485 have the same fault tolerant mechanism?

2. Are there any other important advantages or differences between CAN and RS485 regarding the physical layer?

\$\endgroup\$
  • \$\begingroup\$ Maybe you could link to the CAB bus fault tolerance mode? \$\endgroup\$ – Andy aka May 10 '17 at 12:43
  • \$\begingroup\$ This pdf is talking about the fault tolerant feature of TJA1055T CAN transceiver. \$\endgroup\$ – Macit May 10 '17 at 12:48
  • \$\begingroup\$ The main difference is the bus arbitration of CAN, which means that the network topology is flexible and there is no need for a master to control traffic. In RS-485 there is no built-in mechanism to toggle who gets to send, meaning that RS-485 tends to end up in a star network topology centred around a master. This is dictated on the higher levels, but affects the physical level dramatically. \$\endgroup\$ – Lundin May 18 '17 at 11:15
  • \$\begingroup\$ Overall, there is really no reason to use RS-485 and other UART-based technologies today, unless you need some manner of backwards compatibility. One benefit used to be that all PC computers had UART, but that is no longer the case. \$\endgroup\$ – Lundin May 18 '17 at 11:18
8
\$\begingroup\$

When comparing the physical layer only, CAN and RS-485 are similar in that they both use differential signaling. This gives them both good common mode noise immunity.

The main difference is that RS-485 uses symmetric signaling. One line is 5 V and the other 0 V to signal one state, then flipped to 0 V and 5 V for the other state. This makes detecting the state very easy (a simple comparator, maybe with a little hysteresis), but presents a challenge in terminating the bus.

If you think the twisted pair carrying the signals has 120 Ω characteristic impedance, then ideally you want to put 120 Ω between the two lines. That would be 60 Ω total between the two lines. (5 V)/(60 Ω) = 83 mA. That's a lot of current for the bus, and would be drawn all the time. That comes out to nearly half a Watt quiescent power. Note that each 120 Ω terminating resistor would dissipate 208 mW, which means they'd have to be "¼ W" resistors minimum. 0805 surface mount, for example, need not apply.

Probably due to these considerations, the terminating requirements for RS-485 are somewhat relaxed. That results in a reduced usable bus speed. That's OK for most RS-485 applications since they typically run at common baud rates, rarely above 115.2 kBaud.

CAN on the other hand address termination properly. It assumes 120 Ω twisted pair is used for the different signals, and specifies 120 Ω terminating resistance at each end of the bus. There are then two important differences to avoid the problems described above:

  1. The quiescent state is undriven, meaning the lines are held at the same voltage by the terminating resistances.

  2. The active bus state (called the dominant state in the CAN spec) is each line pulled only 900 mV from the idle level. The two states are therefore 0 V or 1.8 V differential, not 5 V and -5 V like RS-485.

The power to keep a CAN bus in the dominant state is only 54 mW, and none at all to keep it in the recessive (idle) state. CAN is intended for speeds up to 1 Mbaud, made possible by better termination than RS-485.

Another major difference between CAN and RS-485 already alluded to is that RS-485 is actively driven to both states, while CAN is only ever driven to the dominant state, with the bus itself relaxing to the recessive state. This makes a significant difference at higher protocol levels to bus arbitration.

So what to use? CAN is the clear choice for new designs in most cases because:

  1. The low level signaling allows for a collision detection scheme. When a node is "writing" the recessive state to the bus and sees it is actually in the dominant state, it knows some other node is driving the bus. The node trying to write the recessive state backs off and waits for the end of the message. The node writing the dominant state never knows this happened. Its message is sent and received by all other nodes normally.

  2. This collision detection capability allows for peer to peer network architectures without any central arbitration. Nodes simply send messages, but back off when collision is detected, then retry after the current packet completes. Eventually those other messages are sent, the bus is available, and the previously-collided messages are sent without collision.

  3. CAN specifies much more than just the physical layer, whereas that's all you get with RS-485. There is no standard way in RS-485 to decide who gets to send, what is being sent, how to know it got there intact, etc. CAN specifies complete packets on the bus, which include a 16 bit CRC checksum.

  4. Since several protocol layers above the physical are specified with CAN, the logic to implement them can be built into off the shelf hardware. You can find small and cheap micros with hardware that sends and receives whole CAN packets. This hardware automatically takes care of packet start/end detection, collision detection, back off, retry, checksum generation and verification, and a few more capabilities related to dealing with hardware faults.

    In contrast, with RS-485 you get a UART and the rest is your problem. While it is certainly possible to implement a robust protocol above RS-485, it's not as easy to get all the corner cases right as naïve engineers think.

One limitation of CAN that may require work around for some applications is the limit of 8 data bytes per packet. This is also a good thing for the collision/retry mechanism, but is something you have to consider if you intend to pass streaming data over CAN. However, doing the same with RS-485 isn't as trivial as it might appear at first glance either.

\$\endgroup\$
  • \$\begingroup\$ "Probably due to these considerations, the terminating requirements for RS-485 are somewhat relaxed. That results in a reduced usable bus speed." I don't know exactly what you mean by saying that but RS485 can achieve a bit rate up to 10Mbit/s which is 10 times higher than what CAN could afford. \$\endgroup\$ – Macit May 10 '17 at 14:11
  • \$\begingroup\$ What about the fault tolerant mechanism? Does RS485 have such a feature? \$\endgroup\$ – Macit May 10 '17 at 14:12
  • \$\begingroup\$ @Maj: For short lengths, RS-485 can go fast. However, if a typical twisted pair transmission line is used, the ends will not be terminated properly. \$\endgroup\$ – Olin Lathrop May 10 '17 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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