2. 常见CRC算法对比：CRC-8/16/32/CCITT参数模型、查表法与直接计算法的取舍

2.1 CRC算法参数模型剖析

CRC算法的核心差异在于其参数模型的定义。同一个多项式，若初始值、结果异或值或输入/输出反转规则不同，计算出的校验码完全不同。蓝牙协议栈与嵌入式系统中最常用的四种CRC模型如下：

2.2 直接计算法与查表法：原理与性能对比

直接计算法（Bit-by-Bit / Shift-Register）是软件实现CRC的最直观方式：逐位处理输入数据，通过多项式进行模2除法。其核心操作为移位与异或。

// CRC-8 直接计算法核心循环（C语言示意）
uint8_t crc8_direct(uint8_t *data, size_t len, uint8_t poly) {
    uint8_t crc = 0x00;
    for (size_t i = 0; i < len; i++) {
        crc ^= data[i];
        for (int bit = 0; bit < 8; bit++) {
            if (crc & 0x80)
                crc = (crc << 1) ^ poly;
            else
                crc <<= 1;
        }
    }
    return crc;
}

查表法（Table-Driven）利用预计算的查找表将逐位处理优化为逐字节处理。每字节的8位CRC变化被合并为一次查表和异或操作，速度提升约8倍。

// CRC-8 查表法核心循环（C语言示意，表已预生成）
static const uint8_t crc8_table[256] = { /* 预计算多项式0x07的表 */ };

uint8_t crc8_table_driven(uint8_t *data, size_t len) {
    uint8_t crc = 0x00;
    for (size_t i = 0; i < len; i++) {
        crc = crc8_table[(crc ^ data[i]) & 0xFF];
    }
    return crc;
}

2.3 算法取舍决策流程

2.4 蓝牙协议栈中的CRC配置示例

以Zephyr RTOS蓝牙协议栈为例，ACL数据包接收时自动启用CRC-32校验。开发者可通过以下配置项调整CRC行为：

# Zephyr蓝牙CRC相关配置 (prj.conf)
# 启用蓝牙HCI CRC硬件加速（若SoC支持）
CONFIG_BT_HCI_CRC_HW_ACCELERATION=y

# 调试时禁用CRC校验（仅用于抓包分析，不可用于生产）
# CONFIG_BT_HCI_CRC_SKIP_CHECK=y

# CRC查表法内存分配（软件模式）
CONFIG_BT_CRC_TABLE_SIZE=1024

2.5 性能优化实战要点

• 查表法表生成时机：在系统初始化时计算一次（crc_table_init()），或直接使用编译期常量数组。
• 蓝牙数据包边界：利用蓝牙控制器自动CRC校验中断，避免软件重复计算。
• 批量校验优化：当蓝牙L2CAP层连续接收多个小帧时，可合并计算CRC以降低函数调用开销。
• 查表法 vs DMA：部分蓝牙SoC（如Nordic nRF53/54系列）提供硬件CRC引擎，此时直接使用寄存器配置即可，软件查表法可完全省略。

// 蓝牙HCI硬件CRC寄存器配置示意（STM32WB系列）
// 使能CRC-32，多项式0x04C11DB7，初始值0xFFFFFFFF
CRC->CR = CRC_CR_RESET | CRC_CR_REV_IN | CRC_CR_REV_OUT;
CRC->INIT = 0xFFFFFFFF;
CRC->POL = 0x04C11DB7;
// 逐字节写入数据
for (uint8_t *p = data; p < data + len; p++) {
    CRC->DR = *p;
}
uint32_t hw_crc = CRC->DR;  // 读取最终CRC-32值

2.6 课后自查：算法选择决策清单

• 是否为蓝牙HCI数据包？→ CRC-32查表法或硬件CRC
• 是否为蓝牙H4 UART帧尾？→ CRC-8直接计算法（字节数少）
• 是否支持硬件CRC加速？→ 优先硬件，其次查表法
• 是否需要在运行时切换CRC模型？→ 必须使用直接计算法
• 查表法表空间是否超过剩余RAM的10%？→ 如果“是”，考虑部分查表或折半查表