不止是驱动：一个专心设计的、基于“构建器”模式的传感器管理框架

一、引言：嵌入式传感器开发的“混沌”现状

在嵌入式和物联网项目中，传感器是连接物理世界与数字世界的桥梁。然而，随着项目中传感器数量和种类的增加，我们的应用层代码常常会陷入一种“混沌”状态：

• 驱动接口不一：read_sht3x_temp(), get_ds18b20_value(), trigger_ads1015_conversion()… 每个传感器都有一套专属的API，应用层需要记忆和调用大量不同的函数。
• 通用逻辑重复：数据采集、量程检查、数据校准、阈值报警等逻辑，在每个传感器的应用代码中被反复实现，冗余且难以维护。
• 应用与驱动强耦合：应用代码直接调用底层驱动，使得更换一个型号的传感器（例如，用SHT40替换SHT30）可能需要大范围修改上层逻辑。

我们需要的，不仅仅是单个的传感器驱动，而是一个能够将它们有机组织、统一管理、简化应用的框架。今天，我们将要介绍的 wdfk-prog/sensor 项目，正是为此而生。它借鉴了RT-Thread官方传感器的设计，并创新性地引入了“构建器”（Builder）设计模式，为传感器应用开发提供了一套优雅而高效的解决方案。

仓库地址：https://github.com/wdfk-prog/sensor

二、告别混沌：sensor框架的设计哲学

在深入使用方法之前，我们先理解该框架是如何解决上述痛点的。

图1：从强耦合到框架解耦的演变

sensor框架的核心思想是分层与抽象：

1. 驱动层（Driver）：负责与具体硬件（如SHT3x, DS18B20）通信，提供标准化的read/control接口。它只关心“如何获取原始数据”。
2. 核心层（Core）：这是框架的灵魂。它负责：
   • 传感器注册：通过链表管理系统中所有可用的传感器实例。
   • 构建器（Builder）：定义一套标准化的传感器处理流程（例如：采集 -> 校准 -> 范围检查 -> 报警）。
   • 执行器（Director）：统一调度所有“构建器”，驱动整个传感器处理流程的运转。
3. 应用层（Application）：开发者只需关心“将哪个传感器”交给“哪个构建器”处理，并提供一些业务相关的配置（如报警阈值、校准参数等）。

通过这种方式，应用层代码从繁杂的驱动调用和重复的逻辑中解放出来，变得清晰、高内聚。

三、核心概念：构建器（Builder）——传感器处理的“流水线”

“构建器”是理解此框架的关键。您可以把它想象成一条传感器数据的“加工流水线”。每个构建器都包含一系列预设的动作（Action）。

图2：一个典型的“默认”构建器处理流程

• 动作（Action）：每个动作由两部分组成：

  • allow函数（可选）：一个“守卫”，判断当前条件下是否应该执行该动作。例如，allow_collect可以根据定时器判断是否到了采集时间。
  • handler函数：实际执行该动作的逻辑，如default_collect负责调用驱动的read接口。

• 构建策略：框架预设了两种构建策略：

  • default策略：串行处理。将构建器中的所有传感器，逐个完整地走完一遍流水线。适用于传感器处理耗时较长、不能交叉进行的场景。
  • group策略：并行处理。让构建器中的所有传感器，集体完成动作1，然后再集体完成动作2，以此类推。适用于需要同步执行多个传感器动作的场景。

四、实战演练：三步走，用框架管理你的DS18B20

下面我们以一个DS18B20温度传感器为例，展示如何使用此框架。

第1步：注册传感器驱动

首先，我们需要让框架知道“DS18B20”这个传感器的存在。这通常在一个统一的sensor_register函数中完成，该函数需要在系统初始化时被调用。

// 在 sensor_register.c 或类似文件中
#include "sensor_18b20.h" // 引入DS18B20驱动头文件// 假设我们有一个ds18b20的实例
extern sensor_18b20_t ds18b20; /*** @brief  传感器注册函数 (弱函数，可在应用层重写)*/
__weak void sensor_register(void)
{// 将ds18b20传感器的父类（sensor_device_t）注册到全局链表中sensor_register_fun(&ds18b20.parent);// ... 在这里注册所有其他传感器 ...
}

第2步：定义并配置“构建器”

接下来，我们要为DS18B20定义一条“处理流水线”并为其配置“加工参数”。

// 在应用代码中 (e.g., main.c)// 1. 定义一个“默认”策略的构建器
static sensor_builder_t ds18b20_builder = 
{.allow_mode = false,	    // false: 只在第一次执行时判断allow.process = default_process, // 使用框架提供的默认动作序列.process_num = sizeof(default_process) / sizeof(sensor_process_ops_t),.ops = &default_builder_ops,
};// 2. 为该流水线配置具体的参数
static struct sensor_default_cfg ds18b20_cfg = 
{.power = DS18B20_CONSUME,  // 功耗信息 (示例).unit = 10,                // 单位: 0.1°C.cal_addr = 0x080XXXXX,    // 校准参数在Flash中的地址.check = { .max = 85, .min = -55 }, // 量程检查的上下限.ops = { .alarm_handler = temperature_alarm } // 触发报警时调用的函数
};

第3步：组装并启动“生产线”

最后，我们将传感器、配置和构建器三者关联起来，并启动整个处理流程。

// 在应用代码的初始化部分
void sensor_init_example(void)
{sensor_device_t sensor;// 1. 从全局链表中，按名字找到我们注册的DS18B20传感器对象sensor = sensor_obj_get("ds18b20");if(sensor != NULL) {// 2. 将传感器“送入”构建器builder_sensor_add(&ds18b20_builder, sensor);// 3. 将配置“绑定”到构建器builder_config_add(&ds18b20_builder, &ds18b20_cfg, 1, true);// 4. 将配置好的构建器“注册”到执行器sensor_builder_add(&ds18b20_builder);}// ... 对所有其他传感器和构建器重复此过程 ...// 5. 初始化传感器执行器sensor_director_init();
}// 在主循环或定时器线程中
void main_loop(void)
{while(1){// 6. 周期性地驱动所有传感器按预设流程工作sensor_director_process();rt_thread_mdelay(1000);}
}

至此，您的DS18B20传感器已经完全纳入了框架的管理之下。未来如果需要添加一个新的温度传感器，您几乎只需要重复这三步，而无需修改核心的循环逻辑。

五、总结与展望

wdfk-prog/sensor项目为RT-Thread开发者提供了一个超越简单驱动的、高度结构化的传感器管理框架。它通过引入“构建器”设计模式，成功地将传感器驱动、通用处理逻辑和上层应用配置三者清晰地解耦。

使用此框架的价值在于：

• 高度的可扩展性：添加新传感器或新的处理“动作”变得轻而易举。
• 出色的代码复用：通用的传感器处理逻辑被抽象出来，一次编写，处处使用。
• 清晰的应用逻辑：上层代码只需关注业务本身，无需关心底层实现细节，代码更简洁、更易于维护。

如果您正在构建一个涉及多传感器项目，或者希望提升您嵌入式软件架构的健壮性和可维护性，那么这个sensor框架无疑是一个值得学习和借鉴的优秀范例。