1. 项目能做什么：一套可落地的居家安全监测方案
做嵌入式开发这些年，我见过不少智能家居方案，要么依赖云平台、要么成本高得离谱，真正能解决实际问题又适合拿来学习或二次开发的并不多。这套基于STM32单片机的智能安防与燃气监测系统，是我在实际项目中沉淀下来的一套完整方案，代码、原理图、仿真一套齐全，软硬件都验证过。一句话概括：它能在检测到燃气泄漏或非法入侵时，通过本地声光报警和继电器联动及时提醒你，同时把环境温湿度直观显示出来。
很多人第一反应是"这不就是个传感器加单片机吗"，确实，核心逻辑不复杂，但把细节做扎实了——电源设计、传感器校准、报警阈值处理、看门狗防死机——才能让它真正在家庭环境里稳定跑起来，而不是只在实验室里能工作。这套系统特别适合三类人：刚学完STM32基础、想找一个完整项目练手的学生；准备做毕业设计、需要软硬件一体的工程类课题的同学；想给宿舍或家里做一个低成本本地安防设备的极客爱好者。哪怕你只是想把ADC采集、数码管动态扫描、状态机这些基本功串起来，这套代码也值得翻一翻。
我不打算把整套代码贴一遍，那没意义。我更想把项目背后的设计思路、关键电路的处理方式、代码里那些容易踩坑的细节讲清楚，让你拿到资料后能真正复现，甚至能按自己的需求改出第二版。这比"复制粘贴然后跑通"有价值得多。
2. 整体设计与器件选型：先想清楚再动手
2.1 主控为什么选STM32F103C8T6
主控芯片的选择几乎是这个项目的第一步。市面上能用在这类场景的方案不少：51单片机、Arduino、ESP8266、STM32系列。我选STM32F103C8T6，核心原因有三个。
第一，资源够用且不浪费。C8T6是Cortex-M3内核，72MHz主频，64KB Flash、20KB SRAM，片上有3个ADC、多个定时器、丰富的GPIO和USART/I2C/SPI通信接口。这套系统要同时处理气体传感器ADC采集、温湿度传感器单总线通信、数码管动态扫描、按键输入、蜂鸣器和继电器控制，这些资源绰绰有余。相比用51，不用抠引脚分配；相比用ESP8266或者带WiFi的芯片，又不用处理协议栈的复杂度，项目本身不涉及联网，没必要给自己加戏。
第二，资料生态完善。这点对学习型项目来说太重要了。F103系列是STM32里被讲得最多的型号，无论你遇到编译报错、烧录失败还是某个外设初始化不工作的怪问题，网上几乎都能搜到答案。配合标准外设库或者HAL库，代码的可读性和移植性都很好，后续想换芯片或者加功能，改动的成本相对可控。
第三，成本因素。C8T6的散片价格很低，核心板几十块钱就能拿下，做成成品板也不心疼。再加上烧录方式灵活——可以用ST-Link，也可以用DAPLink，甚至串口ISP都能搞定，这就降低了入门门槛。
2.2 传感器选型：燃气检测选MQ-2还是MQ-5
燃气传感器的选型是这套系统里最值得花心思的地方。市面上最常见的两款是MQ-2和MQ-5，很多人搞不清楚区别，直接随便买一个，结果检测效果不理想。MQ-2对液化气、丙烷、丁烷、甲烷以及烟雾都有响应，属于"广谱型"传感器，优点是适用范围广，缺点是选择性差，炒菜油烟大了都可能误报。MQ-5则对液化气、天然气这类城市燃气更敏感，对酒精和油烟的抑制能力相对好一些，更适合"燃气泄漏监测"这个具体场景。
这套开源方案我默认以MQ-2做演示，因为它的资料最多、仿真模型最好找、买配件也最容易。但如果你要做的是真实的厨房燃气报警器，我更建议把传感器换成MQ-5，然后把灵敏度阈值调一调。硬件电路几乎不用改，因为MQ系列传感器的模块接口基本都是AO（模拟输出）+ DO（数字输出）+ VCC + GND四线制，替换成本很低。代码里只需要改一下ADC采样的报警阈值。
MQ系列传感器有一个共同特点：内部有一个加热电阻，需要预热一段时间才能稳定工作。刚上电的几分钟内，输出会有明显的漂移，这不是故障，是物理特性。所以系统上电后我会做30到60秒的"传感器预热"处理，这段时间不参与报警判断，数码管上可以显示一个倒计时或者"--"符号。这个细节很多教程都不提，但实测下来对误报率的控制非常关键。
2.3 显示与交互：数码管、按键和报警输出
显示方案我选了4位数码管，而不是LCD1602或者OLED屏。原因有三：一是数码管的动态扫描能体现定时器和GPIO的综合应用，学习价值更高；二是成本极低，几毛钱一个；三是在强光环境下数码管的可视效果比LCD更好。当然，这套代码在结构上做了抽象，如果你想换OLED屏，只需要重写显示驱动接口，上层逻辑不用动。
按键用了三个：一个"设置"键，用来进入阈值调节模式；一个"加"键、一个"减"键，用来调整报警阈值。按键处理必须做消抖，我采用的是标志位加延时扫描的方式，不用阻塞式延时，避免影响其他任务。有人会问，一个报警器要什么按键？实际使用中，不同家庭的厨房面积、通风条件差异很大，固定阈值要么太敏感天天误报，要么太迟钝真漏气了都不响，所以阈值可调是刚需。
报警输出做了两级：一级是蜂鸣器加LED声光报警，蜂鸣器用有源蜂鸣器，直接给高电平就响，不需要PWM驱动；另一级是继电器输出，可以联动电磁阀切断燃气管道，或者联动排风扇自动排风。继电器选用5V单路继电器模块，配合ULN2003或者三极管驱动，避免单片机直接被继电器线圈的反向电动势打坏。这个电路细节后面在原理图章节细说。
3. 硬件原理图拆解：每个电路都要知道为什么
3.1 电源系统的处理
整套系统的供电入口设计的是5V直流输入，可以用USB供电，也可以用适配器。5V进来之后兵分两路：一路直接供给传感器模块的加热电路、蜂鸣器和继电器；另一路经过稳压芯片降到3.3V，供给STM32主控。注意，STM32虽然标称工作电压范围是2.0到3.6V，但在这种多外设的系统中，稳定供电比极限电压更重要，我用的是一颗AMS1117-3.3。
电源电路里最容易忽略的是滤波电容的布置。原理图上，稳压芯片的输入端和输出端都要加10uF电解电容和0.1uF陶瓷电容并联，大电容储能滤波、小电容滤高频噪声。另外，STM32的每个VDD引脚旁边都要放一颗100nF的去耦电容，并且尽可能靠近引脚。这些不是玄学，是芯片数据手册明确要求的内容，很多初学者画板子不重视，结果就是系统工作不稳定、ADC采样跳得厉害，还找不到原因。
我还加了一个电源指示灯和反接保护。反接保护用的是一颗串联的肖特基二极管SS14，压降只有0.3V左右，能耗损失小，比普通二极管好。实际产品里可以换成自恢复保险丝加防反接MOS的方案，但对这个项目来说肖特基二极管足够了。
3.2 STM32最小系统：不止是"能跑"就行
F103C8T6的最小系统主要包括：晶振电路、复位电路、启动模式配置和下载电路。
晶振我用的是8MHz无源晶振，配合两个20pF负载电容。有人为了省事直接用芯片内部HSI振荡器，系统也能跑，但如果你要用定时器做精确延时、用USART做可靠通信，HSE（外部高速晶振）几乎是必需的。内部RC振荡器的精度在高温下会漂移，这在报警系统里是不能接受的误差来源。
复位电路就是一个10K上拉电阻加一个0.1uF电容，按键复位是可选的，板上我加了，调试阶段非常有用。BOOT0和BOOT1引脚通过10K电阻下拉到地，确保从Flash启动，这个不加的话芯片可能上电后不跑用户程序，是比较容易踩的坑。
下载接口我预留了SWD四线接口——SWDIO、SWCLK、GND、3.3V。很多新手纠结选SWD还是JTAG，我建议SWD，占用引脚少、下载速度快、线序简单，配合DAPLink或者ST-Link都好用。注意SWD接口的SWDIO和SWCLK在F103上默认是PA13和PA14，画原理图时别把这俩引脚安排去做别的功能，否则程序烧录进去一次之后第二次就连接不上了。
3.3 传感器采样电路：模拟量输入的正确接法
MQ-2模块的AO引脚输出的是0到5V的模拟电压，而STM32的ADC输入范围是0到3.3V，所以直接把AO接到PA1上会把芯片烧掉——这是不少新手板子"莫名奇妙"损坏的原因。正确做法是在信号进入单片机前做分压处理。最简单的方案是用两个电阻分压，比如10K和6.8K串联，把5V分压到约2V，留出安全裕量。但这个方案的缺点很明显：即使气体浓度为零，ADC也有一个基础偏置电压，后续计算浓度时要减去这个偏移量，而且分压会降低采样分辨率。
更合理的方案是改用3.3V供电的MQ-2模块。市面上有很多MQ系列模块的加热电路和检测电路都可以由3.3V直接供电，AO输出范围就是0到3.3V，可以直接接STM32的ADC引脚。如果你手头的模块必须用5V供电，那么中间加一级运放跟随器做电平搬移，或者加一个简单的电阻分压网络，总之不要让超过3.3V的电压直接怼进PA1。
ADC采样还有一个细节：STM32的ADC输入阻抗不是无限大，如果信号源阻抗过高，采样的电压值会低于实际值。MQ模块的AO输出阻抗相对较低，直接接问题不大。但如果你用的是自己搭的传感器电路，建议在ADC引脚前加一个0.1uF的电容到地，形成一个简单RC低通滤波，既能抗高频干扰，又能为ADC内部采样电容提供电荷源。
3.4 继电器和蜂鸣器驱动：别让单片机直接"打工"
继电器驱动电路是这个项目里"看起来简单但暗藏杀机"的部分。继电器线圈工作电流通常在50到100mA左右，STM32的GPIO最大输出电流在±25mA，直接驱动肯定会出问题；更重要的是，继电器线圈断电瞬间会产生很高的反向电动势，如果不处理，这个尖峰电压会通过引脚打坏单片机。
所以驱动方案用的是三极管开关电路：GPIO通过一个1K基极电阻控制S8050三极管的导通与截止，继电器线圈并联一个1N4007续流二极管，方向是反向并联在线圈两端。当三极管关断时，线圈产生的反向电动势通过续流二极管形成回路，能量被释放掉，从而保护了三极管和单片机。这个二极管的使用原理我多说一句：它的方向不能接反，接反了等于线圈直接短路，继电器永远吸合不了。
蜂鸣器驱动同理。我用的是一个NPN三极管来驱动有源蜂鸣器，GPIO高电平时三极管导通，蜂鸣器响。如果直接用GPIO接蜂鸣器，虽然声音也能响，但会导致GPIO口电流过载，长期使用有隐患。
3.5 PCB布局布线的几条经验
原理图之后就是画PCB。我建议用两层板就够，但这个项目的PCB布局有几个地方值得注意。
电源线要加宽，至少40mil以上，地线如果能铺铜就铺铜，形成完整的地平面。模拟地和数字地在这个项目里不需要严格分离，因为系统耦合度不高，但ADC采样部分的地要尽量靠近传感器地。
晶振要尽量靠近MCU的OSC引脚，晶振底下不要走信号线，模拟地铺铜，这样可以减少寄生电容对振荡频率的影响。如果晶振离得太远或者走线绕来绕去，会导致起振困难或者频率偏差。
继电器这种大功率器件最好放在板边，远离MCU和传感器。继电器动作瞬间的电磁干扰会影响ADC采样，如果位置布局不好，你会发现每次继电器开关，ADC读数就跳一下。遇到这个问题，除了物理上拉开距离，还可以在软件上做"继电器动作期间不采样"的处理，这个技巧后面代码部分会提到。
4. 软件架构与核心代码实现
4.1 工程结构与任务调度
软件部分我用的是标准外设库（SPL）风格写的，不是说HAL不好，而是SPL的代码更"直白"，逻辑链路清晰，适合拿来教学和二次开发。工程结构上，我把代码按功能拆成几个模块：main.c负责初始化、主循环和任务调度；adc.c负责气体传感器采样和滤波；dht11.c负责温湿度读取；display.c负责数码管显示；key.c负责按键扫描；alarm.c负责报警判断逻辑。
裸机编程最怕的就是写成一锅粥的while(1)大循环。这套系统里有好几个"周期性任务"：ADC采样和显示要持续进行（周期几十毫秒）；按键扫描要每5到10毫秒扫一次，否则容易漏按；温湿度读取要间隔一段时间再读，因为DHT11的响应速度没那么快，读太频繁反而会出错。
我的调度方案很简单：用一个系统节拍SysTick定时器，每1毫秒产生一次中断，中断里维护几个计数器标志。主循环里通过检查标志位来执行对应任务。比如每10毫秒执行按键扫描，每50毫秒更新一次显示，每500毫秒采样一次ADC并做滤波，每2秒读一次DHT11。这样各个任务各司其职，互不干扰。
4.2 传感器数据采集与滤波处理
气体传感器输出的模拟量需要经过ADC采样变成数字量，再换算成浓度百分比。但ADC采回来的原始值是很"毛躁"的，直接拿来做报警判断，会导致蜂鸣器时响时不响。我用了递推平均滤波：维护一个长度为8的采样数组，每次新采样值进来，就去掉最老的一个，然后求平均值。这个滤波方法对付随机噪声很有效，而且计算量小，在裸机上跑毫无压力。
换算逻辑上，ADC是12位的，参考电压3.3V，所以电压值的计算公式是float voltage = (float)adc_value * 3.3f / 4095.0f。然后根据MQ-2的特性曲线做一个简单的线性映射，把电压映射到0到100的浓度指数。注意，这个映射是"经验值"而非"精确值"，因为气体传感器的个体差异很大。真要精确测量，每一颗传感器都需要在标准气体下标定，这在家庭场景不现实。所以我会在代码里把映射系数做成可调的，配合按键调节的阈值，达到"相对准确"够用的水平。
DHT11的读取时序稍微有点讲究：主机先拉低总线至少18毫秒发起起始信号，然后释放总线，DHT11响应后输出40位数据——8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。每一位的波形是通过高低电平持续时间来区分的，所以读取时要做到微秒级的时序控制。我建议用定时器来做延时，别用简单的软件延时循环，因为编译器优化等级变了，延时时间就变了，很容易导致DHT11读不出来。
4.3 数码管动态扫描与显示逻辑
数码管显示用动态扫描：4位数码管的段选线（a到g、dp）并联在一起接到MCU的GPIO上，位选线分别由4个引脚控制。显示时每次只点亮一位，通过快速切换（通常每位数停留1到2毫秒）让视觉上形成"四位数同时亮"的效果。如果扫描速度太慢，会看到明显的闪烁；太快则没有必要，因为人眼已经分辨不出来了。
代码里我用的是查表法：定义一个数组，下标对应要显示的数字，数组里存储的是该数字对应的段码。比如数字0的共阴极段码是0x3F，数字1是0x06，这些是标准值，直接从网上能找到。但要注意，你的原理图上段选线和位选线接到GPIO的哪个引脚，段码表就要做对应调整。这也是很多新手"代码跟教程一模一样但显示乱码"的根本原因。
显示逻辑上，正常状态显示当前的燃气浓度值，单位是"%"或"PPM"由你自己定义。进入阈值设置模式后，显示当前的报警阈值，并且当前可调的位会闪烁提示。闪烁效果就是每隔一定周期把显示关闭几十毫秒再打开，利用人眼余晖形成闪动。实现上不需要额外硬件，软件里加一个标志位就行。
4.4 报警判断状态机
报警逻辑我写成了一个简单状态机，有三种状态：正常、预警、报警。
正常状态下，燃气浓度低于报警阈值的80%，系统只做显示和检测；预警状态，浓度超过阈值的80%但还没到报警值，数码管上的数字开始闪烁，提示"快接近危险值了"；报警状态，浓度超过阈值，启动蜂鸣器间断鸣叫、LED快闪、继电器动作。其中继电器动作后要维持吸合状态，直到浓度降到阈值的60%以下才释放——这是为了防止用户在浓度临界区来回波动时，继电器频繁吸合释放，把电磁阀和排风扇都搞坏。这个回差设计很重要，很多初学者不做，实测中就会遇到"蜂鸣器响一下就停一下，一直反复"的尴尬情况。
另外，报警状态应该是"锁存"的，也就是说一旦触发报警，无论浓度怎么变化，都必须由用户按键确认后才能解除。这是安防系统的常规要求，防止真出事了系统自己"冷静"下来。解除按键我设计的是长按设置键3秒以上才有效，在代码里通过按键计时来判断，短按只是切换显示模式。
DHT11的温湿度数据在报警逻辑中不直接参与控制，但会显示在数码管上，按一下切换键可以在"浓度/温度/湿度"三种显示模式之间切换。考虑到湿度和燃气传感器的交叉敏感特性，后续版本我打算把湿度补偿加进去，目前版本预留了扩展点。
5. 仿真搭建与联调过程
5.1 Proteus仿真环境的准备要点
Proteus里自带了STM32F103C8T6的模型，这是直接用仿真而不是买实物板卡验证的前提。新建工程后，从元件库里拉出STM32F103C8T6、MQ-2的仿真模型（如果库版本老，可以拉MQ-5或者用可调电阻模拟气体传感器输出）、7段数码管、按键、蜂鸣器、LED、继电器等元件。
这里有个关键坑：Proteus里默认的STM32模型需要烧录hex文件才能运行，而源码的编译要借助Keil或IAR，生成hex后再加载到Proteus的MCU模型里。很多人卡在"Proteus仿真STM32没反应"，十有八九是没把hex文件加载进去，只画了电路没给芯片写程序。
MQ-2在Proteus里的行为模型是一个电压源，浓度变化通过滑动变阻器模拟。调试时我用一个电位器接到MCU的ADC引脚，转动电位器就等于改变气体浓度，非常直观。这句操作背后的逻辑是：仿真环境下我们关注的是软件逻辑的正确性，传感器的"电学行为"完全可以用电位器等效替代，因为对MCU来说，它看到的只是一个0到3.3V之间变化的电压信号。
5.2 仿真联调过程中的调试实录
第一次仿真跑起来，我的数码管显示一直是乱码。排查过程：先检查段码表——发现我用的段码是共阴极，但原理图里画的是共阳极数码管，段码全部取反，改过来后显示正常。这个问题在实物调试中同样会遇到，所以我在代码里专门加了一个宏定义COMMON_ANODE，一键切换段码极性。
第二个问题是ADC读数一直满量程4095。在仿真里用探针测PA1引脚的电压，发现电位器中间抽头确实输出3.3V，但ADC配置的通道和引脚不对应。我代码里初始化的是ADC1的通道1，但引脚初始化的却是PA0，引脚和通道不匹配，导致读到的是悬空引脚的浮空电压。把引脚改成PA1后用示波器观察，ADC读数恢复正常。
第三个问题最有代表性：继电器吸合瞬间，数码管数字跳变，ADC数值波动。仿真环境下还能隐约看出是电磁干扰问题。解决办法就是我前面提到的：软件上在继电器动作后加一个50毫秒的"电子屏蔽时间"，暂停ADC采样和显示刷新。这个方案在实物上也验证过，简单有效，不用改硬件就能把干扰降低到不影响系统判断的程度。
5.3 仿真与实物的差异：别依赖仿真一锤定音
仿真能验证80%的逻辑正确性，但剩下20%的真实情况是仿真永远模拟不出来的。比如传感器的个体差异，仿真里电压和浓度是理想线性关系；实物里每个传感器都不同，有老化、温漂、预热漂移这些问题。仿真里继电器动作是"瞬间完成"的，实物里有吸合时间、有电弧干扰、有机械噪声，这会影响系统的时序。
所以我习惯的流程是：先用Proteus把算法和逻辑跑通，再花小半天把实物搭起来，烧录同样的hex文件，用万用表测关键节点电压，用SCope观察ADC波形，对比仿真和实测的差异。这套流程能帮你快速定位"问题出在硬件还是软件"——如果仿真正常但实物不正常，大概率是硬件电路的问题；如果仿真就不正常，那就是代码逻辑的问题。
6. 常见问题与排查技巧实录
6.1 系统上电后无反应
先别怀疑单片机坏了，按照从电源到芯片、从芯片到软件的排查顺序来。用万用表测3.3V电源是否正常——AMS1117的输出端有没有电压；确认晶振是否起振——用示波器探头测8MHz晶振两脚，或者用万用表交流档量一下有没有几十毫伏的压差；检查RESET引脚电压是否被拉低——如果BOOT引脚配置错误，芯片会进入ISP模式而不是运行Flash里的程序；确认hex文件是否成功烧录——DAPLink下载时看提示信息是否报"Flash Download failed"；最后检查芯片型号选择是否正确，F103C8T6的Flash大小是64KB，如果你在Keil里选成了C6T6，Flash是32KB，程序超界会导致下载时校验失败。
6.2 数码管显示亮度不均匀或闪烁
这个问题往往不是硬件故障，而是扫描时序问题。检查主循环里是否被某个长延时阻塞了，如果ADC采样或DHT11读取用了阻塞式延时，数码管扫描就会"卡顿"，表现出来就是一个隔一个数字忽亮忽暗。解决办法是确保显示刷新在定时中断或主循环的极短周期里执行，不要在显示流程里做任何超过1毫秒的等待。另外位选切换时先关掉所有位选再更新段码，最后再打开对应位选，否则会出现"拖影"现象——上位数字残影混进下一位。
6.3 ADC采样值跳动过大
先测电源：用示波器看3.3V纹波，如果纹波超过100mV，大概率是滤波电容不够，或者在电池供电下电压被继电器大电流拉低。再看参考电压：STM32的ADC参考电压是VREF+，这个引脚通常直接内部连到VDDA，如果你的板子上VDDA没接好滤波电容，ADC结果会非常差。再检查软件：采样后有没有做滤波处理，我建议至少做一次递推平均或者中值滤波。最后一招是在代码里把ADC采样周期和继电器/蜂鸣器的动作时序错开，用标志位实现"继电器动作时不采样"，这个技巧在实操中解决了大量"看着像是ADC问题，其实是电源干扰"的情况。
6.4 DHT11读数偶发失败
DHT11是单总线协议，时序要求严格。先看延时函数：同一个延时函数在-O0和-O2编译优化级别下的实际延时时间可能差好几倍，我建议用示波器抓一下起始信号的波形，确认低电平时间在18到30毫秒范围内。再看总线电阻：DHT11的数据线需要一个4.7K到10K的上拉电阻到VCC，如果省了这颗电阻，通信会时好时坏。最后是读取间隔：DHT11的读取周期建议大于1秒，读太频繁会导致传感器内部状态机混乱，返回的数据全都是"1"。
6.5 烧录时提示连接不上
SWD接口烧录不上，先确认接线：SWDIO、SWCLK、GND三条线是否一一对应，有些核心板的丝印顺序和你想的不一样。检查目标板是否供电——DAPLink的SWD接口虽然能输出3.3V，但电流很小，如果芯片本身功耗大，会导致供电不足，连接失败。还有一个高频坑：如果PA13和PA14被程序意外配置成了复用功能，SWD接口就可能被占用，芯片变"砖头"。解决办法是按住复位键，点击下载的瞬间松开复位键，利用芯片刚上电、程序还没来得及运行的小窗口把程序烧进去。这个方法实测有效，胜率九成以上。
7. 这套系统还能怎么改：从"能用"到"好用"的扩展方向
基于这套开源方案继续往下走，有几个方向我个人觉得性价比很高。
第一个方向是加联网能力。把主控换成ESP8266或者ESP32，或者保留STM32通过串口接一个ESP8266模块，就能把浓度和温湿度上传到本地局域网，手机浏览器或者微信小程序直接查看。这样一来，哪怕人在外面也能知道家里燃气有没有异常。相比于直接买现成智能报警器，自己做的好处是数据完全本地化，不会担心平台停服或者隐私问题。
第二个方向是增加联动设备的种类。目前继电器只控制了一个回路，你可以扩展成两路、三路，一路控制电磁阀、一路控制排风扇、一路控制声光报警器。硬件上多加几个继电器模块就行，软件上在继电器控制函数里加几个GPIO操作。
第三个方向是把误报率再压一压。现在的报警判断只依赖浓度阈值和回差，升级方案可以做"浓度变化趋势判断"：如果燃气浓度在短时间内快速上升，说明是正在泄漏，立刻报警；如果浓度是缓慢波动，可能是温度和湿度变化引起的伪信号，适当放宽报警条件。这种基于变化率的判断算法在工业设备里很常见，拿到这个项目里也是一个很有意思的进阶课题。加一个SHT30之类的数字温湿度传感器，把温度补偿做进去，也可以改善MQ系列传感器受温湿度影响大的问题。
最后补一句工欲善其事相关的经验：调试STM32这种裸机程序，示波器和逻辑分析仪是两大神器。逻辑分析仪几十块钱的就可以，拿来抓DHT11时序、抓数码管扫描波形、排查串口数据，比靠猜高效太多。这个项目走到最后你会发现，真正花时间的不是编译通过，而是把那些时序问题和干扰问题一个一个揪出来。这些坑踩一遍，比看十遍教程都长记性。
