What type of framing to use in serial communication

Question

In a serial communication link, what is the prefered framing/sync method?

• framing with SOF and escaping sequences, like in HDLC?
• relying on using a he

Answer 1

Following based on UART serial experience, not research.

I have found fewer communication issues when the following are included - or in other words, do both SOF/EOF and (length - maybe)/checkcode. Frame:

1. SOFrame
2. (Length maybe)
3. Data (address, to, from, type, sequence #, opcode, bytes, etc.)
4. CheckCode
5. EOFrame

Invariably, the received "fames" include:

1. good ones - no issues.
2. Corrupt due to sender not sending a complete message (it hung, powered down, or rump power-on transmission) (receiver should timeout stale incomplete messages.)
3. Corrupt due to noise or transmission interference. (byte framing errors, parity, incorrect data)
4. Corrupt due to receiver starting up in the middle of a sent message or missing a few bytes due to input buffer over-run.
5. Shared bus collisions.
6. Break - is this legit in your system?

Whatever framing you use, insure it is robust to address these messages types, promptly validate #1 and rapidly identifying 2-5 and becoming ready for the next frame.

SOF has the huge advantage of it it easy to get started again, if the receiver is lost due to a previous crap frame, etc.

Length is good, but IMHO the least useful. It can limit through-put, if the length needs to be at the beginning of a message. Some low latency operations just do not know the length before they are ready to begin transmitting.

CRC Recommend more than 2-byte. A short check-code does not improve things enough for me. I'd rather have no check code than a 1-byte one. If errors occur from time-to-time only be caught by the check-code, I want something better than a 2-byte's 99.999% of the time, I like a 4-byte's 99.99999997%

EOF so useful!

BTW: If you protocol is ASCII (instead of binary), recommend to not use cr or lf as EOFrame. Maybe only use them out-of-frame where they are not part of a message.

BTW2: If your receiver can auto-detect the baud, it saves on a lot of configuration issues.

BTW3: A sender could consider sending a "nothing" byte (before the SOF) to insure proper SOF syncing.