CRC Calculator

Why the same "CRC-16" gives different answers

Naming a polynomial is not enough to specify a CRC. Two implementations can both claim CRC-16 with polynomial 0x8005 and disagree on every result, because a complete definition needs six parameters. This set is known as the Rocksoft model and is what the CRC catalog uses:

• Width — the size of the register, and of the result.
• Polynomial — the divisor, written in normal form with the top bit implied.
• Init — the starting register value, commonly 0x0000 or all ones.
• Reflect input — whether each incoming byte is bit-reversed. Reflected models match hardware that shifts data out least significant bit first, which covers most serial protocols.
• Reflect output — whether the final register is bit-reversed before the last step.
• Final XOR — a value XORed into the result, usually 0x0000 or all ones.

When a datasheet gives only the polynomial and one worked example, the reliable move is to fix the polynomial and width, then try the combinations of init, reflection, and final XOR until the example reproduces. The custom mode above is built for exactly that search.

Verifying an implementation

Every model in the catalog publishes a check value: the CRC of the nine ASCII bytes 123456789. For CRC-16/MODBUS it is 0x4B37; for CRC-32 it is 0xCBF43926. Running that string through a new implementation is a single test that exercises the polynomial, the initial value, both reflections, and the final XOR at once. Every model offered here is checked against its published value.

Choosing a polynomial

For a new protocol, pick an established model rather than inventing one. Published polynomials have been analysed for Hamming distance at various message lengths, which is what determines how many bit errors are guaranteed to be detected. An arbitrary polynomial that merely looks random can have poor error detection properties at the message lengths you care about.

As a rough guide: CRC-8 suits short messages within a single device, such as sensor packets on an I²C or 1-Wire bus. CRC-16 covers the frame sizes typical of industrial serial protocols and is what Modbus, XMODEM, and USB data packets use. CRC-32 is appropriate for file-sized data and for links where undetected corruption would be expensive.

Bitwise versus table-driven

The bitwise form processes one bit at a time and needs no lookup table, which matters on parts where flash is genuinely scarce. The table-driven form precomputes 256 entries and consumes a byte per iteration, running roughly eight times faster for 256 bytes of CRC-8 table, 512 bytes for CRC-16, or 1 KB for CRC-32.

On a link running at 115200 baud or above, the table version is usually worth the flash, because CRC time on a long frame competes directly with the inter-frame timeout budget. A middle option is a nibble-wise table of 16 entries, which recovers most of the speed for a fraction of the storage.