[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect

From: Joerg Wunsch
Subject: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
Date: Tue, 11 Dec 2012 17:14:53 +0000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]