bugAVR C Runtime Library - Bugs: bug #45067, inconsistency & errors in...


bug #45067: inconsistency & errors in crc.h documentation

Submitted by:  None
Submitted on:  Sun 10 May 2015 05:59:16 PM UTC  
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  None Percent Complete:  0%
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  1.8.0
Fixed Release:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Mon 25 May 2015 07:48:56 PM UTC, comment #2:

"Unfortunately, the bit order of the CRC polynomial appears to
be one of the things where there is never consensus about. :( "
I agree, so just pick one and be consistent about it. My point is that crc.h mixes both bit orders without even a comment explaining it.

And if you're going to pick one, I think the way pycrc does it is best because it is explicit as to when the polynomial division is bit-reversed. In cases where a CRC shows a polynomial in bit-reversed order, that's an implicit indication that it operates on the bits in reverse order (shift right instead of shift left).

Sun 10 May 2015 06:22:54 PM UTC, comment #1:

Unfortunately, the bit order of the CRC polynomial appears to
be one of the things where there is never consensus about. :(
Just because you cite pycrc as one source, you'll as well be
able to find numerous other sources quoting the opposite.

In your case of the Xmodem CRC, the official protocol
documentation[1] declares the polynomial the same way our
documentation does:


In essence, the difference between Xmodem and CCITT is only
the bit order of the polynomial, since in both cases, the
official doucumentation declares the polynomial being
x^16 + x^12 + x^5 + 1, but in Xmodem, that translates into
a hex value of 0x1021, while in CCITT, it translates into

Yes, I wish all these people would have agreed to a common
definition. :) The only useful option I see is that we
could explain these ambiguities in deeper detail in the
introduction to make people aware of it.


Joerg Wunsch <joerg_wunsch>
Project Administrator
Sun 10 May 2015 05:59:16 PM UTC, original submission:

From http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html:

"Optimized CRC-XMODEM calculation.
x^16 + x^12 + x^5 + 1 (0x1021)"

The hex representation of the poly is correct, but doesn't match the long form, which should be:
x^16 + x^15 + x^5 + 1

Other parts of the docs give the reversed poly in hex instead of the actual poly:
"Optimized Dallas (now Maxim) iButton 8-bit CRC calculation.
Polynomial: x^8 + x^5 + x^4 + 1 (0x8C)"

It would be better to describe them the way pycrc does, with the actual poly used and whether or not the crc reflects (reverses) the bits.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)



    No changes have been made to this item

    Back to the top

    Powered by Savane 3.3