DHT11传感器在STM32上的三种读取方式对比：轮询、定时器中断和DMA（基于HAL库）

在嵌入式开发中，温湿度传感器DHT11因其成本低廉和接口简单，成为了许多项目的入门选择。然而，对于追求系统效率、实时性和稳定性的开发者而言，如何从这颗小小的传感器中稳定、高效地读取数据，却是一个值得深入探讨的课题。尤其是在资源受限的STM32微控制器上，不同的数据读取策略会直接影响到CPU的占用率、系统的响应速度乃至整体功耗。如果你已经熟悉了基本的HAL库操作，能够点亮LED、驱动显示屏，但在面对需要精确时序控制的单总线设备时，总觉得代码“不够优雅”或“效率低下”，那么这篇文章正是为你准备的。我们将跳出简单的功能实现，从系统架构的角度，深入剖析轮询、定时器中断和DMA这三种截然不同的DHT11读取方式，帮助你根据项目需求，做出最合适的技术选型。

1. 理解核心挑战：单总线协议与STM32的时序博弈

在深入三种实现方式之前，我们必须先厘清问题的本质：DHT11的单总线协议对时序有着近乎苛刻的要求。这并非简单的“读”和“写”，而是一场与时间的精密舞蹈。

DHT11的通信始于主机（MCU）发送一个至少18ms的低电平起始信号，随后释放总线并等待20-40us，准备接收从机（DHT11）的响应。从机则会拉低总线80us作为应答信号，再拉高80us宣告数据传送开始。紧接着是40位数据（5字节）的传输，每一位数据都以一个50us的低电平起始，随后的高电平持续时间决定了数据是‘0’（26-28us）还是‘1’（70us）。整个通信过程必须在几毫秒内完成，且对微秒级别的延时异常敏感。

在STM32的世界里，我们通常用HAL_Delay()进行毫秒延时，但对于微秒级别的精确控制，它就显得力不从心了。因此，无论采用哪种高级方式，一个高精度的微秒级延时基础是必不可少的。这里，通用定时器（如TIM2）是我们的得力助手。

// 基于TIM2的微秒延时函数示例
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); // 停止定时器
}

注意：定时器的时钟频率需要根据你的系统时钟配置进行计算。例如，如果APB1总线时钟为84MHz，TIM2的预分频器设置为84-1，那么计数频率就是1MHz，即每个计数对应1微秒。

这个delay_us函数将成为我们后续所有读取方式的基石。但仅仅有精确延时还不够，如何组织代码来“聆听”总线上的每一位数据，才是区分三种方式的关键。轮询方式会霸道地独占CPU，定时器中断尝试在后台进行采样，而DMA则追求极致的“零CPU干预”。理解它们之间的差异，首先要从最直观的轮询方式开始。

2. 方式一：轮询读取——简单直接但效率低下

轮询，或称忙等待，是最符合初学者直觉的实现方式。它的逻辑直白：CPU亲自出马，严格按照协议时序，通过循环检测GPIO引脚电平的变化来拼接出每一比特数据。这种方式代码结构简单，调试直观，但代价是CPU在读取数据的整个过程中被完全阻塞，无法执行其他任何任务。

2.1 实现原理与代码结构

轮询方式的核心是一个状态机，它依次处理起始信号、响应信号和40位数据。下面是一个典型实现的关键片段：

uint8_t DHT11_Read_Byte_Polling(void)
{
    uint8_t byte_data = 0;
    for (int i = 0; i < 8; i++)
    {
        // 等待50us低电平起始位结束
        while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin) == GPIO_PIN_RESET);
        
        delay_us(40); // 延时40us后采样，位于高电平脉冲的中间位置

        // 采样电平判断数据位
        if (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin) == GPIO_PIN_SET)
        {
            byte_data |= (1 << (7 - i)); // 数据位为1
            // 等待高电平结束
            while (HAL_GPIO_ReadPin(DHT11_GPIO_Port, DHT11_Pin) == GPIO_PIN_SET);
        }
        // 如果为0，则高电平持续时间短，此时循环已进入下一位的低电平起始阶段
    }
    return byte_data;
}

整个读取流程可以概括为以下几个步骤：

1. 初始化与起始信号：将GPIO配置为推挽输出，拉低至少18ms，然后释放总线并切换为浮空输入模式，等待DHT11响应。
2. 响应检测：等待80us低电平应答信号，再等待80us高电平准备信号。
3. 数据位循环读取：对于40个数据位，循环调用上述DHT11_Read_Byte_Polling函数类似的逻辑，逐位采样。
4. 校验与返回：接收完5字节数据后，校验和校验，将温湿度值存入结构体并返回。

2.2 优缺点分析与适用场景

轮询方式的优缺点非常鲜明，我们可以通过下表进行快速对比：

特性	优点	缺点
实现复杂度	极低，逻辑直观，易于理解和调试。	-
CPU占用率	-	极高，读取期间（约4-5ms）CPU被完全阻塞。
系统实时性	-	极差，阻塞期间无法响应中断或其他任务。
代码可维护性	高，所有流程集中在一个函数内，一目了然。	-
稳定性	在单任务或对实时性无要求的系统中稳定。	在多任务或实时系统中可能因阻塞导致问题。
适用场景	学习原型验证、简单的单任务程序、对功耗和实时性无要求的场合。	不适合需要复杂外设管理、多任务调度或低功耗的应用。

轮询方式就像一名专注的工匠，在完成一件作品时心无旁骛。 对于刚刚接触STM32和DHT11的开发者，我强烈建议从轮询方式开始。它能帮助你最清晰地理解单总线协议的每一个细节。我曾在一个简单的温湿度记录器项目中使用它，该设备只需每分钟记录一次数据并存入SD卡，其余时间处于停机模式。在这种低频、非实时的场景下，轮询的简洁性成为了最大优势。

然而，当你需要让STM32同时驱动显示屏、处理串口命令、或者运行一个轻量级的实时操作系统（如FreeRTOS）时，轮询的阻塞特性就会立刻成为系统的瓶颈。此时，我们需要将CPU从繁重的“盯梢”工作中解放出来，这就是定时器中断方式要解决的问题。

3. 方式二：定时器中断读取——平衡性能与复杂性

定时器中断方式引入了一个重要的思想：将时间敏感的采样动作交给硬件定时器自动触发，CPU仅在需要处理数据时才被中断唤醒。 在DHT11通信的“数据位读取期”，我们利用定时器以固定的周期（例如，每50us一次）产生中断，在中断服务程序（ISR）中对数据线进行采样。这样，在两次中断之间，CPU是可以自由执行其他任务的。

3.1 实现原理与状态机设计

这种方式的核心是一个精心设计的状态机，它通常在中断服务程序和主循环的上下文之间协作运行。状态机定义了DHT11通信的各个阶段：

typedef enum {
    DHT11_STATE_IDLE,          // 空闲状态
    DHT11_STATE_START_LOW,     // 发送起始低电平
    DHT11_STATE_START_HIGH,    // 发送起始高电平，等待响应
    DHT11_STATE_RESP_LOW,      // 检测响应低电平
    DHT11_STATE_RESP_HIGH,     // 检测响应高电平
    DHT11_STATE_READ_BIT,      // 读取数据位
    DHT11_STATE_ERROR,         // 通信错误
    DHT11_STATE_COMPLETE       // 数据读取完成
} DHT11_State_t;

// 全局状态变量
volatile DHT11_State_t dht11_state = DHT11_STATE_IDLE;
volatile uint8_t dht11_data[5] = {0};
volatile uint8_t bit_index = 0, byte_index = 0;
volatile uint32_t last_edge_time = 0; // 用于记录边沿时间，计算脉冲宽度

定时器被配置为以较高频率（如1MHz，1us计数一次）运行，并在输入捕获模式或输出比较模式下工作。更常见的做法是使用输入捕获来精确测量高电平脉冲的宽度。以下是状态机在输入捕获中断中的处理逻辑片段：

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)
{
    if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) // 假设使用通道1
    {
        uint32_t current_capture = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1);
        uint32_t pulse_width = current_capture - last_edge_time;
        last_edge_time = current_capture;

        switch (dht11_state)
        {
            case DHT11_STATE_READ_BIT:
                // 根据脉冲宽度判断是位0还是位1
                if (pulse_width > 40) // 阈值可根据实际情况调整，如大于40us为1
                {
                    dht11_data[byte_index] |= (1 << (7 - bit_index));
                }
                // 否则为0，无需操作
                bit_index++;
                if (bit_index >= 8)
                {
                    bit_index = 0;
                    byte_index++;
                    if (byte_index >= 5)
                    {
                        dht11_state = DHT11_STATE_COMPLETE;
                        // 停止定时器输入捕获
                        HAL_TIM_IC_Stop_IT(&htim2, TIM_CHANNEL_1);
                    }
                }
                break;
            // ... 处理其他状态（响应信号等）
        }
    }
}

3.2 配置要点与潜在陷阱

实现定时器中断方式需要细致的配置：

1. 定时器模式选择：

   • 输入捕获模式：更精准，能直接测量高电平脉冲宽度，逻辑更清晰。需要配置一个GPIO引脚为复用功能并映射到定时器输入通道。
   • 输出比较中断模式：在已知的采样点（如每位开始后40us）产生中断进行采样。实现相对简单，但灵活性稍差。

2. 中断优先级管理：DHT11读取中断的优先级需要合理设置，既要保证时序不被其他中断过度打断，又不能阻塞关键的系统中断（如SysTick）。

3. 全局变量与volatile关键字：在中断服务程序与主程序之间共享的状态和数据的变量，必须使用volatile关键字声明，防止编译器进行不优化的优化。

4. 超时处理：必须在状态机中加入超时逻辑。例如，在DHT11_STATE_RESP_LOW状态等待低电平，如果超过120us仍未捕获到下降沿，则应跳转到DHT11_STATE_ERROR，避免系统因传感器故障而永远等待。

提示：在调试定时器中断方式时，逻辑分析仪或示波器是必不可少的工具。它们可以帮你直观地看到总线上的实际波形，并与你代码中的状态切换进行对比，快速定位是时序计算错误还是状态机逻辑问题。

定时器中断方式像是一位训练有素的管家。 CPU是主人，只需要在关键节点（如发起读取请求、处理最终数据）下达指令，而具体的、重复性的采样工作则由管家（定时器）按照既定规则自动完成。主人因此获得了宝贵的自由时间。在我参与的一个智能家居网关项目中，STM32需要同时处理Zigbee无线数据、维护TCP连接并更新本地显示屏。采用定时器中断读取DHT11，使得温湿度采集成为一个“后台任务”，完全不影响主循环处理其他网络协议栈，系统响应流畅。

然而，中断本身也是有开销的。每发生一次中断，CPU都需要进行上下文保存与恢复。对于DHT11的40位数据，如果每位产生一次中断，那就是40次中断上下文切换。在极端追求效率、希望CPU干预降至零的场景下，我们还有更终极的武器——DMA。

4. 方式三：DMA读取——极致效率与硬件复杂性

DMA（直接存储器访问）是STM32中用于实现数据在外设与存储器之间直接传输的硬件模块，其核心目标是解放CPU。对于DHT11这种时序严格但模式固定的单总线读取，我们可以探索一种非常规但极具效率的思路：将GPIO输入数据寄存器（IDR）的某一位，通过定时器触发，连续不断地搬运到内存数组中，最后由CPU对这片内存数据进行“解码”，还原出温湿度值。这种方式下，CPU在数据采集阶段完全不参与，实现了真正的“零开销”数据采集。

4.1 实现思路与硬件配置

这种方法的实现较为复杂，需要多个外设协同工作：

1. 定时器（TIM）作为触发器：配置一个定时器（如TIM2）在输出比较模式或PWM模式下，产生一个固定频率的脉冲序列。这个频率应远高于DHT11的数据位速率，例如500KHz（周期2us）。每个脉冲的上升沿或下降沿将作为DMA传输的请求源。

2. GPIO配置：将连接DHT11数据线的GPIO引脚配置为输入模式。

3. DMA配置：这是最关键的步骤。我们需要配置DMA通道，将外设地址设置为GPIO端口输入数据寄存器（GPIOx->IDR） 的地址，将存储器地址设置为我们定义的一个内存数组（如uint16_t raw_buffer[256]）。设置传输方向为外设到存储器，数据宽度为半字（16位，对应整个IDR寄存器）或字节（如果只关心特定引脚）。最关键的是，将DMA的请求源关联到上一步定时器产生的触发事件上。

4. 工作流程：

   • CPU发起起始信号（拉低、释放总线）。
   • 启动定时器和DMA。定时器以2us为周期不断触发DMA请求。
   • DMA控制器在每次触发时，自动将当前GPIO端口IDR寄存器的值（包含了DHT11数据引脚的电平状态）搬运到raw_buffer数组的下一个位置。
   • 持续采集足够长的时间（例如，覆盖整个DHT11响应和数据传输阶段，约5ms，对应2500个采样点）。
   • 采集完成后，停止定时器和DMA。此时，raw_buffer数组中已经按时间顺序记录了数据线电平的快照。
   • CPU离线分析raw_buffer数组，通过寻找电平跳变和测量高电平持续时间，解码出0和1，最终拼合成温湿度数据。

4.2 代码示例与解码算法

配置代码涉及CubeMX或底层寄存器操作，篇幅所限，这里给出核心的解码函数思路：

#define SAMPLE_RATE_US 2 // 采样周期2us
#define BUFFER_SIZE 2500 // 对应5ms的采样

uint16_t dma_raw_buffer[BUFFER_SIZE]; // DMA填充的缓冲区
DHT11_Data_t dht11_decode_from_dma_buffer(uint16_t *buffer, uint32_t size)
{
    DHT11_Data_t result = {0};
    uint32_t i = 0;
    uint8_t data[5] = {0};
    int bit_cnt = 0, byte_cnt = 0;

    // 1. 寻找起始信号后的第一个下降沿（响应信号开始）
    while (i < size && (buffer[i] & DHT11_PIN_MASK)) i++; // 跳过初始高电平
    while (i < size && !(buffer[i] & DHT11_PIN_MASK)) i++; // 跳过起始低电平
    while (i < size && (buffer[i] & DHT11_PIN_MASK)) i++; // 跳过起始高电平，等待响应低电平
    // 此时i指向响应低电平开始

    // 2. 跳过80us低电平和80us高电平（响应信号）
    i += (80 / SAMPLE_RATE_US) + (80 / SAMPLE_RATE_US);

    // 3. 解码40位数据
    for (byte_cnt = 0; byte_cnt < 5; byte_cnt++)
    {
        for (bit_cnt = 0; bit_cnt < 8; bit_cnt++)
        {
            // 跳过50us低电平起始位
            while (i < size && !(buffer[i] & DHT11_PIN_MASK)) i++;
            // 测量高电平持续时间
            uint32_t start_high = i;
            while (i < size && (buffer[i] & DHT11_PIN_MASK)) i++;
            uint32_t high_duration = (i - start_high) * SAMPLE_RATE_US;

            // 判断数据位
            if (high_duration > 40) // 高电平持续时间长，为1
            {
                data[byte_cnt] |= (1 << (7 - bit_cnt));
            }
            // 为0则无需操作
        }
    }

    // 4. 校验并填充结果
    if ((data[0] + data[1] + data[2] + data[3]) == data[4])
    {
        result.humidity = data[0];
        result.temperature = data[2];
        result.valid = 1;
    }
    return result;
}

4.3 优势、代价与选型考量

DMA方式的优势与代价同样突出：

• 极致CPU效率：数据采集阶段CPU完全自由，可处理更复杂的任务或进入低功耗模式。

• 高可靠性：通过存储原始波形，拥有最强的容错和调试能力。即使通信过程受到轻微干扰，也可以通过更复杂的算法（如滤波、容错判断）从原始数据中恢复信息。

• 灵活性：采样率可调，适用于分析信号质量或应对其他类似单总线协议。

• 实现复杂：需要深入理解定时器、DMA和GPIO的协同工作原理，配置繁琐，调试难度高。

• 内存占用：需要开辟一块不小的内存作为缓冲区。

• 功耗考虑：高频采样和DMA传输本身会增加一定的动态功耗。

DMA方式犹如部署了一套自动化监控系统。 CPU作为指挥中心，只需在开始和结束时下达指令，中间的“巡逻录像”（数据采集）全部由硬件自动完成。录像带（内存缓冲区）带回后，再由指挥中心分析录像内容。这种方式在高速数据流采集或对CPU实时性要求极端苛刻的系统中大放异彩。例如，在一个基于STM32的高频振动监测系统中，主CPU需要全力进行实时FFT分析，同时又要采集多个传感器的数据，DMA就成了不可或缺的技术。

5. 综合对比与实战选型指南

至此，我们已经深入探讨了三种方式的原理与实现。现在，让我们将它们放在一起，从多个维度进行直观对比，并给出清晰的选型建议。

对比维度	轮询 (Polling)	定时器中断 (Timer Interrupt)	DMA
CPU占用	采集期间100%占用，完全阻塞。	中等，采集期间CPU可处理其他任务，但需响应中断。	极低，采集期间CPU完全自由。
实现难度	非常简单，逻辑直白。	中等，需设计状态机、管理中断。	非常复杂，需精通外设协同与底层配置。
代码可维护性	高，集中在一处，易于理解。	中，逻辑分散在主循环和ISR中。	低，涉及底层硬件配置，抽象程度高。
系统实时性影响	破坏性，阻塞期间无实时性可言。	可控，中断服务时间短，影响可控。	几乎无影响。
功耗表现	差，CPU全程高速运行。	较好，CPU可在中断间休眠。	好，CPU可深度休眠。
数据可靠性	一般，受循环和延时精度影响。	较高，依赖硬件定时，更精确。	最高，拥有完整波形数据，可后期容错处理。
调试便利性	容易，可单步跟踪。	较难，涉及中断时序。	困难，需要分析内存缓冲区数据。
最佳适用场景	教学演示、单功能设备、对成本极度敏感且无并发需求的项目。	多数嵌入式应用，如需要运行RTOS、同时处理用户界面和网络通信的智能设备。	高端应用，如需要同时采集多路传感器数据、进行高速信号处理或对功耗有严苛要求的电池设备。

如何选择？关键在于权衡项目的核心需求。

• 如果你的项目是一个简单的温湿度计，功能单一，或者你正处于学习阶段，那么轮询方式是你的最佳起点。它能帮你夯实基础。
• 如果你的项目是一个智能家居节点、环境监测站，需要同时处理多个任务（如显示、通信、按键），那么定时器中断方式提供了最佳的平衡点，在复杂度和性能之间取得了很好的折衷。
• 如果你的项目是一个专业的数据记录仪、需要极低功耗的无线传感器节点，或者你的CPU正在处理比读取传感器更重要、更繁重的任务（如电机FOC控制、音频编码），那么投入时间研究DMA方式将是值得的，它能带来质的提升。

在我最近的一个工业现场监测项目中，主控STM32需要管理4个DHT11（分布在不同位置）、1个二氧化碳传感器（I2C）、1个噪声传感器（ADC），并通过LoRa定时上报。最初使用中断方式，发现在密集上报期间，偶尔会出现LoRa发送延迟。后来将4个DHT11的读取改为DMA方式（使用一个定时器触发，DMA多路复用或分时采集），CPU只在最后统一解码，彻底解决了这个问题，系统运行更加顺畅。这个经历让我深刻体会到，没有最好的方案，只有最适合当前系统约束和需求的方案。理解每一种方法背后的权衡，才能做出明智的架构决策。