Efficient handling of fast, real-time hex data
alister
alister.ware at ntlworld.com
Thu Jun 2 08:30:40 EDT 2016
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...
More information about the Python-list
mailing list