结构体与联合体在嵌入式系统中的应用

嵌入式系统开发，说白了就是跟硬件打交道。你写的每一行代码，最终都要映射到某个寄存器、某段内存、某个引脚上。而结构体和联合体，恰恰是C语言里最贴近硬件的两个工具。

我个人习惯把结构体和联合体称为「嵌入式开发的左膀右臂」。为什么这么说？因为它们能帮你把硬件手册上的那些表格、地址、位域，直接翻译成C代码。今天我就结合自己踩过的坑，聊聊这三个经典场景：硬件寄存器映射、中断向量表、通信协议栈。

一、硬件寄存器映射：把手册翻译成代码

做嵌入式的人，谁没翻过几百页的芯片手册？手册里全是寄存器地址、位定义、读写属性。你想想看，如果每个寄存器都用 *(volatile uint32_t *)0x40020000 这种写法，代码能看吗？

结构体就是用来解决这个问题的。我们可以把一组连续的寄存器，定义成一个结构体。每个成员对应一个寄存器，成员的顺序和地址必须跟手册完全一致。

// 以STM32的GPIO为例
typedef struct {
    volatile uint32_t MODER;    // 0x00 模式寄存器
    volatile uint32_t OTYPER;   // 0x04 输出类型寄存器
    volatile uint32_t OSPEEDR;  // 0x08 输出速度寄存器
    volatile uint32_t PUPDR;    // 0x0C 上下拉寄存器
    volatile uint32_t IDR;      // 0x10 输入数据寄存器
    volatile uint32_t ODR;      // 0x14 输出数据寄存器
    volatile uint32_t BSRR;     // 0x18 位设置/清除寄存器
    volatile uint32_t LCKR;     // 0x1C 锁定寄存器
    volatile uint32_t AFR[2];   // 0x20-0x28 复用功能寄存器
} GPIO_TypeDef;

// 然后直接映射到基地址
#define GPIOA ((GPIO_TypeDef *)0x40020000)
#define GPIOB ((GPIO_TypeDef *)0x40020400)

// 使用起来就非常直观
GPIOA->MODER = 0x55555555;  // 设置PA0-PA15为输出模式
GPIOA->BSRR = 0x00010000;   // 复位PA0

这里有个关键点：volatile 关键字绝对不能少。我在项目中遇到过，有人忘了加 volatile，结果编译器优化后，读寄存器永远返回同一个值。排查了整整两天，最后发现是优化搞的鬼。

注意：结构体成员的对齐问题。如果寄存器之间有空洞（比如地址不连续），必须用保留成员填充。否则结构体成员的偏移量会跟硬件地址对不上，后果就是写错寄存器。

二、联合体在寄存器位操作中的妙用

有时候，我们需要同时操作一个寄存器的多个位域。比如一个32位的控制寄存器，高4位是模式选择，中间8位是分频系数，低4位是使能位。用结构体位域可以做到，但不同编译器的位域顺序可能不同，移植性差。

我更喜欢用联合体+结构体的组合方式：

typedef union {
    volatile uint32_t value;  // 整体访问
    struct {
        volatile uint32_t enable : 4;    // 位0-3
        volatile uint32_t divider : 8;   // 位4-11
        volatile uint32_t mode : 4;      // 位12-15
        volatile uint32_t reserved : 16; // 位16-31
    } bits;
} CONTROL_Reg;

#define CONTROL ((CONTROL_Reg *)0x40010000)

// 使用示例
CONTROL->bits.enable = 0x0F;   // 只修改使能位
CONTROL->bits.mode = 0x03;     // 只修改模式位
// 或者整体赋值
CONTROL->value = 0x0000F0FF;

这种写法，既保留了位操作的灵活性，又保留了整体赋值的效率。我曾经在一个电机驱动项目里，用这种方式实现了PWM参数的动态调整，代码可读性提升了一大截。

三、中断向量表：结构体数组的经典应用

中断向量表，说白了就是一个函数指针数组。每个中断源对应一个入口地址。在ARM Cortex-M系列中，向量表的前几个条目是固定的：栈指针、复位向量、NMI、硬错误……

用结构体来定义向量表，非常自然：

typedef void (*ISR_Func)(void);

typedef struct {
    void *stack_ptr;          // 0x00 栈指针
    ISR_Func reset_handler;   // 0x04 复位向量
    ISR_Func nmi_handler;     // 0x08 NMI
    ISR_Func hard_fault;      // 0x0C 硬错误
    // ... 其他异常向量
    ISR_Func irq[240];        // 外部中断向量
} VectorTable;

// 在链接脚本中指定向量表地址
// 然后在C代码中声明
extern const VectorTable __Vectors;

// 使用
void HardFault_Handler(void) {
    // 硬错误处理
    while(1);
}

// 向量表定义（通常放在汇编启动文件中）
const VectorTable __Vectors = {
    .stack_ptr = &_estack,
    .reset_handler = Reset_Handler,
    .nmi_handler = NMI_Handler,
    .hard_fault = HardFault_Handler,
    // ...
};

嗯，这里要注意：向量表的地址必须对齐到256字节或512字节（取决于芯片）。我见过有人把向量表定义在普通全局变量区，结果地址没对齐，芯片一上电就跑飞了。

四、通信协议栈：结构体与联合体的完美配合

通信协议栈是结构体和联合体大显身手的另一个领域。不管是I2C、SPI、UART，还是CAN、Ethernet，底层都是字节流。但上层需要解析出各种字段。

以CAN报文为例，标准CAN帧有ID、DLC、数据等字段。我们可以这样定义：

typedef struct {
    uint32_t id : 11;      // 标准ID
    uint32_t rtr : 1;      // 远程帧标志
    uint32_t ide : 1;      // 扩展帧标志
    uint32_t reserved : 19; // 保留
} CAN_ID_Field;

typedef union {
    uint32_t raw;           // 原始ID值
    CAN_ID_Field bits;      // 位域解析
} CAN_ID;

typedef struct {
    CAN_ID id;              // 报文ID
    uint8_t dlc : 4;        // 数据长度
    uint8_t rtr : 1;        // 远程帧
    uint8_t ide : 1;        // 扩展帧
    uint8_t reserved : 2;   // 保留
    uint8_t data[8];        // 数据段
} CAN_Frame;

// 解析接收到的CAN报文
void CAN_Receive(CAN_Frame *frame) {
    // 从硬件读取原始数据
    frame->id.raw = CAN->RX_ID;
    frame->dlc = CAN->RX_DLC;
    for(int i = 0; i < frame->dlc; i++) {
        frame->data[i] = CAN->RX_DATA[i];
    }
    
    // 判断是否为远程帧
    if(frame->id.bits.rtr) {
        // 处理远程帧请求
    }
}

这种写法，把协议解析和硬件访问解耦了。我在一个车载项目里，用这种方式处理CAN报文，代码量减少了30%，而且调试起来特别方便——直接打印 frame->id.raw 就能看到原始ID值。

五、避坑指南与经验总结

核心原则：结构体用于描述「一组相关的数据」，联合体用于描述「同一数据的多种解释」。在嵌入式系统中，它们就是硬件和软件之间的翻译官。

我总结了几条实战经验，供你参考：

  • 对齐问题：结构体成员的对齐方式，不同编译器可能不同。建议用 __attribute__((packed)) 强制1字节对齐，或者手动填充保留字节。
  • volatile不能省：所有映射到硬件寄存器的结构体成员，都必须加 volatile。否则编译器优化后，可能只读一次寄存器，后面全用缓存值。
  • 位域顺序：位域从低位开始还是高位开始，取决于编译器。跨平台时，建议用宏定义或联合体来屏蔽差异。
  • 大小端问题：通信协议中，多字节字段的大小端必须跟硬件一致。我曾在I2C驱动中，因为大小端搞反了，读出来的传感器数据全是乱的。
小技巧：调试寄存器映射时，可以定义一个全局结构体指针，然后在调试器里直接展开查看每个成员的值。比看原始地址方便多了。

六、知识体系总览

下面这张图，概括了结构体与联合体在嵌入式系统中的三个核心应用场景，以及它们之间的关系：

结构体与联合体在嵌入式系统中的应用 硬件寄存器映射 结构体映射寄存器组 联合体位域操作 volatile关键字 地址对齐与填充 中断向量表 函数指针数组 结构体定义向量表 地址对齐要求 链接脚本配合 通信协议栈 CAN/I2C/SPI协议 联合体解析字节流 大小端处理 协议字段位域定义 核心思想 结构体 → 描述一组相关的硬件资源 联合体 → 同一数据的多种解释方式 两者结合 → 硬件与软件之间的翻译官 嵌入式系统开发 · 结构体与联合体精讲

这张图展示了三个应用场景的并列关系。它们都依赖于结构体和联合体的核心能力：内存布局控制和数据解释。你想想看，没有这两个工具，我们只能靠手动计算地址、手动移位掩码，那代码得多痛苦？

好了，关于结构体和联合体在嵌入式系统中的应用，我就分享到这里。这些经验都是我在实际项目中一点一点积累出来的。希望你能少走一些弯路，写出更优雅、更可靠的嵌入式代码。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →