Hi Pang,

I've not looked at these notes, but I can help with the C..

I'm assuming that "p" is pointing to the message being CRCed..

> r = 0;
> while ( len-- )
> {
>     byte t = ( r >> 24 ) & 0xFF;

>     r = ( r << 8 )  | *p++;             // why OR with the
> contents of the
> address pointer?

This is rotating the CRC value currently stored in "r" by 8 bits and then it
assigns the current message byte into the lower 8 bits of "r" and then moves
the pointer to point to the next element in the message.

This is just a shorthand way of writing:

        r = r << 8;             // rotate the CRC one byte left
        r = r | (*p);   // set the lower byte to the current message value
                                // without changing the upper bytes of "r"
        p++;                    // increment the pointer to the next byte in the message

>
>     r^ =table[t];
>

This is XORing the value in "r" with the result of the table lookup.

In "c", you can use the shorthand of X [operator]= value; to mean X = X
[operator] value;

The "^" means XOR in C.

Does that help? Can you see now where "r" is being updated?

If your going to port this to a PIC, remember - you will have different size
integers on the PIC. This looks like it is working with 32 bit ints.

I've implemented a CRC16 in a PIC with table lookups before. You need two
tables because it can't implement a table with a 16 bit value, so you need a
table for the "high" and "low" bytes.

Cheers,
Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
www.digitalnemesis.com
Mobile: +61 (0)417 705 718

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu