hello,
I have implemented a 32bit crc generation algorithm. Now at the receiver side i need to check the crc for that....i need to add the message in the packet and the crc and divide it with the key common at both side and the remainder should be zero.
now how to add crc which is hexadecimal with the string.
thanks
What format is the data in? What protocol do you use to exchange the data? You need to be much more specific.
So far all I can say from what you say is
memcpy(p+1+strlen(p),crc,sizeof(crc));
which I am sure is not what you are intending....
hello,
i only need to verify the data after i received it
the packet is of size 144 byte : message 140 byte +crc 4 byte
the messege received is a simple string and the crc send is a hexadecimal and received the same.
now i need to add the string and hexdecimal (so need to convert them both to same format)lets say convert the string to decimal (ascii value ) and hexdecimal to decimal.
and add the both......
then divide it by key .......i get the remainder zero if the message is not corrupted.
should this be the way to check the the packet validation of the data with the crc at the receiver end.
assume that i have received the data in the afore said format
thanking you
Traditionally CRC's are transmitted along with the data in binary. Look, for instance, at ethernet packets.
eg...
[ data ] [ crc ]
This will not work, a 32 bit CRC will not fit in "4 bytes of hex". While 32 bits is indeed 4 bytes, a byte has 2^8 (256) possible values; base 256 (haha).
You are implying that the spec is transfering a 32 bit CRC value using "hexidecimal". This effectively reduces the resolution for each byte to 16 values. In doing so, to represent the entire range of 32 bit CRC values it will need 8 hexidecimal "bytes".
More simply stated, the biggest value for a 32 bit CRC is 2^32-1 (hex "FFFFFFFF"). This sequence of hexidecimal characters will occupy 8 bytes if translated verbatim.
Given this, I think you are very confused by something.... I am just not sure what. All the "convert the string and CRC to decimal" [sic] talk makes no sense to me. You have an algorithm that generates a CRC from a piece of data. The receiver should use the same alogoirthm, generate a CRC, and compare against the CRC sent with the data.
If the protocol does something more complicated then you need to understand what that is. For example, you mention a "common key" which I presume is the CRC, but I have no idea.