寄存器映射核心原理：使用 core::ptr 读写内存，volatile 操作的必要性

寄存器映射，说白了就是让 Rust 代码能直接操作硬件寄存器。你想想看，嵌入式开发里，控制 GPIO、配置定时器、读写串口数据，本质上都是在操作一块特定的内存地址。这块地址不是普通的 RAM，它背后连着的是硬件外设的逻辑电路。

我刚开始从 C 转 Rust 做嵌入式时，觉得这事挺简单——不就是指针读写嘛。结果第一次调试 SPI 通信，数据死活不对。后来才发现，编译器把我的寄存器读写优化掉了。嗯，这就是我们今天要聊的核心问题：怎么正确地用 Rust 操作硬件寄存器。

硬件寄存器的本质：内存映射 I/O

大多数 MCU 都采用统一编址架构。什么意思呢？就是外设寄存器和普通内存共享同一个地址空间。比如 STM32F4 的 GPIOA 端口输出数据寄存器（ODR）地址是 0x40020014，你往这个地址写数据，GPIOA 的引脚电平就会变化。

这里有个关键点：硬件寄存器的值可能随时变化。不像普通内存，你不写它就不变。寄存器的值可能因为硬件事件、中断、DMA 传输而改变。编译器可不知道这些。

特性	普通内存	硬件寄存器
值变化来源	仅由软件写入	软件写入 + 硬件事件
读操作副作用	无	可能清除状态位
写操作副作用	仅改变存储值	触发硬件动作
编译器优化	可安全合并/重排	必须禁止优化

用 core::ptr 读写寄存器

Rust 标准库里的 core::ptr 模块提供了裸指针操作。我们一般这样定义一个寄存器：

// 定义 GPIOA ODR 寄存器的地址
const GPIOA_ODR: *mut u32 = 0x40020014 as *mut u32;

// 写入数据
unsafe {
    core::ptr::write_volatile(GPIOA_ODR, 0x0000_FFFF);
}

// 读取数据
let value: u32 = unsafe {
    core::ptr::read_volatile(GPIOA_ODR)
};

注意这里用了 write_volatile 和 read_volatile，而不是普通的 write 和 read。为什么？

volatile 到底在干什么？

volatile 告诉编译器：这次内存访问有副作用，不要优化掉，不要重排。

我举个例子。假设你写了一个延时函数：

// 错误的延时实现
fn delay_bad(cycles: u32) {
    for _ in 0..cycles {
        // 空循环
    }
}

// 正确的延时实现
fn delay_good(cycles: u32) {
    for _ in 0..cycles {
        unsafe {
            core::ptr::read_volatile(0xE000_E010 as *const u32); // 读 SysTick 控制寄存器
        }
    }
}

第一个版本，编译器发现循环体啥也没干，直接给你优化成空函数。第二个版本，每次循环都 volatile 读一个地址，编译器不敢动。

寄存器操作也是同理。如果你用普通指针写：

// 危险写法
unsafe {
    *(0x40020014 as *mut u32) = 0x0000_0001; // 可能被优化掉
}

编译器看到连续两次写同一个地址，可能只保留最后一次。但硬件寄存器每次写入都有意义——比如你写两次控制寄存器，第一次启动外设，第二次配置模式。少一次都不行。

volatile 的三种实现方式

在 Rust 里，volatile 操作主要有三种写法：

方式	代码示例	适用场景
core::ptr::read_volatile/write_volatile	read_volatile(addr)	单次读写，最常用
使用 core::ptr::NonNull + volatile 方法	ptr.as_ptr().read_volatile()	需要空指针检查的场景
通过 core::cell::UnsafeCell 包装	cell.get().read_volatile()	需要共享可变访问

我个人习惯用第一种，简单直接。但在封装 HAL 库时，我会用第三种，配合 UnsafeCell 实现内部可变性。

寄存器映射的典型模式

实际项目中，我们不会直接裸写地址。一般会定义结构体来映射寄存器组：

#[repr(C)]
pub struct GpioRegs {
    pub moder: u32,    // 0x00 模式寄存器
    pub otyper: u32,   // 0x04 输出类型
    pub ospeedr: u32,  // 0x08 输出速度
    pub pupdr: u32,    // 0x0C 上拉/下拉
    pub idr: u32,      // 0x10 输入数据
    pub odr: u32,      // 0x14 输出数据
    pub bsrr: u32,     // 0x18 置位/复位
    pub lckr: u32,     // 0x1C 锁定
    pub afrl: u32,     // 0x20 复用功能低
    pub afrh: u32,     // 0x24 复用功能高
}

// 定义基地址
const GPIOA_BASE: usize = 0x4002_0000;

// 获取寄存器组指针
fn gpioa() -> &'static GpioRegs {
    unsafe { &*(GPIOA_BASE as *const GpioRegs) }
}

然后就可以这样用：

fn set_pin_high(pin: u8) {
    let regs = gpioa();
    unsafe {
        core::ptr::write_volatile(®s.bsrr as *const u32 as *mut u32, 1 << pin);
    }
}

我曾经踩过的坑

有一次调试 I2C 通信，从设备总是无响应。我反复检查时序、地址、速率，都没问题。最后用逻辑分析仪一看，发现 SCL 时钟线上少了一个脉冲。

问题出在哪？我写控制寄存器启动传输后，紧接着读状态寄存器判断完成标志。编译器认为这两次读操作之间没有依赖关系，把读状态寄存器的操作提前了。结果我读到的是上一次传输的状态，误以为传输完成，提前发了停止信号。

解决方案就是给状态寄存器读操作加上 volatile，强制编译器按代码顺序执行。

SVG：寄存器映射与 volatile 操作流程

性能调优：减少 volatile 开销

volatile 虽然安全，但每次访问都强制走内存总线，比普通寄存器访问慢。在性能敏感的场景，比如高速 SPI 数据传输，频繁 volatile 读写会成为瓶颈。

我的优化策略：

• 批量操作：能用一次 32 位写完成的，别拆成四次 8 位写
• 缓存友好：连续寄存器访问尽量在同一个 32 位对齐的地址范围内
• 减少冗余读：如果状态寄存器连续读两次，中间没有写操作，可以考虑缓存第一次的值

// 优化前：每次读都 volatile
fn wait_for_flag_bad() {
    loop {
        let status = unsafe { core::ptr::read_volatile(STATUS_ADDR) };
        if status & 0x01 != 0 {
            break;
        }
    }
}

// 优化后：先 volatile 读，后续用普通变量
fn wait_for_flag_good() {
    let status = unsafe { core::ptr::read_volatile(STATUS_ADDR) };
    if status & 0x01 != 0 {
        return;
    }
    // 继续等待...
}

总结一下

寄存器映射的核心就三件事：

1. 地址要准——对照芯片手册，确认每个寄存器的偏移地址
2. 布局要对——用 #[repr(C)] 保证结构体内存布局与硬件一致
3. 访问要 volatile——所有对硬件寄存器的读写都必须用 volatile 操作

嗯，记住这三点，寄存器映射这块基本不会出大问题。下次我们聊更具体的——怎么用 Rust 的类型系统来保证寄存器操作的安全性，让编译器帮我们检查错误。