宏实现CRC/校验和：编译时CRC计算宏，校验和生成宏，数据完整性检查

说到数据完整性检查，我脑子里第一个蹦出来的场景是：十年前做的一个工业控制项目，现场总线上的数据包偶尔会莫名其妙地跳变。查了三天，最后发现是CRC校验实现里有个移位顺序搞反了。嗯，从那以后，我对CRC的每一个比特都不敢马虎。

今天咱们聊的，是用宏在编译时就把CRC算好。你想想看，运行时算CRC要占用CPU周期，而编译时算好，直接当常量嵌进去——这不香吗？

为什么要在编译时算CRC？

我个人习惯把「能提前做的事，绝不拖到运行时」。CRC计算就是个典型例子：

  • 运行时计算：每次调用都要循环、移位、异或，费时费力
  • 编译时计算：预处理器展开宏，编译器优化成常量，零运行时开销

说白了，就是拿编译时间换运行效率。对于嵌入式系统这种资源受限的环境，这买卖划算。

CRC的基本原理（快速回顾）

CRC的核心就三个操作：移位、异或、查多项式。常见的CRC-8多项式是 0x07（x^8 + x^2 + x + 1），CRC-16是 0x8005。

计算过程其实不复杂：

  1. 把数据左移，高位补0
  2. 每次移位后检查最高位是否为1
  3. 如果是，就异或多项式
  4. 重复直到所有数据处理完

但用宏来实现，就得换个思路了——宏是文本替换，不能有循环。怎么办？用递归宏展开。

编译时CRC-8计算宏

先看一个简单的CRC-8实现。我当年在写Bootloader时就用过这个套路：

// 定义CRC-8多项式（x^8 + x^2 + x + 1）
#define CRC8_POLY 0x07

// 单字节CRC-8计算（递归宏）
#define CRC8_BYTE(crc, byte) \
    ( ((crc) ^ (byte)) & 0xFF )

// 核心：逐位处理宏
#define CRC8_STEP(crc) \
    ( ((crc) & 0x80) ? \
      ( ((crc) << 1) ^ CRC8_POLY ) : \
      ( (crc) << 1 ) )

// 处理一个字节的8个位
#define CRC8_PROCESS_BYTE(crc, byte) \
    CRC8_STEP(CRC8_STEP(CRC8_STEP(CRC8_STEP( \
    CRC8_STEP(CRC8_STEP(CRC8_STEP(CRC8_STEP( \
    CRC8_BYTE(crc, byte) ))))))))

// 最终宏：计算n字节数据的CRC-8
#define CRC8(data, len) \
    CRC8_CALC(data, len, 0x00)

// 辅助宏（递归展开）
#define CRC8_CALC(data, len, crc) \
    ( (len) == 0 ? (crc) : \
      CRC8_CALC((data)+1, (len)-1, \
                CRC8_PROCESS_BYTE(crc, *(data))) )

关键点：这个宏用了条件表达式（三元运算符）来模拟递归。每次处理一个字节，展开8次移位操作。编译器看到这个宏，会直接算出结果，生成一个常量。

编译时校验和生成宏

CRC有时候太重了，简单的校验和也能满足需求。比如Modbus协议里用的LRC（纵向冗余校验）：

// 简单的累加校验和
#define CHECKSUM(data, len) \
    CHECKSUM_CALC(data, len, 0)

#define CHECKSUM_CALC(data, len, sum) \
    ( (len) == 0 ? (sum) & 0xFF : \
      CHECKSUM_CALC((data)+1, (len)-1, \
                    (sum) + *(data)) )

// XOR校验和（更简单，但检测能力弱一些）
#define XOR_CHECKSUM(data, len) \
    XOR_CALC(data, len, 0)

#define XOR_CALC(data, len, xor_val) \
    ( (len) == 0 ? (xor_val) : \
      XOR_CALC((data)+1, (len)-1, \
               (xor_val) ^ *(data)) )

我在一个传感器数据采集项目里用过XOR校验和。当时MCU的Flash只剩256字节，CRC的查表法放不下，就用这个宏在编译时算好校验值，运行时只做一次比较——省得飞起。

数据完整性检查宏

有了CRC和校验和，怎么用它们做完整性检查？我一般这么设计：

// 定义一个带CRC的数据结构
#define DECLARE_CRC_PROTECTED(name, data) \
    static const uint8_t name##_data[] = data; \
    static const uint8_t name##_crc = CRC8(name##_data, sizeof(name##_data));

// 检查宏
#define CHECK_INTEGRITY(name) \
    ( CRC8(name##_data, sizeof(name##_data)) == name##_crc )

// 使用示例
DECLARE_CRC_PROTECTED(config, {0x01, 0x02, 0x03, 0x04})

void verify_config(void) {
    if (CHECK_INTEGRITY(config)) {
        // 数据完整
    } else {
        // 数据被篡改
    }
}

注意：宏展开的递归深度有限制。C标准要求至少支持63层嵌套，但实际编译器可能更多。如果你的数据很长（比如超过32字节），递归宏可能撑不住。这时候我建议改用X-Macro或者Boost.Preprocessor。

实战：编译时CRC-16查表法

查表法比逐位计算快得多，但表怎么在编译时生成？用宏嵌套：

// CRC-16多项式
#define CRC16_POLY 0x8005

// 生成单字节的CRC-16表项
#define CRC16_TABLE_ENTRY(byte) \
    CRC16_CALC_ENTRY(byte, 0)

#define CRC16_CALC_ENTRY(byte, crc) \
    ( (byte) == 0 ? (crc) : \
      CRC16_CALC_ENTRY((byte)>>1, \
        ((crc) ^ ((byte) & 1 ? CRC16_POLY : 0)) >> 1) )

// 生成整个表（256项）
#define CRC16_TABLE \
    CRC16_TABLE_ENTRY(0),   CRC16_TABLE_ENTRY(1),   \
    CRC16_TABLE_ENTRY(2),   CRC16_TABLE_ENTRY(3),   \
    /* ... 一直写到255 ... */

// 使用时直接声明为静态常量表
static const uint16_t crc16_table[256] = {
    CRC16_TABLE
};

我的经验：生成256项的表，宏展开会非常庞大。我建议用脚本生成（比如Python）把表算好，然后直接粘贴到代码里。宏虽然能实现，但编译时间会暴涨——有一次我试过，编译一个带完整CRC-16表的文件，花了整整47秒。

知识体系图

编译时CRC/校验和知识体系 编译时完整性检查 CRC计算宏 校验和生成宏 CRC-8逐位法 CRC-16查表法 累加校验和 XOR校验和 递归宏展开（三元运算符） 条件编译 + 常量折叠 Bootloader固件校验 通信协议数据包 核心：编译时计算 → 零运行时开销

避坑指南

我曾经在一个项目里吃过亏，分享几个血泪教训：

  • 宏参数不要带副作用：比如 CRC8(data++, len)，宏展开后 data++ 会被多次求值，结果完全不对。我建议传指针，别传表达式。
  • 注意字节序：CRC-16有高位在前和低位在前两种模式。我当年就是搞反了移位方向，导致两个设备对不上。一定要在文档里写清楚。
  • 递归深度有限：超过63层嵌套，编译器可能报错。对于长数据，改用X-Macro或者干脆用constexpr（C99以上支持）。
  • 调试困难：宏展开后的代码很难单步跟踪。我一般先用普通函数验证算法正确，再转成宏。

总结

编译时CRC和校验和宏，说白了就是用编译器的算力换运行时的性能。对于嵌入式系统里那些固定不变的数据（比如固件版本、配置参数、协议头），这个技巧特别实用。

我个人习惯在头文件里放一套完整的CRC宏，配合static const变量，既保证了数据完整性，又不占运行时资源。你想想看，一个宏展开就能搞定的事，何必让CPU在循环里空转呢？

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →