STM32环境监测系统实战：从原理图到Proteus仿真的完整开源方案

很多人一看到“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 64KB，RAM 20KB，做传感器采集、数据显示和逻辑判断完全够用；第二，它自带多路ADC、I2C、USART、定时器，不需要外扩芯片；第三，资料多、成本低、Proteus里面也有现成的仿真模型，非常适合做开源项目。

传感器选型上我推荐这样一套组合：

• DHT11（温湿度）：单总线数字传感器，虽然精度一般（温度±2℃，湿度±5%RH），但通信协议简单，代码写起来很容易理解，非常适合学习。如果对精度有要求，可以换SHT30，I2C接口，精度高一个量级，驱动替换起来也方便，代码里我已经预留了接口抽象层。
• 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)/(C1+C2)+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设备，地址固定为0x23（ADDR引脚接低电平），SDA和SCL同样需要上拉电阻，一般取4.7kΩ~10kΩ都可以，我习惯用4.7kΩ。

MQ-2模块需要特别注意供电。它的加热丝需要5V供电，而信号输出和ADC共地之后可以直接接到STM32的ADC引脚。但MQ-2上电之后有大约30秒到1分钟的预热期，这段时间输出电压会漂移，代码里要做个初始化延时，不然上电瞬间就误报警了。信号输出端我加了一个100nF滤波电容，能有效抑制加热丝的纹波干扰。

在ADC采集方面，MQ-2输出接到PA0（ADC1通道0），由于STM32的ADC是12位分辨率，参考电压3.3V，所以电压对应关系是：ADC值/4096*3.3V。如果接的是MQ-2模块而非裸传感器，模块上一般已经集成好比较器，可以输出数字信号，但为了浓度监测，我们还是用模拟输出。

2.3 显示、按键与报警电路

显示部分我用的是I2C接口的OLED屏幕（0.96寸，SSD1306驱动），只需要四根线：VCC、GND、SCL、SDA。对比LCD1602，OLED不需要背光，功耗低，显示信息量也更大，还能显示中文。如果你手头只有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-2

DHT11的驱动是这个项目里最考验时序的地方。它是单总线协议，主机发起起始信号后，DHT11响应并输出40位数据：湿度整数、湿度小数、温度整数、温度小数、校验和。每一位的0或1由高电平持续时间决定，26~28μs表示0，70μ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%RH，OLED显示“注意”提示，蜂鸣器间断鸣叫（响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文件。具体流程：

1. 新建Proteus工程，在元件库搜索STM32F103C8T6并放置。
2. 搜索DHT11、BH1750、MQ-2，如果Proteus版本里缺少这些模型，可以用信号发生器替代模拟电压变化。
3. 搜索OLED或者使用LM016L（LCD1602）作为替代显示。我开源包里的仿真工程用的是OLED的Proteus模型，如果你本地版本打不开提示缺少模型，可以换成LCD1602模型，代码里需要对应改调用的显示函数。
4. 把晶振电路、复位电路、电源网络补上，和真实原理图保持一致。

元件找齐之后，连线就基本和原理图一致了。注意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工程编译不过或者下载失败。我把这套项目里最容易出现的几个问题整理成表格：

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分钟内就能看到效果：

1. 安装Keil MDK5并确保已经安装STM32F1系列器件支持包。
2. 打开2_Code/MDK-ARM/下的工程文件，点击编译，确保0 Error。
3. 在工程配置Debug选项里选择你手头的调试器（ST-Link、J-Link或DAP-Link），连接开发板后下载程序。
4. 如果连不上开发板，直接使用4_Hex/下的hex文件，用FlyMcu等工具通过串口ISP方式烧录，也可以跑起来，不需要额外调试器。
5. 接好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规划、软件架构、代码实现到仿真验证，每一步都有明确的输出产物。很多初学者上来就急着写代码，代码写完了再想硬件怎么配，这样容易返工。正确顺序一定是先把需求想清楚，把原理图确定好，引脚分配规划好，再动手写代码，这样整体进度反而更快。

另外，我在做这个项目时还有一个很具体的体会：开源不是为了把文件丢出去就完事，而是要让别人能够顺畅地使用、复制、修改。所以我特别注重代码注释、原理图标注和文档说明，光是项目说明文档我就写了将近两千字，把每个引脚的连接、每路传感器出来的信号类型、每个模块的供电要求都写清楚了。还是那句话，你今天在文档里多写一句，明天可能就给使用者省下一下午的排查时间。

如果你在复现这套系统的过程中遇到问题，欢迎把报错信息截图或者日志发出来，大家一起交流。这种软硬件结合的项目，往往一个人的知识盲区正是另一个人的擅长领域。希望这套代码、原理图和仿真文件能成为你嵌入式路上的一个有效起点。