1. 项目概述：从国赛真题到实战技能
最近几年，蓝桥杯嵌入式国赛的赛题越来越“接地气”，从早期的跑马灯、数码管，逐渐过渡到各种常用传感器的综合应用。其中，DHT11温湿度传感器几乎成了国赛的“常客”。很多初次备赛的同学，拿到题目一看，原理图上有DHT11，心里就有点发怵——这玩意儿时序要求严格，代码写起来容易出问题，一不留神就读不到数据，在争分夺秒的赛场上，这简直是“定时炸弹”。
我当年备赛和后来带学生参赛，在DHT11上栽过跟头，也总结出了一套稳定高效的驱动方法。今天，我就以蓝桥杯国赛为背景，抛开那些复杂的理论堆砌，直接聊聊怎么用STM32（特别是国赛常用的STM32G431或STM32F103系列）稳稳当当地把DHT11用起来。这不仅仅是完成一道赛题，更是掌握一种与单总线数字传感器打交道的核心方法，以后遇到DS18B20之类的传感器，你也能触类旁通。
简单说，DHT11是一个集成了温湿度传感和模数转换的复合传感器，它通过一根数据线（单总线）与单片机通信，输出已经校准好的数字信号。在国赛中，它通常被用于环境监测类题目，比如“智能农业监控”、“仓库环境监测”等，你需要做的就是编写驱动代码，准确读取温湿度的整数和小数部分，并可能需要在LCD屏上显示，或者通过串口上传。关键在于，你得理解它的“单总线”协议，并写出抗干扰能力强、容错性好的代码。
2. DHT11单总线通信协议深度解析
很多教程一上来就贴代码，但如果不把协议吃透，代码稍微改个地方或者换块板子就可能失灵。DHT11的通信协议是典型的单总线协议，所有数据交换都通过一根双向IO口线完成，这根线需要接一个4.7K-10K的上拉电阻。
2.1 通信流程与关键时序
一次完整的读取过程分为三个步骤：主机启动信号、传感器响应、数据传输。时序要求是微秒级的，这也是为什么很多人用软件延时容易出问题。
第一步：主机启动信号。单片机作为主机，需要先把数据线（假设是PA0）拉低至少18毫秒（ms），然后拉高20-40微秒（μs），随后释放总线，将引脚设置为输入模式，等待传感器响应。这个18ms的低电平是一个“复位”信号，告诉DHT11：“我要开始读数据了”。拉高20-40μs是给总线一个准备时间，然后主机就得赶紧“松手”（改为输入），等着传感器“说话”。
注意：这里的18ms是最小值。在国赛紧张环境下，为了保证可靠性，我通常会拉低25-30ms。但切记不要过长，超过一定时间可能被传感器视为异常。
第二步：传感器响应信号。DHT11检测到总线被拉低又拉高后，会先拉低总线80μs作为响应信号，接着再拉高80μs，表示即将开始传输数据。主机在发出启动信号并改为输入后，就要不断地检测这个引脚的电平变化。
这里有个关键点：如何检测这80μs的低电平响应？你不能用简单的while(PA0==0);然后死等，万一传感器故障不响应，程序就卡死了。正确的做法是使用带超时检测的循环。
第三步：数据传输。响应信号之后，传感器开始发送40位（5字节）数据。数据“0”和“1”的表示方式不同：
- 数据‘0’：一次50μs的低电平，接着一次26-28μs的高电平。
- 数据‘1’：一次50μs的低电平，接着一次70μs的高电平。
区别就在于高电平的持续时间。所以，解码的核心思路是：在检测到起始的50μs低电平后，延时一个很短的时间（比如40μs），再去检测引脚电平。如果此时为高，说明高电平持续时间长，是‘1’；如果为低，说明高电平持续时间短，已经结束了，是‘0’。
2.2 协议背后的硬件原理与软件实现要点
为什么时序这么苛刻？因为DHT11内部没有复杂的时钟系统，它依靠严格的延时来同步和编码数据。任何大的时序偏差都会导致解码错误。
在软件实现上，有几点至关重要：
- 关闭中断：在读取整个40位数据期间，最好关闭全局中断。因为中断服务程序可能会打断微秒级的延时，导致检测电平的时机错位。这是很多初学者忽略的“玄学”问题，明明代码逻辑对，就是偶尔读错。
- 精准的微秒级延时：不能使用
HAL_Delay()（它是毫秒级的）。必须使用系统滴答定时器（SysTick）或者通用定时器（TIM）来实现微秒延时函数。国赛提供的HAL库工程通常已经配置好了SysTick，我们可以基于HAL_GetTick()的微秒计数器，或者直接用定时器实现一个delay_us()函数。 - 超时机制：每一个等待传感器响应的环节（如等待80μs低电平响应结束、等待50μs数据低电平结束）都必须加入超时判断。例如，等待低电平变高时，循环检测的同时计数，如果超过一定时间（如150μs）仍为低，则判定为超时错误，本次读取失败。
3. 基于STM32 HAL库的驱动代码实战
理论懂了，我们来看代码。国赛环境一般是CubeMX生成HAL库代码。我们以PA0连接DHT11数据线为例。
3.1 硬件连接与CubeMX配置
首先，在CubeMX里：
- 将PA0配置为GPIO_Output（初始输出高电平），同时给它起个用户标签，比如
DHT11_IO。 - 在代码中，我们需要动态切换这个引脚的模式。所以我们会用到
HAL_GPIO_WritePin和HAL_GPIO_ReadPin，以及GPIO_InitTypeDef结构体来切换输入输出模式。
硬件上，记得在PA0和VCC（3.3V）之间接一个4.7K的上拉电阻。虽然STM32的IO可以配置内部上拉，但驱动能力通常较弱，为了确保总线电平稳定，强烈建议使用外部上拉电阻。
3.2 核心驱动函数编写
我们先实现一个微秒延时函数。假设系统主频是80MHz（如STM32G431），我们可以用SysTick或者一个简单的循环实现。这里用一个简单的循环示意（实际比赛时最好用定时器校准）：
// 微秒延时函数（需根据实际主频调整） void DHT11_Delay_us(uint16_t us) { uint32_t ticks = us * (SystemCoreClock / 1000000) / 5; // 粗略计算，需要校准 while(ticks--); }然后是引脚模式切换函数，这能提高代码可读性：
// 设置DHT11数据线为输出模式 void DHT11_IO_Out(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = DHT11_IO_Pin; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; // 推挽输出 GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(DHT11_IO_GPIO_Port, &GPIO_InitStruct); HAL_GPIO_WritePin(DHT11_IO_GPIO_Port, DHT11_IO_Pin, GPIO_PIN_SET); // 先拉高 } // 设置DHT11数据线为输入模式 void DHT11_IO_In(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = DHT11_IO_Pin; GPIO_InitStruct.Mode = GPIO_MODE_INPUT; // 浮空输入，依赖外部上拉 GPIO_InitStruct.Pull = GPIO_NOPULL; HAL_GPIO_Init(DHT11_IO_GPIO_Port, &GPIO_InitStruct); }接下来是最核心的读取函数。我将它分为几个部分，并加上详细注释：
// DHT11读取函数 // 成功返回0，失败返回1 // 温湿度值通过指针参数传出 uint8_t DHT11_Read_Data(uint8_t *temp, uint8_t *humi) { uint8_t data[5] = {0}; // 存放40位数据 uint8_t i, j; // 1. 主机发出起始信号 DHT11_IO_Out(); // 设置为输出 HAL_GPIO_WritePin(DHT11_IO_GPIO_Port, DHT11_IO_Pin, GPIO_PIN_RESET); // 拉低 DHT11_Delay_us(25000); // 拉低25ms，更保险 HAL_GPIO_WritePin(DHT11_IO_GPIO_Port, DHT11_IO_Pin, GPIO_PIN_SET); // 拉高 DHT11_Delay_us(30); // 拉高30us // 2. 主机释放总线，等待传感器响应 DHT11_IO_In(); // 设置为输入 // 等待DHT11拉低响应 (超时检测) i = 0; while(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_SET) { DHT11_Delay_us(1); i++; if(i > 100) return 1; // 超时约100us，返回错误 } // 等待DHT11低电平响应结束 (约80us) i = 0; while(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_RESET) { DHT11_Delay_us(1); i++; if(i > 100) return 1; // 超时 } // 等待DHT11高电平准备信号结束 (约80us) i = 0; while(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_SET) { DHT11_Delay_us(1); i++; if(i > 100) return 1; // 超时 } // 3. 开始接收40位数据 for(j=0; j<5; j++) // 5个字节 { for(i=0; i<8; i++) // 每个字节8位 { // 等待50us低电平开始位结束 while(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_RESET); // 延时40us，此时若为高电平，则是‘1’，否则是‘0’ DHT11_Delay_us(40); if(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_SET) { // 收到‘1’ data[j] |= (0x80 >> i); // 高位在前 // 等待本次位传输的高电平结束 while(HAL_GPIO_ReadPin(DHT11_IO_GPIO_Port, DHT11_IO_Pin) == GPIO_PIN_SET); } else { // 收到‘0’，无需额外操作 } } } // 4. 校验数据 // DHT11数据格式：湿度整数(1B) + 湿度小数(1B) + 温度整数(1B) + 温度小数(1B) + 校验和(1B) // 校验和 = 湿度整数 + 湿度小数 + 温度整数 + 温度小数 if(data[4] == (data[0] + data[1] + data[2] + data[3])) { *humi = data[0]; // 湿度整数部分 *temp = data[2]; // 温度整数部分 // 注意：DHT11小数部分通常为0，精度有限。DHT22的小数部分才有意义。 return 0; // 读取成功 } else { return 1; // 校验失败 } }3.3 主循环中的调用与显示
在main函数的循环中，不能频繁调用读取函数。DHT11两次读取之间需要至少2秒的间隔。通常我们会用定时器做一个1秒或2秒的定时，在定时中断标志里触发一次读取。
// 主循环或定时器中断服务函数中 if(read_flag == 1) // 每秒或每两秒置位一次 { read_flag = 0; if(DHT11_Read_Data(&temperature, &humidity) == 0) { // 读取成功，处理数据 // 例如：在LCD上显示 sprintf(display_buf, "Temp:%d C Humi:%d %%", temperature, humidity); LCD_DisplayStringLine(Line2, (uint8_t *)display_buf); // 或者通过串口打印，用于调试 printf("Temperature: %d C, Humidity: %d %%RH\r\n", temperature, humidity); } else { // 读取失败，可以显示错误信息或重试 LCD_DisplayStringLine(Line2, (uint8_t *)"DHT11 Error!"); } }4. 国赛实战中的调试技巧与避坑指南
代码写完了，不代表就能用了。在国赛现场那种紧张环境下，硬件可能不理想，环境可能有干扰。下面这些是我和学生们踩过坑后总结的“保命”技巧。
4.1 常见问题排查速查表
| 现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
| 始终返回错误/超时 | 1. 硬件连接错误（VCC/GND接反或接触不良） 2. 上拉电阻未接或阻值不对 3. 启动信号时序不对（低电平时间不足） 4. 引脚配置错误（未正确切换输入输出） | 1.万用表检查：先测VCC和GND电压是否为3.3V，再测数据线电压，空闲时应为高电平（约3.3V）。 2.示波器抓波形：这是最直接的方法。看主机启动信号（25ms低+30us高）是否规范，看传感器是否有80us低+80us高的响应。没有响应，检查硬件；响应波形畸变，检查电源和上拉。 3.简化代码测试：写一个最简单的程序，只发启动信号，然后用输入模式循环打印引脚电平，看传感器响应期间电平是否变化。 |
| 数据偶尔正确，经常出错 | 1. 延时函数不准确，受中断干扰 2. 未关闭全局中断 3. 电源噪声大，总线电平不稳定 4. 读取间隔太短（小于2秒） | 1.屏蔽中断：在DHT11_Read_Data函数开头用__disable_irq()关闭中断，函数返回前用__enable_irq()开启。2.校准延时：用逻辑分析仪或示波器测量你的 delay_us(40)实际是多少微秒，调整循环计数值，确保40us延时准确。3.加强电源滤波：在DHT11的VCC和GND之间并联一个100nF的瓷片电容，越靠近传感器引脚越好。 4.增加重试机制：连续读取3次，取两次相同的结果作为有效值。 |
| 校验和通过，但数值明显不对（如湿度255） | 1. 数据位解析逻辑错误（高位在前/低位在前弄反） 2. 判断‘0’和‘1’的延时点选择不当 | 1.检查数据解析：`data[j] |
| LCD显示正常，但串口打印乱码或无输出 | 1. 串口初始化或重定向printf有问题2. 在中断中调用了 printf等耗时函数，导致时序错乱 | 1.先确保串口基础功能正常：在主循环里定时发送一个固定字符串测试。 2.避免在读取时序关键代码中打印：将 printf语句移到数据读取并校验成功之后，最好在主循环里打印，而不是在DHT11_Read_Data函数内部。 |
4.2 现场调试的“笨”办法与“巧”心思
- “灯”是最好的调试工具：如果现场没有示波器，利用板载LED。在启动信号发出后、等待响应前，点亮一个LED；如果成功进入数据接收阶段，让LED闪烁；如果校验成功，再点亮另一个LED。通过LED的状态，可以快速定位问题发生在哪个阶段。
- 利用串口打印原始字节：在
DHT11_Read_Data函数中，将接收到的5个字节data[0]到data[4]的十六进制值通过串口打印出来。这样你可以直接看到校验和是否匹配，以及温湿度原始数据是什么，比看最终结果更直观。 - 预留测试引脚：在CubeMX配置时，可以多配置一个LED引脚和一个按键引脚。按键用来手动触发一次读取，LED用来指示状态。这在调试时比定时读取更方便。
- 理解“小数部分”：DHT11的数据手册写明，其小数部分通常为0。所以如果你读到的
data[1]（湿度小数）或data[3]（温度小数）不是0，很可能是读取错误，可以直接丢弃这次数据。国赛题目一般也只要求整数部分。
5. 从DHT11到更广阔的单总线世界
拿下DHT11，你掌握的不仅仅是一个传感器，而是一套应对单总线设备的“方法论”。这套方法的核心在于：精确的时序控制、稳定的电源与上拉、以及包含超时判断的健壮性代码。
5.1 方法迁移：以DS18B20温度传感器为例
DS18B20是另一个经典的单总线器件，协议比DHT11更复杂（有ROM操作、功能命令等），但底层的精神是相通的。它也需要主机用精确的低电平脉冲来发起复位、等待存在脉冲、然后按位读写。你为DHT11编写的微秒延时函数、带超时的等待循环、以及关闭中断的操作，都可以直接复用到DS18B20的驱动中。区别在于具体的脉冲宽度和命令序列。当你理解了“主机驱动总线-从机响应-按位通信”这个范式后，学习任何单总线器件都会快很多。
5.2 项目扩展：国赛综合应用场景
在国赛中，DHT11很少单独出现。它通常是一个子系统。例如：
- 智能农业监控：DHT11监测温湿度，土壤湿度传感器监测湿度，光敏电阻监测光照，三者数据综合判断，通过继电器控制水泵和补光灯。这里的关键是多任务调度和传感器数据融合。
- 智能家居环境站：DHT11监测室内环境，结合OLED显示屏实时显示，并通过按键设置温湿度报警阈值，超过阈值则蜂鸣器报警。这里涉及状态机编程和人机交互。
- 数据记录器：DHT11定时采集数据，存储在板载的EEPROM（如M24C02）或外部Flash中，并通过串口按需上传到电脑。这里考验的是存储器的读写和文件系统（或简单队列）的思想。
面对这些综合题目，模块化编程是制胜法宝。你应该把DHT11的驱动单独放在dht11.c和dht11.h文件中，提供清晰的接口函数（如DHT11_Init(),DHT11_Read()）。在主程序中，像调用库函数一样调用它，这样你的注意力就可以集中在业务逻辑上，而不是底层时序的泥潭里。
最后，关于代码风格，在国赛那种高压环境下，清晰比巧妙更重要。多写注释，把复杂的时序判断用函数封装起来，给函数和变量起有意义的名字。这不仅能帮助你在调试时理清思路，也能让阅卷老师（如果是客观题后的编程题）一眼看出你的逻辑是清晰的。毕竟，稳定可靠的80分，远胜过惊险飘忽的100分。
