FreeRTOS实战：基于STM32的多传感器室内环境监测终端设计与实现

FreeRTOS 项目实战：手把手做一个多传感器室内环境监测终端

如果你已经在裸机开发里摸爬滚打了一阵子，正琢磨着怎么把手头那套“一个 while(1) 走天下”的逻辑升级成真正的实时操作系统，那 FreeRTOS 绝对是最合适的切入点。这次我不讲空泛的理论，直接拿一个可以完整落地的项目说事——FreeRTOS Multisensor Room Monitor，一个基于 FreeRTOS 的多传感器室内环境监测终端。

这个项目听起来高大上，其实本质就是把温湿度、光照、空气质量这几个传感器挂到一块 STM32 上，然后用 FreeRTOS 的任务机制去管理数据采集、处理和显示。它能解决的实际问题很简单：你家的温湿度计只能显示温湿度，空气检测仪只能测 PM2.5，光照传感器还得单独接个屏幕，而用 FreeRTOS 把这些整合到一个系统里，每个传感器一个独立任务，数据通过队列汇总到显示任务，互不阻塞、实时响应，这才是 RTOS 相比裸机循环最大的价值所在。

适合谁参考？正在学 FreeRTOS 但找不到实战案例的嵌入式初学者，以及想从裸机开发过渡到多任务开发的工程师。下面我按照实际开发顺序，把这个项目的完整实现过程拆开来讲，包括任务划分、信号量/队列机制、堆栈配置、低功耗处理和常见的坑。

1. 项目整体架构与方案选型

动手之前先要把架构想清楚。很多人一上来就写代码，结果任务优先级乱设、堆栈大小瞎填，最后系统跑起来一会儿死机一会儿卡顿，问题都不知道从哪查起。

1.1 为什么这个项目一定要用 FreeRTOS

先说一个常被误解的问题：三个传感器用裸机写个循环轮询不就行了吗？为什么非要上 RTOS？

裸机轮询确实能跑，但有一个致命痛点——响应时间和 CPU 利用率无法兼顾。温度传感器比如 DHT22 读取一次要等 100ms 级别的时序，光照传感器 BH1750 需要发送指令后等待转换，空气质量传感器 SGP30 内部算法需要周期刷新。如果串行执行，一个周期下来少说几百毫秒，而且中途任何一个传感器卡住，整个系统都跟着等。

用 FreeRTOS 的好处是每个传感器独立成一个任务，各自安排延时和调度，谁也不会阻塞谁。更重要的是，后续想扩展功能——比如加一个按键任务、加一个网络上报任务——只需要新建任务，不用改动原有的采集逻辑。项目的可维护性和可扩展性完全不在一个量级。

1.2 主控选型与开发环境

主控我选的是 STM32F103C8T6，也就是大家常说的“Blue Pill”，性价比高、资料多、CubeMX 直接支持，非常适合做这类原型验证。如果手上是 F407 或者 G0 系列，代码逻辑完全通用，只是引脚和时钟配置略有差异。

开发环境建议直接用 STM32CubeMX + Keil MDK（或者 GCC + VSCode 也行）。CubeMX 最大的优势是可以图形化配置 FreeRTOS，创建任务、队列、信号量的时候不用手动写一堆初始化代码，而且生成的代码结构清晰，对初学者极其友好。我的习惯是：硬件初始化、时钟配置、引脚复用全部在 CubeMX 里搞定，FreeRTOS 的 task、queue、semaphore 也直接在中间件配置页面添加，真正手写的只有业务逻辑。

1.3 传感器选型与数据流设计

这个项目我选了四类传感器，分别覆盖室内环境监测的核心指标：

数据流的思路很简单：每个传感器任务负责采集原始数据，把处理后的结构化数据通过队列发送给显示任务。显示任务不关心数据从哪来、怎么采，它只负责从队列里拿数据然后刷屏。这样分层带来的好处是耦合度极低——哪天你想把 DHT22 换成 SHT30，只需要改温度任务内部的驱动代码，显示任务和数据格式完全不用动。

2. FreeRTOS 任务划分与核心机制落地

这一章是整篇文章的重头戏。FreeRTOS 的移植和基础 API 就不再赘述了，重点讲在 Multisensor 项目里是怎么设计任务、怎么用队列通信、怎么处理共享资源访问的。

2.1 任务划分和优先级设计的实操经验

我最终把任务拆成了六个，见下表。任务优先级数字越小优先级越低（FreeRTOS 默认配置），这一点新手特别容易搞反。

这里说几个关键设计思路：

温湿度任务和空气质量任务的优先级定为 2 而不是更高，是因为这类传感器读取本身有硬件等待时间，不需要抢占式的高优先级。光照任务 500ms 的周期是为了让屏幕上的亮度值变化更平滑，不会出现数字跳变过快的情况。PIR 任务用 3 是因为它是事件触发型，人一进门就要立刻响应——比如点亮屏幕背光、触发报警，这种交互式需求优先级必须高于传感器轮询。

一个容易踩坑的地方：FreeRTOS 的 vTaskDelay 并不是“精确延时”。它只能保证“至少延时多少 tick”，实际唤醒时间会因为调度器和中断处理而略有偏差，这对传感器采集没影响，但如果你要做精确的 PWM 波形输出，一定要用硬件定时器而不是任务延时。

2.2 任务间通信：队列用的好，逻辑差不了

任务间数据传递我用的是 FreeRTOS 消息队列。每个传感器任务向同一个数据队列发送结构体，显示任务阻塞等待队列数据。

定义消息结构体的时候要注意内存对齐问题，尤其是结构体包含多个字段时。为了保证发送效率，我建议直接用指针传递而不是复制整个结构体——尤其是 SGP30 采集的数据包含多个浮点/整型字段，直接复制结构体会占用栈空间并增加拷贝耗时。FreeRTOS 队列支持传递指针，只需要在创建队列时把“队列项大小”设置为指针大小（4 字节）。

如果不用指针而直接用结构体发送，每发送一条消息就要做一次内存拷贝，高频采集场景下会显著增加任务切换的开销。实测在 F103 这种 Cortex-M3 上，拷贝一个 16 字节的结构体还好，但如果你后续扩展成 24 字节、32 字节，效率下降就很明显了。

2.3 用信号量保护共享资源

多任务系统绕不开“共享资源”问题——两个任务同时访问同一个变量、同一个外设。在这个项目里最典型的就是 OLED 显示屏：如果 PIR 任务检测到人之后要立刻在屏幕上显示“有人”，而温湿度任务也在往屏幕上刷新数据，两个任务同时调用 OLED 写函数，轻则画面闪烁错乱，重则 I2C 总线冲突导致死锁。

解法很简单：为 OLED 操作加一个互斥信号量（Mutex），谁拿到锁谁才有资格操作屏幕。

// 在任务中使用互斥量保护 OLED 操作 void Display_Update(DisplayData_t *data) { // 获取互斥量，带超时保护 if (xSemaphoreTake(oled_mutex, pdMS_TO_TICKS(100)) == pdTRUE) { OLED_Clear(); OLED_ShowString(0, 0, (uint8_t *)data->temp_str); OLED_ShowString(0, 2, (uint8_t *)data->humi_str); OLED_ShowString(0, 4, (uint8_t *)data->lux_str); OLED_ShowString(0, 6, (uint8_t *)data->air_str); // 释放互斥量 xSemaphoreGive(oled_mutex); } }

有一个新手常犯的错误是忘记加超时参数。直接在xSemaphoreTake(oled_mutex, portMAX_DELAY)里填最大值，一旦锁被某个卡死的任务占用，所有等待该锁的任务都会无限阻塞，整个系统直接假死。建议所有锁操作都加上超时，哪怕 100ms 也好，锁获取失败就记录下来或者跳过本次刷新，绝不能无限等下去。

2.4 软件定时器真的很好用

除了常驻任务，FreeRTOS 的软件定时器在这个项目里也派上了用场。比如“无人在房间超过 5 分钟自动关屏”这个功能，用任务来做需要自己维护一个计数变量，还要考虑睡眠唤醒的问题，不如直接用 OneShot 软件定时器：PIR 检测到人时重置定时器，定时器回调里执行关屏操作。

// 软件定时器回调函数 void AutoScreenOff_TimerCallback(TimerHandle_t xTimer) { OLED_SetDisplayState(OFF); } // 创建一次性软件定时器，5分钟后触发 TimerHandle_t screen_off_timer = xTimerCreate( "ScreenOff", pdMS_TO_TICKS(300000), pdFALSE, // 一次性定时器 (void *)0, AutoScreenOff_TimerCallback);

需要提醒的是，软件定时器回调运行在软件定时器服务任务上下文中，优先级通常较低，里面绝不能做阻塞操作。回调里只做置标志、发队列这种轻量级操作，具体关屏逻辑放到 Display 任务里处理，这样更安全。

3. 核心功能模块实现细节

架构和任务规划清楚了，代码实现其实就有章可循了。这一章把几个关键模块逐个拆开，具体讲讲每个模块的坑和细节。

3.1 温湿度采集任务：单总线时序的坑

DHT22 是单总线协议，时序要求比较严格，读取一次需要主机发起始信号然后精确延时等待响应。在裸机里这个还好说，但在 RTOS 环境下有一个非常大的隐患：任务调度器可能在延时过程中切换任务。

DHT22 的时序要求是微秒级的，而 FreeRTOS 的 tick 周期通常是 1ms（1000Hz 频率），也就是说 vTaskDelay 根本无法保证微秒级延时。如果直接在任务里用for循环做微秒延时，中途一旦被高优先级任务抢占，读到的数据大概率是错的。

解决方案有几种，按照可靠性排序：

1. 读取 DHT22 期间临时挂起调度器：vTaskSuspendAll()/xTaskResumeAll()，禁止任务切换，保证时序完整
2. 把读取操作放到中断中执行，任务只负责处理结果
3. 用定时器+DMA 方式模拟单总线时序

对于 F103 这种资源不紧张的场景，方案一最简单有效。实测在挂起调度器的情况下，DHT22 读取成功率接近 100%，不挂起的话经常出现 CRC 校验失败。

// DHT22 读取函数（核心时序部分） uint8_t DHT22_ReadData(float *temp, float *humi) { uint8_t data[5] = {0}; // 挂起调度器，避免时序被破坏 vTaskSuspendAll(); // 主机拉低起始信号 DHT22_PIN_LOW(); delay_us(1800); DHT22_PIN_HIGH(); delay_us(30); DHT22_PIN_INPUT(); // 读取 40 位数据 for (int i = 0; i < 40; i++) { while (DHT22_PIN_READ() == 0); // 等待低电平结束 delay_us(40); if (DHT22_PIN_READ() == 1) data[i / 8] |= (1 << (7 - (i % 8))); while (DHT22_PIN_READ() == 1); // 等待高电平结束 } // 恢复调度器 xTaskResumeAll(); // 校验 CRC if ((data[0] + data[1] + data[2] + data[3]) != data[4]) return 1; // 校验失败 *humi = ((data[0] << 8) | data[1]) / 10.0f; *temp = ((data[2] << 8) | data[3]) / 10.0f; return 0; }

挂起调度器期间千万不能调用任何 FreeRTOS API（除了xTaskResumeAll()），否则会触发断言。这个限制对于单传感器读取这种微秒级操作完全够用。

3.2 I2C 多设备共存：BH1750 与 SGP30 的访问策略

BH1750 和 SGP30 都挂在 I2C1 总线上，地址不同，理论上可以共存。但实际开发中有一个问题：SGP30 每次读取前需要发送 0x2008 命令触发测量，然后等待 10ms 以上才能读回数据；BH1750 发送 0x10 命令开始连续测量，也需要等待一段时间。两个设备交替访问同一个 I2C 外设，如果同步不好，总线状态可能错乱。

我的做法是给 I2C 总线也加一把互斥锁。两个传感器任务在访问 I2C 前先获取 I2C 总线锁，用完立即释放。这样做的核心思路是：尽量缩短持锁时间，防止高优先级任务被低优先级任务长期阻塞（优先级反转问题）。

// 光照传感器任务读取流程 void Sensor_Light_Task(void *arg) { uint16_t lux = 0; SensorData_t data; for (;;) { // 获取 I2C 总线锁 if (xSemaphoreTake(i2c_mutex, pdMS_TO_TICKS(50)) == pdTRUE) { BH1750_ReadLux(&lux); xSemaphoreGive(i2c_mutex); // 发送到显示队列 data.type = TYPE_LUX; data.value = lux; xQueueSend(data_queue, &data, 0); } vTaskDelay(pdMS_TO_TICKS(500)); } }

这种短锁设计还需要考虑优先级反转问题。假如低优先级的空气质量任务拿到了 I2C 锁，高优先级的光照任务想获取锁时会被阻塞，而中优先级任务（比如 PIR）此时如果抢占 CPU，就会让低优先级任务迟迟不能释放锁，高优先级任务就无限等下去。FreeRTOS 的互斥量自带优先级继承机制，能自动提升持有锁的低优先级任务优先级，所以创建 I2C 总线锁时一定要用互斥量（Mutex）而不是二值信号量（Binary Semaphore），否则优先级反转问题会非常棘手。

3.3 显示任务的阻塞式消费模式

显示任务的设计采用了“纯阻塞”模式——没有周期性延时，所有执行节奏由队列消息驱动。

void Display_Task(void *arg) { SensorData_t data; for (;;) { // 阻塞等待队列消息，最长等待时间不限 if (xQueueReceive(data_queue, &data, portMAX_DELAY) == pdTRUE) { // 根据数据类型更新对应屏幕区域 if (xSemaphoreTake(oled_mutex, pdMS_TO_TICKS(100)) == pdTRUE) { switch (data.type) { case TYPE_TEMP: sprintf(temp_str, "Temp:%d.%d C", data.temp_int, data.temp_dec); OLED_ShowString(0, 0, temp_str); break; case TYPE_HUMI: sprintf(humi_str, "Humi:%d.%d %%", data.humi_int, data.humi_dec); OLED_ShowString(0, 2, humi_str); break; case TYPE_LUX: sprintf(lux_str, "Lux:%d", (int)data.value); OLED_ShowString(0, 4, lux_str); break; case TYPE_TVOC: sprintf(air_str, "TVOC:%d ppb", (int)data.value); OLED_ShowString(0, 6, air_str); break; default: break; } xSemaphoreGive(oled_mutex); } } } }

这个模式下 CPU 占用率几乎为零——任务没有消息时一直处于阻塞态，不消耗 CPU 时间。这也是 FreeRTOS 相比裸机轮询的又一个优势：裸机里你得定时刷新屏幕，哪怕数据没变化也要白白耗电；FreeRTOS 里队列没消息就不跑，省电又高效。

3.4 数据存储：如何优雅地落盘

存储任务负责把每小时的平均温湿度写入 Flash。这里有一个很实际的问题：STM32F103 内部 Flash 的擦写寿命约 1 万次，如果你每分钟写一次，不到一周 Flash 就报废了。所以存储逻辑必须做好两点：

• 只保存聚合数据而不是原始数据（10 分钟或者 1 小时算一次平均）
• 写入次数做磨损均衡，不要每次都写同一片扇区

我用了最简单的方案：固定 8 个扇区轮询写入。每次写入前读一个偏移指针，指针指向当前可用扇区，写满后递增，超过 8 就回卷到 0，同时在内存里维护当前轮询位置。这样可以保证每个扇区的擦写频率平均化，有效延长 Flash 寿命。

4. FreeRTOS 内存与堆栈管理：最容易翻车的部分

如果说任务划分是 FreeRTOS 开发的地基，那堆栈大小和内存管理就是随时可能爆的雷。我见过太多人写 FreeRTOS 项目跑着跑着突然 HardFault，一查全是堆栈溢出。这里把我自己的排查方法和参数配置经验完整分享一下。

4.1 FreeRTOS 堆栈大小到底怎么定

先解释一个基础概念：FreeRTOS 中每个任务都有自己的栈空间，这段空间既存放局部变量、函数调用返回地址，也存放中断嵌套时的上下文。任务切换时 CPU 寄存器现场会压栈，中断发生时也要压栈，所以堆栈太小必然导致溢出。

很多人问“堆栈大小设为多少合适”，这个没有标准答案，只能通过测量来确定。我给的参考起始值是：

空气质量任务我给 512 是因为 SGP30 驱动里包含了 CRC 校验和浮点运算，浮点库函数调用会占用较多栈空间。如果在 Keil 里开了微库优化，可以适当缩减；用 GCC 默认 math 库的话建议宁大勿小。

一个很有效的判断方法：把configMINIMAL_STACK_SIZE默认设为 128，先跑 24 小时，如果系统稳定不死机，再逐步减少堆栈大小直到临界值，最终设定值取临界值的 1.5 倍。这种“由大到小压测”的方式比拍脑袋定值靠谱得多。

4.2 堆栈溢出检测的三板斧

FreeRTOS 内置了堆栈溢出检测机制，在FreeRTOSConfig.h中配置configCHECK_FOR_STACK_OVERFLOW，可选值为 1 或 2。建议直接用 2，检测更严密。

方法一：启用内置钩子函数

void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { // 进入这里说明某个任务堆栈溢出 // 记录任务名到全局变量，方便调试 sprintf(debug_info, "Stack Overflow: %s", pcTaskName); // 点亮一个 LED 或进入错误处理循环 Error_Handler(); }

方法二：查看任务高水位线（High Water Mark）。FreeRTOS 提供uxTaskGetStackHighWaterMark()API，返回该任务从创建以来堆栈剩余的最小空间，单位是字。定期在任务里调用这个函数，打印剩余量，如果剩余量持续偏低（比如小于 64 字），就应该加大堆栈。

方法三：用 MPU 或硬件 fault 定位。如果项目跑在支持 MPU 的芯片上（比如 Cortex-M7），可以配置内存保护区域，溢出时直接触发 MemManage Fault。这个配置稍微复杂一些，但定位问题非常精准。

实际项目里我发现一个很有意思的现象：堆栈溢出往往不发生在任务正常运行路径上，而是发生在中断嵌套最深的瞬间。比如系统 tick 中断正在处理，此时来了 I2C 中断，两个中断嵌套会把栈空间消耗到峰值。所以测堆栈用量时一定要在系统繁忙、中断频繁的情况下测，模拟真实负载。

4.3 堆内存分配：heap 大小与内存碎片

FreeRTOS 的configTOTAL_HEAP_SIZE决定所有任务栈、队列、信号量等内核对象可使用的总内存。在 STM32F103C8T6 上，我建议设置为 10-15KB，具体取决于任务数量和堆栈大小。

FreeRTOS 提供了 5 种 heap 实现方案，区别如下：

Multisensor 项目建议直接使用 heap_4，原因很简单：如果你后续想实现“采集任务动态创建/销毁”的功能，或者有临时队列需要删除重建，heap_4 可以回收内存再合并相邻空闲块，不容易碎片化。heap_1 虽然简单可靠，但一旦任务销毁后内存就永久泄漏，不适合这个场景。

4.4 一个排查内存问题的真实案例

我有一次在项目里遇到一个诡异问题：系统运行几个小时后偶尔出现显示错乱，重启后恢复正常。查了两天都没找到原因，最后用高水位线函数逐个任务打印剩余栈空间，发现显示任务的栈剩余量在运行 3 小时后从 400 字掉到了不足 80 字。

进一步查看代码，发现我在显示任务里定义了一个大的局部数组char temp_str[128]，还调用了sprintf做格式化，而sprintf是出了名的栈空间消耗大户。排查后我把局部数组改为全局静态变量，同时用snprintf限定长度，然后把显示任务堆栈从 512 字增加到 768 字，问题彻底消失。

这个案例想说明两件事：第一，打印格式化尽量用全局缓冲区，不要大数组直接定义在任务里；第二，堆栈参数的验证不能靠感觉，要跑足够长时间并采集高水位线数据。

5. 项目调试、运行效果与常见问题排查

代码写完了，不是烧录进去就万事大吉。这一章分享几个我在调试这个项目时遇到的典型问题和最终的解决思路，相当于一份可以直接对照排查的坑位清单。

5.1 任务跑飞与调度异常的排查思路

现象：系统运行一段时间后全部任务停止响应，调试器暂停查看当前任务的 PC 指针，发现停在某个硬错误中断里。

排查步骤：

1. 首先检查是不是堆栈溢出，使用上面讲的高水位线法逐一排查
2. 如果堆栈正常，查看当前执行上下文，定位到出错的源文件行号
3. 检查是否有优先级反转导致死锁——特别是用了信号量但没加超时的情况
4. 检查是否有中断服务函数调用了 FreeRTOS API。ISR 中只能调用带FromISR后缀的 API，否则会破坏临界区嵌套计数，导致调度器状态错乱

这个项目里最容易踩的就是第 4 点。我有一次在定时器中断里直接调用了xQueueSend（不带 FromISR），系统频繁死机。改成了xQueueSendFromISR并检查返回值之后立即恢复稳定。

5.2 传感器数据偶发错误：优先级与延时的博弈

现象：DHT22 偶尔读到 255.5 这种典型错误值，或者温度跳变十几度，但是重启后又能恢复正常。

这个问题的根因我在 3.1 节提到过：单总线时序被任务调度打断。除了挂起调度器之外，还有一个更隐蔽的原因——空气质量的 I2C 任务如果和 DHT22 任务同时被唤醒，I2C 中断会抢占 CPU 并延迟 DHT22 的时序。解决办法除了挂起调度器，还可以把 DHT22 的读取延后到光照和空气质量任务完全处于阻塞期时执行。调整任务相位，让三个采集任务不在同一时刻被唤醒，数据错误率能大幅下降。

一个简单可行的相位调整方法：在vTaskDelayUntil的起始 tick 基础上加一个偏移，每个任务的偏移量不同，错开采集峰。

// 使用 vTaskDelayUntil 配合偏移量控制任务相位 TickType_t xLastWakeTime = xTaskGetTickCount(); const TickType_t xFrequency = pdMS_TO_TICKS(2000); const TickType_t xPhaseOffset = pdMS_TO_TICKS(300); // 300ms 相位偏移 for (;;) { vTaskDelayUntil(&xLastWakeTime, xFrequency); // 在相位偏移处开始采集 vTaskDelay(xPhaseOffset); // 执行 DHT22 读取 DHT22_ReadData(&temp, &humi); // 发送数据 }

注意vTaskDelayUntil的节奏控制，加上偏移后实际周期依然是 2s，不会发生漂移。

5.3 用户态可见的“延迟卡顿”：显示任务饥饿怎么办

现象：屏幕刷新偶尔卡住，人体感应触发的“亮屏”动作有明显延迟。

排查之后发现是高优先级 PIR 任务频繁抢占导致低优先级显示任务饿死，再加上互斥量竞争，显示任务拿不到 OLED 锁就只能干等。

解决办法三个方向：

• 给显示任务合适的优先级，不要低于所有传感器任务，至少设为 2
• 互斥量超时时间不宜太长，取 100ms 左右，拿不到锁就先返回，不要阻塞整个任务
• 全项目只保留一个 OLED 操作入口，统一由显示任务处理，PIR 任务要显示内容时不要直接操作屏幕，而是通过事件标志组（Event Group）通知显示任务

事件标志组的用法也很简单：

// PIR 任务中设置事件位 xEventGroupSetBits(event_group, EVENT_PIR_TRIGGERED); // 显示任务中等待事件位 EventBits_t bits = xEventGroupWaitBits( event_group, EVENT_PIR_TRIGGERED, pdTRUE, // 清除标志位 pdFALSE, pdMS_TO_TICKS(1000));

这种设计让屏幕控制权完全统一，从根源上避免了多任务并发写 OLED 的问题。

5.4 常见问题速查表

5.5 实测数据与运行状态

我实际跑下来的数据是这样的：系统 3.3V 供电，四个传感器加上一块 0.96 寸 OLED，常态电流约 45mA。待机模式下（屏幕关闭、传感器周期拉长到 10s），电流可以降到 12mA 左右。CPU 占用率用vTaskGetRunTimeStats()统计下来，显示任务和处理任务不到 5%，大部分时间所有任务都在阻塞等待。

帧率方面，OLED 刷新一屏大约 15ms，但因为有互斥锁保护，即使读取任务频繁，也没有出现撕裂或闪烁。

任务调度器稳定运行 72 小时无死机、无数据丢失。这个稳定性数据在裸机轮询方案里很难达到——裸机一旦某个传感器驱动卡死，整个循环就断了；FreeRTOS 下最多是这个传感器任务超时，其他任务照常运转。

6. 后续扩展方向

这个项目做完之后，要扩展的方向其实非常多。比如：

• 把显示换成一个 TFT LCD 屏幕，再引入 LVGL 图形库，你会发现 FreeRTOS 和 LVGL 之间存在一个 tick 心跳对接的问题，这是做 GUI 移植时必踩的坑
• 加一个 Wi-Fi 模组（ESP8266/ESP32），把采集数据通过 MQTT 上报到服务器，需要新增一个网络任务，还要考虑网络阻塞对 RTOS 调度的影响——这种情况下网络任务应放在独立的高优先级任务里，并且绝不能阻塞其他传感器任务
• 加一个按键输入：按下息屏、长按配置 Wi-Fi 等，按键消抖逻辑放在哪个任务、和 PIR 任务是否有冲突，都要重新梳理

我个人在实际开发中最深刻的体会是：FreeRTOS 本身不难，难的是用 RTOS 的思维去重新审视原本裸机时代的代码结构。裸机里你操心的是“下一步做什么”，RTOS 里你操心的是“每个任务什么时候能做、做了会不会抢别人”。从裸机到 RTOS，最难的不是学会那几个 API，而是学会任务拆分和资源分配。

另外再分享一个小技巧：调试期务必打开configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS，用vTaskGetRunTimeStats()打印各个任务的 CPU 占用率。这个数据能帮你在性能优化时做出正确的判断——到底瓶颈在传感器等待、还是锁竞争、还是堆栈过大导致的换页开销。

这个项目整体下来，一两个晚上的工作量就能跑通基础版本，但把细节抠到稳定，是很值得花时间的。动手试试看，遇到具体问题再逐个查。