一、驱动概述：什么是设备驱动、驱动在操作系统中的位置、外设接入的典型流程

各位同学，咱们今天正式开讲《外设驱动接入原理解析》的第一章。说实话，我做了十几年嵌入式开发，带过不少新人，发现很多人一上来就急着翻芯片手册、调寄存器，结果折腾半天连灯都点不亮。为什么？因为没搞明白驱动到底是个什么东西。

这一章，咱们就把驱动这个概念彻底掰开揉碎。你理解了它，后面学什么I²C、SPI、USB都顺风顺水。

1.1 什么是设备驱动

设备驱动，说白了就是一段软件代码。它的任务只有一个：让操作系统和应用软件能控制硬件设备。

你想想看，操作系统不认识你板子上的那个温度传感器，也不认识那个电机。它只认识文件、进程、内存这些抽象概念。那怎么让操作系统去读温度、转电机呢？中间就需要一个翻译官——这就是驱动。

我个人习惯把驱动分成三类，这样理解起来更清晰：

驱动类型	典型例子	特点
字符设备驱动	串口、GPIO、ADC	按字节流读写，顺序访问
块设备驱动	eMMC、SD卡、NAND Flash	按块读写，支持随机访问
网络设备驱动	以太网、Wi-Fi、CAN	通过socket接口收发数据包

我在项目中遇到过最典型的例子：一个同事把温度传感器写成了块设备驱动，结果上层应用读数据时总是报错。为什么？因为温度传感器是字符设备，你每次读到的就是当前温度值，不需要像硬盘那样按扇区寻址。这就是驱动类型选错了。

1.2 驱动在操作系统中的位置

驱动不是孤立的。它处在操作系统内核的最底层，紧贴着硬件。我画了一张图，你看完就明白了：

这张图你得记住。从上往下看：

• 最上层是应用层，你的APP、QT界面、业务逻辑都在这里。
• 中间是系统调用和VFS，操作系统把设备也伪装成文件，所以你可以用open()、read()、write()来操作设备。
• 驱动层就是咱们要学的核心。它接收VFS传来的命令，然后去操作硬件寄存器。
• 最底层是物理硬件，芯片、电阻、电容、总线信号。

1.3 外设接入的典型流程

好，现在咱们聊聊实际开发中，一个新外设是怎么接入系统的。我总结了一个五步流程，这些年带团队都是按这个套路走，基本没出过岔子。

咱们拆开细说：

第一步：硬件确认

拿到一个新外设，别急着写代码。先看原理图，确认以下几个东西：

• 外设挂在哪条总线上？（I²C？SPI？还是直接GPIO？）
• 片选引脚、中断引脚、复位引脚分别是哪个GPIO？
• 供电电压对不对？电平匹配吗？（3.3V vs 1.8V）
• 时钟源从哪里来？

我记得有一次，一个传感器怎么都读不到数据，折腾了两天。最后发现是原理图上I²C的上拉电阻画成了4.7kΩ，实际焊的是47kΩ，信号根本拉不起来。嗯，硬件问题永远排在第一位。

第二步：设备树配置

在Linux系统里，硬件资源信息写在设备树（Device Tree）里。你得告诉内核：

// 一个I²C温度传感器的设备树节点示例
&i2c1 {
    status = "okay";
    
    temperature_sensor: tmp117@48 {
        compatible = "ti,tmp117";
        reg = <0x48>;
        interrupt-parent = <&gpio1>;
        interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
    };
};

这里compatible是驱动匹配的关键字，reg是I²C地址，interrupts指定中断引脚。设备树写错了，驱动根本加载不了。

第三步：驱动编写

这是重头戏。一个典型的字符设备驱动框架长这样：

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/platform_device.h>

static int my_probe(struct platform_device *pdev)
{
    // 1. 获取硬件资源（GPIO、中断、时钟）
    // 2. 初始化硬件（复位、配置寄存器）
    // 3. 注册字符设备
    // 4. 创建设备节点
    return 0;
}

static int my_remove(struct platform_device *pdev)
{
    // 反初始化，释放资源
    return 0;
}

static struct platform_driver my_driver = {
    .probe  = my_probe,
    .remove = my_remove,
    .driver = {
        .name = "my_device",
        .of_match_table = my_of_match,
    },
};

module_platform_driver(my_driver);

你注意看，probe函数是驱动的入口。内核发现设备树里有匹配的compatible字符串时，就会调用这个函数。我在项目中见过最坑的事：有人把probe函数写成了死循环，结果内核启动到一半直接卡死。

第四步：编译部署

驱动写好了，编译成内核模块（.ko文件），或者直接编进内核。然后更新设备树，重启系统。这一步看起来简单，但容易出问题：

• 内核版本不匹配，模块加载报错
• 设备树编译时语法错误
• 驱动依赖的其他模块没加载

第五步：应用验证

驱动加载成功后，写个简单的测试程序验证功能：

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main()
{
    int fd = open("/dev/my_device", O_RDWR);
    if (fd < 0) {
        perror("open");
        return -1;
    }
    
    char buf[4];
    read(fd, buf, sizeof(buf));
    printf("Read data: %x %x %x %x\n", 
           buf[0], buf[1], buf[2], buf[3]);
    
    close(fd);
    return 0;
}

如果读出来的数据符合预期，恭喜你，驱动接入成功了。如果不对，别慌，回到第一步检查硬件，或者用逻辑分析仪抓一下总线波形。

1.4 本章小结

这一章咱们把驱动的基本概念讲清楚了：

• 驱动是什么——连接操作系统和硬件的桥梁
• 驱动在哪——内核最底层，紧贴硬件
• 怎么接入——五步流程：硬件确认→设备树→驱动编写→编译部署→应用验证

说实话，驱动开发没有太多玄学。你只要把硬件吃透，把内核框架搞清楚，剩下的就是按部就班地填代码。后面几章，咱们会深入到具体的总线协议和驱动框架里，到时候你会发现，所有外设的接入套路都差不多。