util_crc(3avr)

💅 util_crc(3avr) 💅

okay so real talk bestie, this is util_crc — the CRC page from section 3avr — and it's genuinely one of those pages that looks scary and then turns out to be the most helpful bestie in the whole toolchain. no cap. let's go 💖

---

✨ NAME ✨

util_crc — <util/crc16.h>: CRC Computations

---

🌸 SYNOPSIS 🌸

Functions

static uint16_t _crc16_update (uint16_t __crc, uint8_t __data)
static uint16_t _crc_xmodem_update (uint16_t __crc, uint8_t __data)
static uint16_t _crc_ccitt_update (uint16_t __crc, uint8_t __data)
static uint8_t _crc_ibutton_update (uint8_t __crc, uint8_t __data)
static uint8_t _crc8_ccitt_update (uint8_t __crc, uint8_t __data)

---

📖 Detailed Description 📖

#include <util/crc16.h>

slay, here's the whole point: this header file hands you optimized inline functions for calculating cyclic redundancy checks (CRC) using common polynomials. they're inline, they're fast, they're everything. 💫

References — the receipts, because she cites her sources:

• go read the Dallas Semiconductor app note 27 for an 8051 assembler example plus general CRC optimization suggestions. the table on the last page of that app note? that's literally the key to understanding these implementations. iykyk 🔑
• Jack Crenshaw's "Implementing CRCs" article in the January 1992 issue of Embedded Systems Programming. lowkey hard to find, but it explains CRCs in very clear and concise terms. well worth the effort to obtain a copy. do it.

a typical application would look like this, and yes it's giving main character energy:

// Dallas iButton test vector.
uint8_t serno[] = { 0x02, 0x1c, 0xb8, 0x01, 0, 0, 0, 0xa2 };

int
checkcrc (void)
{
    uint8_t crc = 0, i;

    for (i = 0; i < sizeof serno / sizeof serno[0]; i++)
        crc = _crc_ibutton_update (crc, serno[i]);

    return crc; // must be 0
}

---

🧮 Function Documentation 🧮

uint16_t _crc16_update (uint16_t __crc, uint8_t __data) [inline], [static]

Optimized CRC-16 calculation. ✨

• Polynomial: x16 + x15 + x2 + 1 — that's 0xa001
• Initial value: 0xffff

this CRC is normally used in disk-drive controllers. iconic lineage honestly.

the following is the equivalent functionality written in C:

uint16_t
crc16_update (uint16_t crc, uint8_t a)
{
    crc ^= a;
    for (int i = 0; i < 8; ++i)
    {
        if (crc & 1)
            crc = (crc >> 1) ^ 0xA001;
        else
            crc = crc >> 1;
    }

    return crc;
}

---

uint8_t _crc8_ccitt_update (uint8_t __crc, uint8_t __data) [inline], [static]

Optimized CRC-8-CCITT calculation. 🎀

• Polynomial: x8 + x2 + x + 1 — that's 0xE0

and now the three flavours, bestie, each with its own vibe:

• for use with simple CRC-8 — initial value: 0x0
• for use with CRC-8-ROHC — initial value: 0xff, reference: http://tools.ietf.org/html/rfc3095#section-5.9.1
• for use with CRC-8-ATM/ITU — initial value: 0xff, final XOR value: 0x55, reference: http://www.itu.int/rec/T-REC-I.432.1-199902-I/en

ngl the C equivalent was originally written by Dave Hylands, and the assembly code is based on the _crc_ibutton_update optimization. credit where it's due 🫶

the following is the equivalent functionality written in C:

uint8_t
_crc8_ccitt_update (uint8_t inCrc, uint8_t inData)
{
    uint8_t data = inCrc ^ inData;

    for (int i = 0; i < 8; i++)
    {
        if ((data & 0x80) != 0)
        {
            data <<= 1;
            data ^= 0x07;
        }
        else
        {
            data <<= 1;
        }
    }
    return data;
}

---

uint16_t _crc_ccitt_update (uint16_t __crc, uint8_t __data) [inline], [static]

Optimized CRC-CCITT calculation. 💜

• Polynomial: x16 + x12 + x5 + 1 — that's 0x8408
• Initial value: 0xffff

this is the CRC used by PPP and IrDA. so like, very employed, very booked and busy.

see RFC1171 (PPP protocol) and IrDA IrLAP 1.1 📚

Note — okay this part matters, don't skip it: although the CCITT polynomial is the same as the one used by the Xmodem protocol, they are quite different. the difference is in how the bits are shifted through the algorithm. Xmodem shifts the MSB of the CRC and the input first, while CCITT shifts the LSB of the CRC and the input first. same polynomial, wildly different behaviour, it's giving twins who are nothing alike. 💀

the following is the equivalent functionality written in C:

uint16_t
crc_ccitt_update (uint16_t crc, uint8_t data)
{
    data ^= lo8 (crc);
    data ^= data << 4;

    return ((((uint16_t)data << 8) | hi8 (crc)) ^ (uint8_t)(data >> 4)
            ^ ((uint16_t)data << 3));
}

---

uint8_t _crc_ibutton_update (uint8_t __crc, uint8_t __data) [inline], [static]

Optimized Dallas (now Maxim) iButton 8-bit CRC calculation. 🦋

• Polynomial: x8 + x5 + x4 + 1 — that's 0x8C
• Initial value: 0x0

see http://www.maxim-ic.com/appnotes.cfm/appnote_number/27 ⭐ (yes it's the same app note 27 from up top, she comes back, she's consistent)

the following is the equivalent functionality written in C:

uint8_t
_crc_ibutton_update (uint8_t crc, uint8_t data)
{
    crc = crc ^ data;
    for (uint8_t i = 0; i < 8; i++)
    {
        if (crc & 0x01)
            crc = (crc >> 1) ^ 0x8C;
        else
            crc >>= 1;
    }

    return crc;
}

---

uint16_t _crc_xmodem_update (uint16_t __crc, uint8_t __data) [inline], [static]

Optimized CRC-XMODEM calculation. 🌈

• Polynomial: x16 + x12 + x5 + 1 — that's 0x1021
• Initial value: 0x0

this is the CRC used by the Xmodem-CRC protocol. periodt.

the following is the equivalent functionality written in C:

uint16_t
crc_xmodem_update (uint16_t crc, uint8_t data)
{
    crc = crc ^ ((uint16_t)data << 8);
    for (int i = 0; i < 8; i++)
    {
        if (crc & 0x8000)
            crc = (crc << 1) ^ 0x1021;
        else
            crc <<= 1;
    }

    return crc;
}

---

👑 Author 👑

Generated automatically by Doxygen for AVR-LibC from the source code. she didn't write herself, she was generated, and honestly? still ate. 💅✨

---

and that's the whole page bestie 🫶 this was AVR-LibC, Version 2.2.1 — yes, version 2.2.1, that's the one, no cap. go forth and checksum your little heart out. bye bye! 🎀💖🌟