嵌入式Linux + 安卓 + 驱动开发这个组合，凡是投过BSP（板级支持包）相关岗位的人都不会陌生。几乎每一家做智能硬件、车载、物联网设备的公司，招聘JD里都会挂着类似的关键词，面试时也会反复问到底层驱动的实现链路。你可能会发现一个现象：很多做应用开发的人转驱动岗，难的不是语法，而是脑子里没有一张完整的“从Linux内核到安卓应用”的路径图。这篇内容想跟你聊的就是这么一件事——我基于一个贴近企业真实需求的传感器驱动项目来拆解，从内核驱动的编写、设备树配置，到安卓HAL层封装、JNI上抛、Framework服务集成，再到App最终读到数据，完整走一遍。不管你是刚入行的嵌入式工程师，还是想往BSP方向转的应用开发，又或者是正在准备秋招的应届生，这套思路都能直接套用，特别是面试时怎么把项目讲成亮点，这部分我会毫无保留地分享。

1. 这个项目的核心思路：从Linux内核到安卓应用的一条完整链路

1.1 为什么说驱动开发不只是“写内核模块”

很多人一提到驱动开发，第一反应就是写一个字符设备驱动，然后用insmod加载进去，在/dev下看到一个节点，觉得这就完事了。但真实的企业场景完全不是这样。尤其是安卓设备的BSP工程师，你面对的是一条纵向贯通的技术栈：Linux内核驱动负责操作硬件，HAL层负责向上提供稳定的接口，Framework层通过JNI调用Native代码，最终App通过标准API拿数据。

这条链路里每一环都有独立的坑。内核驱动写得再好，如果HAL层的接口设计不合理，Framework层集成时就会非常别扭；HAL层如果直接暴露了太多的Linux细节，应用层又没法做到“硬件无关”。所以我在做这个项目时给自己定了一个原则：要做一个完整的“端到端”功能，而不是某个孤立的模块。

项目采用的是经典温湿度传感器方案（以SHT30或HDC1080这类I2C接口的传感器为例）。选择传感器作为载体，原因很实际：I2C驱动是驱动开发里最典型、面试出现频率最高的总线类型，硬件原理不复杂，同时又涉及设备树、probe机制、寄存器读写、数据上报等几乎所有核心知识点。把I2C驱动吃透了，后面再做SPI、USB甚至GPU驱动，思路都是相通的。

1.2 实战项目的选型逻辑：如何把多个技术点串联成一个项目

如果只是写一个传感器驱动，这个项目还是太单薄。我在实际做的时候，给项目增加了两个关键工程点：

第一个是根文件系统使用NFS挂载。开发阶段如果把rootfs每次都用dd烧写进SD卡或eMMC，每改一次代码就要重新烧写一次，效率极低。用NFS把开发板上的根文件系统挂载到Ubuntu宿主机上，内核编译完直接拷贝到NFS共享目录，开发板重启即生效，迭代速度能提升好几倍。这里有一个新手必踩的坑：新版内核默认NFS协议版本是v4，很多老旧的开发板或者特定Ubuntu版本里NFSv4的支持不全，挂载时会卡在VFS: Unable to mount root fs。我用的是nfsvers=3参数强制走v3，后面会详细讲。

第二个工程点是安卓侧的框架集成。传感器驱动如果只做到Linux用户态的C程序能读数据，其实还只完成了一半。安卓系统有自己的硬件抽象层规范，你需要实现一个HAL模块，再通过JNI封装成Java接口，注册为系统级服务，让App可以直接调用。这个过程中你会接触到hw_get_module、hardware.h、JNI方法映射、SystemServer注册等一堆听起来陌生但实际有规律可循的机制。

选型里还有一个容易被忽略的点：芯片平台。我建议有条件的话用瑞芯微RK3399或者NXP i.MX6ULL这类资料丰富、社区活跃的芯片。原因很简单，这类平台的BSP源码和相关讨论最多，遇到问题时搜索一下基本都有解决方案。如果手里只有全志或联发科的板子也没关系，驱动框架是通用的，只是设备树和引脚配置不同而已。

2. 项目前期准备：环境、源码与开发板选择的几个细节

2.1 环境搭建的第一步：交叉编译工具链与内核源码树

嵌入式Linux驱动开发的第一步不是写代码，而是把交叉编译环境弄好。很多新人在自己的笔记本上编译模块，拿到开发板上直接insmod，然后报错invalid module format，其实就是内核版本不一致或者编译器版本不匹配导致的。

我使用的组合是Ubuntu 18.04/20.04 + arm-linux-gnueabihf-工具链（针对ARM 32位平台）。如果是RK3399这类ARM 64位平台，就用aarch64-linux-gnu-。关键点在于：交叉编译工具链的大版本必须和开发板商提供的工具链保持一致，否则模块里的__this_module符号和内核的modversions对不上。

内核源码树建议直接使用开发板厂商提供的版本，而不是从kernel.org下载。因为厂商会打上很多芯片相关的patch，比如电源管理、GPU、显示等。用官方内核源码去编译模块，很多时候能顺利编译通过，但加载时会出现Unknown symbol或版本magic不匹配的问题。

这里给一段编译驱动的Makefile示例，适用于大多数内核模块开发场景：

obj-m := tmp_sensor.o KERNELDIR ?= /home/user/rk3399-kernel CROSS_COMPILE ?= aarch64-linux-gnu- PWD := $(shell pwd) all: $(MAKE) ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELDIR) M=$(PWD) modules clean: $(MAKE) ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNELDIR) M=$(PWD) clean

注意ARCH变量要和目标平台一致，32位ARM平台写ARCH=arm，64位写ARCH=arm64。这个变量写错的话，编译时会出现一大堆asm/types.h找不到之类的报错，原因就是内核在寻找架构相关的头文件时找不到对应的目录。

2.2 NFS根文件系统挂载的完整配置与v3协议问题

NFS挂载根文件系统的思路是：开发板上通过bootargs参数告诉内核根设备是NFS，内核在init阶段通过网卡访问宿主机导出的目录，将其作为根文件系统使用。

宿主机需要安装NFS服务：

sudo apt update sudo apt install nfs-kernel-server sudo mkdir -p /srv/nfs/rootfs

然后在/etc/exports里添加一行：

/srv/nfs/rootfs *(rw,sync,no_root_squash,no_subtree_check,insecure)

这里的小细节很多。no_root_squash是必须的，否则开发板的root用户在NFS共享目录里会被映射为nobody，导致systemd等进程无法正常启动，你会在启动日志里看到一堆Permission denied。insecure这个选项允许客户端使用大于1024的端口进行NFS连接，部分板卡的内核NFS客户端会使用随机高位端口，不加上这个选项可能连接失败。

开发板u-boot的bootargs需要指定NFS作为根设备，我实际使用的参数是：

setenv bootargs 'root=/dev/nfs nfsroot=192.168.1.100:/srv/nfs/rootfs,proto=tcp,nfsvers=3 ip=192.168.1.50:192.168.1.100::255.255.255.0::eth0:off rw init=/sbin/init'

把nfsvers=3显式写清楚很关键。我踩过这个坑：在某个新内核版本里，NFS客户端默认尝试NFSv4.2挂载，而宿主机的export配置没有启用NFSv4支持，结果内核日志反复打印VFS: Unable to mount root fs via NFS, trying to continue这样的错误。换成nfsvers=3之后，一次通过。

内核侧还需要确认以下配置项已开启：

CONFIG_ROOT_NFS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_FS=y

如果内核里这些配置没有打开，即使bootargs写对了，也会在挂载阶段直接报错。建议加载模块前先用menuconfig检查一遍，别等到启动失败了再回头查。

2.3 开发板上的文件系统骨架准备

NFS共享目录里光放一套rootfs不够，还需要准备最基本的系统二进制，比如busybox。对于只做驱动验证和HAL开发的场景，不推荐直接拿安卓的system.img来挂载——因为安卓的init和SELinux策略会让调试变得非常痛苦。我更倾向于准备一套精简的busybox根文件系统，先在内核态把驱动跑通，然后再过渡到完整的安卓系统上做HAL集成。

为什么后面还要切到安卓系统？因为HAL层运行在安卓用户空间，需要binder、servicemanager、JNI环境等基础服务，这些在精简rootfs里是不存在的。开发阶段先用busybox rootfs验证内核驱动，这一步把硬件层面的问题全部消除，之后再进入安卓系统，你就只需要关注HAL和Framework层的逻辑，排错范围一下缩小了大半。

3. 核心实现：一个可以写进简历的驱动开发全流程

3.1 字符设备驱动框架与设备号管理

内核驱动最基础的部分是字符设备。不管底层硬件是什么，最终面向用户态时通常通过文件操作接口open/read/ioctl来交互。先看一段最核心的框架代码：

#include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/slab.h> #include <linux/i2c.h> #include <linux/uaccess.h> #include <linux/mutex.h> #define TMP_SENSOR_MAJOR 0 // 动态分配主设备号 #define TMP_SENSOR_MINOR 0 #define TMP_SENSOR_DEV_NUM 1 static int tmp_sensor_major = TMP_SENSOR_MAJOR; static struct cdev tmp_sensor_cdev; static struct class *tmp_sensor_class; static int tmp_sensor_open(struct inode *inode, struct file *filp) { struct i2c_client *client = NULL; client = container_of(inode->i_cdev, struct i2c_client, dev); filp->private_data = client; return 0; }

这里有一个重要概念：主设备号和次设备号。主设备号描述设备类型，次设备号区分同类设备的不同实例。我用主设备号0告诉内核动态分配，这样避免手动指定时冲突。实际生成的设备节点由devtmpfs或者mdev自动在/dev目录创建，这个机制比手动mknod方便得多，但要保证内核配置里有CONFIG_DEVTMPFS=y。

file_operations结构体的注册是驱动对外能力的声明：

static const struct file_operations tmp_sensor_fops = { .owner = THIS_MODULE, .open = tmp_sensor_open, .read = tmp_sensor_read, .release = tmp_sensor_release, };

用户空间调用read的时候，会进入tmp_sensor_read函数。这个函数里要做两件最重要的事情：一是从client结构体（即私有数据）中拿到I2C总线的操作句柄，二是通过I2C协议读取传感器寄存器里的温湿度原始值，再拷贝给用户空间的缓冲区。

3.2 Platform驱动与设备树：硬件描述与驱动解耦的现代方式

在旧版内核里，硬件信息通常直接写死在驱动代码中，比如硬编码I2C总线号、设备地址、中断引脚。这种方式一旦换了板子，就得改驱动代码重新编译。新版内核使用设备树（DTB）来描述硬件资源，驱动通过compatible属性与设备节点自动绑定。

设备树中I2C传感器节点的写法如下：

&i2c1 { status = "okay"; tmp_sensor@48 { compatible = "example,tmp_sensor"; reg = <0x48>; interrupt-parent = <&gpio1>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; }; };

compatible里的“example,tmp_sensor”必须与驱动中的of_match_table完全一致。reg属性表示I2C设备地址是0x48。interrupts描述中断引脚为GPIO1组的第18脚，下降沿触发。

驱动里匹配设备树的代码是这样：

static const struct of_device_id tmp_sensor_of_match[] = { { .compatible = "example,tmp_sensor", }, { } }; MODULE_DEVICE_TABLE(of, tmp_sensor_of_match);

当内核解析设备树发现匹配的compatible后，会调用驱动里的probe函数。这也是I2C驱动比裸字符设备多出来的关键结构。probe函数会收到一个i2c_client结构体，里面包含了总线适配器、设备地址等现成的硬件上下文。传统的register_chrdev_region、cdev_add等注册过程，通常在probe里完成，这样就实现了“设备树描述硬件、驱动处理逻辑”的分离。

发言里老是听到“平台设备”、“总线设备驱动模型”，其实就是这套机制：Linux把设备和驱动分开匹配，设备来了叫probe，设备移除叫remove。这也是面试环节最爱深挖的点。

3.3 数据上报与并发控制：从内核到用户态的正确姿势

驱动读I2C传感器数据一般有两种方式：轮询和中断。温湿度传感器这类低速设备，用轮询就行，每隔几百毫秒读一次。我采用read函数同步读取模式：用户态App调用read时，如果当前没有数据，就通过等待队列让进程挂起，直到传感器数据准备好再唤醒。

这涉及一个很关键的内核编程原则：睡眠安全。在等待队列中睡眠时，进程并没有占用CPU，所以整个系统不受影响。但如果你的read函数里用了自旋锁持有期间睡眠，那就直接panic了。我在实际项目中用mutex保护临界区，用wait_event_interruptible实现阻塞等待，这是低速设备驱动的标准组合。

数据从内核拷贝到用户态必须用copy_to_user，不能直接memcpy。原因很简单：内核空间和用户空间的地址映射不同，直接访问用户传进来的指针会引发段错误甚至内核崩溃。等以后做了mmap方式的驱动，也就是把内核缓冲区映射到用户空间，就可以减少一次拷贝，但字符设备的传统方式仍然是copy_to_user。

static ssize_t tmp_sensor_read(struct file *filp, char __user *buf, size_t count, loff_t *offset) { struct i2c_client *client = filp->private_data; unsigned char data[6] = {0}; int ret; ret = i2c_smbus_read_i2c_block_data(client, 0x00, 6, data); if (ret < 0) { dev_err(&client->dev, "read sensor data failed\n"); return ret; } if (copy_to_user(buf, data, sizeof(data))) return -EFAULT; return sizeof(data); }

注意这里读取的是SHT30在0x00命令下的数据块，总共6字节：前两个字节是温度原始值，后两个是湿度，中间可能还有CRC校验。实际业务中你还需要根据传感器的数据手册换算成温度和湿度值，不要直接拿原始值上报给应用层。

实操中一定还遇到一个问题：把这个.ko文件交叉编译出来后，insmod到开发板，发现/dev/tmp_sensor节点并没有出现。这时候不要慌，先检查是不是devtmpfs没挂载，或者模块在注册时class_create失败。一个稳的习惯是先在busybox rootfs里用mdev或者手动mknod确认节点能出现，再往上走。

4. 安卓侧的封装：从HAL到Framework再到App

4.1 HAL层设计：为什么安卓硬件访问要绕这么一圈

安卓系统不会允许App直接去open/dev下的节点，而是定义了一套硬件抽象层规范。HAL的作用是让上层Framework不必关心底层内核驱动怎么实现：在RK3399上跑的传感器驱动，和在骁龙平台上跑的，对Framework来说接口应该是一致的。

HAL模块首先要实现一个入口函数hw_get_module，它会根据硬件模块ID（比如SENSOR_HARDWARE_MODULE_ID）去/system/lib/hw/目录下找对应的.so文件。所以HAL代码的目录结构是有讲究的，编译生成的库文件名必须符合命名规则，例如sensors.default.so、sensors.rk30board.so，否则模块加载直接失败。

一个最基本的传感器HAL模块结构如下：

struct hw_module_methods_t tmp_sensor_module_methods = { .open = tmp_sensor_device_open, }; struct hw_module_t HAL_MODULE_INFO_SYM = { .tag = HARDWARE_MODULE_TAG, .module_api_version = SENSOR_MODULE_API_VERSION_1_0, .hal_api_version = HARDWARE_HAL_API_VERSION, .id = SENSOR_HARDWARE_MODULE_ID, .name = "TMP Sensor HAL", .methods = &tmp_sensor_module_methods, .dso = NULL, .reserved = {0}, };

HAL_MODULE_INFO_SYM这个符号名是hardware.h里定义的宏，严格规定不能改。我从新人时期就吃过这个亏：随手改成了my_module_info，结果hw_get_module永远找不到这个库。HAL层的代码一头是标准接口，另一头就是open("/dev/tmp_sensor")这种系统调用。到这里，Linux驱动和安卓系统之间的桥梁就算搭上了。

有一个非常实际的建议：HAL层的dev_open，建议在open失败时做两次重试，中间间隔100ms。因为安卓系统启动早期，SELinux策略可能还没完全加载，设备节点的权限没有立刻生效，直接open会失败。这种重试机制不会影响正式运行时的性能，但能减少启动阶段的偶发异常。

4.2 JNI与Framework层：把C函数暴露成Java接口

Framework层是一个Java世界，但它需要通过JNI调用到C/C++世界的HAL。JNI的作用就是注册一组native方法，让Java层的类可以调用到C函数。这一层的代码通常写在frameworks/base/services/core/jni/目录下。

JNI方法注册的代码核心如下：

static jint tmp_sensor_init(JNIEnv *env, jobject clazz) { struct sensors_module_t *module; hw_get_module(SENSOR_HARDWARE_MODULE_ID, (hw_module_t const**)&module); // 初始化设备 return 0; } static const JNINativeMethod gMethods[] = { { "nativeInit", "()I", (void *)tmp_sensor_init }, { "nativeRead", "()[B", (void *)tmp_sensor_read }, { "nativeExit", "()V", (void *)tmp_sensor_exit }, }; int register_android_server_TmpSensorService(JNIEnv *env) { return jniRegisterNativeMethods(env, "android/server/TmpSensorService", gMethods, NELEM(gMethods)); }

Java层的TmpSensorService是一个系统服务，通过SystemServer的main方法注册到servicemanager里，之后App通过Binder可以获取到该服务实例，再调用其方法拿到数据。Binder是安卓最核心的IPC机制，它解决了多进程之间的函数调用和数据传递问题。虽然系统服务的内部实现可以简化到“用static方法直接封装native函数”，但正规的架构里还是应当通过Binder服务暴露给App，这样可以让服务运行在独立的系统进程中，权限控制也更清晰。

常见的一个坑是：SystemServer启动时会按照固定的顺序启动服务，如果在某个阶段调用还没初始化的服务，进程会卡死或者直接crash。我在项目里是把TmpSensorService放在了比较靠后的阶段，并且捕获了初始化异常，避免因为传感器设备不存在导致SystemServer启动失败。

4.3 App层读取数据的完整路径与权限问题

App通过Context.getSystemService拿到TmpSensorService之后，调用getTemperature()方法，实际上会经历一层一层的调用链：App → Binder → SystemServer → Java方法 → JNI → native方法 → HAL → 字符设备节点 → 内核i2c驱动 → 传感器硬件。

这个链路说出来在面试中本身就是个亮点：很多面试者能讲Linux字符设备，能讲安卓四大组件，但能把整条调用链串起来的很少。面试官会认为你真的理解BSP工程师在整个系统里的位置。

权限问题在这个环节会冒出来。安卓的SELinux会使能态策略严格控制进程能访问的资源，包括设备节点。你会在logcat里看到类似这样的错误：

avc: denied { read } for pid=1234 comm="tmp_sensor_app" name="tmp_sensor" dev="tmpfs" scontext=u:r:untrusted_app:s0 tcontext=u:object_r:device:s0 tclass=chr_file

解决办法是在te文件里添加allow规则。如果是自定义HAL并由system_server进程调用，一般只需要在system_app.te或者system_server.te里加上对tmp_sensor设备的访问许可。如果你没有权限改SELinux的sepolicy，可以通过setenforce 0先关掉强制模式验证功能逻辑，但要清楚这只是开发期的临时手段，正式系统里一定要把selinux策略补上。

5. 调试与问题排查实录：这些坑大概率你也会遇到

5.1 insmod失败与设备节点不出现的排查方法

新手最容易撞到的几个报错，我列一份排查顺序表：

使用dmesg是最直接的排查手段。insmod失败时，先看dmesg的输出，大部分模块注册错误都会在日志里有明确线索。我习惯在驱动代码里加一些dev_info打印，比如probe成功、read失败、i2c通信异常时打印state信息，线上调试阶段再统一用dev_dbg替换，可以减少很多无用功。

5.2 NFS挂载卡死的排查细节

NFS挂载失败时，内核会反复重试。你会在串口看到网络文件系统挂载失败的打印，但最关键的还是要看它卡在哪一步：是ARP解析不通，还是NFS RPC请求被拒，还是VFS挂载超时？

如果是网络链路不通，检查bootargs里ip参数是否配置正确。ip参数的格式是：开发板IP:服务器IP:网关:掩码::网卡名:off。很多板子有两个网卡，名字不是eth0而是eth1甚至lan0，必须要认真看开发板原理图和u-boot的启动打印。

如果网络通了但NFS挂载报No such file or directory，先去宿主机上手动验证一下共享目录是否存在且权限正确：

sudo exportfs -ra showmount -e 192.168.1.100

直接在开发板上用mount命令挂载NFS目录来排查：

mount -t nfs -o nolock,proto=tcp,nfsvers=3 192.168.1.100:/srv/nfs/rootfs /mnt

这个命令可以帮你把“根文件系统挂载的问题”和“内核config问题”剥离开。如果手动mount都不行，就排除了内核的rootfs挂载路径问题，集中排查NFS服务和网络配置。

5.3 安卓SELinux权限导致的打开节点失败

有一个典型场景：内核驱动和HAL都验证通过，App在logcat里也拿到了服务，但read数据时返回Permission denied。很多人在这一步排查很久才怀疑到SELinux。

我的排查习惯是：先执行setenforce 0看功能是否恢复；如果恢复，再用adb shell dmesg | grep avc抓取详细的denied信息，然后把缺失的权限补到对应te文件里，重新编译boot.img或直接编译进vendor。生产环境的做法当然是把规则正式加进sepolicy，但在项目验证阶段用setenforce 0快速确认是SELinux导致的问题，效率最高。

5.4 RTSP与流数据缓存类项目的延伸思路

驱动开发里另一个高频需求方向是多媒体。很多车载、盒子项目里都涉及“安卓缓存RTSP流”这种场景。你以为RTSP是应用层播放器的事，不归驱动工程师管，但事实上这个需求往下探会触及dma-buf、Ion内存管理、硬件编解码器等底层机制。

RTSP流本身的解析和缓存策略一般在应用层做，例如用ijkplayer或ExoPlayer的底层库，在Native层做缓冲。但真正要做得稳，你还需要理解GOP的结构、I帧的位置、关键帧对齐等概念，否则缓存出来的文件在拖动进度条时必花屏。驱动工程师在这个领域的切入点往往是buffer分配的优化：用ion分配物理连续内存，通过dma-buf机制把buffer fd传给编解码器或显示器，避免内存搬运带来的性能损耗。

所以要提醒想走驱动的同学：别把自己的视野局限在GPIO和I2C上，多媒体方向一样需要底层功底，而且薪资天花板更高。

6. 如何把项目讲成面试加分项：Offer收割的实战心法

6.1 面试官究竟在考察什么

面试官问驱动开发的题，表面考的是API和机制，实际考的是系统化的理解能力和排查问题的路径。这四个维度是我总结了多次面试后得出的：

一是代码能力，不要求你现场写完全能编译的驱动，但要能画出字符设备的骨架、说出file_operations里read流程的关键步骤。二是硬件理解能力，比如I2C时序、设备树里reg和interrupts怎么来的、i2c_smbus_read_i2c_block_data和i2c_transfer的区别。三是系统级思维，例如open一个设备节点后到底发生了什么，这中间经过VFS、设备驱动模型、总线匹配、drvier的probe等一系列环节。四是排错能力，跟你聊线上问题怎么定位、dmesg怎么看、复现步骤怎么设计。

6.2 项目陈述的叙事结构：问题定位优先于功能实现

很多人在面试里描述项目时，张嘴就是“我实现了一个温湿度传感器驱动”，这其实是最弱的开场。建议按照“问题定位-方案选型-落地实现-量化结果”的顺序来讲。

以本项目为例：你说“开发阶段每次调试rootfs要重新烧写emmc，一次要几分钟，严重拖慢进度”，这个开头展现了工程痛点，然后引出NFS挂载rootfs的方案，顺带抛出一个后续排错的bug——NFSv4挂载失败，通过强制nfsvers=3解决。这样面试官会觉得你有真正的工程嗅觉。

接着讲传感器驱动时不要只讲功能，重点讲设计取舍：为什么用设备树而不是平台数据注册？为什么read里用阻塞式IO和mutex？为什么HAL层要做两次open重试？每一处都说清楚“不这样做会发生什么”，这样才能展示深度。

6.3 高频面试题与参考要点速查表

我整理了一份在BSP方向面试中出现频率极高的题目清单，附上简述思路：

这些题如果每个你都能讲出“为什么”，再配合项目里的具体细节，面试拿下面试官的把握就很大了。其实面试官也清楚，驱动开发对新人来说上手门槛不低，他们要的并不是你什么都会，而是你“知道自己会什么、不会什么，并且有完整的排查思路”。

最后分享一个我个人的习惯：每次到一个新平台开发驱动，我都会先花半小时把Linux内核里现成的同类驱动源码读一遍，比如drivers/i2c/里的驱动、drivers/hwmon/里的传感器驱动，然后在此基础上做裁剪和适配，而不是从头造轮子。这套方法让我在项目的每个阶段都稳扎稳打，希望对你也有用。