8-bit fletcher checksum of 16 byte data - c

Question

I'm trying to implement a 8-bit fletcher checksum function.
My data will always be 17 byte long.
I started with code from Remake of Fletcher checksum from 32bit to 8
Here is what I ended up having :
// 8-bit Fletcher checksum
// data is always 17 byte long
uint8_t fletcher(uint8_t *data) {
uint8_t sum1 = 0x0f, sum2 = 0x0f, len = 17;
while(len) {
sum1 += *data++;
sum2 += sum1;
sum1 = (sum1 & 0x0f) + (sum1 >> 4);
sum2 = (sum2 & 0x0f) + (sum2 >> 4);
len--;
}
sum1 = (sum1 & 0x0f) + (sum1 >> 4);
sum2 = (sum2 & 0x0f) + (sum2 >> 4);
return sum2<<4 | sum1;
}
I'm wondering if it is good and I have the impression that I could simplify further but I can't find where (maybe it just can't be simplified further after all ...).
My main question is whether this code looks it will work okay. I am using it at both sides of a wireless based data link it will "work" (return the same checksum from the same data) but may be wrong in the fletcher way and not provide the expected error detection ...
Hope I'm clear enough ...
Thanks in advance !

Answer 1

First off, any variant of Fletcher is not a CRC. It's a checksum.
Second, there is nothing special about the number of bytes you process as long as the algorithm is correct.
Third, you do not need to and should not be doing the modulo 15 at every step. For speed (which is the whole point of a Fletcher sum as compared to a CRC), there should be an inner loop that only consists of sum2 += sum1 += *data++;. Depending on the size of the sum1 and sum2 data types, you can calculate how many iterations you can do before overflowing sum2 assuming that all input bytes are 0xff. Then an outer loop runs that inner loop that many times followed by the two modulo 15's. The outer loops runs through all of the input data.
Fourth, the (x >> 4) + (x & 0xf) operations do not complete the intended x % 15 when x ends up as 15. There would need to be a final if (x == 15) x = 0;.
Update:
Ok, so here's the code:
#include <stdio.h>
#define MAXPART 5803 /* for 32-bit unsigned sum1, sum2 */
/* #define MAXPART 22 for 16-bit unsigned sum1, sum2 */
unsigned fletcher8(unsigned f8, unsigned char *data, size_t len)
{
unsigned long sum1, sum2;
size_t part;
sum1 = f8 & 0xf;
sum2 = (f8 >> 4) & 0xf;
while (len) {
part = len > MAXPART ? MAXPART : len;
len -= part;
do {
sum2 += sum1 += *data++;
} while (--part);
sum1 %= 15;
sum2 %= 15;
}
return (sum2 << 4) + sum1;
}
#define SIZE 131072
int main(void)
{
unsigned f8 = 1;
unsigned char buf[SIZE];
size_t got;
while ((got = fread(buf, 1, SIZE, stdin)) > 0)
f8 = fletcher8(f8, buf, got);
printf("0x%02x\n", f8);
return 0;
}
Note that I started the Fletcher8 value at 1 instead of 0xff. That is sufficient to assure that a string of any length of zeros will produce the same zero result. You can set the initial value to whatever you like, so long as it's not zero.
If the modulo (%) operation on the machine is very slow, then it may be faster to do the % 15 operations with a set of shifts and adds. Here is an example for a 32-bit type:
k = (k >> 16) + (k & 0xffff);
k = (k >> 8) + (k & 0xff);
k = (k >> 4) + (k & 0xf);
k = (k >> 4) + (k & 0xf);
if (k > 14)
k -= 15;
For the stated case where len == 17, the code can be simplified to use unsigned instead of unsigned long for sum1 and sum2, and to skip the outer loop since len <= 22. The non-% modulo operations can be shortened as well. Here's that, where I also eliminated an unnecessary decrement operation in the loop:
unsigned fletch8_17(unsigned char *data)
{
unsigned sum1 = 1;
unsigned sum2 = 0;
unsigned char *end = data + 17;
do {
sum2 += sum1 += *data++;
} while (data < end);
sum1 = (sum1 >> 8) + (sum1 & 0xff);
sum1 = (sum1 >> 4) + (sum1 & 0xf);
if (sum1 > 14) {
sum1 -= 15;
if (sum1 > 14)
sum1 -= 15;
}
sum2 = (sum2 >> 8) + (sum2 & 0xff);
sum2 = (sum2 >> 4) + (sum2 & 0xf);
if (sum2 > 14) {
sum2 -= 15;
if (sum2 > 14)
sum2 -= 15;
}
return (sum2 << 4) + sum1;
}
For comparison, you can try this 8-bit CRC and see how it compares for speed (crc should be initialized to zero):
#include <stddef.h>
/* 8-bit CRC with polynomial x^8+x^6+x^3+x^2+1, 0x14D.
Chosen based on Koopman, et al. (0xA6 in his notation = 0x14D >> 1):
http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
*/
static unsigned char crc8_table[] = {
0x00, 0x3e, 0x7c, 0x42, 0xf8, 0xc6, 0x84, 0xba, 0x95, 0xab, 0xe9, 0xd7,
0x6d, 0x53, 0x11, 0x2f, 0x4f, 0x71, 0x33, 0x0d, 0xb7, 0x89, 0xcb, 0xf5,
0xda, 0xe4, 0xa6, 0x98, 0x22, 0x1c, 0x5e, 0x60, 0x9e, 0xa0, 0xe2, 0xdc,
0x66, 0x58, 0x1a, 0x24, 0x0b, 0x35, 0x77, 0x49, 0xf3, 0xcd, 0x8f, 0xb1,
0xd1, 0xef, 0xad, 0x93, 0x29, 0x17, 0x55, 0x6b, 0x44, 0x7a, 0x38, 0x06,
0xbc, 0x82, 0xc0, 0xfe, 0x59, 0x67, 0x25, 0x1b, 0xa1, 0x9f, 0xdd, 0xe3,
0xcc, 0xf2, 0xb0, 0x8e, 0x34, 0x0a, 0x48, 0x76, 0x16, 0x28, 0x6a, 0x54,
0xee, 0xd0, 0x92, 0xac, 0x83, 0xbd, 0xff, 0xc1, 0x7b, 0x45, 0x07, 0x39,
0xc7, 0xf9, 0xbb, 0x85, 0x3f, 0x01, 0x43, 0x7d, 0x52, 0x6c, 0x2e, 0x10,
0xaa, 0x94, 0xd6, 0xe8, 0x88, 0xb6, 0xf4, 0xca, 0x70, 0x4e, 0x0c, 0x32,
0x1d, 0x23, 0x61, 0x5f, 0xe5, 0xdb, 0x99, 0xa7, 0xb2, 0x8c, 0xce, 0xf0,
0x4a, 0x74, 0x36, 0x08, 0x27, 0x19, 0x5b, 0x65, 0xdf, 0xe1, 0xa3, 0x9d,
0xfd, 0xc3, 0x81, 0xbf, 0x05, 0x3b, 0x79, 0x47, 0x68, 0x56, 0x14, 0x2a,
0x90, 0xae, 0xec, 0xd2, 0x2c, 0x12, 0x50, 0x6e, 0xd4, 0xea, 0xa8, 0x96,
0xb9, 0x87, 0xc5, 0xfb, 0x41, 0x7f, 0x3d, 0x03, 0x63, 0x5d, 0x1f, 0x21,
0x9b, 0xa5, 0xe7, 0xd9, 0xf6, 0xc8, 0x8a, 0xb4, 0x0e, 0x30, 0x72, 0x4c,
0xeb, 0xd5, 0x97, 0xa9, 0x13, 0x2d, 0x6f, 0x51, 0x7e, 0x40, 0x02, 0x3c,
0x86, 0xb8, 0xfa, 0xc4, 0xa4, 0x9a, 0xd8, 0xe6, 0x5c, 0x62, 0x20, 0x1e,
0x31, 0x0f, 0x4d, 0x73, 0xc9, 0xf7, 0xb5, 0x8b, 0x75, 0x4b, 0x09, 0x37,
0x8d, 0xb3, 0xf1, 0xcf, 0xe0, 0xde, 0x9c, 0xa2, 0x18, 0x26, 0x64, 0x5a,
0x3a, 0x04, 0x46, 0x78, 0xc2, 0xfc, 0xbe, 0x80, 0xaf, 0x91, 0xd3, 0xed,
0x57, 0x69, 0x2b, 0x15};
unsigned crc8(unsigned crc, unsigned char *data, size_t len)
{
unsigned char *end;
if (len == 0)
return crc;
crc ^= 0xff;
end = data + len;
do {
crc = crc8_table[crc ^ *data++];
} while (data < end);
return crc ^ 0xff;
}
An 8-bit CRC will definitely give better error-detection performance than the 8-bit Fletcher checksum. It may even be faster in this case!

Answer 2

Your code looks a lot like the one given in the Optimizations section of the Wikipedia article on the Fletcher checksum. I guess your source took it from there without proper attribution.
Deferred reduction
Your code looks mostly right. However, you sum too much. If your input is only 17 bytes of data, then your maximal value of sum2 will be 17*(17+1)/2*0xf + 0xf = 0x906, which fits into an uint16_t. To reduce that to a single nibble, two reduction steps are sufficient. For sum1, the maximum will be 17*0xf + 0xf = 0x10e which requires two reductions as well. So you could write
uint8_t fletcher(uint8_t *data) {
uint16_t sum1 = 0xf, sum2 = 0xf, len = 17;
while(len) {
sum1 += *data++;
sum2 += sum1;
len--;
};
sum1 = (sum1 & 0x0f) + (sum1 >> 4);
sum1 = (sum1 & 0x0f) + (sum1 >> 4);
sum2 = (sum2 & 0x0f) + (sum2 >> 4);
sum2 = (sum2 & 0x0f) + (sum2 >> 4);
return sum2<<4 | sum1;
}
You could do further “optimizations” on the code, like
do { sum2 += ( sum1 += *data++ ); } while (--len);
or even manually unrolling that loop, but a good optimizing compiler should take care of this for you.
You can adapt the above considerations to other input lengths.
Whole bytes as nibble stream
The above answer assumes that your data only contains unpacked nibbles, i.e. at most the least significant half of each byte is used. I might be wrong here, but I guess that if you were dealing with whole bytes, the solution most in the spirit of Fletcher's checksum would be to treat them as a sequence of twice as many nibbles, e.g.
sum1 += *data & 0xf;
sum2 += sum1;
sum1 += *data >> 4;
sum2 += sum1;
++data;
--len;
There might be more efficient ways to write this as fewer optimizations. Your compiler may or may not be able to find one of them.
Quality of the checksum
but may be wrong in the fletcher way and not provide the expected error detection ...
I'm not sure how useful a fletcher checksum here really is. Perhaps some real CRC with 8 bit output would better suite your needs in terms of error checking.