Good RS232-based Protocols for Embedded to Computer Communication

Some embedded system protocols, several of them extremely simple, are listed at Embedded Systems: Common Protocols, including:

• Tiny Embedded Network (TEN)
• Microcontroller Interpreter for Networked Embedded Systems (MINES)
• Yet Another Scalable Protocol (YASP)
• Local Interconnect Network (LIN)
• Serial Servo Controller (SSC)
• Robot Operating System serial (rosserial)
• netstring
• various field busses
• Modbus
• Controller Area Network (CAN)
• Firmata (Thank you, jippie!)

Perhaps one of these protocols would be adequate for your application as-is, or with only minor tweaking.

I'd vote roll your own, and keep it as simple as possible.

I've dealt with lots of serial protocols for various control applications, and a few things that I can recommend you include are:

• Start & stop characters which are not used elsewhere
• Some sort of checksum / error checking
• Some method of flow control / signalling, especially if you need bi-directional comms.

As a very basic example, you might convert your data to ASCII characters and stick it inside start/stop characters like this:

To send the byte value 0x7A, the data sent would be (7A), where the () are the chosen start/stop chars and 7 and A are two ascii chars. OK it addds a lot of overhead, but it means you can debug with basic terminal software.

If your data is going through XBees, you should put the modules into API mode with escape characters, divide your data into logical packets, and take advantage of the fact that in API mode a packet which is given to an XBee will either arrive intact or not at all. Design your protocol around the transmission of chunks of 1-255 bytes, and let the XBee modules worry about how to deliver the data within each chunk. Don't worry about maintaining the integrity of individual packets or the subdivisions between them. The Digi modules will do a good job of taking care of that. The biggest thing you do need to worry about is the fact that even if the node that transmits a packet believes it wasn't delivered and sends a replacement, the recipient may end up getting it anyhow--possibly even after it gets the replacement. Things may be easiest if you design your protocol so that one side is the "master"; if the master asks for a piece of data, the slave should send it once and not worry about whether the master gets it. If the master doesn't get the data that it wants, it can request it again.

The slave should assign some sort of sequence numbers to data, and the master should assign sequence numbers to requests that the slave change state. If the master's request is of the form "send the first item whose sequence number is greater than XXX", and each piece of data item by the slave includes its own sequence number and that of the previous item (if they're not numbered consecutively), late-arriving packets may cause the slave to redundantly send data to the master, but the master will have no difficulty ignoring the consequent late-arriving responses. If the slave receives a state-change request whose sequence number is below that of an earlier request, it should ignore the that request, since it was superceded even before it was received.