上篇把手册切成了能喂的片段。这篇让 AI 生成驱动，目标 STM32 和 ESP32 的外设代码。
虽然使用 AI 生成驱动省时间，但写出来的代码别急着烧录，回来把这份验收清单过一遍，能挡掉大半“上板不工作”。
文末那份验收提示词能直接抄。数据、易错类型，都在前面。
01 三组公开数据，AI 写的驱动能信多少
华盛顿大学进行了一组实验（ arXiv:2307.03817 ），用了三个模型：GPT-3.5、GPT-4、PaLM 2。共 450 次实验，全在真板子上跑。
GPT-4 写 I2C 接口呢，50 次里 66% 一次跑通。GPT-3.5 和 PaLM 2 在同样任务上还要再差一截。模型选型对结果的影响，跟提示词怎么写一样大。
剩下那 34%，编译全过，板子上就是不工作。
同一篇还测了人和 AI 搭配。15 个用户，从零硬件经验的到老手，用 AI 辅助搭一个 LoRa 环境传感器，成功率从 25% 涨到 100%。能涨这么多，靠的是反馈：人能判断硬件行为对不对，把板子上的真实反应反馈给 AI，AI 再改。缺了这条反馈，模型只能靠猜。
今年 6 月的 Embedded Arena 更极端（ arXiv:2606.16190 ）。Claude Opus 4.7 和 Gemini 3.1 Pro，不给硬件反馈，让它们自己把固件部署到 MCU 上。
成功率 0%。
同一个任务接上硬件反馈，三次迭代内首次成功，七次内超过人类专家。最难的那个任务，部署成功率 80%。
▲ 裸生成 66%、人参与 25% 到 100%、无硬件反馈 0% 对硬件在环 80%（据 arXiv 数据自绘）
三组数据放一起看，差距都出在反馈上。AI 写驱动能干活，但离了硬件反馈和人来兜底，不靠谱。
02 编译通过，不等于能上板运行
先说代码为什么看着没问题。2025 年有篇论文专门测这个（ arXiv:2509.09970 ），结论是 LLM 生成的固件，语法准确，语义上常有缺陷。
语法准确的意思是编译器挑不出毛病。
语义缺陷的意思是寄存器值不对、初始化顺序不对、安全检查漏了。这些编译器全都不管。寄存器赋值在编译器眼里，跟普通变量赋值没有区别，它不读手册，不知道这一行该写 0x01 还是 0x02，只管语法和类型对不对。
论文用模糊测试在生成的固件上抓出缓冲区溢出、竞态条件、拒绝服务，对应 CWE-120、CWE-362、CWE-400。
所以编译通过这条线，在嵌入式里参考价值有限。这条线为什么重要？因为多数人把编译通过当成了写对。在嵌入式里，这两件事中间隔着一整个硬件层。真正要紧的是烧进去之后外设是否正常工作。
03 AI 最容易写错的几处
还是那篇华盛顿大学的实验，模型局限归纳成三类：任务理解错、幻觉、版本和库错误。
放到驱动代码上，常见的是下面这几类。
时钟树：外设时钟没使能，或者使能位写给了别的外设。代码编译全过，外设静默。外设静默这个说法不夸张，时钟没使能，寄存器写了也白写，读回来全是复位值，代码一路跑完，什么都没发生。
寄存器数值：地址没错，位域没错，某个默认值记错。这种最坑，因为它跟正确写法长得一模一样。
库版本：拿 F1 的写法套 F4，HAL 函数名全对，参数含义不一样。训练数据里各版本混着，它不挑。
还有一类是中断和 DMA。优先级配错、回调函数写错、DMA 方向和宽度不匹配，症状是死循环、丢数据、或者程序跑飞。这类错最费排查时间，因为报错点离出错点很远。
时序计算：定时器分频算错，期望频率和实际频率差一倍，编译同样不报错。
拿 PWM 举例。你要 20 kHz 的 PWM，预分频值或自动重载值错一位，输出变成 10 kHz。代码不报错，示波器一测，频率差一半。
▲ 分频系数错一位，频率差一倍，编译不报错（错误模式演示，非实测数据）
这类错误我手上没有能公开的实测样本。错误模式本身在论文里反复出现，共同点是编译工具抓不到，只有上板测量才暴露。
04 验收清单，哪些坑必须人工盯
我的核对顺序是这样，从简单到复杂。先静态后动态：静态的不用上电，顺手就能干；动态的要板子在手，烧录验证，时间成本高一截。
先核时钟树。芯片主频、外设挂哪条总线、总线时钟多少、时钟使能位在 RCC 哪个寄存器。对着 参考手册 核，十分钟以内。
再逐行核对寄存器。生成代码里的赋值，一行行跟手册寄存器表对。地址、位域、复位值、读写属性。主要风险都在这，这一遍最费时间。核对有个省事的办法：把期望值写进注释，跟 AI 生成的那行并排，一眼就看出差在哪。我一般先核读写属性和复位值，这两列最容易错。
再核时序相关段。波特率、定时器分频、采样时序、脉冲宽度，拿笔算一遍，跟代码里的值对。
再核中断和 DMA。优先级、使能位、回调函数、DMA 方向和宽度，错一个就是死循环或者丢数据。
收尾上板。串口回环、GPIO 翻转看波形、定时器输出实测频率，用最简单的办法确认外设真的在工作。
▲ 从静态核对到上电验证的五步验收顺序（自绘）
前四步是静态核对，剩下的交给上电验证。静态步骤挡掉大部分问题，上板步骤挡掉剩下的。
05 上板验证，怎么省时间
上板最怕盲目验证。烧之前先想清楚：怎么算它工作正常？
串口是最简单的验证工具。初始化代码里加一行打印，把寄存器实际值打出来，跟期望值对。回环是最快的串口验收：把 TX 接到 RX，发一串数据，能原样收回来，这条链路就通了，五秒钟的事。
时序验证用 GPIO 翻转加示波器。定时器输出直接接示波器，频率和占空比一测就知道。
还有个办法能省大半核对时间：生成代码时要求它逐行注明依据——这一行来自手册哪一页、哪个寄存器、哪个位。写不出依据的，多半是自己编的。
06 一份能直接抄的验收提示词
前面几节合起来就是这样，方括号里换成你自己的。
# 目标
[芯片型号，如STM32F103C8T6，外部晶振8MHz，SYSCLK 72MHz]
[外设与需求，如USART1，115200波特率，8N1]
# 生成要求
- 用HAL库或寄存器方式均可，先说明你选哪种
- 每一步初始化，写明改了哪个寄存器的哪一位，依据来自手册哪一页
- 时钟使能、GPIO复用、中断配置分开列出
- 手册里没写的，直接说没写，不要推测
# 输出后自查
- 逐行核对寄存器赋值与手册
- 重算波特率与分频值
- 检查中断与DMA方向
生成完，把第 04 节那五步过一遍再上板。
模板里“输出后自查”那四条，先让它自己跑一遍。多数数值错误它自己能找出来，找不出来的再轮到你核。
它给不出依据的地方，先别让它改，回去查手册把依据补上。硬让它编，编出来还是错的。
07 下期预告
驱动生成和验收都有了。下篇换 AI 当代码审查员，重点扫寄存器、中断、DMA 和内存安全，会附一份审查清单。
本篇数据都有出处：Embedded Arena 的部署成功率来自 arXiv:2606.16190；华盛顿大学 450 次实验、I2C 的 66% 和 LoRa 的 25% 到 100% 来自 arXiv:2307.03817；LLM 固件语义缺陷与 CWE 漏洞类型来自 arXiv:2509.09970。PWM 分频错位的例子是错误模式演示，不是本号实测。五步验收顺序和提示词模板是我自己的操作习惯，仅供参考。封面配图由 AI 技术生成。
发表于 15 小时前
|
查看: 22|
回复: 0
