前阵子整理网盘翻出一个三年前的STM32工程是当时给学生做毕设辅导时写的一套家庭环境监测系统。代码、原理图、Proteus仿真文件都还在整理了一下索性开源出来。没想到发出去之后反响还不错不少人留言问硬件怎么接、DHT11时序怎么调、仿真里为什么读不到数据。干脆写一篇完整的拆解文章把设计思路、原理图关键点、代码架构、仿真排坑一次性讲清楚。这个项目本质上就是一块STM32F103C8T6最小系统板配合DHT11温湿度传感器、OLED显示屏、蜂鸣器和几个按键实现温湿度实时采集、显示、超限报警、串口上报这几个核心功能。麻雀虽小五脏俱全非常适合正在学STM32的在校生、刚入门嵌入式开发的自学者、以及需要做课程设计或者毕业设计的同学参考。整套资料包含可编译的Keil工程、Altium Designer格式的原理图、Proteus 8.x仿真文件拿到手就能跑。1. 项目整体设计与思路拆解1.1 核心需求解析做这个项目的初衷很简单要一个能覆盖“传感器采集—数据处理—人机交互—报警输出”完整链路的小系统。很多初学者写的STM32程序停留在点灯和按键轮询的阶段而家庭环境监测恰好能把传感器驱动、显示驱动、中断、定时器、状态机这些知识点串起来。同时温湿度数据是直观可验证的手摸一下传感器数值就变排错门槛低特别适合作为综合练手项目。功能需求定下来四块实时采集环境温湿度OLED屏幕清晰展示数据温湿度超出上下限时蜂鸣器报警通过串口把数据发到上位机。硬件资源上STM32F103C8T6这颗芯片有64KB Flash和20KB RAM跑这些功能绰绰余。选择C8T6而不是F407或者H7还有一个现实考虑价格便宜市面上几块钱一片最小系统板也就十几块学生党折腾起来不心疼。1.2 为什么选STM32F103C8T6这个选择其实带有很强的“教学传承”色彩。STM32F103系列是ARM Cortex-M3内核的经典款主频72MHz GPIO、定时器、USART、I2C、SPI这些外设一应俱全市面上教程最多、资料最全、踩坑记录也最丰富。你遇到任何问题搜一下基本都能找到前人留下的解决方案。具体到C8T6这颗芯片48引脚LQFP封装焊接难度适中手工焊接完全可行。有2个USART、2个SPI、2个I2C、3个通用定时器、1个高级定时器对家庭环境监测这种场景来说外设根本用不完。还要提的一点是3.3V供电TTL电平和OLED模块、温湿度传感器这些常见的3.3V外设直接对接不需要额外的电平转换电路。1.3 传感器选型DHT11还是SHT30传感器这块我特意选了两套方案。默认用DHT11因为这是初学者接触最多的数字温湿度传感器单总线协议、时序要求严格、网上资料多到爆炸是练手和理解时序图的最佳教材。但DHT11的精度和采样周期是有明显天花板的温度精度±2℃湿度精度±5%RH采样周期要求大于1秒。说白了它只能告诉你“今天大概多少度”没办法胜任精密测量场景。有经验的朋友到手之后可以自己换成SHT30I2C接口温度精度±0.3℃湿度精度±2%RH性能完全不在一个量级。原理图上我预留了兼容接口换传感器只需要改驱动库主逻辑代码完全不用动。这也是嵌入式开发的一个好习惯驱动层和业务逻辑层解耦硬件升级不影响上层架构。1.4 显示与交互方案显示方案首选0.96寸I2C接口OLEDSSD1306驱动芯片128×64分辨率。选它的理由很单纯I2C只占两根线SCL、SDA接线极简库也成熟u8g2、ssd1306的驱动源码到处都是。相比LCD1602需要8根数据线加控制线OLED的接线可以让整个系统的硬件复杂度降低一个档次。OLED还能显示中文、画曲线、做简单动画后续想扩展功能有充足的发挥空间。交互部分保留了三个按键和一个蜂鸣器。按键用来设置报警阈值蜂鸣器用来声音报警。很多初学项目喜欢用有源蜂鸣器通电就响程序好写。我这个电路里用的是无源蜂鸣器需要PWM或者定时器翻转IO才能发声。为什么选无源因为可以播放不同频率的声音比如报警时用急促的双音调恢复正常时用平缓的单音交互体验比单纯滴滴声好很多。代价就是驱动稍微复杂一点但正好可以练习定时器PWM输出。1.5 供电整体考虑这个项目供电设计了两种方式USB 5V输入和3.7V锂电池输入。板载AMS1117-3.3稳压芯片把输入电源稳压到3.3V给主控和外设供电。USB供电适合桌面场景锂电池适合做成便携式设备毕竟叫“家庭环境监测”可能被放在阳台、车库、儿童房这些不一定方便拉USB线的地方。要注意的是DHT11的供电范围是3.3V到5VOLED模块一般支持3.3V或5V。我统一用3.3V供电避免电平不匹配的问题。数据引脚DHT11的DATA线不需要上拉电阻到VCC。实际上DHT11模块板上已经集成了4.7K上拉电阻和滤波电容买模块直接用就好。2. 核心硬件细节与原理图解析2.1 最小系统四件套STM32F103C8T6要跑起来最小系统需要四样东西电源电路、时钟电路、复位电路、启动模式选择电路。这四样缺一不可也是原理图里最基础的部分。电源电路的核心是AMS1117-3.3输入侧接5V输出侧接3.3V。输入和输出各放一个10uF钽电容和100nF陶瓷电容滤波。陶瓷电容靠近芯片引脚放置负责滤除高频噪声钽电容容量大负责稳定电压。实际画PCB的时候这两个电容尽量靠近AMS1117的输入输出引脚走线短而粗。时钟电路是STM32的心脏。F103需要外部8MHz晶振。芯片内部虽然有HSI内部时钟精度和稳定性远不如外部晶振特别是用到串口通信时。晶振的两个引脚各接一个20pF左右的负载电容具体值可以通过晶振厂商提供的负载电容参数计算。我用的是8MHz晶振并联1MΩ电阻的经典接法实测串口波特率误差在允许范围内。旁边的32.768kHz低速晶振是可选的——只有用到RTC实时时钟才需要本项目的计时需求用系统滴答定时器就够了所以没有接。复位电路是一个10K电阻上拉到3.3V再接一个100nF电容到地中间引出NRST引脚。上电瞬间电容充电NRST引脚短暂处于低电平芯片复位然后电容充满电后引脚被拉到高电平芯片开始运行。按键复位则是在NRST和地之间并联一个轻触按键按下拉低复位。这个电路是标准写法直接抄就行。启动模式通过BOOT0和BOOT1引脚的电平选择。用跳线帽把BOOT0接地BOOT1随意选择从主Flash启动这是正常运行的配置。烧录程序时不需要切换BOOT状态STM32的ISP烧录和SWD调试都不依赖BOOT引脚网上有些教程让切换BOOT0到高电平再烧录那是串口ISP的玩法用ST-Link SWD下载根本不用折腾。2.2 DHT11传感器接口设计DHT11是单总线协议只有一根数据线既是输入又是输出。主机发起通信时先把总线拉低至少18ms然后释放并延时20-40us之后读取DHT11的响应信号。从机响应后会在总线上输出一串40位数据包含湿度整数、湿度小数、温度整数、温度小数、校验和顺序固定。原理图上DHT11的DATA引脚直接接到STM32的PA1。我之前提过模块板上已经有上拉电阻和滤波电容所以原理图上不额外画。但如果自己设计DHT11的裸传感器电路必须在DATA线上加一个4.7K到10K的上拉电阻到VCC否则总线无法正常工作。单总线的空闲状态是高电平全靠上拉电阻维持。PA1这个引脚选择有个小心思它兼容5V输入。虽然我们统一用3.3V供电但如果你手头只有5V版本的DHT11模块误接到这个引脚也不会烧芯片。这种“顺手留个余量”的习惯在设计时能省掉很多麻烦。2.3 OLED与按键报警电路OLED模块用的是I2C接口SCL接PB6SDA接PB7。这两个引脚是STM32F103的I2C1外设引脚支持硬件I2C。但说实话STM32的硬件I2C在F1系列上口碑一般很多人都遇到过大坑所以我的代码里用的是软件I2C——GPIO模拟时序任意两个GPIO都能用。代码里初始化的是PB6和PB7你要改到别的引脚只需要改宏定义。按键电路设计比较常规三个按键分别接PA0、PA1、PA2。注意PA0和PA1同时被我用作了DHT11的数据引脚不对这里得说清楚。实际布局中DHT11接的是PA1按键接的是PA0、PA4、PA5。当时这样分配是为了避开I2C和串口的引脚冲突。每个按键接一个10K下拉电阻到地按键另一端接3.3V。按下时引脚读高电平松开时下拉电阻保证引脚稳定为低。这里我用的是“按下为高”的接法和常见的“按下为低”接法逻辑相反代码里就要注意去抖和电平判断的配合。蜂鸣器接PB8通过一个NPN三极管S8050驱动。为什么不直接把蜂鸣器接在GPIO上无源蜂鸣器工作电流通常要20-30mA超过了STM32 GPIO的最大输出能力大约25mA长时间工作会损伤引脚。三极管在这里当开关用GPIO输出高电平三极管导通蜂鸣器通电发声GPIO输出低电平三极管截止蜂鸣器静音。基极串联一个1K电阻限制基极电流防止烧坏三极管。2.4 原理图排布与PCB可迁移性原理图层面我没画得太复杂分成了主控区、电源区、传感器接口区、显示接口区、按键区、蜂鸣器区六大块。这样做的好处是逻辑清晰排查问题的时候一眼能定位到某个功能模块。虽然开源包里提供的是原理图文件PCB文件没有放出来因为当时画的板子比较随意布线质量一般怕误导人。原理图是完整的想自己画板子直接照着抄就行。画原理图时有几个细节值得新手注意。第一每个芯片的电源引脚旁边都要放去耦电容一般用100nF靠近芯片放置这是稳定运行的基础保障。第二所有按键、传感器接口、OLED接口的标准件封装建议选插接件或者排针方便调试时飞线。第三丝印层要标注清楚每个接口的引脚定义和电压过了半年你自己回来看板子也能快速想起来更不用说别人拿到你的开源文件标注不清会带来额外的沟通成本。3. 软件架构与核心代码实现3.1 程序总体框架前后台系统整个程序采用典型的“前后台”裸机架构主循环是前台定时器中断是后台。主循环负责按键扫描、OLED刷新、DHT11读取调度、串口发送这些非实时任务定时器中断负责系统时基管理和蜂鸣器发声控制。主循环的大致结构是这样的int main(void) { // 初始化外设 SystemInit(); Delay_Init(); OLED_Init(); DHT11_Init(); UART1_Init(115200); Buzzer_Init(); Key_Init(); // 默认报警阈值 alarm_temp_high 30; alarm_temp_low 10; alarm_humi_high 80; alarm_humi_low 30; while (1) { // 每500ms读取一次温湿度 if (time_flag_500ms) { time_flag_500ms 0; DHT11_Read(); Process_Data(); } // 每100ms刷新一次显示和报警判断 if (time_flag_100ms) { time_flag_100ms 0; OLED_Show(); Check_Alarm(); } Key_Scan(); UART1_SendFrame(); } }这套框架最关键的设计是时间片轮询的思想。DHT11的读取周期要求大于1秒采样太频繁会导致数据不稳定所以用500ms作为读取间隔OLED刷新太快会闪烁100ms刷新一次刚好按键扫描可以更频繁一些主循环跑一圈的时间通常在几毫秒以内等效扫描频率足够了。各个任务分时复用CPU逻辑清晰且互不干扰。3.2 DHT11时序读取与抗干扰DHT11的驱动是整个项目的技术难点也是初学者最容易卡住的地方。单总线协议对时序要求精确到微秒级DHT11的手册里有详细时序图但真正写起代码来还是有不少暗坑。核心读取函数如下节选关键部分uint8_t DHT11_Read_Byte(void) { uint8_t i, byte 0; for (i 0; i 8; i) { // 等待低电平变为高电平表示开始发送下一个位 while (DHT11_PIN_READ() 0); Delay_us(40); // 延时40us判断电平高低 if (DHT11_PIN_READ() 1) { byte | (1 (7 - i)); while (DHT11_PIN_READ() 1); } } return byte; }这里的关键在于40us延时。DHT11的数据位有两种50us低电平26-28us高电平表示050us低电平70us高电平表示1。采样点选在信号跳变后40us处40us时0的高电平已经结束读到的是低电平1的高电平还在持续读到的是高电平。这样就区分出了0和1。延时可以调整到30-45us范围内但不同编译优化级别会影响延时的准确性所以需要实测调整。读取时序还有两个容易出错的地方。一是起始信号的时间必须大于18ms实际我用了20ms确保DHT11能可靠响应二是从开始到读取结束整个过程中要关闭中断否则中断会打乱微秒级延时的准确性导致时序错乱。我在代码里用了__disable_irq()和__enable_irq()来实现读取完成立即恢复中断。3.3 OLED显示与状态切换OLED基于SSD1306控制器我用了自己封装的软件I2C驱动库整个驱动函数就写了几百行核心操作就是通过I2C往SSD1306的显存写数据。SSD1306内置1KB显存对应128×64像素。写入显存的方式分两种页面寻址和水平寻址。我用的页面寻址显存被分成8页每页8行每次连续写入一页的128列数据。这种方式写字符很直观字模是8×16的一次写两页就能完成一个字符。显示逻辑用了一个简单的菜单状态机有四个状态typedef enum { PAGE_MAIN 0, // 正常温湿度显示 PAGE_SET_TEMP_HIGH, // 设置温度上限 PAGE_SET_TEMP_LOW, // 设置温度下限 PAGE_SET_HUMI_HIGH, // 设置湿度上限 PAGE_SET_HUMI_LOW // 设置湿度下限 } Page_State;上电默认进入PAGE_MAIN显示当前温湿度和报警状态还有一朵动态变化的小云朵图案——温度高于28度时云朵变成太阳湿度高于70%时云朵下面画雨滴算是给界面加了一点小趣味。长按SET键进入设置模式进入后用UP/DOWN键调整数值再按SET键切换到下一个参数直到退出设置模式。这种交互相当常见也是很多家电设备的标配逻辑参考价值高。显示界面还有一个容易忽略的细节设置模式下采集的数据仍然在后台更新但主界面暂停刷新。因为设置阈值时数值变化要实时可见如果主界面同时刷新OLED的I2C带宽会不足导致画面闪烁。分开刷新能保证两种模式都流畅。3.4 报警判据与串口协议报警逻辑不仅仅是简单的超限判断还要加上消抖和恢复判定void Check_Alarm(void) { uint8_t alert 0; if (cur_temp alarm_temp_high || cur_temp alarm_temp_low) alert 1; if (cur_humi alarm_humi_high || cur_humi alarm_humi_low) alert 1; // 连续3次检测到报警才真正触发防止偶发毛刺 if (alert) { alarm_cnt; if (alarm_cnt 3) { alarm_flag 1; Buzzer_On(); } } else { alarm_cnt 0; alarm_flag 0; Buzzer_Off(); } }连续三次检测到报警才触发这叫“软件消抖”原理和按键消抖一样。DHT11偶尔会读取失败或者数值跳变如果一超限就报警半夜里一个数据毛刺就能把你吵醒。加了消抖之后只有连续多次超限才会触发报警可靠性明显提升。报警触发之后蜂鸣器不只是一直响而是按照特定的节奏响。我用定时器中断实现了蜂鸣器控制报警时响200ms、停200ms、再响200ms如此循环听起来是急促的“滴滴滴”声恢复正常时响500ms单音提示。定时器每1ms进入一次中断维护一个蜂鸣器计数变量主循环只控制蜂鸣器的开关状态发声节奏交给中断处理这样即使主循环卡顿蜂鸣器依然能按节奏响。3.5 串口上行与上位机对接串口上报使用了简洁的文本协议数据用逗号分隔方便用串口助手直接查看也方便写上位机脚本解析TEMP:25.3,HUMI:56.0,ALARM:0波特率115200每500ms发送一帧。有人问为什么不用JSON格式原因很简单MCU资源有限处理JSON字符串比较费ROM和RAM。这种自定义的简单文本协议在嵌入式领域是主流做法可读性强、解析方便、几乎不占资源。如果后续要接入阿里云物联网平台或者Home Assistant只需要在串口接收端加一个协议转换脚本把文本协议转成云平台要求的JSON格式即可。整个工程的代码结构分模块组织dht11.c、oled.c、key.c、buzzer.c、uart.c、main.c每个模块的接口函数都有注释代码风格统一变量命名有明确含义。工程用的是Keil MDK5ARM Compiler版本5兼容性好直接双击工程文件就能打开编译下载。4. Proteus仿真环境搭建与排坑实录4.1 仿真工程的加载与配置开源包里附带的是Proteus 8.9版本的仿真文件文件名为env_monitor_sim.pdsprj。用Proteus 8.9及以上版本打开工程双击STM32芯片加载hex固件文件。烧录路径在/MDK-ARM/env_monitor.hex是在Keil里编译生成的。需要注意的是Proteus运行STM32仿真时会卡一下因为Proteus对Cortex-M3内核的仿真比较吃资源。电脑配置一般的话先把不用的软件关掉再开仿真。如果仿真时出现变量监视器Variable Monitor窗口闪烁特别慢可以在“System - Animation Options”里把帧率调低减少画面刷新率流畅度会好不少。仿真的意义主要在于验证代码逻辑——OLED显示、按键设置阈值、报警触发这些流程在没有真实硬件时也能完整跑通。但请务必清楚仿真不能替代实物调试很多硬件上的问题比如时序精度、电气特性、信号完整性问题在仿真中是暴露不出来的。4.2 Proteus仿真的几个经典坑第一个坑是Proteus的DHT11模型行为与真实芯片不完全一致。旧版Proteus8.7以下甚至没有DHT11模型需要手动下载安装第三方库。我提供的仿真工程里用的DHT11模型支持温湿度调节但调节方式比较隐蔽仿真运行时鼠标放在DHT11元件上按键盘上的A键是温度微调S键是湿度微调具体按键映射因模型版本而异。如果按键没反应右键点击元件在“Edit Properties”里看有没有外部触发接口有的版本是通过电压源模拟温湿度变化的。第二个坑是LED和蜂鸣器在仿真里的驱动能力问题和实物不同。仿真里三极管模型和真实S8050的放大倍数有差异导致某些情况下蜂鸣器不响或者响的声音很小。排查的时候先看GPIO引脚电平是否正确再看三极管基极有没有电流。用一个虚拟示波器挂在蜂鸣器两端观察波形如果波形正常但没声音多半是声学模型在Proteus里提取的声音太小把电脑音量调大或者换成纯逻辑探针判断电平翻转即可。第三个坑是芯片型号选错导致仿真报错。Proteus里STM32F103C8T6的仿真模型名称在不同版本里不一样有的叫“STM32F103C8”有的叫“STM32F103C8T6”。加载固件后如果不运行双击芯片检查“Program File”是否已经正确指向hex文件。4.3 晶振电容的计算选择原理图里晶振电路的电容参数我选的是22pF这个数值不是拍脑袋定的而是通过晶振负载电容参数计算出来的。8MHz晶振的数据手册里会给出负载电容CL常见值12pF到20pF。外部匹配电容的计算公式是CL (C1 × C2) / (C1 C2) Cstray其中Cstray是PCB走线和芯片引脚引入的寄生电容一般估算3-5pF。假设晶振的CL是12pFC1和C2取相同值C则有12 C/2 4Cstray取4pF解出来C 16pF取标准值15pF或者22pF都是合理的。我选了22pF因为手头正好有这个规格。电容偏大一点会让晶振起振更慢但更稳定偏小一点起振快但可能停振。这个计算过程写出来是想让大家明白原理图上的每个参数都有来源不是随便填的。4.4 交叉验证仿真结果与实物对比用仿真验证完逻辑之后我还做了几组数据对比测试。用DHT11在室温环境实测温度读数25.3度湿度56%RH同一时刻用Proteus仿真把DHT11模型调到相同条件两个数值基本一致。OLED屏幕显示的布局、报警阈值的设置流程、串口输出的数据帧格式在仿真和实物上都能一一对应上。有一点要特别强调仿真的DHT11模型忽略了很多真实世界的物理效应。真实的DHT11响应速度慢从冷环境到暖环境要几分钟才能稳定读数而仿真模型瞬间就变了。还有就是真实世界中的电源噪声会导致数据偶尔读取失败DHT11驱动代码里必须有超时和错误重读机制而仿真环境里永远稳定这些差异会让仿真通过的程序在实物上偶发问题所以最后一定还是要回到真实硬件上验证。5. 典型问题排查与避坑建议5.1 经典问题速查表问题现象可能原因排查思路程序下载时报“No STM32 Target Found”芯片没有供电、SWD引脚被占用、连接线接触不良、目标板进入了低功耗模式先检查电源指示灯再查SWDIO/SWCLK连接最后按住复位键点击下载松开的瞬间能连上就成功了DHT11一直读取失败或返回零起始信号延时不够、引脚配置错误、上拉电阻缺失用示波器抓DHT11数据线上的波形看主机是否有20ms低电平再看从机是否有80us低电平响应OLED屏幕全白或者无显示I2C地址错误、SDA/SCL接反、初始化时序不对、复位引脚没有正确拉高用逻辑分析仪抓I2C波形看主机是否发送了正确的设备地址0x3C或0x3D和命令字节蜂鸣器不响GPIO引脚配置为推挽输出但三极管基极没有限流电阻、驱动代码逻辑反了、无源蜂鸣器的PWM频率太低先测GPIO电平是否翻转再把示波器探头点到蜂鸣器两端看波形最后检查三极管基极电压是否大于0.7V仿真时DHT11数值固定不变没有按对调节快捷键、模型库不匹配、仿真动画被暂停确认仿真处于运行状态左下角有绿色三角再看DHT11模型的帮助文档里具体的按键映射串口输出乱码波特率不匹配、主频和波特率计算不匹配、用的是内部RC时钟确认上位机波特率是115200检查SystemInit是否配置了外部8MHz晶振用串口助手发0x55看是否收到0xAA自测环回5.2 经验总结这些坑我替你踩过了第一关于DHT11的时序。很多初学者从网上抄了一段驱动代码延时函数用的是软件延时换一个编译优化级别或者主频设置时序就全变了。强烈建议把延时函数校准一下用逻辑分析仪或者示波器实测确认延时的实际时间接近设定值。另一个办法是改用定时器做微秒延时牺牲一点点效率换稳定性代码量大一点但调试省心不少。第二关于OLED的I2C地址。市面上0.96寸OLED模块有0x3C和0x3D两种地址由模块背面的电阻焊接位置决定。程序里默认0x3C如果你的模块不显示首先排查这个。我有一次帮同学调程序怎么都不亮查了半小时最后发现模块地址是0x3D。第三关于报警阈值的EEPROM存储。这个项目开源版本里报警阈值是保存在RAM里的断电就丢。如果想做成完整产品阈值应该存到Flash或者外部EEPROM里。STM32F103的Flash支持编程操作把阈值放在最后一页Flash上电时读取修改时先擦除再写入这样可以做到断电保存。代码结构上需要增加一个Flash读写模块整体改动不大建议有余力的朋友自己加上。第四串口调试的坑。STM32F103C8T6板载的USB转串口芯片有时候不稳定尤其是山寨的CH340驱动装不上或者断连很常见。遇到串口异常先换USB口和USB线再检查设备管理器确认串口号识别成功。实测下来PL2303的老芯片在Win10以上的系统兼容性一般CH340反而更好。第五有一个关于编译器的建议。Keil MDK5的优化等级默认是-O0不优化跑DHT11时序没问题。如果你改成-O2甚至-O3编译器可能会调整代码顺序影响精确延时。如果一定要开优化请重点测试DHT11读取和I2C通信是否正常否则程序可能跑飞但你还找不到原因。5.3 项目扩展方向这套系统还可以在几个方向继续演进加ESP8266或者ESP32模块把温湿度数据上传到云平台做成真正的物联网设备加BH1750光照传感器和SGP30空气质量传感器让监测维度更全加LCD屏幕显示历史曲线这需要外扩Flash存储历史数据改用RTOS实时系统用FreeRTOS管理采集、显示、通信、报警各个任务。每个方向都有清晰的进阶路线从一个基础项目拓展到商用水准的设备并不遥远。我在实际使用中发现这整套资料最有价值的部分不是代码本身而是硬件设计、软件架构和调试过程三者之间的对应关系。照着仿真跑一遍能理解逻辑对照原理图看代码能明白为什么这么分配引脚再从仿真切到实物又能体会仿真覆盖不到的真实世界问题。这三层递进本身就是嵌入式开发的核心方法论。最后再分享一个项目层面的小建议做这类开源项目如果有余力的话把工程里每个模块的作用写清楚画一张简单的模块关系图放到README里。代码会过时但你当时为什么这么设计、遇到什么问题、怎么解的这些经验在若干年后比代码本身珍贵得多。我这次开源就把当年调试DHT11时序踩坑的记录整理成了文档放在资料包里面算是把一个嵌入式工程师的思考过程完整地传递给了拿到资料的人。