Can't validate CRC16 with FastCRC library?

Projects Programming
1

Hi! I'm using the FastCRC library from Github GitHub - FrankBoesing/FastCRC: Fast CRC library for PC and ARDUINO and it works great for generating CRC16-ccitt. But I cannot figure out how to validate a CRC if I already got a message and want to check if it was received correctly. Am I missing something here? Surely it should be possible. The code below is the example code from the author, I only cut down the irrelevant CRC's.

//FastCRC
//Validate computed CRCs
//
//(c) Frank Boesing 2014

#include <util/crc16.h>
#include <FastCRC.h>

FastCRC16 CRC16;

uint8_t buf[9] = {'1','2','3','4','5','6','7','8','9'};


void printVals(const char * name, uint32_t check, uint32_t val){
	Serial.print(name);
	if (check == val)
		Serial.print(" is ok");
	else
		Serial.print(" is NOT ok");
	Serial.println();
}

void setup() {
uint32_t crc;

  while(!Serial);
  Serial.begin(9600);

  Serial.println("CRC Validation");

  crc = CRC16.ccitt(buf, sizeof(buf));
  printVals("CCITT", 0x29b1, crc);
}


void loop() 
{
}

In this code it "works" but it seems to me in the function printVals(name, check, val) he just sends "0x29b1" because he knows it's gonna be correct for that instance. To me it would make sense that you send the actual message and the crc and then it calculates if it's ok. But this does not work.

2

You would put into that place the CRC that you extracted from the message.

3

You compare a calculated CRC against a known CRC. In communication, the known CRC is the CRC in the received message (0x29b1) and the receiver calculates the CRC over the received message (excluding the CRC in there).

I use a CRC to detect eeprom corruption. On e.g. an Uno, the CRC is calculated over the first 1020 bytes of the eeprom and compared to the known CRC stored in the last 4 bytes stored in the eeprom. The check will fail when the eeprom is 'virgin' and the code will prompt the user to enter configuration settings. After storing those settings, the CRC is again calculated over the first 1020 bytes and this calculated CRC is stored in the last 4 bytes and is now the known CRC.

4

sterretje:
You compare a calculated CRC against a known CRC. In communication, the known CRC is the CRC in the received message (0x29b1) and the receiver calculates the CRC over the received message (excluding the CRC in there).

I use a CRC to detect eeprom corruption. On e.g. an Uno, the CRC is calculated over the first 1020 bytes of the eeprom and compared to the known CRC stored in the last 4 bytes stored in the eeprom. The check will fail when the eeprom is 'virgin' and the code will prompt the user to enter configuration settings. After storing those settings, the CRC is again calculated over the first 1020 bytes and this calculated CRC is stored in the last 4 bytes and is now the known CRC.

Ok I see. So I actually thought a little about this after asking. I guess my follow up question is: Is there a difference between calculating a CRC from the message and comparing that CRC to the CRC bytes I received and the "usual way" of dividing the message and CRC bytes with the generator polynom to obtain "0" if the message is ok?

5

Some types of checksum will end up at zero if you calculate the checksum over the entire message including the checksum.

In the general case, this is not true. But it is no trouble for an Arduino to check if(A==B)