0
\$\begingroup\$

Not sure whether this is too broad a question but... Why would one choose CAN Bus over RS485, or vice versa, as a system interconnect? I have a MCU SBC with multiple interfaces including the two mentioned. Feeding into that I have various sensors/transducers (up to 20 in total).

RS485 is the most common, but some also have CAN. The ones with CAN also have RS485.

In certain cases we cannot hang 2 device sets which have differing protocols if they automatically send NACK packets, because one device's perfectly good NACK is another's bad packet (and so sends a NACK...)

Given that all devices have short packets, and interconnects of length less than one metre, what other factors would mandate which to use?

\$\endgroup\$
  • 1
    \$\begingroup\$ One is a protocol and hardware definition and the other is a hardware definition that may be called-up by the former. This makes answers problematic. \$\endgroup\$ – Andy aka Oct 10 '18 at 11:35
  • \$\begingroup\$ I'd stick with CAN, because, as @Andyaka said, it's a complete protocol with errorhandling et al. \$\endgroup\$ – Alexander von Wernherr Oct 10 '18 at 11:43
  • \$\begingroup\$ You might reconsider the "NACK" portion of your question. What you describe means only badly designed high-level protocol, which has nothing to do with a choice between CAN and RS485. Note that ACK in CAN is not "true" ACK, since it only confirms valid packet received by any node. \$\endgroup\$ – Maple Oct 10 '18 at 13:55
  • \$\begingroup\$ @Maple We don't get to choose the protocol of the transducers we use. If one gets a bad packet, it sends a NACK \$\endgroup\$ – Dirk Bruere Oct 11 '18 at 7:52
  • 2
    \$\begingroup\$ That is exactly my point! Why would there be bad packet in the system to begin with? If you are connecting devices with different incompatible protocols to the same bus you are asking for trouble. As I said, there is no such thing as "NACK packet" in CAN. Which means it can only be higher-level protocol that sends some packet that means NACK for receiver. If this packet is malformed from the other devices's point of view it is bad design. \$\endgroup\$ – Maple Oct 11 '18 at 14:15
4
\$\begingroup\$

The main difference is that CAN supports multi-master operation through non-destructive arbitration. It has a wired-AND structure. In other words, with RS485 you need to have a mechanism for coordinating devices to ensure that more than one device does not try to transmit at the same time. With CAN bus this is not a problem.

The usual way to solve this issue with RS485 is to define a single master device (your SBC for example) that polls each sensor on the network. This can work fine. The main disadvantage compared with CAN is that there is a single point of failure (your master) though in your case that isn't a real problem, since if the master goes down then there is nothing to use the sensor data anyway. Depending on your sampling/polling scheme CAN may also offer better latency, since sensors can autonomously transmit data as soon as it is available.

As other answers note, CAN also defines more layers of the protocol than RS485, but in practice you can emulate much of this functionality apart from that which relies on the bus level arbitration.

\$\endgroup\$
  • 1
    \$\begingroup\$ I think the problem is with OP question, which should read "why would one choose RS485 over CAN", an answer to which would be cost consideration. \$\endgroup\$ – Maple Oct 10 '18 at 14:01
0
\$\begingroup\$

RS485 only addresses layer 1 (PHY) and CAN also adds layer 2 (PHY & DATA) in the OSI model.

It is possible to compare , but better to define your bus requirements for every layer, then decide.

E.g. Consider a CNC machine with 3 axis XYZ, RPM spindle and water pump etc . Maybe some GUI only works for serial ports like GRBL code with multiple peripherals within 1 m and you have a great Layer 7 software open source, so you choose this and make sure your USB adapter has a big ferrite choke going between SMPS powered floating target and earthed PC tower. So why CAN or RS485 ?

\$\endgroup\$

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.