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

Answer 1

FTP is an example of a protocol that works reasonably well both interactively and with automation. One key is that responses start with a code that indicates whether an automated client should pay attnetion or not. Similarly for POP3.

One nice thing about those protocols is that when your developing/debugging you can reasonbly drive the communication from a regular terminal or script the communication using regular shell scripts/batch files/whatever.

However, one thing they don't do is provide reliability - that's provided by a lower layer of the comm stack. It's something that should be considered in most embedded communication pahs.

Answer 2

I like Bruce McGee's answers. Having worked with similar interfaces I can offer several other pointers:

• When returning numeric types in a data packet, please please PLEASE try to make everything the same format. Don't have single for some numbers and double for others. And don't make it arbitrary!

• Provide examples for data packets in your ICD. It's terribly frustrating to have to guess at byte order or even bit order (is MSByte first, or last? What is first and last?). Provide a diagram that shows packets vs. time (ie, 0x02 is sent earliest, then the address byte, then the message id, etc).

• Don't switch around between data formats if at all possible. I've worked in systems that use 'ASCII-encoded numbers' for some messages where you have to strip the leading '3' off of the bytes, then pull them together to make the real number. (Usually ASCII-encoding is used when you have a byte sequence you have to avoid, like 0x02, 0x04, etc. Encoded the numbers would be 0x30, 0x32, 0x30, 0x34. Use a length field if possible to avoid this, or at least do it all the time!)

• Definitely definitely definitely document the baud rate, parity, etc. If you're using RS-485 document the bus mode (2-wire? 4-wire?) or whatever settings will appear on the machine that you intend this to be used on. Give screenshots if you have to.

This interface will probably be very useful for debug. I've worked with some systems that had debug features such as:

• A system where the programmer made a list of 'logged parameters' (internal variables). You would tell the system which ones you wanted reported (up to 8) and then when you queried the system for the logged parameters it would return them in one data packet. I liked this, but depending on the complexity of the system you may or may not be able to specify them at run-time (or you could do something simple and send the system a mask that would select the ones you want returned).

• Data packets that 'break' behavior and allow parts of the system to be tested independently (ie, on a D/A put out this voltage, on a DIO port stim this byte, etc)

Good luck!

Answer 3

Here is a great article by Eli Benderski on serial protocol framing. Whatever the packet format you chose, be sure to use escape characters. It allows you to have such characters inside actual data and makes it really easy to re-synchronize in case of packet corruption.

Answer 4

Take a look at Firmata as an example protocol.

Answer 5

If you must have your own protocol,

Please please please use packet framing.

SLIP Framing only a few lines of code. Specified in (RFC 1055)

So now all packets can always look like this

 <slip packet start>
 message
 message crc
 <slip packet start>

Don't send a message length. It can get corrupted and then the receiver message parsers get confused.

If your receiver has a small receiver buffer and it overflows, you just keep reading till the packet boundary. No harm done.

Plenty of simple 2 byte CRC's; the Xmodem one is easy. You can just xor all the bytes in the packet it you must.

If you wanted to be a really nice person, use PPP, DDNS and HTTP-REST for your actual commands. Lovely book on doing this on 16 series PIC processor in C by Jeremy Bentham, TCP/IP Lean.

Then you can use a web browser to talk to it, or something like libcurl from C code. As almost every programming language has libraries to do http, everyone can talk to your device.

Answer 6

Unless bandwidth or latency is a big issue, use ASCII where you can - it makes debugging much easier.

I'm fond of protocols that send a message then a clear 'message end' character (such as 'carriage return'). I don't generally find start of packet signals to be that helpful (what else is on that wire?) Using CR for message end also makes it easier to test via terminal program.

Update: Bruce pointed out (in the comments) that a start of packet character lets you find the packets slightly quicker in the case of corruption. Without the start of packet character, it would take until the end of the next packet before you knew where you were and at that point you'd be throwing out 2 packets instead of one.