6
\$\begingroup\$

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.

schematic

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ The CAN-bus lines are idle at 2.5V. RS-485 is idle at 5V and 0V respectively. \$\endgroup\$ – Lundin Apr 29 '14 at 12:00
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ As far as I understand both CAN and RS-485 require termination at both ends only. For RS-485 bias resistors towards ground and VCC are often suggested to provide determinate logic level at open circuit - I'm wondering wether these bias resistors are supposed to be placed at every node. \$\endgroup\$ – Arne Apr 29 '14 at 15:22
  • \$\begingroup\$ Inverting the DEN signal should not pose a problem since the CAN controller is connected to the bus driver though a FPGA/CPLD anyway. \$\endgroup\$ – Arne Apr 29 '14 at 15:29
  • \$\begingroup\$ Pretty sure rs485 uses one set of bias resistors for the whole bus. They usually go near one of the two terminator iirc. \$\endgroup\$ – EternityForest Apr 29 '14 at 21:53
  • \$\begingroup\$ In that case, I misread the schematic as implying that termination and bias would be on every node. I still think the CAN will be potentially flaky if the RS485 bias resistors are there (even if only at the ends of the bus though) \$\endgroup\$ – Martin Thompson Apr 30 '14 at 9:48
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ This is the correct answer. The Tx side can be made to work, but the Rx side will operate at incorrect thresholds. Connecting both a RS485 and CAN transceiver to the same lines will increase capacitive loading, which can be a signal quality problem at high bitrates. \$\endgroup\$ – Timmy Brolin Sep 21 '18 at 22:25
0
\$\begingroup\$

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.

\$\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.