3. 硬件抽象层(HAL)移植：GPIO、UART、SPI、I2C底层驱动适配

好，咱们进入实战环节的第一个硬骨头——HAL层移植。说白了，就是把蓝牙协议栈和你的硬件板子「撮合」到一起。我见过太多工程师，协议栈选得挺好，结果栽在底层驱动上，板子死活跑不起来。

为什么会这样？因为协议栈是通用的，但你的硬件是独一无二的。GPIO怎么配置、UART用哪个时钟源、SPI的极性对不对——这些细节，协议栈管不了，得你来搞定。

3.1 GPIO适配：从点灯到中断响应

GPIO看似简单，但坑不少。我刚开始做助听器项目时，就因为在GPIO中断触发方式上选错了边沿，导致蓝牙配对按键时灵时不灵，查了两天才找到原因。

助听器里GPIO主要干三件事：

  • 控制复位和使能引脚——比如蓝牙模块的RST、EN
  • 检测外部事件——按键、霍尔开关、充电检测
  • 模拟时序——某些传感器用GPIO模拟I2C或SPI

移植时，你需要实现这几个接口：

// 典型的HAL GPIO接口
void hal_gpio_init(hal_gpio_t pin, hal_gpio_dir_t dir, hal_gpio_pull_t pull);
void hal_gpio_set(hal_gpio_t pin, uint8_t value);
uint8_t hal_gpio_get(hal_gpio_t pin);
void hal_gpio_irq_register(hal_gpio_t pin, hal_gpio_irq_trigger_t trigger, 
                           void (*callback)(void *arg), void *arg);
void hal_gpio_irq_enable(hal_gpio_t pin, bool enable);
注意：助听器对功耗极其敏感。GPIO中断一定要支持边沿触发，别用电平触发——否则会一直唤醒CPU，电池撑不了多久。

我个人习惯把GPIO引脚定义放在一个单独的头文件里，用宏定义好板级映射。这样换板子时，改一个文件就行。

// board_pinmap.h
#define BT_RST_PIN      GPIO_PIN_12
#define BT_EN_PIN       GPIO_PIN_13
#define KEY_PAIR_PIN    GPIO_PIN_7
#define CHARGER_DET_PIN GPIO_PIN_3

3.2 UART适配：蓝牙HCI的命脉

UART是蓝牙HCI传输层最常用的物理接口。嗯，这里要注意——助听器里蓝牙芯片和主控之间，90%的情况走的就是UART。

移植UART驱动，核心是这几个函数：

void hal_uart_init(hal_uart_t uart, uint32_t baudrate, hal_uart_config_t *config);
int32_t hal_uart_send(hal_uart_t uart, const uint8_t *data, uint32_t len, uint32_t timeout);
int32_t hal_uart_receive(hal_uart_t uart, uint8_t *data, uint32_t len, uint32_t timeout);
void hal_uart_irq_rx_callback_register(hal_uart_t uart, void (*callback)(uint8_t data));

我建议你重点关注波特率。蓝牙HCI标准推荐115200或921600。但助听器场景下，我踩过一个坑——有些低功耗蓝牙芯片在921600下会丢包，降回115200就稳了。你想想看，921600理论吞吐量高，但实际受限于MCU的中断响应速度和DMA配置，不一定跑得起来。

经验之谈：UART接收一定要用DMA+环形缓冲区。纯中断接收的话，蓝牙数据包一多，CPU就忙着进中断，其他事都干不了。我在一个项目里试过纯中断方式，结果音频流一开，UART直接溢出。

还有一个细节——流控。HCI UART建议开启硬件流控（RTS/CTS）。助听器里空间紧凑，省掉这两根线虽然省了PCB面积，但传输可靠性会下降。我的建议是：能加就加，不能加就降低波特率。

3.3 SPI适配：音频数据的高速公路

SPI在助听器里主要用来干什么？传输音频数据。比如从蓝牙芯片读PCM流，或者往DAC写音频数据。速率要求高，实时性要求也高。

移植SPI驱动，你需要实现：

void hal_spi_init(hal_spi_t spi, hal_spi_config_t *config);
int32_t hal_spi_transfer(hal_spi_t spi, const uint8_t *tx_data, uint8_t *rx_data, uint32_t len);
void hal_spi_irq_callback_register(hal_spi_t spi, void (*callback)(hal_spi_event_t event));

这里有个关键参数——SPI模式（CPOL和CPHA）。蓝牙芯片和主控的SPI模式必须一致，否则数据全是乱的。我记得有一次调试，波形抓出来都对，但读回来的数据就是不对。折腾了半天，发现是蓝牙芯片默认用模式0，而我配成了模式3。

SPI模式 CPOL（时钟极性） CPHA（时钟相位） 适用场景
模式0 0 0 大多数蓝牙芯片默认
模式1 0 1 某些音频DAC
模式2 1 0 较少见
模式3 1 1 部分传感器
核心要点：SPI传输音频数据时，建议用DMA方式。每次传输的数据块大小要匹配音频帧长度——比如16位立体声、48kHz采样率，一帧就是4字节。DMA缓冲区大小建议设为帧长的整数倍，避免数据错位。

3.4 I2C适配：控制通道的稳定之选

I2C在助听器里通常用来配置编解码器、读取电池电量、控制音量芯片等。速度要求不高，但可靠性要求高——毕竟谁也不想戴着助听器时，音量突然自己乱跳。

移植I2C驱动，核心接口：

void hal_i2c_init(hal_i2c_t i2c, uint32_t frequency);
int32_t hal_i2c_write(hal_i2c_t i2c, uint8_t dev_addr, const uint8_t *data, uint32_t len, uint32_t timeout);
int32_t hal_i2c_read(hal_i2c_t i2c, uint8_t dev_addr, uint8_t *data, uint32_t len, uint32_t timeout);
int32_t hal_i2c_write_read(hal_i2c_t i2c, uint8_t dev_addr, 
                           const uint8_t *w_data, uint32_t w_len,
                           uint8_t *r_data, uint32_t r_len, uint32_t timeout);

我曾经在一个项目里遇到I2C通信间歇性失败的问题。查到最后，发现是上拉电阻阻值选大了——助听器为了省电，I2C总线电压只有1.8V，4.7kΩ上拉根本拉不动。换成2.2kΩ就稳了。

避坑指南：I2C的时钟频率别设太高。助听器里走线长、干扰多，400kHz经常出问题。我一般设100kHz，稳如老狗。还有，别忘了加超时处理——I2C从设备没应答时，主设备不能死等。

3.5 移植实战：从零到通的检查清单

好，理论说完了，咱们来点实际的。移植HAL层时，我建议你按这个顺序来：

  1. 先点亮一个LED——验证GPIO输出正常
  2. 再测UART回环——TX和TX短接，发什么收什么
  3. 然后测SPI回环——MISO和MOSI短接，验证传输无误
  4. 最后测I2C扫描——看看能不能枚举到从设备地址

每一步都确认无误后，再对接协议栈。别一口气全怼上去，出了问题你都不知道是哪个外设在捣乱。

我的习惯：每个外设驱动写完后，都写一个独立的测试用例。比如UART测试，我就写个循环，每隔1秒发一次"Hello HAL"，然后用串口助手看。这样移植到新板子时，跑一遍测试用例就知道驱动有没有问题。

最后说一句——HAL层移植没有捷径。你花在调试底层驱动上的时间，都会在后续的协议栈集成和音频流调试中加倍回报回来。别急，慢慢来。

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