简介面向STM32入门开发者这份压缩包提供基于STM32CubeMX配置STM32F103ZET6驱动DHT11温湿度传感器的完整工程解决单总线传感器时序调试难、工程搭建繁琐的问题。包含源码、CubeMX配置文件、编译中间文件及烧录固件可直接打开工程对照学习。资源共974个文件以C源文件与H头文件为主同时包含汇编文件、链接脚本、静态库和HEX文件包体仅12.28MB结构紧凑便于快速获取与复用。已有6779人浏览学习适合希望掌握单总线通信时序、GPIO与定时器配置的读者。通过阅读驱动代码和工程配置可清晰理解DHT11启动信号、应答与40位数据读取的完整流程从系统时钟设置到上拉GPIO输入模式及定时器时序控制一应俱全为后续物联网环境监测项目打下扎实基础。1. DHT11为什么到现在还是入门首选说实话一提起DHT11很多老工程师第一反应是这玩意儿精度不行早该淘汰了。这句话对也不对。DHT11的温度精度是±2℃湿度精度是±5%RH确实比不过SHT30、AHT20这些新一代数字传感器但这颗看起来落后的芯片在入门市场至今无人能撼动原因就三条便宜、好买、资料多。一块DHT11模块的价格通常在一两块钱散件甚至几毛钱。坏了不心疼焊错了也不心疼这在学习阶段是很大的心理优势。更关键的是它用的是单总线协议整个通信过程只占用一根GPIO引脚不需要I2C或者SPI外设对刚接触STM32的开发者来说恰好是用GPIO模拟复杂时序的最佳练习素材。但单总线这三个字也是很多人的噩梦。因为DHT11不像I2C那样有SCL时钟信号同步所有时序完全靠高低电平的持续时间来约定微秒级的时间误差就会导致读出来的数据全是0xFF或者干脆通信失败。尤其从标准库过渡到HAL库之后很多人发现原来在标准库下跑得好好的代码搬到HAL库里突然不工作了原因就是HAL_GPIO_WritePin这种函数封装层级太多GPIO翻转速度跟不上DHT11的时序要求。这篇文章我基于STM32CubeMX HAL库把DHT11从协议到驱动完整走一遍重点讲清楚那些你照着例程抄都可能踩坑的细节。适合刚学会CubeMX建工程、想接第一个真实传感器的朋友也适合被DHT11时序折磨过、想搞清楚根因的开发者。2. 单总线通信到底在传什么2.1 从一次完整通信的流程说起DHT11的总线协议其实不复杂一次完整的数据交换分三个阶段主机发起起始信号、DHT11响应、DHT11连续返回40位数据。先看主机侧。总线空闲时保持高电平。主机想读取数据时先把总线拉低这个低电平必须持续至少18ms通常我们做20ms然后释放总线拉高拉高后等待20~40us就开始监听总线状态。接下来是DHT11的响应。它会在总线释放后等待一小会然后先把总线拉低80us再拉高80us这个低-高组合就是响应信号意思是我准备好了准备接收数据。很多人在这一步栽跟头因为响应信号的高电平持续80us非常关键如果没读到或者读到的时长不对后面一切白搭。响应信号之后紧接着就是40位数据位。每一位数据的传输都以50us低电平作为前导前导结束后拉高高电平持续的时间长短决定这一位是0还是1高电平持续26~28us表示0高电平持续70us表示1。注意这个高电平时间是有内在逻辑的它表示的是前导低电平之后、下一位开始之前的空闲时间长短所以读数据的时候要抓住低电平开始这个时刻来计时而不是高电平开始。2.2 40位数据怎么拆分和校验DHT11一次返回40位数据按顺序依次是湿度整数部分8位、湿度小数部分8位、温度整数部分8位、温度小数部分8位、校验和8位。传输顺序是高字节在前也就是先传最高有效位。校验和算法非常简单就是前四个字节相加取低8位看是否等于第五个字节。例如读到的数据是湿度整数20、湿度小数0、温度整数26、温度小数0那么校验和就是 20 0 26 0 46如果第五个字节是46说明通信正常。实测中最常见的错误就是校验和不匹配这种时候千万别用这帧数据直接丢弃等下一次读取就行。2.3 为什么时序参数这么苛刻我在这里放一张常用时序参数表方便对照写代码信号方向持续时间说明起始信号低电平主机→传感器≥18ms建议20ms确保传感器能识别起始信号后拉高主机→传感器20~40us随后释放总线切输入模式响应信号低电平传感器→主机80us传感器准备完成标志响应信号高电平传感器→主机80us随后开始传数据数据位前导低电平传感器→主机50us每一位都一样数据位高电平(0)传感器→主机26~28us表示逻辑0数据位高电平(1)传感器→主机70us表示逻辑1读取间隔主机≥1sDHT11内部采样周期限制DHT11的时序窗口其实还算宽松的不像DS18B20那样严格但宽松是相对而言。用HAL库的时候如果直接调用HAL_GPIO_ReadPin去轮询读取每一位每个循环里几十次函数调用下来时序早就飘了。所以驱动DHT11的核心矛盾不是不会写时序而是代码效率跟不上时序。3. CubeMX配置阶段最容易忽略的四个设定CubeMX配置DHT11工程的步骤不多绝大多数教程也都说了选MCU、配时钟、配GPIO、生成代码。但我在辅导别人调这个模块时发现问题往往出在几个看起来不重要的配置项上。3.1 时钟树别让SysTick和DWT打架很多人新建工程后时钟配置就跳过了直接用默认的HSI 16MHz。DHT11驱动代码理论上是能在16MHz下跑的但微秒级延时函数的实现方式会受影响。如果你打算用DWTData Watchpoint and Trace来做微秒延时——我强烈推荐这种方案后面会细说——最好配好时钟后再确认一下DWT的时钟源。以STM32F103为例我习惯用8MHz外部晶振作为HSEPLL倍频到72MHz系统主频。步骤如下RCC里选择HSE把PLL的M、N、P配成8MHz进去、72MHz出来确保APB1和APB2总线时钟也确认一遍方便后面挂串口。如果你的板子上没有外部晶振用HSI也是可以的但要心里有数HSI的精度不如HSE对DHT11这种时序敏感型传感器误差会叠加在微秒延时上。3.2 GPIO模式推挽还是开漏这是个问题GPIO的Mode设置是CubeMX配置里的第一个坑。DHT11模块通常板上自带上拉电阻所以很多人直接选推挽输出Push-Pull这在大多数情况没问题。但如果你用的是裸传感器自己搭电路就必须在数据线上外接一个4.7k~10k的上拉电阻到VCC然后把GPIO配置为开漏输出Open-Drain。为什么因为开漏输出模式本身只能拉低、不能主动拉高拉高靠外部上拉电阻完成。这就天然符合单总线线与的逻辑主机和传感器谁都能拉低总线释放后总线自动恢复高电平不会出现推挽模式下主机输出高电平、传感器也输出低电平导致的短路风险。我的习惯是无论模块还是裸传感器GPIO一律配成开漏输出引脚上拉到3.3V最稳妥。这里还要特别注意引脚标签命名CubeMX里给GPIO起的标签比如DHT11_DATA在代码里会生成对应的宏定义命名清晰能省很多事。3.3 串口调试的眼睛必须有DHT11调不通的时候你总不能拿示波器去每根引脚上戳。串口打印是最实用的调试手段。CubeMX里把USART1打开模式选Asynchronous波特率设115200其他参数默认生成代码后重定向printf到串口就能把原始数据、校验结果、错误码打出来。我调试DHT11时日志里一定有三样东西40位原始数据、解析后的温度和湿度、校验结果。光看最终温度湿度没意义因为如果是0xFF或者校验失败你得知道数据是在哪一步坏掉的。3.4 定时器可以不用但不能没有思想准备严格来说DHT11驱动不需要配置定时器因为最理想的微秒延时方案是DWT而不是定时器。但如果你不想折腾DWT或者你的MCU型号比较特殊用TIM定时器来做微秒延时也是常见方案。CubeMX里开一个TIM设置时钟源为内部时钟预分频和自动重载值算好让它产生1MHz的计数频率然后通过读取CNT寄存器来实现微秒延时。注意一个细节如果用了定时器方案延时函数里不要调用HAL_Delay()因为HAL_Delay是基于SysTick的优先级和中断行为跟定时器完全不同混用会引入不可控的误差。CubeMX配置到这里就结束了生成代码之前再检查一下Project Manager里的编译器版本和固件包版本避免HAL库版本不一致带来的接口差异——这个问题在HAL库从1.11.x升级到1.12.x之后尤其明显。4. 驱动代码实现从GPIO模拟到稳定读取4.1 微秒延时DWT方案详解先解决最关键的基础设施——微秒延时。HAL_Delay只支持毫秒级DHT11时序里到处是几十微秒的等待必须自己写。最简单粗暴的方式是空循环延时比如void delay_us(uint32_t us) { uint32_t ticks us * (SystemCoreClock / 1000000U) / 4U; while (ticks--) { __NOP(); } }这种写法能用但坑非常大编译器优化等级不同循环耗时完全不同开启Cache或者流水线紧张的MCU上误差可能达到30%以上。我调试过很多案例最后发现数据不稳定一查是空循环延时在-O2优化下比-O0快了近一倍时序窗口全乱了。所以强烈建议用DWT实现DWT是Cortex-M3/M4内核自带的外设精度高、不受中断影响启用方式也简单。补全后的代码如下static void DWT_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; DWT-CYCCNT 0; } static void delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000U); while ((DWT-CYCCNT - start) ticks); }注意DWT-CYCCNT是32位计数器减法是自动处理溢出的所以不用担心计数器翻转。这份代码在F1、F4、G0、L4系列上我都验证过稳定可靠。4.2 总线读写基础函数有了可靠的微秒延时接下来封装最底层的三个函数拉低总线、拉高总线、读取总线电平。核心逻辑是主机发完起始信号后必须把GPIO从输出模式切换到输入模式否则没法读取传感器返回的数据。HAL库里面GPIO模式切换需要用HAL_GPIO_Init()重新初始化这个函数开销很大每次都调用会导致时序浪费几百纳秒甚至几微秒。推荐的替代方案是直接操作寄存器#define DHT11_GPIO_PORT GPIOB #define DHT11_GPIO_PIN GPIO_PIN_0 static void DHT11_SetOutputMode(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_OD; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); } static void DHT11_SetInputMode(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); }HAL_GPIO_Init虽然慢但只在模式切换的瞬间调用一次不影响后续每一位数据的读取——因为数据位的读取全部发生在输入模式下不需要切换。这是很多人写驱动时最容易犯的错误每读一位就去切换一次模式把性能完全浪费掉了。4.3 起始信号和响应检测下面实现DHT11主机起始信号发送和响应检测。这里的核心逻辑写在注释里每一段等待都要用前面的delay_usuint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t data[5] {0}; // 1. 主机拉低总线持续20ms DHT11_SetOutputMode(); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_RESET); HAL_Delay(20); // 2. 释放总线等待传感器响应 HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET); delay_us(30); // 3. 切换输入模式检测响应信号 DHT11_SetInputMode(); // 等待低电平响应信号超时100us则失败 uint32_t timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { if (--timeout 0) return 1; // 错误无响应 delay_us(1); } // 等待高电平响应信号超时100us则失败 timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 2; // 错误响应信号异常 delay_us(1); } // 等待低电平数据位前导开始超时100us则失败 timeout 100; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { if (--timeout 0) return 3; // 错误响应后未进入数据位 delay_us(1); } // 4. 循环读取40位数据 for (int i 0; i 40; i) { // 等待低电平结束前导50us timeout 60; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET) { if (--timeout 0) return 4; delay_us(1); } // 延时40us后采样高电平持续超过40us即为1否则为0 delay_us(40); if (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { data[i / 8] | (1 (7 - (i % 8))); } // 等待当前位高电平结束 timeout 80; while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { if (--timeout 0) return 5; delay_us(1); } } // 5. 校验和验证 if ((data[0] data[1] data[2] data[3]) data[4]) { *humidity data[0]; *temperature data[2]; return 0; } return 6; // 错误校验和失败 }4.4 主循环里怎么调用最后是主循环的调用逻辑这里有个容易忽略的点DHT11两次读取间隔必须超过1秒否则传感器内部采样还没完成返回的数据会是上一次的旧数据。这个间隔是DHT11的硬件特性不是代码能绕过去的while (1) { uint8_t humi 0, temp 0; uint8_t status DHT11_ReadData(humi, temp); if (status 0) { printf(湿度: %d%%RH, 温度: %d℃\n, humi, temp); } else { printf(读取失败, 错误码: %d\n, status); } HAL_Delay(1500); }5. 实测中的四个坑和对应优化5.1 模块电压和信号电平的匹配问题DHT11传感器本身的工作电压是3.3V~5.5V但市面上大量模块在5V供电时数据引脚输出的高电平也接近5V。如果你的STM32是3.3V供电直接接到GPIO上运气好没事但长期工作会有风险。我见过不少板子烧GPIO的案例根源都是传感器模块和MCU电平不匹配。最稳妥的做法是模块用3.3V供电。DHT11在3.3V下精度会略微下降手册上标注的精度是在5V供电条件下测得的但对日常环境监测来说误差还在可接受范围内。如果必须5V供电数据线上要加分压电阻。最简单是两个电阻分压串联10k和6.8k中间抽头接MCU引脚把5V分到3.3V左右。5.2 环境干扰导致的随机校验失败DHT11的数据线走线过长、靠近电机或者继电器这些感性负载时数据极易被干扰。我调试过一个项目传感器和主控板之间用杜邦线连了30厘米结果每隔几次读取就校验失败一次。解决办法有两个方向一是把杜邦线换成屏蔽线或者双绞线二是通信时软件加一个简单的中值滤波——连续读三次取温度和湿度的中间值。滤波代码很简单uint8_t FilterRead(uint8_t *h_med, uint8_t *t_med) { uint8_t h[3], t[3], status; uint8_t count 0; while (count 3) { status DHT11_ReadData(h[count], t[count]); if (status 0) count; else HAL_Delay(100); } // 简单冒泡取中间值 // 这里省略具体排序代码 *h_med h[1]; *t_med t[1]; return 0; }5.3 中断和RTOS环境下的时序保护如果工程里开了定时器中断、串口中断甚至跑了FreeRTOSDHT11的通信过程很可能被高优先级中断打断。一旦时序被拉开轻则这一帧数据校验失败重则通信完全卡死。最简单的保护方式在DHT11_ReadData最前面关中断读完之后再开uint8_t DHT11_ReadData_Protected(uint8_t *humidity, uint8_t *temperature) { uint8_t status; __disable_irq(); status DHT11_ReadData(humidity, temperature); __enable_irq(); return status; }注意DHT11_ReadData内部有HAL_Delay(20)的起始信号延时关中断期间20ms内所有中断都会被挂起。如果系统对中断实时性要求很高这种粗暴方式就不合适了。更好的方案是把DHT11读取放到一个单独的低优先级任务里并且用互斥锁防止多个任务同时调用。5.4 读取失败后的恢复策略DHT11有个不太友好的特性如果通信中途异常中断它内部状态机可能卡住导致下一次通信彻底无响应。我遇到过一次代码在读取过程中检测到超时比如错误码4返回主循环后立即再次调用读取函数结果连续失败十几次最后只能断电重启。后来我学乖了任何一次读取失败后强制等待200ms再发起下一次读取给传感器足够时间恢复内部状态。如果连续失败超过5次就把GPIO重新初始化为输出模式拉高、拉低几次人工复位一下总线状态再继续读。这个策略实测非常有效基本能解决99%的卡死问题。6. 从DHT11起步但不要止步于DHT11把DHT11稳定跑通意味着你已经掌握了单总线协议、GPIO模拟时序、微秒级延时、数据校验这几项嵌入式开发的核心基本功。调试这个模块的过程远比模块本身有价值。当你彻底理解了单总线协议后回头再看DS18B20、甚至自己用GPIO模拟一个低速的I2C主机都会觉得豁然开朗。我在实际开发中发现DHT11的驱动架构完全可以抽出来复用只需要改底层拉高拉低的函数和延时参数就能驱动其他单总线芯片。后面如果精度不够用可以平滑升级到DHT22AM2302它的协议和DHT11几乎完全一样只是数据格式变成了16位精度时序参数需要微调。也可以在CubeMX里配置一个I2C外设接入SHT30或AHT20这类芯片走标准I2C协议代码逻辑更规范但通过自己的努力用GPIO掐着微秒把数据读出来的那种成就感是I2C给不了的。最后分享一个从实践中总结的小技巧调试DHT11千万不要闷头改代码把串口日志充分利用起来每次通信失败把错误码和原始40位数据都打印出来。错误码集中在哪个阶段、数据当时长什么样往往一眼就能看出是时序问题还是电气问题。这套调试方法论比任何现成驱动都值钱。本文还有配套的精品资源点击获取