I was advised to use RS485 since I have about 7 devices needing to talk to each other (and cannot get CAN to work).

Although I want to start simple (two devices where one sends and other receives), later there might be multiple senders. One of the can be seen as Master, but others also should be able to initiate messages. So I need some kind of polling protocol.

The problem is, in RS-485 every time a device sends a message, all devices will 'hear' it and have to process it (although it's mostly checking one byte to know it's not meant for them).

But if I would get like 100,000 messages per second (worst case), this still cost a lot of processing time. And the master device (who initiates most) needs to do quite some non communication related processing.

How can I reduce the polling? I was thinking of decoupling the master device directly from RS-485 by adding some kind of communication device that passes RS-485 back/forth the master (e.g. via SPI). However, this seems a strange solution (converting back/forth all messages via SPI, also latency will be affected).

Or using some dedicated line (like one of the RS485-A/B lines) that devices can set HIGH to announce they have data. But I'm not sure if I should treat this equally as a RS-485 signal (so essentially having 1.5 RS-485 signals).

  • 3
    \$\begingroup\$ Some MCUs have a USART capable of detecting the address word (with 9'th bit set) and generating interrupt or triggering DMA. \$\endgroup\$ – Eugene Sh. Jul 17 '18 at 14:30
  • 1
    \$\begingroup\$ They have something called "mute mode" \$\endgroup\$ – Eugene Sh. Jul 17 '18 at 14:47
  • 1
    \$\begingroup\$ The USART enters mute mode when an address character is received which does not match its programmed address. In this case, the RWU bit is set by hardware. The RXNE flag is not set for this address byte and no interrupt nor DMA request is issued as the USART would have entered mute mode. \$\endgroup\$ – Eugene Sh. Jul 17 '18 at 14:48
  • 1
    \$\begingroup\$ As far as I understand you do not need it in conjunction, each one will work on it's own. If I understand the concept, the USART will wake on the detected address, I.e. will start generating RX interrupts (and others), you do your processing and put it back to mute, where it won't interrupt until the next matching address. \$\endgroup\$ – Eugene Sh. Jul 17 '18 at 15:01
  • 1
    \$\begingroup\$ I know you say you don't want to try again with CAN, but keep in mind that once you start thinking about robust error detection and recovery, maintaining data consistency across devices (one sees an error, another doesn't), dealing with a loss of frame synchronization, prioritizing operation when the bus is congested, dealing with a node that goes crazy and keeps transmitting etc etc, the CAN bus can save you a huge amount of wheel re-invention. \$\endgroup\$ – Jon Jul 17 '18 at 15:41

How can I reduce the polling?

Considering the advantages of CAN bus i.e. the peer-to-peer protocol and, considering how it works - devices with a lower address naturally override devices with higher addresses, I can see a way something like this might work on RS485 but with limited devices.

It is assumed that all 7 devices can recognize the end of a previous valid message. When this happens, each device counts a period of time proportional with its address (1 to 7 time-slots) but dutifully checks to see if the bus has become active by a device with a lower count. If that happens then that device gives up and waits until the message ends and tries again.

If the device in question reaches "its count" and the bus has not become active then it takes control.

This protocol is only really useful when the number of devices is low because hundreds of devices would waste a lot of time BUT, 7 devices will likely be quicker than sending a typical address byte.

To complete the cycle, if there are no devices wishing to communicate, one device (probably the last one) must issue a short message that resyncs the cycle back to the beginning again.

You have to decide on the length of the time slot carefully - it cannot be so short that a distant device thinks it can take bus control but in fact it just hasn't seen another device take bus control but CAN has the same problem potentially.

| improve this answer | |
  • \$\begingroup\$ CAN is actually still my preferred way but I spent so much time I refuse to try again shortly. But your idea is very cool. The timing is tricky but might work well. I have initially just 3 devices, later max. 10 probably, so that's still ok. When I run into issues I will try this method, good to know a better idea exist (which I didn't doubt, being a novice). \$\endgroup\$ – Michel Keijzers Jul 17 '18 at 14:58
  • 1
    \$\begingroup\$ @MichelKeijzers and in all probability it has already been invented! Original thinking is usually best when done before anyone else and I very much doubt that this kind of idea hasn't already been implemented! \$\endgroup\$ – Andy aka Jul 17 '18 at 15:00
  • 2
    \$\begingroup\$ @Andyaka - one of the in-house lighting control protocols I work with uses a time-slot based RS485 addressing scheme very much like you describe. We allow up to 120 devices on a subnet, but overall throughput isn't critical so the delays are acceptable. \$\endgroup\$ – brhans Jul 17 '18 at 15:18
  • 1
    \$\begingroup\$ @Andyaka That is why I ask the question here, and also knowing in advance if there is a solution in case I get into problems. \$\endgroup\$ – Michel Keijzers Jul 17 '18 at 15:26
  • 2
    \$\begingroup\$ It's proprietary, so the details are not published, but it's named here as the "Fresco Control Network" and supports 24 of these + 96 of these on a subnet. \$\endgroup\$ – brhans Jul 17 '18 at 17:44

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.