收官：新增板卡支持、横向对比与路线图

本篇是《Ariel OS 深度实战：Rust 库式 IoT 操作系统全解析》系列第 30 篇。上一篇：原生目标、基准测试与 Ferrocene，目录见文末。

收官：新增板卡支持、横向对比与路线图

导读

系列最后一篇做三件事。第一，把散落在各篇的"板卡从哪来"拼成完整流程：从填写一份 SBD yaml 到新板跑通 hello-world 的完整步骤（以 adding-board-support.md 为蓝本），并给出三档深入的边界——加板卡、加 MCU、加 HAL 家族各要动哪里。第二，站在整系列的高度横向对比：Ariel OS vs Embassy 直用、RTIC、Tock、Zephyr、RIOT，给出选型决策框架。第三，读一遍 ROADMAP，看看这个年轻的 OS 承诺了什么、还欠什么。

回望整条主线：第 1-8 篇建立构建与观测（laze、烧录、日志），第 9-16 篇吃透执行模型（Embassy 异步、内存、线程、低功耗），第 17-27 篇扫过外设与子系统（I2C/SPI/UART、传感器、随机数、网络三篇、USB、BLE、以太网、存储），第 28-29 篇补齐工程化（测试、native、基准、认证工具链）。30 篇下来，主线板卡 ESP32-C6-DevKitC-1 从"一块 flash 工具能烧录的开发板"变成了一个完整 IoT 节点的全部可能。收官篇不再引入新 API，只做收拢与外推。

为什么值得自己加一块板

Ariel OS 已支持 58 个芯片上下文（ariel-chips.yaml 的芯片列表）与数十块板，但你手里的板大概率不在列表——国产 MCU 的官方板、厂商新发布的评估板、自己的自定义硬件。SBD（结构化板卡描述）架构的意义就在于：板卡支持是数据而非代码——一份 yaml 描述"板上有哪几个 LED、按键、I2C 总线、host-facing UART"，sbd-gen 工具据此生成 ariel-os-boards crate，全部外设 API（第 5 篇以来的 ariel_os_boards::pins::*）随之可用。只要芯片已被支持，加板是小时级工作；这就是为什么本篇敢把流程写成 checklist。

代码案例：新增板卡支持的完整步骤

以下步骤按 adding-board-support.md 组织。前置：fork 仓库（板卡支持要上游化），SBD 目前不能 out-of-tree。

第 0 步：确认芯片已支持

两个检查：HAL 已在 ariel-os-hal 支持列表（当前覆盖 Embassy 支持的 HAL：esp-hal、nrf、rp、stm32，排除 std/wasm）；芯片已有 laze 上下文（laze-project.yml 里 grep 你的芯片型号，如 esp32c6、stm32f401re）。若芯片不支持，跳到后文"三档深入"。

第 1 步：创建 SBD 文件

新建 boards/<your-board-name>.yaml，最好从最相近的现有板复制修改。以 Book 中的 STM32 板示例为模板：

# boards/<your-board-name>.yaml
targets:
  st-nucleo-f401re:
    chip: stm32f401re
    # Generally the board description is supposed to be OS agnostic.
    # In order to be useful, we allow OS specific configuration in subtrees.
    # Ariel OS specific configuration is in the `ariel` subtree.
    # It contains e.g., the choice of SWI interrupt used for the embassy interrupt executor,
    # which is needed to be set on e.g., stm32 MCUs.
    ariel:
      swi: WWDG
    leds:
      # led0
      - pin: PB5
        color: green
        active: high
    buttons:
      # button0
      - pin: PC13
        active: high

逐字段回顾（第 5 篇讲过字段语义，这里强调工程判断）：

  • chip：必须是 ariel-chips.yaml 里已有的 laze 上下文名（含封装/flash 变体）。
  • ariel.swi：仅 STM32 需要——STM32 无专用软件中断，executor-interrupt 要借一个未使用的中断，惯例选 WWDG（窗口看门狗，正常不使能）。这是 OS 专属子树的典型：板卡描述本应 OS 无关，ariel 子树是刻意留出的例外口。
  • leds/buttons：pin/color/active。active: low 表示低电平点亮/按下（nRF 板常见）。ESP32-C6-DevKitC-1 的 SBD 没有声明板上 RGB LED——SBD 只声明"确认可用"的硬件，没把握的不写。
  • i2c：总线的 sda/scl 引脚与 possible_peripherals。Book 给了"什么才算板上有 I2C"的判定标准（原文要点）：板上有 I2C 器件；或总线上有足够强度的上拉电阻（哪怕只接到连接器）；或专用 I2C 连接器（Grove/STEMMA QT/Qwiic/mikroBUS）；或惯例含 I2C 的标准排针（Arduino headers、XIAO pinout）。别名约定：ArduinoI2c、QwiicI2c。
  • uarts：当前只收 host-facing UART（板载 USB-UART 适配器接出的那路，即第 18 篇的 HOST_FACING_UART）。
  • flags：能力标志，如 nRF52840-DK 的 has_usb_device_port、ESP32-C6 板的 has_usb_cdc_acm_port——USB 篇的模块校验就依赖它。

第 2 步：重新生成 ariel-os-boards

cargo install sbd-gen
sbd-gen generate-ariel boards -o src/ariel-os-boards --mode update

生成的 crate 让 ariel_os_boards::pins::LedPeripherals 等类型对新板生效。

第 3 步：登记支持矩阵

编辑 doc/support_matrix.yml：

  • 在 builders 下加一个条目（target 名即 laze builder 名）。
  • 在 boards 下加条目并引用该 builder，附一个描述该板的 web.archive.org 快照链接。
  • 重新生成 Book 的支持页面：
laze build update-book

第 4 步：验证

laze -C examples/hello-world build -b <your-board> run

然后全量编译检查（Book 的 TIP 原文）：只做编译时凭据无需有效：

CONFIG_WIFI_NETWORK='test' CONFIG_WIFI_PASSWORD='password' laze build --global -b <builder>

--global 编译该板全部应用与测试——SBD 声明错误、引脚冲突、能力缺失会在这里集中暴露。最后跑硬件测试（第 28 篇）：laze build -b <board> test 过一遍 tests/ 矩阵中适用的项目。

芯片家族的额外步骤

  • stm32：除 ariel.swi 外，每个 STM32 MCU 需要在 src/ariel-os-stm32/src/rcc.rs 的 default() 里补一条默认时钟配置——这是 STM32 适配层为数不多的"每芯片必填"项。
  • esp32：部分 esp-hal 周边 crate 需要芯片专属 feature，需在 ariel-os-debug 与 ariel-os-esp 中仿照现有条目加一段芯片专属依赖。

三档深入的边界

档一：加板卡（芯片已支持）：只做上述四步，纯数据工作。档二：加 MCU（家族已支持）：在 laze-project.yml 加芯片上下文（parent 指向家族上下文、selects 对应的 cortex-m 级别模块、声明 PROBE_RS_CHIP），Book 的 stm32f401re 示例：

contexts:
  - name: stm32f401re
    parent: stm32
    selects:
      - cortex-m4f
    env:
      PROBE_RS_CHIP: STM32F401RE

再登记 support_matrix.yml 的 chips、把上下文名加入 boards/ariel-chips.yaml，并在相关 crate 里展开 #[cfg(context = ...)] 分支——至少涉及：对应家族的 Ariel OS HAL crate、ariel-os-storage、ariel-os-embassy。档三：加 HAL 家族（Embassy 支持但 Ariel OS 未支持）：ariel-os-hal 加依赖与分发逻辑，再仿照 ariel-os-nrf 写一个家族适配 crate（gpio/i2c/spi/uart/usb/ble/hwrng/identity/storage 的实现）——这是周级工程，也是为社区做贡献的高价值方向。档四（最远）：加处理器架构：每个 rustc target 需要 laze-project.yml 里的专属模块，全新架构则是 another league。

逐段解析

本篇的"逐段"对象不是单一示例，而是两个收官专题：横向对比表与 ROADMAP。先拆前者。

对比表逐维读

以 FAQ.md 的五维对比表为骨架（Rust-based / Async / Preemptive scheduler / Multicore scheduler / Application portability），加入系列 30 篇积累的观察。

维度 Ariel OS Embassy 直用 RTIC Tock Zephyr / RIOT / FreeRTOS
Rust 实现 是 是 是 是 否（C 内核 + Rust 绑定）
异步（async/await 一等公民） 是 是 部分（硬件任务模型） 否 否（C 线程模型为主）
抢占式调度器 是 否（协作式 executor） 否（协作式 + 中断抢占边界） 是 是
多核调度 是（全局 runqueue SMP） 否 否 部分 是
应用跨 MCU 可移植 是（门面 API + SBD） 部分（HAL 初始化各异） 部分 部分（ capsules 模型） 部分（BSP 依赖）

几个系列中反复验证的差异点，收官时给出结论式表述：

vs Embassy 直用：FAQ 的定性是"Ariel OS 心脏是 Embassy"——硬件抽象、async executor、网络、定时器都来自 Embassy（部分是 ariel-os 维护的 fork）。Ariel OS 增加的是：多核抢占调度器（同步/异步混编，第 13-15 篇）、跨 MCU 统一外设 API（各 Embassy HAL 的初始化差异被吸收，第 12/17/18 篇）、预集成子系统（网络/RNG/存储的集中初始化，第 20-27 篇）、模块化系统初始化（应用免写 main 里的 bring-up，第 11 篇）、laze 元构建（--target/runner/链接/feature 矩阵，第 2-3 篇）。一句话：Embassy 是库，Ariel OS 是"把 Embassy 用法固化成系统"的库式 OS——代价是把一些经典 main loop 的控制权交给了系统（FAQ 原文 "Ariel OS moves some of the control of the classical main loop"）。

vs RTIC：RTIC 的硬件任务模型（中断驱动的零开销任务）在中断密集、单核、无 OS 服务的场景极致精悍；但它无抢占线程、无网络/存储等系统服务，跨 MCU 移植靠手写 HAL 初始化。Ariel OS 在"需要 OS 服务的互联设备"场景优势明显，纯中断驱动的小控制器则 RTIC 更轻。

vs Tock：Tock 的核心竞争力是进程隔离与安全架构（kernel capsules + 用户态进程），适合多租户/不可信应用的设备；代价是无 async、多核支持有限。Ariel OS 的信任模型是"单固件镜像"（所有代码同镜像同特权），换来的是零隔离开销与全功能 async。安全需求决定方向。

vs Zephyr/RIOT/FreeRTOS：C 内核 + Rust 绑定的路径继承了生态成熟度（Zephyr 的驱动覆盖无敌），但 Rust 只在边界层，类型安全承诺打折。反向的血缘值得知道：Ariel OS 由 RIOT 维护者在 RIOT-fp 网络安全研究项目中发起，可视为"翻译语义而非字词"的 RIOT 重写（FAQ 原文），与 RIOT 共享代码与社区——理解 RIOT 的网络与安全传统，就理解了 Ariel OS 为什么把 CoAP/OSCORE（第 23 篇）与设备身份（第 26 篇）做得如此前置。

选型决策的粗略树：纯异步单核小工具且要极致精简——Embassy 直用；中断驱动、无阻塞需求——RTIC；不可信应用隔离——Tock；需要庞大驱动生态与 C 遗产——Zephyr；要 Rust 全栈、async+线程混编、互联协议与安全默认值、跨 MCU 可移植——Ariel OS。

ROADMAP 对账：还亮着的灯

ROADMAP.md 的愿景句值得原文级引用的精神：为分布式系统的微控制器节点提供健壮、节能的软件基座；开放源码嵌入式 Rust + 开放标准（IETF）安全低功耗通信。方向清单与本系列各篇的"已知边界"一一对应，收官时做一个"承诺 vs 现状"的对账：

  • 扩展 32 位硬件支持：现状 58 芯片上下文 + 本篇的接入流程；欠的是更多 HAL 家族与新 MCU（Xtensa/ESP 全系、部分 STM32 的 cfg 分支还在补）。
  • 扩展 native 目标：现状 x86_64 GNU/Linux（0.3.0 引入）；Book 明言"Support for other host platforms will be added later"——macOS/Windows 主机、以及更完整的仿真能力在路上。
  • 构建系统与 Cargo 更深度集成：laze 是过渡形态，Cargo 原生表达（build-std、runner、cross 编译的演进）是长期方向；对用户的意义是"有一天也许不再需要 laze"。
  • 现代安全 DevOps 与 OTA 开箱即用：现状 ariel-os-update-transports crate 已存在、存储篇与 CoAP 篇的密钥/身份机制已就位；完整的 OTA 流水线（签名、回滚、差分）未交付——这是 IoT 量产前的最大空白。
  • 更多链路层（BLE、802.15.4、LoRa）与协议（MQTT、DTLS 等）：BLE 已通（TrouBLE，MTU 27 的约束待解）；802.15.4/LoRa 未接入；MQTT 未集成（可经第 22 篇 TCP 自建）；DTLS 因 OSCORE 优先而暂缓——传输层与协议层的覆盖是明确的扩张面。
  • 设备安全上线（commissioning）：第 23 篇的 ACE/EDHOC 是协议基础，端到端的配网/准入流程未封装。
  • CI 增加 HIL 与部分模块的形式化验证：第 28 篇的测试资产是地基，板卡池调度与形式化（尤其调度器、runqueue 这类核心数据结构）是远期投入。

对学习者的建议：Ariel OS 尚在 0.x（0.1.0 到 0.6.0 的 API 变化速度本系列多次领教），生产采用宜锁定版本、关注 CHANGELOG；贡献者视角则是最好的入场时机——第 29 篇 native/基准/HIL 的缺口、本篇的板卡支持流程、ROADMAP 的每一盏灯，都是清晰的贡献入口。 crates.io 上的 0.1.0 已远落后于仓库 dev（本系列基线），读文档认准 ariel-os.github.io 的 dev 版 API。

运行现象

新板支持流程完成后（以 hypothetical 的 STM32F401RE 自制板为例）：

$ laze -C examples/hello-world build -b my-board run
...（构建）
INFO Hello World!

LED 板载灯按 blinky 节奏闪烁，I2C 扫描器扫出板上的传感器，--global 全量编译零失败——一块新板就此获得整个系列的全部能力：日志、线程、网络、存储、测试。这个"一份 yaml 换来全套系统"的瞬间，是对 Ariel OS 设计最好的总结。

横向对比的"运行现象"则是社区观察：FAQ 表格会随版本演进（Tock 的 async、Embassy 的多核都在动），本篇的对比是 2026-10 时点的快照——把对比表当作"需求匹配工具"而非"阵营站队表"，是读完 30 篇应有的工程成熟度。

常见问题

Q1：我改了 SBD yaml 但构建行为没变？

成因：SBD 是数据，ariel-os-boards crate 是生成物——没跑 sbd-gen generate-ariel ... --mode update 就不会生效；另一个可能是改的文件名/target 名与 laze builder 名不匹配（SBD 的 targets.<name> 键就是 builder 名）。解决方案：每次改 yaml 后重新生成（update 模式幂等）；核对 target 名与 laze build -b <name> 的拼写；生成器报错时优先检查 chip 字段是否在 ariel-chips.yaml 列表中。

Q2：新板 hello-world 能跑，blinky/i2c-scanner 报能力缺失？

成因：板卡能力是 SBD 声明驱动的——blinky 要 has_leds（yaml 里没有 leds 条目）、i2c-scanner 要 has_i2c_bus（没有 i2c 条目）。SBD 的哲学是"只声明确认存在的硬件"（C6 板不声明 RGB LED 是同一逻辑）。解决方案：确认板上有对应硬件（LED 真接在 PB5？I2C 满足 Book 的四条判定标准之一？）后补 SBD 条目并重新生成；没有硬件就不选对应示例——这不是缺陷而是"板卡描述 = 能力契约"的设计。

Q3：STM32 新板报 SWI 相关的运行时错误或执行器不跑？

成因：漏了 ariel.swi 字段或选了与实际冲突的中断（WWDG 被应用占用、或该 MCU 的 WWDG 行为特殊）。STM32 无专用软件中断，executor-interrupt 完全依赖这个借用中断。解决方案：SBD 中显式写 ariel: { swi: WWDG }（或另一个确认未使用的中断）；应用代码不要使能该外设；现象上"异步任务全部不跑但线程正常"是 SWI 中断未触发的典型指纹——排查中断配置优先。

Q4：把应用从 Ariel OS 迁回裸 Embassy（或反向）要改什么？

成因：两边的初始化与配置入口不同——Ariel OS 的 #[ariel_os::task]/#[ariel_os::thread]、laze 模块、SBD 引脚 vs Embassy 的 main 手写初始化、Cargo feature、板上硬编码引脚。共享的是 Embassy 原生层：embassy-net socket、embassy-sync、embassy-usb 类、驱动 crate 完全互通（Ariel OS 只是 re-export）。解决方案：迁移方向（Ariel OS → Embassy）要自建 bring-up（时钟、RNG、网络栈、日志通道），代码主体可保留；反向迁移则把 bring-up 交给系统、把引脚声明移入 SBD。这也是选型的隐性成本项：Ariel OS 的门面 API 是双向阀门但不是零成本转换。

Q5：教程以仓库 dev（0.6.0）为基线，升级到未来版本最可能破坏什么？

成因：0.x 阶段的 API 演进规律——本系列记录过的破坏点：0.5.0 的 ariel_os::log 取代 ariel_os::debug::log、logging 传输模块化、GPIO 驱动生命周期泛型；0.6.0 的 alloc 从 Cargo feature 变 laze 模块、interface_eui48 行为变化；模块改名（network-config-*）。可预期的高危面：laze 模块命名（Book 明确警告 module/context 名可能变）、宏参数、依赖 fork 的版本对齐。解决方案：升级前读 CHANGELOG 的 breaking 段；用 laze build --global 做全量编译回归；feature/模块的引用集中管理（应用 laze.yml + 一个地方列出全部 feature）；本系列的 30 篇按 0.6.0 基线写作，升级时以官方 Book 为准修订。

面试考点

考点 1：Ariel OS 的 SBD（结构化板卡描述）体系与 Linux 设备树（devicetree）在目标与机制上的异同？

参考答案：同：都是"板卡硬件的声明式数据描述"，都把硬件知识从代码里分离，都有生成/编译步骤（sbd-gen 生成 crate；dtc 编译 dtb）。异：(1) 范围——devicetree 描述到每个外设寄存器级（地址、中断号、时钟），SBD 只描述 Ariel OS API 需要的抽象层（几颗 LED、哪条 I2C、host-facing UART），芯片级细节由芯片上下文与 HAL 承担；(2) 消费方式——devicetree 是运行时数据（内核启动时解析），SBD 是编译期数据（生成 Rust 类型，引脚是 ZST、无运行时解析开销）；(3) 生态位——devicetree 服务多 OS 共享（同一 dts 可给 Linux/Zephyr），SBD 专属 Ariel OS 但因此能带 OS 专属子树（ariel.swi）。SBD 的设计是"编译期零成本 + API 需求驱动"的嵌入式取向，牺牲了跨 OS 复用。

考点 2：解释 Ariel OS"抢占调度器 + 协作式 executor"双层执行模型的调度责任划分，什么代码放哪一层？

参考答案：两层分工：ariel-os-threads 抢占调度器管线程——固定优先级、可抢占、同优先级协作（需 yield_same）、跨核全局 runqueue；Embassy executor（interrupt 或 thread flavor）管 async 任务——协作式，任务间靠 await 让出。划分原则（本系列各篇的实证）：长计算、阻塞式驱动逻辑、需要硬优先级隔离的代码放线程（如 benchmark 示例、thread-async-interop 的采样线程）；I/O 等待密集、事件驱动的代码放 async 任务（网络 socket、传感器 wait_for_reading）。互通机制：线程内 block_on(future) 下沉到 executor 世界，asynch::spawner() 上浮 spawn 任务；thread_flags 与 embassy-sync 各管各层同步。这个混编能力是 FAQ 对比表中 Ariel OS 独有组合的直接价值。

考点 3：从 FAQ 对比表出发，论证"异步、抢占、多核、可移植"四者同满足的技术难度在哪里？Ariel OS 用什么架构组合达成？

参考答案：难度在张力：抢占与 async 天然冲突（async 要求协作让出，抢占可能在 await 点之间撕开任务，破坏 Future 的状态机假设）；多核与可移植冲突（各 HAL 的核间启动/外设归属差异巨大，ESP32-S3 的外设绑核问题至今使多核被禁）；库式形态与调度器冲突（传统调度器是内核态代码，库式 OS 无特权内核）。Ariel OS 的组合拳：Embassy executor 保持 async 语义纯净（executor 运行在线程里或中断里）；ariel-os-threads 做纯应用态抢占调度器（基于位图 runqueue，无系统调用特权边界）；SMP 用"全局单一 runqueue + 调度器分发 C 个最高优先级就绪线程到 C 核"的简化模型（多核不做 per-core 队列）；可移植靠门面 API + SBD + 芯片上下文把 HAL 差异吸收在适配层。四者同满足的代价：某些 HAL 能力受限（如 ESP32-S3 多核禁用）、执行器 flavor 的优先级机制暂无文档——架构完成度仍在演进。

考点 4：Ariel OS 选择 OSCORE/EDHOC 而非 DTLS、选择设备 ID 派生 MAC 而非出厂烧录、选择 postcard 而非 JSON——三次决策的共同决策模式是什么？

参考答案：共同模式是"开放标准 + 最小设备可用性 + 端到端自洽"三重过滤。(1) OSCORE/EDHOC：IETF Proposed Standard、能缩到 Class-0 设备、跨传输端到端（对比 DTLS 的传输绑定）；(2) 硅片 ID 派生身份：零产线成本、构造唯一、失败报错不给假值（对比烧录方案的成本与随机方案的可追踪性丢失）；(3) postcard：serde 生态兼容、无堆、紧凑（对比 JSON 的体积与堆需求、protobuf 的工具链重量）。三次决策都放弃了"生态最热"的选项（DTLS 的普及度、出厂烧录的确定性、JSON 的可读性），换取"最小 MCU 上零妥协"与"IETF 标准合规"——这呼应 ROADMAP 愿景里的"开放标准安全低功耗通信"。决策模式可迁移：受限系统的技术选型先问 scale-down 极限，再问标准归属，最后才看流行度。

考点 5：如果由你为 Ariel OS 规划下一个大版本的优先级，基于本系列的边界观察，你会把哪三件事排最前？给出理由。

参考答案：参考排序（答案开放，论证质量是评分点）。第一，OTA 与安全上线——ROADMAP 的"OTA 开箱即用"与"commissioning"是 IoT 量产的硬门槛，且地基已备（存储、CoAP 安全、update-transports），边际收益最大；没有它，前 27 篇的所有能力都到不了"可部署"。第二，BLE 与网络栈的能力补全——MTU 27（第 25 篇）与单接口限制（第 21/26 篇）是两个被用户第一周就会撞上的天花板，BLE MTU 交换与多接口（或至少接口切换）的 ROI 高。第三，laze 与 Cargo 的深度融合——Book 自己警告模块名会变、native 篇与 Ferrocene 篇都暴露了构建系统的过渡性；构建层的稳定（或去 laze 化）决定整个生态的采用曲线。反对面的论证也要能展开：多核扩展（ESP32-S3 禁用）虽然显眼，但受制于上游 esp-hal，优先级应低于产品化缺口。

小结

收官三事，各归其位。板卡支持是"数据换代码"的最后一课：SBD 四步流程（写 yaml → sbd-gen → 登记矩阵 → 全量验证）与三档深入边界（板卡/MCU/HAL 家族）给了从用户到贡献者的完整路径。横向对比给了一个诚实的定位：Ariel OS 用"Embassy 之上加系统"的库式路径，在 async、抢占、多核、可移植四个正交维度上同时交卷，换来的代价是控制权的让渡与 0.x 的演进颠簸。ROADMAP 的对账表明：愿景（分布式节点的健壮节能基座、开放标准安全通信）清晰，缺口（OTA、多接口、BLE MTU、构建稳定）明确——这是一个值得现在入局、也值得出力的项目。

30 篇到此封笔。愿你从 hello-world 的那一行 INFO 开始，一路走到自己加的板卡上亮起第一盏灯。Ariel OS 的 crab 已在海里，Rust 的浪潮正当时。

系列目录

  1. 系列总览：Ariel OS 设计理念与生态全景
  2. 环境搭建：Rust 工具链与 laze 构建系统
  3. laze 元构建系统：contexts、modules 与 builders
  4. 第一个应用：从 minimal 到 hello-world
  5. 板卡描述体系：boards yaml 与结构化配置
  6. 烧录与调试：probe-rs、RTT 与日志查看
  7. 日志系统：defmt 与 ariel-os-log
  8. 调试控制台：shell 与交互调试
  9. 异步执行器：Embassy 集成与任务宏
  10. 内存布局与全局分配器
  11. 时钟体系与启动流程
  12. 引脚与 GPIO：静态配置与运行时切换
  13. 多线程（上）：抢占式线程与线程宏
  14. 多线程（下）：Channel、Event 与互斥
  15. 线程与异步互操作：multicore 与定时器
  16. 低功耗与电源管理
  17. I2C 实战：总线扫描与设备通信
  18. SPI 与 UART 实战
  19. 传感器框架：sensor API 与注册表
  20. 随机数与熵源
  21. 网络栈（上）：初始化、Wi-Fi 与 UDP
  22. 网络栈（下）：TCP 客户端与回显服务
  23. 应用协议：HTTP 与 CoAP
  24. USB 实战：串口与 HID 键盘
  25. BLE 实战：广播与扫描
  26. 以太网、设备元数据与身份
  27. 持久化存储
  28. 测试：embedded-test 与硬件在环
  29. 原生目标、基准测试与 Ferrocene
  30. 收官：新增板卡支持、横向对比与路线图
posted @ 2026-10-28 00:46  navysummer_hardware  阅读(9)  评论(0)    收藏  举报