1. 房间监控器为什么用FreeRTOS而不是继续裸机while(1)把FreeRTOS Multisensor Room Monitor这个词拆开看本质是一个多传感器房间环境监控终端要同时完成温湿度、光照、空气质量、人体活动这几路信息的采集再通过屏幕显示和串口/WiFi上报出去。表面上看功能不复杂单芯片、两三个传感器、一块小屏好像一个裸机while循环就能兜住。但做过类似项目的人都有体会硬件功能越多主循环越容易变成一团理不清的状态机。先说最直接的痛点。不同传感器的工作节奏差异非常大。温湿度传感器SHT30走I2C一次读取要发起命令、等待转换、读回数据全流程少说几个毫秒光照传感器BH1750也一样I2C总线上一来一回都是阻塞的。空气质量模块MQ-135走ADC采样量程校准麻烦不说传感器本身还要几十秒甚至几分钟的预热。人体感应PIR干脆是异步触发信号你永远不知道它下一秒什么时候跳变。这些特性如果全塞进一个for循环里最典型的后果就是读一次传感器屏幕就卡顿一次PIR触发了还要等当前I2C操作完成才能处理代码顺序稍微调一下整个系统响应就变形。更麻烦的是扩展性。项目第一阶段只接三个传感器第二阶段加一个屏幕菜单第三阶段又加一个网络上报裸机主循环里的标志位越来越多各种等待传感器完成但又被新事件打断的状态组合迅速膨胀。我见过不少同事在这个阶段开始靠全局变量打补丁结果日志一开发现读到的数据时而正常时而错乱最后只能靠jlink打断点慢慢找。FreeRTOS解决的就是这个问题把每个关注点拆成独立任务由内核根据优先级和时间片统一调度传感器采集阻塞了不会拖累屏幕刷新按键响应也不会被长耗时操作挡住。每个任务看起来像一段独立的程序任务之间通过队列、信号量这类标准机制通信逻辑边界清楚新人接手代码也不至于崩溃。这个项目选择FreeRTOS还有一个很现实的学习价值。现在stm32cubemx已经能直接生成FreeRTOS基础工程配置勾选几步就能跑起第一个任务学习门槛比十年前低很多。项目用正式的FreeRTOS项目实战方式来做把任务创建、队列、互斥量、软件定时器、堆栈溢出检测这些机制全部用一遍比单纯看FreeRTOS学习笔记印象深得多。选型上建议用STM32F103C8T6或者G0系列的芯片。以F103C8T6为例20KB RAM、64KB Flash跑一个4~5任务的小型监控终端完全够用。有人觉得64KB Flash是不是太小实际上完整工程编译出来一般也就30~40KBLVGL精简配置能控制在15KB左右余量充足。20KB RAM要注意的是任务栈的总分配后面第四章会专门讲怎么估算和排查栈溢出。2. 硬件接入和传感器共线I2C总线上挂了四个从机一切没有那么简单2.1 传感器选型清单这个项目我用的传感器组合如下每个都偏入门级成本低、资料多、换起来容易功能传感器型号接口关键特性温湿度SHT30I2C精度高读取快可配置测量重复性光照BH1750I2C量程0~65535 lx数字输出空气质量MQ-135ADC模拟量输出检测CO2、烟雾等人体感应HC-SR501 PIRGPIO数字脉冲触发可调灵敏度显示SSD1306 OLED 或 1.8寸IPS LCDI2C/SPI显示实时数据和报警状态这个组合最大的特点是除了MQ-135和PIR其余器件都挂在同一条I2C总线上总线上一共四个从机SHT30、BH1750、SSD1306如果LCD用SPI就少一个。总线器件的地址要在原理图阶段就排清楚。SHT30默认地址0x44可以通过ADDR引脚改到0x45BH1750的ADDR引脚接地是0x23接高是0x5CSSD1306一般是0x3C少数版本是0x3D。如果调试时I2C扫描不到设备先查引脚电平再查地址这两步能解决八成问题。2.2 上拉电阻的坑比传感器本身多I2C是多主机、多从机协议总线空闲时SCL和SDA必须被上拉到高电平。开发板上一般各自有上拉电阻但外接传感器模块上也经常自带。比如SHT30模块自带2.2k上拉BH1750模块有的带1k再加上屏幕模块自带的四个模块并联之后总等效上拉阻值可能只有几百欧姆总线拉低能力不够时波形边缘变缓就会出现偶尔读取失败第一次读不到数据、复位后又好了这类诡异现象。解决方法是保留一组上拉总阻值控制在2k~10k之间。如果模块自带上拉无法拆掉实测时发现传输速率不高标准模式100k快速模式400k但波形仍不好可以在软件里把I2C时钟降到100kHz试试。这个坑在纯粹的单传感器例程里几乎遇不到多传感器共线时属于第一优先级排查项。2.3 供电和地线的讲究MQ-135内部有加热丝通电时功耗比数字传感器高一个量级加热丝工作电流会在供电线上产生明显压降和纹波。如果MQ-135和STM32用同一个LDO供电模拟地线上会叠上一堆噪声ADC采出来的数值跳得没法看。建议把传感器电源分成两路数字传感器共用3.3VMQ-135加热部分用5V独立供电模拟地AGND在电源入口处单点连接尽量避免大电流回路穿过ADC采样区域。另外注意MQ-135刚上电前几分钟读数漂移很大因为内部加热丝从冷态到热态需要稳定时间。设计上要么在上位机侧加预热中状态提示要么在软件里丢弃前2~3分钟的采样数据只做预热后的数据记录。2.4 ADC采样滤波处理MQ-135输出模拟电压经STM32内部ADC转为数字量。单片机的ADC参考电压如果直接用3.3V供电电源上只要有一点纹波低浓度时的微弱变化就会被淹没。条件允许的话用独立的3.3V基准源给VDDA供电。软件侧至少要做一个多次采样滤波我习惯的做法是连续采样8次去掉最大最小后取平均能压掉大部分工频和随机噪声。3. FreeRTOS任务模型把采集、处理、显示、上报拆成四条独立流水线3.1 任务划分与优先级设计这个项目我最终设计了4个任务和1个软件定时器任务/定时器优先级建议栈深度4字节单位周期/触发方式传感器采集任务3256软件定时器周期触发周期500ms数据处理与告警任务2256阻塞等待传感器队列显示刷新任务1384阻塞等待显示队列 定时器触发网络/串口上报任务2320周期1s发送系统守护任务0空闲级128低优先级统计和看门狗喂狗优先级设计有一个容易忽略的点显示任务虽然看起来不那么重要但它的栈开销其实是最大的。因为刷新屏幕时可能要做局部临时变量、字符串格式化、坐标计算如果走LVGL还要留出GUI内部缓冲的余量。所以把这个任务排低优先级但栈给到384字。采集任务优先级最高因为它要保证传感器读取的时序不被显示刷新打断。这里要说明的是优先不是指它抢占一切而是它在就绪时优先执行。采集中间它也会主动阻塞在I2C等待上这时候CPU会切换到其他任务。3.2 队列和互斥量任务之间怎么安全地传数据任务间通信我用了两个队列和一个互斥量。传感器采集任务读完后把数据打包成一个结构体扔进xSensorQueue数据处理任务阻塞等待这个队列拿到就做滑动平均、阈值判断再把处理结果放进xDisplayQueue。显示任务等xDisplayQueue有数据就刷新对应区域避免了显示任务主动去查询传感器把何时更新这个节奏完全交给上游决定。#define SENSOR_QUEUE_LEN 8 #define DISPLAY_QUEUE_LEN 4 typedef struct { float temperature; float humidity; uint16_t lux; uint16_t air_quality_raw; uint8_t pir_triggered; uint32_t timestamp_ms; } sensor_data_t; QueueHandle_t xSensorQueue; QueueHandle_t xDisplayQueue; SemaphoreHandle_t xI2CMutex; void SensorTask(void *argument) { sensor_data_t data {0}; for (;;) { // 等待软件定时器发出的采集节拍 ulTaskNotifyTake(pdTRUE, portMAX_DELAY); // I2C总线是共享资源用互斥量保护 if (xSemaphoreTake(xI2CMutex, pdMS_TO_TICKS(50)) pdPASS) { /* 读取SHT30、BH1750 */ xSemaphoreGive(xI2CMutex); } data.pir_triggered HAL_GPIO_ReadPin(PIR_GPIO_Port, PIR_Pin); data.air_quality_raw ReadADC_Filtered(); xQueueSend(xSensorQueue, data, pdMS_TO_TICKS(20)); } }这里有一个选择上的细节I2C总线的保护我特意用了互斥量而不是二值信号量。原因是互斥量自带优先级继承机制。假设采集任务持有I2C锁此时显示任务也想用I2C比如刷新屏幕SSD1306走I2C如果显示任务优先级高于采集任务就会出现低优先级任务占着锁不让高优先级任务执行的优先级反转。互斥量会在检测到高优先级任务等待时临时提升持有者的优先级等释放后恢复从根上避免反转。队列的设计也值得说。有人在裸机习惯里会用全局结构体加标志位来传数据这在RTOS里是危险做法。任务A写一半任务B来读读到的是半新半旧的数据。队列每次发送都是值拷贝接收端拿到的是一份完整快照发送和接收天然解耦不需要担心竞争。队列长度不用开太大Sensor队列8个、Display队列4个就够因为生产者和消费者的速度是匹配的入队满了就阻塞等待这本身就是流量控制。3.3 软件定时器做节拍为什么不用一个专门的Delay任务传感器采集周期我用了一个周期500ms的软件定时器定时器回调里通过xTaskNotifyGive唤醒采集任务。为什么不直接在采集任务里vTaskDelayUntil两种做法都能实现周期性但软件定时器把周期发生和工作内容分开了以后想改成每1s采一次或者临时改为按键触发只需要改定时器配置不用动任务代码。定时器回调里只做通知不做实际I2C读取保证回调函数极其短小不会阻塞定时器守护任务。如果不用软件定时器直接在采集任务里做也完全可行用vTaskDelayUntil比vTaskDelay更准因为前者固定了绝对时间段不受任务中途调度影响。这个项目因为后续要加定时校准和低功耗唤醒用软件定时器更灵活学习价值也更大。4. 从裸机循环折腾到FreeRTOS堆栈溢出、I2C锁死和HardFault定位实录4.1 第一次上FreeRTOS就遇到系统复位项目第一次把裸机代码迁移到FreeRTOS时出现了一个特别典型的现象系统上电后正常跑十几秒屏幕一旦开始频繁刷新就突然复位。有时候是几分钟后复位Bug复现完全没有规律。一开始怀疑是看门狗没喂查了一圈发现看门狗根本还没开。后来接了ST-Link在HardFault_Handler里打断点稳定停在HardFault说明是程序跑飞而不是单纯复位。定位HardFault的第一步是把PC指针和LR寄存器保存下来然后用arm-none-eabi-addr2line或者IDE的map文件反查是哪个函数。我的工程里PC停在了一个完全无关的库函数里这说明栈已经被破坏函数返回地址被写乱再去查那个地址意义不大。真正的根因在栈溢出。4.2 堆栈溢出检测configCHECK_FOR_STACK_OVERFLOW怎么用FreeRTOS提供了两种堆栈溢出检测机制在FreeRTOSConfig.h里配置#define configCHECK_FOR_STACK_OVERFLOW 2选择2而不是1是因为方式1只在任务切换时检查栈指针是否超出范围方式2在任务切换时还会额外检查栈顶部预留的数据是否被改写检测更严格误报更少。配置之后同时实现vApplicationStackOverflowHookvoid vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { /* 任务栈溢出后程序已经处于临界状态这里尽量把现场信息留下来 */ volatile char overflowed_task[16] {0}; strncpy(overflowed_task, pcTaskName, sizeof(overflowed_task) - 1); /* 重定向到串口打印随后进入死循环等待调试器 */ printf([FATAL] Stack overflow in %s\r\n, overflowed_task); for (;;); }这里有个经验栈溢出Hook执行时系统已经处于危险状态不要在这个函数里做太多复杂操作常用库函数都可能再次触发栈操作。最简单的做法是把任务名保存到几个全局变量里然后进死循环靠调试器或串口DMA把已发出的数据拿出来。开了检测后打印出来的溢出任务正是显示刷新任务。原因xTaskCreate创建任务时栈大小参数的单位是字4字节不是字节。我把一个需要在栈上构造几百字节临时缓冲区的图形刷新逻辑分配了128字栈512字节一执行复杂绘制就爆栈。后来把显示任务加到384字问题彻底消失。uxTaskGetStackHighWaterMark这个API也很有用它返回任务历史最低剩余栈空间可以编译期把各任务的余量打印出来用实测数据决定栈该开多大而不是拍脑袋。4.3 I2C锁死和优先级反转现象像断路多半是同步问题项目还遇到过另一个很奇怪的现象运行一段时间后屏幕上温湿度数据不动了但系统没死按键还能响应。看代码读取SHT30那段逻辑用的是阻塞式HAL_I2C_Master_Transmit超时设置的是100ms。问题出在互斥量和I2C等待的组合上。显示任务优先等级比采集任务低但显示任务里也用到了同一套I2C总线去刷新OLED。当采集任务持有I2C互斥量等待SHT30应答时显示任务也在等待这个互斥量。理论上等待几十ms就该拿到但OLED刷新被设计成了一次发好几帧数据每帧之间还有延时结果就是低优先级显示任务长时间占用CPU时间片采集任务在高优先级却因为等锁被卡住形成高优先级任务阻塞在低优先级任务后面的连锁表现。解决步骤是把I2C互斥量从二值信号量换成互斥量让优先级继承机制生效然后给每个I2C操作加上明确的超时参数不无限期等待最后把OLED刷新逻辑改成按需刷新只在数据变化的区域绘制而不是整屏重画。这三个改动做完锁死现象再没出现过。4.4 中断服务函数里不要干重活还有一个小坑也提醒一下。有人在PIR触发中断的ISR里直接调用xQueueSend往显示队列发数据这个不算错但一旦在ISR里调用了会阻塞的API比如带超时的发送或者打印串口系统就会随机卡死。FreeRTOS在ISR里只能调用带FromISR后缀的API且不允许阻塞。正确做法是中断里只做xQueueSendFromISR这种轻量操作或者干脆只设置一个标志位由采集任务轮询后处理。PIR的脉冲本身只有几百毫秒主循环即使有几十ms延迟也不会丢事件。5. 显示与上报环节LVGL移植注意事项和串口数据组包5.1 freertos移植lvgl先解决时间基准和锁Freertos移植Lvgl这个话题在圈子里讨论度很高。实际项目中LVGL移植到FreeRTOS有两大要点。第一是时间基准LVGL内部所有动画、定时刷新都依赖一个毫秒级的tick源需要在FreeRTOS里配一个1ms周期的软件定时器调用lv_tick_inc(1)或者用systick分频出来。漏配这个界面会表现为触碰了没反应或者刷新很慢。第二是GUI访问的互斥保护。LVGL并非线程安全如果传感器任务给显示任务传数据显示任务调用lv_label_set_text而另一个任务也在同一时刻调用LVGL API内存管理就会错乱。稳妥做法是把所有LVGL操作集中在显示任务里其他任务只往队列丢数据。如果架构上不可避免要跨任务调用LVGL就在外面套一层互斥量所有LVGL API调用前先拿锁。实际使用中显示任务的结构大概是这样void DisplayTask(void *argument) { lv_init(); /* 注册tick、初始化显示驱动、创建各个控件 */ for (;;) { sensor_data_t data; if (xQueueReceive(xDisplayQueue, data, pdMS_TO_TICKS(200)) pdPASS) { /* 用数据更新labelLVGL内部只标记控件为dirty */ lv_label_set_text_fmt(temp_label, %.1f C, data.temperature); lv_label_set_text_fmt(humi_label, %.1f %%, data.humidity); } lv_timer_handler(); vTaskDelay(pdMS_TO_TICKS(10)); } }注意lv_timer_handler必须在显示任务里周期性调用它负责真正执行重绘操作。刷新频率不需要太高10ms调一次已经足够流畅太高反而浪费CPU在局部重绘上。屏幕尺寸不大时开双缓冲意义有限单缓冲加局部重绘完全够用。5.2 串口上报与上位机协议对象要用心跳和帧格式串口上报是监控终端最基础的上报方式。我用的协议很简单一行一段JSON末尾\r\n波特率115200。结构大致是{t:1711350000,temp:25.3,humi:58.1,lux:320,air:1450,pir:0}这里最容易踩的坑是组包缓冲区大小。假设温度用%.2f格式化字符串长度其实不稳定如果定义了一个64字节的静态缓冲区一旦数据位数变多就可能越界写坏其他内存。稳妥做法是缓冲区给到128字节或者直接用snprintf限制写入长度。上位机侧解析时要按行切分不能按固定长度读因为浮点数转字符串后的长度是变化的。如果接ESP8266这类WiFi模块做网络上报需要特别警惕AT指令的响应等待。ESP8266的AT指令响应有时需要几百毫秒甚至更久绝不能放在传感器采集任务里阻塞等待。我专门开了一个网络上报任务采集任务把数据放进上报队列网络任务基于自己的节奏发送发送失败后做指数退避重试而不是立刻重发导致雪崩。6. 低功耗与扩展方向这个监控器还能怎么继续进化系统跑稳定之后下一步自然考虑功耗和扩展。FreeRTOS支持configUSE_TICKLESS_IDLE开启后空闲任务在无事可做时可让MCU进入低功耗模式同时把系统Tick停下来由一个低功耗定时器在下次事件前唤醒。对于这个项目如果电池供电传感器采集周期从500ms拉长到5s显示只在有变化时刷新整机平均电流能明显降下来。开Tickless要注意的是代码里如果依赖HAL_GetTick之类的软件时基低功耗睡眠期间那些计数器会跳变需要在进入睡眠前保存状态。实测下来STM32G0这类新工艺芯片在Tickless模式下优势比F103明显得多如果项目初始就考虑电池供电直接选G0更省心。扩展传感器的方向也很自然。目前采集任务是一个任务读全部传感器传感器多了之后更合理的模式是每个传感器一个独立采集任务各自用自己的周期把数据汇入同一个队列。这样加一个气体传感器只需要新增一个文件、注册一个任务不用去改原任务的调度逻辑。代价是任务变多占用的RAM总量增加动态内存堆heap_4的配置也要相应调大。I2C总线上的竞争会更明显但前面的互斥量方案已经能兜住。最后还有一点经验想单独分享。做FreeRTOS项目日志常开是大忌也是大恩人。开发阶段用printf打印每条任务栈高水位、队列使用情况能快速暴露问题发布版本时用宏开关把调试日志全部剪掉腾出串口带宽和Flash空间。串口打印本身是阻塞的高频打印会严重拖慢系统实测115200波特率下打印一行30字符的日志就需要差不多2.6ms如果三个任务都在打日志性能直接崩。把日志级别做成LOG_LEVEL_DEBUG宏发布前改成LOG_LEVEL_WARN这个习惯值得早点养成。FreeRTOS多传感器房间监控这个项目难度不高上限却不低。把任务划分、队列通信、互斥量、栈检测、LVGL移植这一整条链路走下来后面再去碰复杂一点的嵌入式系统心里就有底了。