2. 单片机低功耗基础

好，咱们进入第二章。上一章聊了分层架构的宏观思路，这一章咱们把镜头拉近，聚焦在硬件抽象层——也就是 HAL 上。

HAL 是什么？说白了，它就是软件和硬件之间的一道「防火墙」。我个人的理解是：HAL 存在的唯一目的，就是让上层的应用代码不认识底层的寄存器。你想想看，如果哪天 MCU 涨价缺货，你要换另一家芯片，结果发现业务代码里到处都是 GPIOx->ODR、TIMx->ARR……那改起来得多酸爽？

所以，HAL 的核心使命就两个：解耦 和 接口标准化。下面咱们一个一个掰开揉碎了讲。

2.1 解耦：把硬件关进「笼子」里

解耦，就是让软件模块之间、软件和硬件之间的依赖关系降到最低。在 HAL 层面，解耦意味着：上层代码永远不要直接操作寄存器。

我在项目中遇到过这样一个案例：有个同事写 LED 闪烁逻辑，直接在 while 循环里写 GPIOA->BSRR = 0x00010000;。当时看着没问题，后来要换成另一款 MCU，GPIO 寄存器结构完全不同，那部分代码几乎全部重写。这就是典型的耦合过紧。

解耦后的 HAL 应该长什么样？我画了张图，你看一眼就明白了。

看到没？应用层只跟 HAL 接口层打交道。换 MCU 的时候，你只需要重写最下面那层「HAL 实现层」，上面的代码一行都不用动。这就是解耦的价值。

2.2 接口标准化：定好规矩，大家都轻松

接口标准化，就是给所有硬件操作定一套统一的「方言」。不管底层是 STM32、GD32 还是 AT32，上层调用的函数名、参数、返回值都得一样。

我建议，标准化的 HAL 接口应该遵循以下几个原则：

• 命名统一：比如 GPIO 操作，一律用 HAL_GPIO_WritePin()、HAL_GPIO_ReadPin()，不要这家叫 GPIO_SetBits()，那家叫 gpio_set()。
• 参数抽象：用枚举或宏定义代替魔法数字。比如 GPIO_PIN_0 而不是 0x0001。
• 返回值规范：统一返回 HAL_StatusTypeDef，包含 HAL_OK、HAL_ERROR、HAL_BUSY、HAL_TIMEOUT。
• 超时机制：所有可能阻塞的操作，都要有超时参数，防止死等。

举个例子，这是我在一个物联网项目中用过的 GPIO HAL 接口定义：

/* hal_gpio.h - 硬件抽象层 GPIO 接口 */
#ifndef HAL_GPIO_H
#define HAL_GPIO_H

#include "hal_common.h"  /* 包含 HAL_StatusTypeDef 等基础类型 */

/* 引脚号枚举 */
typedef enum {
    HAL_GPIO_PIN_0  = 0,
    HAL_GPIO_PIN_1  = 1,
    /* ... 省略中间引脚 ... */
    HAL_GPIO_PIN_15 = 15,
    HAL_GPIO_PIN_ALL = 16
} HAL_GPIO_Pin_t;

/* 引脚电平枚举 */
typedef enum {
    HAL_GPIO_LOW  = 0,
    HAL_GPIO_HIGH = 1
} HAL_GPIO_Level_t;

/* 引脚模式枚举 */
typedef enum {
    HAL_GPIO_MODE_OUTPUT_PP,    /* 推挽输出 */
    HAL_GPIO_MODE_OUTPUT_OD,    /* 开漏输出 */
    HAL_GPIO_MODE_INPUT_FLOAT,  /* 浮空输入 */
    HAL_GPIO_MODE_INPUT_PU,     /* 上拉输入 */
    HAL_GPIO_MODE_INPUT_PD,     /* 下拉输入 */
    HAL_GPIO_MODE_AF_PP,        /* 复用推挽 */
    HAL_GPIO_MODE_AF_OD         /* 复用开漏 */
} HAL_GPIO_Mode_t;

/* 初始化结构体 */
typedef struct {
    HAL_GPIO_Pin_t   Pin;
    HAL_GPIO_Mode_t  Mode;
    uint8_t          Speed;      /* 0:low, 1:medium, 2:high, 3:very high */
} HAL_GPIO_Init_t;

/* ========== 标准化接口函数 ========== */

/* 初始化 GPIO */
HAL_StatusTypeDef HAL_GPIO_Init(HAL_GPIO_Init_t *pInit);

/* 写引脚电平 */
void HAL_GPIO_WritePin(HAL_GPIO_Pin_t Pin, HAL_GPIO_Level_t Level);

/* 读引脚电平 */
HAL_GPIO_Level_t HAL_GPIO_ReadPin(HAL_GPIO_Pin_t Pin);

/* 翻转引脚电平 */
void HAL_GPIO_TogglePin(HAL_GPIO_Pin_t Pin);

/* 批量写端口 */
void HAL_GPIO_WritePort(uint16_t PortValue);

/* 批量读端口 */
uint16_t HAL_GPIO_ReadPort(void);

#endif /* HAL_GPIO_H */

2.3 接口设计的具体策略

光有原则还不够，落地的时候有几个坑你得提前知道。我总结了三条核心策略：

2.3.1 分层初始化 vs 一键初始化

有些 HAL 库喜欢搞一个大而全的初始化函数，把所有外设配置塞进去。比如：

/* 不推荐：耦合太紧 */
void HAL_InitAll(void) {
    HAL_GPIO_Init(&led_gpio_config);
    HAL_UART_Init(&uart1_config);
    HAL_TIM_Init(&timer2_config);
    HAL_SPI_Init(&spi1_config);
    /* ... 几十行 ... */
}

我建议反过来：每个外设独立初始化，由上层按需调用。这样你调试某个外设时，不会影响到其他模块。而且低功耗模式下，你可以只初始化必要的外设，省电。

2.3.2 回调机制：别让 HAL 把事件「吞」了

硬件事件（比如 UART 收到数据、定时器溢出）怎么通知上层？我见过最糟糕的做法是在 HAL 里直接调用应用层的处理函数——这等于把耦合又请回来了。

正确的做法是：HAL 只负责注册回调函数指针，由上层在初始化时传入。

/* hal_uart.h */
typedef void (*HAL_UART_RxCallback_t)(uint8_t data);

void HAL_UART_RegisterRxCallback(HAL_UART_RxCallback_t callback);

/* 在 HAL 实现中，中断服务程序里调用回调 */
void UART_IRQHandler(void) {
    uint8_t data = UART->DR;
    if (rx_callback) {
        rx_callback(data);  /* 只调用函数指针，不关心具体实现 */
    }
}

2.3.3 错误处理：别让 HAL 静默失败

硬件操作总会出错——I2C 从机没应答、SPI 通信超时、Flash 写入失败……HAL 必须把这些错误「吐」出来。

我建议的规范是：

上层代码拿到这些返回值，才能做出合理的决策。如果 HAL 把所有错误都吞掉，上层就像瞎子开车——迟早要出事。

2.4 移植适配：换 MCU 到底要改多少代码？

这是大家最关心的问题。我直接给答案：如果 HAL 设计得好，换 MCU 只需要改 HAL 实现层的文件。

具体来说，需要改的文件包括：

• hal_gpio.c — GPIO 寄存器操作
• hal_uart.c — UART 寄存器操作
• hal_timer.c — 定时器寄存器操作
• hal_spi.c — SPI 寄存器操作
• hal_i2c.c — I2C 寄存器操作
• hal_common.c — 系统时钟、中断优先级等基础配置

不需要改的文件：

• 所有 .h 头文件（接口定义不变）
• 所有应用层代码（业务逻辑不变）
• 中间件层代码（协议栈、文件系统等）

2.5 本章小结

HAL 设计说白了就两件事：把硬件关进笼子（解耦），给笼子装一把标准锁（接口标准化）。做到这两点，你的代码就有了「跨平台基因」。以后换 MCU、升级芯片，都只是体力活，而不是重构工程。