Comments on: Framing in serial communications

By: eliben

eliben — Fri, 25 Sep 2009 07:27:38 +0000

@matthew,
That’s a whole different level. My post refers to the data link layer, where the goal is to get a packet across. What you’re interested in is the transport layer (at least in the TCP/IP stack land). Read up on TCP – it uses a sliding window protocol to handle bad packets that drop from time to time, with minimal losses.

By: Matthew

Matthew — Thu, 24 Sep 2009 01:15:30 +0000

I understand the necessity of having the framing flags and escape characters, but I’m still unsure of how to handle bad packets on the sender’s side. Does the sender keep a quasi-infinite list of all the messages sent, deleting them as a valid reply is returned? Or does the sender poll the serial port awaiting a valid reply before it sends another message, or resends the bad message?

By: Marcelo MD

Marcelo MD — Mon, 17 Aug 2009 14:20:52 +0000

Oh, I see it now. I’ve never tought about getting the wrong size. Silly me.
Thanks a lot =)

By: eliben

eliben — Fri, 14 Aug 2009 04:58:07 +0000

@Joseph,
As you said yourself, you have a very reliable link, so most issues don’t apply. In addition, your feedback-based resync method is considerably more complex than simple byte stuffing.

@Marcelo,
header + size can work, but you must byte stuff as well. This is why: suppose your data has a header byte somewhere, by chance. This easily happens when you’re transmitting some kind of physical measurement. Now, if your size byte is corrupt just once, you may never be able to resynchronize as the “fake” header byte will be tried as the message header over and over again.

But as long as you use escaping for the header (and for the escape char), this method isn’t much different from header + footer.

By: Marcelo MD

Marcelo MD — Wed, 12 Aug 2009 19:36:32 +0000

How do you compare it with something like:
[header][size][data][crc]
Byte stuffing sounds good when you have an ‘open ended’ byte stream, or when you have enough memory to hold the entire packet before processing it in the upper layers.

I prefer little packets, but it might just be my ethernet background. Maybe I should experiment with it.

By: Joseph Lisee

Joseph Lisee — Wed, 12 Aug 2009 06:38:44 +0000

The character count method works fine if you a have relatively reliable link, checksumed packets and a defined resynchronization protocol. I have used such a system for real time robotics control for several years and I have had no issues. In the simplest terms, when the receiver detects a bad packet it returns an error code which cause the sender to send sync packets at the receiver until the receiver responds with a valid response.

Oh course the serial link in question is really done over USB through an onboard FTDI serial USB converter chip, so the chance of corrupt data is much lower then a normal analog serial comms.