基于STM32的实验室消防预警控制系统设计与实现

凌晨两点实验室的排风柜还在嗡嗡响隔壁间一台加热设备因为温控失灵已经表面发烫。这类场景在高校实验室并不少见而大多数实验室现有的“消防预警”其实还停留在天花板烟感加灭火器。烟感确实能报警但往往到浓烟弥漫时才触发留给人的反应时间非常有限。这个开源项目就是冲着这个痛点做的基于STM32的实验室消防预警控制系统。项目包含完整的STM32工程代码、可生产的原理图、以及Proteus仿真文件覆盖从传感器采集、阈值判断、声光报警到排风联动、上位机串口监控的整个闭环。如果你正在做嵌入式毕设、课程设计或刚好在给实验室/车间做一个低成本的安全监控装置这套东西可以直接拿来改也能帮你把传感器采集、状态机设计、硬件调试这些基本功彻底打通。1. 做之前想清楚实验室消防预警到底要防什么1.1 实际部署背后的几个真实场景很多人一上来就写代码结果做到一半发现需求和硬件对不上。我建议先花半天把场景捋清楚。实验室消防预警和家用烟雾报警器最大的区别在于实验室的起火类型更复杂有机溶剂、电气设备、加热装置每一类的早期表征都不一样而且实验室通常不是24小时有人值守。按我接触过的几个实际部署场景这套系统至少要覆盖三类情况无人值守时段电气设备老化发热温度缓慢上升需要在明火之前给出预警加热设备干烧产生烟雾需要快速报警并联动排风/切断电源实验过程中试剂少量挥发烟雾浓度瞬时波动但没到火灾级别不能动不动就误报警吓人一跳。这三点直接决定了系统不能用“温度高了叫一声”这么简单的判断逻辑。它需要同时采集温度和烟雾浓度两个维度并且用多级阈值做迟滞判断否则误报率会高到让人把报警器拆了。1.2 从需求到硬件清单元器件选型是取舍的过程场景理清了元器件选型就有依据了。我做这套方案时核心器件如下每一项都是按“实验室环境 低成本 好采购”三个条件筛的模块型号/方案选型理由主控STM32F103C8T6便宜、资料多、ADC和定时器够用72MHz主频跑报警逻辑绰绰有余烟雾检测MQ-2气敏传感器对烟雾和可燃气体都敏感响应速度快模块版/裸传感器都容易买温度检测DS18B20单总线数字输出-55℃~125℃量程不需要额外ADC通道显示LCD1602I2C转接板实时显示温度、烟雾浓度百分比和当前状态I2C只占两根引脚执行5V继电器模块 有源蜂鸣器 LED继电器控制排风扇或切断电源蜂鸣器做声光报警调试ST-Link V2 CH340串口模块下载程序和串口日志输出排查问题必备不建议一上来就塞一堆传感器。火焰传感器、气压传感器、湿度传感器这些东西看着炫但每加一个传感器就多一路故障源。这套系统的核心就两个物理量温度和烟雾够了。1.3 整个系统的信号流向与状态机思路先把数据流画在脑子里DS18B20通过单总线把温度数据送到STM32的某个GPIOMQ-2输出模拟电压经过ADC转换成数字值主控把这两个值做滤波、阈值比较然后根据当前状态决定是否点亮LED、鸣响蜂鸣器、吸合继电器。同时LCD实时刷新串口把关键事件逐条打出来。整个控制逻辑我建议用状态机而不是一堆if嵌套。因为消防系统最关键的两个品质是“稳定”和“可预期”状态机能让系统在任何时刻都清楚自己在做什么也方便后续加“手动复位”“消音”这类交互。后面写代码部分我会给出具体的状态定义和转移条件。2. 原理图那点事最小系统、传感器采集与执行驱动2.1 STM32F103C8T6最小系统别在基础电路上省料很多人画STM32原理图只关注外设最小系统本身反而草草了事。这里我想强调所有莫名其妙的死机、复位、ADC读数漂移八成出在你认为“没什么好画”的最小系统上。一个完整的最小系统包含四块电源STM32的VDD和VDDA都要接3.3V而且VDDA引脚建议串一个10μH左右的磁珠再并一个1μF和一个100nF电容去耦。VDDA是ADC和内部参考电压的供电纹波大了直接表现为采样值跳动。时钟用8MHz无源晶振搭配两个20pF负载电容接到OSC_IN/OSC_OUT。晶振下面尽量不要走其他信号线。复位NRST引脚接10kΩ上拉电阻到3.3V再对地接100nF电容形成标准的RC复位电路。启动配置BOOT0和BOOT1分别经10kΩ下拉到地让芯片从Flash启动避免一上电就进系统存储器。我见过有的原理图把VDDA悬空还把BOOT0直接接地用起来也没问题但ADC精度和下载稳定性确实更差。开源包里给的原理图是按可靠标准来的抄作业就行。2.2 烟雾传感器采集电路分压、阻抗匹配与可调灵敏度MQ-2的本质是一个气敏电阻。它在洁净空气中电阻值较高遇到烟雾或可燃气体时电阻下降。这个电阻变化不能直接被STM32读取需要先构建一个分压电路把它变成电压信号。典型的接法是把MQ-2和一个负载电阻RL串联电源5V供电MQ-2的A、B端作为电阻两端从MQ-2与RL的连接点引出输出电压。这个电压随气体浓度升高而升高MQ-2阻值下降导致RL分压变大。RL选多大很关键我实测下来5kΩ到10kΩ比较合适。如果你用的是市面上常见的MQ-2模块而不是裸传感器模块上其实已经集成了比较器LM393和可调电位器直接引出AO和DO两个引脚。DO输出数字电平AO输出模拟电压。这里有个容易踩的坑AO输出的模拟电压范围取决于模块供电用5V供电输出范围接近0~5V而STM32的ADC引脚最大只能承受3.3V。直接接进去是有风险的。解决办法有两种。一是模块用3.3V供电但部分MQ-2模块在3.3V下加热丝功率不足灵敏度会下降二是在AO输出后面加一个电阻分压网络比如10kΩ串联10kΩ把电压范围压到2.5V以内再用一个100nF电容并联到地做滤波。我的原理图里用的是第二种方案稳。这里顺便说一下ADC输入阻抗的问题。STM32的ADC在采样瞬间会从外部电路抽取电流如果信号源阻抗太高采样值会偏低。MQ-2的等效内阻在几kΩ到几十kΩ之间变化直接接ADC时采样误差会随浓度变化。加上运放跟随器是最稳的但为了控制成本我用了一个100nF电容并联到地让ADC在采样时从电容充电而不是直接从高阻源取电实测误差可以接受。2.3 温度采集为什么选DS18B20而不是DHT11很多做温湿度项目的同学习惯性地用DHT11因为它便宜而且自带湿度和温度。但放在消防预警场景里DHT11有两个硬伤温度分辨率只有1℃精度±2℃量程上限只有50℃轮询一次需要等待较长时间不适合做快速响应的预警。DS18B20是单总线数字温度传感器12位分辨率时温度精度±0.5℃量程-55℃到125℃完全覆盖火灾前期的温度变化范围。而且单总线协议允许你在同一条总线上挂多个传感器如果以后想监控多个点位不用额外占用引脚。DS18B20的数据引脚需要接一个4.7kΩ上拉电阻到3.3V这是单总线协议的要求。原理图里这部分很简单但漏掉上拉电阻的话传感器会完全不工作这是新手最常犯的错误之一。按键消抖和LCD部分就不单独展开了原理图里都是常规接法LCD1602的I2C转接板上已经有上拉电阻直接接PB6/PB7就行。蜂鸣器用的是有源蜂鸣器给高电平就响不需要PWM驱动。2.4 执行机构驱动三极管、续流二极管与继电器选型继电器是这套系统里唯一动作部件也是原理图里最需要讲究的地方。STM32的GPIO引脚最大输出电流只有25mA直接驱动继电器线圈根本带不动必须加一级三极管放大。我的接法是GPIO通过一个1kΩ电阻接S8050三极管的基极发射极接地继电器线圈接在5V电源和三极管集电极之间线圈两端反向并联一个1N4007二极管。这个二极管是续流二极管作用是在三极管关断的瞬间给线圈自感产生的反向电流一个泄放回路防止高压击穿三极管——没有这个二极管的话继电器每动作一次都在冲击你的GPIO和三极管迟早烧掉。继电器选型方面5V线圈的继电器最省事和主控共用电源。但要注意继电器触点电流要留余量。如果用来控制排风扇约50W选10A触点规格的继电器足够如果要控制大功率加热设备最好先切断到接触器。有源蜂鸣器同样不能直接接GPIO我用了和继电器类似的三极管驱动方案只是蜂鸣器电流较小用S8050完全够。3. 代码结构设计一个能长期跑的状态机系统3.1 工程组织与主循环框架代码这块我在开源包里用的是标准外设库不是HAL库。原因有两个一是标准外设库代码量少逻辑直白适合教学和毕设展示二是它的ADC、定时器、GPIO配置代码在网上随便搜都是现成的移植成本低。工程结构分成四个层次User - main.c, stm32f10x_it.c 主函数和中断 App - smoke.c, temp.c, alarm.c 烟雾采集、温度采集、报警逻辑 BSP - lcd1602_i2c.c, uart.c, key.c 硬件驱动 System- 标准外设库的核心里核文件主循环采用超级循环结构定时器每100ms打一个时标主循环按照20ms的周期轮询按键、200ms周期刷新LCD、50ms周期读取烟雾和温度。这样做的目的是让不同任务有不同实时性要求而不是把所有操作都塞进一个大while循环里跑否则LCD刷新慢一点没关系但烟雾检测的响应延迟可能就会错过最佳报警时机。int main(void) { SystemInit(); GPIO_Config(); ADC_Config(); TIM_Config(); UART_Config(); LCD_Init(); Alarm_Init(); // 状态机初始化 while (1) { if (g_20ms_flag) Key_Scan(); if (g_50ms_flag) Sensor_Read(); if (g_200ms_flag) LCD_Refresh(); Alarm_Task(); // 状态机主调度 UART_Log(); } }3.2 传感器驱动与数据处理DS18B20的驱动代码是整个工程里最容易出问题的部分核心是单总线协议的时序。初始化时主机拉低总线至少480μs再释放传感器会拉低60~240μs作为存在应答读一个bit需要主机拉低1~15μs后释放然后在45μs内采样电平。uint8_t DS18B20_ReadByte(void) { uint8_t data 0; for (uint8_t i 0; i 8; i) { data 1; GPIO_ResetBits(GPIOB, GPIO_Pin_1); Delay_us(2); GPIO_SetBits(GPIOB, GPIO_Pin_1); Delay_us(4); if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_1)) data | 0x80; Delay_us(60); } return data; }这段时序代码如果直接在Keil里跑通了说明延时函数校准过。如果你发现读出来一直是0xFF或者0x00不用怀疑就是延时不对或者上拉电阻没焊。MQ-2的读取就简单多了直接读ADC。但要注意的是MQ-2上电后需要预热一两分钟前几十秒的读数会持续漂移。我建议在代码里加一个“上电初始化忽略期”开机前60秒的采样值只用于统计基础电压不参与报警判断。这样避免了上电瞬间的误报。原始ADC值还要换算成浓度百分比。做法是采集洁净空气下的基准电压作为0%浓度然后按线性映射到一个风险值。虽然MQ-2本身的曲线不是严格线性的但作为预警系统分段线性映射已经够用后面第5节的标定方法会具体讲。3.3 预警-报警两级状态机的转移条件报警逻辑是全系统的核心我用了一个简单的三态状态机正常、预警、报警。为什么要分成两级因为火灾从“苗头”到“大火”往往有几分钟的窗口期在这个窗口期拉响急促的警铃会把所有人搞得神经衰弱但完全不做反应又可能错过早期处置机会。三级状态定义如下状态触发条件执行动作NORMAL正常温度 50℃ 且烟雾浓度 30%LED绿灯常亮蜂鸣器关闭继电器断开WARNING预警温度 ≥ 50℃ 或烟雾浓度 ≥ 30%LED黄灯闪烁蜂鸣器低频短鸣每2秒一声提醒人员到场确认ALARM报警温度 ≥ 75℃ 且烟雾浓度 ≥ 50%或单一物理量持续超阈值超过10秒LED红灯快闪蜂鸣器连续鸣叫继电器吸合排风或断电状态转移的核心在于“持续超阈值判断”。我代码里用了一个计数器每次采样如果超过阈值就加1没超过就减1最低为0连续超过20次采样才确认进入报警状态。这个机制能滤掉传感器毛刺和瞬时波动避免因为烧杯冒一下烟就触发排风。报警之后还需要复位方式。我的设计是如果触发源是烟雾需要人工按下复位按键才能解除报警——因为烟雾散了不代表危险解除如果触发源是温度温度降到正常值以下并保持30秒后自动复位。前者保证安全后者减少人工干预。这一个细节在实际使用中很受好评。3.4 显示、按键与串口调试不展示出来就是盲调LCD1602通过I2C转接板只占两个引脚刷屏逻辑很简单每200ms把温度和烟雾浓度百分比打印到第一行把当前状态显示到第二行。按键方面我接了三个独立按键复位、消音、阈值加/减。长按阈值加/减可以调整报警阈值这个功能在部署现场调参时非常有用不用反复改代码重新编译烧录。串口的价值在于排查问题。所有关键事件包括状态转移、阈值变化、传感器原始值都会通过USART1打印到串口助手。到了现场测试阶段我的习惯是USB转串口一直挂着用一条python脚本持续抓取日志同步记录状态变化的时间点和实验现象对照。这会让你很快定位到底是传感器读数错还是状态机逻辑错比猜效率高一个量级。void Alarm_Task(void) { switch (g_alarm_state) { case ALARM_NORMAL: if (g_temp TEMP_WARN || g_smoke SMOKE_WARN) Alarm_SetState(ALARM_WARNING); break; case ALARM_WARNING: if (g_temp TEMP_ALM g_smoke SMOKE_ALM) Alarm_SetState(ALARM_ALARM); else if (g_temp TEMP_WARN - TEMP_HYST g_smoke SMOKE_WARN - SMOKE_HYST) Alarm_SetState(ALARM_NORMAL); break; case ALARM_ALARM: if (g_temp TEMP_RECOVER g_smoke SMOKE_RECOVER) Alarm_SetState(ALARM_NORMAL); break; } }这里的TEMP_HYST和SMOKE_HYST是迟滞量防止状态在临界值附近反复跳变。举个例子预警阈值是50℃如果只在达到50℃时进预警、降到49.9℃就退出那么温度在50℃附近轻微波动时系统会不停地切换状态。加上2℃的迟滞降到48℃才退出状态就稳了。这个迟滞思想同样用于继电器吸合/释放避免排风扇频繁启停。4. 仿真验证先让逻辑跑在虚拟硬件上4.1 Proteus电路搭建与元件清单拿到代码和实物原理图之后你会发现仿真这一步其实最花时间。Proteus里搭电路需要逐元件摆放和连线但好处是所有逻辑验证成本为零不用焊板子、不用担心烧芯片。用到的器件清单我整理了一下照着Proteus库里的名称搜就行器件Proteus库内名称备注主控STM32F103C8Proteus的STM32系列模型温度传感器DS18B20模型支持按键模拟温度变化烟雾传感器用电位器POT代替调整阻值模拟气体浓度变化LCDLM016L或PCF8574LCD用I2C转接时选PCF8574继电器RELAY一个标准继电器模型蜂鸣器BUZZER有源蜂鸣器模型三极管NPN 2N2222或S8050驱动继电器/蜂鸣器虚拟串口VIRTUAL TERMINAL配合代码里的日志输出有一点要提前说Proteus里没有和实际MQ-2特性完全一致的高保真模型不要浪费时间去找。工程上普遍的做法是用一个电位器分压来模拟烟雾传感器的AO输出你转电位器的过程就相当于烟雾浓度从低到高变化。这是一个物理量代理的思路仿真验证的是逻辑和电路结构传感器本身的非线性在实物阶段再校准。4.2 模拟传感器输入的几种手法DS18B20在Proteus里的仿真很有意思模型上的温度值可以通过键盘按键来升高和降低比如按下某个键温度1按另一个键温度-1。这样你可以人为制造“升到75℃以上”的场景完整地走一遍预警状态到报警状态的转移。烟雾侧用POT电位器模拟电压配合ADC采集转动电位器旋钮就能让烟雾百分比从0%爬到100%。我建议你在仿真阶段就把“温度正常但烟雾高”“烟雾正常但温度高”“两者同时高”三种场景全部测一遍重点验证状态机的转移方向和复位逻辑是否正确。还有一个小技巧在Proteus里把LCD和虚拟串口同时挂上一边看屏幕状态一边看串口日志。串口输出的时间戳能让你精确判断报警触发的延时是否符合预期——比如从温度超过阈值到蜂鸣器响起整个流程应当不到200ms。4.3 仿真中发现的两个典型问题我在这套系统的仿真调试中遇到过两个很有代表性的问题写出来给你参考。第一个是继电器驱动部分的仿真报错。Proteus的继电器是有线圈内阻的直接用GPIO高电平驱动线圈电流不够继电器根本不动作。必须要按原理图里设计的那样GPIO经1kΩ电阻驱动三极管基极三极管作为开关控制线圈通路。如果在仿真里偷懒把继电器直接连GPIO就会看到一种经典的“看似连了但完全没反应”的现象。这个时候不是代码问题回去检查驱动电路。第二个问题是虚拟终端不输出任何内容。排查了半天发现是波特率不匹配代码里初始化的是115200bps虚拟终端默认是9600。后来在仿真里把虚拟终端设为115200就看到日志一行行刷出来了。这种问题看着低级但真遇到时很容易让人怀疑代码写错了。仿真阶段就把USART配置和虚拟终端参数对上省得用逻辑分析仪去抓信号。4.4 仿真和实物的差距别把仿真当最终标准仿真能验证逻辑和电路拓扑但别迷信仿真结果我跟你说几个明显的差距真实MQ-2的响应曲线是非线性的而且带有明显的温度和湿度交叉敏感仿真电位器给的是理想线性电压所以仿真里设的阈值百分比到实物上肯定要重新标定。真实继电器有动作时间、触点抖动和电磁干扰开关瞬间会在电源轨上砸出毛刺弄不好直接导致ADC读数波动甚至STM32复位仿真看不到这些。DS18B20的实物通信时序受线缆长度和上拉电阻影响Proteus的模型不会模拟这些物理效应。所以我把仿真定位成“逻辑和结构验证”实物调试验证才是收尾。正确的流程是原理图画完先仿真过一遍逻辑烧进板子后从最小功能开始逐步联调。跳过仿真直接调实物当然也行但你会发现找问题的成本高得多。5. 从仿真到实物烧录、调参和踩坑记录5.1 ST-Link下载问题与Keil配置仿真跑通了实物焊好接下来就是烧录。STM32F103C8T6的板子上一般都有SWD调试接口我的方法和Keil MDK的配置经历了很多次翻车后稳定下来。首先在Keil里选对芯片型号STM32F103C8然后在Debug选项卡里选ST-Link Debugger进入Settings确认能读到芯片ID。如果提示“No Target Connected”最常见的原因是接线问题SWDIO和SWCLK两根线接反、GND没共地、或者板子刚好在复位状态下。第三个原因很隐蔽——按住复位键不放再接ST-Link成功率会高一些这招救过我几次后来知道是接线过长导致SWD时序不稳定缩短到10cm以内问题就消失了。下载前要点开Utilities选项卡在Flash Download里勾选Reset and Run。如果漏掉这一步程序烧进去后不会自动运行非常容易让人误以为是程序本身有问题。另外STM32的Flash容量是64KB如果你开了很多调试功能编译出来的hex超过64KB下载会直接失败或跑飞。这个芯片的RAM只有20KB大型中间变量要注意节省否则会莫名其妙HardFault。5.2 MQ-2预热漂移与阈值标定MQ-2上电之后的漂移是所有用气敏传感器的人都会遇到的第一道坎。刚上电时读数可能从很低的电压慢慢爬升然后缓慢回落这个过程可能需要一分钟甚至更久。所以程序里要有上电初始化忽略期不能一开机就把初始电压当作正常工作点。阈值标定的具体做法我在项目中写了个calibrate函数系统上电并预热60秒后采集100次ADC值取平均记为基准电压。然后把这个基准电压映射为烟雾浓度0%再按比例映射满量程。现场部署时用按键把阈值调到一个合适的位置。我个人的经验是实验室正常通风条件下的ADC值应该在某一个稳定区间你拿打火机的气体短暂靠近MQ-2不要烧到传感器观察ADC值跳变幅度把报警阈值设在正常值上浮50%~80%的位置。太高会导致反应迟钝太低会频繁误报。这个没有固定数值因为每批传感器的基线都不一样标定是必须现场做的。5.3 ADC抖动、继电器反电动势和电源纹波到了实物阶段你会发现仿真里干干净净的ADC读数在实物上竟然是抖的。主要原因有三个MQ-2本身输出波动、电源纹波、以及继电器吸合的瞬间干扰。继电器动作时尽管线圈两端有续流二极管触点通断瞬间的电流变化仍然会在公共电源线上产生瞬态干扰。如果继电器的5V和传感器/主控的3.3V共用一组电源ADC读数在继电器动作前后会出现明显的跳变。解决办法是把功率部分和信号部分分开供电或者至少用DC-DC/稳压芯片给主控单独供电功率地走线加粗。这套系统里我把继电器电源和主控电源用了一颗AMS1117-3.3做了隔离效果明显。软件侧我再补一层滑动平均滤波每50ms采一次保留最近5次求平均。这一个简单措施能把抖动幅值压到原来的三分之一左右而且延迟只有250ms对消防场景完全可接受。uint16_t Smoke_GetFilteredValue(void) { static uint16_t buf[5] {0}; static uint8_t idx 0; uint32_t sum 0; buf[idx] ADC_GetValue(); idx (idx 1) % 5; for (uint8_t i 0; i 5; i) sum buf[i]; return (uint16_t)(sum / 5); }5.4 误报处理抗干扰滤波与报警复位策略误报是预警系统最致命的弱点一套三天两头误报的系统最终会被使用者手动断电反而变成安全隐患。我处理误报的思路是“先滤波再迟滞最后加复位确认”。前面说的滑动平均滤波解决的是传感器随机抖动状态机里的持续超阈值计数解决的是瞬时干扰迟滞区间解决的是临界振荡。这三层处理完实物的误报率已经很低了。剩下的偶发误报基本来自外部环境——比如有人在做实验时倾倒有机溶剂MQ-2确实测到了这不是误报而是真实的浓度波动。这时把报警阈值适当调高一点就好。声光报警的复位策略我前面提到过手动复位和自动复位结合。但还有一个容易忽略的细节预警状态蜂鸣器低频短鸣报警状态连续鸣叫这两种声音的音量和节奏要有明显区分否则现场人员听到声音无法快速判断严重程度。我实测下来预警用频率1Hz的短音报警用连续长音配合不同颜色的LED辨识度最高。6. 开源交付内容与后续扩展方向6.1 项目包含的文件结构整个开源项目打包后主要包含三个部分Keil工程源码、Altium Designer原理图、Proteus仿真工程。源码里有详细的注释特别是状态机那一块每一条转移条件都标注了对应的场景方便你改逻辑。原理图提供的是可编辑的源文件不是截图——这点很重要因为抄作业时你总得改那么一两处。拿到项目后建议按这个顺序做先用Proteus打开仿真工程体会一遍完整的预警-报警-复位流程对照原理图确认每个模块的连接关系特别是电源、ADC、继电器这边打开Keil工程编译下载到自己板子上按第5节的步骤标定MQ-2阈值部署到实际环境。6.2 向“能交付”的系统演进如果你不满足于毕业设计交差而是想把它真正变成一个实验室可以长期运行的安全系统有几个值得做的扩展方向传感器换成RS485总线多个DS18B20挂一条总线分布式采集不同点位温度再加烟雾传感器多点布置主控可以通过485接到值班室。报警信息上云用ESP8266模块把报警事件通过WiFi推送到手机这样人不在实验室也能第一时间知道。联动灭火装置在火灾确认后不是只开排风扇而是切断非必要电源、关闭气瓶阀门这个需要额外的安全联锁设计建议在专业人士指导下进行。从整个项目的开发过程回头看我认为最核心的收获不是那几百行C代码而是建立了一种“场景-架构-验证”的工程思维先想清楚系统要防的是什么再决定用什么传感器、什么逻辑最后用仿真和实物两条路径交叉验证。这套方法论在你以后做任何嵌入式项目时都用得上。