Fletcher's Checksum in LabVIEW

[MichaelAivaliotis]

Does anyone have LabVIEW code to do this?

http://en.wikipedia.org/wiki/Fletcher's_checksum

http://www.drdobbs.com/184408761 

[Drewski]

Try this, it takes a string, but could be converted to take an unsigned 8 bit int array very simply.

[glstill]

I ran the example with a byte array input using the values 0x01 and 0x02 as byte 0 and 1.  The function returned check1 = 0xF8 and check2 =  0x04.  The wikipedia example used 0x01 and 0x02 as inputs and got 0XF9 and 0x04.  Is there possibly a mistake with the example?

I was trying to find an example because the wikipedia description of the algorithm was not very clear to me.

Thanks,

Gary

[Drewski]

http://www.drdobbs.com/database/184408761

I used the algorithm from the Dr. Dobb's article.  I don't see the full algorithm in the Wikipedia article. In the talk page of the wikipedia article, other people also had differing results.  And one person discussed how they had to go to the IEEE source to get the algorithm.

It is odd to me that the second part of the checksum would match and the first part wouldn't, as the second part depends on the first part??

Good Luck!

[glstill]

Thanks for replying and for the link to that website.  I believe your implementation is likely correct based on what I read at the DrDobbs site.

I will make another post to this thread if I find out that your example is not correct.  

Thanks,

Gary Still

[MrJackHamilton]

The Fletcher Checksum was conceived about the time of the Apollo program. What is important to keep in mind, that true 8-bit microprocessors, can't perform the SUM operation on all the message bytes - because they will likely over-range the 8-bit value.

So the Fletcher algrithim sum's each byte to the previous byte sum in sequence (FOR Loop replaces SUM Byte array)  - and replaces the value with a 1 IF the value exceeds 255...A work-around to stay below the 8-bit ceiling.

It's very tricky to implement, rarely run into anymore - except in tiny microprocessors or FPGA's. It's devious to implement and test. I recall on a project our inital routine worked for values like "40", "45" and "50" but was wrong when the value was "43".

Regards

Jack Hamilton

[JÞB]

---

@MrJackHamilton wrote:

The Fletcher Checksum was conceived about the time of the Apollo program. What is important to keep in mind, that true 8-bit microprocessors, can't perform the SUM operation on all the message bytes - because they will likely over-range the 8-bit value.

So the Fletcher algrithim sum's each byte to the previous byte sum in sequence (FOR Loop replaces SUM Byte array)  - and replaces the value with a 1 IF the value exceeds 255...A work-around to stay below the 8-bit ceiling.

It's very tricky to implement, rarely run into anymore - except in tiny microprocessors or FPGA's. It's devious to implement and test. I recall on a project our inital routine worked for values like "40", "45" and "50" but was wrong when the value was "43".

Regards

Jack Hamilton

---

<Story Time> RE: About obsolete methods:

A while back-- in this decade! I ran across a "Serial Device" that required the the "Data Package" (really a command) needed to be sent with the "Data" inverted and CSUMed

e.g. "SOH DATA(as U16) !DATA(as U16) CSUM" where Checksum was computed on the Data and !Data fields!  (Can you guess?)

Spoiler

The check sum was always 0xFFFF! since..Well some SW engineer said the protocol was flawless....Do the math yourself;)

So, the guy sending the packet just "pencil-whipped" the CSUM to 0xFFFF and sent it anyway.  The CSum was read by the client and... Yup, its a good data packet! because the CSUM "Must be 0xFFFF"  The random crashes of the target that got bad commands without knowing it were a source of much frustration to the field engineers

<End Story>

Moral of the story: "Even communication protocols become obsolete and modern developers may fail to implement them well."

<Another Story>

@WhEN my son was @9yrs old he wanted to call a friend from my parent's basement... He learned why its called "Dialing a number" from that rotary phone

<End Second Story>

Did I make my point?... upgrade the tech! but don't lose the tech's foundational objectives---- it can cause much pain!

[MrJackHamilton]

I would also like to throw in a caution that even in 'modern' LabVIEW and other programming languages there is trouble lurking on the 'Sum Array' function. I feel NI should put an error cluster on this function.

It's quite possible for the sum to overrun the datatype, meaning summing 900 I16 values, will very likely result in a value that is greater than 32,768.

Now you'll get a number returned from this function, but if it overranges, you'd not know. Following standard overrange handling, it will not return "32768" but roll over, giving you some number that 'looks' reasonable.

Thus, the solution is to cast the array up to a larger datatype and sum that.

Remember:

"The code does what you program it to do...not what you want it to do" - Jack Hamilton