4、驱动层DFT实战（一）：硬件抽象层（HAL）设计模式与单元测试桩（Stub）的构建

驱动层是嵌入式系统里离硬件最近的一层，也是最容易出问题的地方。很多团队做测试，到了驱动层就卡住了——硬件还没回来，或者硬件环境太复杂，没法跑测试。其实，这个问题可以通过硬件抽象层（HAL）的设计来解决。

说白了，HAL就是在驱动代码和硬件寄存器之间加一层“翻译官”。这层翻译官把硬件操作封装成统一的接口，上层代码只管调用，不用管底层是哪个型号的芯片。这样一来，测试的时候就能用软件模拟硬件行为，不用真硬件也能跑单元测试。

核心观点： HAL设计得好不好，直接决定了驱动层能不能做单元测试。一个好的HAL，能让测试桩（Stub）的构建变得非常简单。

4.1 硬件抽象层的设计模式

我见过不少团队，HAL设计得跟硬件寄存器一一对应。比如有个GPIO模块，他们直接定义了一个结构体，里面全是寄存器的地址偏移量。这种设计，说白了就是把硬件手册抄了一遍，测试的时候根本没法模拟。

我个人习惯用“接口隔离”的思路来设计HAL。什么意思呢？就是让上层代码只依赖抽象接口，不依赖具体实现。举个例子：

// 不好的设计：直接操作寄存器
#define GPIOA_BASE 0x40020000
#define GPIOA_MODER (*(volatile uint32_t *)(GPIOA_BASE + 0x00))

void led_on(void) {
    GPIOA_MODER |= (1 << 10);  // 直接写寄存器
}

// 好的设计：通过HAL接口
typedef struct {
    void (*set_pin_mode)(uint8_t pin, uint8_t mode);
    void (*write_pin)(uint8_t pin, uint8_t level);
    uint8_t (*read_pin)(uint8_t pin);
} gpio_hal_t;

static gpio_hal_t *gpio_hal = NULL;

void led_on(void) {
    if (gpio_hal) {
        gpio_hal->write_pin(LED_PIN, 1);
    }
}

你看，第二种设计里，led_on()函数根本不关心底层是哪个GPIO、哪个寄存器。它只调用一个函数指针。测试的时候，我们只需要给这个函数指针赋值一个模拟函数就行了。

这里有个关键点：HAL接口的设计要“够用”，但不要“过度”。我见过有人把HAL接口设计得跟操作系统API一样复杂，结果测试代码比生产代码还难写。你想想看，HAL的目的是让测试变得简单，不是让测试变得更复杂。

设计模式 优点 缺点 适用场景
函数指针表 灵活，运行时可以替换 需要额外内存存储指针 多硬件平台支持
编译时宏定义 零开销，性能好 测试时需重新编译 单硬件平台，性能敏感
虚函数表（C++） 面向对象，扩展性好 有虚函数表开销 大型项目，C++环境
链接时替换 不改代码，只改链接脚本 调试困难，依赖工具链 已有代码，不想重构
我的经验： 对于大多数嵌入式项目，函数指针表模式是最实用的。它既能在运行时替换，又不会引入太多开销。我在一个车载项目中就用这个模式，同时支持了3种不同的MCU，测试代码几乎没改。

4.2 单元测试桩（Stub）的构建

有了HAL接口，构建测试桩就简单多了。测试桩，说白了就是“假的”硬件实现。它不操作真实寄存器，而是记录调用信息、返回预设值。

为什么会需要测试桩？因为驱动层经常要跟硬件交互，比如读一个传感器数据、写一个PWM占空比。如果没有测试桩，这些操作在PC上根本跑不了。有了测试桩，我们可以模拟各种硬件行为，包括正常情况、边界情况、异常情况。

我给大家看一个实际的测试桩例子：

// 测试桩：模拟GPIO
#include "gpio_hal.h"
#include <assert.h>

// 记录调用信息
static uint8_t last_pin = 0;
static uint8_t last_level = 0;
static uint8_t mock_read_value = 0;
static int write_count = 0;

// 模拟写操作
static void mock_write_pin(uint8_t pin, uint8_t level) {
    last_pin = pin;
    last_level = level;
    write_count++;
}

// 模拟读操作
static uint8_t mock_read_pin(uint8_t pin) {
    return mock_read_value;
}

// 测试桩初始化
void gpio_stub_init(void) {
    last_pin = 0;
    last_level = 0;
    mock_read_value = 0;
    write_count = 0;
}

// 注册测试桩到HAL
void gpio_stub_register(void) {
    gpio_hal_t stub = {
        .set_pin_mode = NULL,  // 不需要模拟
        .write_pin = mock_write_pin,
        .read_pin = mock_read_pin
    };
    gpio_hal_register(&stub);
}

// 测试用例：验证LED点亮
void test_led_on(void) {
    gpio_stub_init();
    gpio_stub_register();
    
    led_on();
    
    assert(last_pin == LED_PIN);
    assert(last_level == 1);
    assert(write_count == 1);
}

这段代码里，测试桩做了三件事：记录调用参数、返回预设值、统计调用次数。测试用例只需要检查这些记录，就能验证驱动代码的行为是否正确。

注意： 测试桩不是模拟器。它不模拟硬件的时序、不模拟中断、不模拟DMA。测试桩只关注“接口行为”，不关注“硬件行为”。如果你需要模拟复杂的硬件行为，那应该用模拟器（Emulator）或者硬件在环（HIL）。

4.3 构建测试桩的常见模式

我在项目中总结了几种常见的测试桩模式，分享给大家：

  1. 记录模式（Record Mode）：记录所有调用信息，包括参数、返回值、调用顺序。适合验证驱动是否正确调用了硬件接口。
  2. 预设模式（Preset Mode）：预先设置好返回值，每次调用返回预设值。适合模拟传感器数据、ADC转换结果等。
  3. 状态机模式（State Machine Mode）：根据调用历史改变行为。适合模拟有状态的硬件，比如UART的发送/接收状态。
  4. 错误注入模式（Error Injection Mode）：随机或按条件返回错误码。适合测试驱动的错误处理逻辑。

你想想看，有了这些模式，几乎所有的硬件行为都能模拟。我曾经在一个项目中，用测试桩模拟了I2C总线的各种异常情况——设备无应答、数据错误、时钟拉伸超时。这些场景在真实硬件上很难复现，但用测试桩可以轻松做到。

4.4 实战：构建一个UART HAL的测试桩

我们来看一个完整的实战例子。假设我们要测试一个UART驱动的发送函数：

// UART HAL接口
typedef struct {
    void (*init)(uint32_t baudrate);
    void (*send_byte)(uint8_t data);
    uint8_t (*receive_byte)(void);
    uint8_t (*is_busy)(void);
} uart_hal_t;

// 生产代码：发送字符串
void uart_send_string(const char *str) {
    while (*str) {
        while (uart_hal->is_busy());  // 等待发送完成
        uart_hal->send_byte(*str++);
    }
}

现在，我们来构建测试桩：

// UART测试桩
#include "uart_hal.h"
#include <string.h>
#include <assert.h>

static uint8_t send_buffer[256];
static int send_index = 0;
static uint8_t mock_busy = 0;

static void mock_init(uint32_t baudrate) {
    // 不操作真实硬件
}

static void mock_send_byte(uint8_t data) {
    send_buffer[send_index++] = data;
}

static uint8_t mock_receive_byte(void) {
    return 0;  // 不模拟接收
}

static uint8_t mock_is_busy(void) {
    return mock_busy;
}

void uart_stub_init(void) {
    memset(send_buffer, 0, sizeof(send_buffer));
    send_index = 0;
    mock_busy = 0;
}

void uart_stub_set_busy(uint8_t busy) {
    mock_busy = busy;
}

uint8_t *uart_stub_get_send_buffer(void) {
    return send_buffer;
}

int uart_stub_get_send_length(void) {
    return send_index;
}

// 测试用例
void test_uart_send_string(void) {
    uart_stub_init();
    
    uart_hal_t stub = {
        .init = mock_init,
        .send_byte = mock_send_byte,
        .receive_byte = mock_receive_byte,
        .is_busy = mock_is_busy
    };
    uart_hal_register(&stub);
    
    uart_send_string("Hello");
    
    assert(uart_stub_get_send_length() == 5);
    assert(memcmp(uart_stub_get_send_buffer(), "Hello", 5) == 0);
}

这个测试桩很简单，但很实用。它验证了：字符串是否被完整发送、发送顺序是否正确、是否等待了忙状态。这些测试在真实硬件上跑，可能需要接示波器看波形，但在测试桩上，一行assert就搞定了。

关键点： 测试桩的复杂度要跟被测代码的复杂度匹配。如果被测代码很简单，测试桩就不要搞得太复杂。我曾经见过有人给一个简单的GPIO写了一个200行的测试桩，结果测试代码比生产代码还难维护。记住，测试桩是为了让测试变简单，不是炫技。

4.5 知识结构图

下面这张图展示了HAL设计模式与测试桩构建的核心逻辑关系：

HAL设计模式与测试桩构建逻辑 应用代码 HAL抽象接口层 真实硬件实现 测试桩实现 真实硬件寄存器 模拟行为/记录 关键点： • 应用代码只依赖HAL接口，不依赖具体实现 • 测试桩实现与真实硬件实现遵循相同的接口契约 • 通过链接时替换或运行时注册，切换真实实现与测试桩

这张图展示了HAL的核心思想：应用代码只跟抽象接口打交道，底层是真实硬件还是测试桩，对上层完全透明。测试的时候，我们只需要把真实硬件实现换成测试桩实现，就能在PC上跑单元测试了。

我的建议： 刚开始做HAL设计时，不要追求完美。先从一个模块开始，比如GPIO或者UART，把接口设计好，测试桩写好。等团队尝到甜头了，再逐步推广到其他模块。我在一个项目中就是这样做的，先从LED驱动开始，三个月后，整个驱动层都覆盖了单元测试。

嗯，这里要注意一点：测试桩不是万能的。它只能验证“接口调用是否正确”，不能验证“硬件行为是否正确”。比如，你写了一个I2C驱动，测试桩可以验证你发送的数据格式是否正确，但不能验证I2C总线的时序是否满足硬件要求。后者需要硬件在环测试或者示波器来验证。

但话说回来，大部分驱动层的bug都是逻辑错误，而不是时序错误。我统计过自己项目中的bug，大概80%的驱动bug都是逻辑错误——条件判断写反了、数据格式错了、状态机跑飞了。这些bug，用测试桩都能发现。剩下的20%时序相关的问题，再用硬件测试去覆盖。这样分工，效率最高。

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