裸机编程这些年一直被当成嵌入式入门的第一道坎。你会发现一个奇怪的现象明明开源工具链已经成熟到能搞定大部分MCU了网上教程也堆成山了可真正自己从零做一个可用的裸机项目该卡还是卡。我最近一直在折腾一套“开源嵌入式Skill”的玩法把AI技能包、开源工具链、芯片手册知识这三样东西拧成一条龙实测下来确实能让裸机开发少走很多弯路。这篇就从头到尾讲清楚这套玩法适合刚入门想摆脱“只会抄例程”状态的单片机爱好者也适合想用AI改造现有嵌入式工作流的工程师。1. 裸机编程的底牌没有操作系统不等于没有章法想玩转这套“一条龙”得先把裸机这件事看透。很多人把裸机编程理解成“不用操作系统拿寄存器点点灯”这个理解没错但太浅了。裸机编程的本质是你在跟硬件直接对话没有进程调度、没有内存管理、没有文件系统你写下的每一行C代码最后都要精确地落成对寄存器、中断向量、链接脚本的操作。这不是“没有章法”反而是一套极其严密的章法只是这套章法藏在一摞几千页的芯片手册里。1.1 裸机到底是什么裸机编程就是程序直接在硬件上运行不依赖任何操作系统内核。你常见的三种嵌入式开发模式是开发模式有没有OS典型场景上手难度裸机无小家电、传感器节点、电机控制、玩具中等依赖底层知识RTOS有轻量级RTOS通信网关、复杂工控、多任务采集较高涉及任务调度Linux/Android有完整OS路由器、开发板、边缘计算高涉及内核和驱动裸机不是过时而是嵌入式系统的底层逻辑。哪怕你未来要搞RTOS、搞Linux驱动寄存器、中断、时钟树、外设时序这些基本功全是在裸机阶段打下的。而且对绝大多数MCU应用来说裸机反而是最优解省资源、响应快、代码可控、不需要额外维护一个调度器。1.2 难的不是点灯是信息链断裂很多人初始学裸机买一块开发板打开配套例程改两行代码灯亮了很开心。但一旦脱离例程自己动手写一个新的外设初始化立刻翻车。为什么因为裸机开发真正的难点根本不在“把代码写出来”而在于一条完整的信息链路芯片选型 → 阅读数据手册 → 理解时钟树 → 配置外设寄存器 → 写启动文件和链接脚本 → 编译出固件 → 烧录 → 用调试器观测 → 排查异常。这条链路上的每一环都可能断掉。芯片手册几百上千页寄存器位动辄几十个启动文件的栈指针、向量表、初始化段链接脚本的FLASH分配、RAM分配稍微错一点轻则程序跑飞重则烧录完没反应。以前我们只能靠翻手册、搜论坛、看厂商例程一步一步把信息拼起来这是“求人”的根源求厂商示例求论坛老哥求导师师兄。1.3 开源生态给你的“底牌”但到了现在情况已经变了。开源生态把这条链路上的很多“求人点”直接填平了编译器用arm-none-eabi-gcc老牌开源稳定可靠完全免费芯片支持库用CMSISARM官方的硬件抽象层几乎所有Cortex-M芯片都能用厂商寄存器库/HAL库也有开源版本比如STM32Cube系列乐鑫的ESP-IDFNXP的MCUXpresso SDK烧录调试有OpenOCD加 ST-Link/J-Link/DAPLink完全开源工程构建有 Makefile/CMake配合 VSCode 的嵌入式扩展体验不输商业IDE。也就是说以前需要“求人”的编译环境、调试工具、启动代码现在开箱即用。剩下的核心问题只有一个怎么把“芯片手册知识 实际工程经验”高效地用起来。这就是我要说的Skill机制能发挥最大价值的地方。2. Skill机制让AI从“答手”变成“工程师”现在很多嵌入式开发者已经习惯了用AI写代码但大部分人用的是“聊天式”AI问一句答一句让AI写一个驱动它就愣愣地写一个驱动。你兴高采烈地复制到工程里编译报错或者烧进去跑飞。为什么因为聊天式AI没有上下文不知道你的芯片具体型号、不知道你用哪个库、不知道你的工程目录长什么样、更不知道你踩过什么坑。它只是在“答题”不是在“干活”。Skill机制解决的就是这个问题。2.1 普通AI为什么搞不定裸机代码你让AI写一段STM32G4的Flash擦写代码它可能会给你一份适用F1/F4的API调用你让它写DMA配置它会假设你用的HAL库甚至把中断优先级都写混。为什么会这样因为裸机开发对“精确性”的要求是变态级别芯片型号差一个字母外设寄存器地址就变时钟源差一个波特率就翻车编译优化等级不同volatile写错直接出玄学bug。普通AI没有你的工程上下文当然只能靠猜。我自己踩过最典型的坑让AI生成STM32F103的ADC多通道采样代码它给了一份看起来完美无缺的代码结果DMA搬运的缓冲区长度和外设寄存器配置是F3的烧进去采样数据永远是0。你看Chat式AI就是这样它能编出看起来很合理的东西但不在你这个具体芯片、具体工程环境下它就是会“一本正经地胡说八道”。2.2 一个Skill到底长什么样所谓Skill本质上是一个“面向特定领域的AI技能包”它把一个角色设定、一套完整工作流、一组领域知识、一批输出规范打包在一起让AI在触发这个Skill时按照固定的套路处理问题不再漫无边际。我常用的一套嵌入式Skill目录结构大概长这样stm32-baremetal-skill/ ├── SKILL.md ├── reference/ │ ├── stm32g4-flash-notes.md │ ├── clock-tree-checklist.md │ └── register-map-notes.md ├── protocols/ │ └── coding-standards.md └── examples/ ├── flash_read_write.c └── dma_uart_rx.c其中SKILL.md是这个技能包的入口里面定义了AI的角色、任务边界、处理流程和输出格式。我那个SKILL.md核心部分大概是这样的# STM32 Baremetal Engineer Skill 你是专注于ARM Cortex-M裸机开发的资深嵌入式工程师。 ## 你的任务 帮助用户完成基于寄存器级/LL库的裸机驱动开发、调试与代码审查。 ## 工作流程 1. 先确认芯片具体型号和所用外设。 2. 确认时钟源和系统时钟配置。 3. 查阅reference/中的芯片手册摘要必要时补充官方手册。 4. 给出完整可编译的C代码注明关键寄存器含义。 5. 输出检查清单提示用户必须人工核对的部分。 ## 硬性规范 - 默认采用LL库或纯寄存器操作不引入HAL抽象层除非用户明确要求。 - 所有外设寄存器访问必须使用volatile指针。 - 必须提供备份寄存器/Flash操作前的“读-改-写”保护注释。 - 中断服务函数中禁止调用printf等不可重入函数。 ## 已知坑点 - 擦除Flash前必须先关中断否则CPU取指失灵。 - 某型号DMA1和DMA2的时钟使能位在RCC的不同寄存器不可混淆。看到区别了吗当AI带上这个Skill后它不再是“AI”而是一个“懂你这套工程的嵌入式同事”。你提需求它知道要按你的工作流走先确认芯片型号再查你的知识库最后给代码加检查清单。2.3 把芯片手册“装”进Skill信息链就通了Skill另一个杀手级用法是把原本“信息链断裂”的环节接上。我把芯片参考手册中关于Flash控制寄存器、时钟树配置、启动流程的摘要整理成Markdown笔记放到reference/目录下。AI在回答问题时会主动读取这些笔记而不是凭空生成。举个例子我之前整理了一份STM32G474的Flash写入注意事项里面记录着“写Flash时CPU不能从同一块Flash取指必须把关键代码放到RAM执行”这类经验。以前遇到这种问题我得翻几百页手册、搜半天论坛才能想起来现在Skill直接把它注入到AI的上下文里AI生成代码时会自动带上这个约束还会在代码注释里标明原因。这一步非常关键“不求人”的底气来源于知识不再被困在零散的网页和手册里而是沉淀成结构化、可复用的技能包。你用一次这个技能包就真真正正属于你了。3. 开源工具链搭一条真正的裸机开发流水线聊完Skill回到最落地的部分怎么搭一条真正能用、可复现的裸机开发流水线。这里没有玄学全是实操。我以目前最常用的Cortex-M开发场景为例把工具链一条条列清楚。3.1 工具选型为什么我不用商业IDE很多新手一上来就装集成IDE点一下按钮就能编译烧录确实方便。但问题是IDE遮蔽了太多细节而且不便于自动化、不便于多人协作、不便于Skill介入。你想用AI帮你生成代码、然后用命令行自动编译烧录结果IDE把构建过程封装得严严实实你根本插不进手。所以我推荐的是一条命令行优先的全开源链路环节工具说明编译arm-none-eabi-gccARM官方开源GCC工具链构建CMake Make/Ninja管理多目录、多目标烧录OpenOCD开源烧录调试框架调试arm-none-eabi-gdb pyOCD源码级调试编辑VSCode配合C/C插件和CMake插件调试器硬件ST-Link / DAPLink / J-Link二三十块钱的DAPLink足矣这套链路的好处是整个流程都是文本可配置的AI可以完全看懂并参与工程模板放到Git里同事拉下来一条命令就能编译。3.2 搭建一个干净的CMake裸机模板CMake模板设计因人而异但有几个关键点必须守住芯片型号、编译器Flag、链接脚本、启动文件、源码目录。我常用的最小模板大致长这样cmake_minimum_required(VERSION 3.22) project(baremetal_demo C ASM) set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-none-eabi-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/linker/STM32G474RETx_FLASH.ld) add_compile_definitions( STM32G474xx USE_HAL_DRIVER STM32G4 ) add_compile_options( -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -O2 -Wall -Werror ) add_executable(${PROJECT_NAME} src/main.c src/stm32g4xx_hal_msp.c startup/startup_stm32g474xx.s ) target_link_options(${PROJECT_NAME} PRIVATE -T ${LINKER_SCRIPT} -specsnano.specs -specsnosys.specs )这里有几个细节值得说道说道。第一是-mcpucortex-m4 -mfloat-abihard -mfpufpv4-sp-d16这三个flag必须和芯片硬件严格匹配STM32G474是Cortex-M4F核心带单精度FPU如果搞错浮点指令会直接hardfault。第二是-specsnano.specs它用newlib-nano替代完整的newlib能把固件体积砍掉一大截适合没有外部存储的MCU。第三是启动文件和链接脚本最好从芯片厂商的cube包里拷出来自己手写容易在数值上翻车。CMake本质上是“生成器”它不直接编译而是生成Makefile或Ninja文件。有了这个模板AI就能很轻松地帮你往工程里加新源文件、新头文件路径甚至让它帮你检查CMake配置里芯片型号是否一致。3.3 烧录调试链路OpenOCD那点事编译出来的是.elf和.hex文件下一步是烧录。OpenOCD的配置也是一样一条命令就能搞定openocd -f interface/stlink.cfg -f target/stm32g4x.cfg -c program build/baremetal_demo.elf verify reset exit这条命令的含义是指定使用ST-Link调试器目标芯片是STM32G4系列把编译好的elf文件写入芯片校验复位运行然后退出。如果你是DAPLink把interface/stlink.cfg换成interface/cmsis-dap.cfg就行。调试的话开两个终端# 终端1启动OpenOCD并等待GDB连接 openocd -f interface/stlink.cfg -f target/stm32g4x.cfg # 终端2用GDB连接加载elf并调试 arm-none-eabi-gdb build/baremetal_demo.elf (gdb) target remote localhost:3333 (gdb) load (gdb) continue看断点、看寄存器、看内存、看反汇编这套组合能干完商业IDE能干的绝大部分活。尤其是查HardFault的时候GDB里输入info registers、bt几个命令比在IDE里点来点去高效得多。配合VSCode的Cortex-Debug扩展还能在编辑器里可视化加断点。3.4 在VSCode里把整个流程串起来命令行是底牌但日常开发我还是会回到VSCode。装几个开源插件就能串起整个流水线C/C扩展提供代码补全和跳转CMake Tools负责构建任务Cortex-Debug负责烧录和调试。.vscode/launch.json里我常用这样一个调试配置{ name: OpenOCD Debug, type: cortex-debug, request: launch, servertype: openocd, cwd: ${workspaceFolder}, executable: build/baremetal_demo.elf, device: STM32G474, configFiles: [ interface/stlink.cfg, target/stm32g4x.cfg ], svdFile: STM32G474.svd }特别注意那个svdFile。SVD文件是ARM的“系统视图描述文件”里面存着芯片所有寄存器位定义的映射有了它VSCode的调试窗口里能直接看到每个寄存器的名称和位值而不是一堆十六进制数字。芯片厂商官方一般都会发布SVD文件或者在开源社区能找到。这一步对整个开发体验的提升非常大强烈建议配置上。4. 实战演练用Skill驱动STM32完成片上Flash参数存取工具链和Skill机制都讲清楚了现在来一次完整的实战。这一节我会用自己最近做的STM32G474校准参数存取作为案例完整演示“Skill一条龙”是怎么落地的。4.1 案例目标与原始需求需求听起来很简单把一组传感器的零点校准参数存到片上Flash里掉电不丢失上电自动读取并且支持运行时重新校准和更新。我以前做这类功能流程是打开几百页芯片手册找到Flash章节 → 确认扇区大小、擦写时序 → 写擦除函数 → 写编程函数 → 写读取函数 → 想好怎么兼顾磨损均衡 → 最后还要加一个备份区防止写到一半掉电导致开不了机。每一步都得小心翼翼。这次我换了个思路先建Skill再让AI来干。4.2 喂给Skill的“领域知识”长什么样我做的第一件事不是让AI写代码而是往Skill的reference/里塞知识。这个过程不需要写几千字把关键信息整理清楚就行。比如STM32G4系列Flash操作我记了三类要点擦除粒度一个扇区为单位G4系列不同扇区大小不同擦除前必须检查BSY位必须关全局中断编程粒度一次编程可以写8位、16位、32位或64位但为了保证掉电安全最好以32位对齐写入数据保护校准数据体结构建议带“魔术数校验和备份区”这样能判断数据是否有效并支持从备份区恢复。这些知识一部分来自手册摘要一部分是我从几次“写Flash把板子写挂”的经历里总结的。我顺手把它们整理成Markdown放进reference/stm32g4-flash-notes.md。趁手的工具配合真正有用的经验这套循环才开始发挥威力。然后我在与AI对话中触发这个Skill描述具体需求芯片具体型号、希望的数据结构、需要几个存储槽位、旧数据和新数据的校验逻辑。AI加载Skill后会回调我那几份领域知识笔记再结合我的需求生成代码。4.3 AI生成结果与人工审查重点AI生成的代码骨架我直接贴核心片段简化后的写入流程大概是这样typedef struct { uint32_t magic; uint32_t crc32; uint16_t vref[8]; uint16_t offset[8]; } calib_data_t; static void flash_write_calib(const calib_data_t* data) { __disable_irq(); while (FLASH-SR FLASH_SR_BSY); // 解锁Flash FLASH-KEYR 0x45670123UL; FLASH-KEYR 0xCDEF89ABUL; // 擦除扇区 FLASH-CR | FLASH_CR_PER; FLASH-CR | (FLASH_CR_SNB (CALIB_SECTOR FLASH_CR_SNB_Pos)); FLASH-CR | FLASH_CR_START; while (FLASH-SR FLASH_SR_BSY); // 循环写数据32位对齐 uint32_t* dst (uint32_t*)CALIB_ADDR; const uint32_t* src (const uint32_t*)data; for (int i 0; i sizeof(calib_data_t) / 4; i) { FLASH-CR | FLASH_CR_PG; *dst *src; while (FLASH-SR FLASH_SR_BSY); FLASH-CR ~FLASH_CR_PG; } // 加锁 FLASH-CR | FLASH_CR_LOCK; __enable_irq(); }看起来挺像回事吧但千万不要直接烧录。我人工审查时重点查了几处擦除扇区的编号CALIB_SECTOR确认G474这款芯片这个扇区的起始地址和大小到底是多少代码在擦除期间是否有可能被中断抢占所以AI在开头和结尾做了__disable_irq()/__enable_irq()这个处理是对的写Flash时CPU是否在同一个Flash区取指如果校准区和执行代码在同一个扇区擦除瞬间取指就会出问题——这个在G4上尤其要小心所以我最后把擦写函数放到了RAM执行或者在链接脚本里做了段重定向。AI生成代码只能算完成了50%剩下50%是人工审查和硬件联调。但至少原本要花半天翻手册才能理清的头绪现在十几分钟就能进入深度审查阶段效率提升非常明显。4.4 编译烧录与实测审查完代码走一遍我们前面搭好的流水线cmake -B build -G Ninja . cmake --build build openocd -f interface/stlink.cfg -f target/stm32g4x.cfg -c program build/baremetal_demo.elf verify reset exit编译一次通过烧录后串口打印如下[INFO] Calib data found, magic OK, crc OK. vref[0]2047 offset[0]-12 [INFO] Sensor calibration updated. [INFO] Rebooting to verify reload... [INFO] Calib data found, magic OK, crc OK. vref[0]2047 offset[0]-13第二次读取的offset和第一次差了1是我在测试中途碰了一下传感器导致的这反而证明Flash存取和读取逻辑是正常工作的。整个过程从建Skill到验证通过一共花了一个下午。换两年前光翻手册定位扇区地址、查擦写时序就要半天。5. 站在开源肩膀上这些Skill资产可以直接抄很多人看完上面的流程会问这套Skill是纯自己写的吗有没有现成的可以直接用答案是都有但目前比较分散我按使用场景分个类。5.1 最值得收藏的几类开源仓库先说说“开源知识资产”这块。裸机开发里芯片相关知识和工程模板是复用得最频繁的东西。芯片厂商的官方SDK和示例仓库ST的STM32CubeG4、STM32CubeF1NXP的MCUXpresso SDK乐鑫的ESP-IDF。这些仓库里绝大多数代码是开源的而且是“行为最接近芯片真相”的代码。在做Skill时与其自己写摘要不如直接把官方示例的某个外设驱动丢进reference/里当参考。CMSIS-PackARM官方的CMSIS软件包结构里面包含了SVD文件、启动文件、设备头文件。这个仓库是纯开源的做Skill知识库的“原材料”最好不过。开源的嵌入式工程模板项目GitHub上有大量名称包含stm32-cmake-template、cortex-m-baremetal-template的仓库。挑star高、近期更新的直接fork来改成自己的工程底子。嵌入式AI编码教学类仓库目前已经有不少开源的“AI 嵌入式”教学项目里面把Skill的写法和嵌入式场景结合得很好直接看它们怎么组织提示词和知识库能少走很多弯路。国内源方面也有不少省事的选择。GitHub上的大型SDK仓库用开源镜像站拉取速度会快很多Gitee上也有很多热心人搬运的嵌入式模板和示例搜索时记得看许可证别用了别人仓库的代码却没法满足License要求这点我在项目里吃过亏。5.2 自己动手写Skill的三种方式如果你不想纯抄想按自己的习惯定制一套Skill目前主流的做法有三种纯提示词包模式建一个目录里面放一个SKILL.md和几个参考文档AI编程工具加载这个目录自动读取并遵循里面的规则。这种模式最简单、最容易维护适合个人使用我就是从这种起步的。脚本工具调用模式Skill除了知识文档还附带一些工具脚本比如自动解析SVD文件生成寄存器头文件、自动构建并检查编译错误、自动调用OpenOCD烧录。这种Skill的自动化程度更高适合团队统一规范。完整技能包插件模式封装成完整的AI编程插件包含命令行工具、编译检查钩子、代码风格强制校验等。这种适合公司内部推广但对个人来说维护成本偏高。我的建议是个人开发者从模式1开始觉得顺了再往模式2演进。千万不要一上来就搞平台化、插件化容易陷入工程泥潭反而忘了你只是想写单片机代码。5.3 怎么判断一个开源Skill靠不靠谱开源Skill的质量参差不齐我筛选时就盯三个点是否有明确的目标芯片/平台如果一个Skill号称“万能嵌入式”多半是什么都讲不透。好的Skill一定精确到某系列芯片、某个库、某种外设。知识库与硬件手册是否一致挑几个寄存器位定义跟芯片官方参考手册比对一下。假如连RCC时钟使能寄存器位置都不对这份Skill基本不能用。维护活跃度和Issue反馈看看最近提交时间、别人提的问题有没有人回复。嵌入式领域芯片勘误、版本兼容性都是要持续更新的长期不动的Skill有很大过期风险。记住一点开源Skill是“装修图纸”不是“成品房”。里面的知识必须经过你对照官方手册验证后才能真正变成你的东西。6. 踩坑实录与心态调整最后聊几个我在这套工作流里实际踩过的坑以及我自己调整后的心态。这些内容不是AI能教你的全是实打实的经验。6.1 幻觉代码与校验法宝Skill再强大AI依旧会“一本正经地胡编”。我最严重的一次翻车是让Skill生成ADCDMA的中断处理逻辑它编了一个DMA传输完成中断回调但实际上那个芯片根本没把DMA中断映射到那个NVIC通道。烧进去程序一跑就进HardFault。所以我的准则是AI给出的芯片寄存器地址、中断向量表、DMA通道编号三分靠AI七分靠查证。查证工具不是去翻几百页PDF而是靠SVD文件在VSCode的Cortex-Debug里直接看寄存器地址映射或者在工程里用openocd的mdw命令读设备内存跟芯片手册比对一下几秒钟能省下半天Debug时间。AI帮你提高的是写代码和梳理逻辑的速度而“确认硬件事实”这件事永远不能省。6.2 手册知识喂不全怎么办Skill知识库不可能覆盖芯片手册100%的内容。我现在的做法是“聚焦常用场景”只整理高频外设、高频寄存器、高频坑点例如RCC时钟配置、GPIO复用映射、UART波特率误差、Flash写保护等。剩下冷门模块遇到再补每次踩坑都把原因和解决办法追加到Skill的reference/里。时间长了你的Skill就是一个会生长的知识库越用越贴合自己的项目和习惯。这点比任何一个通用AI都强它没有你踩过的坑而你有。6.3 建议的核心工作流我目前形成的工作流可以总结成四步建库每次给Skill添加新知识时都必须标注来源是“芯片手册验证”“官方示例确认”还是“个人实践总结”避免以后误用未经验证的信息。生成用AI和Skill协同产出代码而不是让AI一个人“表演”。把需求拆成功能点是很有用的一次只让AI处理一个外设。审查重点审查寄存器地址、中断向量、时钟起点、内存布局、并发保护这几个硬骨头。可以写一份通用审查清单每次都过一遍。验证编译零警告、烧录、跑正常流程、跑异常分支比如Flash擦写中断打断。验证环节不要怕麻烦这个环节省下的排查时间往往是后面的几十倍。6.4 最后再说一个习惯问题裸机编程中很多问题是“慢变量”导致的例如电源纹波、晶振起振时间、调试器接触不良。Skill和AI在这类问题上帮不上什么忙还是需要你把基础打牢学会看原理图、会用示波器、会查勘误手册。配合开源生态和Skill工具链现在的裸机开发者已经可以做到“不求人”了。这个“不求人”不是不查资料、不翻手册而是你有了自己掌控开发全流程的能力你知道去哪里查、怎么验证、怎么把经验沉淀下来。外人只能看到AI帮你写了代码而真正的核心是你自己掌握的这套方法。我觉得这才是“一条龙”最值钱的部分。 裸机编程如何用开源工具链和AI技能包少走弯路
裸机编程这些年一直被当成嵌入式入门的第一道坎。你会发现一个奇怪的现象明明开源工具链已经成熟到能搞定大部分MCU了网上教程也堆成山了可真正自己从零做一个可用的裸机项目该卡还是卡。我最近一直在折腾一套“开源嵌入式Skill”的玩法把AI技能包、开源工具链、芯片手册知识这三样东西拧成一条龙实测下来确实能让裸机开发少走很多弯路。这篇就从头到尾讲清楚这套玩法适合刚入门想摆脱“只会抄例程”状态的单片机爱好者也适合想用AI改造现有嵌入式工作流的工程师。1. 裸机编程的底牌没有操作系统不等于没有章法想玩转这套“一条龙”得先把裸机这件事看透。很多人把裸机编程理解成“不用操作系统拿寄存器点点灯”这个理解没错但太浅了。裸机编程的本质是你在跟硬件直接对话没有进程调度、没有内存管理、没有文件系统你写下的每一行C代码最后都要精确地落成对寄存器、中断向量、链接脚本的操作。这不是“没有章法”反而是一套极其严密的章法只是这套章法藏在一摞几千页的芯片手册里。1.1 裸机到底是什么裸机编程就是程序直接在硬件上运行不依赖任何操作系统内核。你常见的三种嵌入式开发模式是开发模式有没有OS典型场景上手难度裸机无小家电、传感器节点、电机控制、玩具中等依赖底层知识RTOS有轻量级RTOS通信网关、复杂工控、多任务采集较高涉及任务调度Linux/Android有完整OS路由器、开发板、边缘计算高涉及内核和驱动裸机不是过时而是嵌入式系统的底层逻辑。哪怕你未来要搞RTOS、搞Linux驱动寄存器、中断、时钟树、外设时序这些基本功全是在裸机阶段打下的。而且对绝大多数MCU应用来说裸机反而是最优解省资源、响应快、代码可控、不需要额外维护一个调度器。1.2 难的不是点灯是信息链断裂很多人初始学裸机买一块开发板打开配套例程改两行代码灯亮了很开心。但一旦脱离例程自己动手写一个新的外设初始化立刻翻车。为什么因为裸机开发真正的难点根本不在“把代码写出来”而在于一条完整的信息链路芯片选型 → 阅读数据手册 → 理解时钟树 → 配置外设寄存器 → 写启动文件和链接脚本 → 编译出固件 → 烧录 → 用调试器观测 → 排查异常。这条链路上的每一环都可能断掉。芯片手册几百上千页寄存器位动辄几十个启动文件的栈指针、向量表、初始化段链接脚本的FLASH分配、RAM分配稍微错一点轻则程序跑飞重则烧录完没反应。以前我们只能靠翻手册、搜论坛、看厂商例程一步一步把信息拼起来这是“求人”的根源求厂商示例求论坛老哥求导师师兄。1.3 开源生态给你的“底牌”但到了现在情况已经变了。开源生态把这条链路上的很多“求人点”直接填平了编译器用arm-none-eabi-gcc老牌开源稳定可靠完全免费芯片支持库用CMSISARM官方的硬件抽象层几乎所有Cortex-M芯片都能用厂商寄存器库/HAL库也有开源版本比如STM32Cube系列乐鑫的ESP-IDFNXP的MCUXpresso SDK烧录调试有OpenOCD加 ST-Link/J-Link/DAPLink完全开源工程构建有 Makefile/CMake配合 VSCode 的嵌入式扩展体验不输商业IDE。也就是说以前需要“求人”的编译环境、调试工具、启动代码现在开箱即用。剩下的核心问题只有一个怎么把“芯片手册知识 实际工程经验”高效地用起来。这就是我要说的Skill机制能发挥最大价值的地方。2. Skill机制让AI从“答手”变成“工程师”现在很多嵌入式开发者已经习惯了用AI写代码但大部分人用的是“聊天式”AI问一句答一句让AI写一个驱动它就愣愣地写一个驱动。你兴高采烈地复制到工程里编译报错或者烧进去跑飞。为什么因为聊天式AI没有上下文不知道你的芯片具体型号、不知道你用哪个库、不知道你的工程目录长什么样、更不知道你踩过什么坑。它只是在“答题”不是在“干活”。Skill机制解决的就是这个问题。2.1 普通AI为什么搞不定裸机代码你让AI写一段STM32G4的Flash擦写代码它可能会给你一份适用F1/F4的API调用你让它写DMA配置它会假设你用的HAL库甚至把中断优先级都写混。为什么会这样因为裸机开发对“精确性”的要求是变态级别芯片型号差一个字母外设寄存器地址就变时钟源差一个波特率就翻车编译优化等级不同volatile写错直接出玄学bug。普通AI没有你的工程上下文当然只能靠猜。我自己踩过最典型的坑让AI生成STM32F103的ADC多通道采样代码它给了一份看起来完美无缺的代码结果DMA搬运的缓冲区长度和外设寄存器配置是F3的烧进去采样数据永远是0。你看Chat式AI就是这样它能编出看起来很合理的东西但不在你这个具体芯片、具体工程环境下它就是会“一本正经地胡说八道”。2.2 一个Skill到底长什么样所谓Skill本质上是一个“面向特定领域的AI技能包”它把一个角色设定、一套完整工作流、一组领域知识、一批输出规范打包在一起让AI在触发这个Skill时按照固定的套路处理问题不再漫无边际。我常用的一套嵌入式Skill目录结构大概长这样stm32-baremetal-skill/ ├── SKILL.md ├── reference/ │ ├── stm32g4-flash-notes.md │ ├── clock-tree-checklist.md │ └── register-map-notes.md ├── protocols/ │ └── coding-standards.md └── examples/ ├── flash_read_write.c └── dma_uart_rx.c其中SKILL.md是这个技能包的入口里面定义了AI的角色、任务边界、处理流程和输出格式。我那个SKILL.md核心部分大概是这样的# STM32 Baremetal Engineer Skill 你是专注于ARM Cortex-M裸机开发的资深嵌入式工程师。 ## 你的任务 帮助用户完成基于寄存器级/LL库的裸机驱动开发、调试与代码审查。 ## 工作流程 1. 先确认芯片具体型号和所用外设。 2. 确认时钟源和系统时钟配置。 3. 查阅reference/中的芯片手册摘要必要时补充官方手册。 4. 给出完整可编译的C代码注明关键寄存器含义。 5. 输出检查清单提示用户必须人工核对的部分。 ## 硬性规范 - 默认采用LL库或纯寄存器操作不引入HAL抽象层除非用户明确要求。 - 所有外设寄存器访问必须使用volatile指针。 - 必须提供备份寄存器/Flash操作前的“读-改-写”保护注释。 - 中断服务函数中禁止调用printf等不可重入函数。 ## 已知坑点 - 擦除Flash前必须先关中断否则CPU取指失灵。 - 某型号DMA1和DMA2的时钟使能位在RCC的不同寄存器不可混淆。看到区别了吗当AI带上这个Skill后它不再是“AI”而是一个“懂你这套工程的嵌入式同事”。你提需求它知道要按你的工作流走先确认芯片型号再查你的知识库最后给代码加检查清单。2.3 把芯片手册“装”进Skill信息链就通了Skill另一个杀手级用法是把原本“信息链断裂”的环节接上。我把芯片参考手册中关于Flash控制寄存器、时钟树配置、启动流程的摘要整理成Markdown笔记放到reference/目录下。AI在回答问题时会主动读取这些笔记而不是凭空生成。举个例子我之前整理了一份STM32G474的Flash写入注意事项里面记录着“写Flash时CPU不能从同一块Flash取指必须把关键代码放到RAM执行”这类经验。以前遇到这种问题我得翻几百页手册、搜半天论坛才能想起来现在Skill直接把它注入到AI的上下文里AI生成代码时会自动带上这个约束还会在代码注释里标明原因。这一步非常关键“不求人”的底气来源于知识不再被困在零散的网页和手册里而是沉淀成结构化、可复用的技能包。你用一次这个技能包就真真正正属于你了。3. 开源工具链搭一条真正的裸机开发流水线聊完Skill回到最落地的部分怎么搭一条真正能用、可复现的裸机开发流水线。这里没有玄学全是实操。我以目前最常用的Cortex-M开发场景为例把工具链一条条列清楚。3.1 工具选型为什么我不用商业IDE很多新手一上来就装集成IDE点一下按钮就能编译烧录确实方便。但问题是IDE遮蔽了太多细节而且不便于自动化、不便于多人协作、不便于Skill介入。你想用AI帮你生成代码、然后用命令行自动编译烧录结果IDE把构建过程封装得严严实实你根本插不进手。所以我推荐的是一条命令行优先的全开源链路环节工具说明编译arm-none-eabi-gccARM官方开源GCC工具链构建CMake Make/Ninja管理多目录、多目标烧录OpenOCD开源烧录调试框架调试arm-none-eabi-gdb pyOCD源码级调试编辑VSCode配合C/C插件和CMake插件调试器硬件ST-Link / DAPLink / J-Link二三十块钱的DAPLink足矣这套链路的好处是整个流程都是文本可配置的AI可以完全看懂并参与工程模板放到Git里同事拉下来一条命令就能编译。3.2 搭建一个干净的CMake裸机模板CMake模板设计因人而异但有几个关键点必须守住芯片型号、编译器Flag、链接脚本、启动文件、源码目录。我常用的最小模板大致长这样cmake_minimum_required(VERSION 3.22) project(baremetal_demo C ASM) set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-none-eabi-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/linker/STM32G474RETx_FLASH.ld) add_compile_definitions( STM32G474xx USE_HAL_DRIVER STM32G4 ) add_compile_options( -mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -O2 -Wall -Werror ) add_executable(${PROJECT_NAME} src/main.c src/stm32g4xx_hal_msp.c startup/startup_stm32g474xx.s ) target_link_options(${PROJECT_NAME} PRIVATE -T ${LINKER_SCRIPT} -specsnano.specs -specsnosys.specs )这里有几个细节值得说道说道。第一是-mcpucortex-m4 -mfloat-abihard -mfpufpv4-sp-d16这三个flag必须和芯片硬件严格匹配STM32G474是Cortex-M4F核心带单精度FPU如果搞错浮点指令会直接hardfault。第二是-specsnano.specs它用newlib-nano替代完整的newlib能把固件体积砍掉一大截适合没有外部存储的MCU。第三是启动文件和链接脚本最好从芯片厂商的cube包里拷出来自己手写容易在数值上翻车。CMake本质上是“生成器”它不直接编译而是生成Makefile或Ninja文件。有了这个模板AI就能很轻松地帮你往工程里加新源文件、新头文件路径甚至让它帮你检查CMake配置里芯片型号是否一致。3.3 烧录调试链路OpenOCD那点事编译出来的是.elf和.hex文件下一步是烧录。OpenOCD的配置也是一样一条命令就能搞定openocd -f interface/stlink.cfg -f target/stm32g4x.cfg -c program build/baremetal_demo.elf verify reset exit这条命令的含义是指定使用ST-Link调试器目标芯片是STM32G4系列把编译好的elf文件写入芯片校验复位运行然后退出。如果你是DAPLink把interface/stlink.cfg换成interface/cmsis-dap.cfg就行。调试的话开两个终端# 终端1启动OpenOCD并等待GDB连接 openocd -f interface/stlink.cfg -f target/stm32g4x.cfg # 终端2用GDB连接加载elf并调试 arm-none-eabi-gdb build/baremetal_demo.elf (gdb) target remote localhost:3333 (gdb) load (gdb) continue看断点、看寄存器、看内存、看反汇编这套组合能干完商业IDE能干的绝大部分活。尤其是查HardFault的时候GDB里输入info registers、bt几个命令比在IDE里点来点去高效得多。配合VSCode的Cortex-Debug扩展还能在编辑器里可视化加断点。3.4 在VSCode里把整个流程串起来命令行是底牌但日常开发我还是会回到VSCode。装几个开源插件就能串起整个流水线C/C扩展提供代码补全和跳转CMake Tools负责构建任务Cortex-Debug负责烧录和调试。.vscode/launch.json里我常用这样一个调试配置{ name: OpenOCD Debug, type: cortex-debug, request: launch, servertype: openocd, cwd: ${workspaceFolder}, executable: build/baremetal_demo.elf, device: STM32G474, configFiles: [ interface/stlink.cfg, target/stm32g4x.cfg ], svdFile: STM32G474.svd }特别注意那个svdFile。SVD文件是ARM的“系统视图描述文件”里面存着芯片所有寄存器位定义的映射有了它VSCode的调试窗口里能直接看到每个寄存器的名称和位值而不是一堆十六进制数字。芯片厂商官方一般都会发布SVD文件或者在开源社区能找到。这一步对整个开发体验的提升非常大强烈建议配置上。4. 实战演练用Skill驱动STM32完成片上Flash参数存取工具链和Skill机制都讲清楚了现在来一次完整的实战。这一节我会用自己最近做的STM32G474校准参数存取作为案例完整演示“Skill一条龙”是怎么落地的。4.1 案例目标与原始需求需求听起来很简单把一组传感器的零点校准参数存到片上Flash里掉电不丢失上电自动读取并且支持运行时重新校准和更新。我以前做这类功能流程是打开几百页芯片手册找到Flash章节 → 确认扇区大小、擦写时序 → 写擦除函数 → 写编程函数 → 写读取函数 → 想好怎么兼顾磨损均衡 → 最后还要加一个备份区防止写到一半掉电导致开不了机。每一步都得小心翼翼。这次我换了个思路先建Skill再让AI来干。4.2 喂给Skill的“领域知识”长什么样我做的第一件事不是让AI写代码而是往Skill的reference/里塞知识。这个过程不需要写几千字把关键信息整理清楚就行。比如STM32G4系列Flash操作我记了三类要点擦除粒度一个扇区为单位G4系列不同扇区大小不同擦除前必须检查BSY位必须关全局中断编程粒度一次编程可以写8位、16位、32位或64位但为了保证掉电安全最好以32位对齐写入数据保护校准数据体结构建议带“魔术数校验和备份区”这样能判断数据是否有效并支持从备份区恢复。这些知识一部分来自手册摘要一部分是我从几次“写Flash把板子写挂”的经历里总结的。我顺手把它们整理成Markdown放进reference/stm32g4-flash-notes.md。趁手的工具配合真正有用的经验这套循环才开始发挥威力。然后我在与AI对话中触发这个Skill描述具体需求芯片具体型号、希望的数据结构、需要几个存储槽位、旧数据和新数据的校验逻辑。AI加载Skill后会回调我那几份领域知识笔记再结合我的需求生成代码。4.3 AI生成结果与人工审查重点AI生成的代码骨架我直接贴核心片段简化后的写入流程大概是这样typedef struct { uint32_t magic; uint32_t crc32; uint16_t vref[8]; uint16_t offset[8]; } calib_data_t; static void flash_write_calib(const calib_data_t* data) { __disable_irq(); while (FLASH-SR FLASH_SR_BSY); // 解锁Flash FLASH-KEYR 0x45670123UL; FLASH-KEYR 0xCDEF89ABUL; // 擦除扇区 FLASH-CR | FLASH_CR_PER; FLASH-CR | (FLASH_CR_SNB (CALIB_SECTOR FLASH_CR_SNB_Pos)); FLASH-CR | FLASH_CR_START; while (FLASH-SR FLASH_SR_BSY); // 循环写数据32位对齐 uint32_t* dst (uint32_t*)CALIB_ADDR; const uint32_t* src (const uint32_t*)data; for (int i 0; i sizeof(calib_data_t) / 4; i) { FLASH-CR | FLASH_CR_PG; *dst *src; while (FLASH-SR FLASH_SR_BSY); FLASH-CR ~FLASH_CR_PG; } // 加锁 FLASH-CR | FLASH_CR_LOCK; __enable_irq(); }看起来挺像回事吧但千万不要直接烧录。我人工审查时重点查了几处擦除扇区的编号CALIB_SECTOR确认G474这款芯片这个扇区的起始地址和大小到底是多少代码在擦除期间是否有可能被中断抢占所以AI在开头和结尾做了__disable_irq()/__enable_irq()这个处理是对的写Flash时CPU是否在同一个Flash区取指如果校准区和执行代码在同一个扇区擦除瞬间取指就会出问题——这个在G4上尤其要小心所以我最后把擦写函数放到了RAM执行或者在链接脚本里做了段重定向。AI生成代码只能算完成了50%剩下50%是人工审查和硬件联调。但至少原本要花半天翻手册才能理清的头绪现在十几分钟就能进入深度审查阶段效率提升非常明显。4.4 编译烧录与实测审查完代码走一遍我们前面搭好的流水线cmake -B build -G Ninja . cmake --build build openocd -f interface/stlink.cfg -f target/stm32g4x.cfg -c program build/baremetal_demo.elf verify reset exit编译一次通过烧录后串口打印如下[INFO] Calib data found, magic OK, crc OK. vref[0]2047 offset[0]-12 [INFO] Sensor calibration updated. [INFO] Rebooting to verify reload... [INFO] Calib data found, magic OK, crc OK. vref[0]2047 offset[0]-13第二次读取的offset和第一次差了1是我在测试中途碰了一下传感器导致的这反而证明Flash存取和读取逻辑是正常工作的。整个过程从建Skill到验证通过一共花了一个下午。换两年前光翻手册定位扇区地址、查擦写时序就要半天。5. 站在开源肩膀上这些Skill资产可以直接抄很多人看完上面的流程会问这套Skill是纯自己写的吗有没有现成的可以直接用答案是都有但目前比较分散我按使用场景分个类。5.1 最值得收藏的几类开源仓库先说说“开源知识资产”这块。裸机开发里芯片相关知识和工程模板是复用得最频繁的东西。芯片厂商的官方SDK和示例仓库ST的STM32CubeG4、STM32CubeF1NXP的MCUXpresso SDK乐鑫的ESP-IDF。这些仓库里绝大多数代码是开源的而且是“行为最接近芯片真相”的代码。在做Skill时与其自己写摘要不如直接把官方示例的某个外设驱动丢进reference/里当参考。CMSIS-PackARM官方的CMSIS软件包结构里面包含了SVD文件、启动文件、设备头文件。这个仓库是纯开源的做Skill知识库的“原材料”最好不过。开源的嵌入式工程模板项目GitHub上有大量名称包含stm32-cmake-template、cortex-m-baremetal-template的仓库。挑star高、近期更新的直接fork来改成自己的工程底子。嵌入式AI编码教学类仓库目前已经有不少开源的“AI 嵌入式”教学项目里面把Skill的写法和嵌入式场景结合得很好直接看它们怎么组织提示词和知识库能少走很多弯路。国内源方面也有不少省事的选择。GitHub上的大型SDK仓库用开源镜像站拉取速度会快很多Gitee上也有很多热心人搬运的嵌入式模板和示例搜索时记得看许可证别用了别人仓库的代码却没法满足License要求这点我在项目里吃过亏。5.2 自己动手写Skill的三种方式如果你不想纯抄想按自己的习惯定制一套Skill目前主流的做法有三种纯提示词包模式建一个目录里面放一个SKILL.md和几个参考文档AI编程工具加载这个目录自动读取并遵循里面的规则。这种模式最简单、最容易维护适合个人使用我就是从这种起步的。脚本工具调用模式Skill除了知识文档还附带一些工具脚本比如自动解析SVD文件生成寄存器头文件、自动构建并检查编译错误、自动调用OpenOCD烧录。这种Skill的自动化程度更高适合团队统一规范。完整技能包插件模式封装成完整的AI编程插件包含命令行工具、编译检查钩子、代码风格强制校验等。这种适合公司内部推广但对个人来说维护成本偏高。我的建议是个人开发者从模式1开始觉得顺了再往模式2演进。千万不要一上来就搞平台化、插件化容易陷入工程泥潭反而忘了你只是想写单片机代码。5.3 怎么判断一个开源Skill靠不靠谱开源Skill的质量参差不齐我筛选时就盯三个点是否有明确的目标芯片/平台如果一个Skill号称“万能嵌入式”多半是什么都讲不透。好的Skill一定精确到某系列芯片、某个库、某种外设。知识库与硬件手册是否一致挑几个寄存器位定义跟芯片官方参考手册比对一下。假如连RCC时钟使能寄存器位置都不对这份Skill基本不能用。维护活跃度和Issue反馈看看最近提交时间、别人提的问题有没有人回复。嵌入式领域芯片勘误、版本兼容性都是要持续更新的长期不动的Skill有很大过期风险。记住一点开源Skill是“装修图纸”不是“成品房”。里面的知识必须经过你对照官方手册验证后才能真正变成你的东西。6. 踩坑实录与心态调整最后聊几个我在这套工作流里实际踩过的坑以及我自己调整后的心态。这些内容不是AI能教你的全是实打实的经验。6.1 幻觉代码与校验法宝Skill再强大AI依旧会“一本正经地胡编”。我最严重的一次翻车是让Skill生成ADCDMA的中断处理逻辑它编了一个DMA传输完成中断回调但实际上那个芯片根本没把DMA中断映射到那个NVIC通道。烧进去程序一跑就进HardFault。所以我的准则是AI给出的芯片寄存器地址、中断向量表、DMA通道编号三分靠AI七分靠查证。查证工具不是去翻几百页PDF而是靠SVD文件在VSCode的Cortex-Debug里直接看寄存器地址映射或者在工程里用openocd的mdw命令读设备内存跟芯片手册比对一下几秒钟能省下半天Debug时间。AI帮你提高的是写代码和梳理逻辑的速度而“确认硬件事实”这件事永远不能省。6.2 手册知识喂不全怎么办Skill知识库不可能覆盖芯片手册100%的内容。我现在的做法是“聚焦常用场景”只整理高频外设、高频寄存器、高频坑点例如RCC时钟配置、GPIO复用映射、UART波特率误差、Flash写保护等。剩下冷门模块遇到再补每次踩坑都把原因和解决办法追加到Skill的reference/里。时间长了你的Skill就是一个会生长的知识库越用越贴合自己的项目和习惯。这点比任何一个通用AI都强它没有你踩过的坑而你有。6.3 建议的核心工作流我目前形成的工作流可以总结成四步建库每次给Skill添加新知识时都必须标注来源是“芯片手册验证”“官方示例确认”还是“个人实践总结”避免以后误用未经验证的信息。生成用AI和Skill协同产出代码而不是让AI一个人“表演”。把需求拆成功能点是很有用的一次只让AI处理一个外设。审查重点审查寄存器地址、中断向量、时钟起点、内存布局、并发保护这几个硬骨头。可以写一份通用审查清单每次都过一遍。验证编译零警告、烧录、跑正常流程、跑异常分支比如Flash擦写中断打断。验证环节不要怕麻烦这个环节省下的排查时间往往是后面的几十倍。6.4 最后再说一个习惯问题裸机编程中很多问题是“慢变量”导致的例如电源纹波、晶振起振时间、调试器接触不良。Skill和AI在这类问题上帮不上什么忙还是需要你把基础打牢学会看原理图、会用示波器、会查勘误手册。配合开源生态和Skill工具链现在的裸机开发者已经可以做到“不求人”了。这个“不求人”不是不查资料、不翻手册而是你有了自己掌控开发全流程的能力你知道去哪里查、怎么验证、怎么把经验沉淀下来。外人只能看到AI帮你写了代码而真正的核心是你自己掌握的这套方法。我觉得这才是“一条龙”最值钱的部分。