Crc-ccitt 16-bit Python Manual Calculation

Problem I am writing code for an embedded device. A lot of solutions out there for CRC-CCITT 16-bit calculations require libraries. Given that using libraries is almost impossible

Solution 1:

Here is a python port of the C library from http://www.lammertbies.nl/comm/info/crc-calculation.html for CRC-CCITT XMODEM

This library is interesting for real use cases because it pre-computes a table of crc for enhanced speed.

Usage (with a string or a list of bytes) :

crc('123456789')
crcb(0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39)

The test gives : '0x31c3'

POLYNOMIAL = 0x1021
PRESET = 0def_initial(c):
    crc = 0
    c = c << 8for j inrange(8):
        if (crc ^ c) & 0x8000:
            crc = (crc << 1) ^ POLYNOMIAL
        else:
            crc = crc << 1
        c = c << 1return crc

_tab = [ _initial(i) for i inrange(256) ]

def_update_crc(crc, c):
    cc = 0xff & c

    tmp = (crc >> 8) ^ cc
    crc = (crc << 8) ^ _tab[tmp & 0xff]
    crc = crc & 0xffffprint (crc)

    return crc

defcrc(str):
    crc = PRESET
    for c instr:
        crc = _update_crc(crc, ord(c))
    return crc

defcrcb(*i):
    crc = PRESET
    for c in i:
        crc = _update_crc(crc, c)
    return crc

Your proposed checkCRC routine is CRC-CCITT variant '1D0F' if you replace poly = 0x11021 with poly = 0x1021 at the beginning.

Solution 2:

Here's a function that I use:

def crc16_ccitt(crc, data):
    msb = crc >> 8
    lsb = crc & 255for c indata:
        x = ord(c) ^ msb
        x ^= (x >> 4)
        msb = (lsb ^ (x >> 3) ^ (x << 4)) & 255
        lsb = (x ^ (x << 5)) & 255return (msb << 8) + lsb

Solution 3:

The original function, checkCRC, can also do "CRC-CCITT (XModem)".

Just set:

poly = 0x1021
reg = 0

Instead of

poly = 0x11021
reg = 0xFFFF

Solution 4:

Here is a C version that you can translate to Python:

#define POLY 0x1021/* CRC-16 XMODEM: polynomial 0x1021, init = 0, xorout = 0, no reflection */unsignedcrc16x(unsigned crc, unsignedchar *buf, size_t len){
    while (len--) {
        crc ^= *buf++ << 8;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
        crc = crc & 0x8000 ? (crc << 1) ^ POLY : crc << 1;
    }
    return crc & 0xffff;
}

crc is initialized to zero.

Solution 5:

The accepted answer above is wrong. It does not augment a zero-length input with 16 bits of 0, as given by http://srecord.sourceforge.net/crc16-ccitt.html. Luckily, it can be fixed very easily. I will only post the changes that I've made.

defcrc(str):
    crc = PRESET
    # start crc with two zero bytesfor _ inrange(2):
        crc = _update_crc(crc, 0)
    for c instr:
        crc = _update_crc(crc, ord(c))
    return crc

defcrcb(*i):
    crc = PRESET
    for _ inrange(2):
        crc = _update_crc(crc, 0)
    for c in i:
        crc = _update_crc(crc, c)
    return crc

Now, if we compare the new implementation to the expected CRC values, we get the "good_crc" values instead of "bad_crc" values.