4、板级支持包(BSP)设计：传感器接口、执行器驱动、通信接口适配

好，咱们接着聊BSP层。这一层说白了，就是让硬件和上层软件「握手」的地方。

我个人的习惯是，先把BSP看作一个「硬件抽象层」。什么意思呢？就是上层代码不用管你用的是哪家的温度传感器，也不用管你是I2C还是SPI。它只管调用一个 bsp_temp_get() 函数，拿到温度值就行。

嗯，这里要注意：BSP设计的好坏，直接决定了你后续移植工作量的多少。我在项目中遇到过，有人把传感器寄存器操作直接写在了应用层里。结果换了个传感器型号，整个项目几乎重写了一遍。那叫一个惨。

4.1 传感器接口设计

传感器是消防报警系统的「眼睛」和「鼻子」。烟雾传感器、温度传感器、气体传感器，每种都有自己的脾气。

我的设计原则是：每个传感器一个驱动文件，对外暴露统一的接口。

举个例子，烟雾传感器，我通常会这样设计接口：

/* bsp_smoke.h */
#ifndef _BSP_SMOKE_H_
#define _BSP_SMOKE_H_

#include <stdint.h>
#include <stdbool.h>

/* 传感器初始化 */
bool bsp_smoke_init(void);

/* 读取烟雾浓度，单位：%/ft */
float bsp_smoke_read_density(void);

/* 读取传感器状态：正常、故障、污染 */
typedef enum {
    SMOKE_STATUS_OK = 0,
    SMOKE_STATUS_FAULT,
    SMOKE_STATUS_CONTAMINATED
} smoke_status_t;

smoke_status_t bsp_smoke_get_status(void);

/* 自检：触发传感器内部自检 */
bool bsp_smoke_self_test(void);

/* 校准：零点校准 */
void bsp_smoke_calibrate_zero(void);

#endif /* _BSP_SMOKE_H_ */

你看，接口很干净。上层应用不需要知道传感器是离子式的还是光电式的，也不需要知道它内部寄存器怎么配。

我的小技巧： 每个传感器驱动里，我都会加一个 bsp_xxx_self_test() 函数。消防系统对可靠性要求极高，自检功能是刚需。我曾经吃过亏，传感器坏了系统还不知道，直到误报才被发现。

温度传感器接口也类似：

/* bsp_temp.h */
bool bsp_temp_init(void);
float bsp_temp_read_celsius(void);
float bsp_temp_read_fahrenheit(void);
temp_status_t bsp_temp_get_status(void);

为什么要同时提供摄氏度和华氏度？嗯，有些国际项目会用华氏度。接口设计时多考虑一步，后面省事很多。

4.2 执行器驱动设计

执行器是消防系统的「手脚」。声光报警器、电磁阀、排烟风机、防火门，这些都是执行器。

执行器驱动和传感器驱动有个本质区别：传感器是输入，执行器是输出。所以接口设计上，更关注「控制」和「反馈」。

我举个例子，声光报警器驱动：

/* bsp_alarm.h */
#ifndef _BSP_ALARM_H_
#define _BSP_ALARM_H_

#include <stdint.h>
#include <stdbool.h>

/* 报警模式 */
typedef enum {
    ALARM_MODE_SILENT = 0,      /* 静音 */
    ALARM_MODE_SOUND_ONLY,      /* 仅声音 */
    ALARM_MODE_LIGHT_ONLY,      /* 仅闪光 */
    ALARM_MODE_BOTH             /* 声光同时 */
} alarm_mode_t;

/* 初始化 */
bool bsp_alarm_init(void);

/* 设置报警模式 */
void bsp_alarm_set_mode(alarm_mode_t mode);

/* 设置音量等级：0-100 */
void bsp_alarm_set_volume(uint8_t level);

/* 获取当前状态 */
alarm_mode_t bsp_alarm_get_mode(void);

/* 获取反馈：执行器是否正常响应 */
bool bsp_alarm_get_feedback(void);

/* 停止报警 */
void bsp_alarm_stop(void);

#endif /* _BSP_ALARM_H_ */
避坑指南： 我曾经设计过一个电磁阀驱动，只提供了「开」和「关」两个接口。结果现场调试时发现，电磁阀动作太快，产生了水锤效应，把管道震坏了。后来我加了一个「缓开」和「缓关」的接口，问题才解决。所以执行器驱动，要考虑实际物理场景。

对于电机类的执行器（比如排烟风机），我通常会提供速度控制接口：

/* bsp_fan.h */
bool bsp_fan_init(void);
void bsp_fan_set_speed(uint16_t rpm);   /* 设置转速 */
uint16_t bsp_fan_get_speed(void);       /* 读取实际转速 */
bool bsp_fan_get_fault_status(void);    /* 故障检测 */

这里有个关键点：读取实际转速。很多执行器驱动只写不读，这是大忌。消防系统需要闭环控制，你发了指令，得知道执行器到底执行了没有。

4.3 通信接口适配

通信接口是BSP里最复杂的一块。消防系统里，通信方式五花八门：CAN、RS485、以太网、LoRa、NB-IoT……

我的做法是：设计一个统一的通信抽象层。

先看一个简单的通信接口定义：

/* bsp_comm.h */
#ifndef _BSP_COMM_H_
#define _BSP_COMM_H_

#include <stdint.h>
#include <stdbool.h>

/* 通信接口类型 */
typedef enum {
    COMM_TYPE_CAN = 0,
    COMM_TYPE_RS485,
    COMM_TYPE_ETHERNET,
    COMM_TYPE_LORA,
    COMM_TYPE_NBIOT
} comm_type_t;

/* 通信状态 */
typedef enum {
    COMM_STATUS_OK = 0,
    COMM_STATUS_DISCONNECTED,
    COMM_STATUS_ERROR,
    COMM_STATUS_BUSY
} comm_status_t;

/* 通用通信接口 */
typedef struct {
    bool (*init)(void);
    bool (*send)(const uint8_t *data, uint16_t len, uint32_t timeout_ms);
    bool (*recv)(uint8_t *buffer, uint16_t *len, uint32_t timeout_ms);
    comm_status_t (*get_status)(void);
    void (*reset)(void);
} comm_interface_t;

/* 获取指定通信接口的实例 */
const comm_interface_t* bsp_comm_get_interface(comm_type_t type);

#endif /* _BSP_COMM_H_ */

你看，我用了一个结构体来封装通信接口。每种通信方式，只需要实现这个结构体里的函数指针就行。

举个例子，CAN接口的实现：

/* bsp_comm_can.c */
static bool can_init(void) {
    /* 配置CAN控制器 */
    /* 设置波特率、过滤器等 */
    return true;
}

static bool can_send(const uint8_t *data, uint16_t len, uint32_t timeout_ms) {
    /* 将数据打包成CAN帧 */
    /* 发送并等待ACK */
    return true;
}

static bool can_recv(uint8_t *buffer, uint16_t *len, uint32_t timeout_ms) {
    /* 从CAN FIFO中读取数据 */
    return true;
}

static comm_status_t can_get_status(void) {
    /* 读取CAN控制器状态寄存器 */
    return COMM_STATUS_OK;
}

static void can_reset(void) {
    /* 复位CAN控制器 */
}

const comm_interface_t g_can_interface = {
    .init = can_init,
    .send = can_send,
    .recv = can_recv,
    .get_status = can_get_status,
    .reset = can_reset
};
核心思想： 上层应用只跟 comm_interface_t 打交道。今天用CAN，明天换RS485，上层代码一行都不用改。只需要在BSP层新增一个 bsp_comm_rs485.c 文件，实现同样的接口即可。

通信接口适配里，还有一个容易被忽略的点：超时处理。消防系统的通信，对实时性有要求。我习惯在每个通信接口里都加上超时参数，并且超时后要有明确的错误处理。

我曾经遇到过一个项目，RS485通信偶尔会卡死。排查了很久，发现是接收函数没有超时机制，一直死等。后来加了个看门狗定时器，超时自动复位通信接口，问题就解决了。

4.4 BSP层的测试策略

BSP层写完了，怎么测？我的经验是：写一个BSP测试用例文件。

比如 bsp_test.c：

/* bsp_test.c */
#include "bsp_smoke.h"
#include "bsp_temp.h"
#include "bsp_alarm.h"
#include "bsp_comm.h"

void bsp_self_test(void) {
    /* 测试传感器 */
    if (bsp_smoke_init()) {
        float density = bsp_smoke_read_density();
        /* 验证数值是否在合理范围 */
    }
    
    /* 测试执行器 */
    if (bsp_alarm_init()) {
        bsp_alarm_set_mode(ALARM_MODE_BOTH);
        /* 检查反馈信号 */
        bool feedback = bsp_alarm_get_feedback();
    }
    
    /* 测试通信 */
    const comm_interface_t *can = bsp_comm_get_interface(COMM_TYPE_CAN);
    if (can && can->init()) {
        uint8_t test_data[] = {0xAA, 0xBB, 0xCC};
        can->send(test_data, 3, 100);
    }
}

这个测试函数，我会在系统上电时调用一次。如果BSP层有问题，系统直接报故障，不会让上层应用在错误的硬件基础上运行。

我的习惯： BSP测试用例里，我会故意制造一些错误场景。比如拔掉传感器，看看驱动能不能正确返回故障状态。这种「破坏性测试」在消防系统里特别重要。

好了，BSP层就讲到这里。总结一下：

  • 传感器接口：统一抽象，隐藏硬件细节
  • 执行器驱动：闭环控制，有写有读有反馈
  • 通信接口适配：函数指针结构体，方便切换
  • 测试策略：自检函数，上电必跑

下一章，咱们聊聊操作系统抽象层。那又是另一番天地了。

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