0

I'm trying to design a simple and reliable master/slaves protocol for a 2-wires RS485 bus.

All the nodes on the bus have a unique address. One node is the master that is the only node that is able to start communications. All other nodes can't send anything until the master sends a request to them.

I was thinking on simple "request/response" protocol: the master sends a request to a slave and wait for its answer. After that, M sends a request to another slave. Three scenarios could happen.

  1. Both frames (request and response) are correctly received by the destination and the transaction ends with no problem.
  2. The request from the master isn't received by the slave (checksum error). After a timeout, the master sends again the request. No problem.
  3. The response from the slave isn't received by the master (checksum error). After a timeout, the master could send again the request.

IMHO, the last scenario is problematic. The slave isn't able to understand if the second request is exactly the same of the first, so it processes the request two times. What happens if the request is "move the motor two steps", "give me if a switch is pressend since last request", "toggle a relay", and so on?

I think the simplest "request/response" protocol can't work well, except if the application level knows the limitations of the protocol and avoids requests that are dangerous if transmitted two times.

Have you some good simple and reliable protocol to suggest? I don't want to reinvent the wheel.

pozzugno
  • 750
  • 6
  • 19
  • 4
    Add some kind of sequence number to the request, the master on a re-send would send the same sequence number it sent the first time. The slave upon seeing the sequence number could compare it to the last received command and choose to ignore the action while still responding to the command – mocj Oct 23 '13 at 22:22
  • In scenario 3, you indicate a checksum error. If there was an error, wouldn't the slave not process the request? And shouldn't it send back a [NACK](https://en.wikipedia.org/wiki/Negative-acknowledge_character) indicating it didn't understand the request? – embedded.kyle Oct 24 '13 at 14:08
  • I was considering a checksum error in the response received by the master (or, if you want, if the master doesn't receive the response at all). – pozzugno Oct 25 '13 at 17:32

1 Answers1

0

I've recently come across HDLC on here as I was looking for something similar. It has an operating mode that may fit your needs. Normal Response Mode (NRM) is what you described: request/response only from the master. There is an open source HDLC framer that you may be able to use as the basis of the protocol. I am considering using this myself, but there still seems to be a fair amount that is left to the project developer to implement.

This is the answer I came across that pointed me in the direction of HDLC.

Community
  • 1
  • 1
rjp
  • 1,760
  • 13
  • 15
  • Thank you, HDLC suggestion is very good. Now the only problem is to implement this protocol or a subset on low-level 8-bit microcontroller, such as ATtiny family of Atmel. The open source HDLC implementation is only for PC. – pozzugno Oct 26 '13 at 13:40
  • The library portion would work on an ATtiny, but the demo and test code is all targeting a PC host. I'm not sure how memory efficient this library is, though. – rjp Oct 26 '13 at 16:27
  • I inspected the library with greater attention. It solves only the problem of syncronous framing (avoiding more than 5 consecutive bits in the frame), but it doesn't implement asyncronous framing (as for RS232/RS422/RS485 connection) nor the managing of tx/rx sequence number with the retransmission in case of errors. – pozzugno Oct 27 '13 at 21:37
  • That's correct. I thought it has asynchronous framing in it, but I must have been mistaken. The code was not all that well documented, so I was likely misinterpreting what certain functions were doing. – rjp Oct 27 '13 at 21:43