> The "Bible" has been:
> http://www.joegeluso.com/software/articles/ccitt.htm
This fellow is just plain Confused.
First of all, The Standard Way to do it is to preset to -1 *and* to
invert the result. Any combination is certainly valid, but if you don't
invert the CRC before appending it,
>> CRC-CCITT = X^16 + X^12 + X^5 + X^0 = 0x8408, and NOT 0x1021
>> CRC-16 = X^16 + X^15 + X^2 + X^0 = 0xa001, and NOT 0x8005
>>
>
> Thank you very much for your time, but what you say is completely
> different than anything else I have found on the net.
>
> Do the math:
>
> 2^ 16 = 65536
On Aug 11, 2005, at 13:08:56, linux-os (Dick Johnson) wrote:
Okay. Thanks. This means that hardware somehow swapped bits
before doing a CRC. I wasn't aware that this was even possible
as it would require additional storage, well I guess anything
is now possible in a FPGA.
The "Bible" has been:
On Thu, 11 Aug 2005, Kyle Moffett wrote:
> On Aug 11, 2005, at 11:19:59, linux-os (Dick Johnson) wrote:
>> On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
>>> You're wrong in two ways:
>>> 1) You've got CRC-16 and CRC-CCITT mixed up, and
>>> 2) You've got the bit ordering backwards. Remember, I sai
On Aug 11, 2005, at 11:19:59, linux-os (Dick Johnson) wrote:
On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
You're wrong in two ways:
1) You've got CRC-16 and CRC-CCITT mixed up, and
2) You've got the bit ordering backwards. Remember, I said very
clearly,
the lsbit is the first bit, and the
On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
>>> Using this bit-ordering, and omitting the x^16 term as is
>>> conventional (it's implicit in the implementation), the polynomials
>>> come out as:
>>> CRC-16: 0xa001
>>> CRC-CCITT: 0x8408
>>
>> Huh? That's the problem.
>>
>> X^16 + X^12 + X^5 + X^0
>> Using this bit-ordering, and omitting the x^16 term as is
>> conventional (it's implicit in the implementation), the polynomials
>> come out as:
>> CRC-16: 0xa001
>> CRC-CCITT: 0x8408
>
> Huh? That's the problem.
>
> X^16 + X^12 + X^5 + X^0 = 0x1021, not 0xa001
>
> Also,
>
> X^16 + X^15 + X^
On Wed, 10 Aug 2005 [EMAIL PROTECTED] wrote:
>> Does anybody know what the CRC of a known string is supposed
>> to be? I have documentation that states that the CCITT CRC-16
>> of "123456789" is supposed to be 0xe5cc and "A" is supposed
>> to be 0x9479. The kernel one doesn't do this. In fact, I
linux-os (Dick Johnson) wrote:
the CCIT-16 CRC. I note that drivers that use it expect it
to return 0xf0b8 if it performs the CRC of something that
has the CRC appended (weird).
That is the remainder you get when checking
a received CRC for correctness. If the value
is not 0xf0b8, there is an
> Does anybody know what the CRC of a known string is supposed
> to be? I have documentation that states that the CCITT CRC-16
> of "123456789" is supposed to be 0xe5cc and "A" is supposed
> to be 0x9479. The kernel one doesn't do this. In fact, I
> haven't found anything on the net that returns th
Hello CRC Wizards,
I am trying to use ../linux-2.6.12/lib/crc_citt in a driver.
Basically, it doesn't return anything that closely resembles
the CCIT-16 CRC. I note that drivers that use it expect it
to return 0xf0b8 if it performs the CRC of something that
has the CRC appended (weird).
Does any
11 matches
Mail list logo
