Master slave protocols for embedded devices

I'm trying to review the serial protocol we're using to connect multiple boards in our device. The device is made of 5 boards, 1 master and 4 slaves, connected through a RS422 serial link. Regarding the OSI layer 1 protocol, we're already using some scheme with a CRC that ensures that the data are transmitted correctly between any slave and the master. I'm looking for some tested protocol to govern the communication, which is now done round robin, with a fixed time window for each slave. If the slave doesn't respond for some fixed time after being messaged, then the device halts, since it really needs to make sure that everything is working perfectly. These fixed windows have given us more than one headaches in the past, since they need to be calculated based on the maximum length of a message to be transmitted, so every time one needed to add some message, then she needed to recalculate each window. Moreover, the kind of messages that are passed are tightly packed, with a starting configuration word that has a bit signalling the presence of each message in the following data, plus a bit that adds a second level, to accomodate more messages. This way of working is problematic, too, because each message needs to be allotted its own configuration bit.

Are there any tested and standard "scheduling" algorithms we could/should use, and are there any clearly defined, standard and easy to implement protocols that are widely used?

Thanks for any link/help!

Reply to
metiu
Loading thread data ...

Hmmm, the simplest thing is to throw out the windows and have the master do a round-robin poll for each unit, though the service cycle time will vary, but you presumably must already allow for worst-case communication. Is there a problem using such a scheme without the fixed time windows? There would be a response timeout period for each poll message.

--
Thad
Reply to
Thad Smith

I recommend you dump the RS422 medium for RS485. This greatly simplifies having multiple slaves respond to polls. Then you place a maximum length on a message, which in turn governs the polling frequency. In addition you divide the polls up into an active and an inactive group.

A peripheral moves from the inactive to the active group by responding to a poll, and the inactive group is polled at a much slower rate that the active group. Possibly once per round of active polls. Only the master need keep track of the groups. Various schemes are possible to validate a response that moves to the active group. Keep such subsidiary to the basic mechanism.

Something moves from active to inactive by simply failing to respond to a poll for some period of time.

Each message has to include source and destination identification, together with length and crc or equivalent validation. This makes direct unit to unit communication possible, controlled by the master.

This will make your communication path 4 wires (2 twisted pairs) plus a common mode reference line. It will be relatively insensitive to reasonable module separation, and quite insensitive to noise.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

You should ask yourself, what is the maximum interval allowed between slave updates and start the polling cycle at that interval.

You have to make sure that with the _longest_possible_ messages, all the required messages are transferred within the polling cycle at the line speed used. If the protocol uses transparent characters to flag some protocol characters within the actual data, the worst case message size can be doubled. Your current system with fixed slots should work fine.

You should simply accept the fact that in most cycles there are idle periods after all communications have been done with a specific slave until it is time for the next slave time slot !

Long idle periods could even be used to transfer a few bytes of low priority non-realtime "nice to have" data. If the realtime data would be close to the maximum and filling up nearly the whole time slot, the low priority transfer would simply be omitted during this slot, thus delaying the transfer of low priority data until the real time messages are shorter.

Paul

Reply to
Paul Keinanen

Huh? I don't understand. RS422 and RS485 are virtually the same thing, except that typically one uses RS422 in a five-wire full-duplex context, and RS485 in a three-wire half-duplex context. What you describe (5 wires) is effectively RS422, but with better (more modern, more robust) RS485 transceivers. I don't see how it affects the architecture. What am I missing?

Steve

formatting link

Reply to
Steve at fivetrees

I may be missing your point, but I *have*done plenty of RS485/RS422 comms. The length of the messages shouldn't matter [1] - it's the time between the master ending its send and seeing the start of the response which needs to be subject to a timeout.

[1] If you're saying that your scheduling system can't cope with the time taken to send a message, wait for a response, and then receive and process the response, then your scheduling system has more serious problems - as in it's inappropriate ;).

Not really. I typically use a state machine where each state is subject to a timeout. This doesn't break up time into fixed timeslots, merely into

*maximum* timeslots.

Steve

formatting link

Reply to
Steve at fivetrees

At least I assumed that the OP was referring to a "4 wire RS-485" network in which the master is a simple RS-422 device and the multidrop slaves all listen to the master RS-422 pair and all the slave transmitter signals are tied to the tri-state "RS-485" pair. Of course no such standard exists, but this configuration is commonly used.

Paul

Reply to
Paul Keinanen

Agreed. Hence my confusion at the suggestion that moving from 422 to 485 would make a significant difference.

(Having said that, 485 is a better standard - and 485-class devices are more robust. I wouldn't use 422-class devices these days, even for a 5-wire system.)

Steve

formatting link

Reply to
Steve at fivetrees

Hi Metiu,

Why don't you use CAN communiaction. Of when pricing is important you can use LIN communication. Works very good. I'm a software engineer at Nedap Specials Automotive in The Netherlands. We often use LIN for our test-equipment. Please take a look on my site:

formatting link
then go the the LIN section.

Kind regards,

John Ploeg

Reply to
John Ploeg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.