• C

32-bit CRC calculation

Write c code to calculate CRC using polynomial: x^32+x^30+x^28+x^23+x^18+x^17+x^16+x^15+x^8+x^7+x^6+x^3+x^2+1 for the message in which each character has been stored in an array of (unsigned char) messageBuffer[MESSAGE_LENGTH].  After calculate the CRC, store back the message with CRC appended to it into (unsigned char) messagewithcrcBuffer[MESSAGE_LENGTH+4].

I know how CRC works but I am unsure how I can get each character from the array and convert to number then concanate all the numbers(for complete message) to be moded by the polynomial to get crc.  Can someone help me, please?
Who is Participating?

Software ArchitectCommented:
you have to reserve a proper buffer size, with enough space to store any message.

This is an example
#define MAX_ESTIMATED_LENGTH   300

Declare proper variables
char buffer[MAX_ESTIMATED_LENTGHT];
int len, i;
unsigned long int crc;

Now you have to copy the message from somewhere to the buffer:
strcpy (buffer, somemessage);
len = strlen(buffer);

Now calculate the CRC (I assume you have your calculation function ready) using a for loop:
crc = 0;
for (i=0; i<len; i++) {
crc = CalcCRC32(buffer[i], crc);   /* use previous crc in your calculus */
}

0

Groupware ConsultantCommented:
Homework?? There are LOTS of examples on the internet, see also CRC16.

In C, a character IS a number, the character a has the value 97. If declared as

char c= 'a';

then

printf("%d\n", (int)c)

will yield 97.
0

Commented:
To concatenate the numbers as a number,you can use:

unsigned long var3;
unsigned int var1=97, var2=98;
int shift=sizeof(int)*8;
var3= ((unsigned long)var1<<shift) | var2;

var3 would contain 9798.

from:
http://www.experts-exchange.com/Programming/Programming_Languages/C/Q_21108427.html#11904200

Using this approach,you'd be limiting your input string to the range of a long.
0

Software ArchitectCommented:
Forgot to append the crc to your buffer. Some casting tricks:

*((unsigned long int *)(buffer+len)) = crc;
len += 4;

Now your buffer has the crc appended and the 'len' variable reflects total lenght including crc.

0

Author Commented:
Ok, thanks jaime i have done the crc calculation and put it together with message and sent them.  Now, at the receiving end, how do i check for crc error.  Write now what i'm doing is get each character by character and concatenate them into big numbers and mod it with the crc which I get after all the characters from message come out.  I think it's kinda wrong.....but I'm not sure.  Anyone know?
0

Software ArchitectCommented:
At the receiving end, you have to extract the crc from the buffer first. You have to know the lenght of the message to know where the CRC is located:

int len;
unsigned long int crc, crc1;

len =  ....   <-- some method to obtain the lenght

Another casting trick:

crc1 = *((unsigned long int *)(buffer+len));

Now do crc calculation using the for loop and store it into 'crc', exactly as done during transmision.
Finally compare 'crc' with 'crc1'.
0

Groupware ConsultantCommented:
Now the fun of CRC-16, and I assume it's the same for CRC-32: just process every byte of the array, including the crc-bytes. The resulting crc-value should be ...... zero! No casting required, but the bytes will have to be put into the string in the right sequence.
0

Software ArchitectCommented:
That's an interesting method, not tried. Since crc is exactly at the end of the string could work, I guess. Maybe you can tell us if Little Endian or Big Endian is required.
0

Groupware ConsultantCommented:
I knew it, the question was too obvious. Eh, I don't know, but I can try... I did, eh, doesn't work. But I'm very sure it worked! I'll be back... :(

0

Groupware ConsultantCommented:
Aaaaaahhhhhh! Gotcha! These little grey cells still work :)

The CRC-32 algorithm I've got produces
378420CF
for the string
The quick red fox jumped over the lazy brown dog.

This result is the inverted value of the actual CRC. Why? Beats me. Anyway, if you add the inverted values of the bytes produces to the CRC-algorithm, so ~CF, ~20, ~84, ~37, you get ~0, i.e. 0xFFFFFFFF. If they would have left the inversion out, everything would have worked as it used to do (in the old days, as granpoh says).

0

Software ArchitectCommented:
So the solution will work with Intel platforms, casting trick needed at transmition, not needed at reception.

About the result of 0xFFFFFFFF. I think it is related with the last XOR needed at crc calculation:
In pseudo code:

crc = 0xFFFFFFFF
while (nextByte in buffer)
crc = (crc>>8)   XOR   crc_table[ (crc  XOR  nextByte)   AND   0xFF]
crc = crc XOR 0xFFFFFFFF
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.