我干嵌入式驱动开发有年头了经常被人问“你这活儿到底在忙什么”。每次听到我都觉得这问题问得好因为很多人对驱动开发的印象停留在“写个hello world、点个灯”这种层面。实际真不是这样嵌入式驱动开发是这个行业里最贴近硬件底层的软件活儿也是连接硬件和操作系统的关键一环。这篇我就把自己的日常工作、踩过的坑、写驱动的完整思路、常用的调试手段以及面试和学习路线上的一些心得掰开揉碎讲一讲。不管你是刚入门的小白还是已经写了几年应用想转驱动的工程师看完应该都能对“嵌入式驱动开发”这件事有个清晰的认知也能知道该往哪个方向使劲儿。1. 嵌入式驱动开发到底在忙什么很多人觉得驱动开发就是“照着芯片手册配寄存器”这说法只对了一半。配寄存器确实是基本功但驱动开发的核心工作远不止这些。往大了说驱动是操作系统和外部硬件之间的桥梁往小了说你要负责让某个具体硬件在内核里正常工作并且把数据以合理的方式交给上层应用。1.1 先把驱动想清楚硬件、内核、应用三层关系驱动开发最容易被忽略的一件事是它夹在硬件和应用之间两头都要懂。硬件侧你要看懂原理图确认芯片引脚接了哪些外设用到了哪组寄存器、哪个中断号、哪条DMA通道。比如你拿到一块板子上面有一颗I2C接口的温湿度传感器你得先看芯片手册确认I2C地址、寄存器地址、数据格式、采样时序这些细节直接决定驱动能不能正常工作。内核侧你要理解Linux内核的驱动模型、总线-设备-驱动框架、设备树、中断子系统、并发机制、内存管理这些东西。不是说非要读透整个内核源码但至少要知道驱动怎么注册、probe函数什么时候被调、read/write回调是怎么走通的。应用侧你得知道应用层是怎么调用驱动的——打开设备文件、read、write、ioctl、mmap这些系统调用是怎么一步一步进入到驱动里的。很多驱动问题表面上是驱动bug实际上是应用用错了接口或者应用和驱动的协议没对齐。这三层互相牵连日常工作的样子就是一会儿翻芯片手册一会儿看内核源码一会儿抓串口日志一会儿又跟硬件工程师对原理图。1.2 一天的活儿长什么样不夸张地说驱动工程师的一天经常是这么过的上午看需求文档发现新项目要调试一颗4G模组需要写一个串口驱动对接中午跟硬件工程师开个小会确认USART引脚没有复用冲突下午开始查内核源码看看现有tty框架能不能直接复用还是需要写个平台驱动晚上在板子上调试用示波器量波形、用dmesg抓内核输出一步步定位问题。这么说可能还是有点虚我举个更具体的例子。有一回我做一颗电容触摸屏的驱动调试板子用I2C接口连接触摸控制芯片。现象是触摸时好时坏有时候按下去没反应过一会儿又自己好了。刚接触这问题第一反应是看看驱动有没有报错结果dmesg干干净净什么异常都没有。后来我用逻辑分析仪抓了I2C总线波形才发现问题根本不在驱动代码逻辑上而是触摸芯片的中断引脚在按键按下时产生了一个极短的低电平脉冲驱动的中断处理函数执行得太慢上下文切换回来之后中断状态已经被复位了于是丢了一次事件。这类问题如果你只盯着代码看折腾一周都可能没结果但把逻辑分析和示波器架上去半小时就定位了。这也让我养成了习惯查驱动问题永远先看波形和数据时序再看代码逻辑顺序反了很容易绕远路。1.3 驱动工程师的核心能力地图搞了这么多年我认为一个合格的驱动工程师能力模型大致包含这几块C语言和计算机体系结构基础指针、内存布局、大小端、位操作、编译链接过程这些是基本功绕不开。Linux内核机制进程调度与上下文、中断上下文、锁机制spinlock、mutex、完成量、工作队列、内核内存分配、设备模型等。具体外设协议GPIO、I2C、SPI、UART、PWM、ADC、看门狗、定时器、DMA、USB、MIPI/LVDS等至少精通其中两三样剩下的能看图就能上手写。硬件调试能力会用万用表、示波器、逻辑分析仪会看原理图和数据手册能读懂时序图。工程交付能力写规范代码、做自测、写文档、跨团队沟通。驱动开发不是写完就完了产品要落地测试和维护同样重要。2. 从零写一个字符设备驱动到底要做什么新手问驱动开发常常不知道从哪下手我的建议始终是先写一个最简的字符设备驱动把它完整走一遍再把内核驱动的套路吃透之后不管是平台驱动、I2C驱动、SPI驱动框架上都差不多。2.1 为什么字符设备驱动是完美的入门入口原因很简单字符设备驱动结构最简单对应关系也最直观。你写一个驱动注册一个设备节点应用层open它、read它、write它数据像水管一样流进去流出来不需要管复杂的协议解析和缓冲管理。在Linux里字符设备驱动最核心的是struct file_operations这个结构体。你可以把它理解为一张“函数表”内核把它和应用层的系统调用对应起来。表格里填了谁应用层调用对应函数时就会走谁。static struct file_operations my_fops { .owner THIS_MODULE, .open my_open, .read my_read, .write my_write, .release my_release, };这段代码就是字符设备驱动的骨架。my_open在应用层调用open(/dev/mydev, ...)时执行my_read在应用层调用read()时执行以此类推。这套机制理解透了字符设备驱动就没什么神秘的了。新手最容易困惑的还有设备号。设备号是内核识别设备的标识分主设备号和次设备号主设备号代表驱动类别次设备号代表具体的设备实例。有两种注册方式手动指定设备号主设备号你自己选一个比如register_chrdev_region()好处是设备节点固定坏处是一不小心就跟现有设备冲突了。动态分配设备号用alloc_chrdev_region()让内核帮你挑一个然后用mknod或者udev在用户空间生成节点这种更灵活也是现代驱动的通行做法。我个人强烈建议新人在自己的板子上用alloc_chrdev_region()然后从/proc/devices里读出分配到的设备号再手动mknod /dev/xxx c 主号 次号。这个过程走一遍你对设备号的理解会比背十遍书都牢。2.2 动手写一个点灯驱动从代码到实验点灯是驱动开发界的“hello world”我拿它来走一遍全流程。假设板子上有一颗LED接在GPIO1_IO18引脚上对应的GPIO编号是gpiochip里的某个序号先通过设备树确认引脚号和电气属性。一个简化版的驱动长这样#include linux/module.h #include linux/fs.h #include linux/miscdevice.h #include linux/gpio/consumer.h #include linux/platform_device.h static struct gpio_desc *led_gpio; static ssize_t led_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { char value; if (copy_from_user(value, buf, 1)) return -EFAULT; if (value 0) gpiod_set_value(led_gpio, 0); else if (value 1) gpiod_set_value(led_gpio, 1); return count; } static struct file_operations led_fops { .owner THIS_MODULE, .write led_write, }; static struct miscdevice led_miscdev { .minor MISC_DYNAMIC_MINOR, .name led, .fops led_fops, }; static int led_probe(struct platform_device *pdev) { led_gpio devm_gpiod_get(pdev-dev, led, GPIOD_OUT_LOW); if (IS_ERR(led_gpio)) return PTR_ERR(led_gpio); return misc_register(led_miscdev); } static int led_remove(struct platform_device *pdev) { misc_deregister(led_miscdev); return 0; } static const struct of_device_id led_of_match[] { { .compatible myvendor,led, }, { } }; MODULE_DEVICE_TABLE(of, led_of_match); static struct platform_driver led_driver { .probe led_probe, .remove led_remove, .driver { .name my_led, .of_match_table led_of_match, }, }; module_platform_driver(led_driver); MODULE_LICENSE(GPL);写完编译成.ko文件拷贝到板子上insmod led.ko如果设备和驱动匹配成功/dev/led节点就出现了。然后应用层操作echo 1 /dev/led echo 0 /dev/ledLED跟着亮灭整个过程就算跑通了。这里有个很多人会忽略的点现代Linux驱动推荐用devm_开头的资源管理接口比如上面代码里的devm_gpiod_get()。这类接口的好处是自动释放机制——如果初始化失败内核会自动帮你释放已经申请的资源不需要你手动写一堆错误处理代码。用老式接口的话你每一步都要检查返回值漏一个错误分支就可能造成资源泄漏。2.3 设备树硬件信息从哪来写完驱动之后你得回答一个问题驱动怎么知道LED接在哪个引脚上答案就是设备树。设备树是Linux用来描述硬件信息的一种数据结构它把“硬件长什么样”和“驱动怎么工作”解耦了。硬件工程师改了引脚软件不用改驱动代码改设备树就行。设备树的基本结构是节点和属性节点代表一个设备属性描述设备的特征。上面那个LED驱动的设备树节点大概长这样/ { myled: my-led { compatible myvendor,led; led-gpios gpio1 18 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 pinctrl_led; }; };这里几个字段的含义compatible匹配字符串驱动里的of_match_table就靠它跟设备对上。led-gpios描述用的GPIO是哪组、哪根脚、有效电平是高还是低。GPIO_ACTIVE_LOW说明低电平点亮。pinctrl-0引脚复用配置告诉内核这个引脚是GPIO功能而不是UART或其它功能。设备树解析这块驱动里通过devm_gpiod_get()自动完成你不必手动从设备树里读gpios属性GPIO子系统会帮你做好。这套机制理解清楚之后你再去看SPI、I2C、PWM驱动的源码会发现套路完全一样只是获取的句柄类型不同而已。3. 深入总线与外设驱动真正的挑战才刚开始字符设备驱动只是入门。实际项目里你碰到最多的还是各种总线设备和外设I2C上挂传感器SPI上挂FlashUSB上插U盘MIPI/LVDS输出显示画面。这一层是驱动开发的深度所在。3.1 GPIO、中断与并发驱动最容易翻车的地方先说中断。几乎每个驱动都会用到中断比如GPIO按键按下、触摸屏触摸、DMA传输完成都需要中断来通知CPU。请求中断的代码很简单irq gpiod_to_irq(gpio_desc); ret request_threaded_irq(irq, NULL, my_threaded_handler, IRQF_TRIGGER_FALLING | IRQF_ONESHOT, my_dev, priv);但这里面的门道很深。中断处理函数分为上半部和下半部上半部要求快速执行不能睡觉不能调用可能睡眠的函数下半部可以用线程化中断、工作队列等方式做耗时处理。IRQF_TRIGGER_FALLING指定下降沿触发如果方向设错了中断可能永不触发或者疯狂触发。IRQF_ONESHOT是配合线程化中断用的保证在处理完之前不会再次触发同一个中断。我第一次写中断驱动的教训就是在中断处理函数里调用了一个会睡眠的I2C读操作结果板子一按按键就死机最后看内核oops信息才发现自己在中断上下文里睡眠了。后来我彻底养成习惯凡是在中断回调里拿不到锁就睡不着觉拿到锁就得掂量一下这个锁会不会睡眠。再说并发这是驱动开发最考验功底的部分。中断来了可能打断正在执行的代码两个CPU核可能同时跑驱动用户空间可能同时有多个进程打开同一个设备。驱动里共享的数据必须用锁来保护。内核里常见的锁有几种选型原则大致是中断上下文只能用自旋锁spinlock因为spinlock不会睡眠等锁的时候死等。进程上下文可以用互斥锁mutex或信号量等锁的时候可以睡觉把CPU让出去。读多写少的场景用读写锁rwlock提高读并发性能。原子变量atomic_t适合只做计数、加减这种简单操作连锁都省了。我在经验帖里看过一句话非常赞同“锁的选择本质是对性能、实时性和正确性的权衡。”内核社区不是随便定规矩的每个设计背后都是一堆血泪教训。3.2 I2C驱动框架从一颗传感器说起I2C外设在嵌入式里太常见了温度传感器、触摸屏、EEPROM、PMIC基本都是I2C接口。以一颗假想的温度传感器为例完整的I2C驱动注册流程是这样的static const struct i2c_device_id tmp101_ids[] { { tmp101, 0 }, { } }; static const struct of_device_id tmp101_of_match[] { { .compatible ti,tmp101, }, { } }; static struct i2c_driver tmp101_driver { .probe tmp101_probe, .remove tmp101_remove, .id_table tmp101_ids, .driver { .name tmp101, .of_match_table tmp101_of_match, }, }; module_i2c_driver(tmp101_driver);I2C驱动的核心套路是设备树里描述I2C控制器上挂了哪些设备、各自地址是多少I2C核心会根据compatible匹配到驱动然后调用驱动的probe函数。probe函数里的典型动作就是通过i2c_client结构体拿到设备地址然后调用i2c_smbus_read_byte_data()这类接口读写寄存器。因为I2C是慢速总线这些操作会睡眠所以只能在进程上下文调用不能放在中断上半部。这里特别提醒一点写I2C驱动时一定要看芯片手册里的时序要求很多传感器上电之后需要等一段时间才能访问有些寄存器必须先写一个配置字才能进入测量模式。这些细节驱动里都要通过延时或者初始化序列来保证。我曾经因为漏了芯片手册里“上电后需要延时10ms”这一句导致驱动加载后第一次读温度返回的全是0xff排查了好几个小时。3.3 MIPI/LVDS显示驱动为什么不简单显示这块很多做应用开发的同事会低估它的复杂度但只要做过MIPI或LVDS驱动的人都知道这里最容易出幺蛾子。MIPI DSI和LVDS是两种常用显示接口协议。LVDS走的是差分信号适合长距离、高分辨率传输MIPI DSI走的是高速串行数据常用于手机和平板这类移动设备。两者在驱动层面都要配置显示控制器的时序参数——像素时钟、行列同步信号、 porch值等等任何一个参数不对屏幕要么不亮要么花屏要么闪烁。驱动代码的作用本质上是把显示芯片的时序参数填进显示控制器的寄存器里再拉起背光、使能输出。但因为LCD模组厂商给的时序参数通常都是推荐值而不是绝对约束实际调试时你需要在推荐值附近做微调。这时候最有效的工具不是代码而是示波器和眼睛——拿示波器量一下行场同步信号的实际周期算出来跟期望差多少再对照屏幕现象去改参数。我踩过的一个典型坑是MIPI屏初始化代码缺少足够的上电时序延时屏幕偶尔能点亮偶尔点不亮后来对比模组规格书才发现电源稳定到拉复位信号之间需要严格的延时驱动代码只延时了规格书要求的一半所以时好时坏。说说好排查但当时困扰了我快两天。3.4 USB设备驱动从CP2102的PID/VID说起USB驱动在整个驱动开发里是另一个大类常见的是做USB转串口、USB摄像头、U盘、HID键盘鼠标等。USB设备比较特殊的地方在于它有一个标准化的枚举流程设备和主机通过描述符互相认识。很多人自己动手做过CP2102这类USB转串口芯片的调试经常会遇到一个问题Windows或Linux下识别出来的设备名不期望或者需要改驱动。就是因为CP2102有自己的PID产品ID和VID厂商ID每个USB设备都有这两个标识系统根据PID/VID决定加载哪个驱动。Linux下写USB驱动时就是把这个匹配关系写进驱动里static const struct usb_device_id cp210x_ids[] { { USB_DEVICE(0x10C4, 0xEA60) }, { } }; MODULE_DEVICE_TABLE(usb, cp210x_ids);这里的0x10C4是Silicon Labs的VID0xEA60是CP2102常用的PID。驱动加载后USB核心发现设备号匹配就会调用probe函数创建一个tty设备或其它类型的设备节点。USB驱动里最考验人的还不是匹配而是URBUSB Request Block的管理、批量传输的缓冲处理、热插拔时的资源清理。一个USB设备拔掉之后驱动要能干净利落地释放资源重新插上之后要能再正常工作这一套做好了说明你对驱动生命周期管理已经很熟了。3.5 DMA、定时器、PWM等底层机制除了总线和外设驱动开发还会大量接触底层机制。DMA用于大块数据的搬运比如从SD卡读数据、网卡收发数据。DMA驱动要处理的关键问题是描述符的分配和轮转、缓存一致性的处理、中断通知的时机。一个常见的坑是CPU读取的外设数据在cache里但DMA已经把数据写到内存里了如果不做cache一致性操作读到的可能是陈旧数据。定时器内核定时器、高精度定时器hrtimer、clockevent和clocksource框架常用于延时、超时判断、周期采样。PWM调亮度、调音量、控制电机转速。PWM驱动关键就是占空比和频率的配置、极性选择以及和背光或电机驱动芯片的配合。这一类机制单个看都不算复杂但组合在一起对整体系统的影响就很大了。我经常提醒同事的一句话是驱动代码看着是“控制某个外设”实际上是在跟整个系统的时序、性能和实时性打交道。4. 驱动开发的调试手段与工具链别光靠printk调试是驱动开发里占比极高的一项工作。写代码可能只花三成时间剩下七成都在调试和排查问题。调试手段丰富程度直接决定你解决问题的速度。4.1 内核日志与打印的进阶用法printk是内核最基础的调试手段但很多新手只知道用它不知道怎么用好它。printk有日志级别从最高优先级KERN_EMERG到最低的KERN_DEBUG。默认情况下级别低于KERN_DEBUG的信息不会打印到控制台而是可能进到内核日志缓冲区。我建议新手先记住这几个常用级别KERN_ERR错误系统功能失效级别通常立即关注。KERN_WARNING警告不影响功能但需要关注。KERN_INFO提示比如驱动注册成功、设备节点创建成功。KERN_DEBUG调试信息默认可能不显示需要动态调试开启。但printk有个问题打印多了会影响实时性而且发布版里不应该有一堆调试打印。所以现代内核更推荐用dev_dbg()配合动态调试机制dynamic debug。dev_dbg把打印挂到设备上不仅能看到驱动名称、函数名和行号还能在运行时通过debugfs动态开关不需要重编译内核。操作方式是在内核配置里打开CONFIG_DYNAMIC_DEBUG挂载debugfs之后echo file my_driver.c p /sys/kernel/debug/dynamic_debug/control这条命令的意思是打开my_driver.c里所有dev_dbg的打印。不用重新编译不用重新加载驱动调试完了一句-p就关掉了。4.2 内核Oops信息与调用栈分析内核崩溃是驱动开发的家常便饭。一个空指针解引用、一次越界访问、一次非法内存操作都可能让内核直接Oops甚至panic。很多新手看到满屏的Oops信息立刻就慌了其实这玩意儿是调试里最有价值的东西。Oops信息最重要的是看这几块出错的地址和指令比如Unable to handle kernel NULL pointer dereference at virtual address ...说明访问了空指针。调用栈Call trace从下往上读能看出是在哪个函数、什么路径上出的问题。寄存器的值尤其是LR链接寄存器、PC程序计数器多出来的信息能帮你定位是哪个函数调用链。拿到这些信息之后先在源码里定位对应函数再把函数里可能访问空指针、可能越界的地方列出来基本就能定位问题。我用这个方法解决过好几次看起来完全没有头绪的崩溃问题所以很推荐新手刻意训练自己读Oops的能力而不是一看到就发截图问别人。4.3 硬件调试工具示波器、逻辑分析仪、万用表驱动开发的调试不能只停留在软件层面。示波器量波形、量时序、看电源纹波。调试I2C、SPI、UART信号时示波器能直接告诉你数据线上的电平跳变是否符合预期。逻辑分析仪抓总线协议数据。调试I2C设备时接上逻辑分析仪能把主机和设备之间的交互完整解析出来地址对不对、ACK有没有、数据对不对一目了然。万用表量电压通断查短路断路。有些问题其实就是引脚虚焊、电源没上电用万用表一量就知道了。我这几年有个体会很多驱动bug的根因并不在代码里而是硬件层面的信号问题、电源问题、时序问题。如果只会在软件层面转圈很多问题会卡到你怀疑人生。反过来学会看波形、看时序很多“灵异现象”一下子就解释通了。4.4 常用调试命令和使用心得在实际板卡调试时下面几个命令是我几乎每天都会用到的dmesg看内核日志排查启动和运行时的错误信息。cat /proc/devices看当前注册的字符设备主设备号。lsmod、rmmod、insmod管理模块加载卸载。cat /sys/kernel/debug/gpio看GPIO状态、复用方向和当前值。strace ./test_app跟踪应用层程序执行了哪些系统调用能快速确认应用到底有没有成功打开设备、有没有调用驱动的读写接口。top、cat /proc/interrupts看中断触发的次数和频率确认中断是不是真的来了。有个很典型的排查案例应用层说读不到数据我第一反应是看驱动有没有问题折腾半天没头绪。后来用strace跟了一下发现应用压根没有打开设备文件因为路径写错了。这类问题在调试中最常见复盘起来很简单但当场就是能卡你半天。5. 项目实战中高频问题的排查经验驱动开发里有些问题属于“高频经典”我整理一个速查表顺手把排查思路写进去照着排查会快很多。现象可能原因排查思路模块加载失败报错Unknown symbol依赖的符号未导出或依赖模块未加载用modinfo查看依赖确认依赖模块已insmod用nm查符号导出设备树匹配成功但probe没被调用compatible不匹配、节点没使能cat /proc/device-tree查看设备树确认驱动和设备树的compatible字符串完全一致设备节点不存在misc设备注册失败或udev规则缺失看dmesg确认注册信息手动mknod临时验证中断不触发引脚复用错误、触发沿错误、中断号不对用cat /proc/interrupts看中断计数确认引脚复用配置正确内存访问异常Oops在驱动函数里缓冲区越界、空指针、并发竞争读调用栈定位检查copy_from_user/copy_to_user的返回值外设数据始终是0xFFI2C时序不对、设备没上电、地址错误用逻辑分析仪抓I2C波形确认ACK和地址驱动里调sleep导致死机在中断上下文或持有自旋锁时睡眠检查代码里是否在中断回调、spinlock临界区内调用了会睡眠的函数卸载模块崩溃资源释放顺序错误、并发访问未同步检查remove函数里的释放顺序确认中断已在release前注销数据错乱偶发性DMA cache一致性、竞争确认DMA缓冲是否需要cache操作用lockdep检查锁的使用是否规范这里补充两个我从实战里总结出来的经验写进文档里很少有人提但对排查非常管用。第一个经验是排查驱动问题永远先从硬件侧或者接口侧入手别先从逻辑侧入手。先量电压、抓波形、看中断计数、看时序确认物理层是好的再进入代码逻辑排查。很多所谓“驱动bug”最后都被证明是硬件焊接问题、电源问题、干扰问题。第二个经验是临时改驱动时尽量用动态调试而不是大量添加printk。大量printk会让你淹没在日志里而且可能改变程序的时序导致问题现象都不一样了。用动态调试控制打印开关只打你需要的那几个点效率高得多。还记得我刚入行时遇到过一次最崩溃的排查驱动代码反复检查了三四遍逻辑没有问题硬件原理图也对得上但设备就是工作不正常。最后无意中看到示波器上时钟边沿有毛刺再查下去发现是PCB layout上晶振附近铺铜有问题串扰导致时钟信号异常。这个案例让我彻底明白了驱动开发真的不只是写代码看不见的信号完整性、电源完整性也是你要关心的范围。6. 面试与学习路线怎样才能真正入门到进阶聊了一堆实战最后说说面试和学习。这应该是很多初学者最关心的话题。6.1 面试常考的核心八股到底考什么“嵌入式八股”这个词现在很流行其实说白了就是内核与计算机体系结构的基础知识。面试官考八股不是为了刁难人而是为了快速判断候选人有没有底子。我平时在面试别人时最看重以下几类问题用户态和内核态的区别是什么系统调用流程是怎样的中断上下文和进程上下文的区别为什么中断上下文不能睡觉spinlock和mutex的区别分别在什么场景用设备模型里bus、device、driver是什么关系设备树的作用是什么compatible匹配机制是什么字符设备、块设备、网络设备的区别内核模块的加载流程是什么initcall机制了解吗DMA和cache一致性是怎么处理的这些问题不是背下来就完事面试官随便往深里一问比如“那你说说我注册一个设备节点应用层open它的时候内核到底经历了哪些步骤”就得靠你对整套体系结构的真实理解了。我的建议是不要只背八股要把每个问题对应的代码路径看完。比如系统调用流程你可以自己写一个简单的驱动在open和read里打印函数调用栈dump_stack()然后应用层调一次open、一次readdmesg里就能看到完整的内核调用路径。看完一遍比背十遍八股都管用。6.2 一条建议驱动的学习路线学习路线这个东西网上版本很多我按自己带人的经验整理一条大家都能走的路径按顺序来第一阶段扎实C语言和操作系统基础。指针、结构体、链表、编译链接、进程、线程、同步互斥都要熟练。不会这些直接上驱动寸步难行。第二阶段建立一个Linux开发环境装好交叉编译工具链在虚拟机上先玩明白Linux基础命令和系统编程文件操作、进程、信号等。第三阶段上手Linux内核模块开发从最简单hello_world.ko开始一步步增加设备号注册、设备节点、file_operations、ioctl把字符设备驱动整套流程跑通。第四阶段学习设备树和平台驱动搞清楚设备树语法和匹配机制然后试着把字符设备驱动改造成platform驱动。第五阶段选择一两种真实外设练手比如I2C温度传感器、SPI Flash、GPIO按键中断完整调通一颗外设。这块做完你对总线和中断的理解会有一个质的飞跃。第六阶段深入内核并发与同步机制研究锁、工作队列、tasklet、线程化中断在驱动里设计多并发场景来试验。第七阶段跟着内核社区做开发哪怕是给mainline提交一个文档修改或者小fix也是极好的历练。能跟社区大佬交流、看他们怎么review代码提升速度远比自己闷头看书快。这里再给一个学习中很有用的技巧找一份真实且经典的驱动源码完整地看完它。比如drivers/i2c/busses/i2c-imx.c或者drivers/misc/下面某个简单的misc驱动。看源码不是看热闹要逐行问自己“这行代码为什么存在”“少了它会怎么样”。我当年就是以这种方式把一套触摸屏驱动从头到尾啃了一遍突然对驱动开发整个框架就有了融会贯通的感觉。写在最后的一些实在话做嵌入式驱动开发这些年我最大的感受是这行永远有学不完的东西但也永远不愁没活儿干。从基础的点灯、串口到复杂的总线协议、多媒体显示、网络设备每一个方向往下挖都有足够深的坑。对于新人我的建议很简单动手动手再动手。别怕踩坑驱动开发的很多经验就是从一次次把板子调死的过程中攒起来的。你亲手把一个驱动从无到有调试到稳定运行那种成就感是看多少篇教程都换不来的。等到你踩的坑足够多把每个坑背后的原理都弄懂了恭喜你你已经是一名合格的嵌入式驱动工程师了。