实验室里最怕的不是着火那一刻而是着火前没人发觉的那十几分钟。传统安防摄像头盯着门外过道对室内烟雾初起基本无感烟雾报警器又往往只在浓度很高时才动作等响起来已经是火烧眉毛。所以我自己动手做了一套基于STM32的实验室消防预警控制系统把烟雾浓度和温度两个最关键的物理量同时盯住按风险等级分三级响应从声光提醒到自动启动排风扇整个项目代码、原理图、仿真工程全部开源可以直接下载复现。这套系统不挑基础只要会一点STM32和C语言就能玩转就算你完全没做过项目跟着原理图和仿真跑一遍也能把整个嵌入式开发的链路摸通。这里我把完整的设计思路、电路细节、代码逻辑和调试踩过的坑一次说清楚。1. 实验室火灾为什么难预警这个系统的设计定位1.1 传统方案的空白点很多人觉得实验室消防安全有现成方案其实仔细拆开看缺口非常大。摄像头监控只能看到明火烟雾初期摄像头画面上也就是一层薄雾不盯着看根本发现不了常规的离子式烟感灵敏度虽高但实验室里经常有酒精灯、加热台、焊锡烟这些正常操作烟感在实验室里误报率极高装久了大家习以为常真出事反而没人当回事。更关键的是实验室火灾很多不是爆燃而是缓慢的阴燃过程比如电路板过热冒烟、锂电池隔膜热失控、化学品放热反应这些场景的特点是“先出烟、后出火”中间有一段宝贵的预警窗口期。这个窗口期大概有多长取决于燃烧物和环境。聚氨酯泡沫、电路板环氧树脂这类材料阴燃阶段可以持续几分钟到十几分钟温度从正常缓慢爬升到着火点。如果系统能在温度异常、烟雾浓度超标的第一时间分层报警值班人员完全来得及断电、疏散、拿灭火器处理。但如果没有任何预警等肉眼看到明火整间实验室已经处于不可控状态了。1.2 系统功能边界与使用场景这套消防预警控制系统核心功能就三句话感知烟雾浓度和环境温度按风险程度分级报警联动执行器自动干预。具体的运行逻辑我设计成这样正常状态绿色指示灯常亮OLED屏显示温湿度和烟雾浓度所有继电器断开。预警状态烟雾浓度或温度超过第一档阈值黄色指示灯闪烁蜂鸣器每2秒短鸣一次OLED显示“注意烟雾浓度偏高”提示现场人员自查。报警状态烟雾或温度超过第二档阈值红色指示灯常亮蜂鸣器连续急促鸣叫继电器吸合排风扇自动启动排烟降温。危险状态烟雾和温度同时严重超标所有指示灯全亮蜂鸣器持续长鸣继电器保持吸合同时串口向上位机发送“DANGER”事件需要人工按键确认复位。需要说明的是这套系统定位是“预警和辅助干预”不是替代消防喷淋和气体灭火系统。它最适合的场景是电子实验室、化学实验室、设备机房、配电间这类空间不大、易燃物集中、有人长期值守的场所。实际部署时可以多个节点组网每个试验台放一个终端汇总到管理室看板。1.3 为什么选STM32做主控这个项目早期我考虑过用51单片机核算下来发现存在三个问题ADC只有8位烟雾传感器输出电压的微小变化根本分辨不出来片上Flash和RAM太小想加个OLED显示和串口日志就得拼命省空间主频太低DHT11的单总线时序控制虽然没问题但以后想加ESP8266联网、加多个传感器51就力不从心了。换成STM32F103C8T6之后这些问题全部迎刃而解。Cortex-M3内核跑72MHz12位ADC可以精确感知烟雾传感器毫伏级的电压变化64KB Flash和20KB RAM让代码结构可以写得很规整3个USART和丰富的GPIO也为后续扩展留足余量。最关键是这个芯片的资料满天飞任何一个小问题都能搜到答案对开源项目来说这决定了别人能不能顺利复现。如果拿它跟F103RCT6比C8T6少了部分引脚和存储空间但对这个项目来说完全够用而且成本只有RCT6的一半左右。2. 硬件选型与原理图设计每一路信号怎么走通2.1 模块选型与引脚规划我尽量选择模块化的传感器和执行器这样复现门槛低有现成的排针可以直接插在洞洞板上。完整清单如下模块型号/规格数量作用主控STM32F103C8T6核心板1系统主控烟雾传感器MQ-2模块带比较器1检测烟雾/可燃气体温湿度传感器DHT111测温、测湿显示屏0.96寸OLED SSD1306 I2C1显示实时数据蜂鸣器有源蜂鸣器 5V1声光报警继电器模块5V单路继电器1控制排风扇按键轻触开关3布防/消音/复位稳压芯片AMS1117-3.313.3V供电引脚分配我在原理图里这样规划的PA0烟雾传感器数字输出DO备用用来做快速断线检测PA1烟雾传感器模拟输出AOADC1_IN1核心采样通道PA2按键1布防/撤防PA3按键2消音PA4按键3系统复位确认PB6DHT11数据线PB8OLED SCLPB9OLED SDAPB0蜂鸣器控制PB1继电器控制PB10绿色LED正常PB11黄色LED预警PB12红色LED报警这个引脚分配有个好处把ADC输入和数字IO分开模拟信号不会受到数字翻转的干扰可能是因为把DHT11的PB6配成开漏输出4.7kΩ上拉I2C的PB8/PB9也是开漏两个总线互相独立工作时序不会打架。2.2 MQ-2烟雾传感器的信号链设计MQ-2的工作原理是传感器内部有二氧化锡半导体加热丝通电后表面吸附氧分子当遇到可燃气体或烟雾时氧分子脱附电导率上升。模块上自带一个比较器和一个可调电位器数字输出DO可以调节灵敏度阈值模拟输出AO则直接反映当前气体浓度对应的电压值。这个模块用起来有一个所有新手都会掉进去的坑它需要5V供电而且加热丝要消耗不小的电流。我实测正常工作电流在150mA左右预热瞬间能到180mA以上。所以在原理图里MQ-2模块的VCC不接在STM32核心板的3.3V端而是直接从USB的5V母线上取电。AO输出接到PA1时注意AO最高输出电压会接近5V而STM32的ADC输入范围是0到3.3V超出就会烧引脚。解决办法有两种一种是在AO引脚串联10kΩ电阻再进ADC利用STM32内部上下拉做分压另一种更规范的做法是加一个3.3V稳压二极管钳位或者用电平转换电路。我这个项目里用的是简单可靠的分压方案10kΩ串阻 3.3V稳压管到地。原理图上看PA1节点最高电压被钳在3.5V以内理论上已经完全保护了。2.3 DHT11单总线时序与上拉设计DHT11数据线采用单总线协议一条线上既有主机到从机的命令又有从机到主机的数据回传所有通信全靠精确的时序控制。硬件上最容易被忽略的是上拉电阻。DHT11模块很多已经在板子上集成了一颗10kΩ上拉电阻但如果买的是裸传感器就必须自己在数据线上加4.7kΩ到10kΩ的上拉电阻否则通信会非常不稳定。在MCU侧还有两个细节值得说。第一DHT11的GPIO要配置成开漏输出模式因为开漏模式下引脚可以被外部上拉电阻拉到标准电平等加上单片机内部有保护二极管这样即使DHT11拉低总线时MCU误输出高电平也不会发生电流倒灌。第二DHT11规格书上写着“采样周期必须大于2秒”每次读取间隔如果小于1.5秒模块就会不响应我在软件里专门做了一个读取节流不管主循环跑多快至少间隔2.5秒才发起一次新读取。2.4 声光报警与继电器驱动电路这个项目的执行器有蜂鸣器、LED指示灯和继电器。蜂鸣器和继电器都不能由GPIO直接驱动原因很简单GPIO在3.3V下最多输出约20mA的电流而蜂鸣器需要的电流在30mA以上继电器线圈更是要70mA左右直接接会拉低GPIO电压严重时直接烧毁引脚。我的驱动方案是NPN三极管开关电路。以蜂鸣器为例STM32的PB0通过1kΩ电阻接到S8050三极管的基极蜂鸣器的正极接5V负极接三极管的集电极发射极接地。当PB0输出高电平时三极管导通蜂鸣器形成回路开始鸣叫。这里两个细节很关键基极串1kΩ限流电阻防止GPIO过流蜂鸣器两端反向并联一个1N4148二极管这里是无源蜂鸣器才严格需要不过有源蜂鸣器并联一个也能吸收感性负载的反向电动势。继电器电路类似只是继电器线圈感性更强反电动势更大续流二极管必须用1N4007这种额定电流1A的功率二极管。我见过好几起继电模块板上明明有续流二极管但MCU还是复位的案例问题往往出在地上——继电器的地和MCU的地是同一根长导线大电流瞬间在接地回路上产生压降导致MCU复位。所以原理图里我把继电器地线单独走线一段在最靠近电源端的地方才和MCU地汇合。2.5 电源拓扑与滤波整个系统用一个USB接口供电5V进来后分两路走5V直接给MQ-2加热器、蜂鸣器、继电器、OLED屏供电。5V经过AMS1117-3.3稳压到3.3V给STM32、DHT11、LED指示灯供电。AMS1117是低压差线性稳压器输入输出压差低至1V左右所以5V转3.3V完全不需要散热片。关键是输入输出电容不能少输入侧放10uF钽电容并联0.1uF陶瓷电容输出侧放10uF电解电容并联0.1uF陶瓷电容。这一步能有效滤除MQ-2加热器带来的纹波以及继电器吸合瞬间的电压跌落。在STM32的VDD脚和VDDA脚处我还各加了一个100nF去耦电容。别小看这几个电容实测中ADC采样值的跳动幅度可以从50个LSB降到5个LSB。如果要在ADC方面追求更高精度可以让VDDA通过一个磁珠和VDD隔离但我实测在这个项目场景里800mV的烟雾电压变化量级磁珠带来的提升不大所以就没有画进去。3. 预警状态机与主控代码如何让系统分层响应3.1 软件框架前后台轮询架构这种规模的嵌入式项目用实时操作系统RTOS是杀鸡用牛刀用复杂的中断驱动框架又容易把自己绕晕。我选了最常见也最稳定的方法一个超级循环在循环里按时间片轮询各个任务模块。主循环伪代码如下while (1) { system_task_run(); // 按键扫描与系统状态处理 sensor_task_run(); // 传感器数据采集与滤波 display_task_run(); // OLED实时刷新 alarm_task_run(); // 预警状态机调度 uart_log_task_run(); // 串口日志输出 }每个任务模块内部自己判断时间是否到达比如传感器采集模块内部维护一个时间戳距离上次采集超过2秒才执行DHT11读取ADC则每100ms采一轮。这种写法的好处是任何一个子模块出问题都不会导致系统完全死锁排查起来也清晰。DHT11时序要求严格读取期间会被几个微妙级的延迟阻塞但整体影响不大那个阻塞顶多150us循环里不算事。3.2 ADC采样与滑动滤波ADC读取烟雾传感器输出电压是整套系统的眼睛这个环节的精度直接影响误报率。我用的ADC1的通道1也就是PA112位分辨率采样时间设置为55.5个ADC时钟周期这样输入阻抗匹配更好读到的值更稳定。核心代码如下float smoke_voltage_read(void) { uint32_t sum 0; uint16_t adc_value; // 连续读取16次 for (uint8_t i 0; i 16; i) { ADC_RegularChannelConfig(ADC1, ADC_Channel_1, 1, ADC_SampleTime_55Cycles5); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) RESET); adc_value ADC_GetConversionValue(ADC1); sum adc_value; } adc_value sum / 16; // 转换成实际电压参考电压3.3V float voltage ((float)adc_value / 4095.0f) * 3.3f; return voltage; }为什么要循环16次取平均因为MQ-2模块的AO输出本身有小的波动加上ADC采样过程中的噪声单次采样值跳动可能到几十个LSB。16次平均可以把噪声摊平同时读取耗时约1ms对系统响应速度没有影响。MQ-2输出电压和气体浓度不是线性关系它本质上是电阻比率的对数变化。在工程上我们不需要精确到ppm只要把电压值映射成一个“烟雾浓度百分比”用来做阈值判断就够用。映射公式我写在软件里float smoke_level (voltage - SMOke_CLEAN_BASE) / (SMOKE_ALARM_TH - SMOKE_CLEAN_BASE); if (smoke_level 0.0f) smoke_level 0.0f; if (smoke_level 1.0f) smoke_level 1.0f;这里的SMOKE_CLEAN_BASE是上电基线标定阶段测得的清洁空气电压值SMOKE_ALARM_TH是报警触发电压实际项目中我通过测试设定为1.2V。这样烟雾浓度从0到100%在OLED上显示直观调阈值也方便。3.3 DHT11驱动一次完整的单总线握手DHT11读写时序是整个项目里最容易写崩的模块我把每一步都拆开讲。整个过程分三个阶段起始信号、响应信号、数据位流。起始信号主机把数据线拉低至少18ms再拉高20到40us。这个拉低18ms是关键DHT11需要这段时间来识别到主机请求。有些人用20ms也没问题但太长浪费CPU太短模块完全无反应。响应信号DHT11检测到起始信号后会把数据线拉低80us然后拉高80us表示“准备发送数据”。主机在拉高后需要等待如果等了足够时间还没看到低电平就说明模块未就绪或者传感器损坏。数据位流紧接着DHT11开始发送40位数据每个bit都先拉低50us然后通过高电平的持续时间来区分0和1。高电平约26到28us代表0约70us代表1。在主机侧我使用延时法采样等低电平结束后延时40us再读电平如果电平为高说明是1否则是0。这个40us的窗口刚好落在两者中间区分度很好。uint8_t dht11_read_bytes(uint8_t out[5]) { uint8_t i, j; uint8_t byte 0; // 1. 起始信号 GPIO_ResetBits(DHT11_GPIO, DHT11_PIN); delay_us(18000); GPIO_SetBits(DHT11_GPIO, DHT11_PIN); delay_us(30); // 2. 等待响应 if (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET) return 1; while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) RESET); while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET); // 3. 读取5个字节 for (i 0; i 5; i) { for (j 0; j 8; j) { while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) RESET); delay_us(40); byte 1; if (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET) byte | 1; while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET); } out[i] byte; byte 0; } // 4. 校验前4字节之和的低8位等于第5字节 if (((out[0] out[1] out[2] out[3]) 0xFF) out[4]) return 0; return 2; }返回码0代表成功1代表模块无响应2代表校验失败。我在主循环里如果连续3次读到非0的返回码就在OLED上显示“DHT11 ERR来自”。这个容错逻辑很重要实验室环境传感器偶尔被烟雾呛一下也会出错不能因为一次读取失败就直接让整个系统报警更不能死循环卡住。3.4 三级预警状态机的实现状态机是这段程序的核心思维把所有可能的状态整理成一张图系统在任何时候只处于其中一个状态状态之间通过明确的迁移条件切换。这比用一串if-else堆逻辑要清晰得多也方便后续扩展。我把状态定义成四档typedef enum { FIRE_ST_NORMAL 0, FIRE_ST_WARNING, // 一级预警 FIRE_ST_ALARM, // 二级报警 FIRE_ST_DANGER // 三级危险 } fire_state_t;状态机调用的核心函数void fire_state_run(void) { float temp get_temperature(); float smoke_v get_smoke_voltage(); uint8_t key_confirm read_key_confirm(); switch (current_state) { case FIRE_ST_NORMAL: if (temp TEMP_WARN_TH || smoke_v SMOKE_WARN_TH) current_state FIRE_ST_WARNING; break; case FIRE_ST_WARNING: if (temp TEMP_ALARM_TH || smoke_v SMOKE_ALARM_TH) current_state FIRE_ST_ALARM; else if (temp TEMP_WARN_TH_REC smoke_v SMOKE_WARN_TH_REC) current_state FIRE_ST_NORMAL; // 滞回退出 break; case FIRE_ST_ALARM: if (temp TEMP_DANGER_TH smoke_v SMOKE_DANGER_TH) current_state FIRE_ST_DANGER; else if (temp TEMP_ALARM_TH_REC smoke_v SMOKE_ALARM_TH_REC) current_state FIRE_ST_WARNING; break; case FIRE_ST_DANGER: // 危险状态只能由人工按键确认后复位 if (key_confirm) current_state FIRE_ST_NORMAL; break; } }对应的执行器输出函数就很简单了void fire_action_run(void) { switch (current_state) { case FIRE_ST_NORMAL: led_green_on(); led_yellow_off(); led_red_off(); buzzer_off(); relay_off(); break; case FIRE_ST_WARNING: led_green_off(); led_yellow_toggle(); led_red_off(); buzzer_slow(); relay_off(); break; case FIRE_ST_ALARM: led_green_off(); led_yellow_off(); led_red_on(); buzzer_fast(); relay_on(); break; case FIRE_ST_DANGER: led_green_on(); led_yellow_on(); led_red_on(); buzzer_always_on(); relay_on(); break; } }这里有个细节值得注意预警和报警的退出阈值跟进入阈值不一样。比如进入预警是电压超过0.6V但退出预警要等到电压回落到0.45V以下。这就是“滞回比较”目的很明确——防止烟雾浓度在阈值附近抖动时系统在正常和预警两个状态之间来回横跳蜂鸣器一会儿响一会儿停几分钟就能把值守的人整到麻木。继电器就更需要滞回逻辑了频繁吸合释放会严重缩短触点寿命。3.5 OLED显示与串口日志输出OLED用I2C接口SSD1306控制器读取。我在开源代码里做了两层封装底层是ssd1306_write_cmd和ssd1306_write_data上层是简单的字符和字符串绘制函数。这样移植到任何I2C屏都很方便换引脚只需要改宏定义。主界面显示逻辑void display_task_run(void) { static uint32_t last_disp_time 0; if (millis() - last_disp_time 200) return; last_disp_time millis(); char line[32]; sprintf(line, T:%.1fC H:%d%%, get_temperature(), get_humidity()); ssd1306_draw_string(0, 0, line); sprintf(line, Smoke:%.2fV, get_smoke_voltage()); ssd1306_draw_string(0, 2, line); sprintf(line, State:%s, state_name[current_state]); ssd1306_draw_string(0, 4, line); ssd1306_refresh(); }串口日志通过PA9和PA10输出配置成USART1波特率115200每秒打印一轮关键数据格式是temp28.3 hum52 smoke0.43 stateNORMAL。这个日志在调试阶段救过我很多次尤其是判断传感器数据是否漂移、状态是否正确迁移。整个系统调试时不要凭感觉把日志数据拉到电脑上用Excel或matplotlib画一条曲线看趋势很多问题一眼就能发现。4. Proteus仿真没有实体模块也能跑通逻辑4.1 仿真工程搭建与芯片加载很多想复现的人卡在没有实体硬件的门槛上其实仿真完全能解决大部分问题。我用的是Proteus 8.9版本新建工程后从元件库拾取STM32F103R6芯片别纠结C8T6和R6的差异仿真模型的外设资源差别不大。关键一步是双击芯片打开属性对话框在“Program File”里加载Keil编译生成的hex文件芯片才会在仿真运行时执行程序。还有两个配置细节容易被忽略。时钟频率要设成8MHz因为代码里用的是外部晶振HSE配置仿真的时钟源也要对得上芯片的RCC dream里默认使用了外部HSE所以如果仿真里不把晶振接上去程序跑不动。搭好芯片后把电源、复位电路、启动模式配置引脚按最小系统接上测量一下RESET脚的电平和BOOT0的电平确保MCU处于正常启动状态。4.2 传感器等效模拟方案仿真环境里没有MQ-2模块的完整模型DHT11虽然有第三方模型但时序兼容性一直不稳定。我的做法是在PA1上接一个电位器调节电位器输出电压来等效模拟MQ-2的AO输出。电位器上方接5V中间滑动端接PA1的串阻这样电位器输出电压可以在0到接近5V之间变化经过分压钳位后ADC就能读到对应的模拟量。温度传感器同理我在另一个ADC通道也接一个电位器软件里把电压值映射成温度。比如0.0V对应0℃3.3V对应100℃线性映射即可。仿真嘛目的是验证逻辑链路是否正确温度值精确不精确无所谓。蜂鸣器在Proteus里接上去后通常不会真发声所以我用两个LED并联在蜂鸣器两端作为替代看LED的闪烁频率就能判断蜂鸣器是在慢速短鸣还是连续长鸣。继电器也用LED代替继电器吸合对应LED点亮程序里能明显看到报警时那个“LED”亮起来了。4.3 仿真中验证状态转换仿真工程搭建好之后启动运行按下述步骤验证整个状态机接通电源绿色LED点亮OLED或虚拟终端显示State:NORMAL此时所有输出保持正常。缓慢调节烟雾电位器将PA1电压从0.1V慢慢提升到0.8V观察黄色LED开始闪烁终端打印State:WARNING。把电压拉回0.3V状态应该回到NORMAL注意这里用的是滞回阈值不是0.6V而是0.45V左右才复位。继续调高电位器到1.5V以上红色LED点亮终端打印State:ALARM替代继电器的LED也点亮。把电压降到1.0V左右状态回到WARNING而不是直接回NORMAL这也是滞回逻辑作用。同时把烟雾电位器和温度电位器都调到高位状态跳到DANGER所有LED点亮此时不管怎么调低电压系统都不会自动恢复按键确认后才复位。跑通这条链路就说明状态机的核心逻辑没有问题。我建议仿真阶段就把每个阈值打印到串口这样对比起来特别直观比盯着LED猜状态靠谱得多。4.4 仿真与实板的差异提醒仿真验证不等于万事大吉有几个差异必须心里有数仿真里的ADC模型是理想的实际STM32的ADC会有±2到±3个LSB的噪声所以实板上需要滤波算法仿真里不滤波也能跑通。仿真里电位器调节是完美的阶跃变化实际烟雾浓度的变化是缓慢的、带波动的时序上要宽容得多。Proteus里的STM32外设模型比Keil仿真要简化中断优先级、定时器精度等细节不会暴露问题实板调试会冒出一堆时序相关的坑。仿真的电源是理想的实板上一旦继电器吸合电压瞬间跌落ADC读数可能跳变几十个LSB这是仿真里永远不会出现的场景。所以我的建议是仿真用来验证代码逻辑正确性实板用来验证电路可靠性两者结合才是完整的开发流程。5. 实板调试记录DHT11时序、电源干扰、阈值漂移5.1 预热期基线漂移导致的误报第一版代码烧进去开板通电我还挺得意——OLED显示正常传感器读数也稳定结果没过3分钟系统自己从NORMAL跳到了WARNING。我看了一眼串口日志烟雾电压从0.12V慢慢爬到了0.3V然后又回落带着系统一起在NORMAL和WARNING之间反复横跳。问题出在MQ-2的预热特性上。MQ-2加热丝上电后传感器内部温度还没稳定表面电导率会经历一个较长的漂移过程一般要3到10分钟才能真正稳定。这段时间里输出电压不是恒定的而是先爬升再回落。如果系统一上电就按最终的阈值判断预热期的爬升段就会被误判成烟雾浓度升高。最终解决办法是在软件里加了一个“基线自动标定”机制系统上电后进入30秒的初始化阶段期间连续采样烟雾电压取30个样本的中位数作为SMOKE_CLEAN_BASE基线值之后的烟雾浓度百分比全部在这个基线上计算。这样一来无论环境本身的背景电压是多少系统都能自适应。基线的30秒内OLED会显示“Calibrating…”处理好之后才进入正常状态。这个机制上线运行后预热误报就再也没有出现过。5.2 继电器反电动势复位MCU项目第一次接上真实继电器做联动测试继电器吸合的一瞬间MCU直接复位了。我用逻辑分析仪抓了瞬时波形发现5V电源线上出现了一个近200ms的低压凹坑电压跌到了3.8V左右。这就是继电器线圈吸合时感性负载电流冲击导致的电压跌落。第一轮修复我加了续流二极管但没解决根本问题后来又分析了一遍续流二极管能解决断电时的反电动势尖峰但解决不了吸合瞬间的电流浪涌。继电器驱动三极管导通时线圈和排风扇同时启动瞬间电流可能超过1A准备不充分的5V电源直接被拉垮。最终方案是三重保障继电器线圈两端并1N4007续流二极管反向尖峰有泄放通路。5V电源入口加大容量储能电容我用的是1000uF电解电容和100uF陶瓷电容并联。继电器模块的信号线串联一个330Ω电阻再接PB1降低线圈驱动对数字电路的影响。三重措施一起上再抓波形电压跌落从200ms缩短到不到5ms深度从1.2V缩到0.15VMCU稳定运行不再复位。这个坑警示意义很大凡是带继电器、电机、电磁阀的项目电源余量永远要多留30%以上。5.3 DHT11数据错乱与IO速率的坑DHT11在调试到第3天突然开始频繁出现校验错误OLED显示“DHT11 ERR”有时候又能正常读到。我一度怀疑是DHT11坏了换了一个新的结果问题依旧。用逻辑分析仪抓了DHT11数据线上的波形发现高电平持续时间出现了明显偏差有些bit明明应该是1高电平却只有50us程序在40us采样点时判断成了0。查代码定位到问题根源我在读DHT11之前调用了delay_us函数但这个函数在系统定时器中断触发时会被打断。当时系统里跑着一个1ms周期的定时器中断用于系统计数中断处理耗时大约20us而DHT11的0/1位判断窗口只有40us左右中断一旦插入采样时机就被拉偏了。解决办法是给DHT11读取函数加一个“临界区保护”读取DHT11前关闭全部中断读完40位数据后再恢复。整个读取过程最多持续几百微秒对于系统计时影响微乎其微但对DHT11来说时序完整干净了。加了这个保护之后DHT11连续跑了48小时零错误。5.4 输出设备联动与现场验证所有模块稳定运行后最后做的联动测试是最能验证可靠性的一步。我在实验室里分别模拟了三种条件用打火机的电子打火器近距离触发烟雾传感器模块旁边的测试口瞬时释放少量可燃气体。用酒精灯在传感器前方缓慢加热使环境局部温度上升。用棉签蘸酒精在传感器附近挥发模拟烟尘浓度缓慢升高。实测下来系统从正常到预警大约2到3秒从预警到报警大约5到10秒排风扇在报警状态会自动启动。酒精蒸气那一次MQ-2对可燃气体也很敏感提前了大概15秒报警这个时间窗口对人员疏散来说非常关键。不过说实话在真正撤离的同时我还得手动断开酒精炉的火焰所以系统本身的自动断气/断电功能暂时没有启用因为实验室灭火器的实际摆放位置和系统逻辑配合还需要再确认一下安全性。5.5 串口日志的时间戳和状态记录调试过程中串口日志是最大的帮手但一开始我把日志输出做得太随意后来才整理成规范格式。推荐大家也按照这个格式来[001234] T28.3 H52 Smoke0.43V StateNORMAL ActionOK [001344] T28.5 H53 Smoke0.67V StateWARNING ActionSLOW [001368] T29.1 H54 Smoke1.24V StateALARM ActionRELAY_ON [001372] T30.2 H55 Smoke1.89V StateDANGER ActionRELAY_ON_BUZZ时间戳由系统滴答定时器维护每一条日志都有精确的时间点。有了时间戳事后回放“系统在什么时间进入警报状态”“持续了多久”“阈值变化曲线什么样”就非常方便。我甚至建议在日志末尾追加一列Volts_raw用来和最终电压做对比排查传感器本身的漂移问题。6. 开源复现清单与后续扩展方向6.1 从原理图到代码的完整复现路径如果你拿到开源仓库资料想复现这套系统路径很清晰按下面顺序推进先打开原理图和PCB文件用立创EDA或者KiCad导入理清各模块的连接关系重点看电源分路、ADC信号链、继电器驱动电路三部分。再打开Proteus仿真工程生成hex文件跑一遍仿真的前置验证确认自己没有在原理图阶段埋雷。买齐元器件在洞洞板上实现最小系统核对外设接线。推荐先单独调通LED亮灭、OLED显示再接入传感器最后接继电器分模块验证。将代码工程导入Keil MDK在Debug模式下编译运行打开串口调试助手观察日志。最后上实物联调做烟雾和温度模拟测试按需要微调阈值。如果你希望完全按PCB来做立创EDA的工程文件已经包含在开源仓库里直接去嘉立创下单打板贴上元器件就行我已经完成过一版样板验证。6.2 值得扩展的几个方向这套系统的结构是开放式的往上叠加功能非常容易加ESP8266或ESP32模块把烟雾浓度、温度、状态通过MQTT传上局域网用手机小程序远程查看实验室没人的时候也能收到告警推送。加一个火焰传感器红外检测专门盯明火和烟雾传感器形成双通道交叉验证。加CO传感器MQ-7实验室电器火灾初期CO浓度上升明显比烟雾还早一步。改成多节点组网每个实验桌一个终端节点用RS485总线串联到管理室的大屏看板。把继电器从一路扩到两路一路控制排风扇一路用电磁阀控制燃气切断阀门。6.3 个人实际使用体会整个项目从设计到跑通我最深的体会就一句话代码是逻辑的骨架电路是逻辑的肌肉只有两者咬合才能真正落地。仿真能让你有信心实板调试才能让你看清问题长什么样。特别是DHT11时序和继电器电源这两个坑仿真里永远遇不到但实板上百分百会遇到只能说每一个坑踩过之后这套系统才真正属于你。另外开源的意义不只是给人一份能直接运行的代码更是让后来者少走弯路。我在工程资料里把所有阈值的推导过程和测试记录也都附上了包括为什么选0.6V作为预警阈值、为什么滞回区间设0.15V这些开发时的思考过程比代码本身更有参考价值。如果你们复现时哪里卡住了或者有更好的设计思路欢迎直接来交流这类项目多做一套实验室就多一分安全保障。 
长河君 · 2026/9/29 5:09:17 · 阅读 1.2k STM32实验室消防预警系统：烟雾温度三级响应开源实战
实验室里最怕的不是着火那一刻而是着火前没人发觉的那十几分钟。传统安防摄像头盯着门外过道对室内烟雾初起基本无感烟雾报警器又往往只在浓度很高时才动作等响起来已经是火烧眉毛。所以我自己动手做了一套基于STM32的实验室消防预警控制系统把烟雾浓度和温度两个最关键的物理量同时盯住按风险等级分三级响应从声光提醒到自动启动排风扇整个项目代码、原理图、仿真工程全部开源可以直接下载复现。这套系统不挑基础只要会一点STM32和C语言就能玩转就算你完全没做过项目跟着原理图和仿真跑一遍也能把整个嵌入式开发的链路摸通。这里我把完整的设计思路、电路细节、代码逻辑和调试踩过的坑一次说清楚。1. 实验室火灾为什么难预警这个系统的设计定位1.1 传统方案的空白点很多人觉得实验室消防安全有现成方案其实仔细拆开看缺口非常大。摄像头监控只能看到明火烟雾初期摄像头画面上也就是一层薄雾不盯着看根本发现不了常规的离子式烟感灵敏度虽高但实验室里经常有酒精灯、加热台、焊锡烟这些正常操作烟感在实验室里误报率极高装久了大家习以为常真出事反而没人当回事。更关键的是实验室火灾很多不是爆燃而是缓慢的阴燃过程比如电路板过热冒烟、锂电池隔膜热失控、化学品放热反应这些场景的特点是“先出烟、后出火”中间有一段宝贵的预警窗口期。这个窗口期大概有多长取决于燃烧物和环境。聚氨酯泡沫、电路板环氧树脂这类材料阴燃阶段可以持续几分钟到十几分钟温度从正常缓慢爬升到着火点。如果系统能在温度异常、烟雾浓度超标的第一时间分层报警值班人员完全来得及断电、疏散、拿灭火器处理。但如果没有任何预警等肉眼看到明火整间实验室已经处于不可控状态了。1.2 系统功能边界与使用场景这套消防预警控制系统核心功能就三句话感知烟雾浓度和环境温度按风险程度分级报警联动执行器自动干预。具体的运行逻辑我设计成这样正常状态绿色指示灯常亮OLED屏显示温湿度和烟雾浓度所有继电器断开。预警状态烟雾浓度或温度超过第一档阈值黄色指示灯闪烁蜂鸣器每2秒短鸣一次OLED显示“注意烟雾浓度偏高”提示现场人员自查。报警状态烟雾或温度超过第二档阈值红色指示灯常亮蜂鸣器连续急促鸣叫继电器吸合排风扇自动启动排烟降温。危险状态烟雾和温度同时严重超标所有指示灯全亮蜂鸣器持续长鸣继电器保持吸合同时串口向上位机发送“DANGER”事件需要人工按键确认复位。需要说明的是这套系统定位是“预警和辅助干预”不是替代消防喷淋和气体灭火系统。它最适合的场景是电子实验室、化学实验室、设备机房、配电间这类空间不大、易燃物集中、有人长期值守的场所。实际部署时可以多个节点组网每个试验台放一个终端汇总到管理室看板。1.3 为什么选STM32做主控这个项目早期我考虑过用51单片机核算下来发现存在三个问题ADC只有8位烟雾传感器输出电压的微小变化根本分辨不出来片上Flash和RAM太小想加个OLED显示和串口日志就得拼命省空间主频太低DHT11的单总线时序控制虽然没问题但以后想加ESP8266联网、加多个传感器51就力不从心了。换成STM32F103C8T6之后这些问题全部迎刃而解。Cortex-M3内核跑72MHz12位ADC可以精确感知烟雾传感器毫伏级的电压变化64KB Flash和20KB RAM让代码结构可以写得很规整3个USART和丰富的GPIO也为后续扩展留足余量。最关键是这个芯片的资料满天飞任何一个小问题都能搜到答案对开源项目来说这决定了别人能不能顺利复现。如果拿它跟F103RCT6比C8T6少了部分引脚和存储空间但对这个项目来说完全够用而且成本只有RCT6的一半左右。2. 硬件选型与原理图设计每一路信号怎么走通2.1 模块选型与引脚规划我尽量选择模块化的传感器和执行器这样复现门槛低有现成的排针可以直接插在洞洞板上。完整清单如下模块型号/规格数量作用主控STM32F103C8T6核心板1系统主控烟雾传感器MQ-2模块带比较器1检测烟雾/可燃气体温湿度传感器DHT111测温、测湿显示屏0.96寸OLED SSD1306 I2C1显示实时数据蜂鸣器有源蜂鸣器 5V1声光报警继电器模块5V单路继电器1控制排风扇按键轻触开关3布防/消音/复位稳压芯片AMS1117-3.313.3V供电引脚分配我在原理图里这样规划的PA0烟雾传感器数字输出DO备用用来做快速断线检测PA1烟雾传感器模拟输出AOADC1_IN1核心采样通道PA2按键1布防/撤防PA3按键2消音PA4按键3系统复位确认PB6DHT11数据线PB8OLED SCLPB9OLED SDAPB0蜂鸣器控制PB1继电器控制PB10绿色LED正常PB11黄色LED预警PB12红色LED报警这个引脚分配有个好处把ADC输入和数字IO分开模拟信号不会受到数字翻转的干扰可能是因为把DHT11的PB6配成开漏输出4.7kΩ上拉I2C的PB8/PB9也是开漏两个总线互相独立工作时序不会打架。2.2 MQ-2烟雾传感器的信号链设计MQ-2的工作原理是传感器内部有二氧化锡半导体加热丝通电后表面吸附氧分子当遇到可燃气体或烟雾时氧分子脱附电导率上升。模块上自带一个比较器和一个可调电位器数字输出DO可以调节灵敏度阈值模拟输出AO则直接反映当前气体浓度对应的电压值。这个模块用起来有一个所有新手都会掉进去的坑它需要5V供电而且加热丝要消耗不小的电流。我实测正常工作电流在150mA左右预热瞬间能到180mA以上。所以在原理图里MQ-2模块的VCC不接在STM32核心板的3.3V端而是直接从USB的5V母线上取电。AO输出接到PA1时注意AO最高输出电压会接近5V而STM32的ADC输入范围是0到3.3V超出就会烧引脚。解决办法有两种一种是在AO引脚串联10kΩ电阻再进ADC利用STM32内部上下拉做分压另一种更规范的做法是加一个3.3V稳压二极管钳位或者用电平转换电路。我这个项目里用的是简单可靠的分压方案10kΩ串阻 3.3V稳压管到地。原理图上看PA1节点最高电压被钳在3.5V以内理论上已经完全保护了。2.3 DHT11单总线时序与上拉设计DHT11数据线采用单总线协议一条线上既有主机到从机的命令又有从机到主机的数据回传所有通信全靠精确的时序控制。硬件上最容易被忽略的是上拉电阻。DHT11模块很多已经在板子上集成了一颗10kΩ上拉电阻但如果买的是裸传感器就必须自己在数据线上加4.7kΩ到10kΩ的上拉电阻否则通信会非常不稳定。在MCU侧还有两个细节值得说。第一DHT11的GPIO要配置成开漏输出模式因为开漏模式下引脚可以被外部上拉电阻拉到标准电平等加上单片机内部有保护二极管这样即使DHT11拉低总线时MCU误输出高电平也不会发生电流倒灌。第二DHT11规格书上写着“采样周期必须大于2秒”每次读取间隔如果小于1.5秒模块就会不响应我在软件里专门做了一个读取节流不管主循环跑多快至少间隔2.5秒才发起一次新读取。2.4 声光报警与继电器驱动电路这个项目的执行器有蜂鸣器、LED指示灯和继电器。蜂鸣器和继电器都不能由GPIO直接驱动原因很简单GPIO在3.3V下最多输出约20mA的电流而蜂鸣器需要的电流在30mA以上继电器线圈更是要70mA左右直接接会拉低GPIO电压严重时直接烧毁引脚。我的驱动方案是NPN三极管开关电路。以蜂鸣器为例STM32的PB0通过1kΩ电阻接到S8050三极管的基极蜂鸣器的正极接5V负极接三极管的集电极发射极接地。当PB0输出高电平时三极管导通蜂鸣器形成回路开始鸣叫。这里两个细节很关键基极串1kΩ限流电阻防止GPIO过流蜂鸣器两端反向并联一个1N4148二极管这里是无源蜂鸣器才严格需要不过有源蜂鸣器并联一个也能吸收感性负载的反向电动势。继电器电路类似只是继电器线圈感性更强反电动势更大续流二极管必须用1N4007这种额定电流1A的功率二极管。我见过好几起继电模块板上明明有续流二极管但MCU还是复位的案例问题往往出在地上——继电器的地和MCU的地是同一根长导线大电流瞬间在接地回路上产生压降导致MCU复位。所以原理图里我把继电器地线单独走线一段在最靠近电源端的地方才和MCU地汇合。2.5 电源拓扑与滤波整个系统用一个USB接口供电5V进来后分两路走5V直接给MQ-2加热器、蜂鸣器、继电器、OLED屏供电。5V经过AMS1117-3.3稳压到3.3V给STM32、DHT11、LED指示灯供电。AMS1117是低压差线性稳压器输入输出压差低至1V左右所以5V转3.3V完全不需要散热片。关键是输入输出电容不能少输入侧放10uF钽电容并联0.1uF陶瓷电容输出侧放10uF电解电容并联0.1uF陶瓷电容。这一步能有效滤除MQ-2加热器带来的纹波以及继电器吸合瞬间的电压跌落。在STM32的VDD脚和VDDA脚处我还各加了一个100nF去耦电容。别小看这几个电容实测中ADC采样值的跳动幅度可以从50个LSB降到5个LSB。如果要在ADC方面追求更高精度可以让VDDA通过一个磁珠和VDD隔离但我实测在这个项目场景里800mV的烟雾电压变化量级磁珠带来的提升不大所以就没有画进去。3. 预警状态机与主控代码如何让系统分层响应3.1 软件框架前后台轮询架构这种规模的嵌入式项目用实时操作系统RTOS是杀鸡用牛刀用复杂的中断驱动框架又容易把自己绕晕。我选了最常见也最稳定的方法一个超级循环在循环里按时间片轮询各个任务模块。主循环伪代码如下while (1) { system_task_run(); // 按键扫描与系统状态处理 sensor_task_run(); // 传感器数据采集与滤波 display_task_run(); // OLED实时刷新 alarm_task_run(); // 预警状态机调度 uart_log_task_run(); // 串口日志输出 }每个任务模块内部自己判断时间是否到达比如传感器采集模块内部维护一个时间戳距离上次采集超过2秒才执行DHT11读取ADC则每100ms采一轮。这种写法的好处是任何一个子模块出问题都不会导致系统完全死锁排查起来也清晰。DHT11时序要求严格读取期间会被几个微妙级的延迟阻塞但整体影响不大那个阻塞顶多150us循环里不算事。3.2 ADC采样与滑动滤波ADC读取烟雾传感器输出电压是整套系统的眼睛这个环节的精度直接影响误报率。我用的ADC1的通道1也就是PA112位分辨率采样时间设置为55.5个ADC时钟周期这样输入阻抗匹配更好读到的值更稳定。核心代码如下float smoke_voltage_read(void) { uint32_t sum 0; uint16_t adc_value; // 连续读取16次 for (uint8_t i 0; i 16; i) { ADC_RegularChannelConfig(ADC1, ADC_Channel_1, 1, ADC_SampleTime_55Cycles5); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) RESET); adc_value ADC_GetConversionValue(ADC1); sum adc_value; } adc_value sum / 16; // 转换成实际电压参考电压3.3V float voltage ((float)adc_value / 4095.0f) * 3.3f; return voltage; }为什么要循环16次取平均因为MQ-2模块的AO输出本身有小的波动加上ADC采样过程中的噪声单次采样值跳动可能到几十个LSB。16次平均可以把噪声摊平同时读取耗时约1ms对系统响应速度没有影响。MQ-2输出电压和气体浓度不是线性关系它本质上是电阻比率的对数变化。在工程上我们不需要精确到ppm只要把电压值映射成一个“烟雾浓度百分比”用来做阈值判断就够用。映射公式我写在软件里float smoke_level (voltage - SMOke_CLEAN_BASE) / (SMOKE_ALARM_TH - SMOKE_CLEAN_BASE); if (smoke_level 0.0f) smoke_level 0.0f; if (smoke_level 1.0f) smoke_level 1.0f;这里的SMOKE_CLEAN_BASE是上电基线标定阶段测得的清洁空气电压值SMOKE_ALARM_TH是报警触发电压实际项目中我通过测试设定为1.2V。这样烟雾浓度从0到100%在OLED上显示直观调阈值也方便。3.3 DHT11驱动一次完整的单总线握手DHT11读写时序是整个项目里最容易写崩的模块我把每一步都拆开讲。整个过程分三个阶段起始信号、响应信号、数据位流。起始信号主机把数据线拉低至少18ms再拉高20到40us。这个拉低18ms是关键DHT11需要这段时间来识别到主机请求。有些人用20ms也没问题但太长浪费CPU太短模块完全无反应。响应信号DHT11检测到起始信号后会把数据线拉低80us然后拉高80us表示“准备发送数据”。主机在拉高后需要等待如果等了足够时间还没看到低电平就说明模块未就绪或者传感器损坏。数据位流紧接着DHT11开始发送40位数据每个bit都先拉低50us然后通过高电平的持续时间来区分0和1。高电平约26到28us代表0约70us代表1。在主机侧我使用延时法采样等低电平结束后延时40us再读电平如果电平为高说明是1否则是0。这个40us的窗口刚好落在两者中间区分度很好。uint8_t dht11_read_bytes(uint8_t out[5]) { uint8_t i, j; uint8_t byte 0; // 1. 起始信号 GPIO_ResetBits(DHT11_GPIO, DHT11_PIN); delay_us(18000); GPIO_SetBits(DHT11_GPIO, DHT11_PIN); delay_us(30); // 2. 等待响应 if (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET) return 1; while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) RESET); while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET); // 3. 读取5个字节 for (i 0; i 5; i) { for (j 0; j 8; j) { while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) RESET); delay_us(40); byte 1; if (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET) byte | 1; while (GPIO_ReadInputDataBit(DHT11_GPIO, DHT11_PIN) SET); } out[i] byte; byte 0; } // 4. 校验前4字节之和的低8位等于第5字节 if (((out[0] out[1] out[2] out[3]) 0xFF) out[4]) return 0; return 2; }返回码0代表成功1代表模块无响应2代表校验失败。我在主循环里如果连续3次读到非0的返回码就在OLED上显示“DHT11 ERR来自”。这个容错逻辑很重要实验室环境传感器偶尔被烟雾呛一下也会出错不能因为一次读取失败就直接让整个系统报警更不能死循环卡住。3.4 三级预警状态机的实现状态机是这段程序的核心思维把所有可能的状态整理成一张图系统在任何时候只处于其中一个状态状态之间通过明确的迁移条件切换。这比用一串if-else堆逻辑要清晰得多也方便后续扩展。我把状态定义成四档typedef enum { FIRE_ST_NORMAL 0, FIRE_ST_WARNING, // 一级预警 FIRE_ST_ALARM, // 二级报警 FIRE_ST_DANGER // 三级危险 } fire_state_t;状态机调用的核心函数void fire_state_run(void) { float temp get_temperature(); float smoke_v get_smoke_voltage(); uint8_t key_confirm read_key_confirm(); switch (current_state) { case FIRE_ST_NORMAL: if (temp TEMP_WARN_TH || smoke_v SMOKE_WARN_TH) current_state FIRE_ST_WARNING; break; case FIRE_ST_WARNING: if (temp TEMP_ALARM_TH || smoke_v SMOKE_ALARM_TH) current_state FIRE_ST_ALARM; else if (temp TEMP_WARN_TH_REC smoke_v SMOKE_WARN_TH_REC) current_state FIRE_ST_NORMAL; // 滞回退出 break; case FIRE_ST_ALARM: if (temp TEMP_DANGER_TH smoke_v SMOKE_DANGER_TH) current_state FIRE_ST_DANGER; else if (temp TEMP_ALARM_TH_REC smoke_v SMOKE_ALARM_TH_REC) current_state FIRE_ST_WARNING; break; case FIRE_ST_DANGER: // 危险状态只能由人工按键确认后复位 if (key_confirm) current_state FIRE_ST_NORMAL; break; } }对应的执行器输出函数就很简单了void fire_action_run(void) { switch (current_state) { case FIRE_ST_NORMAL: led_green_on(); led_yellow_off(); led_red_off(); buzzer_off(); relay_off(); break; case FIRE_ST_WARNING: led_green_off(); led_yellow_toggle(); led_red_off(); buzzer_slow(); relay_off(); break; case FIRE_ST_ALARM: led_green_off(); led_yellow_off(); led_red_on(); buzzer_fast(); relay_on(); break; case FIRE_ST_DANGER: led_green_on(); led_yellow_on(); led_red_on(); buzzer_always_on(); relay_on(); break; } }这里有个细节值得注意预警和报警的退出阈值跟进入阈值不一样。比如进入预警是电压超过0.6V但退出预警要等到电压回落到0.45V以下。这就是“滞回比较”目的很明确——防止烟雾浓度在阈值附近抖动时系统在正常和预警两个状态之间来回横跳蜂鸣器一会儿响一会儿停几分钟就能把值守的人整到麻木。继电器就更需要滞回逻辑了频繁吸合释放会严重缩短触点寿命。3.5 OLED显示与串口日志输出OLED用I2C接口SSD1306控制器读取。我在开源代码里做了两层封装底层是ssd1306_write_cmd和ssd1306_write_data上层是简单的字符和字符串绘制函数。这样移植到任何I2C屏都很方便换引脚只需要改宏定义。主界面显示逻辑void display_task_run(void) { static uint32_t last_disp_time 0; if (millis() - last_disp_time 200) return; last_disp_time millis(); char line[32]; sprintf(line, T:%.1fC H:%d%%, get_temperature(), get_humidity()); ssd1306_draw_string(0, 0, line); sprintf(line, Smoke:%.2fV, get_smoke_voltage()); ssd1306_draw_string(0, 2, line); sprintf(line, State:%s, state_name[current_state]); ssd1306_draw_string(0, 4, line); ssd1306_refresh(); }串口日志通过PA9和PA10输出配置成USART1波特率115200每秒打印一轮关键数据格式是temp28.3 hum52 smoke0.43 stateNORMAL。这个日志在调试阶段救过我很多次尤其是判断传感器数据是否漂移、状态是否正确迁移。整个系统调试时不要凭感觉把日志数据拉到电脑上用Excel或matplotlib画一条曲线看趋势很多问题一眼就能发现。4. Proteus仿真没有实体模块也能跑通逻辑4.1 仿真工程搭建与芯片加载很多想复现的人卡在没有实体硬件的门槛上其实仿真完全能解决大部分问题。我用的是Proteus 8.9版本新建工程后从元件库拾取STM32F103R6芯片别纠结C8T6和R6的差异仿真模型的外设资源差别不大。关键一步是双击芯片打开属性对话框在“Program File”里加载Keil编译生成的hex文件芯片才会在仿真运行时执行程序。还有两个配置细节容易被忽略。时钟频率要设成8MHz因为代码里用的是外部晶振HSE配置仿真的时钟源也要对得上芯片的RCC dream里默认使用了外部HSE所以如果仿真里不把晶振接上去程序跑不动。搭好芯片后把电源、复位电路、启动模式配置引脚按最小系统接上测量一下RESET脚的电平和BOOT0的电平确保MCU处于正常启动状态。4.2 传感器等效模拟方案仿真环境里没有MQ-2模块的完整模型DHT11虽然有第三方模型但时序兼容性一直不稳定。我的做法是在PA1上接一个电位器调节电位器输出电压来等效模拟MQ-2的AO输出。电位器上方接5V中间滑动端接PA1的串阻这样电位器输出电压可以在0到接近5V之间变化经过分压钳位后ADC就能读到对应的模拟量。温度传感器同理我在另一个ADC通道也接一个电位器软件里把电压值映射成温度。比如0.0V对应0℃3.3V对应100℃线性映射即可。仿真嘛目的是验证逻辑链路是否正确温度值精确不精确无所谓。蜂鸣器在Proteus里接上去后通常不会真发声所以我用两个LED并联在蜂鸣器两端作为替代看LED的闪烁频率就能判断蜂鸣器是在慢速短鸣还是连续长鸣。继电器也用LED代替继电器吸合对应LED点亮程序里能明显看到报警时那个“LED”亮起来了。4.3 仿真中验证状态转换仿真工程搭建好之后启动运行按下述步骤验证整个状态机接通电源绿色LED点亮OLED或虚拟终端显示State:NORMAL此时所有输出保持正常。缓慢调节烟雾电位器将PA1电压从0.1V慢慢提升到0.8V观察黄色LED开始闪烁终端打印State:WARNING。把电压拉回0.3V状态应该回到NORMAL注意这里用的是滞回阈值不是0.6V而是0.45V左右才复位。继续调高电位器到1.5V以上红色LED点亮终端打印State:ALARM替代继电器的LED也点亮。把电压降到1.0V左右状态回到WARNING而不是直接回NORMAL这也是滞回逻辑作用。同时把烟雾电位器和温度电位器都调到高位状态跳到DANGER所有LED点亮此时不管怎么调低电压系统都不会自动恢复按键确认后才复位。跑通这条链路就说明状态机的核心逻辑没有问题。我建议仿真阶段就把每个阈值打印到串口这样对比起来特别直观比盯着LED猜状态靠谱得多。4.4 仿真与实板的差异提醒仿真验证不等于万事大吉有几个差异必须心里有数仿真里的ADC模型是理想的实际STM32的ADC会有±2到±3个LSB的噪声所以实板上需要滤波算法仿真里不滤波也能跑通。仿真里电位器调节是完美的阶跃变化实际烟雾浓度的变化是缓慢的、带波动的时序上要宽容得多。Proteus里的STM32外设模型比Keil仿真要简化中断优先级、定时器精度等细节不会暴露问题实板调试会冒出一堆时序相关的坑。仿真的电源是理想的实板上一旦继电器吸合电压瞬间跌落ADC读数可能跳变几十个LSB这是仿真里永远不会出现的场景。所以我的建议是仿真用来验证代码逻辑正确性实板用来验证电路可靠性两者结合才是完整的开发流程。5. 实板调试记录DHT11时序、电源干扰、阈值漂移5.1 预热期基线漂移导致的误报第一版代码烧进去开板通电我还挺得意——OLED显示正常传感器读数也稳定结果没过3分钟系统自己从NORMAL跳到了WARNING。我看了一眼串口日志烟雾电压从0.12V慢慢爬到了0.3V然后又回落带着系统一起在NORMAL和WARNING之间反复横跳。问题出在MQ-2的预热特性上。MQ-2加热丝上电后传感器内部温度还没稳定表面电导率会经历一个较长的漂移过程一般要3到10分钟才能真正稳定。这段时间里输出电压不是恒定的而是先爬升再回落。如果系统一上电就按最终的阈值判断预热期的爬升段就会被误判成烟雾浓度升高。最终解决办法是在软件里加了一个“基线自动标定”机制系统上电后进入30秒的初始化阶段期间连续采样烟雾电压取30个样本的中位数作为SMOKE_CLEAN_BASE基线值之后的烟雾浓度百分比全部在这个基线上计算。这样一来无论环境本身的背景电压是多少系统都能自适应。基线的30秒内OLED会显示“Calibrating…”处理好之后才进入正常状态。这个机制上线运行后预热误报就再也没有出现过。5.2 继电器反电动势复位MCU项目第一次接上真实继电器做联动测试继电器吸合的一瞬间MCU直接复位了。我用逻辑分析仪抓了瞬时波形发现5V电源线上出现了一个近200ms的低压凹坑电压跌到了3.8V左右。这就是继电器线圈吸合时感性负载电流冲击导致的电压跌落。第一轮修复我加了续流二极管但没解决根本问题后来又分析了一遍续流二极管能解决断电时的反电动势尖峰但解决不了吸合瞬间的电流浪涌。继电器驱动三极管导通时线圈和排风扇同时启动瞬间电流可能超过1A准备不充分的5V电源直接被拉垮。最终方案是三重保障继电器线圈两端并1N4007续流二极管反向尖峰有泄放通路。5V电源入口加大容量储能电容我用的是1000uF电解电容和100uF陶瓷电容并联。继电器模块的信号线串联一个330Ω电阻再接PB1降低线圈驱动对数字电路的影响。三重措施一起上再抓波形电压跌落从200ms缩短到不到5ms深度从1.2V缩到0.15VMCU稳定运行不再复位。这个坑警示意义很大凡是带继电器、电机、电磁阀的项目电源余量永远要多留30%以上。5.3 DHT11数据错乱与IO速率的坑DHT11在调试到第3天突然开始频繁出现校验错误OLED显示“DHT11 ERR”有时候又能正常读到。我一度怀疑是DHT11坏了换了一个新的结果问题依旧。用逻辑分析仪抓了DHT11数据线上的波形发现高电平持续时间出现了明显偏差有些bit明明应该是1高电平却只有50us程序在40us采样点时判断成了0。查代码定位到问题根源我在读DHT11之前调用了delay_us函数但这个函数在系统定时器中断触发时会被打断。当时系统里跑着一个1ms周期的定时器中断用于系统计数中断处理耗时大约20us而DHT11的0/1位判断窗口只有40us左右中断一旦插入采样时机就被拉偏了。解决办法是给DHT11读取函数加一个“临界区保护”读取DHT11前关闭全部中断读完40位数据后再恢复。整个读取过程最多持续几百微秒对于系统计时影响微乎其微但对DHT11来说时序完整干净了。加了这个保护之后DHT11连续跑了48小时零错误。5.4 输出设备联动与现场验证所有模块稳定运行后最后做的联动测试是最能验证可靠性的一步。我在实验室里分别模拟了三种条件用打火机的电子打火器近距离触发烟雾传感器模块旁边的测试口瞬时释放少量可燃气体。用酒精灯在传感器前方缓慢加热使环境局部温度上升。用棉签蘸酒精在传感器附近挥发模拟烟尘浓度缓慢升高。实测下来系统从正常到预警大约2到3秒从预警到报警大约5到10秒排风扇在报警状态会自动启动。酒精蒸气那一次MQ-2对可燃气体也很敏感提前了大概15秒报警这个时间窗口对人员疏散来说非常关键。不过说实话在真正撤离的同时我还得手动断开酒精炉的火焰所以系统本身的自动断气/断电功能暂时没有启用因为实验室灭火器的实际摆放位置和系统逻辑配合还需要再确认一下安全性。5.5 串口日志的时间戳和状态记录调试过程中串口日志是最大的帮手但一开始我把日志输出做得太随意后来才整理成规范格式。推荐大家也按照这个格式来[001234] T28.3 H52 Smoke0.43V StateNORMAL ActionOK [001344] T28.5 H53 Smoke0.67V StateWARNING ActionSLOW [001368] T29.1 H54 Smoke1.24V StateALARM ActionRELAY_ON [001372] T30.2 H55 Smoke1.89V StateDANGER ActionRELAY_ON_BUZZ时间戳由系统滴答定时器维护每一条日志都有精确的时间点。有了时间戳事后回放“系统在什么时间进入警报状态”“持续了多久”“阈值变化曲线什么样”就非常方便。我甚至建议在日志末尾追加一列Volts_raw用来和最终电压做对比排查传感器本身的漂移问题。6. 开源复现清单与后续扩展方向6.1 从原理图到代码的完整复现路径如果你拿到开源仓库资料想复现这套系统路径很清晰按下面顺序推进先打开原理图和PCB文件用立创EDA或者KiCad导入理清各模块的连接关系重点看电源分路、ADC信号链、继电器驱动电路三部分。再打开Proteus仿真工程生成hex文件跑一遍仿真的前置验证确认自己没有在原理图阶段埋雷。买齐元器件在洞洞板上实现最小系统核对外设接线。推荐先单独调通LED亮灭、OLED显示再接入传感器最后接继电器分模块验证。将代码工程导入Keil MDK在Debug模式下编译运行打开串口调试助手观察日志。最后上实物联调做烟雾和温度模拟测试按需要微调阈值。如果你希望完全按PCB来做立创EDA的工程文件已经包含在开源仓库里直接去嘉立创下单打板贴上元器件就行我已经完成过一版样板验证。6.2 值得扩展的几个方向这套系统的结构是开放式的往上叠加功能非常容易加ESP8266或ESP32模块把烟雾浓度、温度、状态通过MQTT传上局域网用手机小程序远程查看实验室没人的时候也能收到告警推送。加一个火焰传感器红外检测专门盯明火和烟雾传感器形成双通道交叉验证。加CO传感器MQ-7实验室电器火灾初期CO浓度上升明显比烟雾还早一步。改成多节点组网每个实验桌一个终端节点用RS485总线串联到管理室的大屏看板。把继电器从一路扩到两路一路控制排风扇一路用电磁阀控制燃气切断阀门。6.3 个人实际使用体会整个项目从设计到跑通我最深的体会就一句话代码是逻辑的骨架电路是逻辑的肌肉只有两者咬合才能真正落地。仿真能让你有信心实板调试才能让你看清问题长什么样。特别是DHT11时序和继电器电源这两个坑仿真里永远遇不到但实板上百分百会遇到只能说每一个坑踩过之后这套系统才真正属于你。另外开源的意义不只是给人一份能直接运行的代码更是让后来者少走弯路。我在工程资料里把所有阈值的推导过程和测试记录也都附上了包括为什么选0.6V作为预警阈值、为什么滞回区间设0.15V这些开发时的思考过程比代码本身更有参考价值。如果你们复现时哪里卡住了或者有更好的设计思路欢迎直接来交流这类项目多做一套实验室就多一分安全保障。