我是单片机爱好者-MCU起航，最近在研究STM32的硬件CRC，根据软件CRC的算法，配置对应STM32CUBEMX中硬件CRC的配置，实现CRC校验的替换。
软件部分代码如下：
uint16_t crc16_calculate(const uint8_t *data, size_t length)
{
uint16_t crc = 0x0000; // 初始值为0x0000
for (size_t i = 0; i < length; i++)
{
crc ^= data[i];
for (int j = 0; j < 8; j++)
{
if (crc & 0x0001)
{
crc = (crc >> 1) ^ 0xA001; // 0xA001是逆序的MODBUS多项式
}
else
{
crc = (crc >> 1);
}
}
}
return crc;
}因为比较懒，一开始我直接把软件部分代码放到AI模型中，让它帮我分析，对应的STM32CUBEMX中应该如何配置。
最终实现STM32CUBEMX中硬件CRC对应的配置如下：
配置完之后，我“灵机一动”，提供了一组数，让AI豆包帮我算一下对应的CRC校验值是多少，于是：
def crc16_custom(data):
crc = 0x0000 # 初始值0x0000
for byte in data:
crc ^= byte
for _ in range(8):
if crc & 0x0001:
crc = (crc >> 1) ^ 0xA001 # 多项式0xA001
else:
crc = crc >> 1
return crc
test_data = bytes([
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F,
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
0xA5, 0x3F, 0x9C, 0x5E, 0x4B, 0x7D, 0x2A, 0x61, 0x86, 0x13, 0xF4, 0x0D, 0x39, 0x52, 0xB7, 0x8A,
0x1E, 0x6C, 0x45, 0x90, 0xD3, 0x27, 0x5A, 0xB1, 0x7E, 0x04, 0x19, 0x8F, 0x36, 0xC2, 0x5D, 0xA0,
0x12, 0x6B, 0x3C, 0x95, 0xE7, 0x4A, 0x81, 0xF3, 0x2D, 0x56, 0x9E, 0x07, 0x4C, 0xB8, 0x31, 0x7A,
0xE1, 0x5F, 0x24, 0x93, 0x68, 0x0E, 0x47, 0xA9, 0xD5, 0x3A, 0x16, 0x8C, 0x62, 0xF7, 0x4E, 0x01,
0xAA, 0x55, 0xAA, 0x55, 0xAA, 0x55, 0xAA, 0x55, 0x33, 0xCC, 0x33, 0xCC, 0x33, 0xCC, 0x33, 0xCC,
0x0F, 0xF0, 0x0F, 0xF0, 0x0F, 0xF0, 0x0F, 0xF0, 0x5A, 0xA5, 0x5A, 0xA5, 0x5A, 0xA5, 0x5A, 0xA5,
0x96, 0x69, 0x96, 0x69, 0x96, 0x69, 0x96, 0x69, 0xC3, 0x3C, 0xC3, 0x3C, 0xC3, 0x3C, 0xC3, 0x3C,
0xF0, 0x0F, 0xF0, 0x0F, 0xF0, 0x0F, 0xF0, 0x0F, 0x81, 0x7E, 0x81, 0x7E, 0x81, 0x7E, 0x81, 0x7E
])
crc_value = crc16_custom(test_data)
print(f"CRC16 (custom): 0x{crc_value:04X}") # 输出：0x6D6A
根据提示信息，它给出的校验值是：0x6D6A。出于稳妥考虑，我换了一个平台，准备再算一次。只要两次结果一样，我就敢放心用了。
我换到了Cherry Studio，在这里接入了DeepSeek V3的模型，把C语言代码给它，让它帮我算一下：
DeepSeek给出的答案是：0x5A5A，不一样。在这时，我认为豆包错了（盲目相信DeepSeek），DeepSeek应该是对的。
于是，我又换了个在线运行C语言的平台，试了一下：
给出的结果是：0x21B6。
三个答案都不一样，有意思了！
这下我不敢偷懒了，软件代码放到单片机里跑了一下，确实是：0x21B6。所以，AI是怎么了？
程序写的挺好，给出的运行结果都不对吗？
重新算一下吧，模拟C语言运行不靠谱，做python解释器应该可以吧，我印象里某个抖音主播介绍过这种玩法，通过这种方法练习python。
下面，我选用了四个模型，问同一个问题（正确结果我已经算好了）：
这是一段CRC校验的程序，你用python模拟一下运行过程，看结果是多少：
#include <stdio.h>
#include <stdint.h>
unsigned char test_data[6] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05};
unsigned int crc16_calculate(const unsigned char *data, unsigned char length) {
unsigned int crc = 0x0000;
for (unsigned char i = 0; i < length; i++) {
crc ^= data[i];
for (int j = 0; j < 8; j++) {
if (crc & 0x0001) {
crc = (crc >> 1) ^ 0xA001;
} else {
crc = (crc >> 1);
}
}
}
return crc;
}
int main() {
unsigned int crc = crc16_calculate(test_data, 6);
printf("CRC16: 0x%04X\n", crc);
return 0;
}
1、kimi k2
这两天kimi k2刚出，先让它来试试：
答案错误，下一位。
2、DeepSeek
上次是让它计算C语言的代码结果，可能难度大一些，这次改成python，我还是有点信心的。
Double Kill，下一位！
3、阿里千问
我在硅基流动那里使用Qwen2.5-Coder-32B-Instruct模型，同样的问题：
Triple kill！不解释…
4、豆包Seed 1.6
之前用的豆包PC端的软件，这次我使用Trae国内版。打开的时候发现有更新，还激动了一下。说不定更新后功能强大，能技压群雄。
Quadra kill！
我呵呵了！
测试结束吧，我能想到的就这些，国外的暂时不考虑。
总结一下：
- 1、四个模型，给出了四个完全不一样的答案，然后都是错的。你们错的都不一样，还真是挺不容易的。
- 2、给出的python代码，放到python中运行，结果倒是对的。
- 3、如果做不了python解释器，那就直说。做不了，却硬要做，给答案的时候还很自信，这样不好啊！
所以，这次不经意的尝试给我敲了一次警钟，不要过度相信AI。但我还是很好奇，因为我个人感觉这不是一个很复杂的功能，但都无法实现，所以这是为什么？
最后，鉴于AI模型持续迭代优化，本文测试结果代表当前版本（2025年7月20日）的性能表现。我将持续跟踪各模型的更新动态，并在以下节点重新测试：
- 新版本发布后
- 厂商明确修复相关缺陷后
- 收到读者反馈矛盾结果时
更新的测试数据将同步至公众号平台，确保结论的时效性。
最后的最后，测试用的STM32工程代码，我打包放到了公众号后台，感兴趣的可以自己试一下。回复关键词：030，或者“32硬件CRC”，即可获取下载链接。