1. 为什么选单总线 DHT11项目思路与方案选型1.1 单总线到底是什么一根线的约定先聊一个容易被忽略的基础问题单总线1-Wire到底是什么。很多刚接触嵌入式的朋友看到“单总线”三个字就发怵觉得它不如 UART、SPI、I2C 那么“正规”。其实它的核心思想特别朴素所有通信只有一根数据线没有独立的时钟线。数据要发的时候主机把这根线拉低一段时间再释放通过拉低和释放的电平变化以及电平持续时间的长短把一个一个的 0 和 1 传出去。用人话说单总线就像一条小巷子里只有一个路灯。谁要说话谁先把灯拉灭再让它亮起来。听的人不看灯亮不亮而是看灯亮了多久亮的时间短代表“0”亮得久代表“1”。这种约定一旦定下来一根线就能完成半双工通信缺点是速度不可能快好处是极其省引脚。一个单片机引脚不够用的时候单总线简直就是救命稻草——最少只用一根 GPIO 就能挂一个传感器。DHT11 温湿度传感器就是这类通信方式的典型代表它常被叫作单总线器件。严格讲DHT11 使用的并不是 Dallas 那套标准 1-Wire 协议而是基于类似思想的自定义时序。数据线和时钟线合并在一起主机发起通信从机被动应答通信双方完全靠微秒级的时间差来传递信息。理解这一点你后面看时序图就不会被“1-Wire”和“单总线”这两个词搞混了。1.2 为什么拿 DHT11 练手最合适如果我只有一次机会帮新手入门“协议类通信”我大概率会推荐 DHT11而不是 DS18B20更不是那些 I2C 的传感器。原因很简单DHT11 是一个把“理想难度”和“实际成本”平衡得非常好的器件。首先是便宜。一块钱的量级坏了不心疼可以随便折腾。其次是协议复杂度适中一次通信就 40 位数据没有寄存器读写、没有地址寻址就是最纯粹的“时序”。它逼着你去关注微秒级的延时、电平翻转、采样窗口这些底层细节但又不会复杂到让你一头扎进数据手册出不来。可以说学会了 DHT11你再去看 DS18B20、OLED 屏这类器件会发现很多底层逻辑是相通的——无非是把“读脉冲宽度”这件事换成“读数据位”。另外一个很实际的原因是DHT11 出现在课设、比赛、智能家居项目里的频率非常高。温湿度采集几乎是所有环境监测类项目的标配。把它调通你手里就多了一块可以反复复用的“积木”。这次我把它完整拆开讲从原理到协议到代码一条线走到底就是为了让你能彻底吃透而不是对着别人的代码改来改去却不知道为什么能跑。1.3 和 I2C、SPI、UART 的区别好钢用在刀刃上很多人会问既然单总线这么麻烦为什么不用 I2C 呢这里要分清场景。单总线最大的优势就是引脚少但它不是万能的。我做了个表把常用通信方式放在一起看就明白了。通信方式最少引脚是否有独立时钟典型速度是否支持多设备寻址应用场景UART2TX/RX无靠波特率约定常见 9600~115200一般点对点调试串口、蓝牙模块I2C2SCL/SDA有100k/400k支持按地址寻址存储器、传感器、OLEDSPI4SCK/MOSI/MISO/CS有最高几十 MHz靠片选区分Flash、SD卡、高速外设单总线1无靠时序约定低速视协议而定温湿度采集、低成本传感器从表里能看出来单总线适合的是“引脚非常紧张、对速度没有要求、每次通信数据量又不大”的场景。一个单片机可能只剩下一个空闲引脚但你还想读取温湿度这时候单总线就是最合适的方案。反过来如果你要驱动一个大容量的外部 Flash就别自讨苦吃用单总线了老老实实上 SPI。选型思路上我多说一句方案没有绝对的好坏只有适不适合当前的环境。DHT11 本身的精度不高但它便宜、简单、稳定适合做“有没有大致温湿度数据”这种需求。如果项目对精度要求很高或者读取频率很高那应该直接换 DHT22AM2302或者 SHT30 这种 I2C 传感器而不是在 DHT11 上死磕。2. DHT11 器件原理数据手册里没讲的细节2.1 引脚定义与硬件连接上拉电阻不是可选项DHT11 常见的封装有 3 脚和 4 脚两种。标准 4 脚封装中1 脚接电源VCC3.3V~5.5V 均可2 脚是数据线DATA3 脚悬空NC4 脚接地GND。需要注意的是部分国产贴片封装引脚顺序会有差异接线之前一定要看丝印或者卖家提供的规格书不要想当然。硬件连接上有一个被很多人忽略的关键点DATA 线必须接一个上拉电阻到 VCC典型值是 4.7kΩ。为什么必须接因为单总线通信时总线空闲状态是高电平。主机和从机释放总线之后靠上拉电阻把电平抬回高电平。如果没有这个电阻总线会处于一种漂移状态电平不确定读出来的数据自然全是乱的。我实测过在短距离10cm以内和供电稳定的情况下用单片机内部上拉有时也能工作但一旦线长超过 20cm或者环境里有电机、继电器这类干扰源数据就容易出错。所以上拉电阻一定要加在外面别指望内部上拉能扛住所有场景。供电方面建议在 VCC 和 GND 之间加一个 100nF 的去耦电容靠近传感器引脚放置。这一步在很多开发板上看不到但在批量生产或工业现场非常关键。它能滤掉电源上的高频噪声让传感器内部的时序判断更稳定。2.2 数据格式40 位如何排列DHT11 每次完整通信会返回 40 位数据排列顺序是固定的8 位湿度整数数据8 位湿度小数数据8 位温度整数数据8 位温度小数数据8 位校验和数据从高位开始发送也就是 MSB first。举个例子如果湿度整数部分是 45%RH那这 8 位就是 00101101发送时先发最左边的 0最后发最右边的 1。这个顺序在代码组装字节时特别容易搞反我见过不少人把数据拼反了读出来的数值对不上其实问题就在位移方向。湿度小数部分和温度小数部分DHT11 本身的分辨率只有 1℃ 和 1%RH所以大多数情况下小数部分读出来是 0。但代码里依然要保留这两个字段一是协议格式如此二是有些改良版的 DHT11比如标注 0.1℃ 分辨率的确实会输出小数位提前写好解析逻辑换传感器的时候不用改代码。校验和的计算方式也很朴素前四个字节相加取低 8 位结果应该等于校验字节。比如湿度整数 45、湿度小数 0、温度整数 26、温度小数 0那校验字节就应该是 45 0 26 0 71。如果计算出来不一致说明这次通信的数据不可信应该丢弃等下一次读取。这个校验并不复杂但非常有用强烈建议在代码里实现不要偷懒跳过。2.3 时序协议完整拆解一次通信的四个阶段DHT11 的一次完整通信可以拆成四个阶段每个阶段都有明确的电平状态和持续时间。把这张时序图画在脑子里代码就是照着它一句一句写出来的。第一阶段主机发送起始信号。主机先把总线拉低至少保持 18ms推荐 18~20ms。这个低电平相当于拍一拍 DHT11 的肩膀告诉它我要读数了你准备一下。这里要注意起始信号不能太短短于 15ms 时 DHT11 很可能不响应但也不能太长过长没有意义反而会占用宝贵的时间片。所以代码里一般直接用 20ms 这个值稳妥省事。第二阶段DHT11 响应。DHT11 检测到起始信号后会先拉低总线 80us再释放总线让上拉电阻把电平拉高 80us。用生活化的话说低 80us 是“我收到你的信号了”高 80us 是“我马上要开始发数据了你准备好”。主机在这个阶段只需要等待先等着电平变低再等着电平变高两个 80us 都顺利通过说明通信链路是通的。第三阶段数据发送。DHT11 开始发送 40 位数据每一位的格式都是“50us 低电平 不定长的高电平”。每一位开始的时候DHT11 先把总线拉低 50us然后用高电平的持续时间来表示 0 还是 1高电平持续 26~28us 表示“0”高电平持续约 70us 表示“1”。主机要做的就是不断测量高电平持续了多久超过某个阈值就判定为 1否则判定为 0。第四阶段结束。40 位数据发送完毕后DHT11 会把总线拉低 50us然后彻底释放总线总线恢复高电平。之后 DHT11 进入休眠状态等下一次主机发起起始信号。整个过程从起始信号到结束大约只需要 4ms 左右如果算上起始信号的低电平时间就是 18ms对于慢速采集场景来说非常快。2.4 时序参数量化分析为什么延迟必须准为了方便写代码我把 DHT11 的关键时序参数整理成一张速查表。这张表建议收藏调试的时候随时翻出来对照。参数说明典型值允许范围起始信号低电平时间主机拉低总线20ms18ms~30ms响应低电平时间DHT11 拉低80us54us~80us响应高电平时间DHT11 释放80us54us~80us数据位低电平时间每一位开始50us约 50us数据 0 的高电平时间表示逻辑 026~28us通常小于 40us数据 1 的高电平时间表示逻辑 170us通常大于 50us位间隔时间位与位之间无固定由低电平起始看这张表你会发现区分 0 和 1 的关键阈值大约在 40us 附近。高电平时间短于 40us 的是 0长于 40us 的是 1。这个 40us 的窗口看起来挺宽但实际上如果你的延时函数误差大或者读取过程中被中断打断就很容易误判。尤其是 0 的高电平只有 26us 左右你的代码如果在这里磨蹭太久还没等到采样点DHT11 就已经把总线拉低进入下一位了那读到的 0 就会变成 1数据自然全乱。所以写 DHT11 驱动的核心挑战不是“逻辑复杂”而是“时序敏感”。理解了这一点你就知道为什么很多代码里读一位数据时没有用死板的固定延时而是用 while 循环配合超时保护去测量脉宽——这是更鲁棒的做法。3. 代码实现全拆解从 GPIO 到数据校验3.1 准备工作GPIO 模式切换与精确微秒延时DHT11 的单总线是双向的同一个引脚既要输出主机发起始信号又要输入读取 DHT11 的电平变化。所以代码的第一步是把一个引脚在输出模式和输入模式之间切换。以 STM32 HAL 库为例我通常这样配置#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_PIN_0 void DHT11_Pin_Output(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); } void DHT11_Pin_Input(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); }有两点我要特别说明。第一输出模式配置为推挽输出拉低时能强驱动保证电平稳定。第二切换到输入模式时打开内部上拉这样即使外部上拉电阻焊接不良代码初期调试时也能有一个兜底。不过正式产品里一定还是外部 4.7kΩ 上拉最靠谱。真正麻烦的是微秒级延时。HAL_Delay 只能精确到毫秒而 DHT11 的时序是几十微秒的量级根本不能用。我提供一个基于 DWT 的精确延时方案在 Cortex-M3/M4/M7 上都能用static void delay_us(uint32_t us) { uint32_t tick DWT-CYCCNT; uint32_t ticks us * (HAL_RCC_GetHCLKFreq() / 1000000); while ((DWT-CYCCNT - tick) ticks); }使用前需要初始化 DWTCoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;这个方案的精髓是利用 CPU 的周期计数器不依赖中断也不受系统调度影响。如果你的平台是 51 单片机那更简单直接根据晶振频率用空循环算延时比如 12MHz 晶振下一个 for 循环跑几次大约就是 1us需要自己拿示波器或者逻辑分析仪校准。3.2 起始信号的产生与响应判断起始信号是主机主动拉低总线所以此时引脚必须是输出模式。我习惯把发送起始和检测响应封装成一个函数返回 1 表示 DHT11 正常应答返回 0 表示通信失败。uint8_t DHT11_Start(void) { uint8_t response 0; uint16_t timeout; DHT11_Pin_Output(); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_RESET); delay_us(20000); // 拉低 20ms必须大于 18ms HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET); delay_us(30); // 释放总线等 30us 左右 DHT11_Pin_Input(); // 检测 DHT11 拉低 80us timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 0; } // 检测 DHT11 拉高 80us timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { if (--timeout 0) return 0; } response 1; return response; }这里有个细节值得多说两句。第一个 while 循环等待的是 DHT11 拉低的响应信号它后面跟的第二个 while 循环等待的是高电平结束。在第二个循环里我没用固定的 delay_us(80)而是不断读取引脚电平直到它变低。这种“轮询等待”的好处是不依赖 DHT11 响应时间是否精确它早 5us 晚 5us 我都能接住。代价是循环里不能触发中断或者调度器切换否则时机就跑了。后面我会专门讲 RTOS 环境下的坑。超时保护是必须的。如果 DHT11 没接好、坏了、或者供电不足它根本不会拉低总线那 while 循环就会变成一个死循环把整个程序卡死。加一个计数器每次循环递减到 0 直接退出这个习惯我在所有时序驱动里都用。3.3 位读取的关键如何在几十微秒内准确采样读一位是整个驱动里最考验功力的地方。很多新手代码喜欢用固定延时采样像这样先等待 50us 低电平结束然后延时 40us再读引脚如果还是高就判为 1否则判为 0。这个方法在低主频单片机上偶尔能跑但可靠性不足因为 40us 这个采样点非常容易受中断影响。更稳的做法是直接测量高电平的宽度。逻辑是这样的DHT11 的每一位都以一个 50us 低电平开始然后进入高电平。我们要等低电平结束进入高电平的那一刻开始计时一直数到高电平结束引脚变低统计高电平持续了多少个微秒。如果持续时间超过 40us那就是 1如果不到 40us那就是 0。uint8_t DHT11_ReadBit(void) { uint16_t width 0; uint16_t timeout 200; // 等待低电平结束 while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 0xFF; } // 测量高电平宽度 timeout 200; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { delay_us(1); width; if (--timeout 0) return 0xFF; } return (width 40) ? 1 : 0; }用测量脉宽的方式容错能力远高于固定延时采样。即使 DHT11 的时序有 ±10us 的偏差只要阈值选在 40us都能正确区分 0 和 1。我还加了一个超时保护如果宽度计数超过 200us说明通信已经彻底错乱直接返回一个特殊值 0xFF让上层函数识别到错误。这段代码里我用了 delay_us(1)也就是每秒进行 100 万次计数的节奏。如果你的平台延时函数精度不够可以用一个空循环代替但一定要先校准。我见过有人拿毫秒级延时来跑这段代码结果读出来的全是 1因为宽度计数被放大了。这个问题在 4.2 节会再详细说。3.4 数据组装与校验40 个 bit 如何变成温湿度有了 ReadBit 函数读 40 位数据就很简单了。我用一个结构体来封装结果避免用全局变量到处传代码更干净。typedef struct { uint8_t humidity_int; uint8_t humidity_dec; uint8_t temp_int; uint8_t temp_dec; uint8_t checksum; uint8_t valid; } DHT11_Data; DHT11_Data DHT11_ReadData(void) { DHT11_Data data {0}; uint8_t buffer[40]; uint8_t bytes[5] {0}; uint8_t i, j; for (i 0; i 40; i) { buffer[i] DHT11_ReadBit(); if (buffer[i] 0xFF) { data.valid 0; return data; } } // 把 40 个 bit 拼成 5 个字节MSB first for (i 0; i 5; i) { for (j 0; j 8; j) { bytes[i] (bytes[i] 1) | buffer[i * 8 j]; } } // 校验前四个字节相加的低 8 位等于校验字节 if (((uint8_t)(bytes[0] bytes[1] bytes[2] bytes[3])) bytes[4]) { data.humidity_int bytes[0]; data.humidity_dec bytes[1]; data.temp_int bytes[2]; data.temp_dec bytes[3]; data.checksum bytes[4]; data.valid 1; } else { data.valid 0; } return data; }这里要注意 C 语言的类型隐式转换问题。bytes[0] 到 bytes[3] 都是 uint8_t四个相加的结果在 int 类型下不会溢出但最高位可能超出 8 位范围所以我们显式转成 uint8_t 再比较确保只取低 8 位。拼接字节时我采用了最直观的双循环写法。外循环 i 控制字节序号内循环 j 控制位序号每次把当前字节左移一位再把新读取的 bit 拼到最低位。这个写法对新手非常友好不需要用位域或者联合体。如果你对位操作很熟也可以直接用 64 位整数来接但可读性不如这个版本。在业务代码里拿到数据后可以这样用DHT11_Data dht11 DHT11_ReadData(); if (dht11.valid) { float humidity dht11.humidity_int dht11.humidity_dec * 0.1f; float temperature dht11.temp_int dht11.temp_dec * 0.1f; printf(Humidity: %.1f%%RH, Temperature: %.1fC\n, humidity, temperature); }虽然 DHT11 的小数部分大多为 0但这样写代码以后换 DHT22 之类的传感器时读取逻辑不需要大改。3.5 完整可运行的驱动代码与 51 移植要点把上面的函数拼到一起就是一套完整的 DHT11 驱动。我习惯于把所有内容放在 dht11.c 和 dht11.h 两个文件里外部只需要暴露一个 DHT11_ReadData 函数。这样在多个项目间复用非常方便。51 单片机的移植是一个高频需求毕竟课设里用 STC89C52 的人太多了。51 是准双向 IO不需要像 STM32 那样切换输入输出模式直接用一个位定义就能操作sbit DHT11 P1^0;拉低总线就是 DHT11 0释放总线就是 DHT11 1读引脚就是直接读 DHT11 的值。但 51 的延时函数要特别小心不同晶振11.0592MHz、12MHz和不同单片机1T、12T都会导致空循环的周期数不同。我调试时一般先用示波器看波形确认延时函数的实际时间再去调 DHT11 的时序。没示波器的话方法也简单把延时函数空循环一万次用秒表测一下大概多久再反推单次循环的时间。另外要说一个很多人踩过的坑51 的引脚内部没有上拉或者上拉能力很弱如果不加外部 4.7kΩ 上拉电阻DHT11 的数据线很可能没法恢复到高电平。这个问题在 STM32 上不明显因为内部上拉可以用但在 51 上基本是硬伤。所以无论是哪种平台我都建议把外部上拉电阻当作必选项。4. 常见问题与排查技巧实录4.1 读出来的数据全是 0 或固定值最先排查什么这个问题我在群里被问过不下几十次。先说结论读出来全是 0绝大多数时候不是代码写错了而是硬件链路有问题。遇到这种情况我建议按照下面的顺序逐项排查。第一步检查接线。DHT11 的 VCC、GND、DATA 三根线是不是接对了4 脚封装的第三脚 NC 有没有误接到地万用表量一下 VCC 和 GND 之间的电压是不是正常的 3.3V 或 5V。第二步检查上拉电阻。DATA 线上有没有接 4.7kΩ 到 VCC我接过一个项目采购的人把上拉电阻买成了 470Ω结果总线根本拉不低数据也是乱的。第三步检查起始信号。用示波器或者逻辑分析仪看主机拉低的时长是否超过 18ms如果代码里延时不对或者因为别的原因导致拉低时间不足DHT11 根本不会应答。排除了硬件问题再看看代码。最容易犯的错误是读取完起始信号后忘了把引脚模式从输出切换回输入。这种情况在 STM32 上特别常见输出模式下读取引脚是无效的永远是低电平或者高电平数据自然不对。我写代码时严格要求顺序输出模式发起始信号释放后马上切输入模式再开始读。还有一个隐蔽的错误是 DHT11 引脚和别的外设复用了。很多开发板的引脚有多个功能比如 PA0 既接了 DHT11 又接了按键按键按下时把电平拉低了DHT11 的通信时序直接被打乱。排查时先把所有共用引脚的设备断开单独测试能省很多时间。4.2 校验总是失败重点检查采样时序如果 DHT11 能响应读到的位也能拼接成字节但校验和经常对不上那问题就出在时序采样上和硬件关系不大。我总结下来主要有三个原因。第一延时函数不精确。有人用 HAL_Delay(1) 来实现微秒延时这是致命的。HAL_Delay 底层依赖 SysTick最小单位是 1ms在等待数据位高电平宽度时把 1ms 当成 1us 来计数那所有的 width 都会偏大几百倍0 和 1 直接被全判成 1。第二读取过程中被中断打断。微控制器里的定时器中断、串口中断如果优先级高于当前读取代码就可能插入到 50us 的位时序中间把时序彻底搞乱。解决方法是读取 DHT11 期间关闭中断读完再打开。裸机环境下用 __disable_irq() 和 __enable_irq()RTOS 环境下需要进临界区。第三时钟频率配置不一致。用 DWT 延时函数时如果 HAL_RCC_GetHCLKFreq() 返回的时钟频率和实际跑的不一致延时会成比例地偏大或偏小。我实际调试中遇到最诡异的一个案例是开启编译器优化后代码从 -O0 改成 -O2校验就开始失败。原因是编译器把延时函数里的循环优化掉了延时时间大幅缩短。解决办法有两个把关键延时函数用 volatile 修饰或者直接通过修改编译选项让延时函数所在的文件保持低优化等级。这个问题在开发阶段很难察觉因为调试模式下默认是 -O0一切正常一发布就崩。如果你也遇到“调试好好的release 就不行”的情况优先检查这里。4.3 数值总是不变化间隔时间没控制好DHT11 有一个 1 秒级别的采样周期。也就是说即便你每 100ms 读一次传感器内部的温湿度数据也不会更新它大概每 1 秒才做一次新的测量。因此两次读取操作之间建议至少间隔 1 秒。如果间隔太短DHT11 可能还在上一次通信的“冷却期”你的起始信号发过去它根本不响应或者返回的是旧数据。这个问题在代码层面很好解决在调用 DHT11_ReadData() 之前确保距上次读取超过 1 秒。如果你的系统里有一个 100ms 周期的心跳定时器那就做个节流每 10 个周期读取一次。这样做的另一个好处是降低 CPU 占用因为单总线通信时 CPU 是全程阻塞的。如果排除间隔问题数据依然长时间不变那就要怀疑是不是自恢复的线路问题。把传感器拿起来用手焐热或者对它哈一口气观察数据是否变化。如果毫无变化可能是传感器本身坏了或者焊点虚焊。DHT11 内部是一个感湿电阻加一个 NTC 热敏电阻外壳被树脂封装如果封装破损进水读数也会异常。4.4 干扰环境下的偶发失败如何加固工业现场、电机旁边、变频器附近DHT11 的偶发读取失败会明显增加。这主要是因为单总线缺少差分传输和错误重传机制电平本来就容易受干扰。我给出几个加固手段按性价比排序。第一个手段是缩短引线。DHT11 的数据线尽量控制在 20cm 以内如果非要延长用屏蔽双绞线屏蔽层单端接地。第二个手段是调整上拉电阻。干扰严重时把 4.7kΩ 换成 3.3kΩ下拉能力增强总线抗干扰能力会好一些但代价是上升沿变缓如果电阻太小小于 1kΩDHT11 可能拉不动总线反而适得其反。第三个手段是软件层面增加重试机制。读取失败或校验失败后延时 100ms 再试一次连续重试 3 次绝大多数偶发错误都能被过滤掉。我把这个逻辑封装在业务层驱动层保持单纯这样职责更清晰。我见过一些产品为了解决干扰问题加了一堆滤波电容但效果很一般因为电容会把信号边沿弄圆反而影响时序判断。在 DATA 线上加一个小电容几十 pF可以滤掉高频毛刺但超过 100pF 就会吞掉有效沿得不偿失。想用硬件滤波的话更推荐加一个施密特触发器缓冲器比如 74HC14但这个方案会增加成本和面积一般的消费类产品不会这么干。总体来说先软件重试再处理硬件是性价比最高的路线。5. 进阶思考DHT11 到底靠不靠谱什么时候该换它5.1 DHT11 和 DS18B20 的本质区别很多人在项目里纠结温湿度传感器是选 DHT11 还是 DS18B20其实这两个不是同类产品。DS18B20 只测温度但它支持标准的 1-Wire 协议允许一条总线上挂多个 DS18B20每个器件有一个 64 位 ROM 序列号主机通过序列号寻址。而 DHT11 测的是温湿度但它的单总线并不支持多设备寻址一条总线上只能挂一个 DHT11。这个区别在协议实现上的体现是DS18B20 的通信流程比 DHT11 复杂得多有初始化、ROM 命令、功能命令等多个环节还要处理 CRC 校验和 64 位 ID。如果你只是想学“单总线”这个知识点DHT11 是入门DS18B20 是进阶。如果项目要同时测多个点的温度那 DS18B20 是更合适的选择。至于湿度DS18B20 是无能为力的只能靠 DHT11、DHT22 或者 I2C 接口的 SHT30。我在实际项目中经常这么搭配用一颗 DHT11 采集环境温湿度用于显示和控制用多颗 DS18B20 做多点温度监测比如大棚里的土壤温度、水箱温度等。两种器件都用单总线驱动代码的思路一致但一个是读固定帧一个是读寄存器理解它们的差异能避免很多设计上的弯路。5.2 RTOS 环境下的单总线通信雷区如果你在 FreeRTOS 里创建了一个任务任务里直接调用阻塞式的 DHT11 驱动你大概率会遇到一个诡异的现象系统跑着跑着DHT11 偶尔就读不到数据或者校验失败但单独跑裸机程序时一切正常。原因我在 4.2 节提过DHT11 的位时序是微秒级的而 RTOS 的调度器会按时间片切换任务。当你的读取任务正在 while 循环里等高电平结束的时候调度器突然切换到另一个任务过了几十微秒再切回来这时候 DHT11 的位已经发完了你读到的电平状态自然就错位了。解决办法有几种。最简单的方案在读取 DHT11 期间关闭调度器也就是挂起所有任务只让当前任务独占 CPU。在 FreeRTOS 里用 taskENTER_CRITICAL() 和 taskEXIT_CRITICAL()但要小心临界区代码不能太长DHT11 一次完整读取大约 20ms临界区开 20ms 对整个系统的实时性影响很大如果系统里还有电机控制、通信任务很容易出问题。所以我一般建议把 DHT11 的读取放在一个独立任务里这个任务的优先级最高读取期间临时关闭调度读完立刻恢复同时把系统里其他高实时性任务的时间片错开。另一个更高级的方案是用定时器的输入捕获功能来测量脉冲宽度完全不由 CPU 阻塞等待这样即使被调度器切换也不会丢失数据。这个方案代码复杂度高一些但稳定性最好适合对数据可靠性要求高的产品。5.3 什么时候该换更高级的传感器DHT11 最大的短板是精度和响应速度。温度精度只有 ±2℃湿度精度更是达到 ±5%RH在实验室和医疗场景完全不够看。如果你做的是高精度环境监测或者需要快速响应湿度变化比如培养箱、干燥箱控制建议直接上 DHT22AM2302它的湿度和温度精度都比 DHT11 高一个档次但价格也只贵几块钱。再往上走SHT30 这种 I2C 接口传感器精度、稳定性和一致性都更好驱动也简单适合产品化。但话说回来选 DHT11 不代表“低端”或者“落后”。很多智能家居的场景比如室内温湿度显示、衣柜除湿提醒、鱼缸水温监测DHT11 的精度完全够用。它便宜到可以对每个房间、每个设备角落都布置一个成本和功耗优势非常明显。项目选型时先明确需求再谈参数这才是工程思维。这轮把 DHT11 从原理到代码完整过了一遍过程中反复验证的一件事是嵌入式开发里真正难的从来不是语法和框架而是那些藏在时序里的微秒细节。DHT11 虽然简单但它逼着你去理解“为什么延时必须准”“为什么总线需要上拉”“为什么中断会破坏通信”这些底层认知是任何一门编程课都给不了你的。我最初调 DHT11 时卡了整整一下午最后用逻辑分析仪抓波形才发现是起始信号拉低时间不够从那之后我就养成了“先看波形、再看代码”的习惯。如果你手上正好有逻辑分析仪或者示波器这一步真的能帮你省下大把排查时间。
单总线通信与DHT11温湿度传感器实战：从时序到代码全解析
1. 为什么选单总线 DHT11项目思路与方案选型1.1 单总线到底是什么一根线的约定先聊一个容易被忽略的基础问题单总线1-Wire到底是什么。很多刚接触嵌入式的朋友看到“单总线”三个字就发怵觉得它不如 UART、SPI、I2C 那么“正规”。其实它的核心思想特别朴素所有通信只有一根数据线没有独立的时钟线。数据要发的时候主机把这根线拉低一段时间再释放通过拉低和释放的电平变化以及电平持续时间的长短把一个一个的 0 和 1 传出去。用人话说单总线就像一条小巷子里只有一个路灯。谁要说话谁先把灯拉灭再让它亮起来。听的人不看灯亮不亮而是看灯亮了多久亮的时间短代表“0”亮得久代表“1”。这种约定一旦定下来一根线就能完成半双工通信缺点是速度不可能快好处是极其省引脚。一个单片机引脚不够用的时候单总线简直就是救命稻草——最少只用一根 GPIO 就能挂一个传感器。DHT11 温湿度传感器就是这类通信方式的典型代表它常被叫作单总线器件。严格讲DHT11 使用的并不是 Dallas 那套标准 1-Wire 协议而是基于类似思想的自定义时序。数据线和时钟线合并在一起主机发起通信从机被动应答通信双方完全靠微秒级的时间差来传递信息。理解这一点你后面看时序图就不会被“1-Wire”和“单总线”这两个词搞混了。1.2 为什么拿 DHT11 练手最合适如果我只有一次机会帮新手入门“协议类通信”我大概率会推荐 DHT11而不是 DS18B20更不是那些 I2C 的传感器。原因很简单DHT11 是一个把“理想难度”和“实际成本”平衡得非常好的器件。首先是便宜。一块钱的量级坏了不心疼可以随便折腾。其次是协议复杂度适中一次通信就 40 位数据没有寄存器读写、没有地址寻址就是最纯粹的“时序”。它逼着你去关注微秒级的延时、电平翻转、采样窗口这些底层细节但又不会复杂到让你一头扎进数据手册出不来。可以说学会了 DHT11你再去看 DS18B20、OLED 屏这类器件会发现很多底层逻辑是相通的——无非是把“读脉冲宽度”这件事换成“读数据位”。另外一个很实际的原因是DHT11 出现在课设、比赛、智能家居项目里的频率非常高。温湿度采集几乎是所有环境监测类项目的标配。把它调通你手里就多了一块可以反复复用的“积木”。这次我把它完整拆开讲从原理到协议到代码一条线走到底就是为了让你能彻底吃透而不是对着别人的代码改来改去却不知道为什么能跑。1.3 和 I2C、SPI、UART 的区别好钢用在刀刃上很多人会问既然单总线这么麻烦为什么不用 I2C 呢这里要分清场景。单总线最大的优势就是引脚少但它不是万能的。我做了个表把常用通信方式放在一起看就明白了。通信方式最少引脚是否有独立时钟典型速度是否支持多设备寻址应用场景UART2TX/RX无靠波特率约定常见 9600~115200一般点对点调试串口、蓝牙模块I2C2SCL/SDA有100k/400k支持按地址寻址存储器、传感器、OLEDSPI4SCK/MOSI/MISO/CS有最高几十 MHz靠片选区分Flash、SD卡、高速外设单总线1无靠时序约定低速视协议而定温湿度采集、低成本传感器从表里能看出来单总线适合的是“引脚非常紧张、对速度没有要求、每次通信数据量又不大”的场景。一个单片机可能只剩下一个空闲引脚但你还想读取温湿度这时候单总线就是最合适的方案。反过来如果你要驱动一个大容量的外部 Flash就别自讨苦吃用单总线了老老实实上 SPI。选型思路上我多说一句方案没有绝对的好坏只有适不适合当前的环境。DHT11 本身的精度不高但它便宜、简单、稳定适合做“有没有大致温湿度数据”这种需求。如果项目对精度要求很高或者读取频率很高那应该直接换 DHT22AM2302或者 SHT30 这种 I2C 传感器而不是在 DHT11 上死磕。2. DHT11 器件原理数据手册里没讲的细节2.1 引脚定义与硬件连接上拉电阻不是可选项DHT11 常见的封装有 3 脚和 4 脚两种。标准 4 脚封装中1 脚接电源VCC3.3V~5.5V 均可2 脚是数据线DATA3 脚悬空NC4 脚接地GND。需要注意的是部分国产贴片封装引脚顺序会有差异接线之前一定要看丝印或者卖家提供的规格书不要想当然。硬件连接上有一个被很多人忽略的关键点DATA 线必须接一个上拉电阻到 VCC典型值是 4.7kΩ。为什么必须接因为单总线通信时总线空闲状态是高电平。主机和从机释放总线之后靠上拉电阻把电平抬回高电平。如果没有这个电阻总线会处于一种漂移状态电平不确定读出来的数据自然全是乱的。我实测过在短距离10cm以内和供电稳定的情况下用单片机内部上拉有时也能工作但一旦线长超过 20cm或者环境里有电机、继电器这类干扰源数据就容易出错。所以上拉电阻一定要加在外面别指望内部上拉能扛住所有场景。供电方面建议在 VCC 和 GND 之间加一个 100nF 的去耦电容靠近传感器引脚放置。这一步在很多开发板上看不到但在批量生产或工业现场非常关键。它能滤掉电源上的高频噪声让传感器内部的时序判断更稳定。2.2 数据格式40 位如何排列DHT11 每次完整通信会返回 40 位数据排列顺序是固定的8 位湿度整数数据8 位湿度小数数据8 位温度整数数据8 位温度小数数据8 位校验和数据从高位开始发送也就是 MSB first。举个例子如果湿度整数部分是 45%RH那这 8 位就是 00101101发送时先发最左边的 0最后发最右边的 1。这个顺序在代码组装字节时特别容易搞反我见过不少人把数据拼反了读出来的数值对不上其实问题就在位移方向。湿度小数部分和温度小数部分DHT11 本身的分辨率只有 1℃ 和 1%RH所以大多数情况下小数部分读出来是 0。但代码里依然要保留这两个字段一是协议格式如此二是有些改良版的 DHT11比如标注 0.1℃ 分辨率的确实会输出小数位提前写好解析逻辑换传感器的时候不用改代码。校验和的计算方式也很朴素前四个字节相加取低 8 位结果应该等于校验字节。比如湿度整数 45、湿度小数 0、温度整数 26、温度小数 0那校验字节就应该是 45 0 26 0 71。如果计算出来不一致说明这次通信的数据不可信应该丢弃等下一次读取。这个校验并不复杂但非常有用强烈建议在代码里实现不要偷懒跳过。2.3 时序协议完整拆解一次通信的四个阶段DHT11 的一次完整通信可以拆成四个阶段每个阶段都有明确的电平状态和持续时间。把这张时序图画在脑子里代码就是照着它一句一句写出来的。第一阶段主机发送起始信号。主机先把总线拉低至少保持 18ms推荐 18~20ms。这个低电平相当于拍一拍 DHT11 的肩膀告诉它我要读数了你准备一下。这里要注意起始信号不能太短短于 15ms 时 DHT11 很可能不响应但也不能太长过长没有意义反而会占用宝贵的时间片。所以代码里一般直接用 20ms 这个值稳妥省事。第二阶段DHT11 响应。DHT11 检测到起始信号后会先拉低总线 80us再释放总线让上拉电阻把电平拉高 80us。用生活化的话说低 80us 是“我收到你的信号了”高 80us 是“我马上要开始发数据了你准备好”。主机在这个阶段只需要等待先等着电平变低再等着电平变高两个 80us 都顺利通过说明通信链路是通的。第三阶段数据发送。DHT11 开始发送 40 位数据每一位的格式都是“50us 低电平 不定长的高电平”。每一位开始的时候DHT11 先把总线拉低 50us然后用高电平的持续时间来表示 0 还是 1高电平持续 26~28us 表示“0”高电平持续约 70us 表示“1”。主机要做的就是不断测量高电平持续了多久超过某个阈值就判定为 1否则判定为 0。第四阶段结束。40 位数据发送完毕后DHT11 会把总线拉低 50us然后彻底释放总线总线恢复高电平。之后 DHT11 进入休眠状态等下一次主机发起起始信号。整个过程从起始信号到结束大约只需要 4ms 左右如果算上起始信号的低电平时间就是 18ms对于慢速采集场景来说非常快。2.4 时序参数量化分析为什么延迟必须准为了方便写代码我把 DHT11 的关键时序参数整理成一张速查表。这张表建议收藏调试的时候随时翻出来对照。参数说明典型值允许范围起始信号低电平时间主机拉低总线20ms18ms~30ms响应低电平时间DHT11 拉低80us54us~80us响应高电平时间DHT11 释放80us54us~80us数据位低电平时间每一位开始50us约 50us数据 0 的高电平时间表示逻辑 026~28us通常小于 40us数据 1 的高电平时间表示逻辑 170us通常大于 50us位间隔时间位与位之间无固定由低电平起始看这张表你会发现区分 0 和 1 的关键阈值大约在 40us 附近。高电平时间短于 40us 的是 0长于 40us 的是 1。这个 40us 的窗口看起来挺宽但实际上如果你的延时函数误差大或者读取过程中被中断打断就很容易误判。尤其是 0 的高电平只有 26us 左右你的代码如果在这里磨蹭太久还没等到采样点DHT11 就已经把总线拉低进入下一位了那读到的 0 就会变成 1数据自然全乱。所以写 DHT11 驱动的核心挑战不是“逻辑复杂”而是“时序敏感”。理解了这一点你就知道为什么很多代码里读一位数据时没有用死板的固定延时而是用 while 循环配合超时保护去测量脉宽——这是更鲁棒的做法。3. 代码实现全拆解从 GPIO 到数据校验3.1 准备工作GPIO 模式切换与精确微秒延时DHT11 的单总线是双向的同一个引脚既要输出主机发起始信号又要输入读取 DHT11 的电平变化。所以代码的第一步是把一个引脚在输出模式和输入模式之间切换。以 STM32 HAL 库为例我通常这样配置#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_PIN_0 void DHT11_Pin_Output(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); } void DHT11_Pin_Input(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); }有两点我要特别说明。第一输出模式配置为推挽输出拉低时能强驱动保证电平稳定。第二切换到输入模式时打开内部上拉这样即使外部上拉电阻焊接不良代码初期调试时也能有一个兜底。不过正式产品里一定还是外部 4.7kΩ 上拉最靠谱。真正麻烦的是微秒级延时。HAL_Delay 只能精确到毫秒而 DHT11 的时序是几十微秒的量级根本不能用。我提供一个基于 DWT 的精确延时方案在 Cortex-M3/M4/M7 上都能用static void delay_us(uint32_t us) { uint32_t tick DWT-CYCCNT; uint32_t ticks us * (HAL_RCC_GetHCLKFreq() / 1000000); while ((DWT-CYCCNT - tick) ticks); }使用前需要初始化 DWTCoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;这个方案的精髓是利用 CPU 的周期计数器不依赖中断也不受系统调度影响。如果你的平台是 51 单片机那更简单直接根据晶振频率用空循环算延时比如 12MHz 晶振下一个 for 循环跑几次大约就是 1us需要自己拿示波器或者逻辑分析仪校准。3.2 起始信号的产生与响应判断起始信号是主机主动拉低总线所以此时引脚必须是输出模式。我习惯把发送起始和检测响应封装成一个函数返回 1 表示 DHT11 正常应答返回 0 表示通信失败。uint8_t DHT11_Start(void) { uint8_t response 0; uint16_t timeout; DHT11_Pin_Output(); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_RESET); delay_us(20000); // 拉低 20ms必须大于 18ms HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET); delay_us(30); // 释放总线等 30us 左右 DHT11_Pin_Input(); // 检测 DHT11 拉低 80us timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 0; } // 检测 DHT11 拉高 80us timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { if (--timeout 0) return 0; } response 1; return response; }这里有个细节值得多说两句。第一个 while 循环等待的是 DHT11 拉低的响应信号它后面跟的第二个 while 循环等待的是高电平结束。在第二个循环里我没用固定的 delay_us(80)而是不断读取引脚电平直到它变低。这种“轮询等待”的好处是不依赖 DHT11 响应时间是否精确它早 5us 晚 5us 我都能接住。代价是循环里不能触发中断或者调度器切换否则时机就跑了。后面我会专门讲 RTOS 环境下的坑。超时保护是必须的。如果 DHT11 没接好、坏了、或者供电不足它根本不会拉低总线那 while 循环就会变成一个死循环把整个程序卡死。加一个计数器每次循环递减到 0 直接退出这个习惯我在所有时序驱动里都用。3.3 位读取的关键如何在几十微秒内准确采样读一位是整个驱动里最考验功力的地方。很多新手代码喜欢用固定延时采样像这样先等待 50us 低电平结束然后延时 40us再读引脚如果还是高就判为 1否则判为 0。这个方法在低主频单片机上偶尔能跑但可靠性不足因为 40us 这个采样点非常容易受中断影响。更稳的做法是直接测量高电平的宽度。逻辑是这样的DHT11 的每一位都以一个 50us 低电平开始然后进入高电平。我们要等低电平结束进入高电平的那一刻开始计时一直数到高电平结束引脚变低统计高电平持续了多少个微秒。如果持续时间超过 40us那就是 1如果不到 40us那就是 0。uint8_t DHT11_ReadBit(void) { uint16_t width 0; uint16_t timeout 200; // 等待低电平结束 while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 0xFF; } // 测量高电平宽度 timeout 200; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { delay_us(1); width; if (--timeout 0) return 0xFF; } return (width 40) ? 1 : 0; }用测量脉宽的方式容错能力远高于固定延时采样。即使 DHT11 的时序有 ±10us 的偏差只要阈值选在 40us都能正确区分 0 和 1。我还加了一个超时保护如果宽度计数超过 200us说明通信已经彻底错乱直接返回一个特殊值 0xFF让上层函数识别到错误。这段代码里我用了 delay_us(1)也就是每秒进行 100 万次计数的节奏。如果你的平台延时函数精度不够可以用一个空循环代替但一定要先校准。我见过有人拿毫秒级延时来跑这段代码结果读出来的全是 1因为宽度计数被放大了。这个问题在 4.2 节会再详细说。3.4 数据组装与校验40 个 bit 如何变成温湿度有了 ReadBit 函数读 40 位数据就很简单了。我用一个结构体来封装结果避免用全局变量到处传代码更干净。typedef struct { uint8_t humidity_int; uint8_t humidity_dec; uint8_t temp_int; uint8_t temp_dec; uint8_t checksum; uint8_t valid; } DHT11_Data; DHT11_Data DHT11_ReadData(void) { DHT11_Data data {0}; uint8_t buffer[40]; uint8_t bytes[5] {0}; uint8_t i, j; for (i 0; i 40; i) { buffer[i] DHT11_ReadBit(); if (buffer[i] 0xFF) { data.valid 0; return data; } } // 把 40 个 bit 拼成 5 个字节MSB first for (i 0; i 5; i) { for (j 0; j 8; j) { bytes[i] (bytes[i] 1) | buffer[i * 8 j]; } } // 校验前四个字节相加的低 8 位等于校验字节 if (((uint8_t)(bytes[0] bytes[1] bytes[2] bytes[3])) bytes[4]) { data.humidity_int bytes[0]; data.humidity_dec bytes[1]; data.temp_int bytes[2]; data.temp_dec bytes[3]; data.checksum bytes[4]; data.valid 1; } else { data.valid 0; } return data; }这里要注意 C 语言的类型隐式转换问题。bytes[0] 到 bytes[3] 都是 uint8_t四个相加的结果在 int 类型下不会溢出但最高位可能超出 8 位范围所以我们显式转成 uint8_t 再比较确保只取低 8 位。拼接字节时我采用了最直观的双循环写法。外循环 i 控制字节序号内循环 j 控制位序号每次把当前字节左移一位再把新读取的 bit 拼到最低位。这个写法对新手非常友好不需要用位域或者联合体。如果你对位操作很熟也可以直接用 64 位整数来接但可读性不如这个版本。在业务代码里拿到数据后可以这样用DHT11_Data dht11 DHT11_ReadData(); if (dht11.valid) { float humidity dht11.humidity_int dht11.humidity_dec * 0.1f; float temperature dht11.temp_int dht11.temp_dec * 0.1f; printf(Humidity: %.1f%%RH, Temperature: %.1fC\n, humidity, temperature); }虽然 DHT11 的小数部分大多为 0但这样写代码以后换 DHT22 之类的传感器时读取逻辑不需要大改。3.5 完整可运行的驱动代码与 51 移植要点把上面的函数拼到一起就是一套完整的 DHT11 驱动。我习惯于把所有内容放在 dht11.c 和 dht11.h 两个文件里外部只需要暴露一个 DHT11_ReadData 函数。这样在多个项目间复用非常方便。51 单片机的移植是一个高频需求毕竟课设里用 STC89C52 的人太多了。51 是准双向 IO不需要像 STM32 那样切换输入输出模式直接用一个位定义就能操作sbit DHT11 P1^0;拉低总线就是 DHT11 0释放总线就是 DHT11 1读引脚就是直接读 DHT11 的值。但 51 的延时函数要特别小心不同晶振11.0592MHz、12MHz和不同单片机1T、12T都会导致空循环的周期数不同。我调试时一般先用示波器看波形确认延时函数的实际时间再去调 DHT11 的时序。没示波器的话方法也简单把延时函数空循环一万次用秒表测一下大概多久再反推单次循环的时间。另外要说一个很多人踩过的坑51 的引脚内部没有上拉或者上拉能力很弱如果不加外部 4.7kΩ 上拉电阻DHT11 的数据线很可能没法恢复到高电平。这个问题在 STM32 上不明显因为内部上拉可以用但在 51 上基本是硬伤。所以无论是哪种平台我都建议把外部上拉电阻当作必选项。4. 常见问题与排查技巧实录4.1 读出来的数据全是 0 或固定值最先排查什么这个问题我在群里被问过不下几十次。先说结论读出来全是 0绝大多数时候不是代码写错了而是硬件链路有问题。遇到这种情况我建议按照下面的顺序逐项排查。第一步检查接线。DHT11 的 VCC、GND、DATA 三根线是不是接对了4 脚封装的第三脚 NC 有没有误接到地万用表量一下 VCC 和 GND 之间的电压是不是正常的 3.3V 或 5V。第二步检查上拉电阻。DATA 线上有没有接 4.7kΩ 到 VCC我接过一个项目采购的人把上拉电阻买成了 470Ω结果总线根本拉不低数据也是乱的。第三步检查起始信号。用示波器或者逻辑分析仪看主机拉低的时长是否超过 18ms如果代码里延时不对或者因为别的原因导致拉低时间不足DHT11 根本不会应答。排除了硬件问题再看看代码。最容易犯的错误是读取完起始信号后忘了把引脚模式从输出切换回输入。这种情况在 STM32 上特别常见输出模式下读取引脚是无效的永远是低电平或者高电平数据自然不对。我写代码时严格要求顺序输出模式发起始信号释放后马上切输入模式再开始读。还有一个隐蔽的错误是 DHT11 引脚和别的外设复用了。很多开发板的引脚有多个功能比如 PA0 既接了 DHT11 又接了按键按键按下时把电平拉低了DHT11 的通信时序直接被打乱。排查时先把所有共用引脚的设备断开单独测试能省很多时间。4.2 校验总是失败重点检查采样时序如果 DHT11 能响应读到的位也能拼接成字节但校验和经常对不上那问题就出在时序采样上和硬件关系不大。我总结下来主要有三个原因。第一延时函数不精确。有人用 HAL_Delay(1) 来实现微秒延时这是致命的。HAL_Delay 底层依赖 SysTick最小单位是 1ms在等待数据位高电平宽度时把 1ms 当成 1us 来计数那所有的 width 都会偏大几百倍0 和 1 直接被全判成 1。第二读取过程中被中断打断。微控制器里的定时器中断、串口中断如果优先级高于当前读取代码就可能插入到 50us 的位时序中间把时序彻底搞乱。解决方法是读取 DHT11 期间关闭中断读完再打开。裸机环境下用 __disable_irq() 和 __enable_irq()RTOS 环境下需要进临界区。第三时钟频率配置不一致。用 DWT 延时函数时如果 HAL_RCC_GetHCLKFreq() 返回的时钟频率和实际跑的不一致延时会成比例地偏大或偏小。我实际调试中遇到最诡异的一个案例是开启编译器优化后代码从 -O0 改成 -O2校验就开始失败。原因是编译器把延时函数里的循环优化掉了延时时间大幅缩短。解决办法有两个把关键延时函数用 volatile 修饰或者直接通过修改编译选项让延时函数所在的文件保持低优化等级。这个问题在开发阶段很难察觉因为调试模式下默认是 -O0一切正常一发布就崩。如果你也遇到“调试好好的release 就不行”的情况优先检查这里。4.3 数值总是不变化间隔时间没控制好DHT11 有一个 1 秒级别的采样周期。也就是说即便你每 100ms 读一次传感器内部的温湿度数据也不会更新它大概每 1 秒才做一次新的测量。因此两次读取操作之间建议至少间隔 1 秒。如果间隔太短DHT11 可能还在上一次通信的“冷却期”你的起始信号发过去它根本不响应或者返回的是旧数据。这个问题在代码层面很好解决在调用 DHT11_ReadData() 之前确保距上次读取超过 1 秒。如果你的系统里有一个 100ms 周期的心跳定时器那就做个节流每 10 个周期读取一次。这样做的另一个好处是降低 CPU 占用因为单总线通信时 CPU 是全程阻塞的。如果排除间隔问题数据依然长时间不变那就要怀疑是不是自恢复的线路问题。把传感器拿起来用手焐热或者对它哈一口气观察数据是否变化。如果毫无变化可能是传感器本身坏了或者焊点虚焊。DHT11 内部是一个感湿电阻加一个 NTC 热敏电阻外壳被树脂封装如果封装破损进水读数也会异常。4.4 干扰环境下的偶发失败如何加固工业现场、电机旁边、变频器附近DHT11 的偶发读取失败会明显增加。这主要是因为单总线缺少差分传输和错误重传机制电平本来就容易受干扰。我给出几个加固手段按性价比排序。第一个手段是缩短引线。DHT11 的数据线尽量控制在 20cm 以内如果非要延长用屏蔽双绞线屏蔽层单端接地。第二个手段是调整上拉电阻。干扰严重时把 4.7kΩ 换成 3.3kΩ下拉能力增强总线抗干扰能力会好一些但代价是上升沿变缓如果电阻太小小于 1kΩDHT11 可能拉不动总线反而适得其反。第三个手段是软件层面增加重试机制。读取失败或校验失败后延时 100ms 再试一次连续重试 3 次绝大多数偶发错误都能被过滤掉。我把这个逻辑封装在业务层驱动层保持单纯这样职责更清晰。我见过一些产品为了解决干扰问题加了一堆滤波电容但效果很一般因为电容会把信号边沿弄圆反而影响时序判断。在 DATA 线上加一个小电容几十 pF可以滤掉高频毛刺但超过 100pF 就会吞掉有效沿得不偿失。想用硬件滤波的话更推荐加一个施密特触发器缓冲器比如 74HC14但这个方案会增加成本和面积一般的消费类产品不会这么干。总体来说先软件重试再处理硬件是性价比最高的路线。5. 进阶思考DHT11 到底靠不靠谱什么时候该换它5.1 DHT11 和 DS18B20 的本质区别很多人在项目里纠结温湿度传感器是选 DHT11 还是 DS18B20其实这两个不是同类产品。DS18B20 只测温度但它支持标准的 1-Wire 协议允许一条总线上挂多个 DS18B20每个器件有一个 64 位 ROM 序列号主机通过序列号寻址。而 DHT11 测的是温湿度但它的单总线并不支持多设备寻址一条总线上只能挂一个 DHT11。这个区别在协议实现上的体现是DS18B20 的通信流程比 DHT11 复杂得多有初始化、ROM 命令、功能命令等多个环节还要处理 CRC 校验和 64 位 ID。如果你只是想学“单总线”这个知识点DHT11 是入门DS18B20 是进阶。如果项目要同时测多个点的温度那 DS18B20 是更合适的选择。至于湿度DS18B20 是无能为力的只能靠 DHT11、DHT22 或者 I2C 接口的 SHT30。我在实际项目中经常这么搭配用一颗 DHT11 采集环境温湿度用于显示和控制用多颗 DS18B20 做多点温度监测比如大棚里的土壤温度、水箱温度等。两种器件都用单总线驱动代码的思路一致但一个是读固定帧一个是读寄存器理解它们的差异能避免很多设计上的弯路。5.2 RTOS 环境下的单总线通信雷区如果你在 FreeRTOS 里创建了一个任务任务里直接调用阻塞式的 DHT11 驱动你大概率会遇到一个诡异的现象系统跑着跑着DHT11 偶尔就读不到数据或者校验失败但单独跑裸机程序时一切正常。原因我在 4.2 节提过DHT11 的位时序是微秒级的而 RTOS 的调度器会按时间片切换任务。当你的读取任务正在 while 循环里等高电平结束的时候调度器突然切换到另一个任务过了几十微秒再切回来这时候 DHT11 的位已经发完了你读到的电平状态自然就错位了。解决办法有几种。最简单的方案在读取 DHT11 期间关闭调度器也就是挂起所有任务只让当前任务独占 CPU。在 FreeRTOS 里用 taskENTER_CRITICAL() 和 taskEXIT_CRITICAL()但要小心临界区代码不能太长DHT11 一次完整读取大约 20ms临界区开 20ms 对整个系统的实时性影响很大如果系统里还有电机控制、通信任务很容易出问题。所以我一般建议把 DHT11 的读取放在一个独立任务里这个任务的优先级最高读取期间临时关闭调度读完立刻恢复同时把系统里其他高实时性任务的时间片错开。另一个更高级的方案是用定时器的输入捕获功能来测量脉冲宽度完全不由 CPU 阻塞等待这样即使被调度器切换也不会丢失数据。这个方案代码复杂度高一些但稳定性最好适合对数据可靠性要求高的产品。5.3 什么时候该换更高级的传感器DHT11 最大的短板是精度和响应速度。温度精度只有 ±2℃湿度精度更是达到 ±5%RH在实验室和医疗场景完全不够看。如果你做的是高精度环境监测或者需要快速响应湿度变化比如培养箱、干燥箱控制建议直接上 DHT22AM2302它的湿度和温度精度都比 DHT11 高一个档次但价格也只贵几块钱。再往上走SHT30 这种 I2C 接口传感器精度、稳定性和一致性都更好驱动也简单适合产品化。但话说回来选 DHT11 不代表“低端”或者“落后”。很多智能家居的场景比如室内温湿度显示、衣柜除湿提醒、鱼缸水温监测DHT11 的精度完全够用。它便宜到可以对每个房间、每个设备角落都布置一个成本和功耗优势非常明显。项目选型时先明确需求再谈参数这才是工程思维。这轮把 DHT11 从原理到代码完整过了一遍过程中反复验证的一件事是嵌入式开发里真正难的从来不是语法和框架而是那些藏在时序里的微秒细节。DHT11 虽然简单但它逼着你去理解“为什么延时必须准”“为什么总线需要上拉”“为什么中断会破坏通信”这些底层认知是任何一门编程课都给不了你的。我最初调 DHT11 时卡了整整一下午最后用逻辑分析仪抓波形才发现是起始信号拉低时间不够从那之后我就养成了“先看波形、再看代码”的习惯。如果你手上正好有逻辑分析仪或者示波器这一步真的能帮你省下大把排查时间。
