Geek Answers Handbook

Should I use CRC-16 or IP checksum (RFC1071) for embedded application?

I am writing an embedded application on an ARM7 processor, and I need a certain form of checksum for the data that I send via the serial link, as well as for the data that I store in the flash. I was wondering which of the two CRCs is best suited for this purpose. The main tradeoff is code speed and reliability. Should I consider another CRC? Do you have a link to an effective implementation for ARM?

+4
source share
5 answers

RFC1071 is a simple 16-bit sum of byte pairs. Thus, it is possible that two errors can “cancel” and still give a checksum of “pass”. For instance. bit-bit flips the bit from 1 to 0. Then another bit-error 16 bits later flips the bit from 0 to 1. RFC1071 will not detect this. But the same double-bit error will be detected if checked using CRC.

A similar two-bit flip error is possible with serial transmission. (This is much more likely on a parallel cable, especially if one wire is “noisy,” but who uses the parallel these days?) It is also possible on a flash chip, especially if the PCB has a poor solder connection between the chip and the Flash chip. In general, CRC is statistically more stable in detecting errors because a single change in a bit in an input affects several bits in a CRC shift register.

In practice, the other thing that you probably want to discover is the incomplete loading of Flash, so a large piece of code is simply missing. For this, the statistically checksum is probably fine, but I always advocated for CRC in the projects I worked on. Thanks to the table-based CRC algorithm, we were able to obtain the required computation speeds.

+3
source

CRC32 is relatively cheap and quickly implemented. There was an authoritative and effective implementation as an example of PNG code on the W3C website (cost = 1 KB of RAM for a table and it can be easily created without using EEPROM resources). You can resize the table memory to calculate the time if you look there for other CRC implementations.

+3
source

Take the best checksum you can afford in a situation. Flashing may not be performed frequently, so the flash checksum may be more complicated than for serial communication.

Additional checksums that I mean:

  • CRC32
  • MD5
  • SHA1

but it depends entirely on the application that you are running, and on the harm that can be done if you do not find an error.

Take a look here for more information: http://en.wikipedia.org/wiki/List_of_checksum_algorithms

+2
source

Flash data is something you don't want to mess up with, so crc is good. The other part is a serial protocol. Given the slow serial connection speed, you should go with crc. The ARM7 chip can handle the Ethernet checksum at speeds much higher than the serial connection speed, so code speed should not be a problem, and you get a huge increase in reliability.

+2
source

For things like flash memory or (especially) OTP, it is often useful to have something like CRC that will do well with random combinations of errors and a checksum of one add-on that is long enough to not overflow. The latter will take precedence in that any combination of errors that includes only erroneously set bits or includes only erroneously cleared bits will be detected.

0
source

More articles:


All Articles