1. 为什么STM32F1至今仍是嵌入式入门的首选平台搞嵌入式这行十几年我经手的MCU从8位机到Cortex-M7都有但每次有新人问我“从哪块板子开始练手”我脱口而出的还是STM32F1系列。原因不复杂这颗芯片的资料密度、社区沉淀和价格区间在入门级32位MCU里几乎没有对手。STM32F1基于ARM Cortex-M3内核主频常见72MHz片上Flash从16KB到1MB不等SRAM从6KB到96KB外设覆盖GPIO、USART、SPI、I2C、ADC、定时器、CAN、USB等基本上你能想到的嵌入式基础外设它都有。更关键的是它的参考手册、固件库、HAL库、标准外设库以及无数开源项目构成了一个极其厚实的学习底座。这次我拿“DHT11温湿度传感器STM32F1”这个组合来展开是因为它几乎是每个嵌入式新手都会经历的经典项目。DHT11是一款单总线数字温湿度传感器测量范围温度0~50℃、湿度20%~90%RH精度分别是±2℃和±5%RH采样周期不低于1秒。它便宜、好买、接线简单但时序要求比较严格正好用来练GPIO的输入输出切换、微秒级延时、单总线协议解析和串口打印。把这套跑通你对STM32F1的GPIO、定时器、USART会有一个非常扎实的理解。这篇文章适合三类人刚拿到STM32F1开发板不知道从哪下手的新手做过51单片机想升级到32位平台的老手以及想快速复现一个稳定DHT11驱动、不想在时序上反复踩坑的开发者。我会从方案选型、硬件连接、时序原理、代码实现、常见问题排查几个维度把整个项目拆开讲透代码可以直接抄作业参数计算过程也会写清楚。2. 项目整体设计与方案选型拆解2.1 为什么选STM32F1而不是其他平台先说说选型逻辑。市面上做DHT11驱动的平台很多Arduino、ESP32、51单片机都能跑为什么偏偏用STM32F1我的考量有三点。第一时序控制的确定性。DHT11是单总线协议主机需要拉低总线至少18ms作为起始信号然后释放总线等待传感器响应。传感器响应后会拉低80μs、再拉高80μs之后才开始逐位传输40位数据。每一位数据以50μs低电平开始高电平持续26~28μs表示“0”持续70μs表示“1”。这些微秒级的时间窗口用51单片机跑11.0592MHz晶振也能做但延时精度受中断影响大STM32F1跑72MHz用SysTick或者DWT做微秒延时精度和稳定性明显更好。第二调试手段丰富。STM32F1支持SWD调试可以单步跟踪、看变量、看寄存器配合串口打印排查时序问题比51方便太多。我经常用逻辑分析仪抓DHT11的波形再对照代码逐段核对这种“波形代码”双向验证的方式在STM32F1上做起来很顺手。第三生态延续性。学会STM32F1的GPIO和定时器操作后面换F4、H7、G0、L4系列底层逻辑是相通的HAL库的API风格也一致。用F1入门迁移成本最低。2.2 DHT11的通信协议核心要点DHT11虽然便宜但它的单总线协议有几个坑必须提前说清楚。总线空闲状态是高电平。STM32的GPIO要配置成开漏输出或者推挽输出加外部上拉电阻。我一般用推挽输出因为DHT11模块通常自带4.7kΩ~10kΩ上拉电阻如果没有必须在数据线和VCC之间接一个4.7kΩ电阻否则总线释放后无法回到高电平通信直接失败。起始信号拉低时间不能太短。数据手册写的是“至少18ms”我实测下来18ms是临界值有些批次的传感器在18ms时响应不稳定建议拉到20ms留一点余量。这个时间用HAL_Delay(20)就能实现但要注意HAL_Delay依赖SysTick中断如果中断被关闭或者优先级配置不当延时会不准。响应信号是80μs低80μs高。主机释放总线后传感器会在20~40μs内拉低总线80μs再拉高80μs。如果这两个电平没等到说明传感器没响应常见原因是接线松动、上拉电阻缺失或者传感器损坏。数据位的“0”和“1”靠高电平持续时间区分。每位数据以50μs低电平开始然后高电平持续26~28μs为“0”持续70μs为“1”。这里的关键是采样时机我通常在低电平结束后延时40μs再读引脚如果还是高电平就是“1”否则是“0”。这个40μs是经验值因为“0”的高电平在28μs左右结束“1”的高电平在70μs左右结束40μs正好落在两者之间容错空间最大。40位数据的结构8位湿度整数8位湿度小数8位温度整数8位温度小数8位校验和。校验和等于前四个字节相加取低8位。DHT11的小数部分通常为0但校验时必须按完整字节计算。2.3 硬件连接与供电注意事项接线本身很简单DHT11的VCC接3.3V或5VGND接GNDDATA接STM32F1的某个GPIO比如PA0。但有几个细节容易翻车。注意DHT11的工作电压是3.3V~5.5VSTM32F1的GPIO耐压是5V大部分引脚所以5V供电时DATA线可以直接接GPIO但如果你用的是3.3V供电传感器和MCU电平一致更安全。我建议统一用3.3V避免电平匹配问题。供电电流方面DHT11测量瞬间电流约1mA平均电流很小STM32F1的3.3V稳压器比如AMS1117完全带得动。但如果你的板子上还有其他大电流外设建议给DHT11单独加一个0.1μF去耦电容放在传感器VCC和GND之间距离越近越好。数据线的长度也有讲究。DHT11的单总线对分布电容敏感线长超过20cm时上升沿会变缓可能导致采样错误。我实测过50cm的杜邦线通信成功率明显下降换成20cm以内的短线就稳定了。如果必须长距离降低上拉电阻到2.2kΩ可以改善但会增加功耗。3. 核心细节解析与实操要点3.1 GPIO模式切换的时机与陷阱DHT11通信过程中GPIO需要在输出和输入模式之间切换。具体流程是主机拉低总线输出模式→ 延时20ms → 释放总线切换为输入模式→ 等待传感器响应 → 读取40位数据。这里最大的坑是模式切换后的电平状态。STM32F1的GPIO从输出切换到输入时如果之前输出的是低电平切换瞬间引脚会保持低电平一段时间直到外部上拉电阻把总线拉高。这个时间取决于上拉电阻和总线电容通常是微秒级。如果你切换后立刻开始检测高电平可能会误判。我的做法是释放总线后先延时30μs再开始检测响应信号。这样给上拉电阻足够的时间把总线拉高避免误判。另外切换输入模式时我习惯配置成上拉输入GPIO_MODE_INPUTGPIO_PULLUP这样即使外部没有上拉电阻内部上拉也能提供弱驱动虽然DHT11模块通常自带外部上拉但双重保险更稳。还有一个细节读取数据位时的超时保护。如果传感器故障或者接线断开等待高电平的循环可能永远不退出程序卡死。我一般给每个等待循环加一个超时计数比如等待高电平时最多循环200次每次延时1μs超过就返回错误码。这样即使传感器没接程序也能正常跑下去不会死等。3.2 微秒级延时的三种实现方式对比DHT11的时序要求微秒级延时STM32F1上常用的有三种方式我逐一分析优缺点。第一种SysTick延时。配置SysTick为1μs中断一次在中断里递减计数器。优点是精度高不占用CPU缺点是中断频繁1μs一次中断对72MHz的M3来说负担不小而且如果其他中断优先级更高延时会被打断。我一般不用这种方式做微秒延时。第二种DWT周期计数器。Cortex-M3内核自带DWTData Watchpoint and Trace单元其中的CYCCNT寄存器记录CPU周期数。72MHz下1μs等于72个周期。通过读取CYCCNT的差值可以实现高精度延时不占用中断资源。缺点是DWT默认关闭需要手动使能而且不同编译器的初始化代码略有差异。这是我比较推荐的方式精度和效率兼顾。第三种空循环延时。用__NOP()或者简单的for循环根据CPU频率估算循环次数。优点是简单不需要额外配置缺点是精度受编译器优化影响大不同优化等级下延时差异明显。我通常用这种方式做粗略延时比如1μs、2μs这种短延时配合示波器校准一下循环次数。实际项目中我常用组合方案20ms的起始信号用HAL_Delay80μs和40μs的延时用DWT1~2μs的短延时用空循环。这样兼顾精度和代码简洁性。3.3 数据校验与错误处理策略DHT11的40位数据读完后必须做校验和验证。校验和等于湿度整数湿度小数温度整数温度小数取低8位。如果校验失败说明传输过程中有误码需要重新读取。我的错误处理策略是连续读取3次只要有一次校验通过就采用。因为DHT11的采样周期不低于1秒连续读取之间要间隔至少1秒否则传感器可能不响应。如果3次都失败返回错误码上层可以选择重试或者报警。另外DHT11的温度和湿度数据是整数小数部分通常为0。但有些批次的传感器小数部分可能非零校验时必须按完整字节计算不能忽略小数。我见过有人只校验整数部分结果偶尔误判。还有一个隐藏问题DHT11上电后需要1秒的稳定时间。如果你上电后立刻读取第一次往往失败。我的做法是初始化后延时1~2秒再开始读取之后每次读取间隔不低于1秒。这个1秒不是随便定的是数据手册明确写的采样周期低于这个值传感器可能返回上一次的缓存数据或者不响应。4. 实操过程与核心环节实现4.1 工程搭建与基础配置我以STM32F103C8T6蓝板为例用STM32CubeMX生成工程IDE用Keil MDK或者STM32CubeIDE都行。配置步骤如下时钟配置外部晶振8MHzPLL倍频到72MHzAPB1分频236MHzAPB2不分频72MHz。GPIO配置PA0配置为推挽输出初始高电平速度50MHz。稍后在代码中动态切换输入输出。USART1配置波特率1152008位数据无校验1位停止位用于打印温湿度数据。SysTick配置1ms中断用于HAL_Delay。生成代码后先写一个串口重定向把printf映射到USART1方便调试。代码如下#include stdio.h int __io_putchar(int ch) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, HAL_MAX_DELAY); return ch; }然后在main函数里初始化DHT11引脚写一个微秒延时函数。我用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 cycles us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) cycles); }这段代码的原理是SystemCoreClock是72000000除以1000000得到72即1μs对应72个周期。delay_us(40)就是等待40*722880个周期。DWT-CYCCNT是32位计数器72MHz下约59.6秒溢出一次对于微秒级延时完全够用。4.2 DHT11驱动代码逐段解析先定义引脚操作宏#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_PIN_0 #define DHT11_OUT_HIGH() HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET) #define DHT11_OUT_LOW() HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_RESET) #define DHT11_IN() { 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); } #define DHT11_OUT() { GPIO_InitTypeDef GPIO_InitStruct {0}; \ GPIO_InitStruct.Pin DHT11_GPIO_PIN; \ GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; \ GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; \ HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); } #define DHT11_READ() HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN)这里注意DHT11_IN()和DHT11_OUT()每次都会重新初始化GPIO虽然有点耗时但保证了模式切换的确定性。如果你追求极致速度可以直接操作寄存器CRL/CRH但HAL库的方式更易读对于DHT11这种低速传感器完全够用。起始信号函数void DHT11_Start(void) { DHT11_OUT(); DHT11_OUT_LOW(); HAL_Delay(20); DHT11_OUT_HIGH(); delay_us(30); DHT11_IN(); }拉低20ms然后拉高30μs再切换输入这个30μs是给上拉电阻的缓冲时间。有些代码直接拉高后立刻切输入也能跑但稳定性差一些。等待响应函数uint8_t DHT11_Wait_Response(void) { uint32_t timeout 0; while (DHT11_READ() GPIO_PIN_SET) { if (timeout 100) return 1; delay_us(1); } timeout 0; while (DHT11_READ() GPIO_PIN_RESET) { if (timeout 100) return 2; delay_us(1); } timeout 0; while (DHT11_READ() GPIO_PIN_SET) { if (timeout 100) return 3; delay_us(1); } return 0; }第一个while等待传感器拉低总线第二个while等待传感器拉高第三个while等待传感器再次拉低准备传输数据。每个while都有超时保护返回不同的错误码方便定位问题。读取一个字节uint8_t DHT11_Read_Byte(void) { uint8_t data 0; for (int i 0; i 8; i) { uint32_t timeout 0; while (DHT11_READ() GPIO_PIN_RESET) { if (timeout 100) return 0; delay_us(1); } delay_us(40); data 1; if (DHT11_READ() GPIO_PIN_SET) { data | 1; } timeout 0; while (DHT11_READ() GPIO_PIN_SET) { if (timeout 100) return 0; delay_us(1); } } return data; }这段代码的逻辑是先等待50μs低电平结束然后延时40μs采样。如果还是高电平说明是“1”否则是“0”。采样后等待高电平结束准备下一位。注意这里的40μs是经验值你可以根据逻辑分析仪的波形微调但40μs的容错空间最大。完整读取函数uint8_t DHT11_Read_Data(uint8_t *temp, uint8_t *humi) { uint8_t buf[5]; DHT11_Start(); if (DHT11_Wait_Response() ! 0) return 1; for (int i 0; i 5; i) { buf[i] DHT11_Read_Byte(); } if (buf[4] (buf[0] buf[1] buf[2] buf[3])) { *humi buf[0]; *temp buf[2]; return 0; } return 2; }buf[0]是湿度整数buf[1]是湿度小数buf[2]是温度整数buf[3]是温度小数buf[4]是校验和。校验通过后把湿度和温度传给指针。4.3 主循环与串口打印实现主函数里初始化后每隔2秒读取一次通过串口打印int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); DWT_Init(); HAL_Delay(2000); uint8_t temp, humi; while (1) { if (DHT11_Read_Data(temp, humi) 0) { printf(Temperature: %d C, Humidity: %d %%RH\r\n, temp, humi); } else { printf(DHT11 read error\r\n); } HAL_Delay(2000); } }这里用2秒间隔而不是1秒是因为DHT11在连续快速读取时偶尔会返回错误2秒的间隔更稳。如果你需要更快的数据更新1秒是下限不能再短。4.4 用逻辑分析仪验证时序代码写完后我强烈建议用逻辑分析仪抓一次波形。把探头接在DATA线上采样率设1MHz以上触发方式设为下降沿。你应该能看到20ms低电平→30μs高电平→80μs低电平→80μs高电平→40位数据。每一位数据的低电平都是50μs高电平26~28μs或70μs。如果波形不对比如起始信号只有10ms检查HAL_Delay(20)是否被其他中断打断如果响应信号缺失检查上拉电阻和接线如果数据位的高电平时间不对检查delay_us的精度。我遇到过DWT没使能导致delay_us变成空操作的情况波形上表现为所有延时都极短通信完全失败。所以DWT_Init()一定要在delay_us之前调用。5. 常见问题与排查技巧实录5.1 DHT11读取失败的六大原因我把这些年遇到的DHT11问题整理成一张速查表按出现频率排序问题现象可能原因排查方法解决方案完全无响应接线错误或传感器损坏用万用表测VCC和GND之间电压检查接线更换传感器响应信号缺失上拉电阻未接或阻值过大示波器看总线释放后是否回高加4.7kΩ上拉电阻数据校验失败时序偏差或干扰逻辑分析仪抓波形对比时序调整延时参数缩短数据线偶尔成功偶尔失败电源纹波或接触不良测VCC纹波检查杜邦线加去耦电容换短线温度湿度值不变读取间隔小于1秒检查代码中的延时间隔改为2秒程序卡死等待循环无超时单步调试看卡在哪个while加超时计数这张表里的每一条我都实际踩过。最典型的是“响应信号缺失”当时用的是没有上拉电阻的裸传感器直接接STM32的GPIO结果总线释放后一直是低电平。后来在DATA和VCC之间焊了一个4.7kΩ电阻立刻就好了。所以如果你买的是裸传感器而不是模块上拉电阻是必须的。5.2 时序偏差的调试方法时序问题是DHT11调试中最头疼的。我的调试流程是先用逻辑分析仪抓一次完整波形保存下来然后在代码里每个关键节点翻转一个空闲GPIO比如PA1用另一个探头抓PA1的波形最后把两个波形对齐看代码执行到哪一步时总线状态不对。举个例子我曾经遇到数据位全部读成“1”的情况。抓波形发现每位数据的低电平只有20μs而不是50μs导致我在40μs采样时低电平已经结束误判为“1”。原因是delay_us函数在等待低电平结束时循环次数不够提前退出了。把超时计数从100改成200问题解决。这个问题的根源是DHT11的低电平持续时间可能因批次不同而有差异数据手册写50μs实际可能在40~60μs之间波动超时计数要留足余量。另一个常见问题是中断干扰。STM32F1的SysTick中断每1ms触发一次如果DHT11读取过程中正好遇到SysTick中断delay_us的循环会被打断导致延时变长。虽然1ms中断对微秒级延时的影响通常只有几微秒但在临界情况下可能导致误判。我的做法是在DHT11读取期间关闭全局中断__disable_irq(); DHT11_Read_Data(temp, humi); __enable_irq();但这样会影响其他实时性要求高的任务。更优雅的方式是提高DHT11任务的优先级或者用DMA定时器捕获的方式读取不过那就复杂了。对于入门项目关中断几十微秒是可以接受的。5.3 从DHT11延伸到其他单总线传感器DHT11跑通后你可以用同样的思路玩DS18B20单总线温度传感器和DHT22温湿度传感器精度更高。DS18B20的时序和DHT11类似但复位脉冲是480μs低480μs高读写时隙也不同。DHT22的起始信号是1ms低30μs高数据位的高电平时间也不同。掌握了DHT11的调试方法换传感器时只需要改时序参数框架不用动。我个人的经验是单总线传感器的核心就是“严格按手册时序超时保护波形验证”。这三板斧下去没有调不通的。很多人卡住是因为只看代码不看波形或者波形抓了但不会分析。逻辑分析仪现在很便宜几十块钱的就能用建议每个嵌入式新手都备一个。5.4 代码优化与移植建议最后分享几个代码层面的优化技巧。第一把DHT11的GPIO操作封装成宏移植时只改宏定义不用动驱动逻辑。第二delay_us函数用DWT实现时注意SystemCoreClock的值要和实际时钟一致如果你改了PLL倍频记得更新。第三读取失败时不要立刻重试至少等1秒否则传感器可能不响应。第四串口打印用DMA发送避免阻塞主循环尤其是在高速采样时。移植到其他STM32系列时HAL库的GPIO和UART API基本一致主要改时钟配置和DWT初始化。如果移植到标准外设库把HAL_GPIO_WritePin换成GPIO_SetBits/GPIO_ResetBitsHAL_GPIO_ReadPin换成GPIO_ReadInputDataBit其他逻辑不变。我在实际项目里用这套代码驱动DHT11连续跑了三个月每天读取一次没有出现一次校验失败。关键就是起始信号给足20ms、采样点选在40μs、每次读取间隔2秒、数据线不超过20cm。这几个参数你直接抄基本不会翻车。