很多人一看到“STM32 环境监测”这种组合第一反应往往是又一套毕业设计。但这次我开源这套TSMaster环境的项目并不是为了凑一个“能演示”的DEMO而是想把从需求分析、原理图设计、代码编写到Proteus仿真的完整链路都放在一起让你拿过去就能真正跑通、能改、能落地。这套系统的主控是STM32F103C8T6虽然是小容量、低成本的经典芯片但做图书馆这类室内监测场景性能和资源都绰绰有余。整包内容包含完整可编译的Keil工程、PDF版本原理图、Proteus仿真文件以及一份可直接烧录的Hex文件严格来说属于“代码原理图仿真”三件套全开源。这套东西适合谁如果你正在做嵌入式相关课程设计或者准备参加电子设计竞赛想找一个稳定的基础框架又或者就是单纯想看看一个真实项目如何把传感器采集、数据处理、阈值报警和显示交互整合到一颗MCU上都可以直接参考。接下来的内容我会把整个项目的设计思路、硬件细节、代码架构、仿真调试过程以及我调试时踩过的坑全部摊开来讲你可以把它当成一份带注释的实战笔记来读。1. 需求拆解与整体方案选型1.1 图书馆环境监测到底在监测什么在做任何硬件项目之前先别急着打开数据手册或者建工程先把需求问清楚。图书馆环境监测核心目标有两个一是保障藏书安全二是提升读者舒适度。从这两个目标出发需要采集的参数其实非常明确温湿度纸张对温湿度极其敏感温度过高会加速纸张老化发脆湿度过大会导致霉变、书页粘连湿度过低又会变脆。一般图书馆要求温度在18℃-24℃相对湿度在45%~60%之间。光照强度强光尤其是紫外线会加速纸张褪色所以图书馆阅览区光照需要在合适区间库房等藏书区域则要避免长时间强光直射。光照传感器除了用于报警也可以用来控制灯光照明。烟雾/可燃气体浓度这是消防安全的底线。图书馆是人员密集场所纸质书又多一旦发生火情早期烟雾检测能争取宝贵的疏散时间。MQ-2这种传感器虽然精度不如专业烟感但作为环境监测演示和低成本预警方案非常合适。当这三个维度数据都拿到之后系统就可以完成几件事实时显示当前环境数据超阈值时声光报警并预留串口或无线接口把数据上传到上位机。我自己做的时候还加了一个按键交互可以切换显示界面、调整报警阈值这让整个系统更像一个“产品”而不是一个“裸板”。1.2 主控芯片选型和传感器搭配主控选择STM32F103C8T6也就是俗称的“C8T6”或“蓝丸核心板”的芯片。选择它是因为第一Cortex-M3内核72MHz主频Flash 64KBRAM 20KB做传感器采集、数据显示和逻辑判断完全够用第二它自带多路ADC、I2C、USART、定时器不需要外扩芯片第三资料多、成本低、Proteus里面也有现成的仿真模型非常适合做开源项目。传感器选型上我推荐这样一套组合DHT11温湿度单总线数字传感器虽然精度一般温度±2℃湿度±5%RH但通信协议简单代码写起来很容易理解非常适合学习。如果对精度有要求可以换SHT30I2C接口精度高一个量级驱动替换起来也方便代码里我已经预留了接口抽象层。BH1750光照强度I2C接口数字传感器量程0~65535 lx正好覆盖室内光照场景使用的时候不需要校准直接读寄存器就行。MQ-2烟雾/可燃气体模拟输出输出电压随气体浓度升高而升高。接STM32的ADC引脚即可通过公式换算成浓度百分比用于判断。这套方案成本很低核心板加传感器加屏幕总共几十块钱但功能完整度很高是典型的“花小钱办大事”的选型思路。1.3 为什么选择Proteus仿真先行很多人问过我同一个问题“有真板子为什么要做仿真”我的回答是仿真不是替代硬件而是在硬件到手之前先验证逻辑。Proteus最大的优势就是能模拟STM32运行加载Hex文件之后可以看LED亮灭、LCD显示、传感器输出的变化。尤其对于实验室资源紧张、或者初学者焊接能力还不强的情况仿真能把绝大部分逻辑错误、引脚配置错误提前暴露掉。不过我必须提醒一点Proteus里的传感器模型和真实传感器行为差距较大比如DHT11模型不会有真实器件的时序抖动MQ-2模型响应也太理想。所以正确的开发流程是先在Proteus里调通整个逻辑框架再移植到真实硬件上做传感器校准和参数微调。这也就是为什么开源包里我会把仿真文件和原理图、代码放在一起它们各有用途谁也替代不了谁。2. 硬件原理图设计与关键电路解析2.1 最小系统晶振、复位、Boot引脚STM32F103C8T6的最小系统设计网上铺天盖地但真正自己画板子时还是有几个细节容易忽略。首先是晶振电路8MHz主晶振需要配两个负载电容典型值取20pF计算公式是CL(C1*C2)/(C1C2)Cstray其中Cstray是芯片引脚和PCB走线的寄生电容大约3~5pF所以C1、C2取20pF时实际负载电容约15pF左右正好落在STM32数据手册建议的10~20pF范围内。其次复位电路NRST引脚接10kΩ上拉电阻到3.3V再接一个100nF电容到地这样既能保证复位引脚常态高电平也能滤除高频干扰。最后Boot引脚BOOT0要接10kΩ下拉电阻到地确保从Flash启动BOOT1可以悬空或者下拉没有严格要求。把最小系统画对之后MCU才能稳定跑起来。这部分原理图开源文件里都有但我在PDF版本上用红色框把关键器件和参数标了出来方便大家直接对照。2.2 传感器接入电路的设计细节DHT11的数据引脚是开漏输出所以必须接一个4.7kΩ上拉电阻到VCC这个电阻不能省略否则通信时序会完全乱掉。BH1750是标准的I2C设备地址固定为0x23ADDR引脚接低电平SDA和SCL同样需要上拉电阻一般取4.7kΩ~10kΩ都可以我习惯用4.7kΩ。MQ-2模块需要特别注意供电。它的加热丝需要5V供电而信号输出和ADC共地之后可以直接接到STM32的ADC引脚。但MQ-2上电之后有大约30秒到1分钟的预热期这段时间输出电压会漂移代码里要做个初始化延时不然上电瞬间就误报警了。信号输出端我加了一个100nF滤波电容能有效抑制加热丝的纹波干扰。在ADC采集方面MQ-2输出接到PA0ADC1通道0由于STM32的ADC是12位分辨率参考电压3.3V所以电压对应关系是ADC值/4096*3.3V。如果接的是MQ-2模块而非裸传感器模块上一般已经集成好比较器可以输出数字信号但为了浓度监测我们还是用模拟输出。2.3 显示、按键与报警电路显示部分我用的是I2C接口的OLED屏幕0.96寸SSD1306驱动只需要四根线VCC、GND、SCL、SDA。对比LCD1602OLED不需要背光功耗低显示信息量也更大还能显示中文。如果你手头只有LCD1602也可以用代码里的LCD驱动替代不过建议新学的人直接上OLED接线简单调试起来省心。按键电路我设计了三个KEY1用于切换显示页面KEY2用于增加阈值KEY3用于减少阈值。按键一端接GPIO另一端接地GPIO内部使能上拉所以平时读到高电平按下时读到低电平。为了避免按键抖动导致误触发代码里做了10ms的软件消抖。报警电路部分我用了一个有源蜂鸣器接NPN三极管S8050驱动。STM32的GPIO驱动能力有限直接驱动蜂鸣器电流不够所以用PB0引脚输出高电平控制三极管导通蜂鸣器接在VCC和集电极之间。注意有源蜂鸣器自带振荡源只要通电就会响所以控制逻辑是在超过阈值时把PB0拉高即可。2.4 预留接口与扩展设计开源原理图里我还预留了三个扩展接口一个USART1的TTL串口PA9、PA10可以用来接ESP8266模块把数据通过WiFi传到服务器一个SWD调试接口PA13、PA14相比JTAG只需要两根线刷程序更方便一组5V和3.3V电源输出排针方便后续外接其他模块。这里要提一个实际工程中容易踩的坑STM32F103的PA13、PA14、PA15、PB3、PB4在芯片复位之后默认是JTAG调试功能如果你把这些引脚当作普通GPIO用必须在代码里先关闭JTAG只保留SWD。我这次项目里没有用这几个引脚做普通IO所以没有遇到冲突但如果你自己扩展要注意先用__HAL_AFIO_REMAP_SWJ_NOJTAG()禁用JTAG否则引脚高低电平会异常。3. 软件架构与核心代码实现3.1 代码整体架构前后台调度一目了然很多初学者写STM32程序喜欢把所有东西堆在while循环里程序一大就乱。这套项目的代码我用的是简单的前后台调度结构后台就是while(1)大循环前台是定时器中断。核心思想是所有传感器采集和数据显示都放在主循环里顺序执行而定时器中断只负责维护一个时间标志比如10ms、100ms、500ms的时基主循环通过查询这些标志决定是否执行相应任务。这样设计的好处是逻辑清晰、易读易改而且对于这个项目的数据量来说完全够用不需要上RTOS。如果你以后要扩展成多任务复杂系统再考虑FreeRTOS也不迟。我见过很多人在小项目里强行上RTOS结果任务同步和优先级反而把自己搞晕了没必要。主循环的核心伪代码如下while (1) { if (flag_100ms) { // 每100ms采集一次烟雾浓度 smoke_value MQ2_Read(); flag_100ms 0; } if (flag_500ms) { // 每500ms采集一次温湿度 DHT11_Read(temp, humi); flag_500ms 0; } if (flag_200ms) { // 每200ms采集一次光照 light_value BH1750_Read(); flag_200ms 0; } // 刷新显示与报警判断 Display_Update(); Alarm_Check(); Key_Scan(); }3.2 底层驱动DHT11、BH1750与MQ-2DHT11的驱动是这个项目里最考验时序的地方。它是单总线协议主机发起起始信号后DHT11响应并输出40位数据湿度整数、湿度小数、温度整数、温度小数、校验和。每一位的0或1由高电平持续时间决定26~28μs表示070μs表示1。因此读取代码需要使用微秒级延时我这里用的是SysTick做的delay_us()实测在72MHz主频下精度足够。核心读取函数如下uint8_t DHT11_ReadData(uint8_t *temp, uint8_t *humi) { uint8_t buf[5] {0}; uint8_t i, j; GPIO_SetPin(DHT11_GPIO, GPIO_PIN_RESET); // 拉低至少18ms发送起始信号 delay_ms(20); GPIO_SetPin(DHT11_GPIO, GPIO_PIN_HIGH); delay_us(30); // 拉高30us后释放总线 // 等待DHT11拉低响应信号 if (GPIO_ReadPin(DHT11_GPIO) 1) return 1; // 无响应 while (GPIO_ReadPin(DHT11_GPIO) 0); // 等待响应结束 while (GPIO_ReadPin(DHT11_GPIO) 1); // 等待DHT11拉高 for (j 0; j 5; j) { for (i 0; i 8; i) { while (GPIO_ReadPin(DHT11_GPIO) 0); // 等待每一位起始的低电平结束 delay_us(40); // 延时40us后判断电平 if (GPIO_ReadPin(DHT11_GPIO) 1) { buf[j] | (0x80 i); // 高电平时间较长判为1 while (GPIO_ReadPin(DHT11_GPIO) 1); // 等待高电平结束 } } } // 校验前四个字节之和的低8位等于校验字节 if ((buf[0] buf[1] buf[2] buf[3]) buf[4]) { *humi buf[0]; *temp buf[2]; return 0; } return 2; // 校验失败 }BH1750的驱动相比之下就简单很多。它是标准的I2C从设备支持连续测量模式和单次测量模式。初始化时发送Power On命令0x01然后发送连续高分辨率模式命令0x10之后每次读取2字节光强数据换算规则是光照值 (寄存器值) / 1.2单位是lx。这里我用的是STM32的硬件I2C外设很多人说STM32的硬件I2C不稳定其实在F1系列上只要初始化正确、处理好错误标志稳定性没问题而且用硬件I2C比软件模拟I2C省CPU。MQ-2读取就更直接了用ADC1通道0采集通过公式换算成电压值再根据传感器手册的灵敏度特性曲线近似换算成浓度。不过说实话MQ-2这种半导体传感器的绝对精度很有限我更看重它的相对变化趋势。代码里我把原始ADC值、电压值都通过串口打印出来方便标定阈值。3.3 业务逻辑阈值判断、报警与按键交互报警逻辑我设计了三档阈值对应三种严重程度一级预警温度超过26℃或者湿度低于40%RHOLED显示“注意”提示蜂鸣器间断鸣叫响500ms停500ms。二级报警温度超过30℃湿度低于30%RH或者烟雾浓度超过设定阈值蜂鸣器连续鸣叫OLED背景颜色翻转提示黑底白字变白底黑字。一级加严烟雾浓度超过2倍设定阈值蜂鸣器急促鸣叫同时串口每秒输出一次“DANGER”信息方便连接上位机做联动。阈值初始化是写死在代码里的但你通过KEY2和KEY3按键可以在±20%范围内调整调整后的值保存到结构体变量里掉电不保存。如果你要求掉电保存可以扩展使用STM32内部的Flash模拟EEPROM把阈值参数写进最后几页Flash空间代码框架我已经注释了位置需要的可以自己补充。按键扫描我放在主循环里每10ms检测一次。为了防止长按和抖动问题逻辑是做“检测到按键按下且松开”才产生一次有效操作这样调节阈值时每次只加减一个步进体验很像计算器按键。3.4 显示界面与状态管理显示界面我分了三页第一页同时显示温度、湿度、光照三个数值一目了然。第二页显示烟雾浓度和报警状态。第三页显示当前阈值设置方便现场调整。每次按KEY1就切换一页三页循环。这里我用了一个简单的page_index变量控制显示状态配合OLED的局部刷新能力。OLED的SSD1306驱动芯片我封装了底层像素操作函数上层可以灵活绘制字符串、数字、矩形框。有一点要提醒OLED的刷新率不高如果每帧都全屏清空重绘会出现明显闪烁。我的做法是把页面分成上下两个区域上半区固定显示标题下半区只刷新变化的数据区域实测显示非常稳定长时间运行也没有残影问题。4. Proteus仿真搭建与联调实录4.1 仿真工程创建和元件查找Proteus仿真STM32的步骤和真实板子开发不太一样你需要先在Proteus里放置STM32F103C8T6的模型、传感器模型、OLED显示模型然后加载Keil生成的Hex文件。具体流程新建Proteus工程在元件库搜索STM32F103C8T6并放置。搜索DHT11、BH1750、MQ-2如果Proteus版本里缺少这些模型可以用信号发生器替代模拟电压变化。搜索OLED或者使用LM016LLCD1602作为替代显示。我开源包里的仿真工程用的是OLED的Proteus模型如果你本地版本打不开提示缺少模型可以换成LCD1602模型代码里需要对应改调用的显示函数。把晶振电路、复位电路、电源网络补上和真实原理图保持一致。元件找齐之后连线就基本和原理图一致了。注意STM32模型的电源引脚默认已经接好不需要你额外画VDD/GND但传感器的电源网络必须自己连接。4.2 加载Hex文件和仿真调试在Proteus里双击STM32芯片在Program File一栏选择Keil编译生成的Hex文件然后点击运行。如果一切顺利OLED会按代码逻辑开始刷新数据此时你用鼠标拖动传感器模型的模拟值OLED上的数据会跟随变化报警阈值到达时蜂鸣器模型也会响电脑会播放提示音。我在仿真联调过程中遇到一个特别典型的问题DHT11在Proteus里读取一直是0。排查了很长时间发现是因为Proteus的DHT11模型对GPIO方向切换的时序要求比真实器件严格而我的代码在初始化时GPIO模式配置成了开漏输出Proteus模型对开漏模式模拟不完全。解决办法是在起始信号发送完毕后把GPIO临时切换为浮空输入模式等读取完数据再切回来。这个细节在真实硬件上可能无所谓但在仿真环境必须改代码里我也做了宏开关处理方便你在“仿真模式”和“硬件模式”之间切换。4.3 仿真和实物的差异对照仿真跑通之后千万不要直接认为实物就没问题。我整理了几个差异点方便大家建立预期时序差异仿真环境没有真实的电气噪声和寄生电容DHT11时序在仿真里跑得很干净但实物在长线上读数可能偶发超时代码里我加了重试机制最多重试3次。器件特性真实的MQ-2响应时间需要数十秒仿真模型一般几毫秒就稳定了所以仿真的报警阈值标定值不能直接用于实物。OLED显示Proteus的OLED模型刷新很快而实物使用I2C通讯如果代码里刷新频率太高可能因为I2C速率限制导致画面撕裂。我的代码默认显示刷新间隔200ms实测实物显示流畅。所以我的建议是仿真用于验证逻辑实物用于参数标定两者结合起来才能做出真正稳定可靠的东西。5. 常见问题与排查技巧实录5.1 编译与下载问题速查表很多刚接触STM32的朋友卡在第一步就是Keil工程编译不过或者下载失败。我把这套项目里最容易出现的几个问题整理成表格现象原因解决办法编译报错core_cm3.h文件找不到Keil没有安装对应芯片的Device Pack在Keil的Pack Installer里安装STM32F1系列DFP包下载程序时提示No target connected调试器驱动未装好或接线错误检查SWD四根线SWDIO、SWCLK、GND、3V3是否接对安装ST-Link驱动下载后程序不运行BOOT0引脚电平不对确认BOOT0接低电平从主Flash启动OLED只有背光无字符I2C地址错误确认BH1750和OLED的I2C地址代码中可分别配置蜜蜂器一直响阈值设置不合理或传感器数据异常串口打印传感器原始值排查是数据源问题还是逻辑问题5.2 传感器读数异常的排查思路传感器数据不对是嵌入式项目里最磨人的问题。这里分享一个我常用的排查套路先从源头查起再一级一级往后查。比如DHT11读到的湿度一直是99%或者温度一直是0我先用示波器/逻辑分析仪看数据引脚波形确认DHT11有没有正确响应。没有示波器的话就在代码里加串口打印打印读取过程中的状态标志位比如是否超时、校验是否通过。这套项目里面我专门加了一段调试用的串口输出代码你把#define DEBUG_ENABLE 1打开程序就会把每次DHT11读取状态打印出来非常方便。BH1750读数异常也按类似思路排查先读I2C设备地址是否正确再读寄存器的原始值。如果原始值一直不变检查是不是初始化命令没有执行成功如果原始值乱跳大概率是接线问题或者电源纹波过大。MQ-2的ADC读数异常最常见的问题是参考电压不稳。如果开发板上的3.3V和5V来自同一个USB口供电负载变化时电压会波动导致ADC读数漂移。解决办法是在ADC采样引脚加100nF电容滤波软件上做多次采样取平均代码里默认采20次去掉最大最小再取平均。5.3 Proteus仿真打不开或运行卡死Proteus的版本兼容性问题非常常见。如果你打开我提供的仿真文件提示“This project was created with a newer version”说明当前Proteus版本过低。解决办法是升级到Proteus 8.9或更高版本。如果运行时点击播放键后芯片不跑双击芯片检查Program File路径是否正确另外Proteus仿真STM32需要把芯片的VSS和VDD引脚网络名称和电源端子对应好电源网络命名不匹配也会导致芯片不工作。仿真运行卡死通常是因为代码里出现了死循环。比如DHT11读取函数在等待GPIO变化时如果仿真模型的时序和代码不兼容会一直卡在while循环里出不来。我在DHT11驱动里加了超时退出机制超过200μs就放弃本次读取这样即使在仿真环境也能正常跳出来不至于整个程序“假死”。5.4 一条重要经验阈值不要拍脑袋定最后分享一个我实际工作中体会最深的事报警阈值永远不要靠直觉随便设定。不管是用在图书馆还是其他室内场景都要先采集一段时间的实际环境数据画出曲线之后再来定阈值。我在这套软件里加了一个类似“数据采集模式”的调试入口——按住KEY1超过2秒系统会进入数据记录模式OLED循环显示三组传感器数据同时串口以CSV格式输出你可以用任意串口助手抓数据存成Excel。连续跑上24小时看看环境数据的波动范围再把这个范围加上适当的余量设置为报警阈值这样的系统才是真正好用的系统。6. 开源资料包内容说明与使用指南6.1 开源包目录结构解读整个开源资料包的目录结构我做了清晰的划分拿到手不会一头雾水Library-Environment-Monitor/ ├── 1_Documentation/ │ ├── 原理图_Rev1.0.pdf │ ├── 器件清单_BOM.xlsx │ └── 项目说明文档.md ├── 2_Code/ │ ├── MDK-ARM/ # Keil工程文件 │ ├── Core/ # 主程序与中断 │ ├── Drivers/ # HAL库文件 │ └── user/ # 用户代码传感器驱动逻辑层等 ├── 3_Simulation/ │ └── library_env_monitor.pdsprj # Proteus仿真工程 ├── 4_Hex/ │ └── library_env_monitor.hex # 可直接烧录的固件 └── README.md这样的结构我自己用起来很顺手文档归文档代码归代码仿真和固件各占一个文件夹找东西不需要到处翻。如果你要把这个项目放在Gitee或者GitHub上开源给大家用建议保留同样的目录风格虽然简单但胜在清晰别人按图索骥就能跑起来减少到手就问“怎么编译”“怎么打开”的情况。6.2 如何快速跑起来5分钟上手如果你是第一次拿到这套工程按照下面顺序操作基本5分钟内就能看到效果安装Keil MDK5并确保已经安装STM32F1系列器件支持包。打开2_Code/MDK-ARM/下的工程文件点击编译确保0 Error。在工程配置Debug选项里选择你手头的调试器ST-Link、J-Link或DAP-Link连接开发板后下载程序。如果连不上开发板直接使用4_Hex/下的hex文件用FlyMcu等工具通过串口ISP方式烧录也可以跑起来不需要额外调试器。接好DHT11、BH1750、MQ-2模块和OLED屏幕按原理图对应引脚连接上电即可看到数据。你可能会问为什么要既支持调试器下载又支持串口ISP因为我考虑到有的同学手头只有一块最便宜的STM32核心板和一根USB转TTL没有ST-Link。串口ISP可以利用芯片内部Bootloader烧录程序虽然每次烧录都需要手动设置BOOT0电平但胜在不需要额外设备。6.3 扩展方向这套系统还能变成什么做完这套基础系统之后如果你想让项目继续深入我建议优先考虑下面几个方向联网化利用USART1接ESP8266或者ESP32把数据上传到云端或局域网服务器做成真正的物联网系统手机端也能实时查看。多节点组网多个监测节点通过RS485总线或者LoRa通信连接到汇聚节点再统一上传到服务器适合整栋图书馆的多楼层覆盖需求。数据存储与分析在STM32上外挂SD卡模块定时存储监测数据再配合Python脚本做数据分析可以生成温湿度变化曲线。低功耗化把MCU切换到Sleep模式用RTC定时唤醒采集数据电池供电可以撑很久适合书架角落这种不方便拉电源线的位置。这些扩展方向并不是空谈代码架构上我都预留了位置。比如USART1的串口重定向已经写好了你只需要把ESP8266的驱动文件添加进去在main.c里面初始化并调用即可。硬件方面预留接口的排针也引到了板边扩展模块直接用杜邦线连接就行不用重新画板。写在后面的几点体会这套图书馆环境监测系统对我个人而言最大的收获不是代码跑通了、仿真通过了而是让我把一套真实产品开发流程完整走了一遍从需求分析、器件选型、原理图设计、PCB规划、软件架构、代码实现到仿真验证每一步都有明确的输出产物。很多初学者上来就急着写代码代码写完了再想硬件怎么配这样容易返工。正确顺序一定是先把需求想清楚把原理图确定好引脚分配规划好再动手写代码这样整体进度反而更快。另外我在做这个项目时还有一个很具体的体会开源不是为了把文件丢出去就完事而是要让别人能够顺畅地使用、复制、修改。所以我特别注重代码注释、原理图标注和文档说明光是项目说明文档我就写了将近两千字把每个引脚的连接、每路传感器出来的信号类型、每个模块的供电要求都写清楚了。还是那句话你今天在文档里多写一句明天可能就给使用者省下一下午的排查时间。如果你在复现这套系统的过程中遇到问题欢迎把报错信息截图或者日志发出来大家一起交流。这种软硬件结合的项目往往一个人的知识盲区正是另一个人的擅长领域。希望这套代码、原理图和仿真文件能成为你嵌入式路上的一个有效起点。