作为常年折腾STM32的老嵌入式我见过太多“能跑但没法看”的项目也见过一大堆只丢源码不丢原理图的东西。这次开源的是一个我实际搭过的图书馆环境监测系统代码、原理图、仿真一次性给齐正好适合做课设、毕设或者单纯想练手传感器融合和低功耗控制的朋友。这套系统能实时采集温度、湿度、光照和烟雾浓度在OLED上滚动显示超阈值就触发声光报警还能自动启动风扇通风。整个方案围绕STM32F103C8T6展开成本不高逻辑清晰Proteus仿真也完全能跑起来不用买板子就能先把程序调通。我梳理一下这套系统的完整设计过程从硬件选型到电路拆解再一步步讲代码怎么写、仿真怎么搭最后把我实际调试时踩过的坑列出来。内容会比较细适合边看边抄但每个环节我都会解释为什么这么做省得你只会抄不会改。1. 系统设计与架构思路先想清楚要监测什么、怎么控制做环境监测系统最容易犯的错就是一上来就堆传感器。先别急着画板子要把整个系统“需要感知什么、需要响应什么、用户怎么看数据”这三件事理清楚。图书馆场景有一个很典型的需求点藏书区怕潮湿、怕高温、怕阳光直射而且对烟雾和火灾极其敏感所以环境参数必须实时可见、异常情况必须马上有人知道。1.1 监测参数与硬件选型思路我的做法是先列参数再对着参数选型。这套系统最终圈定四个核心参数温度、湿度、光照强度、烟雾浓度。参数传感器选型选型理由输出形式温度/湿度DHT11单总线协议、接线简单、库成熟课设毕设常用单总线数字信号光照强度光敏电阻模块带比较器输出模拟量或数字开关量接ADC能读连续光照变化模拟电压量烟雾浓度MQ-2灵敏度高、响应快、对烟雾和可燃气体都敏感模拟电压量状态显示OLED SSD1306 0.96寸I2C接口省IO显示内容丰富I2C数字信号为什么主控选STM32F103C8T6而不是51或者Arduino一方面是因为这枚芯片性价比确实高价格几块钱内置64KB Flash和20KB RAM跑这种多传感器任务完全足够。另一方面STM32的ADC采集精度、定时器资源、中断响应能力明显比51强而且生态成熟Proteus仿真库里也直接支持这个型号后面调试会省很多事。如果换成Arduino最难受的是仿真环境和Keil工程不统一代码还要重新适配反而不划算。1.2 控制逻辑设计系统不能只采集数据还要有“决策层”。我的控制逻辑分成三层。第一层是实时显示层主循环定期刷新OLED把温度、湿度、光照值、烟雾电压值同时显示在屏幕上保证现场人员能直观看到当前状态。第二层是阈值判断层温度超过设定值例如28°C或者烟雾电压超过阈值例如1.5V系统立刻驱动蜂鸣器报警并点亮对应的LED指示灯。第三层是联动执行层当温度或烟雾超标时系统通过继电器自动打开风扇进行通风降温等参数回落到安全区间以下再关闭风扇形成一个基本的闭环控制。在设计这个逻辑的时候有个关键点必须提前定好阈值判断放在主循环里做还是放在中断里做我的方案是放在主循环里做原因很简单DHT11本身是慢速传感器每次读取至少要几十毫秒ADC采集也需要稳定时间这些操作就不适合塞进中断。中断只用来处理按键和报警状态锁存尽最大可能保证主循环逻辑清晰、好调试。1.3 为什么选择“代码原理图仿真”三件套一起开源我见过很多开源项目只给代码不给硬件图。结果就是读者拿到代码不知道往哪块板上烧连线全靠猜遇到问题也很难定位是硬件还是软件。这次我把三样东西一次性打包原理图用Altium Designer画的仿真用Proteus 8 Professional搭的代码是在Keil MDK里写的标准外设库工程。三样东西配套使用你可以在电脑上先跑仿真验证算法再按原理图打板或者面包板搭电路最后把同一份hex烧进去就能跑。更重要的是这套项目非常适合作“二次开发框架”。你想加一个按键去手动切换显示页面或者改成用ESP8266上报数据到云平台都可以在这个基础上改硬件预留了串口和GPIO引脚代码的逻辑分层也留了接口不用推翻重来。2. 原理图拆解从STM32最小系统到传感器接口电路原理图是整个硬件项目的根。这个项目里我画原理图的时候没有搞一堆花哨功能全套电路就六个部分最小系统、电源电路、传感器接口、显示电路、报警联动电路、调试接口。这几个部分之间存在明确的信号流向传感器负责感知环境参数把模拟量或数字量送给STM32STM32经过判断后把结果显示在OLED上同时按需触发蜂鸣器和继电器。2.1 最小系统与电源电路STM32F103C8T6的最小系统大家都熟但我还是要重点说几个容易翻车的细节。首先是去耦电容每个电源引脚旁边必须就近放一个100nF陶瓷电容芯片底部如果有VDD和VDDA分开的引脚模拟电源部分还要额外加一个1uF电容这个细节直接决定ADC采集的稳定性。然后是复位电路我用的是一条典型RC复位10kΩ上拉电阻加100nF下拉电容NRST引脚接按键到地。这个复位电路看起来简单但只要电容值选错就会出现上电复位不彻底、程序跑飞的问题。晶振选择的是8MHz无源晶振两个20pF负载电容并联这组参数是芯片数据手册的标准接法。电源部分其实更重要。系统使用5V USB供电但STM32的工作电压是3.3V所以我用了一只AMS1117-3.3线性稳压芯片把5V降到3.3V。这里有个非常关键的教训AMS1117的输入和输出引脚都必须接10uF电解电容和100nF陶瓷电容组合进行滤波。如果只接一个电容当继电器吸合的瞬间电流波动会直接导致3.3V电压跌落到3.1V以下MCU就复位了。我一开始就是没在意这个结果总是莫名重启后来加了电容才稳。2.2 传感器接口电路设计DHT11的电路很简单DATA引脚直接接STM32的一个GPIO口外加上拉电阻到3.3V。因为DHT11用的是单总线协议空闲状态下数据线必须保持高电平上拉电阻我选了4.7kΩ这个值和官方手册推荐一致。另外DHT11的供电电压范围是3.3V到5.5V我直接给它供3.3V保证电平信号和STM32一致不需要额外做电平转换。这一点建议不要为了省事改成5V供电因为很多DHT11模块板载了电平转换还好说如果是裸传感器5V回灌到STM32的引脚就有风险了。光敏电阻模块我采用的是分压式接法光敏电阻和一个固定电阻串联成一分压电路分压点接STM32的PA1引脚做ADC采集。选型上我用的是10kΩ光敏电阻加10kΩ固定电阻这样在普通室内照度下分压点电压大约在1V到2.5V之间ADC采到的数值不至于太低也不会轻易满量程。如果你的使用场景光照变化范围很大可以换100kΩ固定电阻把采样灵敏度摊平这个需要实测调优。MQ-2模块输出的是模拟电压接在PA2引脚上。这里有个细节值得专门说MQ-2上电初期有一个大约一分钟的预热漂移过程电压会慢慢变化所以在程序里我做了开机延时和多次采样取平均值避免刚上电那段时间误报警。如果你想进一步扛干扰可以在ADC引脚前加一个100nF的RC低通滤波电容效果立竿见影。2.3 OLED显示、蜂鸣器与继电器电路OLED用的SSD1306是标准的I2C接口SCL和SDA分别接PB6和PB7这两个引脚是STM32F103的硬件I2C1引脚。这里注意硬件I2C在STM32上容易出一些配置复杂的问题所以我的代码里用的是GPIO模拟I2C这样你在Proteus里仿真的时候不会遇到I2C时序兼容性问题实际跑板的稳定性也能保证。地址引脚AO接地所以I2C地址是固定的0x787位地址0x3C。蜂鸣器电路我用的是三极管S8550驱动GPIO通过1kΩ限流电阻接到三极管基极蜂鸣器正极接5V负极接三极管的集电极。当GPIO输出高电平时三极管导通蜂鸣器鸣叫。刚开始我以为GPIO能直接驱动蜂鸣器结果实测电流不够声音小得跟蚊子叫似的加了三极管驱动之后音量完全不一样。继电器电路也用类似方案我用了一个5V继电器模块PC13控制输出端接风扇插座注意给继电器线圈并联一个1N4007续流二极管这个二极管必须反接否则继电器断电瞬间会产生反向电动势轻则干扰MCU重则烧掉驱动管。2.4 调试接口与设计规则最后是SWD调试接口20pin的JTAG太占地方我只留了4根线SWDIO、SWCLK、GND、3.3V。这四个引脚全部引到一个4pin排针上用ST-Link下载程序时可以直接对接很好用。我强烈建议哪怕你不是为了调试也要把这四个引脚引出来因为万一程序里的时钟配置错了芯片进入低功耗模式或者SWD引脚被复用成GPIO你还能用ST-Link的connect under reset功能挽救。原理图本身的绘制规则也是容易踩坑的地方。我给每个模块加了独立的网络标签在电源网络上加了电源符号并且用不同颜色区分信号线。这一套做法在你用Altium Designer生成PCB时会省大事而且别人拿到原理图也能很快看懂连线关系。整个板子的接插件全部选择2.54mm排针方便面包板验证和后期扩展。3. 代码实现标准外设库工程模块化拆解关键函数代码部分是最容易被别人拿去“直接抄”的但如果代码写成一坨抄的人会非常痛苦。这个项目的代码我按功能拆成了下面几个文件main.c负责主流程dht11.c负责DHT11传感器驱动adc.c负责ADC采集i2c_soft.c和oled.c负责屏幕显示alarm.c负责报警判断和继电器控制。每个文件里的函数尽量做到单一职责接口清晰。3.1 初始化与主循环流程整个程序的主流程可以概括为系统初始化、传感器数据读取、数据处理与显示、阈值判断与控制。先看一下main.c的核心结构。int main(void) { SystemInit(); delay_init(); OLED_Init(); ADC_Init(); DHT11_Init(); relay_Init(); buzzer_Init(); OLED_Clear(); OLED_ShowString(0, 0, Library Env Monitor); while (1) { DHT11_Read_Data(temperature, humidity); lightValue ADC_Read(CHANNEL_LIGHT); smokeValue ADC_Read(CHANNEL_SMOKE); Display_EnvInfo(temperature, humidity, lightValue, smokeValue); Alarm_Check(temperature, humidity, smokeValue); delay_ms(500); } }主循环的节奏是每秒跑两次。为什么不是越快越好因为DHT11的读取周期要求必须大于1秒其实它的数据手册建议两次读取间隔在1到2秒之间所以我把整个循环控制在500毫秒正好满足要求。ADC读取理论上可以很快但加上显示和判断之后500毫秒的周期已经足够了而且还能有效避免OLED频繁刷新导致的闪烁。我特别想提醒一点主循环的delay必须给足。如果你在主循环里刷屏刷得特别快OLED会持续占用I2C总线DHT11的时序又要求非常严格一旦被打断就会采集失败返回一个固定错误值。以前调试这个项目的时候我就因为循环周期太短DHT11经常返回0排查了很久才发现是时序冲突。3.2 DHT11单总线时序的几种坑DHT11的驱动是整套代码里最需要精细处理的模块内核就是单总线时序。你要严格读时序主机先拉低总线18ms以上然后释放并延时20~40us接着读取从机的响应信号然后连续读40位数据。每一位数据都是通过高电平的持续时间来区分的26~28us代表070us代表1。我用的是标准外设库带延时函数的方式实现没有用定时器输入捕获原因是为了保持代码在Proteus仿真中的兼容性仿真环境下定时器中断处理高频信号的稳定性不如延时函数直观。uint8_t DHT11_Read_Byte(void) { uint8_t i, byte 0; for (i 0; i 8; i) { while (DHT11_DATA_PIN() 0); // 等待低电平结束 delay_us(40); if (DHT11_DATA_PIN() 1) // 高电平超过40us表示1 { byte | (1 (7 - i)); while (DHT11_DATA_PIN() 1); // 等待高电平结束 } } return byte; }写这段代码的时候有一个特别容易踩的坑就是读每一位之前都必须在低电平起始处等待如果芯片主频变高或者优化等级变了40us的判断阈值就要跟着调整。我用的是72MHz的系统时钟配套的标准延时函数在Keil里O0编译下实测没有问题。如果你换到别的型号或者超频请务必拿示波器抓一下波形把40us稍微上下浮动看看能不能稳定解析。另外DHT11每次通信结束之后总线会释放并由上拉电阻拉高。程序里我用的是开漏输出加外部上拉DHT11_Init函数里配置引脚模式时要注意主机发送起始信号时必须把引脚切换为输出模式读取时再切换回输入模式。这个切换如果漏了要么发不出起始信号要么读不到数据。3.3 ADC采集与数据处理ADC部分负责采集光敏电阻和MQ-2模块的模拟电压。STM32F103的ADC是12位的参考电压接3.3V所以采集到的原始值范围是0到4095对应的电压是0到3.3V。我在代码里做的处理是连续采样8次去掉最大值和最小值再对剩余6次取平均。uint16_t ADC_Read(uint8_t channel) { uint16_t sum 0; uint8_t i; uint16_t buf[8]; for (i 0; i 8; i) { buf[i] ADC_GetValue(channel); delay_ms(2); } // 简单冒泡排序去最大最小 sort_buf(buf, 8); for (i 1; i 7; i) { sum buf[i]; } return sum / 6; }为什么要做均值滤波因为传感器本身的模拟输出不是稳定的特别是MQ-2它内部是一个加热电阻输出会带有周期性波动直接拿单次采样值做判断就会出现报警器一阵响一阵停的尴尬局面。8次采样取均值基本能把这种波动压掉同时不会增加太多延迟2ms的采样间隔对这两个传感器来说是足够的。还有一个和数值处理相关的细节MQ-2输出的是电压值但它的灵敏度曲线并不是线性的严格来说需要通过查表或者拟合公式才能得到ppm浓度。但在图书馆环境监测这个场景里我们其实更关心“有没有烟雾异常”而不是“确切浓度是多少”所以我直接把ADC电压值和一个经验阈值比较就够用了。阈值定在1.5V对应MQ-2在较浓烟雾环境下输出上升到1.5V以上。你要是想更精确可以接一个电位器调模块上的灵敏度旋钮让它在你认为合适的报警浓度点翻转。3.4 显示与报警联动逻辑OLED显示这部分我用的是0.96寸SSD1306128x64分辨率。因为是I2C模拟驱动显示函数比较直观先在缓冲区写好要显示的内容再一次性刷到屏幕上这样可以避免单字符刷新带来的闪烁。void Display_EnvInfo(uint8_t temp, uint8_t humi, uint16_t light, uint16_t smoke) { OLED_ClearBuffer(); OLED_ShowString(0, 0, Temp: ); OLED_ShowNum(40, 0, temp, 2); OLED_ShowChar(56, 0, C); OLED_ShowString(0, 2, Humi: ); OLED_ShowNum(40, 2, humi, 2); OLED_ShowString(0, 4, Light:); OLED_ShowNum(40, 4, light, 4); OLED_ShowString(0, 6, Smoke:); OLED_ShowNum(40, 6, smoke, 4); OLED_SendBuffer(); }显示的内容要刻意地把关键数字对齐放好方便巡检人员扫一眼就能读出数据。我排了四行每行显示一项数据数值后面直接跟单位这可比那种十几个变量挤在一行写的方式友好得多。报警联动函数放在alarm.c里逻辑其实不复杂但有几个细节值得注意。当烟雾电压超过1.5V或者温度超过28°C时蜂鸣器置高继电器吸合风扇开始转动当所有参数都回到安全区间后蜂鸣器和风扇自动关闭。这里注意我在蜂鸣器控制里加了一个20秒的持续报警时间防止短暂波动导致报警器反复启停。如果你想要更人性化的交互可以加一个按键去手动消音我预留了按键接口代码里也写了注释。4. Proteus仿真搭建从新建工程到流程跑通仿真这部分特别适合还没有买开发板的人或者想在打板之前先把程序逻辑调通的人。我用的是Proteus 8 Professional工程里已经把原理图元件放好位了你只需要把Keil编译生成的hex文件加载到STM32芯片里就能直接看效果。但如果你想自己从零搭一遍仿真我把过程也拆开了讲。4.1 创建工程与元件清单在Proteus里新建工程之后需要从元件库中找到这些元件STM32F103C8、DHT11、光敏电阻模块如果库里没有直接用电阻替代、MQ-2模块Proteus库里有MQ-2或MQ-6可用、OLED12864、蜂鸣器、LED灯、继电器、风扇等。如果你用的版本元件库不全可以用电位器替代模拟量传感器用电阻和开关组合模拟光照变化这个思路在调试中很实用。连线时注意几个地方STM32F103C8的VDD引脚全部接3.3VVSS接地模拟电源VDDA也接3.3VVSSA接地。BOOT0和BOOT1引脚要接下拉电阻到地否则芯片可能进不了Flash启动模式。晶振引脚OSC_IN和OSC_OUT上接8MHz晶振但Proteus仿真对晶振频率不太敏感只要不接错就行。DHT11的DATA引脚接PA0光敏电阻分压点接PA1MQ-2输出接PA2I2C的SCL和SDA分别接PB6和PB7蜂鸣器控制端接PB8继电器控制端接PC13。4.2 加载HEX文件与运行仿真连线完成之后双击STM32芯片在Program File一栏选择Keil工程里生成的hex文件把Crystal Frequency设置为8M然后点击运行。这时候OLED上应该会显示“Library Env Monitor”和实时数据。调整光敏电阻附近的亮度以及改变MQ-2的输入电压你会看到显示数据跟着变化把数值调到超过阈值以后蜂鸣器和风扇就会联动动作。这里有个很重要的经验Proteus里的DHT11模型行为并不完全和实物一致。有些版本的库里DHT11模型交互性比较差甚至只显示固定温湿度。遇到这种情况不要慌工程里我放了一个调试模式开关你可以用滑动变阻器去微调DHT11的模拟输出或者干脆先忽略DHT11的读数把注意力放在ADC、OLED和报警联动的验证上。实物调试时再用真实的DHT11传感器数据。4.3 仿真无法满足的环节和单片机选型仿真能帮我们验证绝大部分逻辑但不能完全替代实物。最明显的就是传感器的真实电气特性没办法完整体现比如MQ-2的预热过程、DHT11的实际温漂、继电器吸合时的电流冲击这些只有真实电路才能暴露出来。我在仿真中做了一版和实物代码完全一致的工程确保你烧录到实物时不需要改逻辑但调试时如果发现传感器数值有偏差请优先检查硬件连接和供电稳定性。至于仿真模型的选型其实Proteus中也支持STM32F401等型号但我不建议换因为F103C8的模型最成熟网上遇到的报错案例也最多出问题好搜答案。C8T6的Flash是64KB仿真工程加代码绰绰有余别为了参数好看去选大容量型号没必要。5. 调试过程中典型问题与排查思路这部分才是这套项目里真正值钱的内容。我把它在面包板和自打板上跑的过程中遇到的实际问题都列出来按现象、原因、解决路径整理成了一张速查表你后面但凡遇到类似问题能少走很多弯路。问题现象可能原因排查与解决程序烧录后OLED无显示I2C地址错误或SCL/SDA接反确认OLED地址是0x3C而不是0x3D检查SCL接PB6、SDA接PB7DHT11读数一直为0上拉电阻缺失或时序被打断确认4.7kΩ上拉主循环延时加强单独测试DHT11例程继电器吸合瞬间MCU复位电源被拉垮续流二极管缺失给5V供电加100uF电容线圈两端反接1N4007ADC采集值跳变剧烈参考电压不稳或者采样率太高加RC滤波电容多次采样取均值压降时检查电源蜂鸣器声音很小GPIO驱动能力不足改用三极管或MOS管驱动蜂鸣器仿真中OLED花屏I2C时序不兼容或刷新太快降低刷新频率到500ms一次检查模拟I2C延时设备正常但报警不触发阈值设置错误或传感器输出没到阈值用万用表或者串口打印判断ADC电压是否真超出阈值5.1 电源问题最隐蔽也最致命我在调试这个项目时遇到最多的故障根源都是电源。举个例子我最早用USB线直接给面包板供电整个系统静态电流不大但是每次继电器吸合的那一瞬间USB线压降很大MCU立刻复位。我加了续流二极管、给继电器独立供电都解决不了最后发现是USB线的线阻太大了换了一根粗线问题彻底消失。所以当你遇到“程序跑一会儿就重启”之类的问题不要只顾着看软件逻辑先把供电的线阻、电容布局都检查一遍。另一个和电源有关的坑是AMS1117压差问题。AMS1117的典型压差约为1V也就是输入电压至少要比输出高1V以上才能稳定输出3.3V。如果USB电压掉到4.2V3.3V输出就不稳定了。因此我建议供电采用5V/2A的适配器或充电头而不是依赖电脑USB口尤其是你要带风扇和OLED一起工作的时候。5.2 I2C和OLED时序的兼容问题OLED花屏这个问题在水群的时候被问了不下二十次。多数情况下不是代码逻辑错了而是刷新时序和I2C总线的信号被干扰了。SSD1306的驱动芯片对时序要求比较宽松但对I2C起始和停止条件的时序比较敏感如果你用的模拟I2C没有加足够的延时就容易出现花屏或者字符错位。我的代码里在每位时钟翻转时都加了一个2us左右的延时实际跑起来很稳。若要进一步提高稳定性可以把I2C速率控制在100kHz左右即标准模式很多模拟I2C花屏问题就是因为速率太高。还有一点要注意OLED的VCC和GND必须和STM32共地。有人可能会想着OLED单独用5V供电但I2C总线上拉电阻如果不小心接到5V那STM32的PB6、PB7引脚长时间会吃到高于VDD的电平时间长了有烧坏引脚的风险。所以我统一全部用3.3V供电这样最安全。5.3 多传感器优先级别让一路传感器拖垮整个系统在这个系统里DHT11的读取时序最严格ADC采集最频繁OLED刷新最耗时间。如果三者在主循环里没有顺序区分很容易出现某一个环节耗时过长而拖累其他环节。我的处理方式是把DHT11放在每次循环的最前面因为它有至少1秒间隔的硬性要求ADC放在DHT11之后因为ADC本身很快不需要抢占DHT11的时间OLED刷新放在显示数据更新之后并且在刷新过程中不启动新的传感器采样防止总线被占用导致时序错乱。如果你觉得主循环的执行顺序不够“优雅”可以考虑用定时器触发ADC的周期性采样DHT11单独用软件延时状态机去驱动OLED则放到低优先级任务里。但说实话以这个项目的规模主循环顺序执行完全足够了没必要引入状态机或者RTOS除非你想顺带练练嵌入式操作系统的应用那就另当别论。6. 实物调试与二次开发扩展方向按我个人的经验把仿真跑通之后最好还是拿一块真实的STM32F103C8T6蓝色药丸板子搭一次实物。实物的意义在于你能感受到传感器真实输出的波动、继电器吸合的声音、蜂鸣器报警的提醒效果这些都是仿真给不了的。实物接线可以完全照搬原理图我打样了一版PCB沉金工艺板子尺寸大概6cm x 8cm所有器件都是直插和贴片混合封装焊接难度不大有热风枪和电烙铁就能搞定。这个系统扩展空间其实很大。如果你想做远程监测只需要把串口空闲引脚接一个ESP8266模块然后用AT指令或者MQTT协议把温湿度数据上报到云平台如果你想加历史曲线可以把数据写到SD卡模块配合文件系统做离线记录如果你想做得更贴近“智慧图书馆”甚至可以加一个RFID门禁联动有人进入时自动调节照明亮度和通风强度。这些都是基于现有代码和原理图就能一步一步加出来的不用推翻重来。最后分享一个小技巧在你正式焊接PCB之前建议先拿洞洞板把全部模块搭一遍用杜邦线连好跑熟了所有功能再动手画板。这样做的好处不只是验证原理图有没有接错更重要的是你会在搭线的过程中对每个模块的“脾气”有更直观的感知比如哪个传感器加热发烫、哪根线容易被碰松、启动瞬间电流有多大。我后来画板时几乎所有改动都来自这个洞洞板阶段的教训而不是Datasheet。硬件这东西光看资料是记不住感觉的真的得摸一遍才知道怎么回事。