While the suggested approach from PeterJ is fine, its cleaner to decouple the "data layer" logic (EEPROM access) from the CRC routine.
This CRC-32 can be universally used, its not bound to program specific behavior:
// CCITT CRC-32 (Autodin II) polynomial
uint32_t CalcCRC32(uint32_t crc, uint8_t *buffer, uint16_t length) {
while(length--) {
crc = crc ^ *buffer++;
for (uint8_t j=0; j < 8; j++) {
if (crc & 1)
crc = (crc >> 1) ^ 0xEDB88320;
else
crc = crc >> 1;
}
}
return crc;
}
Then you just feed blocks of data to the CRC function like you see fit and as required by your application.
This usage example is just written down. It uses the fictional function eeprom_read() which reads a block of data from EEPROM. We start at EEPROM address 0.
const uint8_t BLOCKLENGTH = 128;
uint32_t crc32;
uint8_t buffer[BLOCKLENGTH]; // temporary data buffer
crc32 = 0xFFFFFFFF; // initial CRC value
for (uint16_t i=0; i < NUMBEROFBLOCKS; i++) {
eeprom_read(BLOCKLENGTH * i, buffer, BLOCKLENGTH); // read block number i from EEPROM into buffer
crc32 = CalcCRC32(crc32, buffer, BLOCKLENGTH); // update CRC
}
// crc32 is your final CRC here
Note that NUMBEROFBLOCKS is just a placeholder. I hope you get the idea.
What this is telling you is that there is an infinite number of messages that will produce the same CRC, one for each possible Q(x). All you need to do is pick some particular value of Q(x) and generate the correesponding M(x).
Best Answer
The size/type of the data and the size of the CRC word really have nothing at all to do with each other. When calculating the CRC, you serialize the data (turn it into a stream of bits or bytes) anyway.
A larger CRC is better at detecting a larger class of errors, especially multibit errors. But of course, it requires more memory to store larger CRCs. Considerations like this should be driving your decision.
You also need to think about when and how the data changes, and what you need to go through in order to update the CRC when that happens. In an embedded system, you also need to think about what happens if any of the steps in the process get interrupted — for example, by an unexpected loss of power.
If you can add more details about your specific application to your question, I can write a more specific answer.