1. 从坑里爬出来的DHT11驱动调试经验

最近在复刻一个智能家居项目时，我被DHT11温湿度传感器折腾得够呛。明明是大夏天，温度读数却只有10几度，更离谱的是有时候竟然能读出121%的湿度值——这都快赶上桑拿房了！最初我直接使用了开源的驱动代码，但发现只能成功读取几次数据，后面就完全乱套了。作为一个有强迫症的嵌入式开发者，我决定彻底解决这个问题，从头开始写一个稳定的DHT11驱动。

DHT11是一款常见的温湿度传感器，采用单总线协议进行通信。这个协议看起来简单，但对时序的要求极其严格，误差几个微秒就可能导致数据读取失败。在Linux环境下编写驱动，最大的挑战就是如何保证时序的精确性，因为Linux不是实时系统，各种内核调度和中断都可能影响我们的时间控制。

经过反复试验和示波器验证，我终于找到了一套可行的解决方案。接下来，我会手把手带你走一遍我的调试过程，分享如何用Linux内核提供的高精度时间函数来优化时序控制，解决数据读取不稳定和校验错误的问题。

2. DHT11时序原理与调试难点

2.1 深入理解DHT11的通信协议

DHT11的通信时序可以分为三个主要阶段：主机启动信号、传感器响应和数据传输。整个过程都在微秒级别完成，这就是为什么时序控制如此关键。

启动信号阶段，主机需要将数据线拉低至少18毫秒，然后拉高20-40微秒。这个信号告诉DHT11："嘿，准备好发送数据了！"作为回应，DHT11会先拉低80微秒，然后再拉高80微秒，表示它已经准备好发送数据了。

数据传输阶段更加精细。每个数据位都以50微秒的低电平开始，然后通过高电平的持续时间来区分0和1：30微秒左右的高电平表示0，70微秒左右表示1。总共传输40位数据，包括湿度整数、湿度小数、温度整数、温度小数和一个校验字节。

2.2 为什么Linux环境下时序这么难调

在裸机编程中，我们可以通过简单的延时函数来控制时序，但在Linux环境下，情况就复杂多了。首先，Linux不是实时操作系统，内核调度、中断处理和其他进程的活动都会影响我们的时序精度。其次，printk这样的调试函数本身就会消耗毫秒级的时间，这在微秒级的时序控制中是绝对不能接受的。

我最初遇到的问题很典型：有时候能读到数据，有时候读不到；数据校验经常失败；连续读取时性能下降。通过示波器分析，我发现问题主要出在两个方面：一是延时函数不够精确，二是GPIO状态检测的时机不对。

3. 环境搭建与硬件连接

3.1 硬件准备与接线

我使用的是正点原子的IMX6ULL开发板，这是一个基于ARM Cortex-A7的嵌入式平台。DHT11传感器只有三个引脚：VCC、GND和DATA。接线很简单：VCC接3.3V，GND接地，DATA接到GPIO1_IO02引脚。

选择GPIO引脚时需要注意，最好选择一个没有被其他功能占用的引脚。在我的设备树配置中，我为DHT11专门定义了一个节点：

hc_dht11 {
    compatible = "hc-dht11";
    pinctrl-name = "default";
    pinctrl-0 = <&pinctrl_dht11>;
    gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
    my_name = "dht11";
    status = "okay";
};

pinctrl_dht11: dht11grp {
    fsl,pins = <
        MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0x0001B0B0
    >;
};

这个配置将GPIO1_IO02引脚设置为GPIO功能，并配置了适当的电气特性。0x0001B0B0这个值定义了引脚的上下拉、驱动强度等参数，具体含义可以参考IMX6ULL的数据手册。

3.2 软件环境配置

在驱动代码中，我们需要包含一系列头文件来使用内核提供的各种API：

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/gpio.h>
#include <linux/uaccess.h>
#include <linux/string.h>
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
#include <linux/of_gpio.h>
#include <linux/slab.h>
#include <linux/device.h>
#include <linux/fs.h>
#include <linux/kernel.h>
#include <linux/wait.h>
#include <linux/sched.h>
#include <linux/timer.h>
#include <linux/gpio/consumer.h>
#include <linux/delay.h>
#include <linux/timekeeping.h>
#include <linux/wait.h>
#include <linux/irqflags.h>
#include <linux/ktime.h>

最重要的是<linux/ktime.h>，它提供了高精度的时间函数ktime_get_ns()，这个函数返回纳秒级的时间戳，是我们优化时序的关键工具。

4. 高精度时序控制实战

4.1 使用ktime_get_ns()实现精确延时

传统的udelay()和mdelay()函数在Linux驱动中可能不够精确，特别是当系统负载较高时。为了解决这个问题，我使用了内核提供的高精度时间API：

#define TIMEOUT_NS(us) ((us) * 1000)  // 微秒转纳秒
#define MIN_DURATION_NS 40000         // 40微秒
#define MAX_DURATION_NS 100000        // 100微秒

u64 current_time = ktime_get_ns();
u64 start_time = current_time;

while (ktime_get_ns() - start_time < TIMEOUT_NS(20)) {
    // 等待20微秒
}

这种方法比传统的延时函数更精确，因为它直接基于硬件的时间计数器，不受系统负载影响。

4.2 启动信号发送优化

发送启动信号是通信的第一步，也是最容易出错的环节之一。最初我的代码是这样的：

gpio_direction_output(DHT11_PIN, 1);
gpio_set_value(DHT11_PIN, 0);
mdelay(20);
gpio_set_value(DHT11_PIN, 1);
udelay(40);
gpio_direction_input(DHT11_PIN);
udelay(20);  // 额外的延时

但通过示波器发现，DHT11的应答信号只有40微秒左右，而不是预期的80微秒。问题在于那些额外的延时和模式切换操作本身也需要时间。

优化后的代码：

/* 发送启动信号 */
gpio_direction_output(DHT11_PIN, 1);
mdelay(2);
gpio_set_value(DHT11_PIN, 0);
mdelay(20);
gpio_set_value(DHT11_PIN, 1);
udelay(20);
gpio_direction_input(DHT11_PIN);  // 立即切换为输入模式

关键变化是去除了模式切换后的额外延时，因为gpio_direction_input()函数本身就需要一定时间执行，再加上额外的延时会导致我们错过DHT11应答信号的开始部分。

5. 应答信号检测与数据处理

5.1 精确检测应答信号

检测DHT11的应答信号需要特别小心，因为它的持续时间很短（80微秒），而且任何调试输出都会干扰时序。下面是我的实现：

/* 等待低电平开始（DHT11应答） */
current_time = ktime_get_ns();
while (gpio_get_value(DHT11_PIN)) {
    if (ktime_get_ns() - current_time > TIMEOUT_NS(100)) {
        return -1;  // 超时
    }
}
low_start = ktime_get_ns();

/* 等待低电平结束 */
while (!gpio_get_value(DHT11_PIN)) {
    if (ktime_get_ns() - low_start > TIMEOUT_NS(100)) {
        return -1;  // 超时
    }
}
low_duration = ktime_get_ns() - low_start;

/* 验证低电平持续时间 */
if (low_duration < MIN_DURATION_NS || low_duration > MAX_DURATION_NS) {
    return -1;
}

这段代码使用ktime_get_ns()来精确测量低电平的持续时间，如果不在40-100微秒的合理范围内，就认为应答信号无效。

5.2 数据处理与校验

DHT11发送40位数据，分为5个字节：湿度高字节、湿度低字节、温度高字节、温度低字节和校验字节。校验字节是前四个字节的和的最低8位。

我的数据处理代码如下：

/* 读取5字节数据 */
for (i = 0; i < 5; i++) {
    for (j = 7; j >= 0; j--) {
        // 等待低电平开始
        current_time = ktime_get_ns();
        while (gpio_get_value(DHT11_PIN)) {
            if (ktime_get_ns() - current_time > TIMEOUT_NS(50)) {
                return -1;
            }
        }
        
        // 等待高电平开始并测量持续时间
        low_start = ktime_get_ns();
        while (!gpio_get_value(DHT11_PIN)) {
            if (ktime_get_ns() - low_start > TIMEOUT_NS(70)) {
                return -1;
            }
        }
        
        high_start = ktime_get_ns();
        while (gpio_get_value(DHT11_PIN)) {
            if (ktime_get_ns() - high_start > TIMEOUT_NS(100)) {
                return -1;
            }
        }
        
        high_duration = ktime_get_ns() - high_start;
        
        // 根据高电平持续时间判断数据位
        if (high_duration > 50000) {  // 50微秒
            data[i] |= (1 << j);
        }
    }
}

/* 校验数据 */
checksum = data[0] + data[1] + data[2] + data[3];
if (checksum != data[4]) {
    return -1;  // 校验失败
}

有一个很容易忽略但非常重要的细节：每次读取前必须清空数据缓冲区。我最初就栽在这个坑里，代码只有第一次读取能成功，后面都会校验失败。原因是旧数据残留影响了校验计算。

6. 示波器验证与性能优化

6.1 使用示波器验证时序

调试DHT11驱动，示波器是不可或缺的工具。通过示波器，我可以直观地看到实际的信号波形，与理论时序进行对比。

我观察到的典型问题包括：启动信号中的高电平时间过长、应答信号中的低电平时间不足、数据位中的高电平时间波动等。这些问题在代码中很难发现，但通过示波器就一目了然。

通过反复调整代码和观察波形，我最终得到了符合DHT11规格的时序波形。启动信号中的高电平精确控制在20微秒左右，应答信号中的低电平和高电平都在80微秒左右，数据位中的高低电平时间也符合预期。

6.2 避免调试输出对时序的影响

在早期的调试过程中，我添加了很多printk语句来输出调试信息，但这反而导致了更多问题。后来才发现，printk不是原子操作，它的执行时间在毫秒级别，对于微秒级的DHT11时序来说，这简直是灾难。

解决方案是：只在出错时输出调试信息，而且尽量使用轻量级的输出方式。在最终的生产代码中，应该移除所有不必要的调试输出。

6.3 防止内核调度干扰时序

Linux内核的调度和中断会干扰DHT11的时序，因为我们的驱动可能会在关键时刻被抢占。为了解决这个问题，我使用了中断禁止和内核抢占禁止来保护关键的时序代码：

static ssize_t dht11_read(struct file *filp, char __user *buf, size_t size, loff_t *offset) {
    unsigned long flags;
    int res;
    
    /* 进入临界区，禁止内核抢占和中断 */
    local_irq_save(flags);
    
    res = read_dht11_data();
    
    /* 退出临界区 */
    local_irq_restore(flags);
    
    if (res == 0) {
        return copy_to_user(buf, data, size);
    } else {
        return -EIO;
    }
}

这种方法确保了在读取DHT11数据时，不会被其他中断或进程打断，从而保证了时序的精确性。

7. 完整驱动代码实现

经过多次优化和调试，最终得到的驱动代码既稳定又高效。完整的代码实现了以下功能：精确的时序控制、完整的数据读取和校验、错误处理和用户空间接口。

驱动通过平台设备机制与设备树绑定，支持动态加载和卸载。用户空间程序可以通过标准的文件操作接口（open、read、close）来读取温湿度数据。

在代码组织上，我将时序关键部分放在一个独立的函数中，并用中断禁止保护起来。数据读取成功后，通过copy_to_user()将数据传递给用户空间程序。错误处理方面，定义了多种错误码来区分不同的失败情况，便于调试和问题定位。

这个驱动已经在我的智能家居项目中稳定运行了数周，温湿度读数准确，没有再出现异常值或读取失败的情况。通过这次经历，我深刻体会到在Linux环境下调试硬件驱动时，理解硬件时序特性和使用合适的调试工具是多么重要。