How do you design a serial command protocol for an embedded system? [closed]

Answer 1

I have some preferences (and pet peeves) from writing software to control media and display devices using RS232. Depending on your hardware, some of these may not apply:

• I think it's a good idea to make your protocol more friendly for automation. If you need an interactive interface (command line or other), build it separately and have it use the automation protocol. I wouldn't worry too much about making it human readable, but it's up to you.

• Always return a response, even (especially) if you get an invalid command. Something simple like $06 for ACK and $15 for NAK. Or spell it out if you want it to be slightly more human readable.

• If you can set any value, make sure there's some way to query that same value. If you have a lot of values, it could take a while to query them all. Consider having one or just a few meta-queries that return several values at once.

• If you have information that can't be set, but is important (model no, serial no, version, copyright, etc), make sure these can be queried instead of just displaying them once on startup or reset.

• Never respond with an error for a valid command. You'd think this one would be obvious...

• Speaking of obvious, document the serial settings your hardware supports. Especially if it's going to be used by anyone other than you and you don't want them to spend the first 30 minutes trying to figure out if they can't talk to the device because of the serial port, the connections, the cable or their software. Not that I'm bitter...

• Use absolute commands instead of toggle values. For example, have separate commands for Power On and Power Off instead of sending the same command and having the power toggle on and off.

• Responses should include information on the command they are responding to. This way any program doesn't need to remember the last thing it asked for in order to deal with the response (see extra credit option below).

• If your device supports a standby mode (off, but not really off), make sure queries still work while you're in this state.

Depending on how paranoid you are about data completeness:

• Wrap your message in an envelope. The header could include a starting character, the lengeth of the message and a closing character. Just in case you get partial or malformed messages. Maybe $02 for the start and $03 for the end.

• If you're really paranoid about message integrity, include a checksum. They can be a bit of a pain, though.

For extra credit:

• If your hardware settings can be changed manually, maybe send this change out the serial port as if the user had queried it. For example, you might not want the user to be able to change the input source for a public display monitor.

I hope this helps.

Update:

I forgot something important. Before you either use this seriously and especially before you give it out to someone else, try it out on something trivial to make sure it works the way you expect it to and (more importantly) to make sure you haven't left anything out. It will take more time and effort to fix things if you find a problem in the middle of a bigger project.

This is a good rule of thumb whether you're designing a command protocol, a web service, a database schema or a class, etc.

Answer 2

There are a lot of good suggestions and ideas here and notice that there are different ways to tackle it for different purposes. Having used many serial protocols both good and bad as well having made several of my own (both good and bad...) here are a few of my suggestions and comments.

• Keep it simple. I have found the greatest success with simple header based command-response "packets".

• Don't worry about human readable ASCII. It is only useful for the few hours you actually debug your protocol. After that it is restrictive to always encode data as ASCII and very inefficient if you transfer a lot of data.

• Use error checking. I prefer a 16 bit CRC as it provides orders of magnitude of protection over a checksum and is still simple and efficient over heavier algorithms like MD5 or SHA1.

• Use the same packet format for the commands as the responses.

• Use 8 bit data with no parity. Serial parity bit doesn't add anyprotection if you already use a CRCor other data integrity check and isa poor error check at best.

• So in the simplest form the packet header is the Command or Response, size of the packet, zero or more dataand the error checking code (CRC).

Answer 3

Have you looked at Modbus (http://www.modbus.org/)? It's a fairly simple protocol which includes a checksum on each message. It also sends a response to every command, even those which don't need a "return value", so you know if your command got received correctly. The only choice you would have after choosing Modbus would be the register addresses to store your data at, and the format of any user defined functions (which the MODBUS protocol allows).