Linux设备驱动开发实践：从内核模块、设备树到I2C/CAN总线

做个事儿先说清楚：这篇文章不是“Linux驱动从入门到放弃”的劝退帖，也不是哪儿都能搜到的hello world教程。我打算用一条完整可复制的路径，把Linux设备驱动开发里的几座大山——内核模块、设备树、I2C、CAN——串起来说。你按这条路径走一遍，能把“写驱动”这件事从玄学变成工程学。

说下背景。我这些年带过不少做单片机的工程师转Linux，也带过刚毕业的学生入职嵌入式岗，大家最容易卡住的地方其实不在写代码，而在不知道一整条链路长什么样。比如很多人上来就啃I2C子系统源码，结果被platform_driver、of_match_table、i2c_client这些概念缠住，根本读不下去，原因是缺了设备树和驱动模型的基础。反过来，如果只会在板子上点个灯，跑个模块加载，又完全够不到真实项目的门槛。

所以这篇文章我会按“先跑通内核模块，再搞懂设备树，最后打通I2C/CAN总线驱动”的顺序往下讲。中间会穿插我实际项目中踩过的坑、排查问题的思路，还有可以直接抄作业的代码片段和命令。适合正在学Linux驱动、准备做嵌入式开发，或者在真实板子上调外设的同学参考。

1. 为什么建议按“模块→设备树→总线驱动”这条路径走

1.1 路径设计背后的思考

先说结论：我把这条路径设计成三段，是因为每一段解决的是不同层次的问题，缺一个后面都会别扭。

第一段是内核模块。它解决的是“驱动跑在什么环境里”的问题。你要理解内核态和用户态的区别、模块的加载卸载机制、printk怎么用、字符设备怎么注册。这些是地基，同时也是成就感来得最快的东西——写好一个模块，insmod进去，dmesg里看到自己的日志打出来，你就算迈过第一道门槛了。

第二段是设备树。它解决的是“驱动怎么知道硬件长什么样”的问题。真实板卡上每一颗芯片挂在哪个总线、基地址是多少、中断脚是哪个、引脚复用到什么功能，这些信息不能写死在驱动源码里，否则换一块板子就要改一遍驱动。设备树就是把这些硬件描述从驱动代码中剥离开，形成一个独立描述层。

第三段才是I2C和CAN这类具体总线设备驱动。有了模块基础，你看得懂驱动的生命周期；有了设备树基础，你才知道i2c_client是怎么自动生成并绑定到驱动的。这时再去看i2c-core、can-dev这些子系统代码，思路会清晰得多。

1.2 常见学习误区与定位

这条路看起来很长，但真正让你浪费时间的往往不是知识量，而是路线选错。我在面试和带人过程中经常见到这么几种情况：

• 只玩过树莓派和Arduino，用python调过I2C，就以为Linux驱动也是两三行库函数的事，上来就碰到“extern”符号找不到、内核头文件不匹配这类问题，心态直接崩。
• 一上来就去读Linux内核源码里最复杂的网卡驱动，被一堆NAPI、DMA、offload概念劝退。网卡驱动确实是Linux驱动里最顶级的复杂度，不适合新手开荒。
• 只会在QEMU里做纯软件实验，从不接触真实板子和示波器，结果一到现场就不知道怎么定位硬件还是软件的问题。

你走完这条路径后，应该能对着任何一颗SoC的手册和板子原理图，完成从“看原理图”到“写驱动”再到“上板验证”的完整闭环。这基本就是多数嵌入式驱动岗位的日常工作模型了。

2. 第一站：内核模块——先把最小闭环跑起来

2.1 模块框架与编译环境

内核模块本质上还是一个C程序，但它不依赖libc，入口函数是module_init指定的那个函数，出口是module_exit指定的函数。它跑在内核空间，访问的是内核的符号表。所以第一个模块不用写功能，能加载、卸载、打印日志，就说明环境没问题。

#include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> static int __init demo_init(void) { printk(KERN_INFO "demo: module loaded\n"); return 0; } static void __exit demo_exit(void) { printk(KERN_INFO "demo: module unloaded\n"); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL");

编译这个模块不能直接用gcc，要用内核提供的Makefile体系：

obj-m := demo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules

这里最大的坑是内核版本和配置必须匹配。如果你板子上的内核是5.10，但编译时用了PC的/lib/modules/5.15，加载时会直接报invalid module format。所以交叉编译时要明确指定KDIR指向板卡对应的内核源码树和编译配置。

顺带提一句，内核源码树必须提前编译过，至少要把scripts和Module.symvers生成出来。我之前用Buildroot编系统时，有时候图快只编了内核镜像，没跑make modules，结果后面编驱动就是各种implicit declaration，这是编译环境没搭完整的典型症状。

2.2 字符设备与自动创建设备节点

模块只打印日志肯定不够。驱动最基础的功能是向用户空间提供访问硬件的接口，而最常见的接口就是字符设备。这里我很推荐用miscdevice，也就是杂项设备。它的好处是内核帮你管理主设备号（统一用10号），次设备号自动分配，省去手动register_chrdev_region的麻烦。

#include <linux/miscdevice.h> #include <linux/fs.h> #include <linux/uaccess.h> static ssize_t demo_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { char data[] = "hello from kernel\n"; size_t len = strlen(data); if (copy_to_user(buf, data, len)) return -EFAULT; return len; } static long demo_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { /* 实际项目中可以在这里处理控制命令 */ return 0; } static const struct file_operations demo_fops = { .owner = THIS_MODULE, .read = demo_read, .unlocked_ioctl = demo_ioctl, }; static struct miscdevice demo_misc = { .minor = MISC_DYNAMIC_MINOR, .name = "demo_dev", .fops = &demo_fops, }; static int __init demo_init(void) { return misc_register(&demo_misc); } static void __exit demo_exit(void) { misc_deregister(&demo_misc); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL");

insmod之后，/dev/demo_dev这个节点会被自动创建出来。如果你看到设备节点没有出现，多半是udev/mdev没有正确处理misc设备的uevent。Buildroot默认用mdev的话，要确认/etc/mdev.conf没把它过滤掉。

这个阶段的“最小闭环”是指：用户空间open/read/write/ioctl一个设备节点，内核空间驱动响应这些操作。这样你后续学平台驱动、总线驱动时，核心关注点就只剩“设备怎么找到驱动”，而不用再花心思在文件操作层的骨架搭建上。

2.3 内核调试三板斧

内核调试不像用户空间能用gdb直接跟，多数情况下第一板斧就是printk。printk的日志级别从KERN_EMERG到KERN_DEBUG一共8级，默认控制台只会显示比console_loglevel高的信息。如果你printk(KERN_DEBUG ...)但dmesg和串口都不显示，不要慌，先看看/proc/sys/kernel/printk：

cat /proc/sys/kernel/printk # 默认通常是 7 4 1 7

第一个数字7表示控制台能显示优先级小于7的日志，也就是KERN_DEBUG级别的8被过滤掉了。临时调试可以把该值改成8：

echo "8 4 1 8" > /proc/sys/kernel/printk

第二板斧是动态调试。内核很多子系统和驱动都带了pr_debug/dev_dbg这类调试打印，默认编译时不输出，但运行时可以用dynamic_debug控制。前提是内核配置了CONFIG_DYNAMIC_DEBUG，然后用下面的命令打开：

echo "file drivers/i2c/* +p" > /sys/kernel/debug/dynamic_debug/control

第三板斧才是正经的调试工具，比如/proc/interrupts查看中断统计、/proc/iomem查看设备内存映射，这些到调具体设备时会很有用。而遇到内核崩溃，也就是oops，不要光看最后一行panic，要往上翻找到PC指针和Call trace，先用addr2line把PC地址翻译成源码行号。这一步能帮你定位到具体是哪一行触发了空指针，不然你只能在代码里瞎猜。

3. 第二站：设备树——硬件的“身份证”就该独立存在

3.1 设备树到底解决了什么问题

在没有设备树的年代，ARM Linux对板级硬件的描述是硬编码在一堆board-*.c文件里的。你换了颗Flash、改了颗PMIC，都要改内核代码重新编译，一颗新SoC要想支持多块评估板，代码里得维护大量板级补丁。这就导致社区里流传一句戏言：ARM Linux的板级文件快比机器还多了。

设备树（Device Tree）的引入把硬件描述变成了一种松耦合的文本结构。它本质上是一棵描述硬件拓扑的树，每个硬件外设对应一个节点，节点里有compatible、reg、interrupts、pinctrl等属性。内核启动时解析设备树，生成platform_device或i2c_client等设备对象，再和驱动注册的id_table/of_match_table做匹配，匹配成功后调用probe。驱动只关心“我兼容哪些硬件”，不再关心“硬件具体长什么样”。

常有人问我设备树语法是不是另一种编程语言。严格说不是，它没有执行逻辑，只是数据描述，类似JSON/XML的角色。语法简单归简单，但坑都在细节里，最常见的是：改了设备树文件忘了重新编译dtb、dtb烧错分区、或者节点里compatible写法和驱动对不上，结果probe就是不被调用，还没有任何编译报错。

3.2 一个LED节点的完整拆解

讲语法不如直接看例子。以最常见的GPIO LED为例，设备树节点长这样：

/ { leds { compatible = "gpio-leds"; status = "okay"; work_led: led@0 { label = "work"; gpios = <&gpio4 0 GPIO_ACTIVE_HIGH>; default-state = "on"; }; }; };

驱动侧内核自带的gpio-leds驱动通过compatible = "gpio-leds"匹配到这个节点，然后读取gpios属性，拿到gpio4的第0号引脚，再根据default-state把引脚拉到高电平或低电平。这里面看起来就五行配置，实际牵扯到三层：gpio控制器节点（gpio4）、引脚号（0）、有效电平（GPIO_ACTIVE_HIGH）。

实际项目中，GPIO往往要复用。SoC的同一个引脚可能有UART、I2C、GPIO多种功能，到底哪个功能生效由pinctrl子系统决定。设备树里经常看到：

&pinctrl { led_gpio: led_gpio { rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>; }; };

然后在LED节点里加pinctrl-0 = <&led_gpio>。这里有个初学者必踩的坑：pinctrl设置如果和别的外设冲突，后加载的驱动不会报错，但功能就是不对。我之前调I2C时发现SDA引脚波形异常，最后查出来是某个GPIO节点把同一引脚复用成了普通输出，导致I2C总线一直被拉低。这种问题用示波器看波形会很明显，SCL正常，SDA永久低电平。

3.3 看懂SoC厂商的dtsi继承关系

设备树文件分为dtsi（SoC级）和dts（板级）。dtsi是芯片原厂提供的，描述SoC内部外设，例如UART、I2C控制器、DMA，默认状态往往是disabled，因为同一颗SoC在不同板卡上未必全部引出。板级dts需要include对应的dtsi，然后决定哪些外设使能，怎么配置引脚。

以瑞芯微RK3568这类常见方案为例，你的板级设备树通常长这样：

/dts-v1/; #include "rk3568.dtsi" &i2c0 { status = "okay"; clock-frequency = <400000>; sensor@48 { compatible = "some,vendor-sensor"; reg = <0x48>; interrupt-parent = <&gpio3>; interrupts = <RK_PA5 IRQ_TYPE_EDGE_RISING>; reset-gpios = <&gpio3 RK_PA6 GPIO_ACTIVE_LOW>; }; };

看懂这个结构后，你会明白一个事：拿到一块新板子，第一件事不应该是急着写代码，而是去读它的设备树，看看这颗SoC的哪些控制器被使能了、挂在哪个地址上、中断引脚是哪个。很多时候所谓“驱动适配”，其实就是根据原理图在设备树里补节点、调引脚、配时钟，一行C代码都不用改。

调试设备树也有几个实用命令。板子上直接看当前生效的设备树，可以挂载debugfs或者用/proc/device-tree：

ls /proc/device-tree/ cat /proc/device-tree/model

这个目录下的结构就是运行时设备树展开后的样子。如果你想反编译dtb文件，PC上装dtc工具，用dtc -I dtb -O dts xxx.dtb就能还原出dts源码，排查“烧进去的dtb到底改没改对”特别好用。我调试时习惯在Makefile里加一条target，每次编完dtb自动反编译一份存下来，对比检查比肉眼盯十六进制靠谱得多。

4. 第三站：I2C设备驱动——把总线通信吃透

4.1 I2C协议速记与一个完整读写时序

I2C是嵌入式里出场率最高的低速总线之一，一颗MCU板子上挂个eeprom、温湿度传感器、加速度计、OLED屏，几乎全是I2C。它只有两根线：SCL时钟线、SDA数据线，都是开漏结构加上拉电阻，所以空闲时两根线都是高电平。

我习惯用一个不太严谨但很好记的类比：I2C像一个带门禁的小区。主机是物业，每个从设备是一栋楼，7位地址就是楼栋号。SCL是节拍器，所有通信都跟着它跳动；SDA是对话内容，但只有在SCL为高时才能被采样。通信开始前，主机把SDA从高拉低，这期间SCL保持高，就是START条件，相当于敲了门。结束后，主机让SDA从低变高，也是SCL为高时发生，就是STOP条件，相当于关门。

一次完整的寄存器读取时序大概是这样的：

1. 主机发START。
2. 主机发送7位从机地址+1位写标志（0），等待从机ACK。
3. 主机发送要读取的寄存器地址，等待ACK。
4. 主机再次发送START，也就是repeated START。
5. 主机发送7位从机地址+1位读标志（1），等待ACK。
6. 从机输出该寄存器的数据，主机在每字节后回ACK，最后一个字节要回NACK。
7. 主机发STOP。

为什么中间要repeated START？因为很多从机芯片在连续操作时必须保持总线占用，否则可能丢失状态。内核里i2c_transfer的msgs数组里放两条消息，第一条是写寄存器地址，第二条是读数据，驱动框架会自动处理这个时序。如果你在用户空间用i2c-tools模拟，也能看到相同的效果。

选择i2c-tools还是内核驱动，取决于应用场景和性能要求。可参考下表：

4.2 驱动框架与关键API对照

真正到了内核驱动层面，I2C设备驱动核心是i2c_driver结构体：

#include <linux/i2c.h> static int sensor_probe(struct i2c_client *client) { struct device *dev = &client->dev; u8 id; /* 读取芯片ID做确认 */ id = i2c_smbus_read_byte_data(client, 0x0f); dev_info(dev, "chip id: 0x%02x\n", id); return 0; } static void sensor_remove(struct i2c_client *client) { /* 释放资源 */ } static const struct of_device_id sensor_of_match[] = { { .compatible = "some,vendor-sensor" }, { } }; MODULE_DEVICE_TABLE(of, sensor_of_match); static struct i2c_driver sensor_driver = { .probe = sensor_probe, .remove = sensor_remove, .id_table = NULL, .driver = { .name = "some_sensor", .of_match_table = sensor_of_match, }, }; module_i2c_driver(sensor_driver);

这个驱动里的probe函数什么时候被调用？就是第3.3节设备树里那棵sensor@48节点所描述的i2c_client生成并匹配成功后。整个链条是：设备树节点 → i2c-core解析生成i2c_client → 根据compatible匹配i2c_driver → 调用probe。所以compatible必须两边一致，少了哪一个，probe都不会执行。

I2C通信API有四个层次，我整理过自己的选用规律：

• i2c_master_send/i2c_master_recv：适合只发或只收的简单场景。
• i2c_transfer：可以一次传多条消息，适合需要repeated START的场景，比如读寄存器。
• i2c_smbus_read_byte_data/i2c_smbus_write_byte_data：适合8位寄存器地址的器件，背后帮你封装成两条消息，代码最简洁。
• i2c_mux专用API：如果总线上挂了多路选择器，比如PCA9548，要用i2c_mux框架，不能手动改地址。

调试I2C设备驱动时，我有个固定动作：先不看驱动代码，用i2c-tools确认硬件链路。因为如果芯片地址写错或虚焊，驱动写得再对也白搭。

4.3 用户空间i2c-tools：硬件问题先在这里验明正身

i2c-tools是我调试I2C外设最依赖的命令集合，它能在不写驱动的情况下直接访问I2C总线：

# 列出系统里所有I2C总线 i2cdetect -l # 扫描0号总线上的从设备，-y跳过确认 i2cdetect -y 0 # 读取0x48地址0x0f寄存器的值 i2cget -y 0 0x48 0x0f

i2cdetect扫不到设备，但原理图上明确画了这颗芯片时，我总结过排查顺序：

1. 先量SDA和SCL对地电压，正常空闲状态应该是上拉电平，大概3.3V或1.8V，取决于上拉电源。
2. 如果SDA一直是低电平，优先怀疑有设备把总线拉死了，常见原因是某个从设备地址冲突或虚焊。
3. 用示波器抓START条件，看SCL拉高时SDA是不是有下降沿。没有起始条件说明总线根本没被驱动。
4. 确认地址对不对。7位地址常见表示法是0x48，但有些芯片手册用8位地址写0x90，不转换就会差一位。

我印象最深的一次，是调一颗EEPROM怎么都读不到ACK，i2cdetect超时，但示波器却看到有波形。折腾了大半天，最后拿放大镜才看出是芯片的SDA引脚虚焊，视觉上像焊上了，实际上没吃锡。从那以后我调I2C必带上放大镜和示波器，也建议大家先信硬件，再怀疑软件。

如果你用的是SSD1306这类OLED屏，也可以用i2cset直接往显存里写数据，先确认屏幕和总线没问题，再写驱动。这样能有效区分“屏幕没点亮”是因为驱动没写好，还是硬件链路的问题。

5. 第四站：CAN控制器驱动与SocketCAN

5.1 为什么Linux CAN外设走SocketCAN

CAN总线和I2C/UART最大的区别在于，它不是传统的“主从读写”模型，而是一种多主、广播式的报文协议。总线上每个节点都能随时发帧，帧ID决定了优先级，多个节点同时发送时通过ID仲裁决定谁先发，非破坏性仲裁是CAN的招牌特性。这种模型天然类似于网络通信，所以Linux社区很早就定了一个方向：把CAN做成一个网络协议族，叫SocketCAN。

对用户空间来说，CAN设备不是/dev/ttyCAN0，而是网络接口can0。你用socket(AF_CAN, SOCK_RAW, CAN_RAW)就能收发原始报文。这么做的好处是复用了一整套网络工具链，例如ifconfig/ip、tcpdump风格的分析工具，以及网络命名空间、防火墙等特性。

我之前带过一个人，他在别的RTOS上做CAN一直用字符设备模型，每收一帧都要读一次驱动，用户空间还得自己解析ID和长度，写得特别痛苦。切换到SocketCAN后，他第一次看到ip link set can0 up type can bitrate 500000就把控制器起来了，直接用candump抓包，半天就上手了。

5.2 设备树中的CAN节点与驱动骨架

CAN控制器在设备树里的节点和I2C控制器类似，不同SoC的寄存器名和属性不同。以常见的M_CAN或FlexCAN为例，节点大致长这样：

&can1 { status = "okay"; pinctrl-0 = <&can1_rx &can1_tx>; pinctrl-names = "default"; /* 有些SoC还需要配置时钟和中断 */ };

CAN的引脚复用也得靠pinctrl完成，所以我在第3.2节讲的pinctrl概念在这里直接就会用到。调CAN时如果发现发送超时或者看不到报文，先查引脚复用：确认CAN_TX和CAN_RX对应引脚确实被配置成了CAN功能，而不是GPIO。

驱动侧，CAN控制器驱动要注册一个net_device，核心结构体是can_priv。必要实现包括open/stop、do_set_bittiming、do_start/do_stop这些net_device_ops里的回调，同时还有中断处理、错误状态上报等。因为CAN控制器一般都有硬件发送邮箱和接收FIFO，驱动还要配合can_rx_offload来做NAPI式收包，减轻中断风暴。这部分代码量不小，新人不建议上来就自己从零写控制器驱动，除非你手里芯片没有任何官方或社区支持，否则先把主线内核自带的驱动裁剪适配好才是正路。

实际项目里更多的情况是：驱动已经在BSP里了，你只需要配置设备树、确认引脚、调bitrate。这也是我更推荐先跑通SocketCAN再回看源码的原因。全流程跑通后，再去读drivers/net/can里对应芯片的驱动，理解接收路径、错误处理，收益会高得多。

5.3 上板实测：从ip link到candump

上了真实双节点之后，验证CAN链路最快的方式如下：

# 一台设备配置bitrate并启动 ip link set can0 down ip link set can0 type can bitrate 500000 ip link set can0 up # 另一台同样配置后监听 candump can0 # 第一台发送一帧ID=123的数据 cansend can0 123#DEADBEEF

如果candump里看不到数据，先不要查驱动，重点查物理层：

1. 确认两个节点都接了120欧姆终端电阻，或者使用带终端电阻的CAN分析仪。高速CAN总线两端必须有终端电阻，否则信号反射会导致错误帧。
2. 用万用表量CAN_H和CAN_L之间的电压，静态时应该在2V左右，因为CAN_H约2.5V，CAN_L约2.5V，差分电压接近0。发送时差分电压会拉大。
3. 用示波器分别抓CAN_H和CAN_L波形，看是不是一高一低互补，差分信号明显。如果两个引脚量出来完全一样，可能是CAN收发器坏了或接线接反。

还有一个高频坑是bitrate不一致。两边都是500k但实际晶振误差大，会出现大量错误帧。可以用ip -details link show can0查看当前错误计数，或直接看：

ip -s -d link show can0

这个命令会输出bus error、RX overrun等统计。错误计数不断增长，基本就是波特率不匹配或物理层问题，而不是驱动逻辑问题。

6. 系统裁剪、性能调优与高频问题排查

6.1 从“能跑”到“跑得好”

驱动打通只是第一步，真实产品里还得考虑系统裁剪和性能调优。我见过不少项目，功能都调好了，但上电启动要十几秒，或者CPU占用率莫名高，查下来都是设备树里一堆用不到的外设还开着，或者某颗传感器的轮询线程在空转。

裁剪的第一步是审视设备树。把所有没有用到的外设节点全部status = "disabled"，包括调试串口外的多余UART、未用的I2C控制器、未使用的SDIO/PCIe接口，这样可以减少内核启动时对它们的初始化，降低中断注册和电源管理负担。注意，禁用节点不是删除节点，因为SoC级dtsi里的节点可能会被其他节点引用。

第二步是裁剪内核配置。通过menuconfig关掉不需要的文件系统、驱动、网络协议栈特性。这一步需要结合产品实际需求，比如纯数据采集设备用不到NFS、无线网卡和蓝牙，直接关掉能省不少内存和启动时间。裁剪前强烈建议先用内核自带的savedefconfig导出当前有效配置，备份好现状再动手。

性能调优方面，比较有效的动作有：

• 查看中断分布：cat /proc/interrupts，确认外设中断均衡到多核，或者绑定到指定CPU。
• 用perf top或ftrace查看内核热点。CAN总线压力大时，重点看软中断ksoftirqd的占用，必要时用NAPI、threaded IRQ或硬中断绑核来优化。
• 根据实时性要求考虑preempt_rt或内核RT补丁，但这是另一个大话题，尽可能先不引入，除非产品对实时性有硬性指标。

6.2 高频问题速查表

我把这些年Linux驱动开发中高频出现的问题汇总成一张表，你可以直接截图存着用：

排查问题时，我有一条原则：先从外部到内部，从硬件到软件。量电压、看波形、确认设备树、加载模块、用工具验证，最后才是怀疑驱动代码。倒过来查，经常会把一个虚焊问题查成一部“驱动被迫背锅”的连续剧。

写在最后的一点个人体会

这条路走完一遍后，我有一个很深的感触：Linux驱动开发其实是一门“系统解释学”。你在设备树里看懂硬件描述，在总线框架里理解设备与驱动的匹配，在中断和定时器里感知整个系统的节拍。每一步都不是孤立的，节点和节点之间通过compatible、通过pinctrl、通过中断号紧密咬合。

带项目这几年，我越来越觉得对新手最有帮助的，不是收藏多少篇帖子，而是手边有一块能反复折腾的板子，再加上一条完整的路径图。按“内核模块→设备树→I2C/CAN”这条路走完，哪怕中间多踩几个坑，花的时间也是值得的，因为你会建立起属于自己的调试直觉。

最后分享一个小技巧：把常用的调试命令写成shell函数放进~/.bashrc，比如dmesg -w、cat /proc/interrupts、i2cdetect -y 0这三个我一天能敲几十遍。省下来的时间，够你多抓几次示波器，多读两页芯片手册了。