Running CAN bus with RS-485 transceiver

Question

Recently I had a discussion whether one could use RS-485 transceivers for a CAN-bus network in order to gain the flexibility to use the same hardware either in a CAN-environment or in half-duplex RS-485 network, albeit with different software.

^{simulate this circuit – Schematic created using CircuitLab}

The idea is to use a RS-485 bus driver as usual when utilizing the board in RS-485 setup. That this the transmitter is enabled by DEN when one wants to transmit and the bits are presented at the D input as usual. Additional pull-up and pull-downs are provided to ensure valid bus-level upon open bus lines.

When in CAN-Mode, the D input is tied low (dominant) and the DEN input is used to present the bit stream when transmitting. When DEN=1 (driver enabled) the bus is driven low (dominant), otherwise the line remains recessive. This should then mimic the open-collector nature of the CAN bus since only one state is actively driven while the other is only passively pulled by the pull-up resistors.

The part I consider is the SN64HVD11 and the SN65HVD230 as reference for a 3V3 CAN transceiver.

The driver-enable timings of the SN64HVD11 are given as max. 55ns and the fall time is bounded at 30ns which is less than comparative figures of the "real" CAN driver.

Has someone tried this before? Are there issues I might miss completely?

Clarification: the whole system is intended for a small-scale unmanned vehicle control in the academic domain thus interoperability with 3rd-party components is not deemed important.

Answer 1

It can probably be made to work, although I wouldn't call it a "production solution"!

One thing you'll need to do is invert the DEN signal as CAN is low-dominant, not high-dominant.

You'll also need to adjust the termination as although both CAN and RS485 are designed to be terminated by a single 120ohm resistor at each end of the bus, the additional bias resistors that RS485 usually includes will pull the bus lines to voltages slightly "either side of the centre-point", whereas CAN needs to idle recessive at ~2.5V on both lines.

IIRC, there is about 0.5V of differential voltage allowed before a dominant bit is detected.

Answer 2

This would work, but it would reduce the noise margin against either proper RS485 or proper CAN.

The big problem is at the receive end. CAN threshold is at 700mV typical (+500to+900mV). RS485 threshold is at 0V typical (-200to+200mV).

The termination network is only at each end of the RS-485 bus. This is designed to give around 200mV differential between A and B (Needed by RS485 transceivers to guarantee a "1" output).

For the RS-485 receiver, you end up with negative noise margin when looking for the non-dominant state on a CAN bus (in the worst case), as bog standard RS485 receivers have threshold specified as +/- 200mV, where CAN only promises 500mV. Some newer RS485 transceivers are -50mV typical, 0mV worst case, but these still won't detect 500mV as.

Using a newer transceiver, and swapping the "B" and "A" so that CANL is RS485A and CANH is RS485B, you would get an extra -200mV bias on the bus, so the RS485 receiver would have a better chance to detect the non-dominant state (The bias resistors would be pulling opposite to the dominant bit, so the RS485 transceiver will have a better chance of seeing the crossover).

It will take some work on the CPLD to invert in all the right places.

When I looked at this, I decided to fit both CAN and 485 transceivers, both connected to the bus, and add logic to ensure only one was active at a time.

Answer 3

Somewhere I heard that some of the earliest CAN applications used rs485. Not sure if modern CAN is still compatible but on the surface they look similar. The issue I see is that the RS485 transceiver might have a turn on delay after enabling the driver, but that would be mentioned in the datasheet.

But if the protocols really are similar enough, why not just add pull up/downs to the rs485 bus, and use a CAN tranciever for both tasks? CAN trancievers are the same price or cheaper and seem to have better fault protection that rs485 transceivers of the same cost.

That's if they are actually compatible, which I'm not sure of.