企业官网建设流程全解析

1. 嵌入式驱动开发到底在做什么

很多人第一次听到“嵌入式驱动开发”这个词，脑子里浮现的画面是焊台、示波器和一堆看不懂的寄存器手册。这个印象不算错，但只对了一半。驱动开发本质上是站在硬件和操作系统之间的一层翻译官，它把硬件那些冷冰冰的寄存器操作，翻译成内核和上层应用能听懂的接口。你写一个LED闪烁的程序，应用层调用的是write()或者ioctl()，但真正让LED亮起来的，是驱动里面对GPIO寄存器的那一行writel()。

我做了十多年嵌入式，从裸机跑到RTOS再到嵌入式Linux，最大的感受是：驱动开发的门槛不在写代码，而在“知道为什么这么写”。你可以从网上抄一段字符设备驱动的模板，编译加载也能跑，但一旦硬件行为不符合预期，没有对底层原理的理解，你连从哪查起都不知道。这篇文章就是想把我在实际项目中积累的那些“为什么”和“怎么排查”讲清楚，适合刚入行一两年、能写点裸机程序但一碰驱动就发怵的兄弟，也适合做了几年应用层想往下沉一沉的工程师。

嵌入式驱动开发涉及的面很广，从最基础的GPIO、UART、I2C、SPI，到复杂的USB、PCIe、GPU驱动，再到现在的AI加速器驱动，每一块都有自己的一套逻辑。但万变不离其宗，核心就那么几件事：总线模型、设备树、字符设备框架、中断处理、并发控制、电源管理。把这几个吃透了，换什么硬件都是查手册的事。

2. 驱动开发的核心架构与设计思路

2.1 为什么Linux驱动要分那么多层

刚接触嵌入式Linux驱动的人最容易懵的就是：一个简单的LED驱动，为什么要扯到platform总线、设备树、sysfs、字符设备这么多东西？直接操作寄存器不行吗？行，但那是裸机的做法。在Linux下，如果你直接在内核模块里硬编码寄存器地址，换一块板子就得改代码，硬件稍微变一下就得重新编译，这显然不可维护。

Linux驱动架构的设计哲学是“分离”和“抽象”。分离指的是把硬件相关的部分和硬件无关的部分分开，抽象指的是给上层提供统一的接口。具体来说，platform总线负责匹配设备和驱动，设备树负责描述硬件资源，字符设备框架负责提供文件操作接口，sysfs负责暴露设备属性。每一层各司其职，改硬件只需要改设备树，改逻辑只需要改驱动代码，互不影响。

我拿一个实际项目举例。之前做过一个工业网关，主控是i.MX6ULL，上面挂了一颗自定义的FPGA，通过SPI通信。如果按照裸机思路，我需要在驱动里写死SPI控制器的寄存器地址、FPGA的片选引脚、中断号。但用设备树之后，这些信息全部放在.dts文件里，驱动代码里只用of_property_read_u32()去读。后来客户换了个主控，SPI控制器变了，我只需要改设备树，驱动代码一行没动。这就是分层带来的好处。

2.2 设备树不是万能药，但不会设备树万万不能

设备树（Device Tree）是嵌入式Linux驱动开发绕不过去的坎。它的本质是一份用特定语法描述的硬件配置清单，内核启动时会解析这份清单，把硬件资源转换成platform_device，然后和注册的platform_driver进行匹配。

很多人学设备树的时候喜欢死记语法，什么compatible、reg、interrupts、clocks，背了一堆但不知道为什么要这么写。我的建议是：先理解内核怎么用这些属性，再回头记语法。比如compatible属性，它的作用就是匹配驱动。内核里有一个of_match_table，驱动注册时会把自己的compatible字符串填进去，内核遍历设备树节点，找到匹配的就调用驱动的probe函数。就这么简单。

reg属性描述的是寄存器地址范围，格式是<起始地址 长度>。interrupts描述中断信息，通常需要配合中断控制器。clocks和clock-names描述时钟源，因为很多外设需要先使能时钟才能访问寄存器。这些属性不是随便定的，每一个都对应内核里的一段解析代码。

注意：设备树里的reg地址是物理地址，驱动里用ioremap()映射之后才能访问。不要直接对物理地址解引用，会出问题。

2.3 字符设备框架的演进：从register_chrdev到cdev

早期Linux内核用register_chrdev()注册字符设备，简单粗暴，但有个致命问题：它一次性占用主设备号下的所有次设备号。如果你只需要一个设备，却占用了256个次设备号，其他驱动就没得用了。后来引入了cdev机制，可以精确注册次设备号范围，配合alloc_chrdev_region()动态分配主设备号，灵活了很多。

现在的标准做法是：用alloc_chrdev_region()申请设备号，用cdev_init()和cdev_add()注册字符设备，用class_create()和device_create()自动创建设备节点。这样加载驱动之后，/dev下面会自动出现设备文件，不需要手动mknod。

我见过很多教程还在用register_chrdev()，不是说不能用，但在新项目里最好用新接口。内核社区对旧接口的维护力度在下降，而且新接口的扩展性更好。比如你要支持多个次设备号，cdev机制天然支持，register_chrdev就得自己想办法。

3. 核心细节解析与实操要点

3.1 GPIO驱动：最简单的驱动也有坑

GPIO驱动是入门首选，但里面有不少细节容易翻车。首先是GPIO编号的计算。在嵌入式Linux里，GPIO通常按组管理，比如GPIO1_IO05这种命名。内核里用gpio_request()申请GPIO时，需要传入一个全局编号。这个编号的计算方式是：组号 * 每组引脚数 + 组内偏移。不同芯片的每组引脚数不一样，i.MX6ULL是32，STM32MP1也是32，但有些芯片是16。这个信息在芯片手册的GPIO章节里有。

其次是方向设置。gpio_direction_output()和gpio_direction_input()必须在gpio_request()之后调用，否则会失败。输出电平用gpio_set_value()，读取用gpio_get_value()。注意gpio_get_value()在输出模式下也能读，读的是实际引脚电平，不是输出寄存器里的值。这个区别在调试的时候很有用，比如你设置了高电平但读回来是低，说明引脚被外部电路拉低了。

还有一个坑是GPIO的复用功能。很多引脚默认不是GPIO功能，而是其他外设功能，比如UART、I2C。你需要先通过IOMUX控制器把引脚配置成GPIO模式，才能用GPIO接口操作。这个配置通常在设备树里用pinctrl节点描述，驱动里不需要手动改寄存器。

/* 典型的GPIO操作流程 */ int gpio_num = of_get_named_gpio(dev->of_node, "led-gpios", 0); if (!gpio_is_valid(gpio_num)) { dev_err(dev, "invalid GPIO\n"); return -EINVAL; } ret = devm_gpio_request(dev, gpio_num, "led"); if (ret) { dev_err(dev, "failed to request GPIO\n"); return ret; } gpio_direction_output(gpio_num, 0); gpio_set_value(gpio_num, 1);

用devm_前缀的函数有个好处：设备卸载时自动释放资源，不需要手动gpio_free()。这个机制叫“设备资源管理”，能省掉很多清理代码，也避免了资源泄漏。

3.2 中断处理：上半部和下半部怎么分

中断是驱动开发里最容易出问题的地方。核心原则就一条：中断处理函数要尽可能短。为什么？因为中断处理期间，CPU不能响应同级和更低优先级的中断，如果处理时间太长，系统响应会变差，甚至丢中断。

Linux把中断处理分成上半部（top half）和下半部（bottom half）。上半部就是request_irq()注册的那个函数，它在中断上下文中执行，不能睡眠，不能调用可能阻塞的函数。下半部有几种实现方式：softirq、tasklet、workqueue。softirq性能最好但用得少，tasklet基于softirq但更易用，workqueue运行在进程上下文，可以睡眠。

选择哪种下半部，取决于你的任务特性。如果任务很短且不需要睡眠，用tasklet。如果任务可能睡眠，比如要调用I2C读写，必须用workqueue。我见过有人在中断上半部里调用i2c_transfer()，结果系统直接卡死，因为I2C传输会睡眠，而中断上下文不允许睡眠。

/* 中断上半部 */ static irqreturn_t my_interrupt_handler(int irq, void *dev_id) { struct my_dev *dev = dev_id; /* 清除中断标志 */ writel(0x1, dev->base + INT_STATUS_REG); /* 调度下半部 */ schedule_work(&dev->work); return IRQ_HANDLED; } /* 下半部 */ static void my_work_handler(struct work_struct *work) { struct my_dev *dev = container_of(work, struct my_dev, work); /* 这里可以睡眠，可以调用I2C/SPI */ i2c_transfer(dev->client->adapter, &msg, 1); }

中断共享也是常见需求。多个设备共用一根中断线时，request_irq()的flags要加IRQF_SHARED，并且每个设备都要传一个唯一的dev_id。中断处理函数里要先判断是不是自己的中断，不是就返回IRQ_NONE。这个判断通常靠读中断状态寄存器实现。

3.3 并发控制：自旋锁和互斥锁怎么选

驱动运行在多核系统上，并发访问是常态。用户态可能有多个进程同时打开设备文件，中断可能随时打断驱动代码，内核线程也可能访问共享数据。不加锁，数据竞争迟早出问题。

Linux提供了几种锁机制：自旋锁（spinlock）、互斥锁（mutex）、信号量（semaphore）、读写锁（rwlock）。选择依据是：临界区会不会睡眠。不会睡眠用自旋锁，会睡眠用互斥锁。中断上下文只能用自旋锁，因为中断上下文不允许睡眠。

自旋锁的原理是忙等待，获取不到锁就原地循环。所以临界区必须非常短，否则浪费CPU。互斥锁获取不到会睡眠，让出CPU给其他任务，适合临界区较长的场景。

/* 自旋锁示例：中断上下文和进程上下文共享数据 */ static DEFINE_SPINLOCK(my_lock); static int shared_data; /* 进程上下文 */ static ssize_t my_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { unsigned long flags; spin_lock_irqsave(&my_lock, flags); shared_data = 1; spin_unlock_irqrestore(&my_lock, flags); return count; } /* 中断上下文 */ static irqreturn_t my_isr(int irq, void *dev_id) { spin_lock(&my_lock); shared_data = 2; spin_unlock(&my_lock); return IRQ_HANDLED; }

注意spin_lock_irqsave()和spin_lock()的区别。如果中断上下文也会获取同一把锁，进程上下文必须用spin_lock_irqsave()，在获取锁的同时关中断，否则可能死锁：进程拿了锁，中断来了想拿同一把锁，中断自旋等待，但进程被中断打断无法释放锁，死锁。这个坑我踩过，调试了一整天才定位到。

3.4 设备树与驱动匹配的完整流程

设备树节点和驱动的匹配过程，很多人只知道compatible属性，但不知道内核具体怎么走的。完整流程是这样的：内核启动时解析DTB，为每个节点创建device_node，然后对于有compatible属性的节点，创建platform_device。驱动注册时，platform_driver结构体里的of_match_table包含一组compatible字符串。内核遍历所有platform_device，用of_match_node()比较compatible，匹配成功就调用驱动的probe函数。

probe函数里要做几件事：获取设备树里的资源（寄存器地址、中断号、GPIO、时钟等），初始化硬件，注册字符设备或输入设备等接口。如果probe返回非零，匹配失败，驱动不会加载。

static const struct of_device_id my_of_match[] = { { .compatible = "vendor,my-device" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_of_match); 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);

MODULE_DEVICE_TABLE的作用是让内核在模块加载前就知道这个驱动支持哪些设备，方便自动加载。没有这个宏，模块需要手动insmod。

4. 实操过程与核心环节实现

4.1 从零写一个完整的platform驱动

我拿一个实际的温湿度传感器驱动为例，传感器是SHT30，通过I2C接口通信。这个例子涵盖了platform驱动、I2C子系统、字符设备、sysfs等核心知识点。

第一步是写设备树节点。SHT30挂在I2C1总线上，地址是0x44。设备树里这样描述：

&i2c1 { status = "okay"; clock-frequency = <100000>; sht30: sht30@44 { compatible = "vendor,sht30"; reg = <0x44>; status = "okay"; }; };

第二步是写驱动代码。SHT30的驱动可以基于I2C驱动框架写，也可以用platform驱动加i2c_client的方式。我选择I2C驱动框架，因为传感器本身就是I2C设备，用I2C框架更自然。

#include <linux/module.h> #include <linux/i2c.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/uaccess.h> #define SHT30_MEASURE_HIGH 0x2C06 #define SHT30_READ_LEN 6 struct sht30_dev { struct i2c_client *client; struct cdev cdev; dev_t devno; struct class *class; struct device *device; struct mutex lock; }; static int sht30_read_temp_humi(struct sht30_dev *dev, int *temp, int *humi) { u8 cmd[2] = { SHT30_MEASURE_HIGH >> 8, SHT30_MEASURE_HIGH & 0xFF }; u8 buf[SHT30_READ_LEN]; struct i2c_msg msgs[2]; int ret; msgs[0].addr = dev->client->addr; msgs[0].flags = 0; msgs[0].len = 2; msgs[0].buf = cmd; msgs[1].addr = dev->client->addr; msgs[1].flags = I2C_M_RD; msgs[1].len = SHT30_READ_LEN; msgs[1].buf = buf; ret = i2c_transfer(dev->client->adapter, msgs, 2); if (ret < 0) return ret; *temp = (buf[0] << 8) | buf[1]; *humi = (buf[3] << 8) | buf[4]; return 0; }

第三步是注册字符设备，提供open、read、release接口。read接口里调用sht30_read_temp_humi()，把温湿度数据拷贝到用户空间。

static ssize_t sht30_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { struct sht30_dev *dev = filp->private_data; int temp, humi; char kbuf[64]; int len; if (mutex_lock_interruptible(&dev->lock)) return -ERESTARTSYS; if (sht30_read_temp_humi(dev, &temp, &humi)) { mutex_unlock(&dev->lock); return -EIO; } len = snprintf(kbuf, sizeof(kbuf), "temp=%d.%d humi=%d.%d\n", temp / 100, temp % 100, humi / 100, humi % 100); if (copy_to_user(buf, kbuf, len)) { mutex_unlock(&dev->lock); return -EFAULT; } mutex_unlock(&dev->lock); return len; }

第四步是probe函数，初始化设备、注册字符设备、创建sysfs节点。

static int sht30_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct sht30_dev *dev; int ret; dev = devm_kzalloc(&client->dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev->client = client; i2c_set_clientdata(client, dev); mutex_init(&dev->lock); ret = alloc_chrdev_region(&dev->devno, 0, 1, "sht30"); if (ret) return ret; cdev_init(&dev->cdev, &sht30_fops); dev->cdev.owner = THIS_MODULE; ret = cdev_add(&dev->cdev, dev->devno, 1); if (ret) goto err_cdev; dev->class = class_create(THIS_MODULE, "sht30"); if (IS_ERR(dev->class)) { ret = PTR_ERR(dev->class); goto err_class; } dev->device = device_create(dev->class, NULL, dev->devno, NULL, "sht30"); if (IS_ERR(dev->device)) { ret = PTR_ERR(dev->device); goto err_device; } dev_info(&client->dev, "sht30 probed successfully\n"); return 0; err_device: class_destroy(dev->class); err_class: cdev_del(&dev->cdev); err_cdev: unregister_chrdev_region(dev->devno, 1); return ret; }

这个驱动加载之后，/dev/sht30会出现，cat /dev/sht30就能读到温湿度数据。整个过程涵盖了I2C通信、字符设备、互斥锁、设备资源管理，是一个比较完整的驱动开发案例。

4.2 中断按键驱动的非阻塞扫描实现

按键驱动是另一个经典场景。很多教程用轮询方式读按键，但轮询浪费CPU，而且响应不及时。正确做法是用中断，按键按下时触发中断，在中断下半部里处理消抖和键值上报。

非阻塞扫描的意思是，用户态读取按键时，如果没有按键事件，read()应该立即返回-EAGAIN，而不是阻塞等待。这需要驱动支持O_NONBLOCK标志，并且用等待队列实现阻塞和非阻塞两种模式。

static ssize_t key_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { struct key_dev *dev = filp->private_data; int ret; if (filp->f_flags & O_NONBLOCK) { if (kfifo_is_empty(&dev->fifo)) return -EAGAIN; } else { if (wait_event_interruptible(dev->wq, !kfifo_is_empty(&dev->fifo))) return -ERESTARTSYS; } ret = kfifo_out(&dev->fifo, &dev->key_val, sizeof(dev->key_val)); if (ret != sizeof(dev->key_val)) return -EIO; if (copy_to_user(buf, &dev->key_val, sizeof(dev->key_val))) return -EFAULT; return sizeof(dev->key_val); }

中断处理里用kfifo缓存键值，然后唤醒等待队列。kfifo是内核提供的无锁环形缓冲区，适合单生产者单消费者场景，中断里写入，用户态读取，正好匹配。

消抖用定时器实现。按键中断触发后，启动一个10ms的定时器，定时器到期后再读引脚电平，如果还是按下状态，才认为是有效按键。这样避免了机械抖动导致的多次触发。

static irqreturn_t key_isr(int irq, void *dev_id) { struct key_dev *dev = dev_id; mod_timer(&dev->debounce_timer, jiffies + msecs_to_jiffies(10)); return IRQ_HANDLED; } static void debounce_timer_func(struct timer_list *t) { struct key_dev *dev = from_timer(dev, t, debounce_timer); int val = gpio_get_value(dev->gpio); if (val == 0) { dev->key_val = dev->key_code; kfifo_in(&dev->fifo, &dev->key_val, sizeof(dev->key_val)); wake_up_interruptible(&dev->wq); } }

这个方案实测很稳，按键响应延迟在10ms左右，CPU占用几乎为零。比轮询方案优雅得多。

4.3 嵌入式Linux根文件系统挂载与NFS调试

开发阶段用NFS挂载根文件系统能极大提高效率。每次改驱动不用重新烧写整个系统，编译完模块直接insmod就行。配置NFS根文件系统需要几个步骤。

首先是主机端配置。安装NFS服务，编辑/etc/exports，添加导出目录：

/home/rootfs *(rw,sync,no_root_squash,no_subtree_check)

no_root_squash很重要，否则客户端root用户会被映射成nobody，导致权限问题。然后启动NFS服务：

sudo exportfs -a sudo systemctl restart nfs-kernel-server

目标板端需要配置内核支持NFS根文件系统，启动参数里指定：

setenv bootargs 'console=ttyS0,115200 root=/dev/nfs rw nfsroot=192.168.1.100:/home/rootfs,v3,tcp ip=192.168.1.200'

v3指定NFS版本3，tcp指定传输协议。有些老内核只支持NFS v2，需要根据实际情况调整。ip参数是目标板的IP地址，必须和主机在同一网段。

注意：NFS根文件系统依赖网络，如果网络不稳定，系统会卡死。生产环境不要用NFS，只适合开发调试。

我踩过的一个坑是：主机防火墙没关，NFS端口被挡了，目标板一直卡在“VFS: Cannot open root device”。排查了半天才发现是防火墙问题。所以调试NFS的时候，先把防火墙关了，确认能挂载之后再慢慢加规则。

5. 常见问题与排查技巧实录

5.1 驱动加载失败怎么查

驱动加载失败是最常见的问题，insmod之后报错信息往往很模糊。我的排查顺序是这样的：

先看dmesg，内核打印的错误信息比insmod的返回值详细得多。常见错误有-ENODEV（设备没匹配上）、-EBUSY（资源被占用）、-EINVAL（参数无效）。-ENODEV通常是设备树compatible不匹配，检查设备树节点和驱动的of_match_table是否一致。-EBUSY可能是GPIO或中断被其他驱动占了，用cat /proc/gpio和cat /proc/interrupts查看。

然后看/sys/bus/platform/drivers/下面有没有你的驱动目录。如果有目录但里面没有设备链接，说明驱动注册了但没匹配到设备。如果连目录都没有，说明驱动注册本身失败了。

还有一个工具是devmem，可以直接读写物理地址，验证硬件是否正常。比如你怀疑GPIO寄存器没配置对，用devmem 0x020A0000读一下IOMUX寄存器的值，和手册对比。

5.2 中断不触发的排查思路

中断不触发的原因很多，我整理了一个排查表：

中断号错误是最常见的。设备树里的interrupts属性格式是<中断类型 中断号 触发方式>，不同中断控制器的编码方式不一样。比如GIC控制器，SPI中断的号是中断号 - 32。这个转换关系在手册的中断章节里有。

5.3 内存泄漏和竞态条件的调试

驱动里的内存泄漏很难发现，因为内核模块卸载时不会自动释放kmalloc的内存。用devm_kzalloc()可以避免大部分泄漏，但有些场景必须手动管理。/proc/meminfo可以看整体内存变化，但精度不够。更好的工具是kmemleak，内核配置里打开CONFIG_DEBUG_KMEMLEAK，然后echo scan > /sys/kernel/debug/kmemleak触发扫描，cat /sys/kernel/debug/kmemleak查看泄漏点。

竞态条件更隐蔽，可能运行几天才出一次问题。KASAN（Kernel Address Sanitizer）能检测越界访问和释放后使用，CONFIG_KASAN=y打开。lockdep能检测锁的顺序问题，CONFIG_PROVE_LOCKING=y打开。这两个工具会拖慢系统，只在调试阶段用。

我遇到过一个经典竞态：驱动里用全局变量缓存数据，中断里写，用户态读，没加锁。大部分时候没问题，但压力测试跑几个小时就会读到半新半旧的数据。后来加了自旋锁就解决了。所以共享数据一定要加锁，不要心存侥幸。

5.4 嵌入式面试中驱动相关的高频问题

面试嵌入式驱动岗位，有几个问题几乎必问。第一个是“中断上半部和下半部的区别”，这个前面讲过了。第二个是“自旋锁和互斥锁的区别及使用场景”，核心就是会不会睡眠。第三个是“设备树的作用和匹配流程”，要能说清楚compatible、probe、of_match_table的关系。

还有一个高频问题是“驱动里怎么实现阻塞和非阻塞IO”。答案是用等待队列，非阻塞模式下检查条件不满足就返回-EAGAIN，阻塞模式下用wait_event_interruptible()睡眠等待。poll接口也要实现，支持select和epoll。

“字符设备和块设备的区别”也是常问的。字符设备按字节流访问，不支持随机访问，比如串口、按键。块设备按块访问，支持随机访问，有缓存机制，比如硬盘、Flash。块设备的驱动框架比字符设备复杂得多，有bio、request queue、电梯算法等。

6. 驱动开发的进阶方向与学习路线

6.1 从字符设备到子系统框架

字符设备驱动是基础，但实际项目里很少从头写字符设备。大部分外设都有现成的子系统框架：I2C设备用I2C驱动框架，SPI设备用SPI框架，输入设备用input子系统，显示设备用framebuffer或DRM，网络设备用netdev。这些框架帮你处理了大部分通用逻辑，你只需要实现硬件相关的部分。

以input子系统为例，按键驱动不需要自己实现字符设备，只需要调用input_allocate_device()、input_set_capability()、input_register_device()，然后在中段里用input_report_key()和input_sync()上报事件。内核会自动创建/dev/input/eventX设备节点，用户态用evdev接口读取。这样代码量少了很多，而且兼容标准输入协议。

6.2 GPU驱动和AI加速器驱动的门槛

GPU驱动和AI加速器驱动是嵌入式驱动里门槛最高的方向。GPU驱动涉及图形管线、着色器、内存管理、命令调度，代码量动辄几十万行。AI加速器驱动涉及DMA、张量计算、量化、算子融合，需要对深度学习框架有理解。

这两个方向的学习路径是：先精通字符设备和DMA驱动，理解内存映射和缓存一致性，然后学习具体硬件的架构手册。GPU驱动可以看Mesa和DRM的源码，AI加速器驱动可以看NPU厂商的开源驱动。门槛高意味着竞争少，薪资也高，但需要投入大量时间。

6.3 嵌入式AI测试与驱动的关系

嵌入式AI测试是最近的热词，它和驱动开发的关系在于：AI模型跑在NPU上，NPU驱动负责把模型加载到硬件、分配内存、调度计算任务。测试AI性能时，驱动层的效率直接影响推理延迟。比如DMA传输没用好，数据搬运时间可能比计算时间还长。

做嵌入式AI测试，需要关注几个驱动层指标：内存分配延迟、DMA带宽、中断响应时间、功耗。这些指标用perf、ftrace、powertop等工具测量。如果发现推理延迟高，先查驱动层有没有优化空间，再查模型本身。

6.4 学习路线建议

如果你刚入行，我的建议是：先玩STM32裸机，理解寄存器操作和中断。然后上嵌入式Linux，学设备树、字符设备、platform驱动。接着学一个子系统框架，I2C或SPI都行。最后找一个实际项目练手，比如用I2C传感器做数据采集，用SPI屏幕做显示，用GPIO做控制。

书方面，《Linux设备驱动开发详解》和《深入理解Linux内核》是必读的。源码方面，从drivers/char/下面的简单驱动看起，然后看drivers/i2c/和drivers/spi/。社区方面，内核邮件列表和lwn.net有很多高质量文章。

我个人在实际操作中的体会是：驱动开发最难的不是写代码，而是调试。硬件不会说话，你只能通过寄存器和波形来判断问题。逻辑分析仪和示波器是必备工具，很多时候比打印调试管用得多。还有就是要养成看手册的习惯，芯片手册里什么都有，只是需要耐心找。