仓库里放了大半年的粮食，夏天一到，内部温度能蹿到四十多度，湿度一高，霉菌和虫卵比人还先醒过来。我见过不少粮仓管理的人，靠的还是老式温湿度计加人工巡检，晚上根本顾不上。这套STM32粮仓环境安防监测系统，就是把温度、湿度、烟雾、火光、非法入侵这五类最常见的风险一次性管起来，传感器采集、单片机判断、现场报警、通风排险全自动跑完，而且代码、原理图、仿真工程全部开源，硬件成本压到几十块钱。如果你是嵌入式入门者、电子类在校生，或者正好要交一份软硬结合的课程设计/毕业设计，这个项目就是那种“小而完整”的样板——传感器怎么接、信号怎么读、报警怎么联动、仿真怎么搭，一条链路清清楚楚。
这套系统我前前后后改了三版，踩过不少坑，比如DHT11时序读不出来、Proteus里OLED死活不亮、继电器一吸合单片机就复位，都是实际调试中会撞上的问题。接下来的内容我把设计思路、原理图要点、代码逻辑、仿真验证和问题排查全部拆开讲，尽量做到你拿着文章能从头跟到尾。
1. 项目整体解析：粮仓为什么需要一套自动安防监测系统
1.1 监测需求拆解：温湿度、火情、盗窃是三大痛点
粮仓环境最怕什么？第一是霉变。粮食吸湿以后，温度一高，霉菌繁殖速度会指数级上升，整仓粮食可能就报废了。这里的关键指标就是环境温度和相对湿度，温度超过28℃、湿度超过65%RH就是危险区间。第二是火灾。粮仓里粉尘浓度高，加上电气线路老化，一旦起火蔓延非常快，所以烟雾和明火都要盯着。第三是防盗。粮仓大多在郊外，夜间无人值守，入侵检测就很重要。
对应的传感器选型很明确：DHT11负责温湿度，MQ-2烟雾传感器负责烟雾浓度，火焰传感器负责明火检测，HC-SR501人体红外模块负责入侵报警。这四种传感器都是嵌入式领域最常见、最便宜的型号，而且输出接口友好——DHT11是单总线数字输出，MQ-2可以输出模拟量也可以输出数字量，火焰传感器和人体红外模块直接输出高低电平，STM32处理起来都不费劲。
1.2 为什么是STM32F103C8T6：性能、外设、价格三者权衡
主控芯片我选了STM32F103C8T6，也就是大家常说的“C8T6”核心板。这颗芯片是Cortex-M3内核，主频72MHz，Flash 64KB，SRAM 20KB，价格在十来块钱左右。从外设角度看，它内部有ADC、USART、I2C、SPI、定时器，还有足够多的GPIO，这个项目里我用到的外设它全覆盖，甚至还有很大的富余。
有同学可能会问，用STC89C52或Arduino Uno行不行？也能跑，但这套系统用STM32有三个更合理的理由：第一，DHT11的单总线时序对GPIO翻转速度有要求，51单片机用软件模拟勉强能行，但时序紧张容易出错；第二，OLED显示屏用硬件I2C驱动，STM32的I2C速度比51模拟I2C稳定得多；第三，如果你后面想扩展Wi-Fi模块、把数据传到云平台，C8T6的资源完全扛得住，而51基本就到顶了。从学习价值看，STM32是目前国内嵌入式岗位的主流MCU，从这个项目入门，后面找工作也受益。
1.3 系统架构：从传感器、主控到执行的完整链路
整个系统的数据流是这样的：传感器采集环境信息，输出电信号或数字信号给STM32；单片机通过ADC或GPIO读取数据，经过阈值判断后，把结果显示在OLED屏上，同时通过串口打印到上位机；一旦检测到任何一项指标超出预设阈值，系统立刻驱动有源蜂鸣器报警、点亮对应LED指示灯，并控制一个继电器去启动排风扇或报警灯。
这样的架构就是典型的“感知层—控制层—执行层”三层结构，也是工业监控系统的迷你版。做这个项目最大的收获不是把代码跑通，而是建立一种思维——任何监测系统，本质上都是先定义“什么情况是异常”，再决定“异常之后要做什么”。这套系统的阈值是用按键可以现场调节的，所以实际部署的时候不需要重新编译固件，非常灵活。
2. 原理图设计要点：从最小系统到传感器接口的完整链路
2.1 最小系统电路：3.3V供电、复位、晶振、下载接口
STM32F103C8T6是3.3V供电的芯片，但市面上多数传感器模块和继电器模块是5V供电，所以电源部分必须同时输出5V和3.3V。我的做法是：外部用USB或者DC电源输入5V，经过AMS1117-3.3V稳压器降压，得到3.3V给MCU供电。AMS1117的输入和输出端都要加上10μF和100nF的滤波电容，靠近引脚放置，这个细节能有效避免电源纹波导致单片机意外复位。
复位电路用的是经典的10kΩ上拉电阻加100nF电容到地，低电平复位。晶振电路用8MHz无源晶振加两个22pF负载电容，这是STM32F103的标准配置。下载调试接口用SWD，只需要SWDIO、SWCLK、GND三根线，比JTAG省引脚，四线连上就能用ST-Link下载调试。
注意：STM32F103C8T6的BOOT0引脚必须通过10kΩ电阻下拉到地，否则上电后会进入系统存储器模式，程序跑不起来。很多新手第一次画板子，BOOT0悬空或者直接接高电平，症状就是下载正常但复位后程序不执行。
2.2 按键输入与LED输出：去抖电路和驱动能力
系统设置了三个按键：设置键、加键、减键。按键输入电路最简单有效的做法是“外部上拉+对地按键”，按下拉低，松开发高。这里要注意，虽然STM32内部可以开启上拉电阻，但我还是习惯在外部加10kΩ上拉，因为内部上拉阻值偏大（约30kΩ~50kΩ），抗干扰能力弱，在有继电器、电机这种大功率器件的系统里容易误触发。
LED指示灯直接串联一个330Ω限流电阻接在GPIO和3.3V之间。STM32的GPIO输出电流虽然可以达到20mA，但整片芯片的灌电流总和有限制，所以指示灯控制逻辑我用的是“引脚低电平点亮”——灌电流方式比拉电流更稳，这也是硬件设计里的一个常用习惯。如果你要用高电平点亮，记得把限流电阻调大一些，比如1kΩ，降低总电流压力。
2.3 传感器接口设计：DHT11上拉、MQ-2输出、继电器隔离
DHT11的数据引脚是开漏输出，必须外接一个4.7kΩ或10kΩ的上拉电阻到3.3V，否则时序读不出来。传感器供电可以直接接3.3V，但要注意DHT11量程和精度有限——温度精度±2℃，湿度精度±5%RH，而且采样周期要大于1秒，连续读取会失败。这是传感器本身的限制，代码设计时要兜住。
MQ-2烟雾传感器比较特别，它内部有加热丝，传感器模块上有一个电位器可以调节灵敏度。模块有AO和DO两个输出：AO是模拟电压输出，DO是数字输出。我用了AO接STM32的ADC，这样可以读取更细致的烟雾浓度变化，阈值在软件里灵活设置，不用反复拧电位器。不过要考虑的坑是：MQ-2的加热电流比较大（约150mA），5V供电要稳，别让它在同一路3.3V上工作。
继电器控制排风扇时，不能直接用GPIO驱动继电器线圈，因为线圈需要的电流远超过GPIO输出能力，而且继电器断开瞬间会产生反向感应电动势，可能打坏单片机。正确做法是使用三极管或ULN2003驱动，并且在继电器线圈两端反向并联一个1N4007续流二极管。一旦续流二极管没加，继电器反复通断可能导致单片机死机，这是非常典型的教训。
3. 代码实现：工程结构与核心逻辑逐段拆解
3.1 工程结构：标准外设库还是HAL库？模块怎么划分
代码我基于标准外设库（StdPeriph Library）编写，因为这套老库资料多、网上教程多，对理解寄存器操作也更有帮助。当然用STM32CubeMX+HAL库也能实现同样功能，关键是工程内部的模块划分要清晰。整个工程分成以下几个模块：主程序main.c负责初始化与主循环调度；dht11.c负责单总线时序读写；mq2.c负责ADC采集和滤波；oled.c负责屏幕显示；key.c负责按键扫描与消抖；buzzer.c和relay.c负责报警输出与控制执行；usart.c提供串口打印调试信息。
每一个驱动模块单独形成一个.c/.h文件，模块之间尽量不互相依赖，只暴露必要的接口函数。比如DHT11_ReadData(uint8_t *temp, uint8_t *humi)返回温湿度数据，主循环只关心这个函数返回值是成功还是失败，不关心DHT11内部时序怎么折腾。这种分层思想在以后做更复杂的项目时会非常受用。
3.2 DHT11单总线时序：最容易翻车的地方，代码逐行注释
DHT11的通信协议是所有传感器里最“锻炼人”的，因为它不是标准I2C或SPI，而是完全靠GPIO的电平翻转和对微秒级时间的精确控制来通信。主机先拉低数据线至少18ms产生起始信号，然后释放总线，等待DHT11响应。DHT11会先拉低80μs再拉高80μs，然后开始发送40位数据。
我贴一下读取DHT11数据的核心代码片段，可以对照自己的实现检查：
uint8_t DHT11_ReadData(uint8_t *temp, uint8_t *humi) { uint8_t buf[5] = {0}; uint8_t i, j; /* 主机拉低总线，起始信号 */ DHT11_GPIO_Mode_OUT(); DHT11_DQ_LOW(); Delay_Ms(20); // 至少18ms DHT11_DQ_HIGH(); Delay_Us(30); // 释放总线 DHT11_GPIO_Mode_IN(); // 切换为输入模式 /* 检测响应信号 */ if (DHT11_DQ_READ() == 0) { while (DHT11_DQ_READ() == 0); // 等待80μs低电平结束 while (DHT11_DQ_READ() == 1); // 等待80μs高电平结束 /* 读取40位数据 */ for (j = 0; j < 5; j++) { for (i = 0; i < 8; i++) { while (DHT11_DQ_READ() == 0); // 等待50μs低电平结束 Delay_Us(35); // 在35μs处采样 buf[j] <<= 1; if (DHT11_DQ_READ() == 1) // 如果仍是高电平，说明bit=1 buf[j] |= 1; while (DHT11_DQ_READ() == 1); // 等待剩余高电平结束 } } /* 校验和：前4字节之和等于第5字节 */ if ((uint8_t)(buf[0] + buf[1] + buf[2] + buf[3]) == buf[4]) { *humi = buf[0]; *temp = buf[1]; return 1; // 读取成功 } } return 0; // 读取失败 }这段代码最关键的技巧在于“35μs处采样”判断bit0/bit1。DHT11的数据位是这样的：每一位总是以50μs低电平开始，然后高电平的长度决定是0还是1，bit0的高电平约26~28μs，bit1的高电平约70μs。所以在低电平结束后延时35μs再去读引脚，如果读到高电平，基本可以断定是bit1；如果还是低电平，那就是bit0。这里延时精度很重要，如果系统的Delay_Us是用普通循环实现的，要先校准一下，别在优化等级不同的编译器上差异太大。
3.3 ADC读取MQ-2：平均值滤波与阈值判断
MQ-2的AO引脚接在STM32的PA1上，对应ADC1的通道1。STM32的ADC是12位分辨率，读取范围是0~4095。因为MQ-2输出的模拟量会有噪声，我做了最简单的平均值滤波：连续采样8次，去掉最大值和最小值，取剩余6次的平均值。这样处理之后数据稳定性明显提升，不会因为偶发的尖峰误报。
配置ADC的代码是固定的套路：开启GPIOA和ADC1时钟，配置PA1为模拟输入，配置ADC1的分频系数为6（即12MHz，因为APB2时钟是72MHz，12MHz是ADC最稳定的工作频率），设置采样时间为239.5个周期，然后校准ADC。采样周期设置长一点对精度有好处，代价是转换速度慢一些，但监测系统本来就不需要高速采样。
烟雾的报警逻辑不是简单地和固定阈值比较，而是用了“阈值+持续确认”策略。只有当烟雾浓度连续5次（即大约5秒）都超过阈值才触发报警，这个设计能有效避免炒菜油烟或粉尘偶然飘过导致的误报。
3.4 主循环：轮询调度、按键阈值调节、显示刷新
主循环就是一个大while(1)，里面按固定节奏做几件事。因为项目是低速监测应用，不需要上RTOS，轮询就够了。我给每个周期定义了一个节奏：主循环每20ms扫描一次按键，每500ms读取一次DHT11，每200ms读取一次ADC，每500ms刷新一次OLED。这些节奏可以通过简单的计数变量配合Delay_Ms(10)实现，不需要定时器中断。
按键调节阈值的逻辑是：短按设置键进入设置模式，OLED屏幕上闪烁显示当前要调节的参数名，按加键或减键修改数值，再按设置键切换到下一个参数，四个参数都调完后退出设置模式。为了不破坏主循环结构，我用了一个简单的状态变量menu_state标记当前处于哪个界面。注意在按键扫描时要加上至少15ms的消抖时间，我是在检测到按键按下后延时15ms再确认电平，确认有效才执行操作。实测这个消抖方案比单纯用延时去抖要稳定，而且不会让按键显得“黏”。
另外我把系统状态用串口实时打印出来，格式类似[INFO] Temp=25.1C Humi=58% Smoke=320 Alarm=1。串口打印在调试阶段能省下大量时间，程序每跑一个分支，串口都有日志输出，不用猜程序走到哪里去了。
4. 仿真环境搭建：Proteus仿真流程与验证细节
4.1 仿真器件加载与电路搭建
很多同学拿到的所谓“仿真”就是一张电路截图，但我提供的仿真工程是可以在Proteus里直接跑的。Proteus 8.9以上版本支持STM32F103C8T6，搜索STM32F103C8T6就能找到芯片。DHT11在Proteus元件库里的名称就是DHT11，LCD可以选LM016L（LCD1602模型），如果库里有OLED模型（比如UG-2864HSWEG01）可以直接用，没有的话可以用LCD1602代替显示，逻辑验证一样有效。
Proteus里布局电路时，建议严格按照原理图对应关系连线。有人习惯随手把线拖得很乱，后面仿真出问题排查起来特别痛苦。我自己的经验是：先把芯片放中间，左边放传感器、按键输入，右边放显示、继电器输出，上下分别是电源和地。仿真里继电器的线圈一端接5V，另一端通过NPN三极管接到STM32的GPIO，三极管发射极接地，继电器触点连接一个灯泡模拟排风扇，续流二极管照样画上。仿真虽然不关心续流二极管会不会烧芯片，但保持和真实电路一致，才能验证原理图的正确性。
4.2 编译、烧录与仿真运行
代码在Keil MDK里编写编译，注意Target选项里芯片型号选STM32F103C8，然后把输出设置成生成HEX文件（勾选“Create HEX File”）。在Proteus里双击STM32芯片，在Program File里加载刚才生成的HEX文件，设置晶振为8MHz，点击运行。
仿真里常用的调试手段是串口窗口——Proteus的Virtual Terminal可以接在STM32的USART1的TX和RX引脚上，直接看到串口打印信息。如果你把波特率设置成115200，而Virtual Terminal的显示乱码，先检查波特率是否匹配。DHT11模型在仿真里是可以工作的，它会在你给它设置的温度和湿度范围内产生数据；传感器面板直接拖动滑条就能模拟外接的烟雾浓度变化，不用真的烧烟去测试。
4.3 仿真和实物必须清楚的差异
仿真能验证逻辑，但替代不了实物，这点必须提前说清楚。Proteus里的DHT11模型是理想化的时序，它在响应主机信号时非常“守时”，但真实DHT11的时序会受供电电压、温度、器件个体差异影响。我以前发现一个情况：代码在仿真里读DHT11数据全部正常，但烧到实物上读出来的数据偶尔是0xFF或校验失败，最后定位到是总线没有加外部上拉电阻，仿真里内部上拉就够，实物必须加4.7kΩ外部上拉。
OLED在仿真和实物的差异也很大。很多Proteus版本里的OLED模型模拟不了真实的SSD1306驱动方式，会出现画面不刷新或花屏。遇到这种情况，稳妥的方案是仿真里先用LCD1602代替OLED，验证完逻辑后，在实物上换成OLED。这不算偏离项目，因为核心逻辑没有变，只是显示介质不同。
5. 常见问题排查与避坑实录
5.1 高发问题速查表
我在调试这个项目的过程中遇到过不少问题，有些是传感器本身的坑，有些是设计上没考虑到的。整理一个速查表，方便以后参考。
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 程序下载失败/识别不了芯片 | ST-Link驱动问题、接线错误、BOOT0电平不对 | 检查SWD三根线是否短接，BOOT0是否接地，重新插拔ST-Link，查看设备管理器驱动 |
| 上电后程序不运行 | BOOT0悬空/接高、供电电压不足 | 确保BOOT0通过10kΩ下拉到地，3.3V电压稳定在3.3V±5% |
| DHT11读不到数据或校验失败 | 上拉电阻缺失、时序延时不准、供电不稳 | 加4.7kΩ上拉，校准微秒延时，DHT11供电接3.3V，采样间隔不小于1秒 |
| 屏幕无显示或花屏 | I2C地址不对、接线错误、屏幕供电不足 | OLED地址一般0x3C或0x3D，在代码里切换地址宏，检查SDA/SCL是否接错 |
| 烟雾传感器读数跳动大 | MQ-2供电噪声大、ADC无滤波 | 加平均值滤波，MQ-2独立5V供电，电容滤波 |
| 继电器动作时单片机复位 | 无续流二极管、电源容量不足 | 线圈并联1N4007，拉大电源输出电流，加100μF电解电容 |
| 按键触发不灵敏/乱跳 | 未消抖、外部上拉缺失 | 软件加15ms消抖，外部加10kΩ上拉 |
5.2 调试技巧与规避思路
模块化调试是我反复强调的一点。整个系统不要一次性全部接上电调试，而是分模块验证：先烧一个最小程序点灯，确认GPIO和下载链路没问题；再单独调DHT11，把数据打到串口看；然后调OLED显示；最后再合并报警和继电器逻辑。我见过太多人把整个系统接好，一上电哪里都是问题，根本没法定位。每个模块单独验证通过了，再组合，排查范围一下子就缩小了。
还有一种情况是ADC通道配置错误，比如PA1对应的通道号写错，导致读出来的数值是垃圾数据。STM32F103C8T6的ADC1通道1对应PA1，通道2对应PA2，通道3对应PA3，通道4对应PA4。如果发现读出的ADC值始终是0或4095，先查引脚和通道是否对应，再查GPIO是否配置成了模拟输入。ADC读数的零点检查也很有用——不接烟雾传感器时读值应该接近0，如果漂得很高，大概率是引脚悬空导致噪声耦合。
自定义阈值参数建议写死在Flash的一个结构体里，上电的时候从Flash读取，如果没有有效的标志位再用默认值。这样用户调节过的阈值在断电后不会丢失。当然，这个项目里按键调完阈值直接存在全局变量里也行，但每次上电都要重新调，挺麻烦的。用STM32内部Flash保存参数是一个进阶功能，也符合“粮仓环境安防监测系统”这类实际部署项目的基本需求。
最后再分享一个排查问题最有用的方法：用最小复现法。比如火焰传感器误报，我一开始以为是代码阈值问题，从主程序里把火焰检测功能单独抽出来，写成一个独立的测试程序，只读一个GPIO，发现传感器模块在不接上拉电阻的情况下，输出引脚电平是随机跳变的。这才定位到是模块自身输出问题，加上拉后就解决了。很多人碰到问题喜欢在完整程序里加打印、试来试去，那样效率很低，不如把可疑模块抠出来单独测，五分钟就能得出结论。
