1. 项目概述与整体设计思路1.1 这项目到底能做什么环境质量监测听起来像个挺大的词但落到实际场景里其实就是我们身边最常见的几个痛点办公室空气闷不闷、新装修的房子甲醛担忧用传感器做间接判断、机房温湿度是否超限、鱼缸或温室的环境参数监控。这套基于STM32的监测系统就是在这些需求上做的一个标准化硬件方案。整个系统以STM32F103C8T6为核心外围挂上温湿度传感器、空气质量传感器采集数据后在OLED屏上实时显示一旦指标超限就触发蜂鸣器报警同时通过串口把数据发出去。我去年帮朋友改造工作室的时候做了这套原型后来整理代码时发现它非常适合拿来开源——硬件结构简单代码逻辑清晰而且仿真和实物都能跑通。这个项目最适合三类人看一是正在学STM32、想找一个完整实战案例的初学者二是需要做课程设计或毕业设计的学生三是不想从零画板子、想快速搭一套环境监测原型的工程师。它不像网上那些纯理论教程那样零散而是从原理图到代码到仿真一步到位照着做完你对单片机开发的全流程就有完整概念了。1.2 系统架构与方案选型这套系统的数据流其实很简单传感器负责感知物理量单片机负责采集和处理数据输出设备负责呈现和告警。用专业一点的话说就是感知层-控制层-输出层的三层架构。架构虽简单选型却得抠细节。首先是主控芯片我选了STM32F103C8T6而不是国产替代或更高级的F4系列原因很直接C8T6性价比高、资料多、Proteus仿真模型成熟。蓝色药丸板几十块钱一片I/O口够用72MHz主频跑这些传感器绰绰有余。对于环境监测这种低速数据采集场景你用H7反而属于性能浪费。传感器方面温湿度我选了DHT11。有人会问为什么不上DHT22或SHT30精度不是更高吗我的看法是做项目要看定位如果做高精度仪器级产品当然要上SHT30但作为一套教学和原型验证性质的系统DHT11完全够用而且Proteus里自带DHT11模型这决定了它才是仿真最顺畅的选择。空气质量检测我用的是MQ-2烟雾传感器原因同样是它在仿真环境里有成熟模型而且原理简单——本质就是个电阻值随气体浓度变化的分压电路通过ADC读取电压即可。显示部分采用0.96寸OLEDI2C接口4根线就能搞定在仿真里表现也稳定。报警部分用有源蜂鸣器加一个NPN三极管驱动GPIO输出高电平就能控制。整体下来这套系统的元器件成本控制在五十块钱以内非常适合做入门项目。1.3 为什么仿真和实物要一起做很多初学者有一个误区只追求实物觉得仿真多此一举。说实话这种想法耽误了不少人。仿真的核心价值不在于替代实物而在于让你在没有硬件的时候把代码逻辑完全跑通以及排查问题时多一只眼睛。我做这个项目时Proteus仿真和真实板子的调试流程是并行的先对照原理图在Proteus里把电路搭出来把固件逻辑在仿真环境里验证通过再去焊接实物。这样做的好处非常明显——当实物出现问题的时候我至少能确认代码逻辑没问题问题大概率出在接线或者元器件本身排查范围直接缩小一半。实际上我在调这个项目的过程中确实靠仿真定位了一个棘手问题这个后面在常见问题章节里细说。2. 硬件电路设计原理图拆解2.1 引脚分配与核心资源规划画原理图之前先把资源分配想清楚这是很多新手容易忽略的环节。我见过不少同学拿到芯片就凭感觉接外设结果GPIO冲突、复用功能打架最后代码怎么调都不对。STM32F103C8T6有48个引脚但实际可用的GPIO也就37个左右好钢要用在刀刃上。我这套系统最终的引脚分配如下外设引脚说明DHT11温湿度PA0单总线数据需外部上拉MQ-2烟雾传感器PA1ADC1通道1读取模拟电压OLEDI2CPB6SCL/ PB7SDA硬件I2C1需4.7k上拉蜂鸣器PB0有源蜂鸣器高电平触发LED指示灯PB1状态指示低电平点亮串口PA9TX/ PA10RXUSART1用于数据输出这里有一个很重要的原则ADC引脚和I2C引脚尽量不要复用。虽然你可以通过切换模式来实现分时复用但那样代码复杂度会上升而且容易出问题。做项目不是考试没必要给自己增加难度。另外PA0我特意选了带WKUP功能的引脚后续如果想扩展低功耗模式这个引脚可以派上用场。2.2 最小系统电路别在细节上翻车STM32最小系统包括电源、晶振、复位、BOOT和下载电路。很多初学者以为这部分直接用现成的最小系统板就行不用自己画这话对一半——用开发板当然可以但如果你不亲手画一遍最小系统你对MCU工作的基础条件就没有深刻理解。电源部分我用AMS1117-3.3把USB的5V降到3.3V。输入输出各接一个10uF电解电容和100nF陶瓷电容做滤波这是数据手册推荐的做法别省。我见过有人为省两个电容结果系统一上电就复位测量发现电源纹波高达几百毫伏。单片机对电源的要求比你想的苛刻电源不稳后面全是坑。晶振电路采用8MHz主晶振加两个20pF负载电容。注意电容值不是随便选的要根据晶振的负载电容参数计算。如果晶振规格书的负载电容是12pF那并联的两个电容一般在15-22pF之间。32.768kHz的RTC晶振我这里没有画因为F103C8T6的RTC时钟可以用内部低速时钟虽然精度差一些但对环境监测这种场景没影响。复位电路就是一个10k上拉电阻加一个0.1uF电容到地。BOOT0通过一个10k下拉到地确保从Flash启动。下载电路留了SWD接口——4个排针分别是VCC、GND、SWDIOPA13、SWCLKPA14。这里我强烈建议用SWD而不是串口ISP下载因为SWD不占用USART资源后面你想用串口做通信调试的时候会非常方便。2.3 传感器接口电路与信号调理DHT11的接口电路看起来简单——一个数据引脚接PA0再挂一个上拉电阻。但这个上拉电阻的取值有讲究。DHT11的数据手册要求上拉电阻在4.7k到10k之间我选了5.1k实测波形最稳定。如果上拉太小传感器可能拉不动总线太大信号上升沿变缓时序容易出错。别小看这个电阻我后面调试时遇到过一次通信不稳定最后发现就是上拉电阻用成了100k简直是个隐形杀手。MQ-2传感器模块的输出其实是模拟量但很多人没注意它内部有一个比较器电路。模块上通常有一个电位器可以调节阈值输出端有两路一路是数字量的DO一路是模拟量的AO。我们这里要用的是模拟量AO因为它接在LM393比较器的输入端之前输出的电压范围大致是0到5V对应传感器检测到的气体浓度。这个信号直接接到STM32的ADC引脚之前需要用电阻分压把电压降到0到3.3V范围因为STM32的ADC参考电压是3.3V直接接入5V会烧引脚。我用了两个电阻一个10k和一个6.8k组成分压电路实测能把4V左右的峰值电压降下来同时不影响精度因为后端ADC的输入阻抗足够高不会对分压比造成明显影响。温湿度传感器的数据引脚接法更简单数据线直接连PA0外部上拉到3.3V即可。这里有一个容易忽略的点DHT11的供电电压是3.3V到5.5V都可以但数据引脚的电平取决于供电电压。如果你用5V给它供电那数据引脚的高电平可能就是5V同样不能直接进STM32。所以我的做法是统一用3.3V给DHT11供电省去了电平转换的麻烦。2.4 输出设备与报警电路OLED显示屏用的是I2C接口SDA和SCL分别接PB7和PB6。OLED模块本身一般自带上拉电阻但我还是习惯在外部再挂两个4.7k上拉宁可多此一举也不能让总线因为上拉不足而出问题。OLED的供电是3.3V刚好和主控共用一组电源。蜂鸣器电路就是个典型的三极管开关电路。我用了S8050 NPN三极管基极串联一个1k电阻连接到PB0发射极接地集电极接蜂鸣器的负极蜂鸣器正极接3.3V。当PB0输出高电平时基极电流约3mA三极管饱和导通蜂鸣器通电发声。这个1k电阻是限流用的计算方式是基极电流 (3.3V - 0.7V) / 1k 2.6mA而S8050的放大倍数在100以上集电极电流足够驱动一个30mA左右的蜂鸣器。注意一个细节蜂鸣器的工作电压要和它的规格匹配。我手头这个蜂鸣器是3.3V有源蜂鸣器所以接在3.3V上没问题。如果你买到的是5V有源蜂鸣器接在3.3V上音量会小很多甚至不响。采购元器件时一定要看清楚规格这是老生常谈的坑了。LED指示灯电路就简单了PB1接一个1k限流电阻到LED正极LED负极接地。PB1输出高电平时LED点亮。等一下我前面引脚分配表里写的是低电平点亮这里统一一下经典接法是GPIO高电平点亮即输出1时LED亮。如果LED接法和这里一致代码里直接HAL_GPIO_WritePin输出高电平即可别让代码和硬件打架。电源入口我加了一个自恢复保险丝和一个防反接二极管。防反接二极管用的是1N5819肖特基压降只有0.3V左右对5V电源来说损失不大。自恢复保险丝选500mA规格防止意外短路烧USB口。这两个器件成本不到五毛钱但对系统的安全性提升非常大。很多开发板不带这些保护一旦插反就放烟花不值当。3. 固件开发与核心代码实现3.1 开发环境搭建KeilCubeMX组合拳这套系统的固件开发我的建议是用STM32CubeMX生成初始化代码然后在Keil MDK里写业务逻辑。为什么不用纯寄存器开发或者纯标准库因为这个项目的重点是环境监测系统的整体逻辑不是研究寄存器。用CubeMX可以快速生成时钟树、GPIO和ADC的初始化代码把时间花在业务代码上而且生成的代码结构清晰对初学者来说也是个学习模板。CubeMX中的关键配置项有这些。时钟树外部8MHz晶振倍频到72MHz系统时钟。ADC1开启通道1对应PA1采样时间选择55.5周期分辨率12位连续转换模式关闭。这里说下采样时间为什么要选55.5周期。ADC采样时间越长采样结果越稳定但转换速度越慢。环境监测的数据更新频率不高每秒采一次足够所以采样时间选长一点没有性能压力结果是数据更平滑。I2C1配置为100kHz标准模式这个速率对OLED显示足够了。USART1配置为115200-8-N-1用于调试输出。GPIO就不用说了PA0、PB0、PB1全部设置为输出模式唯一需要注意的就是PA1必须设置成模拟模式否则ADC读取会异常——很多人在这里栽过跟头GPIO配置成复用模式去读ADC结果读出来永远是0或者乱跳。硬件I2C和软件模拟I2C之争也是个老话题。F103的硬件I2C确实名声不太好网上抱怨的人一大把问题主要集中在总线阻塞和错误处理上。但如果你用的是HAL库并处理好错误回调硬件I2C其实是可以用的而且不占用CPU资源。为了在仿真里更稳定这个项目我用的是模拟I2C方式只在CubeMX里把PB6和PB7设为普通推挽输出然后用代码模拟时序。3.2 DHT11驱动单总线时序的坑与对策DHT11用的是单总线协议一根线既要发命令又要收数据时序要求非常严格。整个通信过程大概是这样的主机先把总线拉低至少18ms然后释放并延时20-40usDHT11收到起始信号后响应回一个80us的低电平再回一个80us的高电平作为握手。之后传感器开始输出40位数据8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。每一位数据的编码方式是通过高电平的持续时间来区分的高电平26-28us代表0高电平70us代表1。用代码实现这套时序最关键的就是延时函数要准。HAL库的HAL_Delay()只能精确到毫秒级而DHT11时序需要微秒级延时所以需要自己写一个微秒延时函数。我通常用一个简单的循环空转实现配合DWT-CYCCNT做精确定时F103跑72MHz一个时钟周期约13.9ns这样微秒级延时可以做得非常精确。另一个要点是GPIO的方向切换。DHT11通信过程中引脚要不断在输出和输入之间切换主机发信号时是输出模式等传感器响应时又要切回输入模式。用HAL库的操作是HAL_GPIO_WritePin设置电平再用HAL_GPIO_ReadPin读取数据。每个切换之间都必须严格遵守时序比如发送起始信号后必须在20-40us内释放总线并切换为输入这个窗口很短代码顺序错了就会导致通信失败。我封装了一个DHT11_Read()函数返回温度值和湿度值。函数内部有个超时保护机制如果总线上一直没数据超过10ms就返回错误码。这个设计非常有必要因为DHT11有时候会不响应如果代码没有超时保护主程序就会卡死在这里。我在实际调试中就遇到过一次传感器没插好导致程序死等最后就是靠超时判断定位出问题。3.3 模拟量采集让STM32看懂电压MQ-2的输出经过分压后进入ADC1通道1我们在代码里要做的就是把ADC的采样值换算成实际电压再通过电压变化判断气体浓度变化。ADC是一个12位模数转换器采样值范围是0到4095对应电压0到3.3V。换算公式很简单电压 采样值 * 3.3 / 4095。在这个项目里我们不关心具体的ppm浓度值因为MQ-2本身的精度达不到定量测量的水平它更适合做定性判断——电压越高说明气体浓度越高。所以我在代码里设置了一个阈值判断ADC采样值超过800大约对应0.64V电压就认为空气质量异常触发蜂鸣器报警。在读取ADC的时候有个很重要的工程实践做多次采样取平均而不是一次采样就直接用。因为ADC采集过程中会混入噪声尤其是电源电压波动的时候单次采样值可能偏差很大。我一般连续采样10次去掉最大值和最小值再取平均这样得到的结果就比较稳定。这本质上是一个简单的软件滤波算法效果非常明显。实测下来滤波前后的抖动幅度从±50 LSB降到了±5 LSB以内。模块在刚上电的时候有个预热过程大约1分钟左右这期间输出电压会漂移。所以在代码初始化阶段我会做一次校准读取把上电30秒后的ADC平均值作为基准值后续判断时用当前值减去基准值的差值和阈值进行比较这样能有效消除温漂和器件个体差异的影响。3.4 逻辑主循环与报警状态机主程序的逻辑结构采用了经典的单片机循环架构一个while(1)循环里依次完成数据读取、数据显示、报警判断和串口输出。这种简单的轮询结构对这种系统足够了没必要上RTOS。关键点在报警判断的逻辑。如果只是简单地超了就报警那蜂鸣器会响个不停使用体验很差。我加了一个状态机正常状态、报警状态、恢复状态三种。当检测值超过上限时进入报警状态蜂鸣器持续鸣叫当检测值降到上限以下但仍在迟滞区间时保持报警状态一段时间比如30秒防止指标在阈值边缘抖动导致蜂鸣器频繁开关。这个设计在工业现场叫滞回控制逻辑上类似于温控器的回差设置。OLED显示部分我用了一个轻量级的简化字库在屏幕上轮播显示温湿度、气体浓度状态和系统运行时间。每2秒刷新一次显示内容刷新频率太高反而会看到闪烁因为OLED的驱动芯片SSD1306刷新全屏需要一定时间。串口输出部分我设计了简单的数据帧格式帧头长度数据校验。帧头是0xAA 0x55长度是固定值数据区包含温度和湿度的整数部分和小数部分、ADC采样值、报警状态校验用的是累加和。这个协议格式虽然简单但已经具备完整的数据帧特征后续如果想接上位机或者物联网云平台直接在这个基础上扩展就行不需要推倒重来。4. 仿真搭建与联调验证4.1 Proteus环境下的电路搭建仿真部分我用的是Proteus 8 Professional版本8.9以上都支持STM32F103系列模型。在添加元件的时候可以通过关键字搜索STM32F103C8找到对应型号另外需要添加的元件清单包括DHT11、MQ-2Proteus里可能叫MQ2或者GAS-MQ2、OLED显示屏搜索OLED 12864、有源蜂鸣器、LED、电阻若干、电源端子。典型的连接方式和实物一致。有一个地方需要特别注意Proteus里的MQ-2模型不像实物那样需要预热它的输出是直接根据输入浓度参数变化的比实物听话得多。在仿真时你可以通过调节元件属性面板里的GAS_CONCENTRATION参数来模拟气体浓度变化观察系统报警逻辑是否正常。但正是因为它太听话了仿真顺利不能完全说明实物也顺利这我在后面的问题排查章节会展开说。OLED在Proteus里的连接稍微有点特殊。Proteus的OLED模型I2C地址默认是0x3C和实物一致。如果你的代码里写的地址是0x3D会出现屏幕无显示的故障。这其实是最常见的仿真翻车原因之一。蜂鸣器在Proteus里要选择带ACTIVE标记的型号也就是有源蜂鸣器模型否则不会发声。仿真电路连接完成后把Keil编译生成的HEX文件加载到Proteus的MCU元件里就能运行了。双击STM32芯片在Program File里选择编译输出的Hex文件同时设置外部晶振频率8MHz。如果你在CubeMX里配置的外部晶振是8MHz仿真里也设置成8MHz两边不一致会导致串口波特率计算错误。4.2 虚拟终端与逻辑分析让数据看得见Proteus里有个非常实用的工具叫Virtual Terminal也就是虚拟串口终端可以用来替代实物的USB转串口模块。把虚拟终端的RXD接到STM32的PA9TX引脚TXD接到PA10RX引脚波特率设置成115200匹配代码里的配置就能在仿真界面上实时看到串口输出。另一个值得推荐的调试工具是Proteus的Logic Analyzer逻辑分析仪。调试DHT11时序的时候把探针挂在PA0引脚上可以直观地看到单总线上的电平变化波形。我第一次把这段波形放大看的时候DHT11返回的数据位的高电平持续时间清晰可见哪种高电平是0、哪种是1一眼就能分辨——比自己用示波器打波形还直观。仿真还帮我发现了一个只有逻辑分析才能暴露的问题DHT11的数据位顺序。DHT11传输数据时湿度高字节在前、湿度低字节在后、温度高字节、温度低字节、校验和最后。如果有人把字节顺序搞反显示出来的温度和湿度就会完全错乱。在实物上这个错误很难察觉因为你可能根本不知道真实温度是多少但在仿真里用逻辑分析仪看清每一位的顺序后这个问题就无处遁形了。4.3 仿真通过≠万事大吉两个反例我第一次做这套系统仿真时一切看起来都很完美OLED显示正常DHT11读数合理调节MQ-2的气体浓度参数后蜂鸣器能正确报警。但等实物焊接完成后问题接踵而至。第一个问题OLED在实物上显示正常但蜂鸣器不响。我排查了接线没问题量了GPIO电平程序设置高电平时引脚确实有3.3V输出。问题出在三极管基极的1k电阻变成了10k基极电流只有0.26mA三极管没法完全导通蜂鸣器得到的电流不够自然不响。这个坑在仿真里是发现不了的因为Proteus不会模拟三极管的临界导通状态。所以别以为仿真通过就等于硬件正确元器件的实际参数差异、焊接质量这些仿真一概无能为力。第二个问题实物上DHT11读数极不稳定甚至经常读取失败。我在仿真里用逻辑分析仪确认了代码时序没问题怀疑是上拉电阻阻值不对。测量后发现板子上本应是5.1k的上拉电阻被换成了100k原因是我打样时料单弄错了。换上正确的5.1k电阻后问题立刻消失。仿真通过是代码逻辑正确的必要条件而非充分条件这个经验我算是刻在脑子里了。5. 常见问题与排查技巧实录5.1 DHT11通信异常从时序到硬件一网打尽DHT11报错是这套系统里最常见的故障表现形式一般是读出来的温湿度全是0或者读取函数一直返回超时。排查思路我总结成了一套流程按照这个顺序走大部分问题都能解决。先检查硬件接线。DHT11的数据引脚有没有接对PA0上拉电阻有没有接阻值是否在4.7k到10k之间。这个看起来简单但实际项目中杜邦线松动、虚焊、上拉电阻虚焊是最常见的原因。再检查GPIO配置。PA0有没有正确初始化为推挽输出模式读取阶段有没有正确切换为输入模式。CubeMX里如果配置成了开漏输出DHT11的低电平响应信号会被上拉电阻拉高数据自然读不出来。接着检查微秒延时函数是否准确。很多初学者用HAL_Delay(1)来延时1微秒这完全不对——HAL_Delay的最小单位是毫秒。我用DWT计数器实现的微秒延时函数精度可以达到几十纳秒用逻辑分析仪实测过误差在1%以内。最后检查传感器供电。DHT11的供电电压允许范围是3.3V到5V但如果供电电压太低比如电池供电的板子电压已经掉到3V以下传感器内部逻辑就乱了表现为数据完全不对。这类问题在低功耗场景中特别坑人因为代码和接线都没问题纯粹是电压不够。5.2 OLED白屏或花屏I2C地址和上拉电阻的博弈OLED不出字是另一个高频问题。首先要区分两种情况完全没反应和显示花屏。完全没反应优先检查I2C地址。SSD1306驱动芯片的I2C地址是可以配置的取决于模块上地址选择电阻。绝大多数OLED模块默认地址是0x3C但如果你买到的模块是0x3D地址代码里用的还是0x3C那屏幕肯定是没反应的。我写驱动的时候会把地址做成宏定义万一不行改一个宏就行。如果地址没错但屏幕还是不亮检查SDA和SCL的上拉电阻。I2C总线是开漏结构必须有上拉电阻才能工作。有些OLED模块板载了上拉电阻有些没有。如果你的模块既没板载上拉外部也没接那通讯根本建立不起来。用一个万用表量一下SDA或SCL引脚电压如果稳定在3.3V附近说明上拉工作正常如果电压被拉低到1V以下基本上就是上拉电阻缺失。花屏问题就更好定位了一般是I2C速率过高或者信号线上有干扰。把I2C时钟从400kHz降到100kHz大部分花屏现象会消失。F103的硬件I2C在400kHz下对PCB布线要求其实挺高的如果你用的是杜邦线飞线那400kHz就会出问题。仿真里倒是没有这个困扰因为Proteus的虚拟总线不会受物理布线影响。5.3 ADC读数跳变与MQ-2数据漂移MQ-2的ADC读数在实物上跳变第一个要排除的是电源噪声。MQ-2内部有个加热丝工作时消耗约150mA电流这个电流的波动会通过电源网络传导到ADC参考电压上导致采样值跟着跳。解决办法有几种一是给MQ-2单独用一个电源引脚供电不从主控电源取电二是在MQ-2模块的供电端加一个100uF电解电容用储能来缓冲加热丝的电流冲击三是ADC读取时引入软件滤波多次采样取平均。还有一个容易被忽略的因素是ADC参考电压不稳定。F103的ADC参考电压是VREF引脚在C8T6芯片上通常直接和VDD绑在一起。如果整个系统的3.3V电源有波动ADC的参考电压也在波动采出来的数据自然不准。如果你对测量精度有更高要求可以外接一个基准电压源给VREF但那样电路就复杂了。对这个项目来说软件滤波已经足够。数据漂移则是另一个话题。MQ-2刚上电时内部加热丝还没达到工作温度输出会很低随着加热时间增长输出慢慢稳定下来。我刚做完实物时发现ADC读数在上电后十分钟内持续上升一度怀疑硬件出了问题。查了资料才知道这是MQ系列传感器的正常现象——需要预热。我后来在代码里做了校准流程上电后先运行30秒把这时的ADC读数作为基线存储起来后续判断空气质量时用的是当前读数减基线的差值。这样处理以后环境空气质量变化引起的电压波动就能被准确捕获加热丝老化导致的基线漂移也被抵消了大部分。5.4 从仿真到实物移植的水土不服最后聊聊仿真和实物之间的差别。Proteus仿真是个理想化的环境电压永远是完美的3.3V晶振永远按时起振元器件参数永远和标注一致。实物世界完全不是这样。我遇到过最典型的问题是晶振起振失败。仿真里MCU肯定会用外部晶振跑起来但实物上如果晶振虚焊或者负载电容选择不当晶振可能就不起振程序根本不运行。排查方法是把示波器探头点在晶振脚上看有没有振荡波形。如果没有检查晶振是不是插反了无源晶振不分正反但有些贴片有脚位或者换一个晶振试试。还有个经典坑是电源上电时序。实物系统如果主控3.3V已经稳定了但传感器还没供电传感器输出引脚可能会有不确定电平灌入主控引脚导致芯片锁死。解决办法是让传感器的电源用主控的GPIO控制——像DHT11的VCC通过一个MOS管开关主控上电后延时200ms再打开传感器电源保证主控先稳定再让传感器工作。这个设计在低功耗项目中尤其重要。最终心得我做这套系统最大的收获并不是代码本身而是养成了一个习惯把仿真当成调试工具而不是验证手段。仿真不只是用来检查有没有画错的工具它更像一个带时间旅行功能的示波器——你可以暂停时间、放大波形、注入故障这些在实物上调不了的操作在仿真里都是举手之劳。这个项目我已经把除MQ-2传感器因为选型差异比较大之外的核心代码、原理图源文件、Proteus仿真工程整理好了环境和逻辑部分大家可以直接复用。如果你也是从零开始接触STM32强烈建议按这个流程走一遍——先仿真、再实物、遇到问题别急着网上乱搜先把仿真和实物的差异比对清楚你会发现很多问题自己就能定位出根源。希望这篇记录对你有用。 基于STM32的环境监测系统设计：从Proteus仿真到实物实现
1. 项目概述与整体设计思路1.1 这项目到底能做什么环境质量监测听起来像个挺大的词但落到实际场景里其实就是我们身边最常见的几个痛点办公室空气闷不闷、新装修的房子甲醛担忧用传感器做间接判断、机房温湿度是否超限、鱼缸或温室的环境参数监控。这套基于STM32的监测系统就是在这些需求上做的一个标准化硬件方案。整个系统以STM32F103C8T6为核心外围挂上温湿度传感器、空气质量传感器采集数据后在OLED屏上实时显示一旦指标超限就触发蜂鸣器报警同时通过串口把数据发出去。我去年帮朋友改造工作室的时候做了这套原型后来整理代码时发现它非常适合拿来开源——硬件结构简单代码逻辑清晰而且仿真和实物都能跑通。这个项目最适合三类人看一是正在学STM32、想找一个完整实战案例的初学者二是需要做课程设计或毕业设计的学生三是不想从零画板子、想快速搭一套环境监测原型的工程师。它不像网上那些纯理论教程那样零散而是从原理图到代码到仿真一步到位照着做完你对单片机开发的全流程就有完整概念了。1.2 系统架构与方案选型这套系统的数据流其实很简单传感器负责感知物理量单片机负责采集和处理数据输出设备负责呈现和告警。用专业一点的话说就是感知层-控制层-输出层的三层架构。架构虽简单选型却得抠细节。首先是主控芯片我选了STM32F103C8T6而不是国产替代或更高级的F4系列原因很直接C8T6性价比高、资料多、Proteus仿真模型成熟。蓝色药丸板几十块钱一片I/O口够用72MHz主频跑这些传感器绰绰有余。对于环境监测这种低速数据采集场景你用H7反而属于性能浪费。传感器方面温湿度我选了DHT11。有人会问为什么不上DHT22或SHT30精度不是更高吗我的看法是做项目要看定位如果做高精度仪器级产品当然要上SHT30但作为一套教学和原型验证性质的系统DHT11完全够用而且Proteus里自带DHT11模型这决定了它才是仿真最顺畅的选择。空气质量检测我用的是MQ-2烟雾传感器原因同样是它在仿真环境里有成熟模型而且原理简单——本质就是个电阻值随气体浓度变化的分压电路通过ADC读取电压即可。显示部分采用0.96寸OLEDI2C接口4根线就能搞定在仿真里表现也稳定。报警部分用有源蜂鸣器加一个NPN三极管驱动GPIO输出高电平就能控制。整体下来这套系统的元器件成本控制在五十块钱以内非常适合做入门项目。1.3 为什么仿真和实物要一起做很多初学者有一个误区只追求实物觉得仿真多此一举。说实话这种想法耽误了不少人。仿真的核心价值不在于替代实物而在于让你在没有硬件的时候把代码逻辑完全跑通以及排查问题时多一只眼睛。我做这个项目时Proteus仿真和真实板子的调试流程是并行的先对照原理图在Proteus里把电路搭出来把固件逻辑在仿真环境里验证通过再去焊接实物。这样做的好处非常明显——当实物出现问题的时候我至少能确认代码逻辑没问题问题大概率出在接线或者元器件本身排查范围直接缩小一半。实际上我在调这个项目的过程中确实靠仿真定位了一个棘手问题这个后面在常见问题章节里细说。2. 硬件电路设计原理图拆解2.1 引脚分配与核心资源规划画原理图之前先把资源分配想清楚这是很多新手容易忽略的环节。我见过不少同学拿到芯片就凭感觉接外设结果GPIO冲突、复用功能打架最后代码怎么调都不对。STM32F103C8T6有48个引脚但实际可用的GPIO也就37个左右好钢要用在刀刃上。我这套系统最终的引脚分配如下外设引脚说明DHT11温湿度PA0单总线数据需外部上拉MQ-2烟雾传感器PA1ADC1通道1读取模拟电压OLEDI2CPB6SCL/ PB7SDA硬件I2C1需4.7k上拉蜂鸣器PB0有源蜂鸣器高电平触发LED指示灯PB1状态指示低电平点亮串口PA9TX/ PA10RXUSART1用于数据输出这里有一个很重要的原则ADC引脚和I2C引脚尽量不要复用。虽然你可以通过切换模式来实现分时复用但那样代码复杂度会上升而且容易出问题。做项目不是考试没必要给自己增加难度。另外PA0我特意选了带WKUP功能的引脚后续如果想扩展低功耗模式这个引脚可以派上用场。2.2 最小系统电路别在细节上翻车STM32最小系统包括电源、晶振、复位、BOOT和下载电路。很多初学者以为这部分直接用现成的最小系统板就行不用自己画这话对一半——用开发板当然可以但如果你不亲手画一遍最小系统你对MCU工作的基础条件就没有深刻理解。电源部分我用AMS1117-3.3把USB的5V降到3.3V。输入输出各接一个10uF电解电容和100nF陶瓷电容做滤波这是数据手册推荐的做法别省。我见过有人为省两个电容结果系统一上电就复位测量发现电源纹波高达几百毫伏。单片机对电源的要求比你想的苛刻电源不稳后面全是坑。晶振电路采用8MHz主晶振加两个20pF负载电容。注意电容值不是随便选的要根据晶振的负载电容参数计算。如果晶振规格书的负载电容是12pF那并联的两个电容一般在15-22pF之间。32.768kHz的RTC晶振我这里没有画因为F103C8T6的RTC时钟可以用内部低速时钟虽然精度差一些但对环境监测这种场景没影响。复位电路就是一个10k上拉电阻加一个0.1uF电容到地。BOOT0通过一个10k下拉到地确保从Flash启动。下载电路留了SWD接口——4个排针分别是VCC、GND、SWDIOPA13、SWCLKPA14。这里我强烈建议用SWD而不是串口ISP下载因为SWD不占用USART资源后面你想用串口做通信调试的时候会非常方便。2.3 传感器接口电路与信号调理DHT11的接口电路看起来简单——一个数据引脚接PA0再挂一个上拉电阻。但这个上拉电阻的取值有讲究。DHT11的数据手册要求上拉电阻在4.7k到10k之间我选了5.1k实测波形最稳定。如果上拉太小传感器可能拉不动总线太大信号上升沿变缓时序容易出错。别小看这个电阻我后面调试时遇到过一次通信不稳定最后发现就是上拉电阻用成了100k简直是个隐形杀手。MQ-2传感器模块的输出其实是模拟量但很多人没注意它内部有一个比较器电路。模块上通常有一个电位器可以调节阈值输出端有两路一路是数字量的DO一路是模拟量的AO。我们这里要用的是模拟量AO因为它接在LM393比较器的输入端之前输出的电压范围大致是0到5V对应传感器检测到的气体浓度。这个信号直接接到STM32的ADC引脚之前需要用电阻分压把电压降到0到3.3V范围因为STM32的ADC参考电压是3.3V直接接入5V会烧引脚。我用了两个电阻一个10k和一个6.8k组成分压电路实测能把4V左右的峰值电压降下来同时不影响精度因为后端ADC的输入阻抗足够高不会对分压比造成明显影响。温湿度传感器的数据引脚接法更简单数据线直接连PA0外部上拉到3.3V即可。这里有一个容易忽略的点DHT11的供电电压是3.3V到5.5V都可以但数据引脚的电平取决于供电电压。如果你用5V给它供电那数据引脚的高电平可能就是5V同样不能直接进STM32。所以我的做法是统一用3.3V给DHT11供电省去了电平转换的麻烦。2.4 输出设备与报警电路OLED显示屏用的是I2C接口SDA和SCL分别接PB7和PB6。OLED模块本身一般自带上拉电阻但我还是习惯在外部再挂两个4.7k上拉宁可多此一举也不能让总线因为上拉不足而出问题。OLED的供电是3.3V刚好和主控共用一组电源。蜂鸣器电路就是个典型的三极管开关电路。我用了S8050 NPN三极管基极串联一个1k电阻连接到PB0发射极接地集电极接蜂鸣器的负极蜂鸣器正极接3.3V。当PB0输出高电平时基极电流约3mA三极管饱和导通蜂鸣器通电发声。这个1k电阻是限流用的计算方式是基极电流 (3.3V - 0.7V) / 1k 2.6mA而S8050的放大倍数在100以上集电极电流足够驱动一个30mA左右的蜂鸣器。注意一个细节蜂鸣器的工作电压要和它的规格匹配。我手头这个蜂鸣器是3.3V有源蜂鸣器所以接在3.3V上没问题。如果你买到的是5V有源蜂鸣器接在3.3V上音量会小很多甚至不响。采购元器件时一定要看清楚规格这是老生常谈的坑了。LED指示灯电路就简单了PB1接一个1k限流电阻到LED正极LED负极接地。PB1输出高电平时LED点亮。等一下我前面引脚分配表里写的是低电平点亮这里统一一下经典接法是GPIO高电平点亮即输出1时LED亮。如果LED接法和这里一致代码里直接HAL_GPIO_WritePin输出高电平即可别让代码和硬件打架。电源入口我加了一个自恢复保险丝和一个防反接二极管。防反接二极管用的是1N5819肖特基压降只有0.3V左右对5V电源来说损失不大。自恢复保险丝选500mA规格防止意外短路烧USB口。这两个器件成本不到五毛钱但对系统的安全性提升非常大。很多开发板不带这些保护一旦插反就放烟花不值当。3. 固件开发与核心代码实现3.1 开发环境搭建KeilCubeMX组合拳这套系统的固件开发我的建议是用STM32CubeMX生成初始化代码然后在Keil MDK里写业务逻辑。为什么不用纯寄存器开发或者纯标准库因为这个项目的重点是环境监测系统的整体逻辑不是研究寄存器。用CubeMX可以快速生成时钟树、GPIO和ADC的初始化代码把时间花在业务代码上而且生成的代码结构清晰对初学者来说也是个学习模板。CubeMX中的关键配置项有这些。时钟树外部8MHz晶振倍频到72MHz系统时钟。ADC1开启通道1对应PA1采样时间选择55.5周期分辨率12位连续转换模式关闭。这里说下采样时间为什么要选55.5周期。ADC采样时间越长采样结果越稳定但转换速度越慢。环境监测的数据更新频率不高每秒采一次足够所以采样时间选长一点没有性能压力结果是数据更平滑。I2C1配置为100kHz标准模式这个速率对OLED显示足够了。USART1配置为115200-8-N-1用于调试输出。GPIO就不用说了PA0、PB0、PB1全部设置为输出模式唯一需要注意的就是PA1必须设置成模拟模式否则ADC读取会异常——很多人在这里栽过跟头GPIO配置成复用模式去读ADC结果读出来永远是0或者乱跳。硬件I2C和软件模拟I2C之争也是个老话题。F103的硬件I2C确实名声不太好网上抱怨的人一大把问题主要集中在总线阻塞和错误处理上。但如果你用的是HAL库并处理好错误回调硬件I2C其实是可以用的而且不占用CPU资源。为了在仿真里更稳定这个项目我用的是模拟I2C方式只在CubeMX里把PB6和PB7设为普通推挽输出然后用代码模拟时序。3.2 DHT11驱动单总线时序的坑与对策DHT11用的是单总线协议一根线既要发命令又要收数据时序要求非常严格。整个通信过程大概是这样的主机先把总线拉低至少18ms然后释放并延时20-40usDHT11收到起始信号后响应回一个80us的低电平再回一个80us的高电平作为握手。之后传感器开始输出40位数据8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。每一位数据的编码方式是通过高电平的持续时间来区分的高电平26-28us代表0高电平70us代表1。用代码实现这套时序最关键的就是延时函数要准。HAL库的HAL_Delay()只能精确到毫秒级而DHT11时序需要微秒级延时所以需要自己写一个微秒延时函数。我通常用一个简单的循环空转实现配合DWT-CYCCNT做精确定时F103跑72MHz一个时钟周期约13.9ns这样微秒级延时可以做得非常精确。另一个要点是GPIO的方向切换。DHT11通信过程中引脚要不断在输出和输入之间切换主机发信号时是输出模式等传感器响应时又要切回输入模式。用HAL库的操作是HAL_GPIO_WritePin设置电平再用HAL_GPIO_ReadPin读取数据。每个切换之间都必须严格遵守时序比如发送起始信号后必须在20-40us内释放总线并切换为输入这个窗口很短代码顺序错了就会导致通信失败。我封装了一个DHT11_Read()函数返回温度值和湿度值。函数内部有个超时保护机制如果总线上一直没数据超过10ms就返回错误码。这个设计非常有必要因为DHT11有时候会不响应如果代码没有超时保护主程序就会卡死在这里。我在实际调试中就遇到过一次传感器没插好导致程序死等最后就是靠超时判断定位出问题。3.3 模拟量采集让STM32看懂电压MQ-2的输出经过分压后进入ADC1通道1我们在代码里要做的就是把ADC的采样值换算成实际电压再通过电压变化判断气体浓度变化。ADC是一个12位模数转换器采样值范围是0到4095对应电压0到3.3V。换算公式很简单电压 采样值 * 3.3 / 4095。在这个项目里我们不关心具体的ppm浓度值因为MQ-2本身的精度达不到定量测量的水平它更适合做定性判断——电压越高说明气体浓度越高。所以我在代码里设置了一个阈值判断ADC采样值超过800大约对应0.64V电压就认为空气质量异常触发蜂鸣器报警。在读取ADC的时候有个很重要的工程实践做多次采样取平均而不是一次采样就直接用。因为ADC采集过程中会混入噪声尤其是电源电压波动的时候单次采样值可能偏差很大。我一般连续采样10次去掉最大值和最小值再取平均这样得到的结果就比较稳定。这本质上是一个简单的软件滤波算法效果非常明显。实测下来滤波前后的抖动幅度从±50 LSB降到了±5 LSB以内。模块在刚上电的时候有个预热过程大约1分钟左右这期间输出电压会漂移。所以在代码初始化阶段我会做一次校准读取把上电30秒后的ADC平均值作为基准值后续判断时用当前值减去基准值的差值和阈值进行比较这样能有效消除温漂和器件个体差异的影响。3.4 逻辑主循环与报警状态机主程序的逻辑结构采用了经典的单片机循环架构一个while(1)循环里依次完成数据读取、数据显示、报警判断和串口输出。这种简单的轮询结构对这种系统足够了没必要上RTOS。关键点在报警判断的逻辑。如果只是简单地超了就报警那蜂鸣器会响个不停使用体验很差。我加了一个状态机正常状态、报警状态、恢复状态三种。当检测值超过上限时进入报警状态蜂鸣器持续鸣叫当检测值降到上限以下但仍在迟滞区间时保持报警状态一段时间比如30秒防止指标在阈值边缘抖动导致蜂鸣器频繁开关。这个设计在工业现场叫滞回控制逻辑上类似于温控器的回差设置。OLED显示部分我用了一个轻量级的简化字库在屏幕上轮播显示温湿度、气体浓度状态和系统运行时间。每2秒刷新一次显示内容刷新频率太高反而会看到闪烁因为OLED的驱动芯片SSD1306刷新全屏需要一定时间。串口输出部分我设计了简单的数据帧格式帧头长度数据校验。帧头是0xAA 0x55长度是固定值数据区包含温度和湿度的整数部分和小数部分、ADC采样值、报警状态校验用的是累加和。这个协议格式虽然简单但已经具备完整的数据帧特征后续如果想接上位机或者物联网云平台直接在这个基础上扩展就行不需要推倒重来。4. 仿真搭建与联调验证4.1 Proteus环境下的电路搭建仿真部分我用的是Proteus 8 Professional版本8.9以上都支持STM32F103系列模型。在添加元件的时候可以通过关键字搜索STM32F103C8找到对应型号另外需要添加的元件清单包括DHT11、MQ-2Proteus里可能叫MQ2或者GAS-MQ2、OLED显示屏搜索OLED 12864、有源蜂鸣器、LED、电阻若干、电源端子。典型的连接方式和实物一致。有一个地方需要特别注意Proteus里的MQ-2模型不像实物那样需要预热它的输出是直接根据输入浓度参数变化的比实物听话得多。在仿真时你可以通过调节元件属性面板里的GAS_CONCENTRATION参数来模拟气体浓度变化观察系统报警逻辑是否正常。但正是因为它太听话了仿真顺利不能完全说明实物也顺利这我在后面的问题排查章节会展开说。OLED在Proteus里的连接稍微有点特殊。Proteus的OLED模型I2C地址默认是0x3C和实物一致。如果你的代码里写的地址是0x3D会出现屏幕无显示的故障。这其实是最常见的仿真翻车原因之一。蜂鸣器在Proteus里要选择带ACTIVE标记的型号也就是有源蜂鸣器模型否则不会发声。仿真电路连接完成后把Keil编译生成的HEX文件加载到Proteus的MCU元件里就能运行了。双击STM32芯片在Program File里选择编译输出的Hex文件同时设置外部晶振频率8MHz。如果你在CubeMX里配置的外部晶振是8MHz仿真里也设置成8MHz两边不一致会导致串口波特率计算错误。4.2 虚拟终端与逻辑分析让数据看得见Proteus里有个非常实用的工具叫Virtual Terminal也就是虚拟串口终端可以用来替代实物的USB转串口模块。把虚拟终端的RXD接到STM32的PA9TX引脚TXD接到PA10RX引脚波特率设置成115200匹配代码里的配置就能在仿真界面上实时看到串口输出。另一个值得推荐的调试工具是Proteus的Logic Analyzer逻辑分析仪。调试DHT11时序的时候把探针挂在PA0引脚上可以直观地看到单总线上的电平变化波形。我第一次把这段波形放大看的时候DHT11返回的数据位的高电平持续时间清晰可见哪种高电平是0、哪种是1一眼就能分辨——比自己用示波器打波形还直观。仿真还帮我发现了一个只有逻辑分析才能暴露的问题DHT11的数据位顺序。DHT11传输数据时湿度高字节在前、湿度低字节在后、温度高字节、温度低字节、校验和最后。如果有人把字节顺序搞反显示出来的温度和湿度就会完全错乱。在实物上这个错误很难察觉因为你可能根本不知道真实温度是多少但在仿真里用逻辑分析仪看清每一位的顺序后这个问题就无处遁形了。4.3 仿真通过≠万事大吉两个反例我第一次做这套系统仿真时一切看起来都很完美OLED显示正常DHT11读数合理调节MQ-2的气体浓度参数后蜂鸣器能正确报警。但等实物焊接完成后问题接踵而至。第一个问题OLED在实物上显示正常但蜂鸣器不响。我排查了接线没问题量了GPIO电平程序设置高电平时引脚确实有3.3V输出。问题出在三极管基极的1k电阻变成了10k基极电流只有0.26mA三极管没法完全导通蜂鸣器得到的电流不够自然不响。这个坑在仿真里是发现不了的因为Proteus不会模拟三极管的临界导通状态。所以别以为仿真通过就等于硬件正确元器件的实际参数差异、焊接质量这些仿真一概无能为力。第二个问题实物上DHT11读数极不稳定甚至经常读取失败。我在仿真里用逻辑分析仪确认了代码时序没问题怀疑是上拉电阻阻值不对。测量后发现板子上本应是5.1k的上拉电阻被换成了100k原因是我打样时料单弄错了。换上正确的5.1k电阻后问题立刻消失。仿真通过是代码逻辑正确的必要条件而非充分条件这个经验我算是刻在脑子里了。5. 常见问题与排查技巧实录5.1 DHT11通信异常从时序到硬件一网打尽DHT11报错是这套系统里最常见的故障表现形式一般是读出来的温湿度全是0或者读取函数一直返回超时。排查思路我总结成了一套流程按照这个顺序走大部分问题都能解决。先检查硬件接线。DHT11的数据引脚有没有接对PA0上拉电阻有没有接阻值是否在4.7k到10k之间。这个看起来简单但实际项目中杜邦线松动、虚焊、上拉电阻虚焊是最常见的原因。再检查GPIO配置。PA0有没有正确初始化为推挽输出模式读取阶段有没有正确切换为输入模式。CubeMX里如果配置成了开漏输出DHT11的低电平响应信号会被上拉电阻拉高数据自然读不出来。接着检查微秒延时函数是否准确。很多初学者用HAL_Delay(1)来延时1微秒这完全不对——HAL_Delay的最小单位是毫秒。我用DWT计数器实现的微秒延时函数精度可以达到几十纳秒用逻辑分析仪实测过误差在1%以内。最后检查传感器供电。DHT11的供电电压允许范围是3.3V到5V但如果供电电压太低比如电池供电的板子电压已经掉到3V以下传感器内部逻辑就乱了表现为数据完全不对。这类问题在低功耗场景中特别坑人因为代码和接线都没问题纯粹是电压不够。5.2 OLED白屏或花屏I2C地址和上拉电阻的博弈OLED不出字是另一个高频问题。首先要区分两种情况完全没反应和显示花屏。完全没反应优先检查I2C地址。SSD1306驱动芯片的I2C地址是可以配置的取决于模块上地址选择电阻。绝大多数OLED模块默认地址是0x3C但如果你买到的模块是0x3D地址代码里用的还是0x3C那屏幕肯定是没反应的。我写驱动的时候会把地址做成宏定义万一不行改一个宏就行。如果地址没错但屏幕还是不亮检查SDA和SCL的上拉电阻。I2C总线是开漏结构必须有上拉电阻才能工作。有些OLED模块板载了上拉电阻有些没有。如果你的模块既没板载上拉外部也没接那通讯根本建立不起来。用一个万用表量一下SDA或SCL引脚电压如果稳定在3.3V附近说明上拉工作正常如果电压被拉低到1V以下基本上就是上拉电阻缺失。花屏问题就更好定位了一般是I2C速率过高或者信号线上有干扰。把I2C时钟从400kHz降到100kHz大部分花屏现象会消失。F103的硬件I2C在400kHz下对PCB布线要求其实挺高的如果你用的是杜邦线飞线那400kHz就会出问题。仿真里倒是没有这个困扰因为Proteus的虚拟总线不会受物理布线影响。5.3 ADC读数跳变与MQ-2数据漂移MQ-2的ADC读数在实物上跳变第一个要排除的是电源噪声。MQ-2内部有个加热丝工作时消耗约150mA电流这个电流的波动会通过电源网络传导到ADC参考电压上导致采样值跟着跳。解决办法有几种一是给MQ-2单独用一个电源引脚供电不从主控电源取电二是在MQ-2模块的供电端加一个100uF电解电容用储能来缓冲加热丝的电流冲击三是ADC读取时引入软件滤波多次采样取平均。还有一个容易被忽略的因素是ADC参考电压不稳定。F103的ADC参考电压是VREF引脚在C8T6芯片上通常直接和VDD绑在一起。如果整个系统的3.3V电源有波动ADC的参考电压也在波动采出来的数据自然不准。如果你对测量精度有更高要求可以外接一个基准电压源给VREF但那样电路就复杂了。对这个项目来说软件滤波已经足够。数据漂移则是另一个话题。MQ-2刚上电时内部加热丝还没达到工作温度输出会很低随着加热时间增长输出慢慢稳定下来。我刚做完实物时发现ADC读数在上电后十分钟内持续上升一度怀疑硬件出了问题。查了资料才知道这是MQ系列传感器的正常现象——需要预热。我后来在代码里做了校准流程上电后先运行30秒把这时的ADC读数作为基线存储起来后续判断空气质量时用的是当前读数减基线的差值。这样处理以后环境空气质量变化引起的电压波动就能被准确捕获加热丝老化导致的基线漂移也被抵消了大部分。5.4 从仿真到实物移植的水土不服最后聊聊仿真和实物之间的差别。Proteus仿真是个理想化的环境电压永远是完美的3.3V晶振永远按时起振元器件参数永远和标注一致。实物世界完全不是这样。我遇到过最典型的问题是晶振起振失败。仿真里MCU肯定会用外部晶振跑起来但实物上如果晶振虚焊或者负载电容选择不当晶振可能就不起振程序根本不运行。排查方法是把示波器探头点在晶振脚上看有没有振荡波形。如果没有检查晶振是不是插反了无源晶振不分正反但有些贴片有脚位或者换一个晶振试试。还有个经典坑是电源上电时序。实物系统如果主控3.3V已经稳定了但传感器还没供电传感器输出引脚可能会有不确定电平灌入主控引脚导致芯片锁死。解决办法是让传感器的电源用主控的GPIO控制——像DHT11的VCC通过一个MOS管开关主控上电后延时200ms再打开传感器电源保证主控先稳定再让传感器工作。这个设计在低功耗项目中尤其重要。最终心得我做这套系统最大的收获并不是代码本身而是养成了一个习惯把仿真当成调试工具而不是验证手段。仿真不只是用来检查有没有画错的工具它更像一个带时间旅行功能的示波器——你可以暂停时间、放大波形、注入故障这些在实物上调不了的操作在仿真里都是举手之劳。这个项目我已经把除MQ-2传感器因为选型差异比较大之外的核心代码、原理图源文件、Proteus仿真工程整理好了环境和逻辑部分大家可以直接复用。如果你也是从零开始接触STM32强烈建议按这个流程走一遍——先仿真、再实物、遇到问题别急着网上乱搜先把仿真和实物的差异比对清楚你会发现很多问题自己就能定位出根源。希望这篇记录对你有用。