search

tpircher-zz / pycrc

Free, easy to use Cyclic Redundancy Check (CRC) calculator and source code generator
https://pycrc.org
MIT License
169 stars 36 forks source link

Is it return the wrong poly? #17

Closed wanglihe closed 7 years ago

wanglihe commented 7 years ago

When I run this: ./pycrc.py --verbose --width 10 --poly 0x633 --reflect-in False --xor-in 0 --reflect-out False --xor-out 0 --algorithm table-driven --generate c -o crc10.c it gives this: Width = 10 Poly = 0x233 ReflectIn = False XorIn = 0x000 ReflectOut = False XorOut = 0x000 Algorithm = table-driven

The poly is not the one I input, but the crc10.c is same when poly is 0x633 and 0x233, and the same in the c code。 I am not read the code deeply, but I've tried other numbers, and I find, it seems that it missed the leading "1" more than 10 bits. But I think this is a bug, the poly output should be just the one which is from input.

tpircher-zz commented 7 years ago

Hi wanglihe,

The bit 0x400 in your polynomial 0x633 is bit 11 (or bit ten, if you start counting from 0). This most significant bit is dropped in most specifications, because it is always one. pycrc always truncates the polynomial to the number of bits specified with the --width option. This is to make the algorithm as efficient as possible. Consider for example implementing a 32 bit CRC on a embedded processor. Using a 33-bit-wide polynomial would make the implementation much more inefficient and it would not make the calculated CRC value more correct.

To sum up: this is not a bug. It is the way pycrc has chosen to represent the poly, and you should get the correct CRC values for your model.

wanglihe commented 7 years ago

I mean, the poly write into c code should exactly the number from input, not the value really use. If a program read input is '0x633' and output is '0x233', how can I confirm the input is right, and how can I test?

tpircher-zz commented 7 years ago

the poly write into c code should exactly the number from input, not the value really use.

Hmm, I disagree on this. The code should write the values it is using.

how can I confirm the input is right, and how can I test?

I'm not sure what you you want to test, but if you need to verify that the polynomial in input is the same as the polynomial in output, then you could adopt the same convention pycrc does: mask off the most significant bit.

You can do that like this: MaskedPolynomial = ((1 << PolynomialWidth) - 1) & Polynomial

If you use MaskedPolynomial as the input to pycrc then the that value and the one pycrc uses should always be the same. The same applies to the XorIn and XorOut values too.

wanglihe commented 7 years ago

Ok, I get your point. We just have different opinion about how to check wrong input. In my way, I'll refuse any wrong input when it is can not process, and at least give a hit when input can be convert safely. So, a hour ago, I just can not understand why my input became a number missing a bit. And now, I know whole things, thanks for your explain. And I still suggest, leave a line about "convert 0x633 to 0x233 since width is 10 bit" when it runs in verbose mode. Accept it or not. ^_^ Thanks again.