1. 为什么我要用STM32做一套实验室消防预警系统
实验室这个场景，跟普通办公室或者住宅有个本质区别：危险源密度极高。一个化学实验室里可能同时存在酒精灯、电热板、易燃试剂、高压气瓶，而人员往往在做实验时高度专注，对周围环境变化的感知反而迟钝。我见过太多实验室的火灾苗头都是被隔壁房间的人闻到焦糊味才发现的，等反应过来已经晚了。
市面上成品消防报警器不是没有，但放到实验室里往往水土不服。家用烟感探测器对酒精蒸气容易误报，工业级的多参数探测器价格又直接劝退学生团队。更关键的是，实验室往往需要联动排风、切断电源、声光报警这些定制化动作，成品设备很难灵活扩展。
这套基于STM32的实验室消防预警控制系统，就是冲着这个痛点去的。核心思路是用一颗STM32F103做主控，挂载温度、烟雾、火焰三类传感器，实时采集环境数据，本地做阈值判断和趋势分析，一旦确认异常就触发声光报警、继电器切断实验台电源、并通过串口上报状态。整个项目包含完整的代码、原理图、仿真工程，适合电子类专业学生做课程设计、毕业设计，也适合实验室管理人员拿来做一个低成本的定制化预警方案。
我选STM32F103C8T6这颗芯片，理由很实在：价格便宜（十几块钱）、资料丰富、外设够用、社区支持好。对于这种多传感器采集加逻辑控制加通信上报的场景，它的ADC、定时器、USART、GPIO资源刚好卡在够用且不浪费的位置。你要是上F4或者H7，性能过剩，成本翻倍，对实验室这种批量部署场景不划算。
提示：本文涉及的所有代码、原理图设计思路和仿真配置，都是基于实际可跑通的工程整理，不是纸上谈兵。文中会重点讲清楚每个设计决策背后的原因，以及我在调试过程中踩过的坑。
2. 系统整体架构与核心器件选型逻辑
2.1 三层架构：感知层、决策层、执行层
这套系统的架构不复杂，但分层要清晰，不然后期扩展会乱。我把它分成三层：
感知层负责环境数据采集，包括DHT11温湿度传感器、MQ-2烟雾传感器、火焰检测模块。这三个传感器覆盖了火灾早期最常见的三个特征：温度异常升高、烟雾颗粒浓度上升、明火产生的特定波段红外辐射。
决策层就是STM32F103C8T6主控。它要做的事情比想象中多：轮询采集三个传感器的数据、做滑动平均滤波、跟预设阈值比较、判断是否满足报警条件、管理报警状态机、驱动执行层动作、通过串口跟上位机通信。
执行层包括有源蜂鸣器、LED指示灯、继电器模块。蜂鸣器负责声音报警，LED负责视觉指示（不同颜色对应不同报警等级），继电器负责切断实验台电源或者启动排风扇。
三层之间通过GPIO和ADC接口连接，结构清晰，任何一层出问题都容易定位。
2.2 为什么选DHT11而不是DS18B20或LM35
温度传感器选型这块我纠结过一阵。DS18B20是单总线数字输出，精度高（±0.5°C），但测温范围-55到+125°C，响应速度慢（转换时间750ms），而且单总线协议对时序要求严格，在中断频繁的系统里容易读失败。LM35是模拟输出，精度不错，但需要额外的ADC通道，而且输出是电压信号，长距离传输容易受干扰。
DHT11虽然精度只有±2°C，测温范围0到50°C，但它有两个优势打动了我：一是数字输出，直接给GPIO就能读，不需要ADC资源；二是它同时集成湿度检测，而湿度变化在火灾早期也是一个辅助判断依据（比如某些材料阴燃时湿度会异常下降）。对于实验室常温环境（一般18到28°C），DHT11的量程完全够用。
注意：DHT11的采样周期不能低于1秒， datasheet写的是1Hz，实际用下来建议2秒读一次比较稳。读太快数据会重复或者出错。
2.3 MQ-2烟雾传感器的模拟输出处理
MQ-2是半导体式气体传感器，加热后表面电阻随烟雾浓度变化。它的输出是模拟电压，浓度越高电压越高。这里有个关键点：MQ-2的输出电压范围跟负载电阻RL有关，典型电路里RL取10kΩ时，洁净空气下输出电压大概0.2到0.5V，烟雾浓度高时可以到3V以上。
STM32的ADC是12位，参考电压3.3V，所以分辨率是3.3/4096≈0.8mV。这个精度对MQ-2来说绰绰有余。我在代码里没有直接用原始ADC值做判断，而是先做10次采样取平均，再映射到0到100的浓度百分比，这样阈值设置更直观。
2.4 火焰检测模块的数字与模拟双输出
火焰检测模块我选的是那种带比较器输出的蓝色小板子。它有一个红外接收管，对火焰中的特定波长敏感。模块同时提供数字输出（DO）和模拟输出（AO）。数字输出可以通过电位器调节触发阈值，但我建议用模拟输出接ADC，因为数字输出的阈值调节太粗糙，而且容易受环境光干扰。
实际调试时我发现，打火机的火焰在30cm外就能让AO输出明显变化，但日光灯直射也会造成干扰。所以代码里我加了一个逻辑：火焰检测必须同时满足AO超过阈值且持续时间超过200ms，避免瞬间干扰触发误报。
2.5 继电器模块的驱动隔离
继电器我用的是5V驱动的光耦隔离模块。为什么要光耦隔离？因为继电器线圈在断电瞬间会产生反向电动势，这个尖峰可能通过地线串扰到STM32，导致复位或者GPIO损坏。光耦隔离把控制侧和负载侧完全隔开，STM32的GPIO只驱动光耦内部的LED，电流很小（大概5mA），安全得多。
继电器选型上，我建议选常开触点容量至少10A/250VAC的，因为实验室可能控制的是排风扇或者大功率实验设备。虽然实际电流可能只有几安培，但留足余量没坏处。
3. 硬件原理图设计中的关键细节
3.1 STM32最小系统的晶振与复位电路
原理图这块，STM32最小系统是基础。外部晶振我用的8MHz无源晶振，配合两个22pF的负载电容。这里有个容易忽略的点：负载电容的值要根据晶振规格书上的CL值来算，公式是CL=(C1*C2)/(C1+C2)+Cstray，其中Cstray是PCB走线寄生电容，一般取3到5pF。如果晶振规格书标CL=20pF，那C1和C2大概取33到36pF。我见过有人直接抄别人的22pF，结果晶振起振困难或者频率偏移，就是因为没算这个。
复位电路用经典的10kΩ上拉加100nF电容，再加一个复位按键。NRST引脚内部有弱上拉，但外部再加一个10kΩ更稳。100nF电容的作用是滤除电源上电时的抖动，保证复位信号干净。
3.2 传感器接口的滤波与保护
DHT11的数据线我加了一个4.7kΩ上拉电阻，因为它是开漏输出。线长超过20cm时，建议再加一个100nF电容到地，滤除高频干扰。
MQ-2的模拟输出到STM32的ADC引脚之间，我串了一个1kΩ电阻再加一个100nF电容到地，构成一个简单的RC低通滤波器，截止频率大概1.6kHz。这个滤波器能有效抑制电源纹波和空间干扰，让ADC读数更稳定。
火焰传感器的AO输出同样加了RC滤波，但电阻取10kΩ，电容取100nF，截止频率约160Hz，因为火焰信号的频率成分主要在低频段。
3.3 电源部分的LDO与去耦电容布局
整个系统用5V供电（继电器和蜂鸣器需要5V），STM32需要3.3V，所以用了一颗AMS1117-3.3做LDO降压。AMS1117的压差大概1.1V，5V降到3.3V完全够用。
去耦电容这块，我在STM32的每个VDD引脚旁边都放了100nF陶瓷电容，另外在电源入口放了一个10μF钽电容做储能。这里有个经验：100nF电容要尽量靠近引脚，走线越短越好，否则高频去耦效果大打折扣。我见过有人把去耦电容放在板子另一头，结果ADC采样噪声大得没法看。
3.4 原理图设计中的网络标签与ERC检查
画原理图时，网络标签（Net Label）要规范命名。比如DHT11的数据线我命名为DHT11_DATA，MQ-2的模拟输出命名为MQ2_AO，这样在PCB布局和代码编写时不容易搞混。
画完原理图一定要跑ERC（电气规则检查）。常见的ERC报错包括：输入引脚悬空、电源引脚没有驱动源、输出引脚短接等。我这次画的时候就遇到一个警告：继电器的控制引脚被标记为输出，但STM32的GPIO也是输出，两个输出短接会报错。解决办法是把继电器模块的控制引脚改成输入类型，因为它内部是光耦LED，对STM32来说就是灌电流负载。
4. 软件代码的模块化设计与核心逻辑
4.1 主循环的任务调度：为什么不用RTOS
这个项目功能不算复杂，我最终没有上FreeRTOS，而是用了一个基于系统滴答定时器（SysTick）的时间片轮询调度。原因很简单：任务数量少（传感器采集、数据处理、报警判断、串口通信），任务间没有复杂的同步需求，上RTOS反而增加代码复杂度和调试难度。
具体做法是：SysTick配置成1ms中断，在中断里维护一个全局毫秒计数器。主循环里检查各个任务的时间标志，比如DHT11每2000ms读一次，MQ-2每100ms采样一次，火焰检测每50ms查一次，串口上报每500ms发一帧。这种“时间片轮询”在裸机项目里非常实用，代码量小，逻辑清晰。
// 时间片轮询核心结构 typedef struct { uint32_t lastRun; uint32_t interval; void (*task)(void); } Task_t; Task_t tasks[] = { {0, 2000, DHT11_Task}, {0, 100, MQ2_Task}, {0, 50, Flame_Task}, {0, 500, UART_Report_Task}, {0, 200, Alarm_Logic_Task}, };4.2 DHT11的时序读取与容错处理
DHT11的单总线协议对时序要求比较严格。STM32F103在72MHz主频下，一个NOP大概14ns，所以微秒级延时用循环实现就行。但这里有个坑：如果中断在读取过程中打断，时序就会乱。我的做法是在读取DHT11的整个过程中关闭全局中断，读完再打开。整个过程大概4ms，对系统实时性影响可以接受。
容错处理方面，我加了重试机制：如果连续3次读取失败，就标记传感器故障，在报警逻辑里降级处理（比如只用MQ-2和火焰传感器做判断），同时通过串口上报故障码。
uint8_t DHT11_Read(float *temp, float *humi) { uint8_t retry = 0; while (retry < 3) { if (DHT11_ReadOnce(temp, humi) == SUCCESS) { return SUCCESS; } retry++; Delay_ms(100); } return ERROR; }4.3 MQ-2的滑动平均滤波与浓度映射
MQ-2的原始ADC值波动比较大，直接拿来比较阈值会频繁误触发。我用了滑动平均滤波，窗口大小取10。具体实现是维护一个长度为10的环形缓冲区，每次新采样值覆盖最旧的值，然后求平均。
浓度映射这块，我没有用复杂的曲线拟合，而是用分段线性映射。洁净空气下ADC值大概200到400（12位），我把它映射到0%；烟雾浓度高时ADC值到3000以上，映射到100%。中间分三段线性插值。这样阈值设置就很直观：比如设60%为预警，80%为报警。
#define FILTER_WINDOW 10 static uint16_t mq2_buf[FILTER_WINDOW]; static uint8_t mq2_idx = 0; uint16_t MQ2_GetFiltered(void) { uint32_t sum = 0; mq2_buf[mq2_idx] = ADC_Read(MQ2_CHANNEL); mq2_idx = (mq2_idx + 1) % FILTER_WINDOW; for (int i = 0; i < FILTER_WINDOW; i++) { sum += mq2_buf[i]; } return sum / FILTER_WINDOW; }4.4 火焰检测的持续时间确认逻辑
前面提到火焰检测容易受环境光干扰，所以我在代码里加了一个持续时间确认。具体做法是：每次检测到AO超过阈值时，不立即报警，而是启动一个计数器，连续N次（比如4次，对应200ms）都超过阈值才确认。如果中间有一次低于阈值，计数器清零。
这个逻辑用状态机实现最清晰：
typedef enum { FLAME_IDLE, FLAME_CONFIRMING, FLAME_ALARM } FlameState_t; void Flame_Task(void) { static FlameState_t state = FLAME_IDLE; static uint8_t confirm_cnt = 0; uint16_t ao_val = ADC_Read(FLAME_CHANNEL); switch (state) { case FLAME_IDLE: if (ao_val > FLAME_THRESHOLD) { state = FLAME_CONFIRMING; confirm_cnt = 1; } break; case FLAME_CONFIRMING: if (ao_val > FLAME_THRESHOLD) { confirm_cnt++; if (confirm_cnt >= 4) { state = FLAME_ALARM; } } else { state = FLAME_IDLE; confirm_cnt = 0; } break; case FLAME_ALARM: if (ao_val < FLAME_THRESHOLD) { state = FLAME_IDLE; confirm_cnt = 0; } break; } }4.5 报警状态机与多传感器融合判断
报警逻辑是整套系统的核心。我没有用简单的“任一传感器超阈值就报警”，而是做了一个分级状态机：
一级预警：温度超过40°C，或者烟雾浓度超过60%，或者火焰检测到但持续时间不足。此时黄色LED闪烁，蜂鸣器间歇鸣叫。
二级报警：温度超过55°C，或者烟雾浓度超过80%，或者火焰确认。此时红色LED常亮，蜂鸣器持续鸣叫，继电器动作切断电源。
故障状态：任一传感器读取失败超过3次。此时蓝色LED闪烁，串口上报故障。
多传感器融合的好处是降低误报率。比如夏天实验室空调坏了，温度可能到35°C，但烟雾和火焰都正常，那就只触发一级预警，不会切断电源影响实验。
5. 仿真工程搭建与调试过程实录
5.1 Proteus仿真中STM32模型的选择
Proteus仿真STM32有个坑：不是所有版本的Proteus都自带STM32F103模型。我用的是Proteus 8.13，里面自带STM32F103C6和C8的模型。如果你的版本里找不到，需要单独下载元件库。
仿真里我用的元件清单：
- STM32F103C8（主控）
- DHT11（温湿度）
- POT-HG（电位器，模拟MQ-2和火焰传感器的模拟输出）
- LED-YELLOW、LED-RED、LED-BLUE（状态指示）
- BUZZER（有源蜂鸣器）
- RELAY-SPDT（继电器）
注意：Proteus里的DHT11模型时序跟实物有差异，仿真能跑通不代表实物一定没问题。仿真主要验证逻辑，实物调试才是关键。
5.2 用虚拟串口观察运行数据
仿真里我加了一个COMPIM元件，把STM32的USART1映射到电脑的虚拟串口。这样在电脑上用串口助手就能看到系统上报的数据帧。数据帧格式我设计成：
$DATA,temp=25.3,humi=60,mq2=45,flame=0,state=0,checksum*FF其中state字段：0正常，1预警，2报警，3故障。checksum用简单的异或校验。
通过观察串口数据，可以很直观地看到各个传感器的数值变化和状态切换过程。调试阈值的时候特别有用。
5.3 仿真中发现的逻辑问题与修正
仿真跑起来后我发现一个问题：当MQ-2的模拟输出快速变化时，滑动平均滤波的响应有延迟。比如电位器突然从低转到高，滤波后的值要过好几个采样周期才能跟上。这在真实场景里可能导致报警延迟。
修正方法是：在滤波逻辑里加一个“快速上升检测”。如果当前采样值比滤波值高出一定幅度（比如500），就直接跳过滤波，用当前值参与判断。这样既保留了滤波的稳定性，又保证了突发情况的响应速度。
uint16_t MQ2_GetFiltered(void) { uint16_t raw = ADC_Read(MQ2_CHANNEL); uint16_t filtered = /* 滑动平均结果 */; if (raw > filtered + 500) { return raw; // 快速上升，跳过滤波 } return filtered; }5.4 仿真与实物调试的差异点
仿真跑通之后，我把代码烧到实物板上，发现几个仿真里没暴露的问题：
第一，DHT11在实物上第一次上电读取经常失败，需要等1到2秒稳定。仿真里没这个问题。解决办法是在初始化后加一个2秒延时再开始读取。
第二，继电器的反向电动势对STM32有干扰，仿真里完全看不出来。实物上表现为继电器动作时串口偶尔发乱码。加了光耦隔离和续流二极管之后解决。
第三，火焰传感器在实物上对日光灯敏感，仿真里没模拟这个。后来在代码里加了持续时间确认，并且把传感器安装角度调整了一下，避开直射光。
6. 从实验室场景出发的扩展思路与部署建议
6.1 多点组网与上位机监控
单点预警系统只能覆盖一个房间。如果要覆盖整个实验室楼层，可以考虑用RS485总线把多个STM32节点连起来，每个节点负责一个房间，通过Modbus协议跟中央监控上位机通信。上位机可以用Python写一个简单的GUI，实时显示各房间状态，并记录历史数据。
RS485的好处是抗干扰能力强，传输距离远（1200米），而且支持多点挂载（最多32个节点）。每个STM32节点加一个MAX485芯片就能实现。
6.2 数据记录与趋势分析
现在的系统只做实时判断，不存数据。如果加上一个SD卡模块，把每次采样的数据存成CSV文件，就可以做趋势分析了。比如通过分析温度上升速率，可以在温度还没到阈值时就提前预警。这个思路在工业领域叫“预测性维护”，用在实验室消防上同样有效。
6.3 安装位置与传感器布局经验
传感器安装位置直接影响预警效果。我的经验是：
- 温度传感器放在实验台正上方30到50cm处，避开通风口和空调出风口。
- 烟雾传感器放在房间顶部，因为烟雾上升。但要避开天花板灯座附近，防止热量积聚导致误报。
- 火焰传感器对准实验台区域，但避免正对窗户，防止阳光干扰。
提示：所有传感器线缆建议用屏蔽线，屏蔽层单端接地。实验室里电磁环境复杂，屏蔽线能显著降低干扰。
6.4 代码开源与二次开发建议
这套代码我按模块分成了dht11.c、mq2.c、flame.c、alarm.c、uart.c几个文件，每个文件对应一个功能模块，接口清晰。二次开发时，如果要换传感器，只需要改对应的驱动文件，主逻辑不用动。
如果要加WiFi或者蓝牙上报，可以在UART_Report_Task里把数据帧转发到无线模块，改动量很小。整个工程在Keil MDK 5下编译，芯片包用STM32F1xx_DFP 2.3.0以上版本。
7. 调试过程中踩过的坑与排查思路
7.1 DHT11读取失败：上拉电阻与延时精度
最开始DHT11读取成功率只有一半左右。排查过程：先用示波器看数据线波形，发现STM32发出的起始信号低电平时间不够。DHT11要求主机拉低至少18ms，我代码里用了Delay_ms(18)，但实际因为循环延时不精确，只有15ms左右。改成Delay_ms(20)之后成功率明显提升。
另一个问题是上拉电阻。我一开始用10kΩ，波形上升沿太缓。换成4.7kΩ之后波形干净多了。
7.2 ADC采样值跳动：参考电压与滤波
MQ-2的ADC读数一直在跳，幅度大概±50。排查发现两个原因：一是STM32的VDDA没有单独滤波，直接跟VDD连在一起，电源纹波影响了ADC参考电压。解决办法是在VDDA引脚加一个10Ω电阻串联100nF电容到地。二是采样时间太短，STM32的ADC采样时间设的是1.5个周期，对高阻抗信号源来说不够。改成55.5个周期后，读数稳定多了。
7.3 继电器动作导致MCU复位：电源与地线处理
这个问题最头疼。继电器一吸合，STM32就复位。排查过程：先用万用表看电源电压，发现继电器动作瞬间5V电源跌落到4.2V左右。原因是继电器线圈电流较大（大概70mA），而我的5V电源是USB供电，线损和电源内阻导致压降。
解决办法有三个：一是在继电器线圈两端加续流二极管（1N4148），吸收反向电动势；二是在5V电源入口加一个大电容（470μF）储能；三是把继电器电源和STM32电源分开走线，在电源入口处单点共地。三招下去，复位问题彻底解决。
7.4 串口乱码：波特率与时钟配置
串口一开始发出来全是乱码。检查发现是STM32的USART时钟配置错了。STM32F103的USART1挂在APB2总线上，时钟是72MHz；USART2和USART3挂在APB1上，时钟是36MHz。我代码里USART1的波特率计算用了36MHz的公式，导致实际波特率是设定值的两倍。改成72MHz后正常。
注意：STM32的USART波特率寄存器BRR的计算公式是：USARTDIV = fCK / (16 * baud)。fCK是总线时钟，USART1用PCLK2，其他用PCLK1。这个细节在参考手册里有，但容易看漏。
7.5 火焰传感器误报：环境光干扰与阈值调整
火焰传感器在白天经常误报。排查发现是窗户透进来的阳光含有红外成分，被传感器接收到了。解决办法：一是调整传感器安装角度，避开窗户方向；二是在代码里提高阈值，并且加持续时间确认；三是给传感器加一个遮光筒，只让它“看”到实验台区域。
8. 这套系统实际跑起来的效果与个人体会
实物做出来之后，我在实验室里连续跑了一周。期间做了几次模拟测试：用打火机在30cm外点火，系统在200ms内触发二级报警；用酒精棉球擦拭实验台模拟烟雾，MQ-2在浓度到70%左右时触发一级预警；用热风枪对着DHT11吹，温度到42°C时触发一级预警。整体响应速度和准确性都达到预期。
误报方面，一周内出现了两次一级预警，都是因为实验室有人用酒精灯做实验，温度短时升高到41°C左右。这个属于合理预警，不算误报。真正需要避免的是那种无缘无故的报警，这套系统在加了滤波和持续时间确认之后，没有出现过。
我个人在实际操作中的体会是：硬件项目的难点往往不在代码逻辑，而在电源、接地、屏蔽这些“脏活”。仿真能帮你验证逻辑，但解决不了电磁兼容问题。如果你也在做类似的项目，建议在PCB布局阶段就把电源和地线处理好，继电器和MCU的电源分开走，模拟地和数字地单点连接。这些细节做到位，后期调试能省一半时间。
另外，传感器选型不要追求“高精度”，要追求“够用且稳定”。DHT11精度不高，但在这个场景里完全够用，而且数字接口省事。MQ-2一致性一般，但通过软件滤波和分段映射，实际效果可以接受。关键是理解每个传感器的特性，在代码里做针对性的补偿。
