借助AI实现STM32的OPC UA移植
open62541 是一款知名的开源 OPC UA 协议栈。在 Linux 环境下利用 open62541 搭建 OPC UA 服务端并不算难，然而将其移植到 STM32 等微控制器上，依然是个极具挑战性的任务。
受限的硬件条件。微控制器采用 Arm Cortex-M 核心，其硬件资源远不及 Cortex-A 处理器，核心短板在于内存大小与运算性能。OPC UA 服务端依赖多线程机制，对内存的消耗极为庞大。
轻量化 IP 协议栈（LWIP）。微控制器的网络通讯依赖于精简版的 LWIP 协议栈，能力受限，无法像 Linux 系统那样提供完备的 TCP/IP 协议支撑。
微型 RTOS（FreeRTOS）。基于 CMSIS_OS v2 接口的微型实时系统，仅提供最基础的任务切换与信号量机制，远不如 Linux 的线程体系那般完善。
业界知名的 Matrikon 公司曾提供微控制器端的 OPC UA 协议栈，该企业现已被 Honeywell 兼并。将 open62541 移植并裁剪至 STM32 平台，一直是我渴望完成的夙愿。为此我付出了诸多努力，怎奈自身能力有限，加上配置参数浩繁，最终连编译环节都无法跨过。纵使经过大量的人工修改，代码依然无法运行，屡次尝试均以失败告终。
自 2026 年起，AI Code 技术蓬勃发展。我先行测试了 Web 前后端应用及 Python 编码，成效斐然，于是决定让 AI 涉足嵌入式编程——毕竟，嵌入式软件开发是我深耕数十载、倾注无数心血的看家本领。
第一阶段，我借助小米 MiMo-V2.5 Pro 完成了 ESP32 的语音交互模块开发。
第二阶段，目标转向 STM32。恰巧手边有一块 NUCLEO-H743ZI2 评估板，下载了 STM32CubeMX 与 STM32CubeCLT 等工具链，利用 DeepSeek + Claude Code + VSCode 组合，迅速走通了点亮 LED 灯的编译-烧录-执行全流程。
第三阶段，开始提升挑战难度。回想起那个魂牵梦绕的 open62541 移植计划，决心交由 AI 挑战。我心想：若 AI 能搞定此事，那它完全能够胜任嵌入式程序开发，这必将是嵌入式系统领域的一次变革，将重塑嵌入式工程师的未来。
移植过程主要涵盖以下几个环节。
挑选并下载首个源码包，其中涵盖了各子目录的源码与 Makefile 文件，后续需在此基础之上进行设置与精简。末尾那个包已是裁剪合并后的单文件（.c 与 .h），无法再作精简。
这或许是唯一需由人工处理的任务：使用 STM32CubeMX 设定微控制器的时钟、外设及中间件（LWIP、RTOS）。此环节极为繁琐，尤其是时钟设定，极易出错。一旦此处配置有误，AI 也将回天乏术。设定完毕后点击生成代码，CubeMX 输出一个工程。我选择输出 Makefile 格式，以便后续 AI 采用 Makefile 方式构建。
设定需分两步实施：先设定硬件时钟与以太网，生成工程；随后再进一步设定 LWIP 与 RTOS。若一次性全部配齐，一旦出错 AI 将难以排查。
将下载好的 open62541 压缩包解压至工程目录，接着交由 AI 进行精简，输出单独的 .c 与 .h 两个文件。Claude Code 包揽了开发流程里的大量琐碎事务——切换应用、解析串口日志、研读源码、构建、烧录——这些日常耗费我们大把时间的工作。
起初我采用 MiMo-V2.5 Pro，发觉其表现四平八稳，遇挫时缺乏排错思路，常在原地打转。于是切换至 DeepSeek V4.0，顿觉眼前一亮——响应极为敏捷，点子层出不穷，指令一出便立刻执行。然而失误也多，时常绕圈子，偶尔还会罢工。
我的提议：你可以拿参考项目的完整工具链和工程试一下，看能否编译烧录至你的板子上。或者告诉我是否该放弃。
见其确实无力回天，恰逢智谱的 GLM 5.2 发布，有人提议我不妨一试。于是花费 50 元购入 token，结果截然不同。它率先剖析了 DeepSeek 遗留的工程隐患，与 DeepSeek 截然不同，GLM 5.2 基本无需我介入，全程自主运行，仅偶尔向我确认少许问题。
在排错期间，大模型也会陷入僵局。我会变换思路推它一把，例如：
让我在网络上检索相关的技术文章
你上网检索时可用的关键信息与关键词：
随后它会要求我去搜寻资料供其参考。实则我哪有渠道搜罗如此细碎的内容？只能将这些难题甩给 Google Gemini 4——“当前情况如下……”——接着将 Gemini 4 的答复转发给 Claude Code：“我朋友的建议是……”。看来人类智慧终究更胜一筹：让 Gemini 4 去指挥 Claude Code。似乎 Claude Code 并不擅长自行联网检索信息。
GLM 的花费比 MiMo-V2.5 Pro 及 DeepSeek 高出不少，八小时耗费约 230 元。不过它也颇具分寸，懂得为用户节省开支，遇到大规模改动时会提示我：“此部分工作量巨大，是否继续推进？”
大模型还屡次提醒我：
有一回它再度束手无策，我突然灵光一闪想到 Wireshark 工具，抓取了几帧以太网数据抛给它，引导它从报文交互的维度去剖析。最终顺利化解了难题。
这三大模型给我的观感是：MiMo-v2.5 宛如国企，按部就班，但缺乏主观能动性。DeepSeek 犹如民企，响应迅捷，奇招频出，却易生纰漏。而 GLM 恰似大厂，行事具备规范流程，且兼具智慧与理智。当然，我与它们协作时日尚短，看法恐有偏颇。
终归是大功告成了。GLM 也十分欣喜，第一时间传来捷报：
向它道贺：
首次借助 Claude Code 达成了一项繁复的嵌入式软件开发项目。成功之后我询问 GLM：
这些问题是 lwIP 的原因，还是 FreeRTOS 的原因，亦或是 OPC UA，还是 main 函数的缘故呢？
坦诚而言：这些均非 LwIP / FreeRTOS / open62541 三个库自身的缺陷，而是“集成配置”问题——将这三个库 + STM32 HAL 拼凑在一起时，工程的配置未能契合它们协同运作所需的条件。
GLM 的确非常坦诚。细想之下，我们在嵌入式开发历程中，耗费的大把时光不正是消磨在“集成配置”之上吗？
耗费 230 元，连续奋战八小时；连一个泥瓦小工的日薪都不到；却完成了一项繁杂的嵌入式软件项目；太值了。
相较于纯软件开发，嵌入式编程要求具备软硬件双重技术底蕴与实践经验。开发期间需翻阅海量器件手册，且调试手段受限。整体开发效率低下，嵌入式产品研发的核心瓶颈恰是软件开发。人员流失往往会给企业造成极大困扰。倘若借助 AI Code 来降低嵌入式编程的准入门槛，提升开发效能。这将具有非凡的意义。