DHT11单总线协议时序解析与STM32驱动实现

说到单片机采集温湿度DHT11绝对是一个绕不开的入门器件。很多教程贴几段代码、接三根线就算完事可一旦时序稍有偏差读回来的数据不是乱跳就是直接超时。我自己早期做项目也被这玩意儿折腾过好几个晚上后来把单总线通信的时序和原理彻底吃透了再回头去写任何单总线类器件DS18B20、DHT22都顺了很多。这篇就把DHT11从器件原理、单总线协议细节到完整代码实现全部拆开揉碎来讲适合刚入门单片机、或者已经写过驱动但总是调不通的同学。1. 先别急着敲代码DHT11这个器件你得先看懂1.1 透明封装背后藏着什么DHT11拿到手里通常是一个蓝色四脚的塑封模块或者裸芯片。里面真正干活的东西有两个一个是高分子电容式湿度传感器另一个是NTC热敏电阻测温元件。MCU读取的不是电阻值或电容值本身而是经过内部ADC采样、计算之后通过单总线接口直接输出的数字信号。这就意味着你不需要自己搭建信号调理电路也不需要去换算电压和湿度的关系只要按照协议把数据“挖”出来就行。省去了模拟前端的设计代价就是你得在时序上跟它对齐否则什么都读不到。引脚定义很简单VCC、DATA、NC、GND。其中NC脚悬空不接实际使用只需要三根线。供电范围是3.3V到5.5V数据线需要外接一个4.7kΩ到10kΩ的上拉电阻到VCC。模块版的DHT11通常已经帮你把上拉电阻画在PCB上了直接插面包板和杜邦线用就行。1.2 测量范围和精度的现实问题DHT11的测量范围湿度20%到90%RH温度0℃到50℃。湿度精度±5%RH温度精度±2℃分辨率为1位小数但实际项目中它的小数部分几乎一直输出0。换句话说DHT11适合做环境监测、仓库温湿度记录、智能家居的粗略采集不适合用于精密仪器、实验室数据采集或者医疗设备。很多新人会拿DHT11去跟DHT22、SHT30对比纠结选哪个。我根据实际使用经验列个表传感器温度精度湿度精度采样周期通信接口价格区间约适用场景DHT11±2℃±5%RH1s单总线2-4元低成本环境监测DHT22±0.5℃±2%RH2s单总线8-15元一般精度记录SHT30±0.3℃±2%RH可配置I2C10-20元温室、气象站如果你只是做课程设计、DIY温湿度计、或者验证一下单总线协议DHT11完全够用。但如果是做产品我还是建议直接上SHT30省去后期校准的麻烦。DHT11出厂前做过多级校准个体之间的一致性还行但非线性误差在湿度较高时体现得比较明显。1.3 为什么说“时序”是它的命门DHT11和单片机之间只有DATA这一根线而且是半双工通信。所有信息都是通过这根线上电平变化的时间长短来表达的。它没有时钟线时序完全靠约定好的时间窗口来实现。跟I2C、SPI这类有时钟线的协议相比单总线对延时精度和时序稳定性要求非常高。打个比方I2C通信像两个人中间有一根“节拍器”说话的人按照节拍器来发数据听的人跟着同一根节拍器来采样单总线则更像两个人约定“我敲你一下后你隔两秒敲回我三下”没有任何外部节拍全靠双方内心计时准确。DHT11内部靠RC振荡器计时本身就存在偏差如果单片机侧的延时函数也不准确两边节奏一错位数据就乱了。2. 单总线协议拆解每一微秒都是有讲究的2.1 单总线的通信规则Single Wire Bus也叫1-Wire本质上是主机和从机之间通过一根开漏/推挽输出的数据线进行双向数据交换。严格意义上的1-Wire协议是Dallas公司定义的带总线挂载识别、ROM序列号等功能但DHT11只是借用了单总线的物理形式和时序思想并没有完整的1-Wire协议支持。不能像DS18B20那样在总线上挂多个设备做寻址这是很多人踩坑的地方。DHT11的数据线默认状态是高电平由上拉电阻拉高。主机要发起通信时先把总线拉低这是“预通知”信号告诉从机“我要开始传输了”。接着释放总线等待从机回应。整个数据传输过程中谁拉低总线、拉低多长时间、谁释放总线、在什么时间点采样都必须严格遵守规定的时间窗口。为什么必须用开漏加外部上拉因为主机和DHT11都有可能主动拉低总线如果两个都配置成推挽输出一个往外灌电流一个往里吸收电流轻则读不到数据重则烧坏IO口。开漏结构保证了任何一方想拉低都可以直接拉低想释放就交给上拉电阻恢复高电平。2.2 起始信号与响应信号细节完整通信过程分为几步主机把总线拉低至少18ms通常配置20ms以上然后释放总线并延时20us到40us。这个18ms的低电平对DHT11来说是一个“唤醒”信号时间太短DHT11识别不到太长会影响后续响应时序。DHT11检测到起始信号后会先把总线拉低80us左右再释放并拉高80us左右。这两个80us组合在一起就是DHT11的响应信号告诉主机“我准备好了你准备接收数据”。响应结束后DHT11开始输出40bit数据。每一位数据都是从拉低总线50us开始的。关键在于拉低之后的“高电平持续时间”数据“0”的高电平保持26us到28us数据“1”的高电平保持70us左右。单片机在读每一位数据的时候要看的是总线被拉高之后在某个时间点上总线处于高还是低。数据位的判断逻辑实操中就是在每个bit的低电平时结束之后等待一段时间再去读电平。标准做法是等低电平结束延时40us到50us然后读总线状态。如果读到高说明这一位是1如果读到低说明这一位是0。因为数据“0”的高电平只有26us到28us40us之后早就回落到0了而数据“1”的高电平能维持70us40us时正好还是高。2.3 40bit数据帧结构与校验算法DHT11一次输出40bit数据依次是数据段长度说明湿度整数8bit例如 60 表示60%RH湿度小数8bitDHT11通常为0温度整数8bit例如 26 表示26℃温度小数8bitDHT11通常为0校验和8bit前四个字节相加的低8位收到五个字节之后用前四个字节整数相加看低8位是否等于第五个字节。比如湿度整数湿度小数温度整数温度小数加起来等于校验字节说明数据有效。这也是整个通信流程里唯一的“纠错机制”。我遇到过几次读出来的温湿度偶尔跳变就是因为没有加校验把干扰数据当成有效值展示了。温度数据还有一个容易被忽略的点DHT11的温度整数字节最高位其实是符号位。最高位为0表示正温度为1表示负温度。不过DHT11的原理是NTC测温官方标称范围是0-50℃实际负温度环境下你大概率也读不到准确值所以这个符号位大部分时候用不到。但如果你在东北冬天做室外测试还是得把这个位筛掉否则读出来的温度直接变成一百多度的奇怪数值。3. 代码逐行拆解从GPIO配置到数据校验3.1 准备工作GPIO方向切换与微秒延时写DHT11驱动的第一步不是写时序函数而是准备两样东西一个能精确到微秒的延时一个能随时切换输入输出方向的GPIO。很多新手直接用HAL_Delay或者MS级的延时来拼时序基本都会失败。DHT11要求微秒级别的延时而标准库自带的延时函数精度根本不够误差动辄几十微秒时序早崩了。我常用的微秒延时方案是用Cortex-M内核的DWTData Watchpoint and Trace单元。它是内核自带的调试计数器不需要占用定时器资源精度非常高。DWT初始化代码如下void DWT_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } void Delay_Us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while (DWT-CYCCNT - start ticks); }注意这里的SystemCoreClock要跟实际系统时钟匹配。如果是STM32F103跑72MHz那一个微秒就是72个周期。如果改了时钟频率这个值要同步修改不然延时全错。GPIO方向快速切换以STM32 HAL库为例我习惯写成宏#define DHT11_PIN GPIO_PIN_8 #define DHT11_PORT GPIOB void DHT11_Pin_Out(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_PIN; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_PORT, GPIO_InitStruct); } void DHT11_Pin_In(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_PIN; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(DHT11_PORT, GPIO_InitStruct); }使用上拉模式的同时外部电路仍然建议接一个4.7kΩ上拉电阻。IO内部的上拉电阻大约在30kΩ到50kΩ之间单靠内部上拉不是不能工作但抗干扰能力明显下降线一长就出错。极端情况下甚至响应波形边缘变缓导致时序判断失准。3.2 起始信号发送函数主机拉低总线至少18ms再释放。有些代码写18ms我习惯写20ms多出来的2ms无伤大雅但能确保DHT11稳定唤醒。void DHT11_Start(void) { DHT11_Pin_Out(); DHT11_Set_Low(); // 拉低总线 HAL_Delay(20); // 主机起始信号保持20ms DHT11_Set_High(); // 释放总线 Delay_Us(30); // 释放后延时30us DHT11_Pin_In(); // 切为输入准备接收响应信号 }拉低20ms之后释放这个30us的延时很关键。释放太早或太晚都会错过DHT11的响应窗口。DHT11在检测到起始信号结束之后等待20us到40us才会开始拉低自己的响应信号主机在这个窗口内必须完成方向切换并且准备读。如果切得太晚响应信号已经过去了读到的就是一串高电平。3.3 响应检测与数据位读取响应信号是DHT11拉低80us再拉高80us。主机检测响应其实只需要两步先等总线变为低电平再等总线变为高电平。如果等待过程中一直为高说明DHT11没有响应返回失败。uint8_t DHT11_Wait_Response(void) { uint16_t timeout 0; // 等待低电平到来 while (DHT11_Read() 1) { if (timeout 500) return 1; // 超时无响应 Delay_Us(1); } // 等待低电平结束 timeout 0; while (DHT11_Read() 0) { if (timeout 500) return 1; Delay_Us(1); } // 等待高电平结束80us响应高电平 timeout 0; while (DHT11_Read() 1) { if (timeout 500) return 1; Delay_Us(1); } return 0; }这里为什么要加超时因为一旦信号线断掉、DHT11损坏或者接线错误总线状态就会一直卡在高电平或低电平。没有超时机制的话程序会死循环在等待里。嵌入式设备最怕的就是死等。所有超时值不需要太精确够用就行我习惯给500us到1ms的上限。数据位读取函数是核心中的核心直接上代码uint8_t DHT11_Read_Bit(void) { uint16_t timeout 0; // 等待数据位开始的低电平 while (DHT11_Read() 1) { if (timeout 500) return 0; Delay_Us(1); } // 低电平持续约50us之后是高电平 // 从高电平开始延时40us再采样 timeout 0; while (DHT11_Read() 0) { if (timeout 500) return 0; Delay_Us(1); } Delay_Us(40); // 采样高为1低为0 if (DHT11_Read() 1) { // 等待高电平结束避免影响下一个bit timeout 0; while (DHT11_Read() 1) { if (timeout 500) return 1; Delay_Us(1); } return 1; } else { return 0; } }这个函数里有两个地方值得停下来想一下。第一个是为什么在低电平结束之后要等40us再采样。因为数据“0”的高电平持续时间是26us到28us数据“1”的高电平是70us左右。40us刚好处于两者之间如果是“0”40us时总线已经因为无驱动而回到低电平如果是“1”40us时总线仍然维持在高电平。41us之后电平状态就会是0判读就会错。这个时间窗口其实比较宽裕但也不能太随意。第二个地方是采样完“1”之后为什么要等待高电平结束。如果不等待下一个bit起始的低电平会被误判为当前bit的一部分整体bit流就会错位。这也是很多读取失败产生“幽灵数据”的根源。3.4 完整读取函数与校验逻辑把位读取拼成字节再拼成五个字节。字节的位顺序是高位在前也就是MSB先出。读取时第一个bit是湿度整数部分的最高位。uint8_t DHT11_Read_Byte(void) { uint8_t byte 0; for (int i 0; i 8; i) { byte (byte 1) | DHT11_Read_Bit(); } return byte; } uint8_t DHT11_Read_Data(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5] {0}; DHT11_Start(); if (DHT11_Wait_Response() ! 0) return 1; for (int i 0; i 5; i) { buf[i] DHT11_Read_Byte(); } // 等待总线恢复空闲高电平 uint16_t timeout 0; while (DHT11_Read() 0) { if (timeout 1000) break; Delay_Us(1); } // 校验和判断 uint8_t sum buf[0] buf[1] buf[2] buf[3]; if (sum ! buf[4]) return 2; *humidity buf[0]; // 湿度整数 *temperature buf[2]; // 温度整数 return 0; }拿到温度数据后要不要处理负数如果你只在室内做环境监测不需要。如果你放室外最好把温度整数和0x80与运算一下保留低7位作为实际温度再根据符号位决定正负。DHT11虽然标称0℃到50℃但NTC测温在低温下响应很慢零下温度准确度不高只能做个参考。3.5 STM32主循环里的调用方式DHT11的数据手册明确写着两次读取间隔必须大于1秒实际我建议至少2秒。这个限制来自内部传感器的响应周期读得太频繁DHT11可能来不及完成测量就直接输出上一次的缓存数据甚至导致后续时序异常。uint8_t temp, hum; uint8_t status; while (1) { status DHT11_Read_Data(hum, temp); if (status 0) { printf(Temp: %d.%d C, Hum: %d.%d %%\r\n, temp 7 ? -(temp 0x7F) : (temp 0x7F), 0, hum, 0); } else { printf(DHT11 read error: %d\r\n, status); } HAL_Delay(2000); }有个小细节DHT11的小数位虽然是0但驱动里也可以读取buf[1]和buf[3]然后显示出来。不读的话有些模块会打印出奇怪的0%其实是正常的。我通常只取整数部分界面更干净。4. 51单片机的DHT11驱动差异点很多人学DHT11用的是STC89C52开发板而51单片机没有HAL库GPIO方向切换方式也和STM32不一样。51单片机的IO口是准双向口写1之后可以当作输入来读。但读之前要先写1这是准双向口的特性不写1直接读的话读到的永远是IO锁存器里的值而不是外部电平。51版的起始信号和位读取核心逻辑完全一样区别只在于GPIO的控制方式sbit DHT11 P1^0; void DHT11_Start(void) { DHT11 1; Delay_Ms(20); DHT11 0; DHT11 1; Delay_Us(30); DHT11 1; // 释放总线准备读 } uint8_t DHT11_Read_Bit(void) { while (DHT11 1); while (DHT11 0); Delay_Us(40); if (DHT11 1) { while (DHT11 1); return 1; } else { return 0; } }51单片机没有硬件DWT微秒延时只能靠软件空循环。我之前在STC89C52上用过这样的延时函数void Delay_Us(uint16_t us) { while (us--) { _nop_(); _nop_(); _nop_(); _nop_(); } }这个写法能不能用取决于晶振频率和编译器优化等级。12MHz晶振下一个_nop_大约1us但不同编译器优化之后实际周期数会变。稳妥的做法是直接拉逻辑分析仪看波形调空循环次数直到时序符合要求。如果是STC12系列运行速度更快同样的空循环延时只有12MHz下的一半时间需要重新校准。实在不想手动调微秒延时的人可以用定时器。51单片机一般有T0/T1两个定时器开一个1us中断的定时器来做计数基准精度比空循环稳定得多。代价是多占用一个定时器资源而且中断频繁调用也会增加CPU负担取舍看需求。5. 实战踩坑时序问题与硬件布线的门道5.1 常见故障对照速查表我在调DHT11的过程中遇到最多的问题集中在下面几种情况现象可能原因排查方向永远读到0xFF或255GPIO方向未切换接线错误DHT11未响应确认DATA引脚检查方向切换偶尔读到正确数据偶尔超时时序临界供电不稳导线过长加长起始信号缩短线缆加强供电温湿度长时间不动读的是缓存数据采样间隔太短拉长读取间隔到2s以上温度偏高5℃以上传感器靠近发热元件IO口上拉电阻过小远离热源检查上拉电阻数据跳变无规律电磁干扰接触不良代码超时逻辑有问题布线远离电机/继电器换屏蔽线第一个温度值为负或大于127没处理温度符号位温度整数与0x80判断符号5.2 上拉电阻与导线长度的选择DHT11数据线上拉电阻我一般选4.7kΩ这个阻值在3.3V和5V下都工作良好。阻值太大比如100kΩ会让信号上升沿变缓时序采样的窗口会被压缩。阻值太小比如100Ω则灌电流太大可能损坏传感器IO。导线长度方面DHT11原厂推荐数据线不超过20米但我实际测试下来超过3米就需要用屏蔽双绞线超过10米基本就得想办法加总线缓冲器。如果你用普通杜邦线接传感器放在窗外长度超过2米就已经开始偶尔报错了而报错表现很隐蔽——大部分时间正常每几十秒来一次超时。推荐的做法是数据线尽量短传感器放在单片机边上用延长线接传感器时要让VCC和GND在数据线两边并行走线。如果非要长距离传输可以考虑用RS485总线方案但那已经超出了DHT11本身的能力范围。5.3 用逻辑分析仪看波形调DHT11时序最大杀器就是逻辑分析仪。我用的是一台几十块钱的8通道24MHz采样率逻辑分析仪配Saleae兼容软件就能非常清楚地看到起始信号、响应信号和每一位数据的波形。接法也很简单逻辑分析仪的CH1接DHT11的DATA引脚GND接GND设置采样率为20MHz以上触发电平设置在高电平到低电平的下降沿然后触发抓取。波形出来后你会看到非常直观的时序节奏起始信号一段特别长20ms左右的低电平响应信号两个一短一短的低高脉冲各约80us数据位每位的起始都是50us低电平后面跟着不同的高电平宽度通过波形可以一眼判断出问题出在哪里。比如起始信号低电平时间不够18msDHT11永远不会响应又比如数据位高电平宽度全部接近50us说明传感器的时基偏差较大这时要适当调整采样时间点。调试时我还发现过一个好玩的现象DHT11不同批次的器件数据位的时序精度有一定差异。有的批次数据“1”的高电平在60us左右有的在80us左右。如果代码里的延时参数是抄的别人现成的在这一片上能用在另一片上可能就不行了。最稳的方式是在延时40us的采样点做动态判断同时把超时上限放宽到100us以上。5.4 供电稳定性的影响DHT11对供电纹波比较敏感尤其是用ST-Link的3.3V输出或者USB转TTL模块供电的时候。如果同时驱动了继电器、电机、舵机这类大电流负载稳压电路没做好VCC会周期性跌落DHT11的响应信号和数据信号就会失真。我的习惯是温湿度模块单独用一个LDO供电至少加一个100uF电解电容和一个0.1uF陶瓷电容在传感器附近。别觉得小题大做温度采集类的传感器对电源纯净度要求本来就高尤其是你要做长时间数据记录的时候这个电容能帮你省下大量排查莫名其妙的“偶发跳变”的时间。6. 驱动写完之后别忘了这些收尾工作驱动调通了只是第一步实际产品中还要考虑连续工作稳定性和异常恢复。我遇到过一种情况单片机已经跑了一段时间DHT11突然再也不响应了重启之后又恢复。排查下来是总线被干扰后卡在一个异常状态下而代码里所有等待都加了超时但超时后的处理只是简单报错没有做“复位整个总线”的操作。解决办法是每次读取失败之后把数据线拉低20ms以上再释放相当于强制DHT11软复位。我把这个逻辑整合进读取函数第一次失败后延时100ms重新发一次起始信号再读。连续失败3次才算真正的错误。用这个策略之后单次干扰导致的偶发失败基本都自动恢复了。另外DHT11的“小数位为0”这件事在显示层要处理得舒服一些。打印温湿度的时候很多教程直接用printf拼接整数和小数结果小数位永远是0看着很尴尬。我通常只打印整数或者用四舍五入把小数位的0处理成不显示。最后再分享一个个人体会如果你调DHT11已经超过半天还没调通先别急着改代码拿示波器或者逻辑分析仪看一遍波形绝大多数问题在波形图上一目了然。对着波形改参数比盲试快得多。这也是为什么我后来无论调什么单总线器件都会养成“先看波形、再改代码”的习惯。你可以把这个思路用在后续的DHT22、DS18B20甚至一些国产温湿度传感器上一通百通。