📚 课程目录第2章硬件寄存器映射

2. 硬件寄存器映射：用结构体指针把外设寄存器变成变量

做嵌入式开发，说白了就是跟寄存器打交道。你写个 GPIO 高低电平，本质是往某个地址写 0 或 1；你配个串口波特率，也是往特定地址写个除数。但问题来了——难道每次都要记一串 0x4001 0C00 这样的地址？

当然不。我刚开始做 STM32 项目时，就见过有人这么写：

*(volatile uint32_t *)0x40010C00 = 0x00000001;  // 拉高 PA0

这代码能跑，但你看一眼就头疼。要是项目里到处都是这种“魔法地址”，后期维护简直是噩梦。所以，我们需要一种优雅的方式——用结构体指针把外设寄存器映射成变量。

2.1 为什么用结构体指针？

你想想看，一个外设通常有多个寄存器。比如 USART，有数据寄存器、状态寄存器、控制寄存器……它们排列在连续地址空间里。C 语言的结构体，天然适合描述这种“连续内存布局”。

我习惯的做法是：

定义一个结构体，成员顺序对应寄存器地址顺序
声明一个指向该结构体的指针，赋值为外设基地址
然后就能用 USART->DR、USART->SR 来读写寄存器了

这样写出来的代码，可读性直接拉满。

  核心思想： 结构体成员的地址 = 结构体基地址 + 成员偏移量。只要成员顺序和寄存器地址顺序一致，指针访问就是安全的。

2.2 实战：定义一个 USART 寄存器结构体

拿最常见的 USART 外设举例。它的寄存器地址映射通常是这样的：

偏移地址	寄存器名称	描述
0x00	SR	状态寄存器
0x04	DR	数据寄存器
0x08	BRR	波特率寄存器
0x0C	CR1	控制寄存器 1
0x10	CR2	控制寄存器 2
0x14	CR3	控制寄存器 3

对应的结构体定义：

typedef struct {
    volatile uint32_t SR;   // 0x00
    volatile uint32_t DR;   // 0x04
    volatile uint32_t BRR;  // 0x08
    volatile uint32_t CR1;  // 0x0C
    volatile uint32_t CR2;  // 0x10
    volatile uint32_t CR3;  // 0x14
} USART_TypeDef;

注意每个成员都加了 volatile 关键字。为什么？因为寄存器值可能被硬件修改，编译器不能优化掉对这些变量的读写。我曾经踩过这个坑——不加 volatile，优化等级一开，寄存器读出来永远是同一个值，排查了半天。

然后定义指针：

#define USART1_BASE  0x40013800
#define USART1       ((USART_TypeDef *)USART1_BASE)

现在，想读状态寄存器？uint32_t status = USART1->SR;。想发数据？USART1->DR = 'A';。清晰明了。

2.3 地址对齐与内存布局陷阱

这里有个关键点：结构体成员的对齐方式必须和硬件寄存器对齐方式一致。大多数 MCU 外设寄存器是 32 位对齐的，结构体默认 4 字节对齐，刚好匹配。但如果你遇到 16 位或 8 位寄存器混排的情况，就得小心了。

举个例子，某个外设的寄存器布局是：

0x00: 32 位控制寄存器
0x04: 16 位数据寄存器
0x06: 16 位状态寄存器

结构体应该这样写：

typedef struct {
    volatile uint32_t CR;   // 0x00
    volatile uint16_t DR;   // 0x04
    volatile uint16_t SR;   // 0x06
} MY_PERIPH_TypeDef;

编译器默认不会在 DR 后面填充字节，因为 SR 是 16 位，地址 0x06 天然对齐。但如果你把顺序写反了，或者中间插了个 8 位变量，就可能出现填充，导致映射错位。

我曾经遇到过： 某国产 MCU 的 TIM 寄存器手册上写的是连续 16 位寄存器，但结构体定义时没注意对齐，结果读出来的计数器值永远不对。后来用 #pragma pack(1) 强制 1 字节对齐才解决。所以，一定要确认硬件手册的寄存器宽度和地址偏移。

2.4 位段操作：用结构体位域访问寄存器位

有时候我们只想操作寄存器的某一位或某几位。比如控制寄存器的 bit 0 是使能位，bit 4-7 是分频系数。传统写法是：

USART1->CR1 |= (1 << 0);       // 使能
USART1->CR1 |= (0x05 << 4);    // 设置分频

可读性还行，但不够直观。C 语言的结构体位域可以做得更漂亮：

typedef struct {
    volatile uint32_t EN      : 1;  // bit 0
    volatile uint32_t RESERVED: 3;  // bit 1-3
    volatile uint32_t DIV     : 4;  // bit 4-7
    volatile uint32_t MODE    : 2;  // bit 8-9
    volatile uint32_t         : 22; // 剩余位
} CR1_Bits;

typedef union {
    volatile uint32_t R;
    volatile CR1_Bits B;
} CR1_Union;

然后这样用：

CR1_Union *cr1 = (CR1_Union *)&USART1->CR1;
cr1->B.EN = 1;
cr1->B.DIV = 5;

嗯，这里要注意：位域的顺序和位分配是编译器相关的。ARMCC、GCC、IAR 的行为可能不一样。我建议只在同一编译器系列内使用，跨平台时还是用宏定义更稳妥。

2.5 映射整个外设地址空间

实际项目中，一个 MCU 有几十个外设。我们通常会做一个头文件，把所有外设的基地址和结构体指针都定义好。比如：

// 外设基地址
#define GPIOA_BASE  0x40010800
#define GPIOB_BASE  0x40010C00
#define USART1_BASE 0x40013800
#define TIM2_BASE   0x40000000

// 外设指针
#define GPIOA   ((GPIO_TypeDef *)GPIOA_BASE)
#define GPIOB   ((GPIO_TypeDef *)GPIOB_BASE)
#define USART1  ((USART_TypeDef *)USART1_BASE)
#define TIM2    ((TIM_TypeDef *)TIM2_BASE)

这样，整个工程的代码都可以用 GPIOA->ODR、TIM2->CNT 来访问硬件，再也不用记地址了。

个人习惯： 我会把外设基地址和结构体定义放在一个独立的 mcu_reg.h 文件里，不掺杂任何业务逻辑。这样换 MCU 时，只需要替换这一个文件，上层驱动代码几乎不用改。

2.6 本章知识结构图

下面这张图总结了寄存器映射的核心流程：

2.7 避坑总结

最后，把我这些年遇到的坑整理一下：

volatile 不能省——没有它，优化后的代码可能根本不读寄存器，直接拿缓存值。
结构体对齐要确认——不同 MCU、不同编译器可能有差异，用 offsetof 宏验证偏移量。
位域顺序不跨编译器——位域是 C 标准里的“灰色地带”，同一套代码换编译器可能出问题。
保留位要占位——结构体里没定义的保留位，编译器可能插入填充，导致后续成员偏移错误。
外设基地址要核对数据手册——不同型号、不同封装，基地址可能不同。别想当然。

掌握了结构体指针映射寄存器，你就拿到了 MCU 驱动开发的“万能钥匙”。后面所有外设驱动，都建立在这个基础之上。