基于STM32的实验室消防预警系统：从传感器选型到开源实战

直接开始。先说个背景：我大学那会儿，实验室里最怕的就是线路老化、设备过载引发火情，尤其是晚上没人值守的时候。市面上的商用消防主机动辄几千块，真要做毕业设计或者个人项目，成本根本扛不住。后来我自己用STM32搭了一套消防预警控制系统，把烟雾浓度、环境温度、火焰状态全采进来，再通过蜂鸣器、OLED屏和继电器联动排风扇，整套做下来硬件成本不到一百块。代码、原理图、仿真工程我全部开源了，今天这篇文章就是把整个项目的设计思路、硬件选型、代码逻辑、仿真调试过程和踩坑记录一次性讲透，适合正在做嵌入式课设、准备电赛或者单纯想练手STM32的朋友。

这套系统本质上解决的是实验室/机房/库房场景下的"无人值守预警"问题。传感器负责采集，MCU负责判断决策，输出端负责声光报警和设备联动。相比纯硬件逻辑电路方案，STM32方案的灵活性高很多——阈值可以随时用按键调，报警逻辑可以通过改代码升级，甚至以后想加WiFi上报、CAN组网，都有充足的IO和通信资源。我会把每一部分掰开揉碎地讲。

1. 项目整体设计与系统架构思路

1.1 需求拆解：消防预警系统到底要解决什么问题

很多人做消防预警项目，上来就堆传感器，结果做出来的东西要么误报率极高，要么该报警的时候不报。我一开始也走过这个弯路。冷静下来重新梳理需求，其实实验室消防预警就三个核心问题：

第一是火情前端感知。火灾发生初期通常有三个特征：环境温度上升、空气中烟雾颗粒浓度增加、出现特定波长的火焰红外辐射。所以传感器方案至少要覆盖温度和烟雾两项，条件允许再加一路火焰传感器。只做单参数检测的方案我不推荐，因为温度传感器对明火响应快但烟还没到，烟雾传感器对阴燃响应快但温度没上来，两者结合才能减少漏报。

第二是声光报警与信息展示。报警不是简单地让蜂鸣器响，还要告诉值班人员“哪个区域出问题、问题有多严重”。所以我用了1602/OLED做现场显示，加上红绿双色LED指示状态，蜂鸣器分二级报警——一级预警间歇响，二级报警连续响。这样人在现场不用看代码也能判断当前风险的等级。

第三是联动控制与远程通知的预留。检测到火情后，如果不能自动切断风险源、启动排烟，那检测的意义就少了一半。系统加了一路继电器输出，正常状态下继电器吸合，报警状态下继电器断开，直接可以控制排风扇、电磁阀或者切断非必要负载电源。后续想在这基础上扩展GSM短信、ESP8266 WiFi上报，只需要在串口资源上做文章。

系统的使用者分为两类：一类是实验室管理员，他们要的是可靠——别没事乱叫，叫了就得有人处理；另一类是正在学STM32的开发者，他们要的是可复制——原理图看得懂、代码能编译烧录、仿真能跑通。所以这个项目从设计之初就定了四个原则：传感器选型要常见、电路结构要清晰、代码模块化要到位、仿真工程要能直接打开运行。

1.2 为什么选STM32F103C8T6而不是51或ESP32

先说结论：STM32F103C8T6是这类课设和入门项目的最优解之一，它既不会像51那样外设捉襟见肘，也不会像ESP32那样把重点引向网络通信而忽略嵌入式基本功。

C8T6的核心配置是72MHz主频、64KB Flash、20KB SRAM，片上集成3个USART、2个SPI、2个I2C、3个通用定时器和1个高级定时器，还有10通道12位ADC。这个外设规模应付烟雾传感器（ADC通道）、温度传感器（单总线或者I2C）、火焰传感器（ADC或GPIO中断）、OLED显示（I2C或SPI）、按键输入（GPIO）、蜂鸣器输出（PWM或GPIO）、继电器控制（GPIO）完全够用，哪怕以后再加LCD、再加一个从机，资源也不会紧张。

跟51单片机比：STC89C52虽然便宜，但ADC得外挂，PWM得靠定时器模拟，代码写起来绕来绕去，而且仿真环境也不太直观。C8T6自带ADC和PWM，硬件设计上省一大截。跟ESP32比：ESP32的优势是WiFi/蓝牙，但如果这个项目不上云，那WiFi模块纯属闲置，反而增加了电源设计和PCB布线的复杂度。用STM32的核心逻辑是：外设刚需、生态成熟、教程丰富，遇到问题网上随便搜都有答案。

1.3 系统整体工作流程设计

这里我花了比较多时间的是状态机设计。消防预警系统如果不做状态分层，代码就会变成一团乱麻：传感器各有各的采集周期、报警有报警的优先级、按键随时可能打断当前状态。我最终把整个系统抽象成五个状态：

正常监控态（NORMAL）：所有传感器轮流采集，OLED刷新显示，蜂鸣器关闭，LED绿灯亮。这是系统99%时间所处的状态。

一级预警态（WARNING）：任意一项参数超过预警阈值但未达到报警阈值，或者短时间内检测到传感器数据异常波动。此时OLED交替显示预警参数，蜂鸣器以低频短鸣提示（比如响0.2秒停2秒），LED黄灯（或者绿灯快闪）指示。这个状态的设计目的是“人文关怀”——提醒管理员有异常趋势，但不需要紧急疏散。

二级报警态（ALARM）：任意一项参数超过报警阈值，或者至少两项参数同时超过预警阈值。此时蜂鸣器连续长鸣，LED红灯常亮，OLED全屏显示“FIRE ALARM”以及超标参数，继电器立即动作（默认断开负载）。这个状态下系统只做一件事：最大程度提醒现场人员处理火情。

参数设置态（SETTING）：按下设置键进入，用“加减键+确认键”逐一调整烟雾报警阈值、温度报警阈值和报警延时。参数保存在STM32内部Flash的最后一个扇区，重新上电不丢失。

自检态（SELF_CHECK）：开机后执行3秒自检，蜂鸣器响一声、LED三轮闪烁、OLED显示“SYSTEM OK”。这一步对实际工程非常重要——你无法确定现场传感器是否损坏，但自检至少能确认MCU、显示、声光通路是完好的。

状态机的核心代码放在后面写。先提醒一句：状态切换用标志位+switch实现，不要用复杂的函数指针数组，否则Debug的时候你根本不知道当前跑在哪条逻辑里。

2. 硬件原理图设计与核心电路解析

2.1 传感器选型对比：DHT11、MQ-2、火焰传感器各自的特性

这个项目我传感器的选型方案是MQ-2烟雾传感器 + DHT11温湿度传感器（只用温度）+ 3路红外火焰传感器。下表是当初我对比过的几个方案：

重点解释一下MQ-2的使用细节。MQ-2内部是二氧化锡半导体气敏材料，加热丝通电后表面吸附氧气，当还原性气体（烟雾、甲烷、丙烷等）接触时，电导率变化，从而在负载电阻上产生电压变化。它输出的是模拟量，不是标准浓度值（比如ppm），所以我们需要标定“报警阈值”而不是“浓度值”。我的做法是：传感器预热5分钟稳定后，采集干净环境下的基准电压作为Baseline，然后在实际测试中用打火机放气或者烧纸片制造烟雾，记录不同烟雾浓度下对应的ADC值，把正常情况下采集到的值乘1.5倍作为预警阈值，乘2.5倍作为报警阈值。这个标定方法比查手册准得多，因为MQ-2的一致性并不好，同一型号不同批次基准电压可能差200mV。

DHT11在这套系统里主要提供环境温度。虽然它的精度只有±2℃，湿度精度只有±5%RH，但实验室消防场景不需要精确到小数点，我们要的是“环境温度趋势”。如果某机房空调故障导致室温从25℃逐步飙到50℃，MQ-2可能还没怎么报警，DHT11已经先触发高温预警了。这个冗余设计很关键。

火焰传感器模块的原理是接收火焰燃烧时发出的红外光（波长约760nm~1100nm），模块上有个运算放大器（通常是LM393），把光强信号放大后输出模拟电压，同时和电位器设定的阈值比较输出数字电平。实测中这玩意儿对打火机火焰非常敏感，距离30cm都能触发数字输出。它的坑在于阳光和白炽灯里也有红外成分，容易误触发。所以我的电路里做了一个处理：火焰传感器的数字输出不直接进中断，而是进ADC，读取模拟量之后再配合“连续3次超过阈值才确认报警”的软件消抖逻辑。

2.2 MCU最小系统与电源设计要点

STM32F103C8T6的最小系统包含四部分：电源电路、复位电路、时钟电路、下载调试电路。

电源方面，我用了典型的USB 5V输入 + AMS1117-3.3稳压方案。AMS1117是LDO，输入5V输出3.3V，最大输出电流1A。需要注意：MQ-2的加热丝电流峰值大约150-180mA，LCD背光再加30-50mA，蜂鸣器驱动30mA，继电器线圈约70mA（如果用5V继电器且持续吸合），全系统实际电流约350mA。AMS1117在压差1.7V、电流350mA时功耗约0.6W，会明显发热但还扛得住。如果你要做产品级设计，建议改成DC-DC降压（比如MP1584、TPS5430），效率高而且发热小。低成本方案里AMS1117没问题，但PCB上要给稳压芯片留好散热焊盘。

复位电路采用10K电阻上拉+100nF电容对地+按键复位，这是标准RC复位电路。时钟用8MHz无源晶振+两个20pF负载电容，MCU内部PLL倍频到72MHz。这里有个容易被忽略的点：晶振下方的PCB不要走其他高速信号线，否则容易干扰起振，严重时系统一上电就死机。

下载调试电路我用了SWD两线制——SWDIO、SWCLK，加上NRST和GND一共4根线。相比JTAG的20针，SWD省IO又省PCB空间，而且下载速度也够用。板上留一个4Pin的2.54mm排针座，接ST-Link或者J-Link都行。

2.3 关键外设电路：蜂鸣器驱动、继电器控制、OLED接线

这三块电路是新手最容易翻车的地方，我说得细一点。

蜂鸣器驱动电路。板载蜂鸣器我用的是5V有源蜂鸣器，内部自带振荡源，给高电平就响。STM32 GPIO输出能力只有几毫安，带不动蜂鸣器，所以必须加三极管放大。推荐用S8050 NPN三极管：蜂鸣器正极接5V，负极接三极管集电极，三极管发射极接地，基极串联1K电阻接GPIO。GPIO输出高电平时三极管导通，蜂鸣器通电发声；输出低电平时截止。注意在蜂鸣器两端反向并联一个1N4148二极管做续流保护，否则关断瞬间产生的反向感应电动势容易击穿三极管。

继电器控制电路。我用的是5V单路继电器模块，但一般不建议直接用GPIO推继电器，而是用NPN三极管驱动。原理和蜂鸣器一样，但继电器线圈阻抗更低、感性更大，所以续流二极管必须接。更稳妥的做法是买光耦隔离型继电器模块（比如带EL357N光耦的），MCU输出经过光耦再驱动继电器，实现强弱电隔离，防止继电器动作瞬间的干扰反冲到MCU。我在项目里用的是普通5V继电器+三极管方案，但这些坑我都踩过了，给你们的建议是：继电器控制脚不要直接接在PA15、PB3、PB4这几个JTAG复用引脚上，除非你重新映射了功能，否则板上电这些引脚默认是调试功能，电平状态不受你控制。

OLED接线。0.96寸I2C OLED，SDA接PB7，SCL接PB6，VCC接3.3V。虽然OLED模块标称支持3.3V-5V供电，但我建议都用3.3V，因为I2C的上拉电阻电平必须和MCU的IO电平一致，混用电压域容易烧模块。选I2C接口而不是SPI接口的原因很简单：少两根线，原理图和PCB走线都简单。缺点是刷新率不如SPI，但显示消防参数这种低频刷新场景完全够用。

2.4 原理图设计实战：从元器件清单到连线布局

原理图设计我是在立创EDA专业版上画的，因为在线方便、元件库全、而且可以直接生成嘉立创打板文件。画原理图有几个经验分享给你们：

不要用总线画法把一堆信号全拉成总线再网络标签，除非你非常熟悉，否则排查起来人要疯。我习惯每个模块独立画在矩形区域内，模块之间用网络标签互联。比如传感器区放三个传感器的原理图符号，电源区放USB座、稳压、滤波电容，MCU区放芯片和最小系统，执行器区放蜂鸣器和继电器。每块区域右下角标注模块名称，打印出来对照PCB焊接时一眼就能找到位置。

关键的滤波电容不要省。每个芯片的VCC引脚旁边放一个100nF去耦电容，而且摆放位置要尽量靠近芯片引脚。注意，这里我说的是PCB布局要靠近，不是原理图上靠近，原理图你随便放，PCB才是关键。电源入口放一个470uF电解电容+一个100nF陶瓷电容，分别滤低频纹波和高频噪声。我实测过，不装100nF电容时OLED画面偶尔会出现水波纹，装了之后立即消失。

原理图完成后要做电气规则检查（ERC），查两类问题：一是单端网络，就是只连了一根线没有对端，说明有信号漏接；二是电源短路，比如3.3V网络和GND网络被同一个元件短接。ERC过了再转PCB。

3. 核心代码实现与软件逻辑拆解

3.1 工程结构规划：模块化写法才是可维护的关键

代码工程我按模块划分，每个模块一个.c文件配一个.h头文件，这是嵌入式开发的基本素养。整个工程包含以下模块：

这个分法的主要思路是每个模块只干一类事，模块之间通过函数接口交互，比如display_task只负责显示，它不关心报警状态怎么产生，只接收“显示什么”的数据结构。这样改显示逻辑不会影响报警逻辑，Debug的时候也能缩小范围到具体某个文件。

3.2 传感器采集与软件滤波：ADC多通道采样实战

MQ-2输出接在PA4（ADC1_IN4），火焰传感器模拟输出接在PA5（ADC1_IN5）。STM32的ADC是12位的，读出来是0-4095的数字量。初始化的时候有几个要注意的参数：

void ADC_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; ADC_InitTypeDef ADC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_ADC1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4 | GPIO_Pin_5; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN; // 模拟输入模式 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); ADC_InitStructure.ADC_Mode = ADC_Mode_Independent; ADC_InitStructure.ADC_ScanConvMode = DISABLE; // 单通道模式，后面用多路切换 ADC_InitStructure.ADC_ContinuousConvMode = DISABLE; ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right; ADC_InitStructure.ADC_NbrOfChannel = 1; ADC_Init(ADC1, &ADC_InitStructure); ADC_Cmd(ADC1, ENABLE); ADC_ResetCalibration(ADC1); while(ADC_GetResetCalibrationStatus(ADC1)); ADC_StartCalibration(ADC1); while(ADC_GetCalibrationStatus(ADC1)); }

采集的时候用轮询+多次采样取平均：

uint16_t ADC_ReadChannel(uint8_t channel) { uint16_t sum = 0; ADC_RegularChannelConfig(ADC1, channel, 1, ADC_SampleTime_55Cycles5); for (uint8_t i = 0; i < 8; i++) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while(!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)); sum += ADC_GetConversionValue(ADC1); } return sum / 8; }

为什么要做8次采样取平均？因为MQ-2在烟雾环境中输出的模拟电压有噪声波动，单次采样可能在报警阈值边沿附近震荡，导致继电器反复动作。除了平均值滤波，我还在软件里做了延时确认：连续3次采样（每次间隔200ms）都超阈值才进入报警状态，这个措施基本消灭了偶发性误报。

DHT11需要注意它的采样周期不能低于1秒，否则读出来的温湿度可能不变或者直接读错。我的做法是用一个1秒的软件定时器作为采集节拍，DHT11读取成功后才更新显示缓冲，读取失败就用上一次的值，不打断主流程。这里有个技巧：DHT11的时序要求很严格，读数据期间要禁止中断，所以需要短暂地关全局中断再开。

uint8_t DHT11_Read_Data(uint8_t *temp, uint8_t *humi) { // 略去起始信号发送，直接看数据读取部分 __disable_irq(); // 关中断，确保时序精确 for (uint8_t i = 0; i < 40; i++) { while(GPIO_ReadInputDataBit(GPIOC, GPIO_Pin_1) == Bit_RESET); Delay_us(40); if(GPIO_ReadInputDataBit(GPIOC, GPIO_Pin_1) == Bit_SET) { data |= 0x01; } // 移位处理... } __enable_irq(); // 恢复中断 }

3.3 核心状态机：报警逻辑与阈值分级判断

我前面提到系统有五个状态，接下来是核心的状态机代码框架。这是整个项目软件的灵魂，我建议你仔细看逻辑，而不是直接复制。

typedef enum { STATE_NORMAL, STATE_WARNING, STATE_ALARM, STATE_SETTING, STATE_SELF_CHECK } SysState_t; SysState_t currentState = STATE_SELF_CHECK; void StateMachine_Run(void) { // 读取最新传感器数据 SensorData_t data = Sensor_GetLatestData(); // 更新显示 Display_Update(&data); switch(currentState) { case STATE_NORMAL: // 正常态：判断是否进入预警或报警 if (data.smoke >= alarmThreshold.smoke || data.temp >= alarmThreshold.temp) { // 连续3次确认后进入ALARM if (confirmCount >= 3) { currentState = STATE_ALARM; confirmCount = 0; } else confirmCount++; } else if (data.smoke >= warningThreshold.smoke || data.temp >= warningThreshold.temp) { currentState = STATE_WARNING; } break; case STATE_WARNING: // 预警态：阈值升级则进报警，恢复正常则退回正常 if (data.smoke < warningThreshold.smoke && data.temp < warningThreshold.temp) { currentState = STATE_NORMAL; } else if (data.smoke >= alarmThreshold.smoke || data.temp >= alarmThreshold.temp) { currentState = STATE_ALARM; } break; case STATE_ALARM: // 报警态：只执行声光报警和继电器动作，直到人为复位 Alarm_ResetCheck(); // 长按复位键2秒退出报警 break; case STATE_SETTING: break; } // 根据状态驱动输出设备 Alarm_Output(currentState); }

这套状态机的设计有个我在实际测试中发现的细节：一级预警到二级报警之间必须有一个“状态滞后”处理。什么意思呢？如果阈值设置得很紧，烟雾浓度在阈值附近波动，系统就会在NORMAL和WARNING之间反复横跳，蜂鸣器一会儿响一会儿停，特别折磨人。我的做法是：从NORMAL进入WARNING只需要单次超阈值，但从WARNING退回NORMAL需要连续5次采样都低于预警阈值。这就是经典的滞回比较思想，消除临界抖动。

报警延时参数也很关键。我增加了报警延时设置（默认0秒，可调1-60秒），目的是应对短时干扰。比如实验室里有人抽烟，M Q-2检测到烟雾浓度超标，但只是瞬时飘过，延时3秒后浓度回落，就不触发二级报警。真实火情的特点是持续恶化，延时不会掩盖它。

3.4 按键处理与参数存储：一个容易被忽略的稳定性问题

按键我用的是GPIO中断+软件消抖的组合。PA0、PA1、PA2分别接“设置”“加”“减”三个按键，上拉输入模式。按键按下时GPIO电平跳变，触发EXTI中断，在中断服务函数里只做标志位记录，不做实际逻辑处理——中断服务函数里千万不要写延时和大量代码，这是嵌入式开发的铁律。

消抖采用“按下记录+释放确认”的方式。GPIO低电平持续超过30ms才算有效按下，松开后执行一次动作。我用定时器4做1ms时基扫描，主循环里检查按键状态标志：

typedef struct { uint8_t key_state; // 当前电平状态 uint8_t press_flag; // 有效按下标志 uint16_t press_time; // 按下持续时间 } Key_t; void Key_Scan(void) { for (uint8_t i = 0; i < 3; i++) { uint8_t level = GPIO_ReadInputDataBit(KEY_GPIO_PORT, keyPins[i]); if (level == 0) { keys[i].press_time++; if (keys[i].press_time > 30) { keys[i].press_flag = 1; // 确认有效按下 } } else { keys[i].press_time = 0; } } }

阈值参数的存储我用了STM32内部Flash的最后一个小扇区。F103C8T6的Flash是64KB，共64页，每页1KB，我使用最后一页（地址0x0800FC00）来保存烟雾预警阈值、烟雾报警阈值、温度预警阈值、温度报警阈值、报警延时。写入前先擦除整页，擦除Flash期间MCU会暂停执行，所以不要在做关键操作时存参数。

需要注意Flash的擦写寿命是1万次左右，设置参数频繁读写没问题，但不要让程序每次开机都往Flash写一遍——只在参数变化时写，写完后用标志位确认。

3.5 OLED显示界面设计与串口打印配合调试

显示界面我分了三页：

正常界面：第一行显示温湿度，第二行显示烟雾原始ADC值和状态图标。比如“T:25.3C H:60%”“SMK:1200 NORMAL”。这个界面的目的是让管理员一眼知道环境正常。

报警界面：全屏红色（OLED就双色，实际是黄色高亮），第一行“!! FIRE ALARM !!”，第二行显示超标的参数名和数值。报警界面优先级最高，任何其他界面在报警时都会被顶掉。

设置界面：逐项显示当前阈值和闪烁光标。设置项用数字编号，比如“S1:SMK WAR”“S2:SMK ALM”，按键加减调整数值，长按确认退出。闪烁光标实现方法是在主循环里用定时器标志取反光标位置的显示状态，每500ms翻转一次。

同时我会把关键调试信息通过串口1输出到电脑串口助手，波特率115200。主要打印三类内容：系统启动信息、状态切换日志、每2秒一次的传感器采样值。在调试阶段，串口打印的价值远远超过OLED，OLED刷新会占用CPU时间，而且看实时波形不方便，串口配合串口绘图插件（比如匿名上位机）可以直接观察ADC波形变化。

printf("State: %d, SmokeADC: %d, Temp: %.1f, Flame: %d\r\n", currentState, data.smoke, data.temp, data.flame);

4. 仿真方案与调试实录

4.1 Proteus仿真工程搭建：元件选型与接线

做实物之前先做仿真，是我个人非常推荐的工作流。特别是课设阶段，导师要中期检查，你不可能抱着焊了一半的板子去汇报，仿真跑通了至少证明方案可行。

仿真我用的Proteus 8.15，新建工程后添加以下元件：

• STM32F103C6（Proteus库里没有C8T6封装，用C6也能跑，Flash小一点但逻辑一致）
• MQ-2烟雾传感器模型（Proteus的传感器库里有MQ-2简化模型，输入电压变化可以模拟烟雾浓度变化）
• 滑动变阻器（模拟传感器模拟量输出，这个比用MQ-2模型更直观）
• LM016L（1602液晶，Proteus里OLED模型不好找，用1602替代显示功能）
• 蜂鸣器模型、LED、按键、虚拟终端（串口调试输出）

仿真方案里我用滑动变阻器分压输出接入STM32的ADC引脚，转动变阻器就能改变ADC输入电压，等价于改变烟雾浓度。这个方法比用MQ-2模型好在：干扰因素少，你能精确知道当前输入是多少伏，方便验证阈值逻辑。

接线按照实物原理图一一对应：变阻器输出接PA4，按键接PA0-PA2，1602接PB8-PB15，蜂鸣器通过三极管接PA8（定时器1通道1，可以PWM控制音量）。编译Hex文件后在Proteus里双击芯片载入，点击运行就能看到效果。

4.2 仿真环境下验证状态切换与报警联动

仿真调试要验证的关键场景有三个：

场景一：正常状态到一级预警。把变阻器从0V慢慢往上拧，观察OLED（仿真里是1602）显示的ADC数值逐步上升。当滑动超过“预警阈值”对应的电压点后，系统应该进入WARNING状态，蜂鸣器开始间歇鸣叫，串口输出状态切换日志。我实测时发现一个仿真坑：Proteus里RCC配置如果不对，STM32不能启动，LED永远不亮。解决方法是确认代码里SystemInit()正常执行，并且时钟配置HSE为8MHz。Proteus的STM32外设仿真比51慢很多，不要着急，把仿真速度降低到0.5倍再观察。

场景二：一秒内烟雾猛升触发二级报警。快速把变阻器拧到最大位置，此时ADC值瞬间拉高，状态机应该跳过WARNING直接进入ALARM（这是我在代码里加了快速升级逻辑——变化速率超过一定值直接报警，不管是否经过预警）。进入ALARM后继电器断开（仿真里用LED代替继电器负载），蜂鸣器连续鸣叫。这个场景验证的核心是“系统对突发火情有快速响应”。

场景三：复位与参数设置。长按“设置”键，系统进入参数设置态，OLED显示当前阈值，“加/减”键改变数值。修改后退出设置态，重新回到NORMAL态。重点验证Flash存取逻辑——重新上电后阈值是否保持上次设置的数值。Proteus仿真里Flash擦写比较慢，几百毫秒的卡顿是正常的。

4.3 仿真与实物的差异：哪些仿真验证不了

仿真通过不代表实物就能跑，这是很多新手栽过的跟头。我如实说一下仿真环境和实物之间的差距：

第一，传感器响应特性仿真不了真实物理过程。变阻器拧下去，ADC立刻变了，但MQ-2在真实场景中对烟雾浓度的响应有上升沿延迟和恢复延迟，大概几秒到几十秒不等。所以仿真通过只能说明你的代码逻辑没问题，不代表传感器灵敏度设置合理。

第二，电源噪声和电磁干扰在仿真里不存在。实物板子上电机继电器动作瞬间会产生尖峰干扰，可能导致ADC采集跳变或MCU复位。仿真里的“干净电源”掩盖了这个问题。所以实物调试时一定要在电源输入端加好滤波电容，继电器负载要远离传感器走线。

第三，I2C OLED时序问题仿真很难复现。Proteus里我用的是1602替代，IO时序简单得多，不代表你的OLED驱动代码在实物上就正常。实物上OLED不显示，多半是I2C上拉电阻没接、器件地址不对、初始化时序和模块版本不匹配这三个原因，跟仿真毫无关系。

所以我给你们的建议是：仿真验证逻辑正确性，实物验证工程可靠性，两者缺一不可。

5. 实物调试、常见问题与避坑指南

5.1 真实调试过程中踩过的5个坑

做起实物来，问题千奇百怪。我把最典型的问题整理成一个速查表：

最坑的一个问题我单独拿出来讲：继电器动作瞬间STM32死机重启。第一次焊好板子，系统能正常跑，但只要继电器一吸合，OLED直接黑掉，MCU像断电一样。排查了很长时间，最后发现两个叠加问题：一是继电器线圈没有接续流二极管，断开瞬间的反向电动势直接把MCU的3.3V拉崩了；二是电源线太细，继电器吸合瞬间的大电流造成压降，MCU复位。解决方法是：继电器线圈两端并联1N4148（注意方向，负极接正电源），同时把供电线换成至少AWG24以上的导线，电源输入端增加100uF电解电容缓冲。

5.2 阈值参数标定与误报率控制实验

标定阈值是整个项目工期里最花时间的一步。我拿了三种场景做实测：

场景一是干净环境基线。实验室正常通风状态下，MQ-2预热30分钟后ADC读数稳定在800左右（3.3V参考电压，12位ADC，大约0.64V）。这个值作为BaseLine。

场景二是模拟阴燃。用一小团棉花放在电烙铁头上加热冒烟，距离传感器20厘米。烟雾扩散后ADC读数从800升到1400左右，属于“预警区间”（约1.1V）。如果继续冒烟几分钟，可到1800-2200，进入“报警区间”。

场景三是明火。拿打火机在30cm距离点火，MQ-2的ADC直接冲过2800，同时火焰传感器数字输出拉低。这也是系统判断最果断的场景——模拟量和数字量双重确认，立即二级报警。

根据这三组数据，我把预警阈值设在BaseLine1.5=1200（对应ADC值），报警阈值设在BaseLine2.5=2000。温度阈值按DHT11实测设置：实验室正常25℃，预警设为45℃，报警设为60℃（设备过载发热通常会先到40-50℃，人不在现场来得及报警）。这套参数在实际运行两个月里，误报次数是零，真实触发过一次（实验室有人烧坏了电源适配器），从发现到报警大概5秒，排风扇自动开启，效果让人满意。

5.3 实物运行效果与扩展建议

整机装进一个透明的亚克力盒子，传感器探头露在外面，OLED面板贴在盒体正面，端着一个5V 1A的USB电源就能工作。实测整机静态功耗约80mA，报警联动时峰值约350mA，长时间运行稳定。断电重启后自动进入自检，然后恢复工作。

这个项目的扩展空间其实很大。我列几个方向供你们参考：

第一是无线化。在USART2上挂一个ESP8266或者ESP-01S模块，把报警信息和传感器数据通过MQTT协议上报到服务器，手机上就能收到推送。STM32只负责组帧发AT指令，逻辑不复杂。如果选ESP32，甚至可以双核跑——ESP32负责WiFi，通过串口和STM32通信，数据链路很清晰。

第二是CAN总线组网。F103C8T6自带CAN控制器，加一个TJA1050收发器就能把多个节点连起来。每个实验室一个节点，所有节点挂到同一条CAN总线上，监控室主机轮询各节点状态。这个方案比WiFi稳定，适合工业场景，而且是很多实验室的标配功能，写在简历上是很加分的点。

第三用RTOS重构。如果你想挑战一下自己，可以给这个系统引入FreeRTOS，把传感器采集、状态机、显示、按键扫描各分配一个任务，用消息队列传递数据。代码结构会变得更清晰，实时性更强，更重要的是这个项目本身逻辑简单，非常适合作为RTOS入门练手——你不会因为系统复杂度太高而陷入“任务同步地狱”。

6. 开源资源与上手指引

6.1 开源仓库内容清单与文件说明

我把这套系统的全部资料整理在GitHub/Gitee仓库里，包含以下内容：

• 源码工程（Keil MDK 5.32版本，兼容5.36+，C语言编写，注释覆盖率超过30%）
• 原理图（立创EDA格式，包含工程文件和PDF导出件）
• 仿真工程（Proteus 8.15版本，打开即跑）
• 上位机串口调试助手配套脚本（Python版，用于采集传感器数据、可视化坐标图）
• 元器件清单（BOM表，含立创商城编号和参考价格）
• 焊接与调试说明文档（PDF图文版）

仓库根目录的README写清楚了环境版本要求：Keil MDK需要装好STM32F1系列器件包（如果你还不会装，可以先从Keil官网下载DFP，或者用Pack Installer在线装），Proteus版本要在8.10以上，否则打不开仿真文件。

6.2 从零开始复现此项目的三步走建议

第一步，先跑仿真。下载仓库后打开Proteus仿真工程，编译源码生成Hex文件，载入并运行。通过串口虚拟终端观察打印日志，转动滑动变阻器看状态切换。到这一步你就已经把系统的逻辑流程全摸清了。

第二步，画板焊接。把原理图用立创EDA打开，导出Gerber文件下单打样（打样5块也就二三十块钱包邮），等板子的同时备料。焊接顺序建议：先焊电源部分，上电测3.3V；再焊MCU最小系统，用ST-Link下载一个点灯程序验证芯片；最后焊传感器和外设，逐个测试。千万不要一把梭全部焊完再上电，否则出了问题你不知道从哪查起。

第三步，标定参数。装好全部模块后，先预热MQ-2半小时，读取干净环境的ADC基线，然后通过上位机记录打火机测试的ADC变化曲线，把预警阈值和报警阈值改到合理范围。保存参数，之后再放入真实环境试运行几天观察误报率。

6.3 个人建议与经验总结

最后分享一点我做这个项目最大的体会：开源项目最重要的不是代码能不能跑，而是别人拿到你的资料能不能轻松复现。我一开始只放了源码，结果有网友私信我问“原理图在哪”，后来又补了PDF，又有“Proteus打不开”，最后才明白，一个完整的开源项目，应该同时包含源码、原理图、仿真、BOM、调试说明，缺一个都会让复现门槛翻倍。所以我在这次开资料包里把所有能想到的都放齐了，连关键封装的立创编号都标好了——照着买就行，不用自己搜。

另外关于学习路径，我给学生的建议是：不要只抄代码，哪怕你把我的代码烧进去能跑，也要把每个模块的源码打开读一遍，不懂的函数查数据手册或者参考手册。你可以在我的代码基础上修改阈值逻辑、增加新传感器、改显示布局，这个“改”的过程才是真正内化的过程。如果调试中遇到问题，优先怀疑自己的接线，其次是电源噪声，最后才是代码逻辑——这个排查顺序能帮你省下大量的时间。