https://b0weny-qwq.github.io/Blog/tags/mspm0/Recent content in MSPM0 on BlogHugo -- gohugo.iozh-CNMon, 18 May 2026 00:00:00 +0000https://b0weny-qwq.github.io/Blog/p/toolchain-bringup-stm32f1-mspm0/Mon, 18 May 2026 00:00:00 +0000https://b0weny-qwq.github.io/Blog/p/toolchain-bringup-stm32f1-mspm0/<h1 id="工具链搭建完成">工具链搭建完成 </h1><p>这段时间主要在折腾自己的嵌入式工具链。到 <code>5.18</code> 这一天，基本可以算是阶段性搭建完成了。</p> <p>以前做嵌入式，很多流程其实是被厂商 <code>IDE</code>、图形配置工具和各种零散脚本拖着走。能跑是能跑，但每次换平台、换板子、换环境，都像是在重新和工具链打一架。现在我更想把这些东西统一到一套可复现、可调用、可交给 <code>agent</code> 执行的流程里：构建、烧录、检查、日志、错误定位，都尽量走明确的命令和工程结构。</p> <p>这次最重要的成果，是测试成功了两条 <code>ARM</code> 架构相关的烧录链路。</p> <p>一条是经典的 <code>STM32F1</code>。这基本算是我最熟悉的一类 <code>MCU</code>，也是很多嵌入式开发者绕不开的起点。能把它从传统开发方式里抽出来，用现代一点的工程结构完成构建和烧录，对我来说像是把老朋友重新接进新的工作流。</p> <p>另一条是 <code>TI MSPM0</code>。相比 <code>STM32F1</code>，它更像是一个新的切入点：同样是 <code>ARM</code> 生态，但厂商工具、SDK 组织方式、烧录链路和调试习惯都不完全一样。把 <code>MSPM0</code> 也跑通，说明这套工具链不是只为某一个芯片临时拼出来的，而是有机会扩展成更通用的嵌入式开发底座。</p> <p>从结果看，<code>STM32F1</code> 和 <code>MSPM0</code> 两边都能完成烧录验证，这件事让我很兴奋。工程流开始从“某个项目能跑”变成“某类流程能复用”。只要构建、烧录、调试这些基础动作足够稳定，后面再接入更多芯片、板卡和模板，就不用每次都从一片混乱里重新开始。</p> <h2 id="下一步认识-zephyr">下一步：认识 Zephyr </h2><p>工具链跑通之后，我开始对 <code>Zephyr</code> 这个 <code>RTOS</code> 产生兴趣。</p> <p>以前接触 <code>RTOS</code>，更多是从裸机工程往上加：任务、调度、信号量、队列、驱动抽象，一层一层把东西堆起来。这样学很扎实，但也容易停留在“我会移植一个系统”或者“我会用一套接口”的阶段。</p> <p><code>Zephyr</code> 给我的感觉不太一样。它不像只是一个单纯的内核，更像一整套面向现代嵌入式工程的系统：设备树、配置系统、构建系统、驱动模型、板级支持、跨平台抽象，这些东西组合在一起，才接近我想理解的“工程化嵌入式”。</p> <p>我想认识它，不只是为了会用一个新的 <code>RTOS</code>，而是想看看成熟的嵌入式系统到底怎么组织复杂性。为什么它能支持那么多板子，为什么驱动可以被抽象成统一模型，为什么配置和构建能被系统化管理，这些问题都值得拆开看。</p> <p>工具链搭好只是第一步。烧录跑通代表入口打通了，有意思的事情还在后面：把底层硬件、构建系统、<code>RTOS</code> 思想和 <code>agent</code> 工作流接到一起，形成一套自己能长期维护、长期扩展的嵌入式工程体系。</p> <p>这是我接下来想继续推进的方向。</p>