第4章设备驱动框架入门

第4章：设备驱动框架入门

说实话，很多初学者一上来就问我：「驱动到底是个啥？」

我通常这么回答：驱动就是操作系统和硬件之间的翻译官。应用程序说人话，硬件说方言，驱动就是那个两头都能聊的中间人。

这一章，咱们就把这个翻译官的工作机制彻底搞明白。

4.1 驱动模型分层：谁该干什么活

QNX的驱动模型，我习惯把它分成三层。你想想看，如果所有代码都揉在一起，那调试起来得多痛苦？

层次	职责	我见过的坑
硬件抽象层（HAL）	直接操作寄存器、处理中断	寄存器地址写错，板子直接死给你看
核心逻辑层	数据缓冲、协议解析、状态机	缓冲区溢出，查了两天才找到
接口层	暴露给上层应用的API	接口设计不合理，后面改得想哭

为什么要分层？我在项目里吃过亏。有一次写SPI驱动，把寄存器操作和协议解析混在一起。结果换了个芯片，寄存器地址全变了，我不得不重写整个驱动。嗯，从那以后，我再也不敢不分层了。

核心原则：每一层只关心自己的事。HAL层不知道上层在传什么数据，接口层不知道寄存器长什么样。这样换硬件时，你只需要改HAL层。

4.2 用户态驱动 vs 内核态驱动

这是QNX里一个特别有意思的话题。别的操作系统，驱动基本都在内核里待着。但QNX不一样，它给了你选择权。

用户态驱动，说白了就是一个普通进程。它通过 mmap 映射硬件地址，通过 ThreadCtl 获取中断权限。我刚开始做QNX时觉得这太奇怪了——驱动还能跑在用户态？

内核态驱动，就是传统意义上的驱动模块，运行在系统空间，通过 io-pkt 或 devb-* 框架加载。

对比项	用户态驱动	内核态驱动
开发难度	低，可以用标准C库	高，受内核API限制
调试方式	gdb直接调试，爽	需要kgdb或printk
崩溃影响	只挂掉驱动进程	整个系统可能挂掉
性能	有上下文切换开销	零拷贝，性能更好
适用场景	开发阶段、非实时外设	高性能、实时性要求高

我的建议：新手先从用户态驱动入手。为什么？因为你可以用printf调试，崩溃了也不会重启机器。等把硬件摸透了，再考虑搬到内核态。

我曾经在一个项目中，用户态驱动跑了半年，性能完全够用。后来客户要求提高吞吐量，我才花了两天时间把它改成内核态驱动。你想想看，如果一开始就写内核态驱动，调试那半年得多痛苦？

4.3 驱动开发流程：从零到一

很多新手拿到开发板，第一件事就是写代码。我劝你别急。我总结了一套流程，照着走，能少走很多弯路。

读数据手册——至少把寄存器列表和初始化序列看三遍
搭测试环境——用命令行先验证硬件能不能正常工作
写HAL层——封装寄存器读写函数，加调试打印
验证中断——确保中断能触发，能正确响应
写核心逻辑——实现数据收发、状态机
封装接口——设计给上层用的API
集成测试——和应用程序联调

注意：千万别跳过第2步。我见过有人花了两周写驱动，结果发现硬件本身就有问题——焊错了电阻。用命令行先测一下硬件，十分钟就能发现的问题，别等到最后才暴露。

4.4 Hello World 驱动：动手写一个

光说不练假把式。咱们写一个最简单的用户态驱动，控制一个GPIO引脚。

先看代码，我一行一行解释：

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <hw/inout.h>

#define GPIO_BASE 0x48000000  // 假设的GPIO基地址
#define GPIO_DATA 0x00        // 数据寄存器偏移
#define GPIO_DIR  0x04        // 方向寄存器偏移

int main(int argc, char *argv[]) {
    int fd;
    volatile uint32_t *gpio;
    
    // 1. 打开物理内存映射
    fd = open("/dev/mem", O_RDWR);
    if (fd == -1) {
        perror("open /dev/mem failed");
        return EXIT_FAILURE;
    }
    
    // 2. 映射GPIO寄存器到用户空间
    gpio = (volatile uint32_t *)mmap(0, 0x1000, 
                                     PROT_READ | PROT_WRITE,
                                     MAP_SHARED, fd, GPIO_BASE);
    if (gpio == MAP_FAILED) {
        perror("mmap failed");
        close(fd);
        return EXIT_FAILURE;
    }
    
    // 3. 设置引脚为输出
    gpio[GPIO_DIR / 4] |= (1 << 10);  // 假设用第10脚
    
    // 4. 输出高电平
    gpio[GPIO_DATA / 4] |= (1 << 10);
    printf("GPIO10 set to HIGH\n");
    
    sleep(2);
    
    // 5. 输出低电平
    gpio[GPIO_DATA / 4] &= ~(1 << 10);
    printf("GPIO10 set to LOW\n");
    
    // 6. 清理
    munmap((void *)gpio, 0x1000);
    close(fd);
    
    return EXIT_SUCCESS;
}

这段代码干了这么几件事：

通过 /dev/mem 拿到访问物理内存的权限
用 mmap 把GPIO寄存器映射到进程的地址空间
直接读写寄存器，控制引脚输出高低电平

编译命令很简单：

qcc -Vgcc_ntoaarch64 -o gpio_hello gpio_hello.c

然后以root权限运行：

./gpio_hello

注意：这个例子假设你有root权限，并且硬件地址是0x48000000。实际项目中，这些地址一定要从数据手册里确认。我见过有人把地址写反了，结果控制的是隔壁的I2C控制器，整个总线都乱了。

4.5 加载与卸载：让驱动跑起来

用户态驱动不需要「加载」这个概念。编译出来就是一个可执行文件，直接运行就行。但如果你想把它做成系统服务，可以用 waitfor 或者 launch 来管理。

对于内核态驱动，加载方式是这样的：

# 加载驱动模块
mount -T io-pkt /path/to/devnp-mydevice.so

# 查看已加载的驱动
ls /dev/

# 卸载驱动
umount /dev/mydevice

我个人习惯在开发阶段用用户态驱动，调试方便。等代码稳定了，再考虑做成内核模块。你想想看，开发阶段每改一次代码就要重启系统，那效率得多低？

小技巧：在用户态驱动里加一个 -d 参数，开启调试打印。这样出问题时，不用重新编译，直接加参数运行就能看到详细信息。我在项目里一直这么干，省了不少事。

好了，这一章的内容就到这。你学会了驱动模型的分层思想，知道了用户态和内核态的区别，还亲手写了一个控制GPIO的Hello World驱动。下一章，咱们深入中断处理——这才是驱动开发的硬核部分。

📚 课程目录