Any communication protocol must define the format of the message so that both sides know how to send/receive the data. Any (robust) protocol must also include some kind of error checking.

Whether you use a linear or circular buffer is not important at the protocol level. The decision between circular and linear is an implementation issue, not a protocol issue. A circular buffer can work for either binary data or text, as can a linear buffer.

Your comment that a circular buffer would only work if the message text was between STX and ETX is not necessarily true--it depends how you implement it. If you know where the buffer stars and where the buffer ends, you know that everything in between those two is data--whether it is binary or text is not important as far as the buffer goes. The buffer stores whatever comes in. It's up to the program to interpret that data.

Both types of buffers must take into account the possibility of corrupt data and overflows. The protocol determines how you deal with that. Likewise, if you find yourself with a full buffer that would be an error condition. You'd normally send some kind of NAK message to have the sender re-send the data.

I generally use a linear buffer. This is because most protocols are based, at some level, on "messages." You will receive one message, process it, ACK it, and then receive the next. Every time you process it you can just reset the buffer and overwrite what you previously received. In those cases I can't really see any benefit of using a circular buffer.

Circular buffers are most useful if you are receiving serial data quickly in an interrupt. If you just want to store the data and get out of the interrupt ASAP, a circular buffer is appropriate. Still, even many interrupt-based serial routines are better served with a linear buffer if the protocol is message-based for the same reasons described above.

Craig Steiner