Alternatives to CAN for multi-master transmission

Question

As usual these days I'm fighting against component shortage. As in completely redesigning boards since they give us lead times in the 2023 years.

At the moment I have this product line where the boards talk to each other via CAN over cat-5 cable; for historical reasons the MCUs do not have an embedded controller and we are using a mix of Microchip and TI SPI connected CAN controllers (by the way the latest Microchip and the TCAN455x family are essentially the same Bosch IP wrapped inside a SPI). Too bad that they are now unavailable in substantial quantities so I need to redesign the whole architecure.

My first idea would be RS485: substantially the same medium but no arbitration. The big problem is that the whole architecture is multimaster, not master slave like, say, modbus. I have a designated network master for various purposes but most communication is peer-to-peer.

As discussed in Can RS485 be considered a multi-master bus? the real issue is bus contention which can be straightly damaging (depending on the kind of transceiver, the good ones simply go in current limitation).

Link layer is completely under my control. I'm thinking about some kind of token passing arbitrated by the network master (if it fails it is admissible to bring the network in stop).

Is there some other alternative? Another idea could be to use CAN transceivers instead of RS485 ones to gain the dominant/recessive properties and going CSMA/CD (listening for the results on the line). Traffic is periodic but there is spare bandwidth and the bus is short (under 10m) so collisions should be manageable. Ethernet seems overkill and needs an hub (well, excluding old style coax ethernet:D). Am I missing some useful technology that can be used here?

Answer 1

If your bus is little busy, and you can accept some lag, then I think it is doable with RS-485.

A few years ago I did a multi-master system on a RS-485. Every packet contained source and dest address, and a "type" of packet. Types under 128 were the originating command, and had to be acknowledged by the destination node with the same command+128 (you can't assume that a packet has been correctly received, no?).

Every device listens continually to the bus. Of course, when characters are traveling, the bus is not free. When a packet is finished, an analysis is done in order to understand if it can transmit or not:

1. If the packet must be acknowledged (the device is the target of the command), then the bus is free.

2. If the packet is a command, then the bus will not be free for a certain time: the destination node will reply.

3. If a packet is an acknowledge, then the bus is (momentarily) free.

The "momentarily free" is a situation where every device potentially could start a transmission. From that moment, every device waits for a number of hundredth of second depending on its own address: lower the address, more priority granted. The master (yes, there was a node more important than others), which had address 1, was always free to send a packet. A device with address 12 had to wait always 12 cs before trying to transmit, but that was perfectly acceptable.

The scheme above reduces the possibility of collisions, but can be relaxed, for example if the latency time is divided by 10, a device with address 12 just waits for 1 (well, 2) cs, and there is a collision only if another device in the range 10-19 tries to do the same.

To be sincere, I did use that pre-calculated delay only after having tried two other systems.

First system did not have any bus arbitration. In case of a collision, the sending node simply resended the packet until acknowledged. The imprecision of the clock of the various devices, soon or late, gave at every device the chance to initiate a communication.

Sometimes, however, two devices were competing for several seconds, disturbing each other. So I augmented the wait time (for an ack) for the sending node, basing on its address, and it worked quite well. But, lately, I found that it was best to try to avoid collisions as much as possible, and preferred to introduce that fixed delay. Everything depends on the application.

Answer 2

Can RS485 be considered a multi-master bus?

In principle yes.

Bus contention in this context can be done using two RS485 transceivers: one writes data and the other reads and confirms or not the data written by the other.

That is quite expansive though especially in these days of chip shortage.

---

If you can't use two RS485 transceivers per node than you might use the back-off and retry technique explained here, without the listen-before-talk part:

https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_avoidance