Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What type of framing to use in serial communication

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

  • framing with SOF and escaping sequences, like in HDLC?
  • relying on using a header with length info and CRC?

It's an embedded system using DMA transfers of data from UART to memory. I think the framing method with SOF is most attractive, but maybe the other one is good enough?

Does anyone has pros and cons for these two methods?

like image 301
user2479653 Avatar asked Jun 12 '13 19:06

user2479653


People also ask

What is framing in serial communication?

In serial communications, a framing error is the result of reading a data frame -- a string of symbols which are grouped in blocks -- at the wrong starting point. The symbols are bits and the blocks are bytes, ten bits in asynchronous transmission and eight in synchronous.

What are the two methods used in serial data communication?

A serial interface where both devices may send and receive data is either full-duplex or half-duplex. Full-duplex means both devices can send and receive simultaneously. Half-duplex communication means serial devices must take turns sending and receiving.

What is framing in UART?

A UART will detect a framing error when it does not see a "stop" bit at the expected "stop" bit time. As the "start" bit is used to identify the beginning of an incoming character, its timing is a reference for the remaining bits.


1 Answers

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 your 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.

like image 67
chux - Reinstate Monica Avatar answered Jan 02 '23 20:01

chux - Reinstate Monica