背景与问题界定

在工业物联网边缘控制器的固件开发中，原有的C语言代码库虽然稳定但维护成本极高——驱动、协议栈和应用逻辑全部混合在一个main.c中，任何硬件迭代（如更换传感器型号、升级MCU从Cortex-M4到M7）都意味着大量条件编译和寄存器级代码的重写。我们决定评估Rust作为嵌入式固件开发的替代方案。Rust的no_std生态提供了"零成本抽象"和"静态分发"的承诺，但工程化挑战也很严峻：如何搭建no_std开发环境？如何设计可复用的硬件抽象层（HAL）？如何在中断上下文中安全地共享数据？如何实现可靠的固件OTA更新与错误恢复？

目标拆解与工程约束

  1. no_std下的运行时缺失：标准库提供的分配器、文件系统、线程模型等在no_std环境中完全不可用。core库虽提供了基本类型和迭代器支持，但Vec、String和HashMap等堆分配结构需要手写或引入alloc crate，且必须提供合适的全局分配器（如embedded-alloc）。
  2. 中断上下文的安全约束：Rust的"安全"模型要求中断服务函数（ISR）不能引发panic（panic_handler必须实现），且ISR与主循环之间的数据共享必须避免数据竞争和ABA问题。嵌入式场景的原子操作可能只有单周期指令（如Cortex-M的LDREX/STREX），但Rust的AtomicBool在ARMv6-M（Cortex-M0）上不可用，因为缺少LDREX/STREX支持。
  3. 外设寄存器访问的安全封装：传统嵌入式C代码通过将外设寄存器映射到特定内存地址并直接解引用指针来访问。Rust要求将所有外设寄存器访问封装在safe的API中，通过volatile读写的正确内存序来保证行为可预测。trait Peripheral和svd2rust自动生成的Rust绑定是主流方案，但SVD文件的质量参差不齐。
  4. 固件大小与SRAM限制：MCU的Flash通常只有128-512KB，SRAM 16-64KB。Rust的泛型monomorphization和trait object的vtable可能会导致代码膨胀。需要精细控制linker script和LTO优化来满足固件大小预算。

方案设计

我们采用"分层HAL"架构。最底层是"外设访问层"（PAC），通过svd2rust从芯片厂商的SVD文件自动生成外设寄存器级别的Rust绑定。中间层是"嵌入式HAL"（embedded-hal trait），是一组通用的trait定义（OutputPin、SpiDevice、I2cBus等），让驱动代码可以针对抽象trait而非具体芯片编写。最顶层是"板级支持包"（BSP），将具体的MCU引脚映射到板载硬件的功能名。

// 使用embassy框架构建的异步嵌入式程序
#![no_std]
#![no_main]

use embassy_executor::Spawner;
use embassy_stm32::gpio::{Level, Output, Speed};
use embassy_stm32::time::Hertz;
use embassy_time::Timer;

#[embassy_executor::main]
async fn main(spawner: Spawner) {
    let p = embassy_stm32::init(Default::default());
    
    // 硬件抽象：输出Pin
    let mut led = Output::new(p.PB0, Level::Low, Speed::Low);
    
    // 传感器BMP280驱动，通过I2C抽象
    let i2c = embassy_stm32::i2c::I2c::new(p.I2C1, p.PB8, p.PB9, Hertz(100_000), Default::default());
    let mut bmp280 = bmp280::BMP280::new(i2c, bmp280::Address::Primary);
    bmp280.init().unwrap();
    
    loop {
        let (pressure, temp) = bmp280.measure().unwrap();
        led.toggle();
        Timer::after_secs(1).await;
    }
}

关键设计是使用embassy框架提供的异步运行时——它在no_std环境中实现了async/await，使得多任务协作无需操作系统的线程支持。中断处理通过#[interrupt]宏安全地注册，中断与主循环的共享状态通过critical_section和AtomicUsize实现。

对于SRAM限制，我们使用linker garbage collection（--gc-sections）和cargo bloat分析固件大小热点。对需要动态数据结构的场景使用静态大小可预测的heapless::Vec替代alloc::Vec。

实施路径与关键决策

  • 从STM32L4开发板开始验证：选择STM32L4系列作为初始目标（丰富文档、embassy官方支持完善），验证完整开发流程后移植到量产芯片GD32F303上（M4内核，但SVD文件需要手动修正）。
  • 驱动采用Cargo Workspace管理：每个外设驱动作为独立crate，BSP通过feature flag选择具体MCU型号。所有驱动通过embedded-hal 1.0的trait实现通用性。

验证指标与可持续迭代

最终固件大小：STM32L4目标上Flash占用127KB（含embassy运行时和WiFi协议栈），SRAM占用31KB。OTA升级包（差分压缩后）平均22KB。所有中断响应时间在<500ns范围内，未使用关中断保护。在CI中使用QEMU（cargo run with qemu-system-arm）和硬件的HIL测试双重验证。

工程落地思考

Rust嵌入式开发目前已经走出早期探索阶段，形成了以embassy、embedded-hal和svd2rust为核心的成熟生态。对从C移植过来的团队来说，最大的认知转变是"外设操作也应当遵循类型安全原则"——不再通过写宏定义的寄存器地址来配置外设，而是通过类型安全的builder模式。另一个关键收获是异步编程在no_std环境中的可行性：embassy将中断驱动的事件循环封装为可await的Future，使得复杂协议栈（如MQTT over Wi-Fi）可以用类似std环境async/await的方式编写，而不需要OS提供的线程抽象。