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?

  • \$\begingroup\$ How many boards on a bus? What speeds should be supported? \$\endgroup\$
    – Justme
    Nov 22, 2021 at 12:29
  • 1
    \$\begingroup\$ Your thoughts sound correct. I guess, you may detect contention on RS485 with extra cost. But, it is easier with CAN PHY. First of all, if you have enough bandwidth (you need it anyway), you may be able to avoid the complexity of CSMA/CD. If we have to, I would call it "appointed master", which eventually establishes P2P switch on a BUS. BTW, I am on the same boat, started changing parts with available ones. Otherwise, wait about a year without promise. Eventually, ended up in completely new circuit boards, still competing with other engineers over limited stock. Sad..., who to blame? \$\endgroup\$
    – jay
    Nov 22, 2021 at 14:51
  • \$\begingroup\$ Bit banging CAN with external diff. amplifiers doesn't sound that crazy anymore, huh \$\endgroup\$ Nov 22, 2021 at 17:29
  • \$\begingroup\$ IMHO, you should stick to existing wiring and CAN transceivers. It will simplify transition when supply problems end. Monitor Rx state before beginning the transmission and use XOR gate on Rx/Tx routed to extra pin with interrupt to detect collisions during transmission. This way you can write UART driver that will behave almost like CAN controller, so your main code will not require many changes. You don't have to keep exact frame format, but make it byte-aligned and keep ID assignment the same. \$\endgroup\$
    – Maple
    Nov 22, 2021 at 18:08
  • \$\begingroup\$ @jay your "appointed master" is… token passing, just done by a central entity. Foundation H1 does that \$\endgroup\$ Nov 23, 2021 at 6:44

2 Answers 2


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.

  • \$\begingroup\$ You just described CSMA/CD; random backoff usually solves your timing issues \$\endgroup\$ Nov 23, 2021 at 6:47
  • \$\begingroup\$ @LorenzoMarcantonio: I would say no, because in what I described above, there is not a monitoring during transmission. That would improve further, but I am not sure that a device on RS-485 can sense exactly what the other devices receive, because of the delays on the line. It should not hurt either, anyway. \$\endgroup\$ Nov 23, 2021 at 7:48

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:


  • 3
    \$\begingroup\$ Why would you need two transceivers for a job that is commonly done with a single tranceiver? \$\endgroup\$
    – Justme
    Nov 22, 2021 at 16:27
  • \$\begingroup\$ For the collision detection, You would read the packet you sent. This is the easiest way to detect contention on the bus. An RS485 Transceiver is usually half duplex device (either RX or TX at any given moment). \$\endgroup\$
    – Lior Bilia
    Nov 22, 2021 at 17:27
  • \$\begingroup\$ MAX485-style 8-pin transceivers have separate driver enable and receiver enable pins (the second one often active low) that are commonly tied together to a single GPIO because you usually either transmit or receive. Nothing stops you from controlling them independently or tying receiver enable permanently low. One transceiver should be enough :-) \$\endgroup\$
    – filo
    Nov 22, 2021 at 21:13
  • \$\begingroup\$ no need for the second transceiver, either use a full duplex or simply tie the receive enable on the 8 pin parts for that! \$\endgroup\$ Nov 23, 2021 at 6:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.