4、GPIO驱动层封装：从寄存器到函数、输入输出模式封装、中断回调机制设计

GPIO 驱动，是嵌入式软件分层里最基础、也最容易被轻视的一层。

很多人写 GPIO 代码，就是直接往寄存器里填数。今天拉高，明天拉低，项目一复杂，代码就乱成一锅粥。我早期做项目时也这样，直到有一次产品量产前发现某个引脚电平反了，改一处寄存器要牵连十几个文件……那滋味，真不好受。

所以这一章，我们就把 GPIO 驱动层好好封装一下。从寄存器操作开始，一步步抽象成函数，再封装输入输出模式，最后加上中断回调机制。这套思路，说白了就是让底层硬件“听话”，让上层应用“省心”。

4.1 从寄存器到函数：告别魔法数字

STM32 的 GPIO 寄存器，大家都不陌生。控制一个引脚，通常要操作几个寄存器：

直接操作这些寄存器，代码长这样：

// 直接操作寄存器——不推荐
#define LED_PIN     (1U << 5)   // PA5
GPIOA->MODER &= ~(0x3U << (5 * 2));
GPIOA->MODER |=  (0x1U << (5 * 2));  // 输出模式
GPIOA->OTYPER &= ~LED_PIN;            // 推挽
GPIOA->OSPEEDR |= (0x2U << (5 * 2)); // 高速
GPIOA->PUPDR   &= ~(0x3U << (5 * 2));// 无上下拉
GPIOA->BSRR = LED_PIN;                // 输出高电平

这段代码能跑，但问题很明显：

• 可读性差：0x3U、0x1U 这些魔法数字，过两周自己都看不懂。
• 复用性差：换个引脚，所有位运算都要重算。
• 维护成本高：项目里几十个 GPIO，每个都这么写，改一处漏三处。

我的做法是：先定义一套清晰的数据结构，把引脚信息抽象出来。

// GPIO 引脚配置结构体
typedef struct {
    GPIO_TypeDef   *port;      // GPIO 端口基地址
    uint16_t        pin;       // 引脚号 (0~15)
    uint8_t         mode;      // 模式
    uint8_t         otype;     // 输出类型
    uint8_t         speed;     // 速度
    uint8_t         pull;      // 上下拉
    uint8_t         alt_func;  // 复用功能号
} gpio_pin_cfg_t;

然后封装几个基础操作函数：

// 初始化 GPIO
void gpio_init(const gpio_pin_cfg_t *cfg);

// 写引脚电平
void gpio_write_pin(GPIO_TypeDef *port, uint16_t pin, uint8_t level);

// 读引脚电平
uint8_t gpio_read_pin(GPIO_TypeDef *port, uint16_t pin);

// 翻转引脚电平
void gpio_toggle_pin(GPIO_TypeDef *port, uint16_t pin);

这样上层代码就变成了：

gpio_pin_cfg_t led_cfg = {
    .port  = GPIOA,
    .pin   = 5,
    .mode  = GPIO_MODE_OUTPUT,
    .otype = GPIO_OTYPE_PP,
    .speed = GPIO_SPEED_HIGH,
    .pull  = GPIO_PULL_NONE
};
gpio_init(&led_cfg);
gpio_write_pin(GPIOA, 5, 1);  // 点亮 LED

嗯，这才像样。寄存器操作被隐藏了，上层只关心“哪个引脚、做什么事”。

4.2 输入输出模式封装：不只是拉高拉低

GPIO 的模式远不止“输入”和“输出”两种。STM32 的每个引脚，都有 4 种基本模式：

输出模式里，还有推挽和开漏之分。输入模式里，上下拉配置也很关键。

我在封装时，会把模式、类型、速度、上下拉打包成一个“配置组”，一次性写入。这样既减少寄存器访问次数，也避免中间状态导致引脚电平抖动。

// 批量配置 GPIO 模式相关寄存器
static void gpio_set_mode_reg(GPIO_TypeDef *port, uint16_t pin,
                               uint8_t mode, uint8_t otype,
                               uint8_t speed, uint8_t pull)
{
    uint32_t pin_pos = pin;
    uint32_t reg_val;

    // MODER
    reg_val = port->MODER;
    reg_val &= ~(0x3U << (pin_pos * 2));
    reg_val |=  ((uint32_t)mode << (pin_pos * 2));
    port->MODER = reg_val;

    // OTYPER
    if (otype == GPIO_OTYPE_OD) {
        port->OTYPER |= (1U << pin_pos);
    } else {
        port->OTYPER &= ~(1U << pin_pos);
    }

    // OSPEEDR
    reg_val = port->OSPEEDR;
    reg_val &= ~(0x3U << (pin_pos * 2));
    reg_val |=  ((uint32_t)speed << (pin_pos * 2));
    port->OSPEEDR = reg_val;

    // PUPDR
    reg_val = port->PUPDR;
    reg_val &= ~(0x3U << (pin_pos * 2));
    reg_val |=  ((uint32_t)pull << (pin_pos * 2));
    port->PUPDR = reg_val;
}

你可能会问：为什么不直接用 HAL 库？

HAL 库当然能用，但它的 GPIO 初始化函数一次只能配一个寄存器，而且参数传递路径长。在裸机环境下，我更倾向于这种“一次配完”的方式——快，而且可控。

4.3 中断回调机制设计：让 GPIO 学会“主动汇报”

轮询读引脚，是低效的。尤其当系统里同时有按键、编码器、唤醒信号时，CPU 大部分时间都在空转。

中断才是正道。但裸机下的中断处理，很容易写成“大杂烩”——所有中断逻辑都塞在 IRQHandler 里，维护起来想哭。

我的方案是：设计一套轻量级的中断回调机制。

核心思路就两点：

• 注册回调函数：每个外部中断线，可以挂一个用户回调。
• 统一中断入口：所有 GPIO 中断都走同一个 IRQHandler，由驱动层分发。

先定义回调函数类型：

// 中断回调函数类型
typedef void (*gpio_irq_callback_t)(void *arg);

再设计注册和分发结构：

// 中断回调注册表
typedef struct {
    gpio_irq_callback_t callback;
    void               *arg;
} gpio_irq_entry_t;

// 每个 EXTI 线一个条目（STM32 支持 16 条外部中断线）
static gpio_irq_entry_t s_irq_table[16];

// 注册回调
void gpio_irq_register(uint8_t exti_line,
                       gpio_irq_callback_t callback,
                       void *arg)
{
    if (exti_line < 16) {
        s_irq_table[exti_line].callback = callback;
        s_irq_table[exti_line].arg      = arg;
    }
}

// 统一中断处理函数（在 IRQHandler 中调用）
void gpio_irq_handler(uint8_t exti_line)
{
    if (EXTI->PR & (1U << exti_line)) {
        // 清除挂起位
        EXTI->PR = (1U << exti_line);

        // 调用用户回调
        gpio_irq_entry_t *entry = &s_irq_table[exti_line];
        if (entry->callback) {
            entry->callback(entry->arg);
        }
    }
}

用户代码就清爽了：

// 按键中断回调
void button_pressed_callback(void *arg)
{
    // 处理按键事件
    uint32_t timestamp = (uint32_t)arg;
    // ...
}

// 初始化
void app_init(void)
{
    // 配置 PA0 为外部中断，下降沿触发
    gpio_pin_cfg_t btn_cfg = {
        .port  = GPIOA,
        .pin   = 0,
        .mode  = GPIO_MODE_INPUT,
        .pull  = GPIO_PULL_UP
    };
    gpio_init(&btn_cfg);
    gpio_exti_config(GPIOA, 0, EXTI_TRIGGER_FALLING);

    // 注册回调
    gpio_irq_register(0, button_pressed_callback, (void *)get_tick());
}

这样，中断处理逻辑和硬件配置完全解耦。你想换引脚？改配置就行，回调函数不用动。

4.4 整体架构：一张图看懂 GPIO 驱动层

下面这张图，展示了 GPIO 驱动层的完整分层结构：

从下往上看，每一层只依赖它的下一层。应用层永远不知道寄存器长什么样，它只调用 gpio_write_pin 和 gpio_irq_register。

这就是分层的好处——改底层硬件，不影响上层逻辑；换上层业务，不用动驱动代码。

4.5 避坑指南：GPIO 封装中的常见问题

最后，分享几个我在实际项目中遇到的坑：

• 引脚复用冲突：同一个引脚被两个模块同时配置。解决办法是在 gpio_init 里加一个“占用检查”，记录已配置的引脚。
• 中断优先级配置：NVIC 的优先级分组要统一。我见过一个项目里，有的中断用抢占优先级，有的用子优先级，结果中断嵌套乱套了。
• EXTI 线共享：多个引脚不能同时映射到同一条 EXTI 线。比如 PA0 和 PB0 不能同时做外部中断。这个在硬件设计阶段就要规避。
• BSRR 的误用：BSRR 的低 16 位置位，高 16 位复位。如果同时写 1 到高低位，结果是复位优先。我早期没注意这个细节，调试了整整一下午。

GPIO 驱动层封装，看似简单，但做好了对整个项目的健壮性影响很大。把寄存器藏起来，把模式标准化，把中断回调化——这三步走完，你的嵌入式软件就有了一个扎实的底层基础。