单片机消防预警项目说实话是个老掉牙的题目但每次看到有人把它重新做出来开源我还是会点进去看一眼。原因很简单这个题目麻雀虽小五脏俱全几乎把嵌入式开发里最常见的那套东西全过了一遍——多传感器采集、ADC转换、单总线时序、状态机调度、声光报警、按键交互甚至还能牵扯到继电器控制和电源设计。对正在找毕业设计方向、或者刚入门想找个完整项目练手的人来说这比单纯点个LED灯有价值得多。这次分享的是一个实验室消防预警控制系统的完整开源方案带代码、原理图和Proteus仿真工程我把它从需求拆解到硬件选型到代码逻辑再到仿真调试全流程过一遍顺便把我在实际调试中踩过的坑也一并整理出来。1. 项目概览与设计思路1.1 实验室消防隐患与项目定位实验室跟普通办公区最大的区别在于里面同时存在易燃试剂、大功率设备和密闭或半密闭空间。一旦出现火情烟雾和温升往往比明火更早出现所以做消防预警的核心逻辑是“尽早感知异常快速声光提醒争取人工处置窗口期”而不是等火烧起来再启动什么自动灭火——对实验室这种场景自动喷淋反而可能造成二次事故。基于这个定位系统用到的传感器就很明确了烟雾浓度、环境温度、以及可选的火焰信号。我的方案里烟雾用的是MQ-2温度湿度走DHT11火焰检测预留了一个数字量接口。主控用STM32F103C8T6这板子便宜、资料多板载资源对一个预警系统来说完全不紧张。输出侧包括蜂鸣器报警、LED闪烁指示、继电器控制排风扇或电磁阀外加一块OLED屏显示实时数据和阈值状态。整个项目解决的核心问题就是让一个只有基础电路知识的开发者能够在一周左右把一套完备的消防预警原型机跑起来——既能理解原理又能复制实现还能源码级二次开发。1.2 系统功能架构拆解先看整体数据流逻辑非常清晰烟雾传感器(MQ-2) → ADC通道 → 数据滤波 → 阈值比较 → 异常判定 温湿度传感器(DHT11) → 单总线时序 → 数据解析 → 阈值比较 → 异常判定 火焰传感器(数字量/模拟量) → GPIO/ADC → 状态读取 → 异常判定 ↓ STM32F103C8T6 主控状态机调度 按键设置 ↓ OLED显示(实时数据) / 蜂鸣器报警 / LED指示 / 继电器联动排风功能上我分了三个层级第一层是“采集显示”实时刷新温湿度和烟雾浓度让值班人员能随时看到环境状态第二层是“阈值预警”超过预设阈值触发蜂鸣器和灯光第三层是“联动控制”异常持续一定时间后继电器动作自动打开排风扇。这个三层设计的好处是就算传感器误报最坏结果也只是排风扇转一会儿不至于直接触发报警器吓到满楼人。按键交互部分我用了三个按键一个进菜单、一个加、一个减。长按进入设置模式后可以调整烟雾和温度的上限值设置完自动存入内部Flash下次开机不用重新设。OLED上会同步显示当前阈值和实测值方便校准。1.3 功能选型背后的取舍为什么不直接买现成的烟雾报警器模块因为市面上绝大多数模块只给出一个“是否超标”的数字量输出你拿不到确切的浓度变化曲线更没法自己设定阈值。消防预警系统的核心恰恰就在阈值逻辑上——不同实验室的允许值不一样烟感探头安装距离不一样环境基线也不一样固定阈值的模块根本没法适配。所以我在设计里特意把MQ-2的模拟量输出接入了STM32的ADC做实时浓度采样。这带来的额外好处是阈值能软件可调而不是焊死在电路上。代价就是需要处理传感器的上电漂移问题这部分我在代码章节详细讲。DHT11选择它的理由只有一个够用且时序简单。实验室消防预警不需要高精度温湿度测量DHT11的±2℃和±5%RH精度足够判断环境是否异常代码层面只需要严格按单总线时序来读。假如你有更高要求代码里预留了DHT22的替换位置只需要改一下读取函数的时序参数。2. 硬件原理图设计与器件选型2.1 主控最小系统STM32F103C8T6典型电路原理图的核心是STM32F103C8T6最小系统这部分没什么可发挥的照着数据手册搭就行。我的电源方案是USB的5V进来先用一个100uF电解电容做输入滤波再经过AMS1117-3.3输出3.3V给主控和传感器供电。选AMS1117的原因简单——封装大好焊接输出稳定对DIY项目来说不容易烧。复位电路用的是经典的RC复位10K上拉电阻加100nF落地电容搭配STM32内部的NRST引脚。有人问过为什么不用专用复位芯片这个项目是用在实验室环境不是汽车电子的严苛场景RC复位配合内部看门狗完全够用没必要多花成本。晶振部分我用了8MHz主晶振加两个20pF负载电容。注意STM32F103也能用内部HSI振荡器省掉外部晶振但在ADC采样场景下内部RC振荡器的精度会对采样稳定性产生微妙影响建议还是把外部晶振焊上。另外我还引出了一个用于RTC的32.768K晶振位置虽然这个项目没有用到RTC但原理图上留了封装后面要扩展定时记录历史数据的时候不用改板子。下载调试接口用的是标准的SWD四线制SWDIO、SWCLK、GND、3V3。有条件就接一个5脚的杜邦座出来调试的时候方便很多。当然如果你习惯用串口ISP下载原理图上也预留了BOOT0和BOOT1的跳线帽位置。2.2 采集端MQ-2烟雾与DHT11温湿度MQ-2的接法有个容易翻车的地方。模块上通常有两种输出数字量DOUT和模拟量AOUT。很多新手图省事只接DOUT结果就是只能判断“有没有超阈值”完全丧失浓度监测能力。我接的是AOUT到PA0ADC1通道0配合一个10K电位器在模块本身上调灵敏度两个自由度配合起来阈值设置才真正灵活。MQ-2上电时需要预热。它的内部是一个加热电阻冷启动时采样值会从很低慢慢爬升大约三到五分钟才稳定。代码里我加了一个“启动稳定期”逻辑——开机前60秒只显示不上报避免开机瞬间的飘高值误触发报警。这个细节一定要做否则每次断电重启系统都会乱叫一通。DHT11的数据线接PB11需要外接一个4.7K上拉电阻到3.3V。这个上拉电阻是单总线通信的硬性要求不能省。有朋友直接把DHT11模块的PCB小板往杜邦线上一插模块上本身自带上拉电阻但如果你是自己焊的传感器裸体上拉忘了加时序会全线崩溃读出的数据全是0xFF漂移值。我在原理图上是画了上拉电阻的焊板时注意一下就好。DHT11的供电电压理论上可以在3.3V到5V之间跑我建议统一使用3.3V。为什么因为STM32的GPIO耐压有限如果你用5V给DHT11供电它的数据线输出高电平也是5V直接怼在PB11上长期运行会缩短MCU寿命甚至直接烧GPIO。3.3V供电虽然让DHT11的测量范围略微受限但在这个项目里完全够用安全第一。2.3 执行与交互声光报警、继电器、OLED蜂鸣器这里有个经典坑。有源蜂鸣器自己带震荡源给电就响可控性好无源蜂鸣器需要外部PWM驱动才能发声代码复杂度更高。我做消防预警当然选有源的用一只NPN三极管S8050做开关驱动而不是直接把蜂鸣器接在GPIO上——蜂鸣器工作电流普遍要20mA以上GPIO直接拉会超手册额定值时间长了GPIO口可能损坏。三极管驱动电路的接法是GPIO通过1K限流电阻接三极管基极蜂鸣器接在集电极和5V电源之间发射极接地基极再并一个10K下拉电阻防止上电误触发。注意蜂鸣器是感性器件断开瞬间会产生反向电动势我并了一个1N4148续流二极管在蜂鸣器两端方向反接正极对地这个二极管能把反向尖峰泄放掉没有它的话报警频率高的时候三极管容易被击穿。继电器控制排风扇用的是低电平触发继电器模块同样通过三极管驱动线圈两端并联一个LED做状态指示。我实际选的是5V单路继电器触点容量10A控制一个实验室排气扇绰绰有余。需要提醒的是继电器驱动和单片机逻辑地一定要共地否则模块没法触发。显示用的0.96寸I2C接口OLEDSCL接PB6SDA接PB7程序里用软件模拟I2C还是硬件I2C都可以。我实测下来STM32F103的硬件I2C偶尔会出现总线锁死问题为了稳定性在代码里直接用的软件模拟I2C牺牲一点CPU时间换可靠性对于这种显示频率不高的场景非常划算。2.4 电源与PCB布局要点整个系统的电源树是USB 5V进来后分三路——第一路直接给继电器模块供电第二路过AMS1117转为3.3V给STM32、OLED、DHT11供电第三路经过滤波电感给MQ-2的加热回路供电。为什么把MQ-2单独拉一路因为它的加热电阻在工作时会有明显的电流波动如果跟MCU共用一条电源线ADC的参考电压会被污染采样值一跳一跳的看起来像传感器坏了。PCB布局方面我画的是双层板。模拟地和数字地在主控芯片下方单点汇合ADC采样电路尽量靠近MCU引脚走线短而粗。DHT11的放置位置要远离蜂鸣器和继电器这两个器件工作时会产生机械振动和电磁干扰离得太近会让温湿度读数在报警瞬间发生跳变。OLED用排针引出做成可插拔结构方便调试时拆下来看主板。3. 软件代码核心逻辑与调试经验3.1 工程结构与初始化流程软件部分我用的是标准库开发的STM32F103工程代码目录结构从写好到现在一直保持三块Hardware放外设驱动Core放主逻辑和中断System放系统时钟和延时函数。这种分层的思路对新手特别友好——传感器出问题就查Hardware逻辑判断出错就查Core不要到处乱翻。主函数的初始化顺序有讲究我按这个顺序来int main(void) { SystemInit(); // 系统时钟初始化设为72MHz Delay_Init(); // 延时函数初始化 OLED_Init(); // OLED初始化 ADC1_Init(); // ADC配置用于MQ-2采样 DHT11_Init(); // DHT11 GPIO配置 Key_Init(); // 按键GPIO配置 Buzzer_Init(); // 蜂鸣器GPIO配置 Relay_Init(); // 继电器GPIO配置 ReadThresholdFromFlash(); // 从Flash读取用户设定的阈值 MQ2_WarmUp_Delay(60); // MQ-2预热稳定期60秒 while(1) { StateMachine_Update(); // 主循环状态机 } }初始化顺序里最容易被忽略的是读取Flash阈值的时机一定要在进入主循环之前完成因为OLED第一屏就要显示阈值。另外预热期间虽然不上报报警但OLED还是要正常刷显示我把“预热状态”作为一个变量传入显示函数让界面上直接显示“WARMING UP”字样这样用户不会以为死机了。3.2 传感器读取与数据滤波MQ-2的ADC读取我配置为12位分辨率VREF是3.3V所以采样值范围是0到4095。代码里我不能直接拿原始采样值跟阈值比较需要转成电压值再换算成跟浓度相关的无量纲数值。我实用性地做了一个映射float MQ2_GetVoltage(void) { uint16_t adc_val ADC_GetValue(); return (float)adc_val * 3.3f / 4096.0f; }这个电压值作为判据已经够了因为MQ-2的电阻随可燃气体浓度变化输出电压单调变化。阈值默认是1.2V约等于室内刚有烟味时的水平用户可以手动调整。ADC数据我是用滑动窗口滤波的取最近10次采样的平均值。这里有个性能小技巧用循环队列维护窗口每次进一个新值就加进去、踢掉最旧的值再除以窗口大小而不是每次重新累加10次否则100Hz的采样频率下CPU开销会白白高10倍。DHT11的读取代码是全项目里最讲究时序的地方。它的单总线协议要求主机先拉低总线至少18ms然后释放并延时20~40us之后读取传感器返回的80us低电平响应和80us高电平准备信号再开始逐位读取40bit数据。每一位的时间窗口在70us左右微秒级延时必须精准。我调试DHT11时发现在72MHz主频下用简单的循环空转做微秒延时编译器开O2优化后延时时间会缩水导致时序错乱。解决方案有两个一是查表校正延时函数的循环次数二是直接用DWT硬件定时器做微秒延时。我后来改用了DWT数据观察点与跟踪单元来精确计时代码稳定多了。3.3 消防判定逻辑与消抖消防预警最怕误报。直接阈值比较的做法在实机上会有问题MQ-2在有人抽烟或者炒菜的实验室里电压值会瞬间飙高又回落如果判定逻辑太灵敏蜂鸣器会跟着一阵狂响。我设计的判定状态机是三态模型typedef enum { STATE_NORMAL, // 正常态不报警 STATE_WARNING, // 预警态超过阈值进入倒计时确认 STATE_ALARM // 报警态预警持续确认后触发 } FireAlarmState;从NORMAL进入WARNING的条件是烟雾电压连续3秒超过阈值不是一瞬间这个连续3秒的判断通过周期计数实现——每100ms检测一次连续30次超标才切换状态。进入WARNING后蜂鸣器不响只是OLED提示“疑似烟雾”从WARNING进入ALARM的条件是累计超标时长超过10秒。这样做之后偶发性烟雾干扰几乎不会触发报警只有持续的浓度异常才会导致真正的警报。温度判定同理DHT11读到的温度超过设定上限默认55℃且持续5秒以上才进入预警。温度与烟雾的逻辑是“或”关系——任何一个超限都会触发预警因为实验室火灾往往伴随温度上升而有些燃烧是不产生大量烟雾的。报警触发后的处理逻辑也要写清楚蜂鸣器以2Hz频率鸣响、LED快速闪烁、继电器吸合排风扇工作。复位报警的方式有两种一是手动按键确认当浓度回落到阈值以下后按OK键清除警报二是自动恢复浓度低于阈值80%且持续30秒后系统自动复位——自动复位的滞回区间一定要有否则浓度在阈值边缘震荡时系统会在报警和正常之间疯狂跳变。3.4 按键阈值设置与OLED显示阈值设置接口我做成了菜单模式这是整个交互逻辑里最磨人的部分。OLED上显示两行上面是当前参数名下面是对应的数值。按键逻辑长按OK键2秒进入设置模式短按切换参数项加键减键调节数值。每调一个参数都会实时把新值写入Flash避免退出菜单时忘记保存。Flash写入用的是内部Flash最后一个扇区地址0x0800FC00F103C8T6有64KB Flash最后1KB留给用户参数。写入前先擦除整个扇区再写入64字节的结构体数据里面包含参数结构体和校验字段我用了简单的CRC8。开机读Flash时先校验CRC通过才加载用户设置不通过就用默认值——这能避免读到全0xFF的空白Flash时把阈值默认成0直接引发误报的尴尬。OLED显示界面分三个页面主页循环显示温度和湿度、烟雾电压值、系统状态第二页显示当前阈值设置第三页是历史报警记录次数。页面切换用短按OK键实现。字体方面我用的是中景园8x16字符点阵数据量小、刷新快在0.96寸OLED上显示四行信息刚刚好。4. 仿真环境搭建与Proteus联调4.1 Proteus器件准备与电路搭建很多人在Proteus里搭这个电路会发现几个元件找不到MQ-2模块、DHT11模块、OLED的I2C模型。我的做法是分开搭——烟雾传感器用“滑动变阻器电压源”的组合模拟因为MQ-2对STM32来说本质就是一个电压源浓度变化反映为电压变化仿真时用一个电位器分压模拟烟雾浓度升降效果非常直观温度传感器用Proteus里的LM35代替。虽然DHT11也能输出温度但Proteus没有现成的DHT11仿真模型硬要用的话得自己写SPICE模型成本太高不如用LM35实现“温度采集”这个功能等价物。这背后其实是一个重要仿真思路仿真验证的核心是逻辑而不是传感器本身行为。你不需要在仿真里复现MQ-2的加热漂移特性只需要验证“电压超阈值→系统报警→排风扇启动”这条链路是否通了。所以我仿真工程的传感器部分全部用等效模型而代码层我把MQ2_GetVoltage()、DHT11_Read()这些函数做了条件编译——在仿真模式下走等效接口在实机模式下走真实驱动同一套主逻辑跑两边都不用改。4.2 仿真中的传感器等效模拟烟雾浓度部分我用一个10K电位器滑片接ADC输入通道两端分别接3.3V和地。旋转电位器时ADC采样电压从0到3.3V连续变化这样就能复现烟雾浓度变化的完整过程。阈值设置成1.2V时旋钮转到大约36%的位置就会触发预警模拟实验操作非常方便不用真的去点烟。温度部分用的是LM35加一个电压源。LM35的输出电压是10mV/℃室温下约300mV。为了模拟温度异常升高我接了一个可调电压源叠加到LM35的输出上用一个加法电路把两个信号合起来送入ADC。旋转电压源就能模拟温升过程很方便验证温度报警路径。有了这些等效模拟联调的关键操作路径就清晰了电路上电后OLED虚拟屏幕应显示当前环境电压值0.5V左右慢慢旋转烟雾电位器当电压超过阈值时系统进入WARNING状态OLED显示变化保持该状态超过10秒后进入ALARM状态蜂鸣器虚拟器件响起继电器动作使风扇电机旋转。这一整套链路跑通整个项目的核心逻辑就算验证通过了。4.3 仿真调试技巧与实物一致性问题Proteus里最容易被坑的是晶振设置和MCU时钟频率不匹配。我吃过一次大亏原理图上画的8MHz晶振但Proteus的STM32模型默认外部时钟是72MHz直接导致代码里所有依赖时间基准的逻辑混乱——延时缩短到原来的1/9OLED初始化一半就卡死。解决方法是双击STM32芯片模型在Clock Frequency里改成72MHz或者干脆把代码里的延时函数改成查询周期计数器的方式不依赖固定的循环延时。仿真中OLED模型嵌入的是SSD1306的接口但Proteus自带的OLED模型对I2C的时序容错比较差软件模拟I2C的延时在仿真里会影响显示。我最后把仿真工程的显示驱动切换成了硬件I2C版本仿真通过后烧回实机时才改为软件模拟I2C。这里借用一个思想仿真工程和实物工程的驱动代码可以不一样两者之间的桥梁是统一的应用层接口——OLED_ShowString()、OLED_ShowHexNum()这些函数在两端都叫同一个名字内部实现各归各应用层逻辑完全复用。仿真还有一个容易被忽略的点是Proteus里复位电路有时会发生复位引脚毛刺导致芯片反复重启。我的处理是把这个RC复位电路的复位电容加大到1uF确保上电后复位信号能持续足够长的时间让晶振稳定起来。这个改法在实物上不能照抄1uF复位电容会导致复位太慢按键复位体验差但仿真里运行稳定即可。5. 常见问题与排查实录5.1 经典故障速查表我把从原理图到代码的整个调试过程中遇到的典型问题整理了一下大部分都是新手项目里反复出现的高频故障MQ-2电压值一直为0先量模块供电是否正常再看AOUT引脚是否真的连接到PA0。我遇到过一次是杜邦线插错位AOUT插到了GND丝印旁边排查了半小时才反应过来。软件层面检查ADC初始化有没有开启GPIO的模拟输入模式没有的话读到的值恒为0。DHT11一直读到0xFF或超时大概率是上拉电阻缺失或引脚初始化模式不对。数据脚一定要配成开漏输出外部上拉用推挽输出或浮空输入都会失败。另外连续两次读取DHT11之间要间隔至少1秒读得太频繁传感器会不响应。蜂鸣器不响但LED正常先把代码里的GPIO配置改成推挽输出、翻转电平测试如果还是无声检查三极管基极电阻——我见过有人把1K焊成了10K驱动电流不够蜂鸣器只能发出微弱的“嘶嘶”声。更隐蔽的问题是蜂鸣器正负极接反有源蜂鸣器反接不会响但也不会烧现象跟没驱动一模一样。继电器频繁抖动继电器线圈断电时产生的反向电动势干扰了MCU电源表现为系统复位或ADC值突变。在继电器线圈两端并联续流二极管后这个现象基本消失。如果是模块化的继电器板板上一般自带续流二极管直连MCU控制信号时注意模块输入端的电平匹配就行。烧录后程序不跑但下载正常ST-Link能识别芯片能烧录说明SWD和电源基本没问题。程序不跑常见原因是BOOT0被拉高芯片进入了ISP模式不会从Flash启动。检查BOOT0引脚是否有跳线帽或者外接电阻把它误拉高到3.3V。另一个原因是复位电容太大上电后复位时间过长主程序其实在跑但OLED初始化还没完成要等三五秒才显示。ADC采样值跳变超过100个单位MQ-2的加热电阻在工作时电流变化会影响到模拟参考电压尤其是用USB供电时更明显。拉大ADC采样窗口到20次平均或者用软件均值滤波能压住一部分。硬件上把MQ-2供电单独用LC滤波隔离开是最彻底的方案。5.2 实测中的坑与心得先说传感器预热的问题。我第一次实机调试时就翻过车通电后系统立刻报警蜂鸣器一通狂响当时还以为是阈值设得太低。后来看打印的电压曲线才明白MQ-2冷启动时输出会先冲到2.5V再慢慢降到0.8V稳定值这个过程持续两三分钟。如果代码不做预热屏蔽系统一上电就误报观感极差。所以“开机60秒预热”这个逻辑不是可有可无的是必须加的。关于按键消抖很多人都知道用延时消抖但在这个项目里光延时不够。因为面板按键和蜂鸣器靠得近报警时蜂鸣器振动会引起机械抖动表现为按键一次触发变成两三次。我在按键扫描里用的是状态机消抖——连续检测到稳定电平超过20ms才算一次有效按下并且在按键松开前不响应第二次触发。DHT11的读取频率我也要特别提醒。它的数据手册上写得清清楚楚读取间隔要大于1秒。新手容易犯的错误是在主循环里反复快速读结果就是传感器不响应或者CRC校验失败。我最后把DHT11的读取频率限制在每2秒一次主循环里加了个时间戳判断时间未到就跳过读取直接显示上一次的缓存值。这个缓存策略同样适用于OLED刷新——每200ms刷一次就够了不必要的快速刷新会加重I2C总线负担。还有一个比较隐蔽的问题我一开始把ADC采样放在主循环里用的是阻塞式读取结果DHT11的微秒级时序延时被ADC阻塞打断了导致DHT11频繁超时。后来把ADC读取改成了DMA模式MCU在后台持续把ADC值搬运到内存环形缓冲区DHT11读取期间不会被ADC占用打断。主循环里只需要取缓冲区最新的平均值即可。这个改动让两个传感器都能稳定工作强烈建议同样被时序问题困扰的朋友试试。5.3 扩展方向与二次开发建议代码和原理图开源出去之后很多朋友问下一步还能往哪改。我给几个实际可行的方向第一是增加WiFi模块比如ESP8266或ESP32用串口跟STM32对接把实时数据和报警信息推送到钉钉或微信机器人这样人不在实验室也能收到通知。第二是换成4G模块做远程短信报警适合没有WiFi覆盖的旧实验室。第三是加一个火焰传感器模拟量输出版本作为第三路判据三路信号之间用“或”逻辑综合判定能显著降低单一传感器失效带来的漏报风险。如果想把系统升级成更符合工业消防规范的版本可以考虑替换核心传感器把MQ-2换成电化学式一氧化碳传感器把DHT11换成SHT30这类I2C接口的高精度温湿度传感器ADC前端加一级运放放大电路以适配不同传感器的输出电压范围。主控端如果觉得F103的Flash不够用可以换F103RCT6或者F407代码移植成本极低因为用的标准库API大部分兼容。对了还有一个日常维护的小经验MQ-2这类半导体传感器的敏感材料会随着时间老化基线输出电压会漂移建议每半年做一次阈值校准——把传感器放在干净空气中通电稳定半小时记录此时的基线电压然后把阈值改成“基线电压固定偏移”的形式存进Flash。我在代码里留了这个接口开机时长按加减键组合进入校准模式屏幕上会自动显示当前基线值一键写入。最后再说一个我一直坚持的习惯原理图、代码和仿真工程三者必须同步更新。很多人只改代码不改原理图过两个月自己都忘了哪个引脚被改了。我的做法是在原理图每个网络标号上标注对应的GPIO宏定义名称代码里的引脚定义直接引用原理图上的标签这样两边对不起来的时候一眼就能发现不一致。开源项目最怕的就是文档和代码脱节哪怕只是一个人自用把“原理图-代码-仿真”的对应关系维护好后续版本的迭代会轻松十倍。