这次我们来看一个非常典型的 STM32 开源实战项目：家居环境监测系统。作者把源码和原理图都放出来了，项目编号 A166。对正在做课程设计、毕业设计，或者想快速搭一套“温湿度 + 光照 + 烟雾 + 显示报警”环境监测装置的人来说，这类开源项目的价值在于不用从零画板、不用到处拼驱动，拿到源码和原理图就可以直接跑通。
先说它最突出的几个点：第一，资料完整度高，源码能编译、原理图能照着画板；第二，硬件方案偏向主流低成本器件，不挑物料；第三，代码逻辑清晰，适合学习定时器、ADC、单总线协议、I2C 通信和嵌入式状态切换；第四，可以在此基础上扩展 WiFi 上云，做成真正的“远程家居环境监测”。本文会带你梳理硬件架构、原理图关键电路、开发环境搭建、源码编译烧录、功能验证方法，以及常见坑点。
内容比较长，建议先收藏。下面进入正题。
1. 项目能力速览
| 能力项 | 说明 |
|---|---|
| 项目类型 | STM32 嵌入式入门/进阶实战，环境监测类系统 |
| 开源内容 | 源码 + 原理图 |
| 主控芯片方向 | 基于 STM32F1 系列，常见为 STM32F103C8T6，具体型号以仓库原理图为准 |
| 主要功能 | 环境温湿度采集、光照检测、烟雾/可燃气体检测、本地显示、声光报警 |
| 典型传感器 | DHT11/DHT22 温湿度、光敏电阻或数字光强度传感器、MQ 系列气体传感器、OLED/LCD 显示屏 |
| 开发工具链 | Keil MDK、STM32CubeMX、ST-Link/串口烧录工具 |
| 硬件画图工具 | 常见使用嘉立创 EDA / Altium Designer，原理图可转 PDF 查看 |
| 是否跨平台开发 | 源码编译一般基于 Windows + Keil；Linux 下可通过 GCC 工具链，需自行适配 |
| 是否支持 API | 本项目属于嵌入式离线系统，不默认提供网络 API |
| 是否支持批量任务 | 支持多传感器循环采集；批量生产需自行处理器件校准 |
| 适合人群 | 嵌入式学习者、课程设计/毕设、环境监测产品原型验证 |
需要说明：不同版本的开源项目，具体引脚分配、传感器型号可能不同。下面所有分析都围绕“STM32 家居环境监测系统”的通用硬件框架展开，最终请以你实际下载到的源码和原理图为准。
2. 适用场景与使用边界
这个开源项目适合谁？一句话总结：适合想把“单片机理论”落到一块实际板子上的嵌入式开发者。
它最典型的用途是课程设计和毕业设计。很多高校的嵌入式课程要求做“环境监测系统”，如果自己从零画板，需要处理传感器驱动、PCB 设计、上位机等多个环节，工作量不小。有了开源源码和原理图，可以快速完成系统框架，再根据自己的需求替换传感器或显示方案。
它也能用于产品原型验证。比如你想做一个小型的仓库温湿度监测节点，或者实验室烟雾报警模块，这个项目的代码框架可以直接拿来做初期验证。先用 STM32F103 + DHT11 + MQ-2 跑通数据采集逻辑，验证完功能后再换更低成本的方案。
不适合什么场景？第一，不适合需要高精度数据的工业环境。DHT11 这类传感器精度有限，工业级温湿度监测需要 SHT30、SHT4x 或温湿度探头。第二，不适合需要大规模无线组网的生产系统。STM32F103 做本地采集没问题，但多节点低功耗组网需要选带 LoRa、NB-IoT、Zigbee 的芯片或者加无线模块。第三，不适合完全零基础的纯软件开发者。项目涉及原理图阅读、引脚配置、烧录和硬件接线，至少需要懂一点电路基础。
使用边界必须提醒：本项目只能用于合法授权的学习、实验和产品开发。如果你要采集的是他人场所的环境数据，需要获得明确授权；传感器模块本身的来源也要合规。如果你要给真实家庭做烟雾报警，不能只依赖单个 MQ 传感器，必须结合正规烟雾报警器和灭火装置，安全责任不能靠一个 MCU 实验项目承担。这是硬件项目最基本的合规意识。
3. 系统框架与硬件架构
绝大多数 STM32 家居环境监测系统，硬件框图都长这样：
- 主控 STM32F103C8T6：负责读取各传感器数据、逻辑判断、驱动显示和报警。
- 温湿度传感器 DHT11/DHT22：采集环境温度和相对湿度。
- 光照传感器：光敏电阻方案走 ADC 采集，数字方案多用 BH1750 走 I2C。
- 气体传感器 MQ-2/MQ-5：检测烟雾、可燃气体浓度，输出模拟电压或 TTL 电平。
- 显示模块：0.96 寸 OLED（I2C/SPI）或 LCD1602。
- 报警模块：有源蜂鸣器 + LED 指示灯。
- 输入模块：独立按键，用于切换显示页面、设置报警阈值。
- 电源模块：USB 5V 输入，经 LDO 转 3.3V 给 MCU 和外设供电。
- 调试接口：SWD 烧录口和串口日志输出。
从功能逻辑看，代码主体是一个“超级循环 + 定时采集 + 状态判断”的结构。主循环里不停刷新传感器数据，DHT11 需要遵守单总线时序，OLED 负责把温湿度、光照强度、烟雾浓度显示出来，如果任意一项超过阈值，蜂鸣器就会响。
如果带 WiFi 扩展模块，通常会在 STM32 上留一个 USART，用 AT 指令把数据发给 ESP8266/ESP01，再通过 MQTT/HTTP 上报到云平台，这就完成了一部分“物联网化”。不过基础开源版本不一定默认带 WiFi，需要根据仓库内容确认。
4. 核心电路原理解读
拿到原理图后，不要着急从头看到尾。STM32 系统原理图有固定的阅读顺序：先看电源，再看最小系统，然后一路看外设接口和传感器模块。
4.1 电源电路
家居环境监测系统常用的供电方式是 USB 5V 输入，板载 AMS1117-3.3 稳压到 3.3V。原理图上重点关注两个地方：输入端有没有防反接二极管，以及 3.3V 输出端有没有 10uF 和 100nF 去耦电容。
实际接线时，DHT11 和 OLED 都建议使用 3.3V 供电，不要直接接 5V，否则长期运行可能出现通信不稳定。如果板子同时带 5V 外设，则需要确认电平是否兼容。
4.2 STM32 最小系统
STM32F103C8T6 的最小系统包含四部分：
- 3.3V 供电。
- 8MHz 晶振作为 HSE 时钟源，两个 20pF 负载电容。
- NRST 复位电路，复位按键并联 100nF 电容到地。
- BOOT0 下拉到地，确保从 Flash 启动；BOOT1 一般也接地或悬空。
原理图上还能看到 SWD 调试接口，通常是 4 针：SWDIO、SWCLK、GND、3.3V。用 ST-Link 烧录时只需要接这四根线，比串口 ISP 烧录方便很多。
4.3 DHT11 温湿度电路
DHT11 是单总线传感器，DATA 引脚通常需要接一个 4.7kΩ 到 10kΩ 的上拉电阻到 3.3V。它只有一根数据线，时序要求比较严格，代码里一般会用延时函数模拟时序，或者用定时器输入捕获。
如果 DHT11 数据线和 MCU 引脚之间直接相连，没有问题；如果线长超过 20cm，建议缩短距离或换用 DHT22。原理图上 DHT11 一般会标注为 P1/P2 排针接口，方便插拔。
4.4 OLED 显示电路
0.96 寸 OLED 常见 I2C 接口，SDA 和 SCL 分别接 MCU 的 I2C 引脚。OLED 模块通常自带 10kΩ 上拉电阻，不需要额外加。重点是确认模块地址，绝大多数是 0x3C，如果地址不对，OLED 不显示或者显示雪花点。
4.5 光照采集电路
如果用光敏电阻方案，原理图上会是“光敏电阻 + 固定电阻”组成分压电路，中点接到 MCU 的 ADC 输入引脚。MCU 读取 ADC 值后，通过反推电压值换算出光照强弱。这类电路便宜，但精度不高，适合做“亮/暗”等级判断。
如果用 BH1750，它是 I2C 接口的数字光照传感器，直接输出 Lux 值，精度更好，代码也更简单，前提是引脚上不要和 OLED 的 I2C 冲突。
4.6 MQ 气体传感器电路
MQ-2/MQ-5 模块一般有 4 个引脚：VCC、GND、DO（数字输出）、AO（模拟输出）。AO 接 MCU 的 ADC 引脚，通过检测电压判断气体浓度。模块上电后需要预热，刚上电的前几十秒输出会漂移，不要在预热阶段直接做报警判断。
注意 MQ 系列传感器加热电流较大，如果直接用 STM32 的 3.3V 引脚供电，可能出现电压跌落和采集值波动。推荐做法是 5V 单独给 MQ 模块供电，并将 AO 输出电压限制在 3.3V 以内，再接入 MCU。很多模块自带比较器，输出就是 TTL 电平，可以直接给 GPIO。
5. 开发环境准备与工具链
做这个项目，至少需要准备以下软件和硬件：
| 类型 | 推荐工具 | 说明 |
|---|---|---|
| 集成开发环境 | Keil MDK5 | 编译 STM32 工程最常用 |
| 芯片初始化配置 | STM32CubeMX | 用来生成初始化代码，便于修改引脚 |
| 驱动安装 | ST-Link 驱动 / CH340 驱动 | ST-Link 烧录时需要；串口模块也需要 |
| 原理图查看 | Altium Designer / 嘉立创 EDA / PDF 阅读器 | 转 PDF 后查看更方便，不一定要装原软件 |
| 串口调试助手 | SSCOM / PuTTY / CuteCom | 查看日志输出，验证采集数据 |
| 烧录工具 | STM32 ST-LINK Utility / STM32CubeProgrammer | 烧录 hex/bin 到芯片 |
| 硬件 | ST-Link V2、杜邦线、面包板、USB 线 | 前期联调必备 |
操作系统的选择上，Windows 用户最顺。Keil MDK5 在 Windows 上安装简单，驱动兼容性好。Ubuntu 用户可以用 stlink-tools、openocd 和 arm-none-eabi-gcc 完成烧录，但前提是项目本身的工程文件能通过 CMake 或 Makefile 编译；很多开源仓库只提供 Keil 工程，Linux 下需要手动把源码加进构建系统。
硬件版本建议选 stm32f103c8t6 最小系统板，某宝上比较容易买到，引脚标注清晰，适合做开发验证。也可以直接用项目自己的 PCB，按原理图焊接元器件。
5.1 Keil 环境安装步骤
- 安装 Keil MDK5，安装路径不要带中文和空格。
- 安装 STM32F1 系列支持包，一般是 Keil.STM32F1xx_DFP。
- 把 ST-Link 驱动装好，插入 ST-Link 后设备管理器应能识别到。
- 打开项目工程文件，编译确认环境没问题。
如果你的板载调试器是 CMSIS-DAP，同样需要安装对应驱动。很多 STM32 最小系统板使用 DAP 下载器，接线方式依然是 SWDIO/SWCLK/GND/3V3。
5.2 检查引脚冲突
打开原理图后，把主控的所有外设引脚整理成一张表。以常见配置为例，可以把引脚规划成下面这样，注意这不是固定答案：
| 外设模块 | 信号 | 常见引脚 |
|---|---|---|
| DHT11 | DATA | PB0 或 PA1 |
| OLED I2C | SCL | PB6 |
| OLED I2C | SDA | PB7 |
| 光敏分压 | ADC_IN | PA0 |
| MQ 传感器 | ADC_IN | PA4 或 PA5 |
| 蜂鸣器 | GPIO_OUT | PA8 或 PB5 |
| 按键 | GPIO_IN | PB12/PB13/PB14 |
| 调试串口 | TX/RX | PA9/PA10 |
拿到开源代码后，不要直接改代码，先对照源码里的main.c、bsp_gpio.c或board_init.c，确认每个外设用的是哪个引脚。如果你自己接线的板子没有按作者画的原理图接线，就必须在代码里修正引脚定义。
6. 源码编译、烧录与运行方法
从仓库下载源码后，先看工程目录结构。STM32 工程常见的目录组织如下，如果仓库实际结构不同，按相同思路去找对应文件即可：
project_a166/ ├── Doc/ │ ├── 原理图.pdf │ └── 使用说明.pdf ├── Hardware/ │ ├── 原理图源文件 │ └── PCB 源文件 ├── Firmware/ │ ├── MDK-ARM/ │ │ └── Project.uvprojx │ ├── Core/ │ │ ├── Inc/ │ │ └── Src/ │ │ └── main.c │ ├── Drivers/ │ │ ├── CMSIS/ │ │ └── STM32F1xx_HAL_Driver/ │ ├── BSP/ │ │ ├── dht11.c │ │ ├── oled.c │ │ ├── bh1750.c │ │ └── mq_adc.c │ └── output/ └── README.md这里的BSP（Board Support Package）目录放的是板级驱动，比如 DHT11 的时序读取、OLED 的显示接口。很多开源作者会把传感器驱动集中放在这个目录下，阅读代码时优先看bsp下的文件就行。
6.1 Keil 编译流程
用 Keil 打开.uvprojx工程文件后，按下图顺序操作：
Project -> Build Target (F7)如果编译通过，会出现类似这样的输出：
"Project.axf" - 0 Error(s), 0 Warning(s)如果遇到头文件找不到的错误，检查 Keil 的 C/C++ Include Paths 是否正确。常见情况是工程目录移动后，原相对路径失效，需要重新添加：
# 在 Keil 中依次点击 Options for Target -> C/C++ -> Include Paths # 添加 Core/Inc、Drivers/CMSIS/Device/ST/STM32F1xx/Include、BSP 等目录如果遇到Error: L6218E: Undefined symbol xxx，说明某个源文件没有被加入工程。在项目管理器里把对应.c文件添加进去即可。
6.2 ST-Link 烧录
Keil 内直接烧录最方便。先配置调试器：
Options for Target -> Debug -> Use ST-Link Debugger Settings -> Flash Download -> Reset and Run然后点 Load 按钮。烧录成功会有提示。如果提示No Target connected，检查接线和设备管理器驱动。
如果不想用 Keil 内烧录，也可以在命令行里用 STM32CubeProgrammer：
# Windows 下进入 STM32CubeProgrammer 目录 STM32_Programmer_CLI.exe -c port=SWD mode=UR -w build/project.hex -v -rstLinux 下用 openocd 也可以：
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "program project.hex verify reset exit"6.3 上电验证
烧录完成后，接好传感器和 OLED，上电复位。正常现象是 OLED 背光亮起，屏幕上开始滚动显示温湿度、光照强度和烟雾浓度。如果 OLED 是空白，用万用表量一下 I2C 引脚是否有上拉；如果温度数据不正常，先检查 DHT11 数据线是否接对引脚，再确认代码里 GPIO 模式是不是开漏加上拉。
如果是 LCD1602 方案，上电后屏幕会先显示两行初始化信息，然后刷新数据。LCD1602 对比度调节电位器不建议省略，否则屏幕可能出现“只有背光没有字符”的现象。
7. 功能测试与效果验证
拿到一套开源环境监测系统源码，建议按下面的顺序做功能验证。不要一次把所有外设都接上，容易出问题。先烧录基础程序，再逐一验证每个模块。
7.1 串口日志验证
许多项目会在main.c里初始化一个调试串口，把传感器数据通过串口打印出来。连接串口模块时，STM32 的 TX 接串口模块的 RX，STM32 的 RX 接串口模块的 TX，GND 共地。
参考日志格式可能如下，具体以实际源码为准：
Temp: 25.3C Humidity: 56.2% Lux: 320 MQ ADC: 1024 Threshold Temp: 30.0C如果串口输出乱码，先检查波特率。常见设置是 115200 或 9600，代码里搜USART_BAUDRATE或huart.Init.BaudRate就能找到。如果波特率没问题，检查板载晶振频率是否和代码里配置一致。
7.2 DHT11 温湿度测试
DHT11 的单总线协议对时序敏感，测试时要关注两点：
第一，读取频率不能太高。官方数据手册建议两次读取间隔 1 秒以上，代码里如果死循环连续读，很容易出现校验失败。如果看到温度不变或者显示 0，先降低读取频率。
第二，用手捏住传感器，温度数值应该缓缓上升。如果数值跳变或者长时间为 0，大概率是 GPIO 初始化配置不对，把开漏改成推挽试试，或者检查上拉电阻。
判断成功标准：温度在环境温度附近波动，湿度在 30%~60% 之间，数值偶尔变化 1%RH，并且校验函数正常通过。
7.3 OLED 显示测试
上电后 OLED 如果正常，第一行显示标题，第二行以后显示实时数据。测试时可以用亮光照 OLED，观察光照数值变化；用手指遮住，数字应下降。I2C OLED 常见的失败原因是地址错误，0x3C 和 0x3D 容易搞混。
如果屏幕只亮无字，可以检查初始化时 OLED 的 I2C 速度是否太高。部分 SSD1306 对 400kHz I2C 兼容性差，把 I2C 时钟降到 200kHz 或 100kHz 再试。
7.4 气体传感器测试
测试 MQ 传感器时，不要用打火机直接对着传感器猛喷，容易造成传感器中毒。更稳妥的办法是用打火机气体在距离传感器 10cm 外短按释放，观察 ADC 值变化。注意实验室通风。
如果 AO 值没有变化，用万用表量模块 AO 引脚对地电压，看是否随气体浓度变化。如果电压正常说明模块没问题，问题在 MCU ADC 配置；如果电压不变，检查传感器加热线圈是否工作，也就是 VCC 引脚供电是否正常。
7.5 报警功能测试
在代码里把温度阈值临时改成比环境温度低 1℃ 的值，蜂鸣器应该响起，LED 点亮。测试完成后改回原来的阈值。如果蜂鸣器不响，检查蜂鸣器是有源还是无源。有源蜂鸣器给高低电平就会响，无源蜂鸣器需要输出一定频率的 PWM 才能发声。很多例程默认用有源蜂鸣器，如果买到无源蜂鸣器，就会“不响”。
这正好也是学习 STM32 TIM 定时器输出 PWM 的好场景。如果你手里的蜂鸣器是无源的，改造思路很简单：把驱动函数从HAL_GPIO_WritePin改成HAL_TIM_PWM_Start，输出 2kHz~4kHz 的频率。开源项目代码里往往已经有脉冲宽度控制的经验写法，可以沿用它。
8. 联网扩展与数据上报思路
基础版环境监测系统会止步于“本地显示”。很多人的需求是“手机上看数据”，这时候就涉及 WiFi 模块和云平台接入。如果你下载的源码里没有 WiFi 部分，可以按下面思路自己扩展，这也是 STM32 项目比较常见的进阶路径。
8.1 加一块 ESP8266/ESP01
在 STM32 上预留一个 USART 给 ESP8266。软件逻辑上，STM32 作为主机，通过串口发送 AT 指令控制 ESP8266 连接路由器，再连接 MQTT Broker 或云平台。
一个典型 AT 指令序列如下，方便测试模块：
AT AT+CWMODE=1 AT+CWJAP="your_wifi_ssid","your_password" AT+MQTTUSERCFG=0,1,"client_id","username","password",0,0,"" AT+MQTTCONN=0,"broker_ip",1883,0 AT+MQTTSUB=0,"device/command",0 AT+MQTTPUB=0,"device/data","{\"temp\":25.3,\"hum\":56}",0注意：ESP8266 AT 固件版本不同，指令细节会有差异。以模块厂商提供的固件文档为准。
8.2 上报数据格式
数据上报建议使用 JSON 格式，方便云端解析。下面的 JSON 片段可以作为设备模拟数据示例，并非仓库默认格式：
{ "device_id": "A166", "temp": 25.3, "hum": 56.2, "light": 320, "gas_level": 1, "alert": 0 }8.3 OneNet/阿里云/自建服务器
常见做法有三个方向：
- 接入公共物联网平台，比如 OneNet、阿里云 IoT、腾讯云 IoT。平台提供设备影子、规则引擎和可视化面板，适合做毕设展示。
- 自建 MQTT Broker，例如 EMQX，部署在云服务器。开发灵活，但需要自己维护服务。
- 串口转 TCP 网关，由 STM32 直接把数据通过 WiFi 模块发到 TCP Server。这种方式最原始，适合内网调试。
如果只是本地小范围验证，建议先把数据发到 PC 上运行的 MQTT Broker，用 MQTTX 客户端订阅主题看数据是否正常。不要一上来就买云服务器，先用内网把 MQTT 链路跑通，再考虑公网部署。
9. 显存、CPU 之外的资源占用怎么看
STM32 项目不像 AI 模型那样看显存，但同样要关注 Flash、RAM 和 CPU 占用。用 Keil 编译后，Build Output 窗口里会直接给出占用：
Program Size: Code=12676 RO-data=1288 RW-data=132 ZI-data=2416 FromELF: creating hex file...这四个数字的含义：
| 指标 | 含义 |
|---|---|
| Code | 代码段，占 Flash |
| RO-data | 只读数据，例如常量表和字符串，占 Flash |
| RW-data | 初始化过的变量，运行时拷贝到 RAM，占 Flash + RAM |
| ZI-data | 零初始化变量，运行时占 RAM |
STM32F103C8T6 的 Flash 是 64KB、RAM 是 20KB，也就是说 Code + RO-data + RW-data 要小于 64KB，RAM 总量要小于 20KB。开源项目通常不会超，但如果你加了 WiFi、JSON 库、OLED 字库、FreeRTOS，就要经常瞄一眼编译输出。
CPU 占用怎么估算？如果是裸机超级循环，CPU 基本都在跑传感器读数和显示刷新，谈不上“实时性”。如果加了 FreeRTOS，可以用任务运行时间统计功能，逐个任务看 CPU 占比，确认 DHT11 读取任务没有长时间阻塞其他任务。
系统运行稳定性可以从三点观察：第一，看日志连续采集 12 小时是否有卡死；第二，看 OLED 是否一直在刷新；第三，看蜂鸣器误报频率是否正常。建议把采集周期设置成一个合理值，比如 2 秒采集一次温湿度，不要用 while 死循环连续读，否则传感器容易不稳定。
10. 常见问题与排查方法
嵌入式项目的坑基本集中在硬件连接、软件配置和工具链上。下表是高频问题清单，可以作为排查索引：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 编译报找不到头文件 | 工程路径变化，Include Path 失效 | 查看报错头文件名 | 在 Keil Options 里重新添加路径 |
| 编译报 Undefined symbol | 源文件没有加入工程 | 搜索符号名，找到所在的 .c 文件 | 右键 Source Group -> Add Existing Files |
| 烧录提示 No Target Connected | ST-Link 接线错误或驱动未装 | 检查 SWDIO/SWCLK/GND 是否接对 | 重装驱动，检查线序 |
| 烧录后程序不运行 | BOOT0 被拉高或者 Reset and Run 未勾选 | 测量 BOOT0 引脚电压 | 设置 BOOT0 为低电平，重新上电 |
| 串口乱码 | 波特率不匹配或晶振频率配置错误 | 检查日志波特率和主频 | 将波特率改为代码中的值；检查 HSE_VALUE |
| DHT11 数据一直为 0 | 接线错误、上拉缺失、读取间隔太短 | 示波器/万用表测DATA引脚 | 加 4.7k 上拉，读取间隔改为 1s 以上 |
| OLED 不显示 | I2C 地址错误、接线反了 | 扫描 I2C 设备地址 | 改地址 0x3C/0x3D，调换 SDA/SCL |
| OLED 显示花屏 | I2C 速率过高或供电不足 | 降低 I2C 时钟 | 改为 100kHz~200kHz |
| 光照数据不变 | 光敏电阻分压电路焊接问题或者 ADC 通道配置错误 | 量 ADC 引脚电压 | 检查分压电阻和 ADC 初始化 |
| 蜂鸣器不响 | 有源/无源蜂鸣器搞混 | 查阅模块引脚定义和原理图 | 无源蜂鸣器改用 PWM 驱动 |
| MQ 传感器数值不稳 | 预热时间不够或供电不足 | 上电预热 5 分钟后再测试 | 使用 5V 独立供电 |
| 长时间运行后死机 | 看门狗未开启，某传感器阻塞读超时 | 开启独立看门狗 IWDG | 在任务循环中喂狗 |
| 板子重新上电不工作 | 复位电路问题或供电不足 | 量 3.3V 电压是否稳定 | 检查 LDO 和电容 |
这里列出的方案都是最常见的排查思路。遇到具体问题时，先做最小系统测试：只留下 STM32 最小系统和串口，把其它外设全部断开。如果最小系统程序能跑，说明故障主要集中在传感器接入电路；如果最小系统都不正常，重点查电源和晶振。
11. 工程化最佳实践
从简单复现走向工程化，建议把这几点养成习惯。
11.1 保留最小可运行配置
下载完开源项目后，先不要改代码，直接编译烧录。如果板子没反应，问题大概率在硬件接线，而不是代码。跑通以后，再复制一份工程作为备份，保证任何一次改动后都能回退到可运行状态。
11.2 目录分清楚
建议把项目文件按下面的方式管理：
01_Src/ 仓库源码 02_Hardware/ 原理图、PCB、传感器数据手册 03_Tools/ 烧录工具、串口助手 04_Output/ 固件输出、日志记录 05_Docs/ 自己的笔记、引脚映射表这种分类方式对课程设计和产品开发都适用。
11.3 每次改动记录引脚和阈值
模块化开发时，自己改过的引脚定义、报警阈值、传感器采集周期都应该记录在项目根目录的CHANGELOG.md里。不然后面回头维护时根本想不起来为什么当时要把 PA1 改成 PB0。
# CHANGELOG ## 2025-06-01 - 将 DHT11 数据引脚从 PA1 改为 PB0 - 温度报警阈值从 28.0℃ 改为 30.0℃ - 温湿度采集间隔从 1s 调整为 2s11.4 代码中加入限幅滤波
MQ-2 这类传感器的输出噪声很大，直接拿原始 ADC 值做报警判断容易误报。建议在代码里加一个简单的限幅滤波，典型的实现如下：
#define MAX_DELTA 50 uint16_t limit_filter(uint16_t new_val, uint16_t last_val) { if (new_val > last_val + MAX_DELTA) { return last_val + MAX_DELTA; } else if (new_val + MAX_DELTA < last_val) { return last_val - MAX_DELTA; } return new_val; }每 100ms 采一次 ADC，限幅后再做平均值滤波，可以有效减少传感器噪声。
11.5 接口服务不要裸奔
如果后续真的接入了 WiFi 模块并做了 HTTP/MQTT 接口，务必注意安全边界。不要在代码里明文保存路由器密码，不使用公共 MQTT Broker 传输未加密数据，接口要设计 token 鉴权。云服务器上的端口尽量不暴露到公网，如果必须暴露，用 IP 白名单或安全组限制访问。
11.6 人脸、声音之外的隐忧
这个项目不涉及人脸和声音，但它在采集家庭环境数据。温湿度数据、传感器状态本身不敏感，但一旦接入公网，云端会积累设备运行信息和家庭时间段的数据。不要把这些数据随意公开，也不要接未经授权的第三方平台。合法合规是底线。
12. 总结与下一步
这个开源项目最大的价值在于：完整提供了 STM32 家居环境监测从硬件原理图到软件源码的可复现链路。对初学者，它是研究传感器驱动、GPIO 配置、定时器、ADC 和 I2C 通信的活教材；对做课程设计和毕设的人来说，它是一份能快速出效果的参考工程；对想接触物联网的开发者，它则是很好的本地采集节点底座。
拿到仓库以后，建议第一步做的事很明确：先把原理图转成 PDF，标出每个传感器接到哪个引脚；再打开源码对比一遍引脚定义；然后直接编译烧录，用串口日志确认传感器数据能正常读取。最容易踩的坑是“不看原理图，拿代码按默认接线就上电”，看起来小问题，实际排查可能耗掉一整天。
跑通第一版以后，可以按三条线继续扩展：一是提高数据精度，把 DHT11 升级成 SHT30；二是增加联网能力，用 ESP8266 把数据推给 MQTT Broker，手机端做可视化面板；三是优化整套系统的防误报逻辑和低功耗机制，让传感器节点能靠电池长期运行。
不管你是准备做毕设展示，还是想把它改造成真正可用的家庭环境监测节点，这个开源项目都值得完整跑一遍。建议收藏备用，后面做 STM32 项目时可以直接拿出来当工程模板。
