1. DHT11温湿度传感器基础认知

第一次接触DHT11时，我误以为它和普通模拟传感器一样简单，结果被它的单总线协议狠狠教育了一番。这个火柴盒大小的传感器内部其实藏着完整的数字处理系统——它把模拟信号转换、温度补偿、校准数据存储这些功能全部集成在芯片里，输出的是直接可用的数字信号。

DHT11采用单总线通信协议，这意味着数据发送和接收都通过同一根线完成。这种设计节省了IO口资源，但也带来了严格的时序要求。传感器内部包含一个电阻式感湿元件和一个NTC测温元件，测量范围在20-90%RH（湿度）和0-50℃（温度），精度分别为±5%RH和±2℃。虽然精度不算高，但对于大多数家用和工业监控场景已经足够。

实际使用中有个容易忽略的细节：传感器上电后需要1秒的稳定时间。我有次调试时发现数据一直异常，后来才发现是上电后立即读取导致的。建议在初始化代码里加上HAL_Delay(1000)，这个教训是用半天调试时间换来的。

2. CubeMX工程配置详解

打开CubeMX时，新手常会对着密密麻麻的配置选项发懵。我们一步步来破解：

时钟配置就像给单片机设置心跳节奏。以STM32F103为例，选择HSE（外部高速时钟）作为时钟源，在Clock Configuration标签页里将HCLK设置为72MHz。记住要确保PLLCLK被选中，就像给引擎挂上涡轮增压器。

GPIO配置需要特别注意：虽然数据线平时是输出模式，但在接收数据时需要切换为输入。我习惯将初始模式设为Output，但实际项目中会根据通信阶段动态切换。在Pinout视图里找到对应引脚（比如PA5），右键选择GPIO_Output即可。

定时器配置是精准延时的关键。选择任意一个基本定时器（如TIM2），设置Prescaler为71（72MHz/72=1MHz），Counter Period设为最大值65535。这样定时器每计数一次就是1微秒，为后续的精确延时打下基础。

串口配置建议使用USART1，模式选Asynchronous，波特率设115200bps。有个实用技巧：在NVIC Settings中使能串口全局中断，这样后续可以方便地实现中断接收功能。最后别忘了在Project Manager里勾选"Generate peripheral initialization as a pair of .c/.h files"，这能让代码结构更清晰。

3. 微秒级延时实现技巧

HAL库自带的HAL_Delay()只能实现毫秒级延时，而DHT11的时序要求精确到微秒级别。通过定时器实现us延时时，我踩过一个坑：没有考虑定时器溢出的情况。比如当需要延时1000us时，如果计数器已经到达65500，简单的while循环就会永远等不到目标值。

改进后的延时函数应该这样写：

void delay_us(uint16_t us) { __HAL_TIM_SET_COUNTER(&htim2, 0); HAL_TIM_Base_Start(&htim2); while(__HAL_TIM_GET_COUNTER(&htim2) < us); HAL_TIM_Base_Stop(&htim2); }

这个实现有三个关键点：

1. 每次延时前重置计数器
2. 启动定时器后采用忙等待
3. 延时结束后立即关闭定时器以节省功耗

实测发现，在72MHz主频下这个函数的误差在±0.5us以内，完全满足DHT11的要求。如果项目中对功耗敏感，还可以优化为中断方式，但会增加代码复杂度。

4. 单总线通信协议实现

DHT11的通信过程就像两个人在用摩斯电码对话，必须严格遵守时间约定。整个通信流程分为四个阶段：

起始信号阶段需要主机（STM32）主动拉低数据线至少18ms，然后拉高20-40us。这里有个细节：拉高后要立即切换为输入模式，就像说完话后要把耳朵凑过去听回复。对应的代码实现：

void DHT11_Start(void) { DHT11_OUT(); HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_RESET); HAL_Delay(20); // 实际18ms即可，多留余量 HAL_GPIO_WritePin(DHT11_GPIO_Port, DHT11_Pin, GPIO_PIN_SET); delay_us(30); DHT11_IN(); }

响应检测阶段需要等待DHT11的回复。传感器会先拉低80us，再拉高80us。这里容易出现的问题是响应超时，我的经验是加上超时判断：

uint8_t DHT11_Check_Response(void) { uint8_t retry = 0; while(HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin) && retry<100){ retry++; delay_us(1); } if(retry>=100) return 1; // ...后续检测逻辑 }

数据读取阶段要解析40位数据。每个bit都以50us低电平开始，通过高电平持续时间区分0（26-28us）和1（70us）。建议用一个缓冲区暂存所有位数据，最后再组装成字节：

uint8_t DHT11_Read_Byte(void) { uint8_t data = 0; for(int i=0; i<8; i++){ while(!HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待50us低电平结束 delay_us(40); data <<= 1; if(HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)){ data |= 1; while(HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin)); // 等待高电平结束 } } return data; }

5. 数据校验与错误处理

DHT11传输的40位数据包含校验和，这是防止数据错误的重要机制。校验和是前四个字节（湿度整数、湿度小数、温度整数、温度小数）的和的最低8位。完整的读取函数应该这样实现：

uint8_t DHT11_Read_Data(uint8_t *humi, uint8_t *temp) { uint8_t buf[5]; DHT11_Start(); if(DHT11_Check_Response()) return 1; for(int i=0; i<5; i++) buf[i] = DHT11_Read_Byte(); if(buf[0]+buf[1]+buf[2]+buf[3] != buf[4]) return 2; *humi = buf[0]; *temp = buf[2]; return 0; }

实际项目中我建议添加这些容错机制：

1. 连续读取失败超过3次就延时1秒再试
2. 校验失败时丢弃当前数据包
3. 记录最近5次读取的成功率，低于阈值时报警

6. 串口输出与printf重定向

要让开发板通过串口输出数据，需要重定向printf函数。在Keil环境下需要两个步骤：

首先在工程选项中勾选"Use MicroLIB"，然后在usart.c文件中添加：

#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t*)&ch, 1, HAL_MAX_DELAY); return ch; }

有个常见问题是printf无法输出浮点数，这是因为默认的库配置问题。解决方法是在工程选项的Target标签下，勾选"Use float with printf from MicroLIB"。

输出格式优化建议：

printf("温度:%d℃ 湿度:%d%%\r\n", temperature, humidity);

这里的\r\n是回车换行符，保证在串口助手中能正确换行。我习惯在数据前加上时间戳，方便后期分析：

uint32_t tick = HAL_GetTick(); printf("[%5dms] 温度:%d℃\r\n", tick, temperature);

7. 实战调试技巧与问题排查

调试DHT11时最常遇到的问题是读取失败，根据我的经验，90%的问题都出在以下几个方面：

时序问题是最常见的坑。建议用逻辑分析仪抓取实际波形，对照数据手册检查各阶段时间参数。如果没有专业仪器，可以用GPIO翻转+示波器观察：

HAL_GPIO_WritePin(DEBUG_PIN_GPIO_Port, DEBUG_PIN_Pin, GPIO_PIN_SET); delay_us(10); HAL_GPIO_WritePin(DEBUG_PIN_GPIO_Port, DEBUG_PIN_Pin, GPIO_PIN_RESET);

电源干扰会导致数据异常。解决方法是在VCC和GND之间加104电容，数据线上拉电阻选用4.7KΩ。我曾遇到一个案例：当继电器动作时DHT11数据就乱跳，后来在电源端加了100μF电解电容就解决了。

接线错误看似低级但经常发生。DHT11的引脚顺序因厂家而异，有的模块是VCC-DATA-GND，有的是VCC-GND-DATA。我有次把电源接反，传感器瞬间烫手，这个教训价值30元（传感器价格）。

当读取失败时，可以按这个流程排查：

1. 检查电源电压是否在3-5.5V范围内
2. 用万用表测量DATA线空闲时是否为高电平
3. 确认上拉电阻是否正常工作
4. 检查代码中的延时参数是否准确
5. 尝试降低主频测试（有时高速时钟会影响时序）