📚 课程目录第1章嵌入式Rust生态全景

1. 嵌入式Rust生态全景：从no_std到HAL，为什么选择Rust做嵌入式？

说实话，我接触嵌入式开发快十五年了。从最早的C语言裸机编程，到后来折腾FreeRTOS，再到前几年一头扎进Rust嵌入式生态——这条路走得不算快，但每一步都踩得挺实。今天咱们就来聊聊，为什么Rust能在嵌入式领域掀起这么大的波澜。

1.1 嵌入式Rust的三层架构

先看一张整体架构图，帮你快速建立认知框架。

这张图我画了很多次。每次给团队新人讲Rust嵌入式，我都会先让他们看这个三层结构。为什么？因为理解了分层，你就理解了Rust嵌入式生态的精髓。

1.2 为什么是no_std？

嵌入式环境跟桌面开发最大的区别是什么？资源受限。很多MCU只有几KB的RAM，几十KB的Flash。标准库里的文件系统、网络套接字、线程管理——这些在裸机上都跑不起来。

所以Rust嵌入式生态的基石是no_std。说白了，就是不带标准库的Rust。它只依赖核心库core，提供最基本的类型、迭代器、引用等机制。没有堆分配器，没有动态内存管理，没有操作系统服务。

核心要点：no_std不是阉割版Rust，而是针对嵌入式场景的精简运行时。它保留了Rust最强大的所有权和类型系统，去掉了你根本用不上的重量级抽象。

我在一个IoT传感器项目里吃过亏。当时用C写固件，一个野指针导致整个采集节点三天后死机。排查了整整一周，最后发现是中断服务函数里不小心修改了全局缓冲区指针。换成Rust no_std之后，同样的逻辑，编译器直接告诉我「这个引用不能跨中断共享」。嗯，有些bug，在编译阶段就被掐死了。

1.3 HAL：硬件抽象层的威力

HAL层是Rust嵌入式生态最亮眼的设计之一。它定义了一套统一的trait接口：

OutputPin —— 推挽输出
InputPin —— 浮空/上拉/下拉输入
I2c、Spi、Uart —— 串行总线
DelayMs、DelayUs —— 延时

每个芯片厂商（ST、NXP、Espressif、Raspberry Pi）都基于embedded-hal这个核心crate，实现自己芯片的HAL。你写应用代码时，只需要依赖这些trait，不用关心底层寄存器怎么配。

我的习惯：写驱动库时，永远只依赖embedded-hal的trait，不直接引用任何芯片级crate。这样换个芯片，驱动代码一行不改。我在三个不同项目里验证过这个做法——STM32F4、ESP32-C3、RP2040，同一个温湿度传感器驱动，直接复制粘贴就能用。

1.4 为什么选择Rust做嵌入式？——五个硬理由

维度	C语言	Rust
内存安全	全靠程序员自觉，UAF/野指针是家常便饭	编译期所有权检查，无GC无运行时开销
并发安全	中断+主循环，数据竞争靠经验规避	Send/Sync trait，编译器保证无数据竞争
零成本抽象	抽象往往带来性能损失（函数指针、虚表）	泛型单态化、trait对象可选，性能与手写C持平
生态工具链	IDE支持参差不齐，交叉编译配置繁琐	cargo + rustup + probe-rs，一行命令烧录调试
可复用性	驱动代码与芯片强耦合，移植成本高	embedded-hal trait解耦，驱动可跨平台

你想想看，C语言在嵌入式领域统治了三十年，凭什么Rust能撬动它？就凭上面这张表里的每一条，都是真金白银的工程成本。

我曾经维护过一个C语言写的电机控制固件，代码量大概两万行。每次加新功能，最怕的就是「改了一个全局变量，不知道哪里会崩」。后来用Rust重写了核心控制逻辑，同样的功能，代码量少了一半，而且编译通过之后，基本没出过运行时崩溃。这不是Rust有多神奇，而是它把很多运行时才能发现的问题，提前到编译期暴露了。

1.5 生态现状：能干活了吗？

这是很多人最关心的问题。我直接说结论：2025年的今天，Rust嵌入式生态已经可以用于量产项目了。

主流芯片的支持情况：

STM32系列：HAL非常成熟，F0/F1/F3/F4/G0/G4/H7全系列覆盖
ESP32系列：esp-hal官方维护，WiFi/BLE驱动完善
RP2040：rp-hal社区活跃，PIO支持到位
nRF52系列：nrf-hal成熟，蓝牙协议栈有Rust绑定
RISC-V芯片：esp32c3/hpm系列支持良好

注意：虽然生态已经可用，但某些小众外设（比如特定型号的以太网MAC、硬件加密引擎）的驱动可能还不完善。选型前建议先查一下crates.io上对应芯片的HAL crate是否支持你需要的功能。

1.6 一个最小示例：点灯

说了这么多理论，咱们看个实际例子。用Rust控制STM32F4开发板上的LED：

// 不依赖标准库，不依赖操作系统
#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _;
use stm32f4xx_hal as hal;

use hal::{
    pac,
    prelude::*,
    gpio::{Output, PushPull},
};

#[entry]
fn main() -> ! {
    // 获取外设实例
    let dp = pac::Peripherals::take().unwrap();
    let gpiod = dp.GPIOD.split();

    // 配置PD12为推挽输出（开发板上的绿色LED）
    let mut led = gpiod.pd12.into_push_pull_output();

    loop {
        led.set_high();
        cortex_m::asm::delay(8_000_000);
        led.set_low();
        cortex_m::asm::delay(8_000_000);
    }
}

这段代码你一看就懂。没有复杂的宏，没有晦涩的寄存器操作。into_push_pull_output()返回的led变量，类型系统保证了它只能被当作输出引脚使用。你想把它当输入读？编译器直接报错。

我在培训新人时经常说：Rust嵌入式编程，其实是在跟编译器「合作」写代码。你告诉编译器你的意图，编译器帮你检查有没有越界、有没有误用、有没有资源冲突。这种体验，用C语言是永远体会不到的。

1.7 小结

嵌入式Rust生态的三层架构——应用层、HAL层、PAC层——每一层都各司其职。no_std让你在资源受限的环境下依然享受Rust的安全保证，HAL trait让你写出跨芯片的可复用代码。

选择Rust做嵌入式，不是因为它时髦，而是因为它实实在在地解决了C语言在嵌入式开发中的痛点：内存安全、并发安全、代码复用、工具链体验。这些不是锦上添花，而是直接降低bug率、缩短开发周期、减少调试痛苦。

我个人觉得，未来五年，Rust在嵌入式领域的份额会快速增长。现在开始学，正是好时机。