RT5350 OpenWrt平台DHT11温湿度传感器驱动开发全流程解析

1. 项目概述

在嵌入式开发领域，尤其是基于OpenWrt这样的开源路由器系统进行二次开发时，我们常常需要扩展其功能，使其不再仅仅是一台路由器，而成为一个功能丰富的物联网网关或数据采集节点。今天要分享的，就是如何在RT5350开发板上，为OpenWrt系统编写一个DHT11温湿度传感器的驱动程序，并提供一个简单的用户空间应用程序来读取数据。这个项目看似基础，但其中涉及的从硬件连接到内核驱动，再到用户态交互的完整链路，是每一位嵌入式Linux开发者都应该掌握的硬核技能。无论你是刚接触OpenWrt的新手，还是想巩固Linux驱动开发知识的老鸟，这篇基于实际项目经验的总结，都能为你提供一条清晰的实践路径。

2. 硬件原理与接口设计

2.1 DHT11传感器核心原理

DHT11是一款经典的复合数字温湿度传感器。它的核心优势在于将模拟传感元件（电阻式感湿元件和NTC测温元件）与一个8位微控制器集成在同一个封装内。这个微控制器负责采集原始的模拟信号，进行模数转换，并利用出厂时存储在OTP（一次性可编程）存储器中的校准系数进行补偿计算，最终输出经过校准的数字信号。这种设计把最复杂的信号调理和校准工作留在了传感器内部，极大地简化了外部主控器的开发工作。我们只需要通过一根数据线，按照特定的单总线（1-Wire）协议与它通信，就能读取到可靠的温度和湿度数据。这种“单线串行接口”正是其易于集成的关键。

2.2 RT5350开发板GPIO连接详解

在本次项目中，我们使用的是基于RT5350芯片的开发板。RT5350是联发科（MediaTek）的一款高度集成的Wi-Fi SoC，常用于路由器方案，其GPIO资源相对有限，因此引脚复用和准确定义至关重要。

根据提供的原理图片段，传感器连接如下：

• VCC引脚：连接至开发板的3.3V电源引脚。这里有一个关键细节：必须确保是3.3V，DHT11的工作电压范围是3.3V-5.5V，但为了与RT5350的GPIO电平（通常是3.3V）匹配，避免电平转换问题，直接使用3.3V供电是最稳妥的选择。
• GND引脚：连接至开发板的地（GND）。
• DATA引脚：连接至开发板的P13引脚，该引脚被复用为GPIO0。在RT5350的系统中，GPIO通常以组（Bank）的形式进行管理。例如，GPIO0可能属于GPIO21这一组（具体分组需查阅RT5350的数据手册）。在驱动代码中，我们通过内存映射I/O（MMIO）来访问控制这个引脚的寄存器。

寄存器地址解析： 代码中出现的0x10000620和0x10000624是RT5350芯片内存空间中GPIO控制寄存器的物理地址。通常，在一个Bank中：

• *GPIO21_0_DATA（地址0x10000620）：这是数据寄存器。向它的特定位写1或0，可以设置对应GPIO引脚输出高或低电平；读取它，可以获取引脚当前的输入电平状态。
• *GPIO21_0_DIR（地址0x10000624）：这是方向控制寄存器。向它的特定位写1，将对应引脚设置为输出模式；写0，则设置为输入模式。

通过ioremap函数将这些物理地址映射到内核的虚拟地址空间后，我们就可以像操作普通内存一样操作这些寄存器，从而控制GPIO0。

注意：GPIO编号的“坑”。不同芯片、不同内核版本对GPIO的编号方式可能不同。有的使用全局统一的GPIO编号（如gpio-0），有的使用(bank * 32 + index)的方式。在OpenWrt中，更常见的做法是使用gpiolib子系统提供的API（如gpio_request,gpio_direction_output等），而不是直接操作寄存器。直接操作寄存器虽然高效、直接，但可移植性较差，且需要开发者对芯片手册有深入了解。本文示例采用直接寄存器操作，是为了最清晰地展示底层时序控制的原理。

2.3 上拉电阻的必要性

DHT11的数据线是开漏输出。这意味着传感器本身只能将总线拉低（输出0），而不能主动拉高（输出1）。总线的高电平状态需要由一个外部的上拉电阻来维持。通常，DHT11模块本身已经集成了一个4.7KΩ或10KΩ的上拉电阻。如果你的模块没有，或者你是直接使用传感器元件，务必在数据线和3.3V电源之间连接一个4.7KΩ的上拉电阻。否则，总线将无法被拉高，通信会完全失败。这是硬件连接中最容易忽略却至关重要的一步。

3. DHT11单总线通信协议深度解析

驱动DHT11的核心，在于精确实现其单总线通信协议。这个协议对时序的要求非常严格，微秒（us）级的误差都可能导致读取失败。

3.1 主机启动信号与传感器响应

通信总是由主机（我们的RT5350）发起。整个过程分为三个阶段：

1. 主机发送起始信号：主机将数据线（GPIO0）设置为输出模式，并拉低至少18毫秒（ms），然后拉高20-40微秒（us）。这个“拉低-拉高”的过程，相当于对DHT11说：“喂，醒醒，我要读数据了”。
2. 传感器响应信号：DHT11检测到起始信号后，会先拉低总线约80us作为应答，然后再拉高80us，表示它已经准备好发送数据。
3. 数据传输：紧接着，传感器开始连续输出40位数据（8位湿度整数+8位湿度小数+8位温度整数+8位温度小数+8位校验和）。

在驱动代码的read_dht11函数中，我们清晰地看到了对这个过程的模拟：

DHT11_OUT; // 设置GPIO为输出 DHT11_L; // 拉低 mdelay(30); // 等待30ms (>18ms) DHT11_H; // 拉高 udelay(30); // 等待30us (在20-40us范围内) DHT11_IN; // 切换GPIO为输入，准备读取传感器的响应

随后，代码用两个while循环等待传感器拉低和拉高的应答信号，并设置了超时判断（t_count > 250），防止程序因传感器故障而死锁。

3.2 数据位“0”与“1”的判定逻辑

DHT11传输的每一位数据都以一个50us的低电平起始位开始，随后是一个高电平。区分“0”和“1”的关键，就在于这个高电平的持续时间。

• 位“0”：高电平持续时间约为26-28us。
• 位“1”：高电平持续时间约为70us。

因此，读取一位数据的策略是：等待起始的低电平结束（总线变高），然后延时一个大约30us的时间（这个值是经验值，位于26-28us和70us之间），再去采样总线电平。

• 如果采样时为高电平，说明高电平持续时间已经超过了30us，很大概率是“1”，就将该位置1。
• 如果采样时为低电平，说明高电平持续时间很短（小于30us），可以判定为“0”，就将该位置0。

代码中的read_byte函数完美实现了这个逻辑：

udelay(32); // 延时约32us后采样 if (DHT11_STA == 1) { // 如果此时总线还是高电平 r_val <<= 1; r_val |= 1; // 判定为‘1’ } else { // 如果总线已经是低电平 r_val <<= 1; // 判定为‘0’， r_val默认位就是0，所以只需移位 }

实操心得：延时的精度是成败关键。udelay和mdelay是内核提供的忙等待延时函数，在OpenWrt这种非实时操作系统上，其精度会受系统负载、中断等因素影响。对于DHT11这种要求~30us精度的协议，在驱动中直接使用udelay在多数情况下可行，但并非绝对可靠。在更苛刻或负载较重的系统中，可能需要使用高精度定时器（如hrtimers）或直接使用GPIO中断配合定时器来测量高电平脉宽，从而实现更稳健的读取。对于初学者，先从udelay实现开始理解原理是完全可行的。

3.3 数据格式与校验

DHT11一次输出40位（5字节）数据。通常我们只使用其中的湿度整数和温度整数部分。DHT11的精度为湿度±5%RH，温度±2°C，小数部分通常为0。

校验和是前4个字节（湿度高、低字节，温度高、低字节）相加后的低8位。驱动程序中的校验逻辑是：

if (check_sum == (h_i+h_f+t_i+t_f) || (h_i!=100 && t_i != 100)) { dht11 = t_i; dht11 <<= 8; dht11 += h_i; }

这里有一个有趣的“或”条件：(h_i!=100 && t_i != 100)。这其实是一个针对读取错误的容错处理。read_byte函数在超时时会返回100。这个条件意味着，只要读出的湿度和温度整数部分不是错误值100，即使校验和不匹配，也尝试采用数据。在实际应用中，更严谨的做法是只依赖校验和，因为时序错误可能导致某个位读错，使得数据“看起来合理”（比如温度25°C）但其实是错的。舍弃校验错误的数据，等待下一次读取，是更可靠的做法。

4. Linux字符设备驱动框架实践

4.1 驱动模块的组成结构

一个标准的Linux字符设备驱动，就像我们写的dht11.ko，需要遵循固定的模板：

1. 模块加载与卸载函数：module_init(dht11_init)和module_exit(dht11_exit)。这是驱动的人口和出口。
2. 初始化函数 (dht11_init)：这是驱动的“安装”过程。
   • 设备号申请：使用alloc_chrdev_region动态申请一个主设备号。设备号是内核识别设备的核心ID。
   • 字符设备注册：使用cdev_init初始化一个cdev结构体，并用cdev_add将其添加到内核中，关联上设备号和文件操作函数集。
   • 创建设备节点：利用class_create和device_create在/sys/class/下创建类，并在/dev/目录下自动创建设备文件节点（如/dev/dht11）。这样用户程序才能通过open(“/dev/dht11”)来访问驱动。
   • 硬件初始化：映射GPIO寄存器地址（ioremap），并初始化GPIO方向。
3. 文件操作函数集 (file_operations)：这是驱动与用户空间交互的“协议”。
   • dht11_open：当用户程序调用open()时执行。这里我们把GPIO设置为输出并拉高，准备发起通信。
   • dht11_read：当用户程序调用read()时执行。这是核心函数，它会调用read_dht11()函数触发一次完整的温湿度数据读取，然后通过copy_to_user将数据拷贝到用户空间缓冲区。
   • dht11_close：当用户程序调用close()时执行。这里没有特殊操作。
4. 模块信息：MODULE_LICENSE,MODULE_AUTHOR等，用于声明模块的许可证和作者。

4.2 资源管理的艺术：goto语句的合理使用

细看dht11_init函数，里面充满了goto语句。这在Linux内核开发中是一种常见的、用于处理初始化错误时资源清理的“链式回滚”模式。其核心思想是：初始化步骤是分层的，失败时必须以相反的顺序释放已申请的资源。

例如，如果device_create失败，我们需要依次：

1. 销毁刚创建的device（虽然失败了，但部分资源可能已分配）。
2. 删除已添加的cdev。
3. 注销已申请的设备号。
4. 销毁已创建的class。

代码通过goto标签（如device_c_error,class_c_error）将控制流跳转到对应的错误处理段落，确保了在任何一步失败时，系统都不会残留未被释放的资源（如设备号），从而避免了资源泄漏。这是编写稳健内核代码必须养成的习惯。

4.3 用户空间与内核空间的数据交换

驱动运行在内核空间，用户程序运行在用户空间，它们的内存是隔离的。因此，不能直接传递指针。dht11_read函数中的copy_to_user(buffer, &dht11, 4)就完成了这个跨越边界的数据拷贝。它将内核空间变量dht11（一个32位整数）的4个字节，安全地复制到用户空间传入的缓冲区buffer中。反之，从用户空间向内核拷贝数据则使用copy_from_user。

5. 从编译到部署：完整的实操流程

5.1 OpenWrt SDK环境与驱动编译

在OpenWrt环境下编译内核模块，强烈推荐使用其SDK（Software Development Kit），而不是直接在开发板或虚拟机里编译整个内核。

1. 获取SDK：从OpenWrt官方下载对应你固件版本（如15.05）和硬件平台（如ramips/rt5350）的SDK。解压后，其目录结构包含了交叉编译工具链、内核头文件等。
2. 创建驱动包：
   • 在SDK的package/目录下，新建一个目录，例如dht11-driver。
   • 在该目录下创建两个关键文件：
     • Makefile：定义如何编译你的驱动。
     • src/目录：里面放置你的dht11.c驱动源代码。
3. 编写驱动包的Makefile：

   include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=dht11 PKG_RELEASE:=1 include $(INCLUDE_DIR)/package.mk define KernelPackage/dht11 SUBMENU:=Other modules TITLE:=DHT11 Temperature and Humidity Sensor Driver FILES:=$(PKG_BUILD_DIR)/dht11.ko AUTOLOAD:=$(call AutoLoad,81,dht11) # 设置自动加载，81是加载顺序 endef define KernelPackage/dht11/description A kernel driver for the DHT11 temperature and humidity sensor on RT5350 GPIO. endef define Build/Prepare mkdir -p $(PKG_BUILD_DIR) $(CP) ./src/* $(PKG_BUILD_DIR)/ endef define Build/Compile $(MAKE) -C "$(LINUX_DIR)" \ M="$(PKG_BUILD_DIR)" \ ARCH="$(LINUX_KARCH)" \ CROSS_COMPILE="$(TARGET_CROSS)" \ modules endef $(eval $(call KernelPackage,dht11))

   这个Makefile会调用OpenWrt构建系统，使用正确的内核配置和交叉编译器来编译你的驱动。
4. 编译：在SDK根目录执行make menuconfig，在Kernel modules -> Other modules下选中我们新增的dht11驱动，保存后执行make package/dht11-driver/compile V=s。编译生成的.ipk安装包位于bin/packages/下。

5.2 应用程序的交叉编译

应用程序dht11_app.c的编译更简单一些，可以直接使用SDK中的交叉编译工具链。

# 假设SDK的staging_dir目录下有工具链 export STAGING_DIR=/path/to/your/sdk/staging_dir $STAGING_DIR/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-gcc dht11_app.c -o dht11_app -static # 静态链接，避免依赖问题

使用-static选项进行静态链接，可以将所有库函数打包进最终的可执行文件，这样它就可以在任何相同架构（如mipsel）的系统上运行，而无需担心目标板上缺少动态库。

5.3 在开发板上的部署与测试

1. 传输文件：使用scp命令将编译好的dht11.ko（驱动模块）和dht11_app（应用程序）传输到开发板。开发板需要开启SSH服务。

   scp dht11.ko dht11_app root@192.168.1.1:/tmp/

2. 安装驱动模块：

   # 在开发板终端执行 cd /tmp insmod dht11.ko

   使用lsmod命令查看模块是否加载成功，使用dmesg | tail查看内核日志，应该能看到我们驱动的printk输出的初始化成功信息。
3. 检查设备节点：加载成功后，/dev/目录下应该会出现dht11这个设备文件。使用ls -l /dev/dht11查看其权限。
4. 运行测试程序：

   chmod +x dht11_app ./dht11_app

   如果一切正常，程序会打印出当前的温度和湿度值。

5.4 集成到OpenWrt系统

为了让开发板每次启动都自动加载驱动，可以将驱动模块集成到固件中。

1. 将编译好的dht11.ko放入SDK的files/lib/modules/$(uname -r)/目录下（需要先创建）。
2. 在files/etc/modules.d/目录下创建一个文件，例如60-dht11，内容就是一行：dht11。这样系统启动时会自动加载它。
3. 重新编译固件并烧录。这样，驱动和应用程序就成为了固件的一部分。

6. 调试技巧与常见问题排查

驱动开发的大部分时间都在调试。以下是一些实战中总结的排查思路：

1. 问题：insmod失败，提示“Invalid module format”或“Unknown symbol”。

   • 原因：最常见的原因是驱动模块与当前运行的内核版本不匹配。内核模块是高度依赖内核版本和配置的。
   • 解决：确保你编译驱动所用的内核源码版本、配置（特别是CONFIG_MODVERSIONS）与开发板上运行的内核完全一致。使用OpenWrt SDK编译是避免此问题的最佳实践。

2. 问题：驱动加载成功，但/dev/dht11设备节点没有创建。

   • 排查：首先dmesg查看内核日志，确认dht11_init函数是否执行到了“auto mknod success!”这行打印。如果没有，说明device_create可能失败了。
   • 检查：确认内核配置中已启用CONFIG_SYSFS和CONFIG_DEVICE_支持。在OpenWrt的make kernel_menuconfig中，确保Device Drivers -> Generic Driver Options -> /sys/devices/ support和Device Drivers -> Character devices -> /dev/ devices support相关选项已启用。

3. 问题：应用程序能打开/dev/dht11，但read返回0或错误值，dmesg显示“read_dht11 error”。

   • 排查：这是时序问题的高发区。
   • 步骤1：检查硬件。用万用表测量DATA引脚电压，在空闲时是否为稳定的高电平（3.3V）？发起起始信号时，是否能被拉低？确认上拉电阻存在且连接正确。
   • 步骤2：增加调试信息。在驱动的read_dht11和read_byte函数中，多加入一些printk，打印出超时发生的位置（是等不到传感器响应，还是数据位读取超时？）。这能帮你定位是起始信号问题，还是数据读取问题。
   • 步骤3：调整延时。尝试微调udelay(32)这个关键延时。可以尝试28us, 30us, 35us等值。不同批次的DHT11或不同的系统时钟漂移可能导致最佳采样点偏移。
   • 步骤4：检查电源。DHT11在启动和数据转换时需要较大电流，确保3.3V电源稳定，必要时在VCC和GND之间并联一个100uF的电容进行滤波。

4. 问题：读取的数据偶尔错误，比如湿度超过100%。

   • 原因：电磁干扰或时序临界导致某个数据位读取错误。
   • 解决：
     • 软件层面：实现读取重试机制。在应用程序中，如果读出的数据校验失败或数值明显不合理（湿度>100%），可以延迟几百毫秒后重读几次，取出现次数最多的合理值。
     • 硬件层面：缩短传感器与开发板之间的连线，并在DATA线上串联一个100欧姆左右的小电阻，有助于抑制信号振铃。确保电源地线连接良好。

5. 问题：系统负载高时，读取失败率上升。

   • 原因：udelay在系统繁忙时可能不精确，被更重要的中断或任务抢占。
   • 解决：这是使用udelay的固有缺陷。对于生产环境，考虑重构驱动：
     • 使用内核高精度定时器（hrtimer）来更精确地控制延时和测量时间。
     • 或者，将DATA引脚配置为中断引脚，在驱动中捕获下降沿和上升沿，通过计算中断间的时间差来判定是“0”还是“1”。这种方法对CPU占用最低，也最可靠，但编程复杂度更高。

7. 项目总结与扩展思考

通过这个完整的DHT11驱动开发项目，我们走完了嵌入式Linux开发的一个典型闭环：从硬件原理分析、通信协议解读，到内核驱动编写、资源管理，再到用户空间应用和系统集成。对于RT5350这类资源受限的MIPS平台，直接操作寄存器提供了最高的效率和对硬件的直接控制力。

然而，在现代Linux驱动开发中，更推荐的做法是使用GPIO子系统和设备树（Device Tree）。你可以将DHT11的GPIO引脚信息写在设备树文件中，驱动中使用gpiod_get来获取GPIO描述符，用gpiod_direction_output等标准API来控制引脚。这样做的好处是驱动与硬件配置解耦，同一份驱动代码可以轻松适配不同引脚连接的开发板，只需修改设备树即可，大大提升了代码的可移植性和可维护性。这是你从“裸写驱动”迈向“规范化驱动开发”的下一步。

最后，这个驱动只是一个起点。你可以将它集成到lm-sensors框架中，让温度数据出现在/sys/class/hwmon目录下；也可以编写一个LuCI（OpenWrt的Web管理界面）插件，在路由器管理页面上实时显示温湿度；更进一步，可以结合MQTT客户端，将采集到的数据上报到物联网云平台，真正发挥出OpenWrt作为智能网关的潜力。硬件、驱动、系统、应用、网络，链条上的每一环都充满了值得深入探索的细节，而这正是嵌入式开发的魅力所在。