基于STM32的充电桩环境安全监测系统设计与实现

1. 项目概述：为什么需要一个充电桩环境安全监测系统

做充电桩相关的嵌入式开发快五年了，我见过太多因为环境隐患引发的安全事故。充电桩长期暴露在户外，夏天高温暴晒、冬天低温冻裂，内部还有高压大电流，加上电动车充电时电池本身就会发热——这些因素叠加在一起，如果环境异常不能被及时发现，后果真的不是开玩笑的。

所以这次我把一个完整的充电桩环境安全监测系统开源出来，包含全部代码、原理图和仿真工程，用的是最常见的STM32F103系列单片机。这个系统的核心任务是实时采集充电桩周围的环境温湿度、烟雾浓度、明火信号，一旦发现异常立刻声光报警，同时通过继电器切断充电主回路，从源头避免事故恶化。

这套系统解决的实际问题有三个：一是充电桩内部温度过高时自动告警并断电；二是充电过程中出现烟雾（通常意味着线缆过载或电池热失控前兆）时能第一时间响应；三是出现明火时联动切断电源，为人员处置争取时间。它很适合三类人来参考——正在做毕设/课设的嵌入式专业学生、充电桩行业的硬件开发工程师、以及想自己动手做一套环境监测装置的电子爱好者。

我并不打算只是扔个压缩包出来，这篇博文会把整个项目从需求分析、器件选型、硬件设计、代码编写、仿真验证到实际调试的完整链路都讲清楚，包括那些在文档里根本不会写的坑和教训。

2. 系统整体设计与方案选型

2.1 功能需求拆解

开始画原理图之前，先把功能需求一条条列清楚。充电桩环境安全监测系统，最关键的是“监测”这两个字——不仅要知道当前环境状态，更重要的是在异常发生时做出正确响应。我习惯把需求拆成采集、判断、执行、交互四层来看。

采集层需要获取三类数据：环境温度与湿度、烟雾浓度、明火信号。温度湿度用DHT11数字温湿度传感器，烟雾浓度用MQ-2气敏传感器，明火用火焰传感器模块。这三类数据基本覆盖了充电桩火灾隐患的早期特征：温度异常升高、线缆绝缘层热解产生烟雾、明火已经出现。

判断层由STM32完成。MCU不断读取传感器数据，和预设的安全阈值比较。阈值不能设得太死，因为环境温度本来就有正常波动，比如夏天中午充电桩表面温度到50℃也不稀奇，所以报警条件要考虑持续时间和变化趋势。

执行层包括声光报警和继电器控制。报警用有源蜂鸣器加红色LED，级联控制一个5V继电器，继电器常开触点串联在充电主回路里。环境正常时继电器吸合，充电回路导通；报警时继电器释放，切断输出。

交互层则是一个OLED显示屏和三个按键。显示屏实时显示温度、湿度、烟雾浓度和系统状态，按键用来设置报警阈值。为什么不做成Wi-Fi上报？因为这样整个系统的复杂度会高一个量级，而且充电桩现场一般有严格的网络隔离要求，本地显示加声光报警是更稳妥、更工程化的方案。

2.2 主控选型：为什么用STM32F103C8T6

主控选择其实没有太多悬念，STM32F103C8T6是这类项目的绝对主力。我选它是因为这几个理由足够充分：第一，Cortex-M3内核72MHz主频，跑这种轻量级采集控制任务绰绰有余；第二，Flash 64KB、RAM 20KB，放完整的FreeRTOS都够，裸机程序更不用说了；第三，片上外设齐全，ADC、定时器、I2C、SPI、USART一个不少，后面想扩展通信功能不用换芯片；第四，市面上买得到的最小系统板也就十几块钱，坏了不心疼。

可能有人会问，用STM32F103是不是杀鸡用牛刀？一个8051单片机不是也能干这些事？但实际做项目不能只看功能能不能实现。STM32F103有完整的标准外设库和HAL库生态，调试工具支持成熟，网上能找到的海量参考资料意味着开发效率完全不同。更关键的是，如果你后续要在系统里加4G模块上报数据、加密认证芯片、多路传感器通道，STM32的资源和性能冗余让你有足够的升级空间。

2.3 传感器选型：低成本优先，兼顾可靠性

传感器这块我走过不少弯路。最早试过用DHT22替代DHT11，精度确实高不少，但价格也翻了四倍多。对于环境安全监测这种偏阈值告警的应用场景，探测精度的需求并没有那么苛刻——我要知道的是“湿度是不是超过85%RH”，至于到底是85.3%还是86.1%，其实关系不大。所以最终选型是以性价比为第一优先级。

DHT11的精度是±2℃和±5%RH，测量范围0~50℃、20%~90%RH，看起来指标一般，但充电桩环境监测的需求恰好落在这个区间里。MQ-2对液化气、丙烷、氢气等可燃气体的灵敏度都不错，对充电桩内部绝缘材料热解产生的烟雾也有响应。火焰传感器模块本质上是一个红外接收管加比较器，检测波长760nm~1100nm的红外光，对明火敏感，但要注意避免太阳光直射干扰。

需要说清楚的是，这套传感器方案做的是“可燃气/烟雾浓度趋势监测”，不是精密计量仪表。如果要达到消防验收标准，正规充电桩设计要求用的是符合国标的气体探测器，那个成本不是个人项目能承受的。但做原理验证、做课程设计、做产品原型预研，这套方案是够用且典型的。

2.4 整体架构设计

整个系统以STM32F103C8T6最小系统为核心，外围电路由五个模块组成：电源模块、传感采集模块、人机交互模块、报警执行模块、调试接口模块。电源模块把外部输入的12V电压降压到5V和3.3V两路，5V为MQ-2传感器、继电器、蜂鸣器供电，3.3V为主控、OLED、DHT11供电。这里有个容易忽略的细节——DHT11虽然标称支持3.3V供电，但3.3V下通信时序的容限会变差，更稳妥的做法是5V供电然后数据线串电阻再接MCU引脚，我最终选了后者。

传感采集模块中，DHT11数据线接PB11，需要外部上拉电阻，因为单总线协议空闲时靠上拉电阻维持高电平；MQ-2的AO输出接PA0作为ADC输入，DO输出作为辅助数字参考接PA1；火焰传感器DO输出接PA2。

人机交互模块包括0.96寸I2C接口OLED（SCL接PB6、SDA接PB7）和三个按键（分别接PA3、PA4、PA5），按键采用独立接法，一端接地一端接GPIO，内部上拉使能，按下为低电平。报警执行模块中，蜂鸣器接PB8，红色LED接PB9，继电器控制脚接PB10。

调试接口使用标准的20针JTAG/SWD，实际调试时我只用SWD的四根线——SWDIO、SWCLK、GND、3.3V。这些引脚分配并不是随手定的，基本思路是把有特殊功能的外设引脚（ADC、I2C）放在对应功能引脚上，普通GPIO按剩余引脚自由分配，同时避免把晶振引脚、BOOT引脚和调试引脚占用掉。

3. 原理图设计详解：每个引脚的来龙去脉

3.1 电源电路设计：从12V到3.3V的两级降压

充电桩现场通常提供12V或24V直流电源，所以系统需要一个多级降压架构。我设计的方案是：12V进来先经过自恢复保险丝F1（500mA），防止后级短路导致故障扩大；然后进LM7805线性稳压器降到5V，5V这一路供给MQ-2、继电器、蜂鸣器和DHT11。

5V再经过AMS1117-3.3降到3.3V，给STM32、OLED供电。有经验的工程师一看就明白，LM7805把12V降到5V，在负载电流200mA的情况下耗散功率是(12-5)×0.2=1.4W，这对于TO-220封装来说是危险的发热量。所以7805必须加散热片，或者在布局上利用大面积铜皮辅助散热。如果输入电压是24V，7805方案就不太合适了，建议用降压型的DC-DC模块，比如MP1584、LM2596，效率高发热小。

每个电源输出端的滤波电容也值得说一下：7805输入端放一个470uF电解电容和一个104陶瓷电容，输出端放一个100uF电解电容和一个104陶瓷电容。AMS1117的输入输出端各放一个10uF钽电容或电解电容。这些电容不是随便放的，电解电容负责低频储能，陶瓷电容负责高频噪声抑制，两者互补。

3.2 最小系统电路：启动配置与复位

STM32F103C8T6的最小系统电路包括晶振电路、复位电路、BOOT配置和去耦电容。8MHz主晶振两端各接一个20pF负载电容到地，这个值是从芯片数据手册推荐值来的。32.768kHz的RTC晶振，如果项目不需要实时时钟功能可以省掉，我这次没焊，但原理图里留了位置。

复位电路是经典的RC复位，10K电阻上拉到3.3V，104电容到地，复位引脚NRST接在中间节点。按键按下时NRST被拉到低电平，MCU复位；松开后电容充电延时拉高。BOOT0通过10K电阻下拉到地，BOOT1悬空或者下拉，这样保证从Flash启动。

去耦电容这块新手容易忽略，却极其重要。每个VDD引脚旁边都要放一个104陶瓷电容，位置尽量靠近引脚，这是保证MCU稳定运行的基础。我见过不少学生画的板子，主芯片一个去耦电容都没有，结果程序跑着跑着就死机，换了芯片也一样，最后发现就是电源噪声问题。

SWD调试接口用4Pin排针引出，SWDIO接PA13、SWCLK接PA14，不占用其他IO口。如果你用的是ST-Link V2下载器，四个引脚正好一一对应，接线顺序为3.3V、SWDIO、SWCLK、GND，注意别接反。

3.3 传感器接口电路：匹配、保护与容错

DHT11接口电路有一个关键设计——上拉电阻的取值。DHT11的通信时序要求数据线空闲为高，我选择5V给DHT11供电，数据引脚串联一个1K电阻后再接MCU引脚，同时到5V上拉一个4.7K电阻。为什么串1K电阻？因为DHT11的数据线电平是5V，而STM32的GPIO耐压虽然是5V容忍，但为了避免过冲和潜在风险，串个电阻做限流保护更稳妥。实际测试中这个组合非常稳定，3米以内的杜邦线连接都能正常通信。

MQ-2模块需要预热。上电初期，内部加热丝会把敏感材料表面吸附的气体分子清除，这个过程通常要1~2分钟，在此期间输出信号不稳定。所以设计上要在软件里做一个开机初始化延时，等MQ-2稳定后再开始监控。MQ-2的AO引脚输出信号范围是0~5V，而STM32的ADC输入范围是0~3.3V，直接接会超出量程。模块本体上有一个可调电位器，可以通过调节把它输出的模拟电压范围映射到合适的区间，但更规范的做法是在原理图里加一个分压电阻网络，把AO电压先分压到3.3V以内再进ADC。我的做法是用两个10K电阻分压，实测效果稳定。

火焰传感器模块的DO输出是3.3V逻辑电平，可以直接接MCU。这个模块在室内常规环境下输出高电平，检测到火焰时输出低电平，所以设计时让MCU内部上拉使能。它有一个灵敏度调节电位器，逆时针旋转灵敏度降低、顺时针升高，调试时根据实际场景调好再固定。

3.4 执行电路：继电器驱动与保护二极管

继电器控制是嵌入式项目里最容易烧板子的地方之一。5V继电器线圈的驱动电流在70mA左右，STM32的GPIO最大输出电流只有25mA，直接驱动是绝对不行的。我用的是S8050三极管做开关驱动，GPIO输出高电平通过1K基极电阻使三极管导通，继电器线圈通电吸合；GPIO低电平时三极管截止，继电器释放。

这里有一个必须画的元件——续流二极管。继电器线圈是感性负载，在三极管关断瞬间会产生反向电动势，如果不加保护，这个反向电压可能高达几十伏，直接击穿三极管。续流二极管反向并联在线圈两端，给反向电流提供泄放回路。我用的1N4148就能胜任，注意方向一定不能接反，否则通电瞬间直接短路。

蜂鸣器驱动大同小异，有源蜂鸣器内部自带振荡源，只要通电就会发声。同样用三极管驱动，同样要加续流二极管——很多人以为蜂鸣器不是感性负载就不用加，实际上蜂鸣器内部有线圈，一样会产生反向电动势。LED限流电阻一般取1K到2K，3.3V供电时LED工作电流在2~5mA之间，亮度适中又不刺眼。

3.5 PCB Layout的实战要点

原理图画完之后，Layout才是真正见功力的地方。这个项目如果打板，我建议严格注意以下几点：首先是电源走线加粗，12V和5V主干线至少1mm宽，3.3V至少0.5mm；其次是MCU去耦电容要靠近电源引脚放，距离不要超过3mm，否则高频退耦效果几乎为零；第三是模拟地和数字地单点连接，MQ-2的模拟信号部分单独走线，避免和继电器、蜂鸣器这些大电流开关器件共用回流路径。

继电器和蜂鸣器属于高噪声器件，布局时尽量远离天线状的传感器模拟输入端和MCU晶振。如果板子尺寸紧张，至少保证继电器在板边，传感器接口在另一侧板边，让信号链路尽量直短。如果需要画双层板，底层铺地铜，关键信号线上方不要走其他信号线去割裂地平面回路。这些都是经验总结，第一次画板的人往往在这些细节上踩坑。

4. 固件实现详解：从裸机框架到传感器驱动

4.1 软件架构与状态机设计

固件代码我选择使用标准外设库（SPL）而不是HAL库。原因很简单——这个项目的逻辑不复杂，SPL的代码更精简，寄存器层级更清晰，对学习理解STM32内部机制帮助更大。如果你想用CubeMX生成HAL库代码，逻辑框架完全一样，只需替换底层API。

整体软件架构分为三层：驱动层（DHT11、OLED、ADC、按键）、业务应用层（状态判断、阈值管理、报警联动）、主循环调度层。主循环用一个简单的状态机维护系统状态：

正常态：轮询各传感器数据，刷新OLED显示，无异常则维持继电器吸合。

预警态：某个参数超过预警阈值但未达到报警阈值，此时OLED显示预警信息，蜂鸣器间歇短鸣提醒，继电器不动作。

报警态：参数超过报警阈值，或连续多次采样超过预警阈值，此时蜂鸣器持续鸣响、红色LED点亮、继电器断电释放，直到人工按键复位或参数恢复正常。

状态机的好处是代码可读性强、扩展性好，后面如果要加Wi-Fi上报，只需要在报警态里加一个调用就行。

主循环的调度周期是我交替运行不同任务的方案：DHT11每2秒采集一次，因为DHT11本身的响应速度有限，太频繁读取反而容易超时；MQ-2的ADC采样每200毫秒一次，取10次平均值滤波；按键扫描每50毫秒一次，带消抖处理；OLED刷新每500毫秒一次。

4.2 DHT11驱动：单总线时序的精确把控

DHT11是这项目里最容易让新手翻车的器件之一，原因在于它的单总线时序对时间精度要求敏感。完整时序分两部分：主机发起起始信号，然后从机应答并返回40位数据，数据格式为8bit湿度整数、8bit湿度小数、8bit温度整数、8bit温度小数、8bit校验和。

起始信号：主机先将数据线拉低至少18ms，再释放并拉高20~40us，然后等待从机响应。我从实际的时序测试中确认，拉低时间在20~30ms之间最稳定。

从机响应：DHT11检测到起始信号后，输出80us低电平应答信号，然后连续输出40位数据。

数据位表示：每一位数据都是以50us低电平开始，之后拉高。高电平持续26~28us表示数据0，高电平持续70us表示数据1。判断是高电平的持续时间还是拉高后的电平状态，我这里基于高电平持续时间来判定，比单靠电平判断更可靠。

这里我给出一个实际可用的DHT11读取代码核心逻辑（完整工程见开源仓库）：

uint8_t DHT11_ReadByte(void) { uint8_t i, byte = 0; for(i = 0; i < 8; i++) { while(GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == RESET); // 等待50us低电平结束 Delay_us(30); // 延时30us后再采样 if(GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == SET) byte |= (0x80 >> i); // 高电平持续超过30us，判定为1 while(GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == SET); // 等待高电平结束 } return byte; }

这个实现的精髓在于延时30us后采样，已经能从时间上区分0和1。实际调试时我用逻辑分析仪看过波形，采用这种“中间采样”策略后，误判率明显降低。

校验方面，读取完40位数据后，用前四个字节相加取低8位，和第五个字节比较，不等则丢弃本次数据，使用上一次的有效数据。这是个简单但有效的容错机制，DHT11偶尔因为时序抖动读错数据是正常现象，校验能保证显示值和报警判断的稳定性。

4.3 ADC采集与滤波：让烟雾浓度数据更平滑

MQ-2的AO引脚输出模拟电压，电压越高代表检测到的烟雾/可燃气体浓度越高。STM32的ADC是12位分辨率，我配置为PA0模拟输入、采样时间55.5周期，这个采样时间对MQ-2这种响应速度慢的气敏传感器来说非常充足。

代码层面有几个值得注意的地方。ADC校准：STM32F103上电后应该调用ADC_GetCalibrationFactor函数进行自校准，否则转换结果可能偏差了几个LSB。多通道切换：如果后续要扩展其他模拟传感器，ADC通道切换后需要等待一小段时间让采样保持电容稳定，再启动转换，我习惯在切换通道后加10us延时。滤波方法：我没有用简单的算术平均，而是用滑动中值滤波——取5次采样，排序后取中值。这种方法对尖峰脉冲干扰的抑制效果比平均滤波好很多，因为MQ-2偶尔会产生瞬时跳变，平均法会被拉偏，中值法不会。

报警阈值不是直接把ADC原始值拿来比较。我做了归一化处理：设置一个基准电压值（正常环境下的输出电压）和满量程值，通过公式计算得到一个百分比浓度值。这样用户通过按键设置阈值时，操作的是“30%”这种直观的百分比，而不是“1245”这种ADC原始码值。

4.4 OLED显示与按键交互：一个小型嵌入式UI

OLED用的是0.96寸SSD1306驱动芯片，I2C接口，标准128x64分辨率。我移植了常见的软件驱动，只保留显示字符、字符串、整数、浮点数的函数，加上两个画图函数用于画报警图标。

UI结构设计得很简单：第一行显示温度值，单位℃，第二行显示湿度值，单位%RH，第三行显示烟雾浓度百分比和系统状态标志（正常/预警/报警），第四行显示继电器状态（ON/OFF）。进入阈值设置模式后，屏幕显示当前选中的参数和数值，按键加减修改。因为OLED刷新率不高，我在写显示逻辑时把固定不变的字段（比如“TEMP：”）和动态变化的字段分开了，只更新变化的部分，这能显著减少I2C通信量和屏幕闪烁感。

按键处理必须加消抖。我用简单的延时消抖：检测到按下后延时20ms再读一次，确认是低电平才认为有效按键。另外所有按键都是短按触发，不做长按和组合键，降低代码复杂度和误触概率。阈值设置分两级：长按确认键进入设置模式，短按切换设置项，短按加减修改数值，长按确认键保存退出。

4.5 继电器控制逻辑与报警联动

继电器控制是整个系统安全逻辑的最终执行环节。我的控制逻辑是这样的：正常状态下，继电器控制引脚输出高电平，三极管导通，继电器吸合，充电回路导通；任何报警条件下，控制引脚变为低电平，继电器立即释放，切断充电回路。

这里面有一个关键设计——故障安全型（fail-safe）逻辑。即：异常发生时让继电器回到“失电断开”的状态，而不是“失电闭合”。因为继电器线圈停电时自然释放，如果设计成“有电才断开”，一旦整个系统失电，继电器反而保持导通，那就完全失去了安全保护的意义。充电桩在待机和环境异常时，让继电器保持释放状态才是安全状态。

此外我增加了报警自锁功能：一旦触发报警，即使环境参数后来恢复正常，系统仍然保持报警状态，需要人工按下复位按键才能解除。这是刻意设计的。因为环境安全监测系统处理的可能是严重隐患，如果参数一恢复就自动复位，现场人员可能根本来不及到场确认原因。有些场景下用户希望自动复位，只需要修改报警处理逻辑里那个自锁标志位即可。

5. 仿真搭建与验证：在Proteus里先把逻辑跑通

5.1 仿真电路搭建方法与元件配置

在打样实焊之前，先用Proteus做功能验证是一个非常高效的工作方式，能省下大量的烧录调试时间。仿真工程我用的Proteus 8.x版本，元件库中需要找到：STM32F103C8T6（Proteus需要用专门的模型库，我用的是通过LPC2138替代方案，或者从网上下载STM32库文件放入Proteus的LIBRARY目录）、DHT11（Proteus 8自带）、LM016L液晶或OLED仿真模型、虚拟终端（Virtual Terminal）。

有个现实问题是Proteus标准库中没有MQ-2模型。我的替代方案用一个10K电位器接在ADC输入口上，调节电位器阻值即可模拟MQ-2输出电压的变化——烟雾浓度升高→输出电压升高→ADC采样值变大。这对于验证ADC采集、阈值比较、报警联动逻辑来说完全够用。火焰传感器同样用按钮代替，按下模拟检测到火焰，看看报警是否触发。

仿真电路搭建好之后，把编译生成的hex文件加载到MCU元件上就能跑了。Proteus仿真的优势在于可以直观地看到每个引脚的逻辑状态，用示波器探头观察DHT11数据线上的时序波形，这在实物调试时反而不容易做到。

5.2 仿真验证的关键场景与结果

我在仿真里验证了六个场景：常温正常环境（温度26℃，湿度50%，烟雾浓度正常，继电器闭合）；高温报警（把温度传感器参数调高到70℃以上，观察蜂鸣器动作和继电器断开）；烟雾报警（调低电位器模拟烟雾浓度上升，确认ADC采样值变化走完整个报警链路）；火焰报警（按下火焰传感器模拟按钮，确认报警触发）；阈值设置（通过按键修改阈值后重新触发报警，确认新阈值生效）；DHT11通信异常（拔掉传感器，观察程序能否用上一次有效数据继续运行而不死机）。

前五个场景在仿真中都一次通过了。第二个场景有个小插曲，DHT11在Proteus里把温度参数手动调高后，读数不是立刻变的，有一定延迟且需要重新发送读取命令才能更新——这其实和真实DHT11的行为一致，不用紧张。真正值得关注的是第六个场景，让我发现了代码的一个隐性bug，具体在下一小节展开。

5.3 仿真阶段发现并修复的三个问题

问题一：DHT11读取失败导致系统挂死。最初版本代码中，DHT11读取超时后没有做错误处理，程序会卡在while循环里等待电平变化，导致整个系统死掉。仿真里把DHT11的数据线断开后，OLED再也不刷新，继电器也不响应了。修复方案是给每个while等待循环加超时计数，超时后直接返回错误码，主循环判断读取错误后显示“ERR”并继续运行。

问题二：ADC通道初始化时首次采样值异常。仿真中发现上电后第一次ADC读取的值总是满量程0xFFF，之后才恢复正常。原因是ADC上电后需要一段稳定时间，直接开启转换得到的值不可靠。修复方法是在初始化后先丢弃两次采样值，把第三次作为有效数据。这个问题实物板上也遇到过，算是STM32 ADC使用的一个通用注意事项。

问题三：继电器频繁跳变。仿真中把烟雾浓度设置在报警阈值附近时，继电器会不停地吸合、释放，声音听起来就像快速开关。原因是传感器数据有正常波动，滤波后仍然会在阈值附近上下穿越。修复方案是引入滞后比较——报警阈值设为40%，但解除报警要等浓度降到30%以下。这样形成了一个滞回区间，继电器只会在阈值跨越时动作一次，不再抖动。

6. 实物调试实录：从烧录到稳定运行的完整过程

6.1 Keil工程搭建与下载调试

拿到PCB和元器件后，第一步是搭建Keil MDK开发环境。我用的Keil MDK 5.x，配合ST-Link V2下载器。新建工程时选择STM32F103C8，CMSIS选CORE，Device选Startup，然后手动添加标准外设库源码。这里有一个老生常谈但新手常犯的错误——忘了在C/C++选项卡里定义STM32F10X_MD这个宏，导致工程编译报一堆“unknown type name”的错误。

下载配置选择ST-Link Debugger，接口SWD，右下角Settings里可以看到是否能正确识别到芯片ID。如果这里报“No ST-Link detected”或“No target found”，不要慌，按优先级排查：ST-Link驱动装没装好、接线对不对（SWDIO接PA13、SWCLK接PA14、GND共地）、目标板有没有供电、BOOT0是否接地。其中“断电重启”这个最容易被忽略，ST-Link和MCU必须先给目标板上电，再打开烧录操作，否则无法建立通信。

调试时我习惯在代码里加上串口printf输出，通过CH340串口模块把日志发到电脑上看。用一个USART1重定向printf函数，调试信息就包括“DHT11 read OK: 26.1C 52%RH”“ADC value: 1254, smoke level: 23%”“RELAY ON/OFF”这类内容。这比看OLED屏幕有效率得多，尤其在做长时间稳定性测试的时候。

6.2 实测数据记录：从早到晚的环境监测日志

系统在充电桩模拟环境里连续运行了48小时，我摘录了几个时间点的数据。早上6点：环境温度18.2℃，湿度68%RH，烟雾浓度5%，系统正常，继电器闭合。中午12点：温度31.5℃，湿度45%RH，烟雾浓度7%，接近午间高温但未超阈值。傍晚18点：温度24.8℃，湿度55%RH，烟雾浓度9%，因为现场做了一次模拟线缆过热的烟雾测试，浓度短暂上升到29%后被系统判定“预警”，但没有触发断电。深夜23点：温度17.5℃，湿度72%RH，烟雾浓度4%，一切正常。

从数据可以看到湿度的变化范围比较大，这也是我在代码里把湿度报警阈值默认设到85%RH的原因，避免夜间高湿环境误报警。另一个观察是烟雾浓度即使在正常状态下也不是绝对不变的，会随着现场通风情况有2%~3%的波动，所以报警阈值默认设在30%算是一个比较合理的经验值。当然这些阈值都不是固定的，用户可以根据实际应用环境通过按键调整。

6.3 实物调试中踩过的坑

第一个坑是DHT11上拉电阻。第一次打板时我没有给DHT11数据线加上拉电阻，结果通信成功率很低，大概三五个周期就会读错一次。原因是IO配置为开漏输出模式后，如果没有外部上拉，释放总线时电平浮空。后来改成推挽输出模式，内部上拉使能，情况有所好转，但也不完全稳定。最终方案是在外部加了4.7K上拉到VCC，问题彻底解决。

第二个坑是MQ-2预热期的误报警。系统刚上电时，MQ-2的模拟输出电压会先冲到比较高的值，然后慢慢稳定下来，这个过程可能持续两三分钟。如果主控在这段时间就启动监控逻辑，大概率会误报警。我的解决方法是开机延时三分钟再开始烟雾浓度判定，期间OLED显示“SENSOR WARMUP”。

第三个坑是继电器响应对ADC采样数值的干扰。继电器吸合瞬间，蜂鸣器响的时候，ADC采样值会出现明显的跳变，有时候会跳到报警阈值以上，让系统误判。排查后发现是继电器和蜂鸣器工作时拉低了5V电源轨，导致MQ-2的加热丝电流变化引起输出波动。解决方法是把传感器的5V供电串联一个10Ω电阻加一个100uF电容滤波，让传感器供电和继电器供电在电源入口处就分离开。效果立竿见影，ADC采样值的波动从原来的±50个码值降低到±5个码值以内。

6.4 常见问题与排查思路速查表

为了给新手一个可以直接对照的排查路径，我做了一张在实际调试中高频出现的问题速查表：

7. 开源内容使用指南：跑通这个项目最快路径

整个开源仓库包含五个目录：/Code（完整Keil工程源码）、/Hardware（原理图PDF和AD工程文件）、/Simulation（Proteus仿真工程）、/Docs（数据手册与设计说明）、/Tools（烧录工具、串口调试助手等）。

如果你是第一次接触STM32项目，我建议按这个顺序走：先在Proteus里打开仿真工程，加载hex文件跑通全部逻辑，看看系统“应该长什么样”；然后打开原理图，对照我上一节讲的模块划分，理解每个器件为什么这么接；接着打开Keil工程，仔细阅读DHT11驱动代码——这是整个项目里技术含量最高的部分；最后如果你手上有板子，焊一块实板，按第6节的调试流程把代码烧进去，配合串口日志观察现象。

在真正画板或焊板之前，建议先看看原理图里几个关键设计点：电源滤波电路、传感器信号调理、继电器驱动与续流保护。这些是你移植到别的项目时也会反复用到的“通用积木”。如果电路基础弱一些，最好用洞洞板先手工搭一个最小系统出来验证，再考虑画PCB打样。打样的话，嘉立创打5片双层板也就几十块钱包邮，周期3~5天，完全在个人项目可承受范围内。

最后说两句实在话。我做这个项目的初衷，是因为发现很多嵌入式学习者手里存了一堆开发板例程，每个例程都会跑，但一遇到实际场景就不知道如何组织一个完整系统——传感器怎么选、电源怎么做、报警执行之外还要考虑什么、可靠性从哪里来。这个项目能帮你把这些环节串起来。如果你在复现时遇到问题，先查本章的排查表，解决不了就在开源仓库提issue，我会持续维护。后续我还在计划加一个低功耗版本，用STM32L0系列加锂电池供电，配合NB-IoT模块把报警信息推送到云端，感兴趣的可以保持关注。