简介这份压缩包面向Arduino IDE使用者与物联网项目开发者提供DHT11、DHT21、DHT22三种温湿度传感器的统一驱动库解决不同型号传感器在Arduino平台上读取数据需要分别适配的问题。包内共10个文件以cpp源文件与h头文件构成核心库两个ino示例工程展示初始化与读取流程另有Markdown说明文档、library.properties配置及关键字列表等辅助内容整体仅15KB。已有1361人学习下载适合电子爱好者快速完成环境监测原型。借助封装的简洁API开发者无需深究单总线通信细节即可稳定获取温度与湿度数据并根据项目需求灵活选用入门级DHT11、均衡型DHT21或高精度DHT22大幅缩短智能家居、气象站、温室控制等场景的开发迭代时间。 昨天群里又有人截图求救“下载了一个DHT11-DHT21-DHT22库文件.zip解压出来一堆文件然后呢”老实说这个问题我在各种嵌入式群、论坛里见过不下五十次。DHT11温湿度传感器可能是很多人入门单片机做的第一个能输出有效数据的传感器而能不能把网上下载的库文件正确塞进工程往往是新手的第一个拦路虎。这篇文章不打算只告诉你“把文件夹放到哪”我会从库文件里到底封装了什么、DHT通信时序为什么苛刻、在Arduino/STM32/51等平台怎么落地以及读不到数据时按什么顺序排查这几个角度把它们一次讲透。无论你是刚拿到东西的初学者还是想自己封装驱动的进阶者都能在这里找到可复现的操作。1. 为什么总有人发“库文件.zip”而不是直接给源码1.1 库文件到底是什么它解决了什么问题DHT11这类传感器本质上就是一个三个引脚的元件VCC、GND、DATA。很多新手觉得这叫个什么事我用GPIO读高低电平不就行了但等你真正开始操作就会发现DHT的通信协议里全是“微秒级”的时序要求。比如主机要先拉低数据线18ms以上作为起始信号释放总线后要等20到40us让传感器响应接着读每一位数据时还要区分高电平持续26us左右是逻辑0、持续70us左右是逻辑1。裸写这套时序最容易出的问题就是延时函数不准、位判断边界模糊、时序被打断。社区里大家就干脆把整套驱动封装成“库文件”你拿到手不用关心底层怎么实现的实例化一个对象调一个读函数温湿度就出来了。这个zip包实际就是一群嵌入式工程师把“反复验证过的驱动代码”打了个包让你绕开最容易翻车的那部分。1.2 zip压缩包里的典型目录结构长什么样我把这个“DHT11-DHT21-DHT22库文件.zip”解压之后典型结构一般是这样的DHT11-DHT21-DHT22/ ├── dht.h ├── dht.cpp ├── keywords.txt ├── README.md └── examples/ └── DHTtester/ └── DHTtester.ino其中dht.h是头文件声明了DHT这个类以及setup、read等公共接口dht.cpp是核心实现所有时序读取、数据校验、型号参数切换都写在里面examples目录放的是Arduino的示例工程你直接用IDE打开DHTtester.ino就能跑。keywords.txt和README.md一个用于IDE语法高亮、一个是说明文档删掉不影响编译但README里的接线图和采样周期说明建议认真看一遍。因为.dht.cpp和.dht.h是一对直接散着发容易被漏掉所以大家习惯打成zip包。这也带来了一个必然结果你拿到zip后第一件事不是改代码而是把目录放到正确的位置位置放错了编译器根本找不到库。1.3 DHT11、DHT21、DHT22为什么能共用一套库很多人第一次看到这个文件名会疑惑三个传感器不是一个型号怎么共用一套库因为它们的引脚定义完全一样通信协议都是单总线只是同一个协议下的参数不同。主控端看来区别仅仅是“某个高电平持续多少微秒”“采样周期是多少”“数据怎么换算”。所以库文件里一般会用宏或者枚举来区分三个型号你实例化时告诉库“我用的是哪一种”它内部就会切换对应的参数。比如在Arduino示例里常见这样一行DHT dht(DHTPIN, DHT22); // 第二个参数换成DHT11、DHT21或DHT22这也是这个zip包叫“DHT11-DHT21-DHT22库文件”而不是三个单独压缩包的原因。遇到性能接近的型号时改个参数就能复用省事很多。2. 把库跑起来之前先弄懂DHT的脾气2.1 单总线上的一场“你来我往”有人觉得DHT读取就是一个“读引脚”的过程其实不然。整个过程更像是一问一答主机先把数据线拉高然后拉低18到30ms这是呼叫传感器。主机释放总线上拉电阻把电平拉高等待20到40us。传感器响应先拉低约80us再拉高约80us表示“我准备好了”。随后传感器连续发送40位数据每发完一位总线都会先回落到低电平。这里有个细节起始信号的最低电平时间必须足够长短了传感器不响应。但也不能无限长长了传感器可能进入异常状态。库文件里已经写好了这些时长所以尽量别去改它。2.2 40位数据一位一位读出来40位数据按字节分成5组湿度整数、湿度小数、温度整数、温度小数、校验和。每个bit的编码方式是一段低电平之后跟着一段高电平高电平持续时间短是0长是1。读取时常见办法是先等总线变高然后再延时40us采样一次。如果采样到高电平说明这个bit的高电平总时长大于40us判为1如果采样到低电平说明高电平很短判为0。这套逻辑在库文件的readByte函数里基本都是这么写的。校验和的计算很简单把前4个字节相加取低8位如果和第5个字节相等这帧数据才算有效。我建议你拿到库之后把这个校验逻辑自己走一遍能极大提高你排查问题的能力。2.3 你手上到底是哪个型号市面上常见封装里白色的三脚/四脚扁插头老款大多是DHT11蓝色透明方壳多半是DHT21或DHT22。DHT21也常被标成AM2301DHT22标成AM2302英文资料里两种名字经常混着出现。三个型号的关键参数差异如下型号湿度分辨率湿度精度温度精度湿度测量范围温度测量范围额定采样周期DHT111%RH±5%RH±2℃20%~90%RH0℃~50℃1sDHT21AM23010.1%RH±3%RH±0.5℃0%~99.9%RH-40℃~80℃2sDHT22AM23020.1%RH±2~5%RH±0.5℃0%~99.9%RH-40℃~80℃2s如果你手头传感器来源不明最稳妥的办法是先用库里的DHT22参数测试因为它的湿度和温度量程最宽读数更容易判断是否合理。3. 库文件落地三种主流平台的具体接法3.1 Arduino最无脑但也最容易出错的位置Arduino上使用这个库确实是最简单的。zip解压后把整个文件夹放进libraries目录Windows一般在“文档/Arduino/libraries/”Linux在“~/Arduino/libraries/”。Arduino IDE 1.8以上版本也支持“项目/加载库/添加.ZIP库”直接选择这个zip文件IDE会自动帮你解压到正确位置。有三个坑我必须提醒你第一文件夹名不能带中文、不能带短横线否则编译阶段会报找不到头文件第二如果之前装过同名旧版库先删掉旧的再解压新的IDE不会主动覆盖两个版本共存经常导致“编译过了但行为很怪”第三放好库之后一定要完全重启IDE否则新库不会加载进索引。接线方面DATA脚接任意数字引脚比如D2VCC接3.3V或5VGND接GND最好在DATA和VCC之间加一个4.7k到10k的上拉电阻。示例代码就能直接读到串口输出。3.2 STM32 HAL库最大的敌人是HAL_DelaySTM32上用这个库最大的问题不是库本身而是HAL库里HAL_Delay只有毫秒级延时。DHT起始信号18ms可以用HAL_Delay但读取每个bit时要微秒级延时直接用HAL_Delay肯定不行。我通常用DWT寄存器做一个微秒延时#include stm32f1xx_hal.h static void DWT_Delay_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } static void DWT_Delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) ticks); }DWT是Cortex-M内核自带的调试跟踪组件不需要额外占用定时器在F1、F4系列上都能用。把库里的delay_us函数替换成这个时序就有保障了。还有一个细节DHT的数据线需要既当输出又当输入。最省心的方式是配成开漏输出加上外部上拉电阻。输出0就是拉低总线输出1就是释放总线让上拉把电平拉高读的时候直接读输入数据寄存器。这样省去了频繁切换GPIO输入输出方向的麻烦时序也更稳。3.3 51单片机与瑞萨没有现成底层就手写延时循环51平台上没有HAL_Delay这么方便的东西库文件里的微秒延时全靠自己造。如果系统时钟是12MHz一个简单的延时循环加上_nop_()就能凑出微秒级延时。比如void delay_us(unsigned int us) { while (us--) { _nop_(); } }但这里有个大坑同样的代码在不同优化级别下延时可能差一倍。我建议把延时函数单独放到一个没有优化或者固定优化的文件里然后用示波器或者逻辑分析仪实测校准千万不要凭经验瞎猜。瑞萨RA系列用e2 studio开发时思路一样GPIO读写用R_GPIO驱动微秒延时用定时器或者系统计时器生成重要的是让读取函数在微秒级别上稳定。4. 库加进去了但读不到正确数据我的排查顺序4.1 板子一上电就读先让传感器喘口气数据一直返回0xFF或者恒定不变的数最常见的不是库坏了是读取频率太高。DHT11额定采样周期是1sDHT21/DHT22是2s而新手经常在loop里不眠不休地循环读传感器根本来不及完成下一次测量返回的就是陈旧数据或者应答异常。我在实际项目里有个习惯不管是哪个型号把采样周期宏设置成比额定期长1.5倍以上。比如DHT22就至少隔3秒读一次宁可慢一点也要稳。另外刚上电的瞬间不要立刻读先延时1秒再来第一次握手很多莫名其妙的首帧错误就这么消失了。4.2 引脚模式、上拉电阻和电平不匹配的表现形式接好线却读回全是0大概率是GPIO方向配置或者上下拉出了问题。如果你用推挽输出并手动切换输入输出方向切换瞬间可能因为总线电平没稳定而读错。这时可以改用开漏加外部上拉如果实在没有外部电阻内部上拉也能凑合但内部上拉阻值往往几十千欧上升沿太慢长线或者干扰大的场合特别容易读错。电平不匹配同样隐蔽MCU用3.3V传感器却拿5V供电DHT返回的高电平接近5V对部分3.3V容限不够的引脚就是灾难。反过来传感器用3.3V供电、MCU的引脚是5V容限时虽然一般能跑但最好确认一下手册。用万用表量DATA线在高电平时是否接近供电电压能快速排除这部分问题。4.3 校验和不过关时的完整排查链路如果你已经能读到数据但库函数一直返回校验失败这时候我建议按顺序查先看波形。用逻辑分析仪抓DATA引脚正常波形里起始信号至少要维持18ms低电平响应信号应该是两个80us左右的脉冲。如果你看到低电平时长明显短或者毛刺很多问题出在驱动侧或供电侧。再看延时函数。DWT或者定时器延时务必在主频配置正确的前提下使用如果SystemCoreClock和你实际跑的主频不一致微秒延时全部偏差根本不可能读到正确的40位。最后才怀疑传感器。排除接线和时序问题之后换一个已知正常的传感器对比测试别一上来就甩锅给元件。在处理校验问题上要特别强调读取整段40位数据的过程中任何中断都会破坏时序。串口中断、定时器中断如果在读取中途触发轻则误判某个bit重则直接丢帧。我通常会在读数据前关全局中断读完立刻打开__disable_irq(); dht.readData(); __enable_irq();这也是很多库的示例里没写、但实际项目中必须加的细节。如果只是Demo怎么都行上产品了这行代码能帮你省掉一堆偶发错误。最后分享一个我自己的习惯不管从哪个渠道下载的DHT系列库我一定会先打开dht.cpp把采样周期、校验和计算、微秒延时这三段代码读一遍再决定直接用还是改一版。这不是信不过别人而是只有你自己理解了这套时序后面遇到“读十次错一次”这种最难查的偶发故障时你才知道从哪个方向下手。实际测试下来外部上拉电阻、开漏输出、关中断读数据、放宽采样间隔这四件事做好DHT11和DHT22的读取成功率能稳定很长时间。本文还有配套的精品资源点击获取
简介这份压缩包面向Arduino IDE使用者与物联网项目开发者提供DHT11、DHT21、DHT22三种温湿度传感器的统一驱动库解决不同型号传感器在Arduino平台上读取数据需要分别适配的问题。包内共10个文件以cpp源文件与h头文件构成核心库两个ino示例工程展示初始化与读取流程另有Markdown说明文档、library.properties配置及关键字列表等辅助内容整体仅15KB。已有1361人学习下载适合电子爱好者快速完成环境监测原型。借助封装的简洁API开发者无需深究单总线通信细节即可稳定获取温度与湿度数据并根据项目需求灵活选用入门级DHT11、均衡型DHT21或高精度DHT22大幅缩短智能家居、气象站、温室控制等场景的开发迭代时间。 昨天群里又有人截图求救“下载了一个DHT11-DHT21-DHT22库文件.zip解压出来一堆文件然后呢”老实说这个问题我在各种嵌入式群、论坛里见过不下五十次。DHT11温湿度传感器可能是很多人入门单片机做的第一个能输出有效数据的传感器而能不能把网上下载的库文件正确塞进工程往往是新手的第一个拦路虎。这篇文章不打算只告诉你“把文件夹放到哪”我会从库文件里到底封装了什么、DHT通信时序为什么苛刻、在Arduino/STM32/51等平台怎么落地以及读不到数据时按什么顺序排查这几个角度把它们一次讲透。无论你是刚拿到东西的初学者还是想自己封装驱动的进阶者都能在这里找到可复现的操作。1. 为什么总有人发“库文件.zip”而不是直接给源码1.1 库文件到底是什么它解决了什么问题DHT11这类传感器本质上就是一个三个引脚的元件VCC、GND、DATA。很多新手觉得这叫个什么事我用GPIO读高低电平不就行了但等你真正开始操作就会发现DHT的通信协议里全是“微秒级”的时序要求。比如主机要先拉低数据线18ms以上作为起始信号释放总线后要等20到40us让传感器响应接着读每一位数据时还要区分高电平持续26us左右是逻辑0、持续70us左右是逻辑1。裸写这套时序最容易出的问题就是延时函数不准、位判断边界模糊、时序被打断。社区里大家就干脆把整套驱动封装成“库文件”你拿到手不用关心底层怎么实现的实例化一个对象调一个读函数温湿度就出来了。这个zip包实际就是一群嵌入式工程师把“反复验证过的驱动代码”打了个包让你绕开最容易翻车的那部分。1.2 zip压缩包里的典型目录结构长什么样我把这个“DHT11-DHT21-DHT22库文件.zip”解压之后典型结构一般是这样的DHT11-DHT21-DHT22/ ├── dht.h ├── dht.cpp ├── keywords.txt ├── README.md └── examples/ └── DHTtester/ └── DHTtester.ino其中dht.h是头文件声明了DHT这个类以及setup、read等公共接口dht.cpp是核心实现所有时序读取、数据校验、型号参数切换都写在里面examples目录放的是Arduino的示例工程你直接用IDE打开DHTtester.ino就能跑。keywords.txt和README.md一个用于IDE语法高亮、一个是说明文档删掉不影响编译但README里的接线图和采样周期说明建议认真看一遍。因为.dht.cpp和.dht.h是一对直接散着发容易被漏掉所以大家习惯打成zip包。这也带来了一个必然结果你拿到zip后第一件事不是改代码而是把目录放到正确的位置位置放错了编译器根本找不到库。1.3 DHT11、DHT21、DHT22为什么能共用一套库很多人第一次看到这个文件名会疑惑三个传感器不是一个型号怎么共用一套库因为它们的引脚定义完全一样通信协议都是单总线只是同一个协议下的参数不同。主控端看来区别仅仅是“某个高电平持续多少微秒”“采样周期是多少”“数据怎么换算”。所以库文件里一般会用宏或者枚举来区分三个型号你实例化时告诉库“我用的是哪一种”它内部就会切换对应的参数。比如在Arduino示例里常见这样一行DHT dht(DHTPIN, DHT22); // 第二个参数换成DHT11、DHT21或DHT22这也是这个zip包叫“DHT11-DHT21-DHT22库文件”而不是三个单独压缩包的原因。遇到性能接近的型号时改个参数就能复用省事很多。2. 把库跑起来之前先弄懂DHT的脾气2.1 单总线上的一场“你来我往”有人觉得DHT读取就是一个“读引脚”的过程其实不然。整个过程更像是一问一答主机先把数据线拉高然后拉低18到30ms这是呼叫传感器。主机释放总线上拉电阻把电平拉高等待20到40us。传感器响应先拉低约80us再拉高约80us表示“我准备好了”。随后传感器连续发送40位数据每发完一位总线都会先回落到低电平。这里有个细节起始信号的最低电平时间必须足够长短了传感器不响应。但也不能无限长长了传感器可能进入异常状态。库文件里已经写好了这些时长所以尽量别去改它。2.2 40位数据一位一位读出来40位数据按字节分成5组湿度整数、湿度小数、温度整数、温度小数、校验和。每个bit的编码方式是一段低电平之后跟着一段高电平高电平持续时间短是0长是1。读取时常见办法是先等总线变高然后再延时40us采样一次。如果采样到高电平说明这个bit的高电平总时长大于40us判为1如果采样到低电平说明高电平很短判为0。这套逻辑在库文件的readByte函数里基本都是这么写的。校验和的计算很简单把前4个字节相加取低8位如果和第5个字节相等这帧数据才算有效。我建议你拿到库之后把这个校验逻辑自己走一遍能极大提高你排查问题的能力。2.3 你手上到底是哪个型号市面上常见封装里白色的三脚/四脚扁插头老款大多是DHT11蓝色透明方壳多半是DHT21或DHT22。DHT21也常被标成AM2301DHT22标成AM2302英文资料里两种名字经常混着出现。三个型号的关键参数差异如下型号湿度分辨率湿度精度温度精度湿度测量范围温度测量范围额定采样周期DHT111%RH±5%RH±2℃20%~90%RH0℃~50℃1sDHT21AM23010.1%RH±3%RH±0.5℃0%~99.9%RH-40℃~80℃2sDHT22AM23020.1%RH±2~5%RH±0.5℃0%~99.9%RH-40℃~80℃2s如果你手头传感器来源不明最稳妥的办法是先用库里的DHT22参数测试因为它的湿度和温度量程最宽读数更容易判断是否合理。3. 库文件落地三种主流平台的具体接法3.1 Arduino最无脑但也最容易出错的位置Arduino上使用这个库确实是最简单的。zip解压后把整个文件夹放进libraries目录Windows一般在“文档/Arduino/libraries/”Linux在“~/Arduino/libraries/”。Arduino IDE 1.8以上版本也支持“项目/加载库/添加.ZIP库”直接选择这个zip文件IDE会自动帮你解压到正确位置。有三个坑我必须提醒你第一文件夹名不能带中文、不能带短横线否则编译阶段会报找不到头文件第二如果之前装过同名旧版库先删掉旧的再解压新的IDE不会主动覆盖两个版本共存经常导致“编译过了但行为很怪”第三放好库之后一定要完全重启IDE否则新库不会加载进索引。接线方面DATA脚接任意数字引脚比如D2VCC接3.3V或5VGND接GND最好在DATA和VCC之间加一个4.7k到10k的上拉电阻。示例代码就能直接读到串口输出。3.2 STM32 HAL库最大的敌人是HAL_DelaySTM32上用这个库最大的问题不是库本身而是HAL库里HAL_Delay只有毫秒级延时。DHT起始信号18ms可以用HAL_Delay但读取每个bit时要微秒级延时直接用HAL_Delay肯定不行。我通常用DWT寄存器做一个微秒延时#include stm32f1xx_hal.h static void DWT_Delay_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } static void DWT_Delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) ticks); }DWT是Cortex-M内核自带的调试跟踪组件不需要额外占用定时器在F1、F4系列上都能用。把库里的delay_us函数替换成这个时序就有保障了。还有一个细节DHT的数据线需要既当输出又当输入。最省心的方式是配成开漏输出加上外部上拉电阻。输出0就是拉低总线输出1就是释放总线让上拉把电平拉高读的时候直接读输入数据寄存器。这样省去了频繁切换GPIO输入输出方向的麻烦时序也更稳。3.3 51单片机与瑞萨没有现成底层就手写延时循环51平台上没有HAL_Delay这么方便的东西库文件里的微秒延时全靠自己造。如果系统时钟是12MHz一个简单的延时循环加上_nop_()就能凑出微秒级延时。比如void delay_us(unsigned int us) { while (us--) { _nop_(); } }但这里有个大坑同样的代码在不同优化级别下延时可能差一倍。我建议把延时函数单独放到一个没有优化或者固定优化的文件里然后用示波器或者逻辑分析仪实测校准千万不要凭经验瞎猜。瑞萨RA系列用e2 studio开发时思路一样GPIO读写用R_GPIO驱动微秒延时用定时器或者系统计时器生成重要的是让读取函数在微秒级别上稳定。4. 库加进去了但读不到正确数据我的排查顺序4.1 板子一上电就读先让传感器喘口气数据一直返回0xFF或者恒定不变的数最常见的不是库坏了是读取频率太高。DHT11额定采样周期是1sDHT21/DHT22是2s而新手经常在loop里不眠不休地循环读传感器根本来不及完成下一次测量返回的就是陈旧数据或者应答异常。我在实际项目里有个习惯不管是哪个型号把采样周期宏设置成比额定期长1.5倍以上。比如DHT22就至少隔3秒读一次宁可慢一点也要稳。另外刚上电的瞬间不要立刻读先延时1秒再来第一次握手很多莫名其妙的首帧错误就这么消失了。4.2 引脚模式、上拉电阻和电平不匹配的表现形式接好线却读回全是0大概率是GPIO方向配置或者上下拉出了问题。如果你用推挽输出并手动切换输入输出方向切换瞬间可能因为总线电平没稳定而读错。这时可以改用开漏加外部上拉如果实在没有外部电阻内部上拉也能凑合但内部上拉阻值往往几十千欧上升沿太慢长线或者干扰大的场合特别容易读错。电平不匹配同样隐蔽MCU用3.3V传感器却拿5V供电DHT返回的高电平接近5V对部分3.3V容限不够的引脚就是灾难。反过来传感器用3.3V供电、MCU的引脚是5V容限时虽然一般能跑但最好确认一下手册。用万用表量DATA线在高电平时是否接近供电电压能快速排除这部分问题。4.3 校验和不过关时的完整排查链路如果你已经能读到数据但库函数一直返回校验失败这时候我建议按顺序查先看波形。用逻辑分析仪抓DATA引脚正常波形里起始信号至少要维持18ms低电平响应信号应该是两个80us左右的脉冲。如果你看到低电平时长明显短或者毛刺很多问题出在驱动侧或供电侧。再看延时函数。DWT或者定时器延时务必在主频配置正确的前提下使用如果SystemCoreClock和你实际跑的主频不一致微秒延时全部偏差根本不可能读到正确的40位。最后才怀疑传感器。排除接线和时序问题之后换一个已知正常的传感器对比测试别一上来就甩锅给元件。在处理校验问题上要特别强调读取整段40位数据的过程中任何中断都会破坏时序。串口中断、定时器中断如果在读取中途触发轻则误判某个bit重则直接丢帧。我通常会在读数据前关全局中断读完立刻打开__disable_irq(); dht.readData(); __enable_irq();这也是很多库的示例里没写、但实际项目中必须加的细节。如果只是Demo怎么都行上产品了这行代码能帮你省掉一堆偶发错误。最后分享一个我自己的习惯不管从哪个渠道下载的DHT系列库我一定会先打开dht.cpp把采样周期、校验和计算、微秒延时这三段代码读一遍再决定直接用还是改一版。这不是信不过别人而是只有你自己理解了这套时序后面遇到“读十次错一次”这种最难查的偶发故障时你才知道从哪个方向下手。实际测试下来外部上拉电阻、开漏输出、关中断读数据、放宽采样间隔这四件事做好DHT11和DHT22的读取成功率能稳定很长时间。本文还有配套的精品资源点击获取
