企业官网建设流程全解析

1. 项目定位：这个多传感器盒子到底解决什么问题

1.1 “Real-Time”不等于“快”，而是一种可以量化的确定性

最近在做的一个小项目 Real-Time FreeRTOS Room Multisensor，是一个放在房间角落的小盒子，按固定周期采集温度、湿度、光照、PM2.5、TVOC 和人体存在，并把结果实时送到屏幕显示、按需要上报。整个系统跑在 STM32F407 加 FreeRTOS 上，标题里的 Real-Time 不是指代码写得快，而是指每一步触发到响应的延迟都是可量化的、可控的。对想从裸机 while(1) 升级到 RTOS，或者想把多个传感器任务组织成一套稳定系统的嵌入式开发者，这篇内容应该能帮你在搭架构和踩坑时少走弯路。

很多新手拿到多传感器项目，第一反应是把所有传感器都丢进一个大循环，挨个查询，再花时间去处理异常。一开始数据不多可能没问题，等到传感器从三四个增加到六七个，又要加显示、加网络上报，循环体里每执行一次，最末端传感器被响应的间隔就被拉长，而且这个“拉长”是不可预测的。FreeRTOS 做的事情，就是把这些周期不同的采集、处理和输出拆成一个个独立任务，让每个任务在自己的优先级和时间约束下运行。所谓实时性，就是无论系统同时都忙，某个房间里最重要的触发（比如人经过、空气质量超标）也能在最坏情况下于规定时间内得到响应，而不是看运气。

我在做这个项目时，给自己定的响应指标是：从 PIR 人体传感器检测到变化，到任务真正读取电平并触发 LED/蜂鸣器联动，端到端延迟不超过 50ms；从 PM2.5 的串口收到一帧数据，到解析结果被聚合任务使用，延迟不超过 100ms。这些指标并不高，但如果架构混乱，中断里堆逻辑、低优先级任务里做长时间 I2C 等待，很容易就超出目标。FreeRTOS 的价值正是在这种“多个延迟目标共存”的场景里体现出来的。

1.2 为什么用 FreeRTOS 而不是裸机轮询

裸机轮询不是不能用，我以前也拿大循环写过不少传感读取程序。核心问题是当任务变多，资源共享变复杂时，业务之间互相干扰会变得非常难控制。比如一次 I2C 读取要等待几百微秒，DHT22 的单总线时序又要求严格的时间窗口，这两类操作放在同一个循环里轮流执行，互相打断是必然的。FreeRTOS 让每个传感器任务可以独立阻塞（等待自己的时钟或事件），不会把时间片浪费在无关的查询上，任务间用队列、事件组传递数据，时序上也相对独立。

当然我也不是劝所有人都上 RTOS。如果整套系统只有一两个传感器，输出就是点个灯，那用裸机 while 循环加状态机反而更简洁，代码体积也小。FreeRTOS 带来的收益来自“多路并发”和“资源复用”——多个传感器有各自的采样周期，显示任务要刷新屏幕，通信任务要处理网络协议，这时候如果全部挤在一个循环里，代码会越来越难维护，稍微加一个功能就可能殃及其他模块。

再说一个项目上用 FreeRTOS 的隐性好处：可以配合 STM32CubeMX 直接生成工程配置，把时钟、外设初始化、任务创建都通过图形化方式完成，我实际开发时不太需要手写底层 port 文件。Cortex-M 内核的 tick 和调度逻辑已经被官方移植得很稳定，重点可以放在业务任务拆分上，而不是操作系统本身。项目做完后，也方便换 STM32L4 这类低功耗芯片继续演进，FreeRTOS 移植成本非常低。

2. 硬件选型：先别急着买板子，把传感器接口和总线规划好

2.1 房间级多传感器怎么选，我列了一份参考清单

做这类项目，传感器的接口类型直接决定后续代码架构，所以我会在买零件前先画一张表，把每颗传感器用哪种接口、大概什么采样周期、有哪些外围要求都列清楚。下面是我最终选用的组合，覆盖了房间环境监测最常见的几个维度。

之所以没有继续用 DHT22，是因为它用的是单总线协议，时序极敏感，任务调度一抖动就容易读错数据。BME280 走 I2C，在 FreeRTOS 环境里可以用互斥量保护总线访问，稳定性和代码复杂度都快很多。光照和空气质量传感器也都选择 I2C 接口，这样整条 I2C 总线统一管理，减少任务切换带来的时序冲突。

如果你预算或者采购渠道受限，也可以做组合替换：用 DHT22 替代 BME280，PM2.5 换成夏普 GP2Y1010 模拟输出走 ADC，但代码里就要额外处理单总线和 ADC 采样的抖动，工作量会大不少。我的建议是，除非你只想做最小验证板，否则多花几十块把传感器统一到 I2C/UART 上，后面写代码会顺畅得多。

2.2 总线资源与中断资源分配

我用的主控是 STM32F407VET6，Flash 512KB，RAM 192KB，跑 FreeRTOS 加三四组任务绰绰有余。硬件上我把 I2C1 作为传感器总线，挂 BME280、BH1750、SGP30；UART4 接 PMS7003；一个 GPIO 接 PIR 的 OUT 引脚；另一个 GPIO 接 LED 和蜂鸣器用于联动演示。这样各外设之间不共享中断线，排查问题时会省去很多麻烦。

有一个很容易被忽略的点：I2C 总线上挂三个传感器，每个传感器核心电压附近都要加 100nF 去耦电容，总线本身也要有上拉电阻。STM32 内部虽然可以开启 I2C 上拉，但驱动能力有限，我的板子外置了 4.7k 上拉到 3.3V，实测通信非常稳定。多个 I2C 设备的地址一定要提前确认，BME280 的 ADDR 引脚如果接 VCC 会变成 0x77，BH1750 的 ADDR 引脚决定地址是 0x23 还是 0x5C。如果三个设备地址冲突，系统会出现间歇性错误，排查起来很考验耐心。

PMS7003 是 5V 供电，数据输出引脚电平文档上写的是 3.3V 兼容，但我实际用示波器量过，某些批次高电平接近 3.7V 左右，直接接到了 STM32 的 RX 引脚短期没问题，长期还是建议加个电平转换或者串一个 1k 电阻做保护。PIR 模块输出一般是 3.3V 或者 5V 跳线可选，务必在接线前确认，我因为这个原因烧掉过一个 IO 口，后来所有数字传感器输入都养成了先看电平再接线的习惯。

2.3 供电和布局的几个细节

房间多传感器设备通常要 7×24 小时运行，供电稳定性比性能更重要。我的方案是 5V 适配器进板，先经过一个低压差 LDO 稳压到 3.3V，给 MCU、I2C 传感器和 ESP8266 供电；PMS7003 使用 5V 供电，但在启动瞬间电流峰值较高，我在它的电源引脚旁边并了两个 220uF 电解电容，实测不会影响其他传感器。若用单个 AMS1117 给所有外设供电，建议算一下总电流余量，避免电压跌落导致 WiFi 模块反复重启。

传感器布局上，SGP30 和 BME280 尽量远离板载稳压芯片和 WiFi 模块，因为热源会干扰温度测量。PMS7003 是风扇主动吸入空气，要保证风道附近没有遮挡，同时避免风扇振动传导到 PCB 上的其他传感器。这些都是“看起来不影响功能、实际影响数据质量”的细节，房间级监测设备对温度绝对值和 PM2.5 数值的长期稳定性要求比较高，踩过一次坑就很难忘。

3. FreeRTOS 任务划分：像分部门一样把活拆开

3.1 任务边界怎么画才合理

任务划分是整个项目里最影响成败的环节。我的原则很简单：按“响应紧急程度”和“采样频率”两个维度拆，而不是按传感器数量硬拆。PIR 是事件型，必须最快速地感知并处处理；BME280、BH1750、SGP30 都属于周期性慢速采样，凑在一起用一个采集任务反而容易管理；PMS7003 一直通过串口往上发数据，需要专门的解析任务负责拆包校验。

UART 接收中断和定时器中断都属于高优先级的中断服务函数，里面只做数据接收、标记和通知，实际的协议解析放到任务里做。这样一个 PIR 中断来了，ISR 立即唤醒一个高优先级任务去处理；传感器周期到了，定时器回调里唤醒采集任务，再由采集任务统一发出读数。任务数量控制住，每个任务的栈空间、优先级和生命周期才清晰。

很多教程喜欢给每个传感器建一个独立任务。这个方法不是不行，但每个任务意味着至少 256~512 字的栈空间，再加上可能需要的互斥量管理，最后系统复杂度和内存开销都上去了。我在这个项目里把三个 I2C 传感器放进同一个 sensor_mgr 任务，按 tick 计数器的相位错开读取时间，整个代码比三个独立任务简洁得多，而且天然避免了 I2C 总线竞争。

3.2 我实际使用的任务优先级与栈大小

下面这张表是我调试稳定后最终保留的任务配置。注意 FreeRTOS 里数字越大优先级越高，这与一些人习惯的“数值越大越低”相反，我第一次移植时刚好搞反了，结果人体感应一直响应慢半拍。

irq_handler 最高优先级，但它执行体很短，只是读取 PIR 状态，通过任务通知让 data_agg 或者联动逻辑响应。sensor_mgr 在第二优先级，它负责等待周期消息并读取 I2C 传感器，不会长时间阻塞更高优先级的 PIR 响应。net_task 放在最低优先级，因为网络上报本来就是可容忍延迟的操作，即使被传感器采集任务抢占，也不会造成恶劣影响。

实际调试时，我把 ui_task 的刷新频率从 100ms 降到 50ms 后，发现 OLED 显示变得非常消耗 CPU，PMS7003 的串口解析出现丢帧。原因很简单，UI 刷新虽然优先级不高，但占用 CPU 时间太长，导致低优先级任务频繁饿死。后来把刷新频率改回 100ms，并在 ui_task 里做了脏标记判断，只有数据变化时才真正更新屏幕，问题自然消失。任务频率不是越快越好，而是要根据系统余量选择合适值。

3.3 任务栈大小：很多人第一步就写错

FreeRTOS 创建任务时，xTaskCreate的usStackDepth参数单位是“word”，在 Cortex-M4 上每个 word 是 4 字节。我见过不少新手直接写usStackDepth = 1024，以为是 1024 字节，实际上分配了 4KB 栈空间，大量 RAM 被白占。反过来也会有人把usStackDepth = 128当 128 字节，结果任务一调用复杂库函数就栈溢出。

STM32F407 的 RAM 虽然足够大，但嵌入式设备的内存规划不能凭空拍脑袋。我建议所有任务初始都设置成 256 word 起步，跑一段实际业务后用uxTaskGetStackHighWaterMark查看剩余栈空间，再统一削减或增加。如果某个任务里要调用printf之类可变参数打印，栈需求至少会膨胀到 512 word 以上，这也是我把调试打印统一放到一个独立的串口输出任务里的原因。

为了在开发期就抓住栈溢出问题，一定要把configCHECK_FOR_STACK_OVERFLOW设为 2，并实现vApplicationStackOverflowHook钩子函数，在栈溢出时打点保存现场。实测下来，栈溢出往往表现为系统随机重启、数据经常错乱，如果没有钩子，排查这类问题能让人崩溃。等到项目稳定后再把这个选项关掉，还能省掉一点点运行开销。

4. 核心代码实现：从传感器到事件队列的实时通路

4.1 中断处理与事件通知：PIR 人体感应

PIR 是典型的事件型传感器，不能靠轮询。我选择在 GPIO 外部中断回调里做一次快速状态读取，然后通过 FreeRTOS 任务通知唤醒联动任务。任务通知比二值信号量更轻量，正好适合这种“一个 ISR 通知一个任务”的场景。下面是简化后的示例流程。

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; if (GPIO_Pin == PIR_PIN) { uint32_t level = HAL_GPIO_ReadPin(PIR_PORT, PIR_PIN); vTaskNotifyGiveFromISR(irq_task_handle, &xHigherPriorityTaskWoken); } portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

在irq_handler任务里，通过ulTaskNotifyTake(pdTRUE, portMAX_DELAY)等待通知。收到通知后根据 PIR 当前电平和时间窗口判断是“有人进入”还是“有人离开”，进而控制 LED 和联动逻辑。这样设计后，ISR 只做几行赋值和通知，不会因为业务复杂而出现中断延迟过大的问题。

这里要额外提醒：GPIO 外部中断回调里避免调用 HAL_Delay 或者长时间执行的库函数。PIR 信号本身会有一些抖动，处理抖动的逻辑应该放在任务里，而不是在中断里用 busy wait 过滤。我在早期版本里尝试过在中断里延时 10ms 去抖，结果系统整个调度周期都被拖乱了，后来改成任务内延后判断，效果反而更稳定。

4.2 I2C 传感器批量采集：用一个任务独占总线

三个 I2C 传感器挂同一条总线上，如果每个传感器都由独立任务去读取，就必须加互斥量；但加互斥量本身又可能引发优先级反转问题。我的做法是让 sensor_mgr 任务独占 I2C 总线，在 10ms tick 调度里维护每个传感器各自的“下次读取时间”字段，到点再读取。

typedef struct { uint32_t next_read_tick; uint16_t sample_interval; // 单位: tick int32_t value; } sensor_slot_t; void sensor_mgr_task(void *arg) { sensor_slot_t bme = {0, 100, 0}; sensor_slot_t bh1750 = {0, 200, 0}; sensor_slot_t sgp30 = {0, 100, 0}; while (1) { uint32_t now = xTaskGetTickCount(); if (now >= bme.next_read_tick) { bme.value = bme280_read_all(); bme.next_read_tick = now + bme.sample_interval; } if (now >= bh1750.next_read_tick) { bh1750.value = bh1750_read_lux(); bh1750.next_read_tick = now + bh1750.sample_interval; } if (now >= sgp30.next_read_tick) { sgp30.value = sgp30_read_tvoc(); sgp30.next_read_tick = now + sgp30.sample_interval; } vTaskDelay(10); } }

这段代码把 I2C 读取均匀地分布在不同的时间相位里，避免三个传感器同时读取、总线拥堵。实际效率很高，而且完全不需要互斥量，因为同一时刻只有一个任务访问 I2C。测量结果保存在结构体里，聚合任务通过访问全局快照获取最新值即可。

如果以后要增加新的 I2C 传感器，只需要在传感器槽位表里加一行，把读取函数挂进去，sensor_mgr 主体逻辑无需改动。这种可扩展性正是把传感器抽象成“槽位”的收益。代码里没有把每个结果单独通过队列发出去，因为 I2C 传感器采样频率不高，直接共享最新值反而更合理，少了队列内存和消息复制开销。

4.3 UART 接收 PMS7003：DMA 空闲中断拆包

PMS7003 持续通过串口发送二进制帧，每帧 32 字节，包含帧头、PM2.5、PM10 和校验和。如果直接在中断里一个字节一个字节收，很占 CPU 而且容易丢帧。我采用 UART DMA 接收，配合串口空闲中断判断一帧结束，再由 pm_parser 任务解析。

核心思路是开一个大缓冲区，DMA 收到数据后不断填充；当串口总线空闲超过一定时间，就认为当前这一包数据已经收完，触发一次解析。解析时从缓冲区内查找帧头0x42 0x4D，校验帧长和校验和，然后提取 PM2.5 值。因为解析任务优先级低于 PIR 中断和 sensor_mgr，不会影响更紧急的响应。

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart->Instance == UART4) { pms_frame_ready = true; pms_frame_len = Size; xTaskNotifyGive(pm_parser_task_handle); } }

DMA 接收的好处是 MCU 不需要在每字节到达时被打断，空闲中断方式又能从硬件层面判断“一条完整消息结束”。需要注意，DMA 缓冲区如果被长时间用完而没有及时处理，数据会覆盖，因此 pm_parser 任务必须保持足够高的执行频率。实测 PMS7003 每帧间隔约 200~300ms，留给任务处理的时间窗口非常宽裕，丢包概率很低。

如果手头的芯片串口不够或者不想用 DMA，也可以用逐字节中断加状态机解析。但那样中断频率高，且随时被打断会影响 I2C 时序，我还是建议优先 DMA。对 FreeRTOS 来说，中断越少，调度器控制权越强，系统实时性越好——这也是“实时”在工程实现上的具体体现。

4.4 数据聚合与对外发布

各个传感器把数据准备好之后，需要有一个统一的数据快照结构体，方便 UI 和网络任务取用。我定义了RoomSnapshot，包含时间戳、温度、湿度、气压、光照、PM2.5、TVOC、人体状态等字段。data_agg 任务在收到“传感器数据已更新”的事件组标志后，重新计算一段时间内的均值并更新快照，然后用事件组通知 ui_task 和 net_task。

使用 FreeRTOS 事件组的原因是可以同时等待多个条件：只有当“至少一个数据源更新”和“距离上次发布达到一定时间”同时满足时，才触发对外发布。这样网络任务不会因为每次都发一条孤零零的数据而被占频，也不会漏掉关键更新。事件组的操作是位级别的，速度快，非常适合这种“多个条件达成后执行一次动作”的模式。

实际遇到过一个问题：多个任务同时访问RoomSnapshot导致读到的数据“半新半旧”。解决方法是把快照更新放进短临界区，或者直接用一个 FreeRTOS 互斥量保护读取。因为快照很小，短临界区更轻量，我用taskENTER_CRITICAL()/taskEXIT_CRITICAL()包裹了复制和更新，实测不会产生明显调度延迟。

5. 低功耗与睡眠：多传感器房间设备最难的一环

5.1 FreeRTOS tickless 空闲模式

房间设备如果一直满速运行，风扇和传感器都耗电，长时间挂着并不划算。FreeRTOS 支持 tickless 模式，也就是当所有任务都阻塞时，系统不再产生周期性的 tick 中断，而是让 MCU 进入低功耗状态，直到下一个定时器事件触发。

configUSE_TICKLESS_IDLE开启后，还需要实现portSUPPRESS_TICKS_AND_SLEEP这个底层函数。在 STM32 上可以简单调用 HAL 库的停止模式，但要注意唤醒后系统 tick 要重新同步，否则任务延时会出现漂移。我不推荐对 FreeRTOS 还不熟悉的人一开始就开 tickless，因为调试难度会明显上升：任务明明应该 1 秒执行一次，结果睡眠唤醒后可能变成 1.2 秒一次，而且不好复现。

我的折中方案是先在调试阶段关闭 tickless，等所有功能稳定后再开启，并把传感器采样周期设计得比较整齐，保证唤醒次数不会太多。最后实测一个 5V 供电的板子待机电流从 80mA 降到 50mA 左右，具体功耗还取决于 LDO 静态电流和传感器自身耗电，不能只靠 MCU 省电。

5.2 WiFi 模块休眠策略

我在这套系统里加了一个 ESP8266 模块做 MQTT 上报，这也是很多做物联网网关的人会遇到的场景。ESP8266 如果一直保持透传模式，功耗和发热都不低，而且会抢占串口资源；如果让它进入 deep sleep，唤醒时间又需要一两秒，不适合每次传感器更新都上报。

我的策略是积攒 10 组数据，每 30 秒或 1 分钟上报一次。平时让 ESP8266 处于 Modem-Sleep 模式，CPU 不主动收数据，仅维持 TCP 连接；需要上报时再发 AT 指令切换透传。要注意 ESP8266 使用的串口和 PMS7003 最好不要用同一个物理 UART，否则两个外设数据会互相干扰。如果串口资源不够，可以用软件串口，但稳定性差一些，建议用带多路 UART 的芯片。

WiFi 上报任务是所有任务里优先级最低的，因为网络拥塞或延迟不会影响本地传感器采集。唯二要小心的是，ESP8266 启动时可能瞬间拉低电源电压，如果前面供电设计余量不足，会导致整板复位。我在 ESP8266 的电源并联了大容量电容，并且用独立 LDO 给 WiFi 供电，实测系统运行期间没有再出现无故重启。

5.3 Flash 写入与任务抢占的冲突

房间设备经常要保存校准参数、开关机状态、传感器偏置等。很多开发者以为HAL_FLASH_Program只是简单的写操作，但在 FreeRTOS 环境下，Flash 写操作可能被高优先级任务打断，导致写入半成品或者损坏参数区。搜索热词里有“stm32 freertos flash写入被打断”，说明这是个高频问题。

我踩过一次：设备运行中通过 WiFi 收到远程配置，写 Flash 保存时正好 PIR 中断来了，高优先级任务在写 Flash 期间抢占 CPU，Flash 控制器状态被破坏，整个参数区读出来全是错误。后来我改成用一个专门“存储任务”，只有它才调用 Flash 驱动，写操作前关中断，写完后做 CRC 校验，再通过队列把结果告诉上层。任何任务要保存参数，只能发消息给存储任务，不能直接调 HAL 写 Flash。

还要注意 Flash 擦写次数寿命。房间设备长期运行，如果每小时至少写一次参数，几年下来就可能接近 STM32 内置 Flash 的擦写上限。我的做法是把参数写入频率降到最低，并且只写变化的部分，数据开头加版本号和 CRC。如果项目对持久化要求很高，建议外接 SPI Flash 或者 EEPROM，没必要消耗主控的片上 Flash 寿命。

6. 实测遇到的问题与解决思路

6.1 堆栈溢出表现为随机重启

项目调试到中期，系统时不时出现重启，而且是完全随机的那种。最初我以为传感器硬件问题，后来把所有外设断开只跑 FreeRTOS 任务，重启现象依旧。打开堆栈溢出检测钩子后，发现是ui_task的栈设置偏小。

罪魁祸首是在 UI 任务里用了一个带格式化的snprintf拼接显示字符串，比较复杂，栈瞬间增长。我将ui_task栈从 256 调整为 512 word 之后，连续跑了一周再没出现随机重启。这里分享一个经验：凡是涉及格式化字符串、浮点数打印、文件系统操作的任务，栈空间至少预留 512 word；测试时再用高水位检测函数确认实际峰值，保留 30% 余量。

开发期我把configCHECK_FOR_STACK_OVERFLOW设为 2，钩子里把出错任务名和当前剩余栈值打印出来，非常直观。上线版本再把检测关掉，换来微小的性能提升。遇到随机复位时，除了看硬件，第一步一定要开栈溢出检测，这一步能过滤掉大半的“灵异事件”。

6.2 DHT22 单总线时序被中断打乱

我在设计初期为了省事选过 DHT22，结果发现它的单总线时序对中断敏感得离谱。只要 PIR 中断或者串口 DMA 中断在 DHT22 读时序中间插一脚，读出的数据就会出现偶发跳变。FreeRTOS 环境下任务调度是不可完全预知的，因此这类由严格时序驱动的单总线传感器非常不友好。

解决方案有两个：一个是在读取 DHT22 期间用taskENTER_CRITICAL()关闭中断，但临界区不能待太久，所以还得把读取代码压缩到极致；另一个是直接换 I2C 接口的 BME280，省去时序麻烦，同时还能获得气压数据。我后来选了第二方案，项目稳定性一次性到位。如果你的硬件已经固定用 DHT22，我建议在读取时对总线做临界区保护，并且把 DHT22 采集放到一个独立的高优先级短任务里，降低被调度器打乱时序的概率。

还要提一个隐蔽问题：DHT22 上电后第一次读取经常超时或返回固定错误值。很多代码在初始化阶段就疯狂重读，导致任务被阻塞很久。正确做法是上电后等 1~2 秒再读，读失败就视为无效数据，而不是在任务里忙等重试。

6.3 I2C 总线被多个任务并发访问导致锁死

早期版本里我尝试过给每个传感器各自开一个任务，每个任务读取自己的传感器，I2C 总线由互斥量保护。结果系统在频繁运行 20~30 个小时后会出现一次“卡死”，所有任务都不动了，看门狗却没有复位。

原因在于互斥量虽然避免了并发访问，但中途一个任务持锁后调用延时，另一个更高优先级任务又去申请同一把锁，出现优先级继承链过长的情况，再叠加日志打印阻塞，最终陷入不可控状态。解决办法有两个方向：一是用FreeRTOS互斥量自带优先级继承的特性来缓解反转，二是根本不让多个任务同时访问 I2C。我选择了后者，把 I2C 读取全收敛到 sensor_mgr 任务里，彻底消灭总线竞争。

如果你必须要多个任务读 I2C，请记住：任何持锁期间都不能做长延时、不能调用可能阻塞的库函数、不能直接printf。持锁时间应压缩到几百微秒到几毫秒级别。互斥量能解决一部分问题，但最佳策略是“共享外设只有一个管理者”。

6.4 PIR 人体传感器误触发与去抖

PIR 模块的热释电传感很容易受环境温度变化、空调气流甚至窗外阳光移动影响，出现误触发高电平。我在任务里做了两层过滤：第一层是事件发生后 200ms 内重复触发只算一次；第二层是连续两次有效触发的时间间隔要大于 1 秒，否则忽略。经过这两层过滤，误触发率明显下降。

任务里做去抖比中断里做更合理，因为 PIR 高电平本身持续好几秒，不需要微秒级响应。客厅里偶尔有宠物路过，这样的逻辑也避免系统反复打开展示和通知。如果你希望系统能够区分“人持续在房间”和“人进出高频动作”，还可以用两个 PIR 传感器做方向判断，但代码量和安装要求都会提高，个人项目一般没必要。

我实际测试的响应链路是：PIR 输出高电平 → 外部中断触发 →irq_handler任务被通知执行 → 200ms 去抖 → 更新 LED 状态并做一次快照记录。从电平跳到 LED 点亮的总延迟在 20ms 以内，完全满足预定指标。

6.5 看门狗与“任务活着但业务卡死”

独立看门狗只能防止 MCU 死循环，防止不了业务逻辑卡死。例如某个任务阻塞在互斥量上一直拿不到锁，CPU 其实还在运行，看门狗不会复位，但系统业务已经失效。我加了一个软看门狗：每个周期任务在完成任务后递增自己的心跳计数，watchdog_task 定期检查这些计数，发现某个任务心跳停滞就调用一次软件复位，或者至少输出诊断信息。

软看门狗的实现非常简单：用一个全局结构体数组保存每个任务最近的心跳时间戳，watchdog_task 每秒检查一次，超时超过阈值就处理。这套机制帮我抓到了几次 I2C 锁死和 DMA 配置异常。对于长期运行的房间设备，宁可重启一次，也不要带着故障状态一直跑下去。

7. 实时性验证：别靠感觉，用逻辑分析仪来测

7.1 GPIO 翻转法测响应时间

说“我的系统很实时”之前，最好先拿出证据。我做的第一个验证是 GPIO 翻转法：在每个关键执行路径的入口和出口翻转一个空闲 GPIO，然后用逻辑分析仪观察这个 GPIO 波形的时间宽度，就知道某段代码执行耗时多少。

测 PIR 到 LED 的响应链路时，我在 PIR 外部中断触发处拉高一个测试引脚，在 LED 点亮处拉低，然后用逻辑分析仪看高电平持续时长。实测得到 18~25ms，说明架构达到设计目标。如果波形出现明显毛刺或者持续时间波动很大，就说明调度不稳定，需要进一步排查中断优先级和任务抢占情况。

这个方法成本极低，却能快速定位“某个任务执行时间过长”或“某个任务被长时间饿死”的问题。我强烈建议在做任何 FreeRTOS 多传感器项目时，都在 PCB 上预留 2~3 个测试 GPIO，这在出问题时能救你一命。测量结果也能当作项目验收指标，比口头说“系统很快”有说服力得多。

7.2 用 Trace 工具看任务调度曲线

GPIO 翻转法能抓住宏观点，但看不到任务内部切换细节。我调试阶段用了 FreeRTOS 官方生态里的 SystemView 或者 Tracealyzer，定时导出任务切换记录，能清楚看到每个任务何时被创建、何时被抢占、何时阻塞等待。有一次我发现net_task优先级虽然最低，却频繁抢占ui_task，原因是它在延时等待 WiFi 响应时被 I2C 中断唤醒，白白获得执行时间，导致 UI 刷新变得卡顿。用 Trace 工具一眼就能看出这种异常调度。

如果你不想引入额外工具，也可以用vTaskList/vTaskGetRunTimeStats周期打印各任务的运行时间和状态。我在串口调试阶段打印过一次，发现 sensor_mgr 实际占用 CPU 只有 3% 左右，ui_task 却占了 20%，于是针对性优化了刷新策略。数据驱动的裁剪方式比自己猜高效很多。

7.3 可以从这个项目继续扩展的方向

做完基础版本后，如果还想继续折腾，可以加一块带触摸的显示屏，把 UI 任务直接换成 LVGL 界面；FreeRTOS 和 LVGL 的配合已经有成熟方案，LVGL 的 tick 由独立定时器提供，渲染任务放在低优先级即可。这样房间盒子就能直接显示趋势曲线，比 OLED 文字信息直观得多。

也可以把主控换成 STM32L4 系列，开启 tickless 低功耗模式，用电池供电；传感器方面把 SGP30 换成更低功耗的空气质量传感器，再配合 BLE 或者 WiFi 模块的深唤醒机制，整套系统的续航能提升很多。这些扩展不改变核心的任务架构，只是在硬件和外设上做替换，FreeRTOS 项目天然具备这种演进灵活性。

最后分享一个我在实际调试中体会最深的小技巧：刚开始做这种多传感器系统，不要一上来就把所有传感器都同时集成进去。先跑通“一个传感器 + 一个显示任务 + FreeRTOS”的最小链路，验证任务调度没问题，再逐步增加下一颗传感器和一个处理任务。每加一步，都用上面的 GPIO 翻转法和 Trace 工具看一眼系统时延变化。多传感器系统最怕的不是某个传感器读不出来，而是多个传感器凑到一起时彼此干扰、任务抢占失控。先把地基打好，后面加功能就是水到渠成的事。