基于STM32的实验室消防预警系统：从硬件设计到开源实践

1. 项目缘起与整体设计思路1.1 为什么选择STM32做消防预警主控实验室场景的消防预警和商用楼宇的系统完全是两码事。商用系统动辄几万块一套走的是总线制烟感加集中控制器而实验室通常就几十到一百多平米里面堆着酒精灯、电烙铁、锂电池组、各种易燃试剂风险点分散但总量不大。用一套工业级方案属于杀鸡用牛刀成本高、布线复杂、后期维护还得请专人。STM32这类MCU刚好卡在性能和成本的甜点区Cortex-M3/M4内核跑个多传感器轮询加逻辑判断绰绰有余片上外设丰富到几乎不用额外扩芯片一片十几块钱的芯片就能把整个系统的控制核心撑起来。我选的是STM32F103C8T6也就是大家常说的“蓝板”或“最小系统板”。这颗芯片在实验室环境里有个天然优势资料多到烂大街学生焊错了、烧了随手换一片就行不用等货期。而且它的GPIO驱动能力、定时器资源、ADC通道数应付温度、烟雾、火焰三类传感器同时采集完全够用。更关键的是它的待机功耗和运行功耗都低配合一个简单的锂电池组就能做成断电后还能撑几个小时的独立设备这在实验室突然断电的场景下特别重要——很多时候火灾就是先从电路故障开始的。1.2 系统架构的取舍逻辑整个系统我拆成了四层感知层、决策层、执行层、交互层。感知层就是传感器阵列决策层是STM32主控执行层包括声光报警和继电器输出交互层是OLED屏幕加按键。这个分层不是为了好看而是为了调试方便。比如你发现误报率高那问题大概率在感知层的阈值设定或者传感器选型上直接换传感器或者调阈值就行不用动主控代码。如果报警逻辑不对那就在决策层改判断条件。这种模块化的思路在开源项目里尤其重要因为别人拿到你的代码第一件事就是按自己的需求改分层清晰能省掉大量读代码的时间。传感器选型上我用了三种DHT11测温湿度、MQ-2测烟雾浓度、火焰传感器测明火。有人会问为什么不用更贵的MQ-135或者工业级烟感原因很简单——实验室场景下MQ-2对液化气、丙烷、氢气、烟雾的灵敏度足够而且价格只要几块钱坏了直接换。DHT11虽然精度一般但测个环境温度趋势完全够用它的单总线协议也简单一根线就能读数据。火焰传感器我选的是带数字和模拟双输出的模块数字输出用于快速触发模拟输出用于判断火焰距离这样既能快速响应又能避免阳光干扰导致的误报。1.3 开源策略与资料组织这个项目我决定开源核心原因是实验室消防设备本身就应该是一个“公共品”。每个实验室都自己从头造一遍轮子既浪费精力又容易因为设计缺陷留下隐患。开源的内容包括三部分完整的Keil工程源码、Altium Designer画的原理图和PCB、Proteus仿真工程。代码里我加了详细的中文注释每个函数上面都写了输入输出和调用注意事项。原理图分成了电源部分、主控部分、传感器接口部分、报警输出部分方便别人按模块参考。仿真工程则是给那些手头没有实物硬件的朋友准备的可以在Proteus里直接跑起来看效果验证逻辑对不对。这里有个经验开源项目最怕的就是“只给代码不给上下文”。所以我额外写了一份README里面列了每个传感器的量程、响应时间、预热时间还有常见问题的排查步骤。比如MQ-2需要预热20秒以上才能稳定输出这个如果不写清楚别人一上电就以为传感器坏了。还有DHT11的读取间隔不能小于1秒否则数据会出错这种细节在数据手册里虽然有但很多人不会仔细看直接写个while循环疯狂读结果就是数据乱跳。2. 核心硬件细节与原理图设计要点2.1 电源部分的防反接与稳压设计实验室消防系统对电源的可靠性要求比普通DIY项目高一个等级。我用的是9V锂电池供电经过LM2596降压到5V再经过AMS1117-3.3降到3.3V给STM32和传感器供电。这里有个细节LM2596的输入输出压差不能太小9V降到5V有4V压差完全没问题但如果用两节18650串联7.4V降到5V压差只有2.4V效率会下降发热会明显增加。所以如果你打算用锂电池组建议要么用三节串联要么直接选低压差稳压芯片。防反接我用了一个PMOS管加一个肖特基二极管。PMOS的导通电阻只有几十毫欧比二极管的正向压降损耗小得多。肖特基二极管是作为最后一道保险万一PMOS击穿了二极管还能挡住反向电流。这个设计在实验室环境里特别实用因为经常有人正负极接反尤其是学生做实验的时候。我实测过反接之后系统完全不工作但不会烧任何东西换过来就能正常跑。2.2 传感器接口的滤波与保护DHT11的数据线我加了一个4.7k的上拉电阻和一个100nF的电容到地。上拉电阻是必须的因为DHT11是开漏输出没有上拉电阻读不到数据。电容的作用是滤掉高频干扰尤其是在电机或者继电器附近没有这个电容数据会偶尔出错。MQ-2的模拟输出我加了一个RC低通滤波截止频率大概在10Hz左右因为MQ-2的输出变化很慢高频噪声全是干扰。火焰传感器的数字输出我加了一个施密特触发器整形避免信号边沿抖动导致MCU误触发中断。这里有个坑MQ-2的加热丝电流比较大大概150mA左右如果和STM32共用一路5V启动瞬间会把电压拉低导致STM32复位。我的解决办法是给MQ-2单独走一路LDO或者至少在5V线上并一个1000uF的电解电容。我试过并470uF还是会偶尔复位换成1000uF之后就稳了。这个细节在仿真里看不出来只有实际搭电路才会遇到。2.3 报警输出与继电器驱动声光报警部分我用了一个有源蜂鸣器加一个高亮LED。蜂鸣器的工作电流大概30mASTM32的GPIO直接驱动有点勉强所以我用了一个S8050三极管做开关。基极电阻选的1k实测下来饱和压降只有0.1V左右蜂鸣器声音很响。LED我串了一个1k的限流电阻亮度足够但不刺眼。继电器我用的是5V的SRD-05VDC驱动电路和蜂鸣器类似但多加了一个续流二极管1N4148防止继电器线圈断电时产生的反向电动势打坏三极管。继电器的输出我留了一个常开一个常闭触点可以接排风扇或者电磁阀。这里要注意继电器触点容量有限一般只有10A/250VAC如果控制大功率设备必须加中间继电器或者接触器。我在原理图上标注了这一点但很多人会忽略直接拿它去控制空调或者大功率排风扇结果触点粘死了。实验室场景下控制个排气扇或者声光报警器完全够用但别拿它当工业接触器使。2.4 原理图绘制中的栅格与标注规范用Altium Designer画原理图的时候栅格设置很关键。我习惯用100mil的栅格这样引脚对齐方便连线不会出现歪歪扭扭的情况。有些人喜欢用50mil甚至更小觉得这样能画得更紧凑但实际上会导致后期改图时连线对不上尤其是移动元件的时候线会断掉。我的建议是原理图阶段用100milPCB阶段再根据封装密度调整。标注方面每个网络标签我都写了明确的功能名比如“DHT11_DATA”、“MQ2_ADC”、“FIRE_DO”而不是用“NetLabel1”这种默认名。这样别人看你的原理图时一眼就能知道这根线是干什么的。电源网络我统一用“5V”、“3.3V”、“GND”这种标准命名避免用“VCC”这种模糊的叫法。还有一点每个元件的位号我都按功能分区编号比如电源部分的电容从C1开始传感器部分的从C10开始这样找元件的时候不用满图翻。3. 软件架构与核心代码实现3.1 主循环的任务调度与时间片分配STM32的主程序我没有用RTOS因为任务数量不多用前后台架构就够了。主循环里我做了三个时间片10ms任务、100ms任务、1s任务。10ms任务负责按键扫描和火焰传感器的数字输入检测因为火焰报警需要快速响应。100ms任务负责读取MQ-2的ADC值和DHT11的数据这两个传感器的响应速度本身就不快读太快没意义。1s任务负责更新OLED显示和检查报警状态因为人眼刷新率有限1秒更新一次足够。这种时间片分配的好处是逻辑清晰每个任务执行时间都很短不会互相阻塞。我试过把所有任务都塞进一个while循环里不加时间控制结果DHT11读取的时候会阻塞整个循环火焰报警响应延迟明显。后来改成时间片之后火焰从触发到报警的延迟稳定在15ms以内完全满足实验室场景的需求。// 主循环时间片调度示例 uint32_t last_10ms 0, last_100ms 0, last_1s 0; while (1) { uint32_t now HAL_GetTick(); if (now - last_10ms 10) { Key_Scan(); Fire_Detect(); last_10ms now; } if (now - last_100ms 100) { MQ2_Read(); DHT11_Read(); last_100ms now; } if (now - last_1s 1000) { OLED_Update(); Alarm_Check(); last_1s now; } }3.2 DHT11单总线驱动的时序细节DHT11的驱动说简单也简单说坑也坑。它的单总线协议对时序要求很严格尤其是微秒级的延时。我用的是HAL库的微秒延时函数但HAL_Delay只能到毫秒级所以我自己用SysTick写了一个us延时。这里有个关键点DHT11的起始信号是拉低至少18ms然后拉高20-40us接着释放总线。如果拉低时间不够DHT11不会响应如果拉高时间太长DHT11会认为总线空闲也不响应。读取数据的时候每一位数据都是以50us的低电平开始然后高电平的持续时间决定是0还是1。26-28us是高电平表示070us表示1。我用的是输入捕获或者简单的while循环计数实测下来while循环更稳定因为输入捕获在中断里处理会有延迟。但while循环有个问题如果传感器坏了一直不释放总线程序会卡死。所以我加了一个超时计数器超过1ms还没读到数据就直接返回错误。// DHT11读取一位数据 uint8_t DHT11_ReadBit(void) { uint8_t retry 0; while (DHT11_DATA_READ() retry 100) { retry; delay_us(1); } retry 0; while (!DHT11_DATA_READ() retry 100) { retry; delay_us(1); } delay_us(40); if (DHT11_DATA_READ()) { return 1; } else { return 0; } }3.3 MQ-2的ADC采样与滑动滤波MQ-2的输出是模拟电压我用STM32的ADC1通道0来采集。这里有个细节STM32的ADC参考电压是3.3V但MQ-2的输出范围是0-5V直接接上去会超过量程。所以我用了一个电阻分压两个10k电阻串联分压比是0.5这样5V对应2.5V在ADC量程范围内。分压电阻的精度直接影响测量精度我用的是1%的金属膜电阻普通碳膜电阻误差太大会导致阈值判断不准。采样方面我用了滑动平均滤波每次采10个点去掉最大值和最小值剩下的8个点求平均。这样能有效滤掉脉冲干扰尤其是实验室里电机启动时产生的尖峰。滤波后的值再和阈值比较超过阈值就触发报警。阈值我设的是1.5V对应的ADC值大概在1860左右。这个阈值不是固定的因为MQ-2的灵敏度会随环境变化所以我加了一个按键校准功能长按按键3秒就把当前值设为基准然后阈值自动设为基准值的1.5倍。3.4 火焰传感器的数字与模拟双路判断火焰传感器我用了双路判断数字输出接外部中断模拟输出接ADC。数字输出用于快速触发只要检测到火焰就立刻进中断置位报警标志。模拟输出用于判断火焰距离ADC值越大说明火焰越近。这样设计的好处是既能快速响应又能避免误报。比如打火机的火焰和阳光中的红外线数字输出都会触发但模拟输出的值差别很大阳光的ADC值通常只有几百而打火机火焰能到2000以上。中断服务函数里我只做一件事置位标志位不做任何耗时操作。因为中断里做太多事情会影响其他任务的实时性。标志位在主循环的10ms任务里处理这样既保证了响应速度又不会阻塞其他任务。这里有个经验外部中断最好加上拉或下拉电阻否则悬空的时候会频繁触发。我用的火焰传感器模块自带10k下拉所以直接接就行但如果你自己搭电路一定要加。4. 仿真验证与实物调试对比4.1 Proteus仿真环境的搭建与局限Proteus仿真我主要用来验证逻辑不指望它能完全模拟真实传感器。DHT11在Proteus里有现成的模型可以直接调温度和湿度。MQ-2没有现成模型我用了一个电位器模拟模拟输出手动调电压来模拟烟雾浓度变化。火焰传感器也是用电位器模拟。OLED我用的是I2C接口的SSD1306Proteus里有库直接调用就行。仿真的最大局限是时序。Proteus的仿真速度取决于电脑性能有时候会跑得比实际慢很多导致DHT11的微秒延时对不上。我的解决办法是在仿真里把DHT11的延时函数改成空操作直接返回固定值只验证主循环的逻辑。等逻辑验证通过了再烧到实物上跑真实的时序。这样分工明确仿真验证逻辑实物验证时序效率最高。4.2 实物调试中的常见问题与排查实物调试遇到的第一个问题是DHT11读不出来。排查了半天发现是上拉电阻忘了焊。DHT11的数据线必须接4.7k到10k的上拉电阻否则总线一直是低电平。第二个问题是MQ-2预热时间不够上电就读数据一直是满量程。后来加了20秒预热延时数据就正常了。第三个问题是继电器吸合时STM32复位原因是电源功率不够继电器吸合瞬间电流太大把5V拉低了。换了一个2A的电源适配器就解决了。还有一个比较隐蔽的问题OLED显示偶尔会花屏。查了很久发现是I2C总线的上拉电阻太大用的是10k导致上升沿太慢高速通信时数据出错。换成4.7k之后就稳定了。这个问题的教训是I2C总线的上拉电阻不能随便选标准模式用4.7k快速模式用2.2k长距离通信还要更小。很多人从模块上拆下来的上拉电阻是10k直接就用结果就是偶尔花屏查半天查不出来。4.3 仿真与实物的差异对照表项目Proteus仿真表现实物表现原因分析DHT11读取稳定无延时要求对微秒延时敏感仿真不模拟真实时序MQ-2输出电位器手动调节需要预热有漂移仿真无化学传感器特性继电器吸合无电流冲击可能导致复位仿真不模拟电源内阻OLED显示始终正常上拉电阻不当会花屏仿真不模拟总线电容火焰响应即时触发有10-20ms延迟仿真无传感器响应时间这张表是我实际对比之后总结的仿真能帮你验证逻辑对不对但绝对不能替代实物调试。尤其是电源和时序相关的问题仿真里根本看不出来。我的建议是仿真跑通之后直接打板做实物实物调试才是真正学到东西的地方。5. 常见问题速查与避坑经验5.1 传感器类问题排查DHT11数据一直为0或者255先检查上拉电阻没有上拉电阻数据线永远是低电平。再检查供电DHT11的工作电压是3.3V到5.5V但3.3V供电时数据线也要上拉到3.3V不能上拉到5V否则会倒灌电流。最后检查读取间隔两次读取之间至少间隔1秒读太快数据会错。MQ-2读数一直满量程预热时间不够MQ-2的加热丝需要20秒以上才能达到工作温度。如果预热够了还是满量程检查分压电阻是否焊错或者传感器是否损坏。可以用万用表直接量MQ-2的模拟输出脚正常应该在0.5V到4V之间变化。火焰传感器误报阳光中的红外线会触发火焰传感器这是原理决定的没法完全避免。解决办法是加一个遮光罩或者用模拟输出判断只有ADC值超过阈值才认为是真火焰。另外火焰传感器的检测角度有限一般只有60度左右安装时要注意朝向。5.2 电源与复位类问题系统频繁复位首先检查电源功率继电器和蜂鸣器同时工作时电流可能超过500mA如果电源只有1A余量不够。其次检查复位引脚STM32的复位引脚内部有上拉但外部最好加一个100nF电容到地滤掉干扰。最后检查看门狗如果开了独立看门狗但没及时喂狗也会复位。ADC读数跳动大检查参考电压是否稳定STM32的VDDA和VSSA要加滤波电容。检查模拟输入线是否远离数字信号线尤其是PWM输出线。如果还是跳动加RC低通滤波截止频率设低一点比如1Hz。5.3 代码与工具类问题Keil编译报错“cannot open source input file”检查头文件路径是否添加Keil的Include Paths里要把所有用到的文件夹都加进去。另外检查文件名大小写Windows不区分大小写但有些编译器区分。ST-Link烧录失败检查接线SWDIO、SWCLK、GND、3.3V四根线必须接对。检查芯片是否被读保护如果被保护了用ST-Link Utility解除保护。检查复位模式有些板子需要把BOOT0接高电平才能烧录。Proteus仿真跑不起来检查晶振频率设置STM32的仿真模型默认是8MHz如果你代码里用的是72MHz要在属性里改。检查电源网络Proteus里VDD和VSS要接对否则芯片不工作。5.4 独家避坑技巧汇总DHT11的延时函数不要用HAL_Delay它只能到毫秒级必须自己写微秒延时。MQ-2的加热丝电源要独立不要和MCU共用一路LDO否则启动瞬间会拉低电压。继电器的续流二极管不能省省了之后三极管用不了多久就会击穿。OLED的I2C上拉电阻用4.7k不要用10k否则高速通信会花屏。火焰传感器的数字输出加施密特触发器不加的话信号抖动会导致频繁中断。原理图里的网络标签要写功能名不要用默认名否则后期改图会疯掉。仿真验证逻辑实物验证时序两者不能互相替代。6. 项目扩展与二次开发建议6.1 接入WiFi模块实现远程报警这个项目最直接的扩展就是加一个ESP8266或者ESP32模块通过串口和STM32通信把报警信息推到手机或者服务器。ESP8266用AT指令就行STM32这边只需要发AT指令和解析响应。我试过用ESP-01S成本不到十块钱稳定性也不错。需要注意的是ESP8266的峰值电流能到300mA电源要单独走一路LDO不能和STM32共用。通信协议我建议用MQTT轻量级适合这种小数据量场景。STM32把温度、烟雾浓度、火焰状态打包成JSON通过ESP8266发到MQTT服务器手机端订阅对应的主题就能收到报警。如果不想自己搭服务器可以用一些公共的MQTT测试服务器但生产环境还是自己搭一个靠谱。6.2 增加备用电池与断电续航实验室断电之后消防系统本身不能断电否则就失去意义了。我加了一个18650锂电池组和TP4056充电模块正常时由9V电源供电并给电池充电断电时自动切换到电池供电。切换电路我用了一个PMOS加一个肖特基二极管实现无缝切换。实测下来2000mAh的电池能撑4个小时左右足够等到人员处理或者电力恢复。这里有个细节电池供电时MQ-2的加热丝耗电很大会显著缩短续航。我的做法是断电后自动降低MQ-2的采样频率从100ms一次降到1s一次这样平均电流能降到50mA以下续航能延长到8小时以上。这个逻辑在代码里加一个电源检测引脚就能实现。6.3 多节点组网与集中监控如果实验室面积比较大或者有多个房间可以做成多节点组网。每个节点用一个STM32加传感器通过RS485或者CAN总线连到集中控制器。RS485成本低布线简单适合几十米的距离。CAN总线可靠性高适合电磁干扰大的环境。集中控制器可以用树莓派或者工控机跑一个简单的Web界面实时显示每个节点的状态。组网的关键是地址分配和冲突避免。我建议每个节点用一个拨码开关设置地址集中控制器轮询各个地址节点收到自己的地址才响应。这样逻辑简单不容易出错。通信协议我定义了一个简单的帧格式帧头地址命令数据校验帧尾。校验用CRC16能有效防止误码。6.4 代码开源与社区协作的注意事项开源这个项目的时候我踩过几个坑。第一个是代码里用了绝对路径别人下载下来编译报错。解决办法是用相对路径或者把路径配置写在单独的配置文件里。第二个是库文件版本不一致我用的是HAL库1.8.0别人用1.7.0编译报错。解决办法是在README里明确写清楚依赖的库版本或者直接把库文件打包进去。第三个是注释太少别人看不懂。解决办法是每个函数都写注释关键变量也写注释宁可多写不要少写。还有一点开源协议要选清楚。我选的是MIT协议允许别人自由使用、修改、商用只要保留版权声明就行。如果你希望别人改进之后也开源那就选GPL协议。协议的选择没有对错关键是要写清楚避免后续纠纷。7. 个人实操体会与最后分享这个项目我从画原理图到打板调试前后花了大概三周时间其中一半时间是在解决各种意想不到的问题。最大的体会是仿真和实物之间的鸿沟比想象中大得多。仿真里跑得好好的代码烧到实物上可能连启动都启动不了。所以我的建议是不要追求一次成功做好打两次板的准备。第一次打板专门用来验证电源和接口第二次打板再优化布局和走线。另一个体会是传感器的数据手册一定要仔细看尤其是时序图和电气参数。DHT11的时序图我看了三遍才完全理解MQ-2的预热曲线也是看了数据手册才知道要等20秒。很多人拿到传感器就直接写代码结果调半天调不出来其实问题就在数据手册里写着。最后分享一个小技巧调试的时候善用串口打印。我在每个关键步骤都加了串口输出比如“DHT11 read success”、“MQ2 value: 1234”、“Alarm triggered”。这样一旦出问题看串口输出就能快速定位是哪一步出错。串口打印的代码在最终版本里可以注释掉但调试阶段绝对不能省。我试过不打印直接调结果一个问题查了一整天后来加上打印十分钟就找到了。