Efficient handling of fast, real-time hex data

[alister]

On Thu, 02 Jun 2016 05:41:40 -0400, Gene Heskett wrote:

> On Thursday 02 June 2016 04:13:51 alister wrote:
> 
>> On Thu, 02 Jun 2016 18:50:34 +1200, Gregory Ewing wrote:
>> > jladasky at itu.edu wrote:
>> >> One common data transmission error I've seen in other systems is
>> >> added/dropped bytes. I may add a CRC-8 error-checking byte in place
>> >> of the newline.
>> >
>> > Also maybe add a start byte with a known value at the beginning of
>> > each packet to help resynchronise if you get out of step.
>>
>> No maybe about it if you are sending a binary stream you need to be
>> able to reliably signal the start AND finish of the data stream (either
>> send the length in the message start or have a fixed msg. length)
>>
>> after a lot of experimenting to ensure reliability you will probably
>> have reinvented something like intelhex or x-modem
>>
> Neither of which can handle that last packet well unless the last packet
> is padded out to be a fill packet and the filler bytes thrown away in
> the receiver.

The examples quoted were for examples of binary transfer protocols & not 
intended to be an exhaustive list.

> 
>> The work [of software development] is becoming far easier (i.e. the
>> tools we're using work at a higher level, more removed from machine,
>> peripheral and operating system imperatives) than it was twenty years
>> ago, and because of this, knowledge of the internals of a system may
>> become less accessible.
>> We may be able to dig deeper holes, but unless we know how to build
>> taller ladders, we had best hope that it does not rain much.
>> 		-- Paul Licker
> 
> Paul is absolutely correct.
> 
> Cheers, Gene Heskett
^^^^ like that quote




-- 
Under deadline pressure for the next week.  If you want something, it can 
wait.
Unless it's blind screaming paroxysmally hedonistic...