Simple serial point-to-point communication protocol

Solution 1:

I would use HDLC. I have had good luck with it in the past. I would for a point to point serial just use the Asynchronous framing and forget about all of the other control stuff as it would probably be overkill.

In addition to using HDLC for the framing of the packet. I format my packet like the following. This is how options are passed using 802.11

U8 cmd;
U8 len;
u8 payload[len];

The total size of each command packet is len +2

You then define commands like

#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02

The other advantage is that you can add new commands and if you design your parser correctly to ignore undefined commands then you will have some backwards compatibility.

So putting it all together the packet would look like the following.

 // total packet length minus flags len+4
 U8 sflag;   //0x7e start of packet end of packet flag from HDLC
 U8 cmd;     //tells the other side what to do.
 U8 len;     // payload length
 U8 payload[len];  // could be zero len
 U16 crc;
 U8 eflag;   //end of frame flag

The system will then monitor the serial stream for the flag 0x7e and when it is there you check the length to see if it is pklen >= 4 and pklen=len+4 and that the crc is valid. Note do not rely on just crc for small packets you will get a lot of false positives also check length. If the length or crc does not match just reset the length and crc and start with decoding the new frame. If it is a match then copy the packet to a new buffer and pass it to your command processing function. Always reset length and crc when a flag is received.

For your command processing function grab the cmd and len and then use a switch to handle each type of command. I also require that a certain events send a response so the system behaves like a remote procedure call that is event driven.

So for example the sensor device can have a timer or respond to a command to take a reading. It then would format a packet and send it to the PC and the PC would respond that it received the packet. If not then the sensor device could resend on a timeout.

Also when you are doing a network transfer you should design it as a network stack like the OSI modle as Foredecker points don't forget about the physical layer stuff. My post with the HDLC is the data link layer and the RPC and command handling is the Application Layer.

Solution 2:

RS232 protocols are tricky. The suggestion to use HDLC, is a good one, but its not the entire solution. There are other things you need to decide:

• How will the baud rate between the two devices be determined? Autobuad? Predefined, or set explicate?
• Will you do flow control in software or hardware or both? Note, if you use hardware flow control then you must make sure, that the cables are built correctly.
• Speaking of cables, this is a huge pain with RS233. Depending on the device, you may need to use a straight through cable, or a cross over cable, or a variant.
• Using a software based flow control mechanism can be effective as it allows the most simple cable to be used - just three wired (TX, RX, and common).
• Do you pick a 7 or 8 bit word?
• HW parity or software error checking.

I suggest you go with 8 data bits, no hardware parity, 1 stop bit, and use software based flow control. You should use autobaud if your hardware supports it. If not, then autobaud is devilishly difficult to do in software.

Solution 3:

I read this question a few months back, having exactly the same issue, and didn't really find anything efficient enough for a tiny 8-bit micro with tiny amounts of RAM. So inspired by CAN and LIN I built something to do the job. I called it MIN (Microcontroller Interconnect Network) and I've uploaded it to GitHub here:

https://github.com/min-protocol/min

There are two implementations there: one in embedded C, one in Python for a PC. Plus a little "hello world" test program where the PC sends commands and the firmware lights an LED. I blogged about getting this up and running on an Arduino board here:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

MIN is pretty simple. I fixed the layer 0 representation (8 data bits, 1 stop bit, no parity) but left the baud rate open. Each frame starts with three 0xAA bytes which in binary is 1010101010, a nice pulsetrain to do autobaud rate detection if one end wants to dynamically adapt to the other. Frames are 0-15 bytes of payload, with a 16-bit Fletcher's checksum as well as a control byte and an 8-bit identifier (to tell the application what the payload data contains).

The protocol uses character stuffing so that 0xAA 0xAA 0xAA always indicates start-of-frame. This means that if a device comes out of reset it always syncs with the start of the next frame (a design goal for MIN was never to pass up an incomplete or incorrect frame). This also means there's no need to have specific inter-byte and inter-frame timing constraints. Full details of the protocol are in the GitHub repo wiki.

There's room for future improvements with MIN. I've left some hooks in there for block message passing (4 bits of the control byte are reserved) and for higher-level negotiation of capabilities (identifier 0xFF is reserved) so there's plenty of scope for adding support for commonly required functionality.

Solution 4:

There are some good answers in here, here are some useful pointers:

Even if your packets are not time-separated, the sync byte is an essential way of reducing the number of places you need to attempt to construct a packet from. Your devices will often have to deal with a bunch of junk data (i.e the end of a packet in flight when they turned on, or result of a hardware collision). Without a sync byte you will have to try to make a packet out of every byte you receive. The sync byte means that only 1/255 bytes of random noise could be the first byte of your packet. Also FANTASTIC when you want to snoop on your protocol.

Having an address on your packets or even just a bit saying master / slave or pc / device is useful when you look at the packets via a snoop tool of some type or another. You might do this by having a different sync byte for the PC than the DEVICE. Also, this will mean a device will not respond to its own echo.

You might want to look into error correction (such as Hamming). You package 8 bit of data into a 12 bit protected byte. Any one of those 12 bits can be flipped en-route and the original 8 bits retrieved. Useful for data storage (used on CDs) or where the device can't re-send easily (satellite links, one-way rf).

Packet numbers make life easier. A packet sent carries a number, responses carry the same number an a flag saying "response". This means that packets that never arrived (sync corrupted say) are easily detected by the sender and in full-duplex mode with a slow link, two commands can be sent before the first response is received. This also makes protocol analysis easier (A third party can understand which packets were received with no knowledge of the underlying protocol)

Having a single master is an awesome simplification. That said, in a full-duplex environment it does not matter much at all. Suffice to say you should always do it unless you are trying to save power or you are doing something event driven at the device end (input state changed, sample ready).

Solution 5:

My suggestion is modbus. It's an efficient and easy standard protocol for communication with devices that has sensors and parameters (for example a PLC). You can get the specifications at http://www.modbus.org. It’s been around since 1979 and is gaining in popularity, you will have no problem finding examples and libraries.