Because I couldn't find any program which met my needs. I wanted an Open Source tool with the following features:
Over the years zillions of different CRC code snippets have accumulated in the Web, many of them are not compatible one with another, even if they are called the same (let's say CRC 16). pycrc tries to bring some clarity into this mess, by religiosly using the Rocksoft Model, described by Ross Williams in Painless Guide to CRC Error Detection Algorithms.
It happens often that one has a few bytes of sample data and the CRC but a few parameters are not given. How can the missing CRC parameters be found?
Gregory Ewing wrote up an article on his experience of Reverse-Engineering a CRC Algorithm. It outlines an algorithm how to get the CRC parameters from raw data. Greg Cook's Perl script crcbfs.pl does a good job in finding the parameters when a few data points are given.
It is very straightforward to use the CRC implementation in python.
from crc_algorithms import Crc
crc = Crc(width = 16, poly = 0x8005,
reflect_in = True, xor_in = 0xffff,
reflect_out = True, xor_out = 0x0000)
data = "01020304A12B".decode("hex") # your data is probably already in binary form, so you won't have to convert it again.
my_crc = crc.bit_by_bit_fast(data) # calculate the CRC, using the bit-by-bit-fast algorithm.
print("0x%04x" % my_crc)
This is correct. And I'm not going to change this. The Python implementation is thought to provide a correct, stable and easy to read code bases for further experiments. The right place to do performance tuning is the generated C code. I'm happy to consider every suggestion to improve the generated code.
This depends. For occasional computations on small amounts of data the optimized bit-by-bit implementation might be a feasable solution and might also have a speed which is comparable to other models. On desktop computers, with larger amounts of data, the table driven model is a good choice, but on embedded platforms, where code space is a major concern, an optimized bit-by-bit implementation might be the better choice.
| Parameters | Width | Platform | Data quantity | Possible algorithms |
|---|---|---|---|---|
| Variable, Fixed | 1-16 bits | Embedded, Desktop | Low | bit-by-bit, bit-by-bit-fast |
| Fixed | 8, 16 bits | Embedded, Desktop | Medium, Low | bit-by-bit-fast, table-driven (table index width: 4) |
| Fixed | 8 or more bits | Desktop | Medium, High | table-driven |
The following numbers are gathered from a unspecified computer using an unspecified compiler (at maximum optimisation level). The numbers (in an unspecified time unit) are meaningful to compare the performance of the algorithms on this particular setup.
| Algorithm | Looping over | User time |
|---|---|---|
| bit-by-bit | 65536 blocks of 1024 bytes each | 7.590 |
| bit-by-bit | 65536 * 1024 bytes | 8.260 |
| bit-by-bit-fast | 65536 blocks of 1024 bytes each | 6.450 |
| bit-by-bit-fast | 65536 * 1024 bytes | 7.280 |
| table-driven | 65536 blocks of 1024 bytes each | 0.320 |
| table-driven | 65536 * 1024 bytes | 0.760 |
| table-driven (table index width: 4) | 65536 blocks of 1024 bytes each | 0.720 |
| table-driven (table index width: 4) | 65536 * 1024 bytes | 1.190 |
This question has become almost irrelevant with the MIT licence introduced in version 0.6. The sloppy answer is: you are free to do whatever you like with the generated code, as long as you don't cite the author to court and don't alter the copyright statement.