STM32充电桩环境安全监测系统：温湿度、烟雾与火焰报警联动设计

1. 项目背景：为什么充电桩需要一套环境安全监测系统

在开始聊电路和代码之前，我想先跟各位说说这个项目的来由。我自己做嵌入式开发有些年头了，平时接触的很多毕业设计、工程落地项目里，环境监测类一直是个热门方向，但很多方案要么只做数据采集、没有联动控制，要么把成本堆得很高、根本不具备可复制性。这次分享的充电桩环境安全监测系统，算是我把“毕业设计级方案”往“工程可用级方案”拉近的一次尝试。

充电桩这东西，现在城市里越来越多，地下车库、露天停车场、高速服务区随处可见。但大家有没有想过一个问题：充电桩长期工作在户外或者半封闭环境，本身又是大功率设备，它的工作环境温度、湿度、烟雾浓度、可燃气体浓度，其实都是潜在风险点。尤其夏天暴晒后充电桩内部温度升高，或者地下车库通风不良导致可燃气体聚集，这些都是真实存在的安全隐患。如果有一套系统能实时监测这些环境参数，在温度过高、烟雾超标、可燃气体泄漏时及时报警并启动排风设备，那就能把很多隐患扼杀在早期。

这个STM32项目就是干这件事的。它基于STM32F103C8T6主控芯片，配合DHT11温湿度传感器、MQ-2烟雾传感器、火焰传感器，实现对充电桩周边环境的温度、湿度、烟雾浓度、火焰信号的实时采集和监测。系统还带OLED显示屏实时显示数据，有蜂鸣器和LED报警提示，能自动控制风扇排风，支持按键调节报警阈值，并且通过串口把数据上传到上位机。整套系统的代码、原理图、仿真工程全部开源，拿到手就能自己复刻。

适合谁来看这个项目？如果你是正在做嵌入式相关课程设计或毕业设计的学生，这个项目从硬件到软件到仿真一条龙齐全，直接拿来改改就能用；如果你是刚开始接触STM32开发的初学者，这个项目用到的外设模块覆盖了GPIO、ADC、定时器、串口、I2C等主流知识点，是一个很好的综合练手项目；如果你是在做充电桩运维或者相关产品预研的工程师，这套监测系统的架构思路也有参考价值。下面我把整个项目从设计思路到具体实现一步步拆开讲清楚。

2. 系统整体设计与硬件架构思路

2.1 核心需求拆解：这套系统到底要监测什么

充电桩环境安全监测，说到底要回答三个问题：环境是什么样的、有没有异常、异常了怎么处理。围绕这三个问题，我梳理出系统的核心需求。

第一个需求是环境参数的实时采集。温度、湿度是最基本的环境指标，充电桩工作温度过高会影响电路稳定性和电池寿命，湿度过大则容易导致绝缘性能下降、电路板凝露短路。烟雾浓度和可燃气体浓度则是消防安全的核心指标，不管是线缆过热冒烟还是外部环境气体泄漏，都需要第一时间感知。

第二个需求是本地显示与告警。监测数据不能只存在单片机里，要让现场人员一眼就能看到当前环境状态。我用了一块0.96寸OLED屏做实时显示，同时设计了声光报警电路——蜂鸣器响、LED灯闪，异常状态想忽略都难。

第三个需求是自动联动控制。这也是这个项目和很多“纯监测”类设计的最大区别。当温度或者烟雾浓度超过阈值时，系统自动打开风扇进行排风散热，把被动监测变成主动干预。

第四个需求是远程数据上报。通过串口把环境数据发送给上位机，方便后期扩展成真正的物联网监测平台——这是为后续接ESP8266、4G模块、云平台预留的接口。

2.2 主控选型：为什么是STM32F103C8T6

有人可能会问，做个环境监测而已，用51单片机不也行吗？确实行，但体验完全是两回事。这次选型我坚持用了STM32F103C8T6，理由很实在。

这颗芯片是ARM Cortex-M3内核，主频72MHz，在同等价位的MCU里性价比极高。最关键的是它的外设资源非常丰富，Flash容量64KB、RAM 20KB，GPIO口够多，还带多路ADC、多个定时器、多个串口。这意味着项目后期想扩展 WiFi模块、加更多传感器，芯片资源都扛得住。而且STM32的生态太成熟了，标准外设库、HAL库随便选，出了任何问题网上一搜一大把解决方案，对新手极度友好。

我做这个项目时用的是STM32F103C8T6最小系统板，板上自带了8MHz晶振、复位电路、LDO稳压、USB转串口芯片，插上数据线就能下载程序，非常省事。原理图设计的时候也保留了完整的启动配置引脚和复位电路，确保兼容性。

2.3 传感器选型逻辑：DHT11、MQ-2与火焰传感器的组合

传感器选型这块我踩过不少坑，这里把我的思路讲清楚。

温湿度检测选了DHT11，很多人觉得它精度一般、采样速率慢，但在这个场景下够用了。DHT11温度精度±2℃，湿度精度±5%RH，测量范围温度0到50℃、湿度20%到90%RH，对于充电桩环境监测来说完全满足要求。它的优势是单总线通信，一根线就把数据传回MCU，电路简单、代码也好写，非常适合项目复现。想追求更高精度可以换成DHT22或者SHT30，但原理和代码框架不用变。

烟雾和可燃气体检测选了MQ-2，这是一颗经典的半导体气敏传感器，对液化气、丙烷、氢气、烟雾等都有较好的灵敏度。它内部有一个加热电阻和一个气敏电阻，当环境中的可燃气体或烟雾浓度升高时，气敏电阻的阻值会下降，通过一个分压电路就能把浓度变化转换成电压变化，再送给STM32的ADC采集。这里注意，MQ-2上电后需要一段预热时间让加热丝稳定工作，一般建议预热1分钟以上再读取数据，不然读数会漂。

火焰传感器用的是红外接收型的模块，它能检测波长在760nm到1100nm范围内的火焰光源。模块上有个电位器可以调节灵敏度，当检测到火焰时输出低电平信号。这个传感器主要作为烟雾检测的补充，用于识别明火风险。

2.4 执行机构与交互模块：OLED、风扇、蜂鸣器和按键

系统不是只用来“看”的，还得能“动”。执行机构这块我设计了三个部分。

报警执行部分用的是有源蜂鸣器和双色LED灯。有源蜂鸣器内部带振荡源，只要通电就会发声，单片机给一个高电平就能驱动，也不用写PWM频率控制代码，简单可靠。LED灯用了红色和绿色两个，正常状态亮绿灯，报警状态亮红灯，配合蜂鸣器实现声光同时报警。

应急联动部分是一个5V直流风扇，用PNP三极管做驱动开关。当检测到温度或烟雾浓度超过阈值时，单片机控制引脚输出低电平导通三极管，风扇开始转动排风。风扇选型上我用的是普通的5V电脑散热风扇，功耗小、风量大，测试效果不错。

人机交互部分是一块0.96寸I2C接口的OLED屏和三个独立按键。OLED屏显示分辨率128x64，不需要背光，对比度高，在户外强光下也能看得清。三个按键分别是“设置”键、“加”键、“减”键，用于调整报警阈值参数。为什么不直接把阈值写死在代码里？因为不同安装场景对安全标准的要求不一样，有的地方温度超过40度就要报警，有的地方可能45度才报警，做成可调才是真正好用的系统。

3. 原理图设计详解与硬件实现要点

3.1 电源电路设计

整个系统的电源设计其实不复杂，但容易被忽视。充电桩现场通常能提供220V交流电或者12V/24V直流电，不可能直接给STM32供电。我的方案是系统预留了一个DC电源接口，支持输入9V到12V直流电，经过一个LM2596降压模块降到5V，再由板载AMS1117-3.3稳压器降到3.3V给MCU供电。

这里有一个很重要的细节：DHT11和OLED屏用的是5V电源，STM32用的是3.3V电源，两者逻辑电平不匹配，通信的时候需要通过上拉电阻实现电平兼容。DHT11的数据线需要接一个4.7KΩ上拉电阻到3.3V，实际测下来通信很稳定。OLED屏的I2C接口同样是开漏结构，也需要在SCL和SDA线上各接一个4.7KΩ上拉电阻到3.3V。

电源滤波方面，我在每个芯片的电源引脚附近都加了一个0.1μF的瓷片电容做去耦，在电源输入端加了470μF电解电容做储能滤波。这些小细节看似不起眼，但能有效减少电机、风扇启动时对MCU电源的冲击。

3.2 STM32最小系统与外围电路

STM32F103C8T6最小系统包含晶振电路、复位电路、启动模式配置和电源滤波四部分。

晶振电路用了8MHz主晶振和两个20pF负载电容，STM32内部通过PLL锁相环把时钟倍频到72MHz。另外还有一个32.768KHz的RTC低速晶振，这个项目里没用到RTC功能，所以我直接省略了，电路图上只保留了8MHz主晶振。复位电路是10KΩ上拉电阻加0.1μF电容到地，NRST引脚低电平复位。

启动模式配置需要注意BOOT0和BOOT1引脚。BOOT0通过一个10KΩ电阻下拉到地，选择从Flash启动，这是正常运行模式。BOOT1也下拉到地，这个引脚在从Flash启动时不起作用，但为了保险起见还是给它一个确定的电平。

下载调试接口用的是SWD方式，只需要SWDIO、SWCLK、GND三根线，比JTAG的20根线省事多了。如果你的开发板带了ST-Link或者USB转串口下载电路，直接用就行，原理图上我也预留了标准的4针SWD接口。

3.3 传感器接口电路设计

MQ-2传感器的接口电路是整个原理图里我最想重点讲的。MQ-2模块通常有四个引脚：VCC、GND、DO（数字量输出）、AO（模拟量输出）。我们这里用的是AO引脚接STM32的ADC输入，因为只判断有没有烟雾不够，还需要知道浓度变化趋势。

MQ-2的模拟输出本质上是一个分压电路，传感器的气敏电阻和负载电阻串联，AO引脚的电压等于负载电阻上的分压。当气体浓度升高时，气敏电阻阻值下降，AO电压升高。STM32的ADC采集AO电压，转换成0到4095的数字量（12位分辨率），再映射成0到100的浓度百分比。在原理图上，我在AO引脚和MCU的PA1引脚之间串了一个100Ω小电阻，主要作用是限流保护和滤波，同时并联了一个0.1μF电容滤除高频噪声。

DHT11的接口电路我已经说过，一个4.7KΩ上拉电阻就搞定了。火焰传感器模块是数字量输出，直接接MCU的GPIO输入引脚，内部配置成上拉输入模式，检测到火焰时模块输出低电平，MCU读取到低电平就触发报警。

风扇驱动电路用了S8550三极管。MCU的GPIO引脚驱动能力有限，直接接风扇肯定带不动，所以用三极管做开关。风扇一端接5V电源，另一端接三极管的集电极，发射极接地，基极通过1KΩ限流电阻接MCU的PB0引脚。当PB0输出高电平时三极管导通，风扇转动；输出低电平时三极管截止，风扇停止。这里要注意续流二极管的问题——风扇是感性负载，断电瞬间会产生反向电动势，我在风扇两端反并联了一个1N4007二极管，把反向尖峰电压泄放掉，保护三极管不被击穿。

3.4 原理图设计心得：从画图到打样的常见坑

原理图看着简单，真正动手画还是会踩坑。我用的绘图工具是嘉立创EDA专业版，免费、在线、元件库全，画完直接能导出Gerber文件打样，对学生党特别友好。

第一个坑是元器件封装。画原理图的时候就要把封装一并选好，别等到画PCB的时候才发现封装不对。比如电阻电容我统一用了0603贴片封装，STM32最小系统板是2.54mm排针，OLED屏是4针I2C接口，这些都要提前确认好。

第二个坑是电源网络命名。很多新手画原理图时电源网络命名不规范，VCC、VDD、+5V乱用，到了PCB布线的时候电源分割非常痛苦。我的习惯是：5V电源网络命名为VCC_5V，3.3V命名为VCC_3V3，GND统一叫GND，清晰明了。

第三个坑是没有做测试点。对于需要调试的板子，我强烈建议在关键信号线上预留测试点，比如ADC输入引脚、PWM输出引脚、串口TX/RX引脚。焊接完板子后拿示波器或万用表量信号，有测试点真的能省很多事。

4. 软件代码架构与核心模块实现

4.1 代码工程的整体组织方式

代码我用的是STM32标准外设库开发，配合Keil MDK5编译环境。为什么不直接上HAL库？因为标准库代码更接近寄存器底层，能让人真正理解STM32的工作原理，而且网上现成的参考代码最多，遇到问题比较好查。如果你习惯用HAL库，逻辑上是一样的，无非是API名字不同。

工程文件按功能模块组织：

• main.c：主函数，系统初始化、主循环调度
• sys.c / delay.c：时钟配置和延时函数
• usart.c：串口初始化与数据发送
• adc.c：ADC采集配置
• timer.c：定时器配置
• i2c.c / oled.c：OLED屏驱动
• dht11.c：DHT11温湿度采集
• mq2.c：烟雾浓度采样与处理
• key.c：按键扫描处理
• control.c：报警与风扇联动逻辑

每个模块一个.c文件配一个.h头文件，互不干扰，后续想增删功能直接改对应模块就行。这种模块化组织方式也是实际工程开发的基本功，哪怕项目再小，我都不建议把所有代码堆在一个main.c里。

4.2 系统初始化流程详解

主函数的初始化顺序是有讲究的，顺序错了轻则功能异常，重则系统跑不起来。我的初始化流程是：

int main(void) { Delay_Init(); // 延时函数初始化，必须先于所有外设初始化 GPIO_Config(); // GPIO引脚配置 USART1_Config(115200); // 串口1初始化，用于上位机通信 ADC1_Config(); // ADC配置，用于采集MQ-2模拟信号 TIM2_Config(); // 定时器配置，用于系统调度和按键消抖 OLED_Init(); // OLED显示屏初始化 OLED_Clear(); // 清屏 DHT11_Init(); // DHT11传感器初始化 MQ2_Init(); // MQ-2烟雾传感器初始化 Key_Init(); // 按键初始化 Control_Init(); // 报警与风扇控制引脚初始化 // 初始化完成后显示欢迎界面 OLED_ShowString(0, 0, "Charging Pile"); OLED_ShowString(0, 2, "Safety Monitor"); OLED_ShowString(0, 4, "System Init OK"); Delay_Ms(2000); OLED_Clear(); // 加载默认报警阈值 g_temp_alarm = 45; // 温度报警阈值（℃） g_smoke_alarm = 50; // 烟雾报警阈值（%） while(1) { Task_Process(); // 主循环任务调度 } }

延时函数最先初始化是因为后面所有模块初始化都需要用到延时，比如OLED上电后要等一段时间才能稳定、DHT11起始信号需要精确的时序延时。如果把延时初始化放在后面，前面的外设初始化可能因为时序不对而失败。

4.3 DHT11温湿度读取：单总线协议踩坑记录

DHT11用的是单总线协议，只有一根数据线，读写数据和命令都通过这根线完成。协议本身不算复杂，但时序要求比较严格，主机发起通信后，DHT11会先回应一个80μs的低电平响应信号，然后发送40位数据：8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。

我直接贴出我封装好的读取代码，这里包含了完整的时序控制：

// 从DHT11读取一个字节数据 static uint8_t DHT11_ReadByte(void) { uint8_t i, byte = 0; for(i = 0; i < 8; i++) { // 等待数据线变高，表示数据位开始 while(DHT11_DQ_IN() == 0); Delay_Us(40); // 高电平持续40us后采样 if(DHT11_DQ_IN() == 1) // 如果还是高电平，说明这一位是1 { byte |= (0x80 >> i); // 将对应的位置1 } // 等待数据位结束，回到低电平 while(DHT11_DQ_IN() == 1); } return byte; } // 读取DHT11温湿度数据 uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5]; uint8_t i; // 主机发送起始信号：拉低数据线至少18ms DHT11_DQ_OUT_LOW(); Delay_Ms(20); // 释放总线，拉高数据线 DHT11_DQ_OUT_HIGH(); Delay_Us(30); // 切换为输入模式，等待DHT11响应 DHT11_DQ_SET_INPUT(); // 检测响应信号：低电平80us + 高电平80us if(DHT11_DQ_IN() == 0) { // 等待80us的低电平响应结束 while(DHT11_DQ_IN() == 0); // 等待80us的高电平响应结束 while(DHT11_DQ_IN() == 1); // 连续读取5个字节数据 for(i = 0; i < 5; i++) { buf[i] = DHT11_ReadByte(); } // 校验 if((buf[0] + buf[1] + buf[2] + buf[3]) == buf[4]) { *humidity = buf[0]; *temperature = buf[2]; return 0; // 读取成功 } } return 1; // 读取失败 }

在实际调这个代码的时候，我踩过一个影响很大的坑：DHT11的数据引脚在通信结束后要释放总线，也就是拉高，但我一开始没有切换GPIO方向，导致下一次读取时起始信号发不出去。解决方法是每次通信前都要把GPIO引脚配置成输出模式，通信结束后再配置成输入模式，代码里的DHT11_DQ_SET_INPUT()就是干这个的。

时序还有一点要特别注意，DHT11定义了数据位“0”和数据位“1”的电平持续时间，数据位“0”的高电平持续约26到28μs，数据位“1”的高电平持续约70μs。所以我读取每一位时，在检测到高电平后延时40μs再采样，高电平还在就是“1”，已经变低就是“0”，这个采样点很关键。

4.4 MQ-2烟雾浓度采集：ADC采样与数据处理

MQ-2输出的是模拟电压信号，STM32通过ADC1的通道1（PA1引脚）采集这个电压。采集本身不复杂，难的是把AD值转换成一个有意义的浓度值。

我的处理思路是：先采集10次ADC值，去掉最大最小值后取平均，减少随机噪声干扰。然后把平均AD值映射到0到100的浓度百分比。STM32的ADC是12位的，理论范围是0到4095。但在实际测试中，MQ-2在纯净空气中的输出电压大约0.2V左右，对应ADC值约170；在打火机气体靠近时输出电压能到3V以上，对应ADC值超过2500。所以我把映射范围定在0到3000，超过3000按100%算。

// MQ-2烟雾浓度采集 uint16_t MQ2_GetValue(void) { uint32_t sum = 0; uint16_t adc_value; uint8_t i; // 连续采集10次 for(i = 0; i < 10; i++) { adc_value = ADC_GetValue(); sum += adc_value; Delay_Ms(10); } // 计算平均值 adc_value = sum / 10; // 映射到0-100范围 if(adc_value >= 3000) return 100; else if(adc_value <= 170) return 0; else return (adc_value - 170) * 100 / (3000 - 170); }

这里有个细节要想清楚：MQ-2的模拟输出和气体浓度并不是线性关系，严格来说是指数关系。所以在做高精度测量时通常需要查表或者分段拟合曲线。我们这个应用场景是报警监测，关注的是“浓度有没有超阈值”而不是“浓度精确是多少”，线性映射已经够用了。如果你追求更准的读数，可以拿标准气体标定，做一条浓度-ADC值的拟合曲线写进代码里。

4.5 报警判定与联动控制逻辑

报警判定逻辑是整个控制程序的核心，我设计了一套分级报警机制。正常状态下，绿色LED常亮，OLED实时显示环境参数；当温度或烟雾浓度超过阈值时，进入报警状态，红色LED闪烁、蜂鸣器鸣叫、风扇自动开启。

void Control_Process(void) { // 读取当前传感器数据 uint8_t temp, humi; uint8_t smoke = MQ2_GetValue(); uint8_t flame = Flame_GetStatus(); // 火焰传感器，1为正常，0为检测到火焰 DHT11_ReadData(&humi, &temp); // 判断报警条件 if((temp >= g_temp_alarm) || (smoke >= g_smoke_alarm) || (flame == 0)) { Set_Alarm_State(1); // 进入报警状态 Fan_SetStatus(1); // 开启风扇排风 } else { Set_Alarm_State(0); // 恢复正常状态 Fan_SetStatus(0); // 关闭风扇 } // 更新OLED显示 OLED_ShowTempHumi(temp, humi); OLED_ShowSmoke(smoke); OLED_ShowAlarmStatus(); }

报警状态的执行我放在了定时器中断里，每500ms翻转一次LED和蜂鸣器状态，实现闪烁效果。这样做的好处是闪烁频率精确不受主循环影响，而且不用在主循环里写延时，不会阻塞其他任务。

报警恢复我加了一个“去抖”逻辑：要连续3次检测到正常状态才解除报警。这看起来是个小细节，但实际应用非常重要，否则传感器读数稍微波动一下，系统就会在报警和正常之间来回切换，蜂鸣器响一下停一下，非常烦人。

4.6 OLED显示设计：一屏看清所有环境状态

OLED这一块我用的是0.96寸128x64分辨率的I2C接口屏，驱动芯片是SSD1306。我在驱动代码里实现了中英文字符显示函数，可以指定坐标显示字符串。

显示界面布局我做成了三行信息加一行状态栏：

• 第一行：显示温度和湿度，格式为 Temp: 25C Humi: 60%
• 第二行：显示烟雾浓度，格式为 Smoke: 30%
• 第三行：显示火焰状态，格式为 Flame: Normal/Detected
• 第四行：显示系统工作状态，Normal或者Alarm

OLED刷新不需要太快，我设置的是每500ms刷新一次，刷新太快反而会有残影，而且占用CPU时间。这里提个醒，SSD1306的驱动代码网上版本很多，有些写的比较绕，我建议找那种代码简洁、注释清晰的版本，重点看I2C读写函数和显存刷新逻辑。

// OLED显示核心代码示例 void OLED_ShowTempHumi(uint8_t temp, uint8_t humi) { char buf[20]; sprintf(buf, "Temp:%dC Humi:%d%%", temp, humi); OLED_ShowString(0, 0, buf); }

5. 仿真环境搭建与Proteus仿真过程

5.1 为什么仿真：硬件不到位也能先把逻辑跑通

在硬件打样或者开发板到位之前，先用仿真软件把代码逻辑跑通，是一件性价比极高的事情。我用的是Proteus 8 Professional，它支持STM32F103系列的仿真，可以直接加载Keil编译生成的hex文件运行。这样能提前验证DHT11的时序读取、ADC通道配置、OLED显示驱动这些模块的代码正确性，不用等到板子贴好了再一步步查问题。

很多初学者容易忽略仿真这一步，觉得反正最后要把代码烧到板子上，仿真多此一举。但我做项目这些年，仿真真的能帮你省下大量调试时间。比如DHT11单总线时序这种时序敏感型外设，在仿真里可以反复观察引脚电平时序，快速定位问题；而在实物调试时只能靠示波器或者逻辑分析仪，门槛高不少。

5.2 Proteus仿真电路搭建与配置步骤

在Proteus中搭建仿真电路，第一步是从元件库里找到需要的元件。我这里列一下仿真用的元件清单，方便你照着搭：

• STM32F103C8主控芯片：在元件库中搜索“STM32F103C8”
• DHT11温湿度传感器：搜索“DHT11”
• MQ-2烟雾传感器：搜索“MQ2”或者用“MQ-2”代替，如果元件库没有直接用可变电阻模拟模拟输出也可以
• 火焰传感器：Proteus里没有直接的火焰传感器模型，我用一个开关代替，高电平正常、低电平报警
• OLED显示屏：搜索“OLED”或者用“LM016L”液晶屏代替验证逻辑
• 蜂鸣器、LED、电阻、按键、风扇电机等基础元件

搭建的时候按照原理图的连接关系逐一连线。电源部分直接用Proteus的电源符号，不需要像实物一样搭降压电路。晶振电路要接上，否则仿真跑不起来。特别注意STM32的BOOT0和BOOT1引脚要接GND，不然程序可能不按预期运行。

5.3 仿真运行：加载hex文件与调试技巧

仿真电路搭好之后，双击STM32芯片，在弹出的属性对话框里找到Program File选项，选择Keil工程编译生成的hex文件。如果你用的是以下Keil配置，编译后会在工程目录的Objects文件夹下生成hex文件：

Target Options -> Output -> Create HEX File 打勾

然后点击Proteus左下角的运行按钮，仿真就能跑起来了。在仿真过程中，我习惯把DHT11的“Temperature”和“Humidity”属性值直接改掉，模拟温度从正常升高到超过阈值的过程，验证报警逻辑是否正确触发。这是仿真比实物调试方便的地方——实物想模拟传感器输出变化还得用热风枪吹或者气体靠近，仿真里鼠标改一下属性就行。

仿真中我遇到过一个比较典型的问题：程序加载后OLED屏幕没有反应。排查后发现是I2C的时序问题——Proteus的I2C仿真速度比实物快，我在I2C通信的每个字节之间加的延时不够，导致OLED初始化失败。把延时从1μs加大到10μs之后，OLED正常显示了。这个坑在实物调试时不一定会遇到，但也提醒了我写驱动代码的时候延时参数要留足余量。

5.4 仿真与实物的差异：你需要知道的真相

必须跟大家说实话，Proteus仿真和实物还是有不少差异的。最明显的就是DHT11的时序，Proteus里的DHT11模型对时序要求没有那么严格，稍微宽松的时序也可能通过仿真；但实物的DHT11对时序要求非常苛刻，起始信号的低电平时间、读写时的高电平采样点都不能差太多，否则读出来的数据全是0xFF或者读取失败。

还有就是ADC采样，Proteus里的模拟信号是理想化的，不会有噪声干扰，但实物上MQ-2的信号会有波动，需要在软件上做滤波处理。我的代码里做了多次采样取平均就是这个原因。

所以我的建议是：仿真主要用来验证逻辑正确性，模块之间的交互逻辑、报警联动、按键处理这些逻辑性的东西在仿真里调试最方便；而传感器时序、电源稳定性、信号完整性这些硬件相关的问题，还是得靠实物调试来解决。

6. 实际操作中遇到的典型问题与排查方法

6.1 编译与烧录环节的常见报错

代码写好了，编译第一关就会卡住不少人。我把自己遇到过的几个高频报错和解决方案整理成表格，方便大家对照排查：

其中Flash Download failed这个报错是我见过的最高频问题，九成是ST-Link的杜邦线接触不良。SWDIO接PA13、SWCLK接PA14，这两根线别接反了，别接到别的引脚上。如果用的是ST-Link V2那种小棒子，插到电脑上还要看驱动是否装好，设备管理器里能看到“STM32 ST-LINK”设备才算正常。还有就是芯片如果之前烧过“读保护”相关的配置，也会导致烧录失败，这种情况按着复位键再点下载，或者先全片擦除再下载。

最近很多朋友问我遇到error: no stm32 target found! if your product embeds debug authentication这类报错怎么处理。这个报错只有两个原因，要么芯片没进入调试模式，要么调试器根本没连上目标板。不要慌，按照这个顺序查：先量板子有没有3.3V电压，再查SWDIO和SWCLK有没有接对，然后查复位引脚电平是否正常，最后查ST-Link的固件版本是否需要升级。排到这基本能解决90%以上的问题。这里要特别提醒，部分新版芯片默认开启了调试保护（Debug Authentication），需要用新版驱动配合解锁工具处理，不是硬件坏了。

6.2 DHT11读取数据异常：全是传感器时序的锅

DHT11读出来的数据永远是0xFF，或者温度湿度显示成乱码，是我在这个项目里遇到最多的问题。排查思路如下。

第一步，检查传感器供电。DHT11供电范围3.3V到5V，但数据线上的逻辑电平不能超过供电电压，如果MCU是3.3V而DHT11是5V供电，数据线需要接上拉电阻到3.3V做电平匹配，否则通信不稳定。

第二步，检查数据线上拉电阻。DHT11数据线是开漏输出，必须配上拉电阻才能输出高电平，没有上拉电阻或者上拉电阻阻值太大（超过10KΩ）都会导致通信失败。我用的是4.7KΩ，实测工作最稳定。

第三步，用逻辑分析仪看时序。如果没有逻辑分析仪，可以在代码里用GPIO翻转配合示波器查看。DHT11起始信号要求主机先把总线拉低至少18ms，然后释放总线，等待传感器响应。如果起始信号时间不够，传感器根本不会响应。

第四步，检查读取间隔。DHT11的采样周期是1秒，两次读取之间至少要间隔1秒以上。读取太频繁，传感器来不及更新内部数据，读出来的数值会异常。我在主循环里加了判断，每次读取后至少等1秒钟再进行下一次读取。

6.3 MQ-2数值跳变、零点漂移问题

MQ-2在刚上电的时候，传感器内部加热丝还没稳定，输出的电压会一直漂，有时还会突然跳高。我实测过，冷启动时读取的烟雾浓度数值能在前30秒内从5%漂到30%再去。解决方案就是代码里加一个预热延时，系统上电后先让MQ-2预热60秒，再开始正常监测。

另外MQ-2长期使用后零点会漂移，在纯净空气中的输出电压不再是出厂标定的0.2V，可能变成0.35V甚至更高。如果你直接按固定零点做映射，会导致浓度读数偏高。解决思路有两个：一是程序里加校准模式，长按按键3秒进入校准状态，系统采集当前值作为新的零点；二是在上位机或者代码里做动态零点修正，取最近5分钟的最小值作为参考零点。

// 简单的动态零点修正思路 static uint16_t zero_base = 170; // 默认零点ADC值 void MQ2_AutoZero(void) { uint16_t current = ADC_GetValue(); // 每采集10次，更新一次最小零点 if(current < zero_base) { zero_base = current; } // 浓度计算时减去零点偏移 uint16_t diff = (adc_value > zero_base) ? (adc_value - zero_base) : 0; smoke_percent = diff * 100 / (3000 - zero_base); }

6.4 报警频繁误触发与阈值设置策略

做环境监测系统，最怕的就是误报警。你想想，充电桩旁边有人抽烟，或者汽车尾气飘过来，系统一直响个不停，最后用户干脆把报警功能关了，那这套系统就失去意义了。为了解决误报问题，我从算法和阈值两个维度做了优化。

算法层面，前面提到过报警恢复去抖，其实报警触发也应该去抖。我的做法是连续3次采样都超过阈值才触发报警，而不是单次采样超标就报警。这能有效过滤掉传感器噪声和瞬时干扰信号。

阈值设置层面，我默认设置的是温度45℃、烟雾浓度50%。这个值不是拍脑袋定的，而是参考了充电桩行业相关标准中对工作环境的要求。当然不同场景需求不同，所以我做了按键可调的设计。设置键进入阈值调节模式，加键增加阈值，减键减少阈值，长按设置键保存并退出。调好的参数我存储到了MCU内部Flash的最后一个扇区，掉电不丢失。

有一个实际操作中的技巧分享给大家：调试阈值的时候，可以把串口输出的实时数据接到上位机看曲线，先观察一段时间正常运行时的数据波动范围，然后把报警阈值设定在正常范围上限的1.2倍左右。比如正常温度在30到35度波动，上限35度，那么45度左右报警就合理，不会被正常的波动触发。

7. 系统测试方法与功能验证

7.1 模块级功能测试清单

拿到焊接好的板子，先别急着整套系统跑起来，一步一步测。我的测试顺序是电源先测、最小系统次之、各传感器模块再逐个验证、最后整体联调。

第一步测试电源：不焊MCU和传感器之前，先给板子通电，用万用表量关键节点电压，5V和3.3V必须正常。这个步骤能避免后级短路把芯片烧了。

第二步测试最小系统：焊上STM32，用ST-Link尝试连接芯片，读取芯片ID。能读出0x410立即跳闸，说明芯片已经在工作。烧个LED闪烁的测试程序，验证GPIO、时钟、烧录链路都正常。

第三步测各传感器模块：逐个接入DHT11、MQ-2、火焰传感器、OLED，分别测试数据读取是否正常。每接一个模块就验证一次，不要一次性全焊上再查问题，否则出了故障不知道是谁的问题。

第四步联调：所有模块正常后，把完整的固件烧进去，进行整体功能验证。

7.2 环境模拟测试：怎么证明系统真的能报警

功能是否可靠，不能靠嘴上说，得设计测试场景验证。

温度报警测试：我用了一个可调温的电吹风，对着DHT11吹热风，观察OLED显示的温度数值上升。当温度超过设定的45℃阈值时，蜂鸣器响、红灯亮、风扇自动开启。把热风移走，温度回落后，系统应自动解除报警。实测下来，热风距离传感器10cm左右，温度能从25℃升到50℃以上，整个响应过程大约10秒。

烟雾报警测试：我准备了一只打火机，不点火，只放气（丙烷气体），气嘴靠近MQ-2传感器约5cm处，轻按放气阀释放少量气体。观察OLED上的烟雾浓度数值从个位数迅速上升，超过50%阈值后系统触发报警。注意测试时保持通风，别在密闭房间猛放气，毕竟是可燃气体，量大了有危险。

火焰报警测试：用打火机点火后，火焰放在火焰传感器前方10cm以内，传感器输出低电平触发报警。这个测试我建议在通风良好的地方做，旁边备一罐水，安全第一。

7.3 数据稳定性和可靠性测试

报警功能验证完后，我还做了一项容易被忽视的测试：长时间运行稳定性测试。让系统连续运行24小时，每2小时记录一次传感器读数，观察数据漂移情况和系统有无死机重启。

实测下来，DHT11的温湿度读数在24小时内波动很小，温度稳定在±1℃以内。MQ-2的零点漂移在长时间运行后比较明显，6小时后纯空气中的浓度读数从2%慢慢漂到8%左右。所以我在固件里加了自动零点校准逻辑，每5分钟更新一次最小ADC值作为零点基准，解决长时间运行读数漂移的问题。

系统死机方面，STM32本身可靠性非常高，只要不是供电波动导致复位，基本不会死机。我更担心的是看门狗问题——万一主循环卡死在某个传感器的等待循环里（比如DHT11通信异常时一直while等待），系统就彻底无响应了。所以我在项目里加入了独立看门狗IWDG，主循环每隔500ms喂狗一次。如果程序跑飞或者卡死，看门狗超时自动复位系统，保证系统能够自动恢复。这是工程级代码和课程设计代码的一个重要区别。

8. 项目复盘与可扩展方向

整个项目做下来，我最大的体会是：嵌入式系统开发，硬件设计和软件编程从来都不是孤立的两条线，而是互相约束、互相验证的一个整体。原理图设计时要考虑软件怎么驱动，写驱动代码时要考虑硬件实际怎么接，只有在两者之间来回审视，才能做出真正可靠的作品。

这个充电桩环境安全监测系统，从我最初的原型验证到现在整理成开源全套资料，前前后后迭代了好几个版本。第一版只是把传感器数据读出来显示到OLED上，第二版加了报警和风扇联动，第三版改进了报警去抖和零点校准，到开源发布的这一版才算真正做到了“系统”的层级——有采集、有显示、有告警、有联动、有参数配置、有异常恢复。

最后说几个我认为后续值得扩展的方向。第一个是加无线通信模块，比如ESP8266，把采集到的环境数据通过WiFi上传到云平台，实现手机远程查看和告警推送。这样充电桩运维人员在办公室就能监控全站充电桩的运行环境，这是从“单机监测”走向“物联网监测”的关键一步。第二个是增加数据存储功能，用SD卡模块或者外挂Flash芯片，把历史环境数据记录下来，方便事后追溯分析。第三个是升级传感器方案，比如把DHT11换成SHT30，把MQ-2换成更专业的电化学传感器，进一步提高测量精度和长期稳定性。

我自己在实际项目开发中还摸索出一个习惯：每一版硬件改版，都会把核心问题记录在一个文档里，包括现象、原因、解决方法和验证结果。这个习惯在后期维护和升级的时候价值巨大，很多问题当时解决了很快忘记，半年后客户反馈同样问题，翻文档一眼就能找到答案。也建议正在看这篇文章的朋友，别嫌记录麻烦，好记性不如烂笔头，这在嵌入式开发和所有工程项目里都是通用的真理。

如果你打算把这个项目作为毕业设计或者课程设计的起点，时间充裕的话，我强烈建议你在跑通基础功能后，挑一到两个方向做深度扩展。比如做充电桩远程监控云平台的本科生，就是把ESP8266模块、MQTT协议、云服务器搭了一套完整的“端-管-云”架构，答辩时老师给的评价明显不一样。一个能完整讲述“为什么这样设计、遇到过什么问题、怎么解决”的项目，远比一个功能多但说不清来龙去脉的项目更有说服力。