Follow-up Comment #6, bug #37901 (project avr-libc):
Well, we cannot impose a 1 KiB lookup table on everyone using this
header file. Also, a usable patch needs documentation. No problem
if you don't have the time to do it right now.
Regarding the reference to CCITT, there's a simple proof: the X.25
document (which all this eventually refers to) is publically
available, and it contains examples for their CRC calculation in
appendix I. One of them is:
10000000 11001110 11000001 11101010
Address = B UA(F = 1) Frame check sequence
Remember that this is a communications standard, so the first bit
transferred is the low-order one. Consequently, the message contains
two octets, 0x01, followed by 0x73. If you pass this through
avr-libc's _crc_ccitt_update() function (with an initial CRC value of
0xffff), you get a CRC of 0xa87c, or 0x7c 0xa8 in octet-order. If you
turn this into the X.25 bit-order, it's 00111110 00010101. For odd
reasons, X.25 states they transfer their FCS in a negated way, which
yields the 11000001 11101010 you see in their example.
Another example:
11000000 11111100 11011010 00110111
Address = A SABM(P = 1) Frame check sequence
0x03 0x3F
=> CRC 0x13a4 = 00100101 11001000, inverted 11011010 00110111
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?37901>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
