STM32 Blue Pill + FreeRTOS 多传感器监测：Wokwi 仿真与任务通信实战

1. 项目缘起与整体设计思路

1.1 为什么选这个组合：Blue Pill + FreeRTOS + Wokwi

STM32 Blue Pill（也就是那块十几块钱的 STM32F103C8T6 最小系统板）在嵌入式圈子里算是“人手一块”的存在。72MHz 主频、64KB Flash、20KB SRAM，资源不算富裕，但跑一个轻量级 RTOS 加几个传感器任务绰绰有余。我手上这块板子买来很久了，一直想找个由头把它用起来，正好最近在梳理 FreeRTOS 的任务调度和队列通信，就想着做一个“房间多传感器监测”的小项目——温湿度、光照、人体感应，三个典型传感器，覆盖模拟量、数字单总线和 GPIO 中断三种不同的采集方式，麻雀虽小五脏俱全。

选 Wokwi 做仿真平台，理由很直接：不用焊板子、不用接线、不用怕烧芯片。Wokwi 对 STM32 Blue Pill 的支持已经比较成熟，能跑 FreeRTOS，能挂 DHT22、BH1750、PIR 这些常见外设，还能实时看串口输出。对于想学 FreeRTOS 但手头没有完整硬件环境的人来说，这是一个几乎零成本的入口。你只需要一个浏览器，就能把任务创建、队列传递、信号量同步这些核心概念跑通。

这个项目的定位很明确：不是做一个产品级的房间监测系统，而是做一个 FreeRTOS 多任务协作的教学级范例。它适合三类人：刚接触 FreeRTOS 想找个完整例子练手的初学者；习惯用仿真平台验证逻辑再上硬件的开发者；以及需要快速演示 RTOS 任务间通信的教学者。整个项目的核心不在于传感器本身，而在于如何用 FreeRTOS 的机制把多个传感器的采集、处理、输出组织成一个稳定运行的系统。

1.2 系统架构：三个任务 + 两条队列 + 一个信号量

在裸机编程里，我们通常写一个超级循环，依次读取传感器、处理数据、刷新显示，简单直接。但这种方式有个天然缺陷：任何一个环节阻塞，整个系统都会卡住。比如 DHT22 的读取需要至少 2 秒的转换等待时间，如果在这期间用delay死等，PIR 传感器的中断响应就会被耽误，光照数据的刷新也会被推迟。

FreeRTOS 的思路是把不同职责拆成独立的任务，由调度器根据优先级和时间片来分配 CPU。这个项目里我设计了三个任务：

• 传感器采集任务（优先级 2）：负责周期性读取 DHT22 温湿度、BH1750 光照强度、PIR 人体感应状态，把结果打包成结构体，通过队列发送给处理任务。
• 数据处理任务（优先级 1）：从队列接收原始数据，做简单的滤波和阈值判断，比如温度超过 30 度标记为“高温”、光照低于 50 lux 标记为“昏暗”、PIR 触发标记为“有人活动”。
• 串口输出任务（优先级 1）：从第二条队列接收处理后的结果，格式化后通过 UART 打印出来，同时控制板载 LED 做状态指示。

任务之间通过两条队列通信：一条从采集任务到处理任务，传递原始传感器数据；另一条从处理任务到输出任务，传递处理后的状态信息。另外用一个二值信号量来保护对 DHT22 的访问——虽然这个项目里只有一个任务读 DHT22，但加上信号量是为了演示资源互斥的用法，也方便后续扩展多个采集任务。

提示：任务优先级的分配原则是“响应时间要求越短的任务优先级越高”。采集任务需要及时响应 PIR 中断和定时采样，所以给 2；处理和输出对实时性要求没那么高，给 1 即可。如果后续加入显示刷新任务，可以再调整。

1.3 数据流与任务间通信的设计考量

为什么用队列而不是全局变量？这是 FreeRTOS 初学者最容易犯的错。全局变量在单任务环境下没问题，但多任务并发访问时，如果没有保护机制，就会出现数据竞争。比如采集任务正在写温度值，处理任务同时读这个变量，可能读到一半新一半旧的“撕裂数据”。队列自带拷贝语义和阻塞机制，发送方和接收方不需要额外加锁，天然线程安全。

队列的长度也需要斟酌。采集任务每 2 秒发一次数据，处理任务正常情况下能在几十毫秒内处理完，所以队列深度设为 4 就足够了——即使处理任务偶尔被高优先级任务抢占，也不会丢数据。如果队列设得太短，采集任务发送时发现队列满，可以选择阻塞等待或丢弃数据；设得太长则浪费内存。在 20KB SRAM 的 Blue Pill 上，每个队列项大约 16 字节，深度 4 的队列只占 64 字节，完全可以接受。

信号量的使用场景是 DHT22 的读取。DHT22 的单总线协议对时序要求很严格，读取过程中不能被其他任务打断。虽然 FreeRTOS 的任务调度是基于时间片的，但在读取 DHT22 时如果发生任务切换，时序就会乱掉。所以我在读取前获取信号量，读取完成后释放，确保这段时间内不会有其他任务干扰。实际测试中，即使不加信号量，因为 DHT22 读取函数里关了中断，也能正常工作，但加上信号量是更规范的做法。

2. 核心细节解析与实操要点

2.1 Wokwi 仿真环境的搭建与 STM32 配置

Wokwi 是一个在线嵌入式仿真平台，打开浏览器就能用，不需要安装任何软件。进入 Wokwi 后新建一个 STM32 Blue Pill 项目，你会看到一个默认的main.c和diagram.json。diagram.json是硬件连接描述文件，定义了板子和外设之间的引脚连接；main.c是主程序。Wokwi 支持直接编译和运行，串口输出会显示在底部的终端窗口。

在diagram.json里，我们需要添加三个外设：DHT22 温湿度传感器、BH1750 光照传感器、PIR 人体感应模块。DHT22 的数据引脚接到 PA1，BH1750 使用 I2C 接口，SCL 接 PB6、SDA 接 PB7，PIR 的数字输出接 PA0。这些引脚选择不是随意的：PA0 同时是外部中断线 0，方便配置中断；PB6/PB7 是 STM32F103 的 I2C1 默认引脚，Wokwi 的 BH1750 模型默认使用这个接口。

{ "version": 1, "author": "room-multisensor", "editor": "wokwi", "parts": [ { "type": "wokwi-stm32-blue-pill", "id": "stm32", "top": 0, "left": 0 }, { "type": "wokwi-dht22", "id": "dht", "top": -80, "left": 100, "attrs": {} }, { "type": "wokwi-bh1750", "id": "bh1750", "top": -80, "left": -100, "attrs": {} }, { "type": "wokwi-pir", "id": "pir", "top": 80, "left": 100, "attrs": {} } ], "connections": [ [ "stm32:PA1", "dht:2", "green", [] ], [ "stm32:PB6", "bh1750:SCL", "blue", [] ], [ "stm32:PB7", "bh1750:SDA", "blue", [] ], [ "stm32:PA0", "pir:OUT", "yellow", [] ], [ "stm32:3V3", "dht:1", "red", [] ], [ "stm32:GND", "dht:4", "black", [] ] ] }

注意：Wokwi 的 DHT22 模型引脚顺序是 1-VCC、2-DATA、3-NC、4-GND，和实物略有不同，接线时以仿真图为准。BH1750 的地址默认是 0x23，如果模块上有 ADDR 引脚拉高则变为 0x5C，Wokwi 模型默认 0x23。

FreeRTOS 的源码在 Wokwi 里不需要手动下载，平台已经内置了 FreeRTOS 内核。你只需要在代码里包含FreeRTOS.h和task.h等头文件，然后在platformio.ini或 Wokwi 的项目配置里启用 FreeRTOS 支持即可。Wokwi 使用的是 GCC 工具链，编译选项里需要加上-DUSE_FREERTOS或者在代码里直接调用 FreeRTOS API。

2.2 FreeRTOS 任务创建与优先级分配

任务创建使用xTaskCreate函数，原型是：

BaseType_t xTaskCreate( TaskFunction_t pvTaskCode, // 任务函数指针 const char * const pcName, // 任务名称（调试用） configSTACK_DEPTH_TYPE usStackDepth, // 栈深度（单位：字） void *pvParameters, // 传递给任务的参数 UBaseType_t uxPriority, // 优先级 TaskHandle_t *pxCreatedTask // 任务句柄 );

栈深度的单位是“字”，在 32 位 STM32 上 1 字等于 4 字节。采集任务里用了sprintf和浮点运算，栈需求较大，我给了 256 字（1KB）；处理任务和输出任务各给 128 字（512 字节）。这三个任务加起来占 2KB 栈空间，加上 FreeRTOS 内核自身的开销（约 1KB），总共 3KB 左右，在 20KB SRAM 里占比很小，留足了余量。

优先级方面，采集任务设为 2，处理和输出设为 1。FreeRTOS 的调度策略是“优先级抢占 + 同优先级时间片轮转”。采集任务优先级最高，当它从阻塞态（等待定时器）变为就绪态时，会立即抢占正在运行的低优先级任务。这保证了传感器数据的采集周期稳定。处理和输出任务优先级相同，它们之间按时间片轮流执行，每个时间片默认 1ms（由configTICK_RATE_HZ决定，通常设为 1000）。

xTaskCreate(vSensorTask, "Sensor", 256, NULL, 2, &xSensorTaskHandle); xTaskCreate(vProcessTask, "Process", 128, NULL, 1, &xProcessTaskHandle); xTaskCreate(vOutputTask, "Output", 128, NULL, 1, &xOutputTaskHandle);

实操心得：任务栈溢出是 FreeRTOS 新手最常见的崩溃原因。建议在开发阶段开启configCHECK_FOR_STACK_OVERFLOW设为 2，并在vApplicationStackOverflowHook里打印出错任务名。Wokwi 的串口终端会显示这些信息，方便定位问题。

2.3 队列与信号量的创建和使用

队列在使用前必须先创建。创建队列的函数是xQueueCreate，参数是队列长度和每个队列项的大小（字节）。这个项目里定义了两个结构体：SensorData_t存放原始传感器数据，ProcessedData_t存放处理后的状态信息。

typedef struct { float temperature; float humidity; uint16_t lightLux; uint8_t motionDetected; } SensorData_t; typedef struct { uint8_t tempStatus; // 0-正常 1-高温 2-低温 uint8_t lightStatus; // 0-正常 1-昏暗 2-过亮 uint8_t motionStatus; // 0-无人 1-有人 uint32_t timestamp; } ProcessedData_t; QueueHandle_t xSensorQueue = xQueueCreate(4, sizeof(SensorData_t)); QueueHandle_t xProcessedQueue = xQueueCreate(4, sizeof(ProcessedData_t)); SemaphoreHandle_t xDHT22Semaphore = xSemaphoreCreateBinary();

信号量创建后默认是“空”的，需要先释放一次才能被获取。我在main函数里创建完信号量后立即调用xSemaphoreGive(xDHT22Semaphore)，这样采集任务第一次读取 DHT22 时就能成功获取。

发送数据到队列用xQueueSend，接收用xQueueReceive。这两个函数都有阻塞版本和非阻塞版本。采集任务发送时用xQueueSend(xSensorQueue, &data, pdMS_TO_TICKS(100))，表示如果队列满则最多等待 100ms；处理任务接收时用xQueueReceive(xSensorQueue, &data, portMAX_DELAY)，表示一直阻塞等待直到有数据到来。这种“发送方有限等待、接收方无限等待”的搭配，既避免了采集任务被长时间阻塞，又保证了处理任务不会空转浪费 CPU。

注意：portMAX_DELAY在 FreeRTOS 里是一个宏，表示无限等待。使用它时任务会进入阻塞态，不消耗 CPU 时间。但要注意，如果队列永远没有数据，任务就会永远阻塞，所以需要确保有发送方。

3. 实操过程与核心环节实现

3.1 传感器采集任务的完整实现

采集任务是整个系统的数据源头，它的职责是周期性地读取三个传感器，把数据打包后发送到队列。任务函数是一个无限循环，每次循环开始时先获取 DHT22 信号量，读取温湿度，释放信号量；然后读取 BH1750 光照；最后读取 PIR 状态。三个数据都拿到后，打包成SensorData_t结构体，发送到xSensorQueue。

void vSensorTask(void *pvParameters) { SensorData_t data; TickType_t lastWakeTime = xTaskGetTickCount(); const TickType_t xFrequency = pdMS_TO_TICKS(2000); for (;;) { // 读取 DHT22，用信号量保护 if (xSemaphoreTake(xDHT22Semaphore, pdMS_TO_TICKS(500)) == pdTRUE) { dht22_read(&data.temperature, &data.humidity); xSemaphoreGive(xDHT22Semaphore); } else { data.temperature = -99.0f; data.humidity = -99.0f; } // 读取 BH1750 光照 data.lightLux = bh1750_read_lux(); // 读取 PIR 状态 data.motionDetected = gpio_read_pir(); // 发送到队列 if (xQueueSend(xSensorQueue, &data, pdMS_TO_TICKS(100)) != pdPASS) { printf("[Sensor] Queue full, data dropped\r\n"); } vTaskDelayUntil(&lastWakeTime, xFrequency); } }

这里用vTaskDelayUntil而不是vTaskDelay，是为了保证采集周期严格为 2000ms。vTaskDelay是“延迟指定时间”，实际周期等于“处理时间 + 延迟时间”，会随着处理时间波动；vTaskDelayUntil是“延迟到指定时刻”，周期固定，适合需要稳定采样率的场景。

DHT22 的读取函数需要实现单总线协议：主机拉低数据线至少 1ms 作为起始信号，然后释放，等待 DHT22 响应。DHT22 会拉低 80us 再拉高 80us 表示应答，然后连续输出 40 位数据（16 位湿度 + 16 位温度 + 8 位校验和）。每一位数据以 50us 低电平开始，高电平持续时间决定数据是 0 还是 1：26-28us 表示 0，70us 表示 1。这个时序对微秒级延时要求很高，在 Wokwi 仿真里可以用delay_us函数实现。

实操心得：DHT22 读取失败率比较高，尤其是在仿真环境里。建议在读取函数里加重试机制，连续读三次取中间值，或者至少读两次对比。如果两次差异超过 2 度，就丢弃这次数据。我在 Wokwi 里测试时，大约每 10 次读取会有 1 次失败，加上重试后基本稳定。

3.2 数据处理任务与阈值判断逻辑

处理任务从xSensorQueue接收原始数据，根据预设阈值判断状态，然后把结果发送到xProcessedQueue。阈值判断的逻辑不复杂，但需要考虑边界情况和数据有效性。比如 DHT22 读取失败时温度会是 -99，这时候不应该判断为“低温”，而应该标记为“传感器故障”。

void vProcessTask(void *pvParameters) { SensorData_t raw; ProcessedData_t processed; for (;;) { if (xQueueReceive(xSensorQueue, &raw, portMAX_DELAY) == pdPASS) { // 温度状态判断 if (raw.temperature < -50.0f) { processed.tempStatus = 3; // 传感器故障 } else if (raw.temperature > 30.0f) { processed.tempStatus = 1; // 高温 } else if (raw.temperature < 10.0f) { processed.tempStatus = 2; // 低温 } else { processed.tempStatus = 0; // 正常 } // 光照状态判断 if (raw.lightLux < 50) { processed.lightStatus = 1; // 昏暗 } else if (raw.lightLux > 1000) { processed.lightStatus = 2; // 过亮 } else { processed.lightStatus = 0; // 正常 } // 人体感应状态 processed.motionStatus = raw.motionDetected ? 1 : 0; processed.timestamp = xTaskGetTickCount() * portTICK_PERIOD_MS; xQueueSend(xProcessedQueue, &processed, pdMS_TO_TICKS(100)); } } }

阈值的选择基于常见的室内环境标准：温度 10-30 度是舒适区间，光照 50-1000 lux 是正常活动范围。这些值可以根据实际需求调整，比如书房可能需要更亮的光照，卧室可能需要更暗。PIR 状态直接映射，检测到人体活动就标记为 1。

时间戳使用xTaskGetTickCount()获取系统节拍数，乘以portTICK_PERIOD_MS转换为毫秒。这个时间戳在输出任务里用来计算数据延迟，也可以用来做简单的趋势分析。比如连续三次检测到温度上升，就可以提前预警。

3.3 串口输出任务与 LED 状态指示

输出任务从xProcessedQueue接收处理后的数据，格式化后通过 UART 打印。STM32F103 的 USART1 默认引脚是 PA9（TX）和 PA10（RX），Wokwi 的串口终端会自动连接到这两个引脚。打印格式要清晰易读，我用了表格形式，每行显示一个时间戳和三个状态。

void vOutputTask(void *pvParameters) { ProcessedData_t data; const char *tempStr[] = {"Normal", "High", "Low", "Fault"}; const char *lightStr[] = {"Normal", "Dark", "Bright"}; const char *motionStr[] = {"No motion", "Motion"}; for (;;) { if (xQueueReceive(xProcessedQueue, &data, portMAX_DELAY) == pdPASS) { printf("[%lu ms] Temp: %s | Light: %s | Motion: %s\r\n", data.timestamp, tempStr[data.tempStatus], lightStr[data.lightStatus], motionStr[data.motionStatus]); // LED 指示：有人活动时点亮 PC13 if (data.motionStatus == 1) { gpio_set(LED_PORT, LED_PIN); } else { gpio_reset(LED_PORT, LED_PIN); } } } }

Blue Pill 的板载 LED 连接在 PC13，低电平点亮。Wokwi 的仿真模型里这个 LED 也会同步显示，方便直观看到 PIR 触发状态。输出任务里还做了一个简单的统计：每 10 次输出后打印一行分隔线，方便在串口终端里区分数据批次。

注意：printf在 FreeRTOS 里不是线程安全的，如果多个任务同时调用会输出乱码。这个项目里只有输出任务用printf，所以没问题。如果后续加入其他需要打印的任务，建议用互斥量保护，或者改用xQueueSend把打印内容发到统一的输出队列。

3.4 主函数与调度器启动

主函数负责初始化硬件、创建 FreeRTOS 对象、创建任务，最后启动调度器。初始化的顺序很重要：先初始化串口（方便调试输出），再初始化传感器，然后创建队列和信号量，最后创建任务并启动调度器。

int main(void) { // 硬件初始化 uart_init(115200); dht22_init(); bh1750_init(); pir_init(); led_init(); printf("Room Multisensor Starting...\r\n"); // 创建 FreeRTOS 对象 xSensorQueue = xQueueCreate(4, sizeof(SensorData_t)); xProcessedQueue = xQueueCreate(4, sizeof(ProcessedData_t)); xDHT22Semaphore = xSemaphoreCreateBinary(); xSemaphoreGive(xDHT22Semaphore); // 创建任务 xTaskCreate(vSensorTask, "Sensor", 256, NULL, 2, NULL); xTaskCreate(vProcessTask, "Process", 128, NULL, 1, NULL); xTaskCreate(vOutputTask, "Output", 128, NULL, 1, NULL); // 启动调度器 vTaskStartScheduler(); // 正常情况下不会执行到这里 for (;;); }

vTaskStartScheduler()启动调度器后，FreeRTOS 会创建空闲任务（优先级 0）和定时器任务（如果启用了软件定时器）。空闲任务在系统没有其他就绪任务时运行，可以用来做内存回收或低功耗处理。这个项目里没有用到软件定时器，所以只需要空闲任务即可。

实操心得：如果程序在vTaskStartScheduler()后卡死，最常见的原因是堆空间不足。FreeRTOS 的任务栈和队列都从堆里分配，configTOTAL_HEAP_SIZE默认是 17KB 左右，如果创建的任务太多或栈太大，就会分配失败。可以在vTaskStartScheduler()前打印xPortGetFreeHeapSize()查看剩余堆空间。

4. 常见问题与排查技巧实录

4.1 任务栈溢出与堆空间不足的排查

栈溢出是 FreeRTOS 项目里最隐蔽的问题之一。症状可能是任务突然停止运行、数据错乱、或者系统直接死机。FreeRTOS 提供了栈溢出检测机制，在FreeRTOSConfig.h里把configCHECK_FOR_STACK_OVERFLOW设为 2，然后在代码里实现vApplicationStackOverflowHook函数：

void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { printf("STACK OVERFLOW in task: %s\r\n", pcTaskName); for (;;); }

当检测到栈溢出时，这个钩子函数会被调用，打印出出错的任务名。Wokwi 的串口终端会显示这条信息，直接定位到问题任务。栈溢出的常见原因是局部变量太大（比如在任务里定义了 100 字节的数组）或者递归调用太深。解决办法是增大任务栈深度，或者把大数组改成静态分配。

堆空间不足的表现是xTaskCreate或xQueueCreate返回pdFAIL。可以在创建对象后检查返回值，如果失败就打印错误信息。xPortGetFreeHeapSize()返回当前剩余堆空间，xPortGetMinimumEverFreeHeapSize()返回历史最小剩余堆空间，后者更能反映堆的使用峰值。

4.2 DHT22 读取失败的常见原因与解决

DHT22 读取失败在仿真和实物中都很常见。在 Wokwi 里，失败通常表现为温度湿度都是 0 或者 -99。原因可能有几个：时序不对、信号量未释放、或者传感器模型响应延迟。首先检查dht22_read函数里的微秒延时是否准确，Wokwi 的仿真时间可能和真实时间有偏差，可以适当放宽时序容差。

其次检查信号量。如果采集任务在获取信号量后没有释放（比如读取函数里提前 return 了），下次读取就会一直阻塞。建议用xSemaphoreTake的返回值判断是否成功获取，无论读取成功与否都要释放信号量。我在代码里用了if...else结构，确保任何情况下都会执行xSemaphoreGive。

还有一个容易被忽略的点：DHT22 上电后需要 1-2 秒的稳定时间，第一次读取往往失败。可以在初始化后加一个vTaskDelay(pdMS_TO_TICKS(2000))，等传感器稳定后再开始采集。实测下来，加上这个延迟后，首次读取成功率明显提高。

提示：如果 DHT22 持续读取失败，可以先用一个简单的裸机程序测试传感器本身是否正常，排除硬件或仿真模型的问题。确认传感器没问题后，再检查 FreeRTOS 环境下的时序和信号量逻辑。

4.3 队列满与数据丢失的处理策略

队列满的情况在采集频率高、处理速度慢时会出现。这个项目里采集周期 2 秒，处理任务通常几十毫秒就能完成，所以队列满的概率很低。但如果处理任务被高优先级任务长时间抢占，或者处理逻辑变复杂，就可能出现队列满。xQueueSend在队列满时会返回errQUEUE_FULL，我在这里打印了一条警告信息，方便调试时发现。

处理队列满的策略有三种：丢弃新数据、丢弃旧数据、或者阻塞等待。丢弃新数据最简单，但会丢失最新信息；丢弃旧数据需要先接收再发送，会多一次拷贝；阻塞等待会让采集任务暂停，影响采样周期。这个项目选择了丢弃新数据并打印警告，因为传感器数据具有时效性，旧数据比新数据更有价值。

如果数据丢失频繁发生，可以考虑增大队列深度、提高处理任务优先级、或者优化处理逻辑减少耗时。在 Wokwi 里可以通过串口输出的时间戳计算处理延迟，如果延迟超过 500ms，就说明处理任务需要优化了。

4.4 Wokwi 仿真与真实硬件的差异及注意事项

Wokwi 仿真虽然方便，但和真实硬件有一些差异需要注意。首先是时序精度：Wokwi 的仿真时间是基于软件模拟的，微秒级延时的精度不如真实硬件。DHT22 的单总线协议对时序要求很高，在仿真里可能需要调整延时参数才能稳定读取。其次是中断响应：Wokwi 对中断的模拟比较理想化，真实硬件上中断延迟会受到其他中断和临界区的影响。

另外，Wokwi 的传感器模型是理想化的，不会出现真实传感器的噪声和漂移。比如 BH1750 在仿真里读数非常稳定，但实物会有 ±20% 的波动。PIR 传感器在仿真里触发很干净，实物可能会有误触发。所以这个项目在仿真里跑通后，移植到真实硬件时还需要做滤波和去抖处理。

实操心得：我通常的做法是先在 Wokwi 里把 FreeRTOS 的任务框架和通信逻辑跑通，确认任务调度、队列传递、信号量同步都没问题，然后再移植到真实硬件上调试传感器驱动。这样可以把 RTOS 层面的问题和硬件层面的问题分开排查，效率高很多。

5. 项目扩展与进阶方向

5.1 加入软件定时器实现周期性任务

目前采集任务用vTaskDelayUntil实现周期控制，这种方式简单直接，但会占用一个任务栈。如果周期任务比较多，可以考虑用 FreeRTOS 的软件定时器。软件定时器由一个定时器服务任务统一管理，不需要为每个定时器创建独立任务，节省栈空间。

使用软件定时器需要先在FreeRTOSConfig.h里把configUSE_TIMERS设为 1，然后调用xTimerCreate创建定时器，指定周期和回调函数。回调函数在定时器服务任务的上下文里执行，不能调用阻塞 API。对于传感器采集这种需要调用阻塞 API 的场景，可以在回调函数里发送一个任务通知或队列消息，唤醒采集任务执行实际读取。

TimerHandle_t xSensorTimer = xTimerCreate( "SensorTimer", pdMS_TO_TICKS(2000), pdTRUE, // 自动重载 NULL, vSensorTimerCallback ); void vSensorTimerCallback(TimerHandle_t xTimer) { xTaskNotifyGive(xSensorTaskHandle); }

采集任务改成等待通知：ulTaskNotifyTake(pdTRUE, portMAX_DELAY)。这样采集任务只在定时器触发时运行，其他时间都处于阻塞态，不消耗 CPU。

5.2 低功耗模式与 tickless 空闲

Blue Pill 虽然通常用 USB 供电，不太考虑功耗，但如果用电池供电，低功耗就很重要了。FreeRTOS 提供了 tickless 空闲模式，在系统空闲时关闭系统节拍中断，让 MCU 进入低功耗状态，有任务需要运行时再唤醒。启用 tickless 模式需要把configUSE_TICKLESS_IDLE设为 1，并实现vPortSuppressTicksAndSleep函数。

在 Wokwi 里 tickless 模式的效果不太明显，因为仿真不模拟功耗。但在真实硬件上，tickless 模式可以把空闲电流从十几毫安降到几毫安甚至更低。对于这个房间监测项目，如果采集周期是 2 秒，大部分时间系统都在空闲，tickless 模式可以显著延长电池寿命。

5.3 从仿真到实物的移植清单

把项目从 Wokwi 移植到真实 Blue Pill 上，需要做几件事：把diagram.json里的引脚连接对应到实际接线；把 Wokwi 特有的仿真函数替换成 HAL 库或标准外设库函数；调整 DHT22 的微秒延时参数；加入传感器滤波和去抖逻辑。

具体来说，Wokwi 里的gpio_read_pir()需要替换成HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0)；bh1750_read_lux()里的 I2C 读写需要替换成HAL_I2C_Master_Transmit和HAL_I2C_Master_Receive；dht22_read()里的微秒延时可以用 DWT 周期计数器或硬件定时器实现。串口输出可以用HAL_UART_Transmit或者重定向printf到 USART1。

移植过程中最容易出问题的是 DHT22 的时序。真实硬件上建议用示波器或逻辑分析仪抓一下数据线的波形，确认起始信号、应答信号和数据位的时序都符合 DHT22 手册要求。如果手头没有仪器，可以用 GPIO 翻转加延时的方式慢慢调，先确保能读到稳定的数据，再优化速度。

这个项目后续还可以加入 OLED 显示、WiFi 上报、数据存储等功能。FreeRTOS 的任务框架已经搭好了，新增功能只需要创建新任务、定义新队列，然后接入现有的数据流即可。比如加一个 OLED 显示任务，从xProcessedQueue接收数据并刷新屏幕；加一个 WiFi 上报任务，把数据打包成 JSON 通过串口发给 ESP8266 模块。任务之间通过队列解耦，互不影响，这就是 RTOS 多任务架构的优势所在。