If I had to design a product that needed to be able to connect to either CAN or RS-485, I'd probably start by considering separate connectors or separate pins on the same connector for the two busses. The ground pin can be common if on the same connector.
Jumpers can be made to work, but users don't always set them right, especially if multiple jumpers need to be set a particular way, which is probably the case between RS-485 and CAN. Jumpers will also likely be more expensive and take more space than a connector with two extra pins.
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:
- The quiescent state is undriven, meaning the lines are held at the same voltage by the terminating resistances.
- 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:
- 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.
- 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.
- 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.
- 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.
Best Answer
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.