MPU6050驱动移植实战：从STM32裸机到龙芯嵌入式Linux

先说背景。走马观碑组这次领到的任务是“龙芯k - 走马观碑组MPU驱动移植”，目标很明确：把我们之前在一颗ARM平台的MCU（STM32H750）上调通的MPU6050六轴姿态传感器驱动，完整搬到一块龙芯2K系列的嵌入式Linux板卡上。很多人一听“驱动移植”就觉得要改写底层寄存器，其实真正动脑子的地方不是寄存器，而是“访问方式变了、平台资源变了、调试手段也变了”。这篇文章就围绕这次移植展开，把我们在项目里的拆解思路、环境准备、代码改造和真机调试过程原原本本记录下来，给后面要碰类似工作的同学做一份可以直接对照的参考。

文章适合谁看？如果你需要把一段在裸机/MCU上跑得好好的传感器驱动，挪到嵌入式Linux平台上继续跑；或者你不确定用户态驱动、内核驱动该怎么选，遇到I2C地址漂移、数据全零、量程换算不对这类问题，那这篇应该能帮你省下不少时间。即使你还没碰过龙芯硬件，代码里大部分平台差异处理逻辑也一样能复用到其他Linux板卡上。

1. 先想清楚：这个“MPU驱动移植”到底在移什么

很多人拿到类似任务，第一反应是打开原来的工程，看一下MPU6050的初始化代码，复制粘贴到新工程，然后编译。这个做法不能说错，但大概率会卡在后面的调试阶段。动手之前，把“MPU驱动”四个字拆成三个层次理解，思路会清楚很多。

1.1 MPU6050驱动里，真正不能动和必须动的部分

MPU6050本身是一颗I2C/SPI接口的运动处理单元，里面集成了三轴加速度计和三轴陀螺仪，还带一个内部的DMP（Digital Motion Processor）。这颗芯片所有功能最终都落到寄存器读写上。而“驱动”这个词，在跑Linux的板子上其实包含着两层意思：第一层是芯片自身的寄存器配置与数据解析逻辑，第二层是芯片挂在哪个总线上、CPU怎么访问这个总线里的设备。

我们原本的工程是在STM32H750裸机环境下写的，用的是HAL库的 HAL_I2C_Mem_Read 和 HAL_I2C_Mem_Write 来发I2C事务。整个MPU6050的初始化序列、唤醒流程、量程配置、FIFO读取、加速度和角速度的十六位数据解析，这些属于“芯片自身逻辑”。它们和CPU是哪家没有关系，只要你提供的I2C读写函数行为一致，就完全不需要动。

真正必须动的，是底层那个I2C读写函数本身，以及跟平台绑定的一些资源，比如引脚复用、中断配置、时基。H750上用的是硬件I2C外设和GPIO外部中断，而龙芯2K这套Linux系统里，I2C控制器已经被内核接管了，用户态程序不可能也不应该去直接操作I2C控制器的寄存器。你只能通过内核暴露的 /dev/i2c-x 接口，用 ioctl 的方式发起读写事务。也就是说，这次移植的中心任务，是写一个“Linux版”的I2C HAL层，去替换掉原来H750上依赖HAL库的那层实现。

1.2 用一层“驱动边界”把平台差异隔离掉

如果直接把Linux的i2c-dev调用代码散落在整个传感器驱动里，后面维护会很难受。我们团队的习惯是画一条清晰的边界：上层只关心“读寄存器、写寄存器、读一批数据”这三个动作，底层则根据平台实现这三个动作。在H750上，底层实现就包一层函数，里面调HAL库；在龙芯Linux上，底层实现重新包一层，里面走文件操作和ioctl。上层什么都不用知道。

这个设计很像搬家。家里的沙发、柜子、电器怎么摆，你不需要因为从一楼搬到五楼就重新设计一遍；你需要做的只是把“搬运通道”这段路径跑通，确保每件东西能原封不动地进门。传感器驱动里的姿势解算算法、寄存器配置表就是家具，I2C HAL层就是那条搬运通道。新建平台时只重写搬运通道，家具还原样摆放。

后来证明这个隔离层的价值非常大。我们在龙芯2K板子上验证时需要切换不同总线，从 /dev/i2c-0 换到 /dev/i2c-2，只需要改一处open路径参数，其余代码一行没动。如果前期没做这层隔离，改起来就不是改一处而是全工程搜I2C，容易漏。

1.3 用户态驱动 vs 内核驱动，为什么这次选了用户态

嵌入式工程师看到“驱动”两个字，很容易默认要写一个内核模块。实际项目里要分情况。走马观碑组这次的目标是把姿态传感器先跑起来，验证硬件接线、I2C总线和后续算法效果，属于算法验证和前期集成阶段。在这种情况下，内核里i2c-dev机制完全够用，直接在用户态通过设备文件操作寄存器，开发效率明显更高，改个代码不用重新编译内核，也不用担心模块加载把整个系统搞挂。

当然用户态方案也有不足，比如实时性差一些、中断处理做不到内核态那么直接。如果这个传感器后续要跟内核里其他子系统做深度配合，比如要作为一个标准工业输入设备被引用，那就可以在用户态跑通之后，再把它封装成一个标准的内核I2C客户端驱动。这两种路径不是互斥关系，而是验证阶段和生产阶段的先后关系。我见过很多团队一开始就要求写内核驱动，结果调试环境变量多了一倍，麻烦也翻倍。

2. 龙芯平台环境搭建：板子、工具链与可复现的准备过程

环境准备听起来不像技术活，但这次项目至少有一半的“坑”是环境没对齐导致的。我按实际踩过的顺序说说，尽量让后面的人少走弯路。

2.1 拿到板子先别急着接线：确认I2C总线和引脚状态

我们手头的龙芯2K开发板，板载引出多路I2C，理论上挂MPU6050很轻松。但“理论上”和“实际可用”之间隔着一个设备树。板子上的I2C控制器并不会把所有通道都默认打开，引脚也可能被复用成别的功能。所以第一件事不是拿杜邦线去怼，而是在终端里跑：

bash复制ls /sys/bus/i2c/devices/
i2cdetect -l

i2cdetect -l 会列出当前系统注册的所有I2C总线，能看到类似 i2c-2 这样的条目，说明这条总线已经被内核识别并注册了。如果列表里根本没有你要用的总线号，那说明设备树里对应节点可能没有打开，或者状态写的是 disabled。这时候应该去找这块板卡配套的BSP资料，确认是哪组引脚复用了I2C功能，检查内核设备树里对应的I2C控制器节点是否设置为 status = "okay"。

还要提醒一点：不要只依赖原理图来判断总线号。同一颗SoC可能有多个I2C控制器，板卡厂商在设备树里的顺序不一定跟SoC手册完全一致。最可靠的做法是，查看板卡BSP里设备树源文件，搜 i2c 关键字，逐个核对 reg 属性和实际引出的丝印，再跟 i2cdetect -l 的输出对照。这一步骤花二十分钟，后面能省两天。

2.2 交叉编译工具链和板端运行库的匹配

在Linux板卡上做驱动移植，交叉编译工具链是绕不开的一步。如果你是刚从MCU开发切过来，可能不习惯“在PC上编译、在板子上运行”的模式。龙芯是LoongArch架构，跟我们常用的x86、ARM都不一样，所以普通 gcc 编出来的程序没法直接在板子上跑。要安装对应LoongArch的交叉编译工具链，编译时指定前缀，例如：

bash复制loongarch64-linux-gnu-gcc -o mpu_test mpu_test.c

编译完之后，用一个文件判断一下格式对不对：

bash复制file mpu_test

正常应该输出包含 ELF 64-bit LSB executable, LoongArch 之类的字样。如果显示的是x86-64，说明编译器没用对，拷贝到板子上执行必然报 “Exec format error”。这个小命令很多老手也容易忽略，尤其当你机器上同时装了多个工具链的时候。

另外还要注意板子的根文件系统架构。之前组里有人交叉编译完程序，随手 scp 到板子上跑，结果提示缺少某个动态库。这就是典型的宿主机库与板端库不一致问题。稳妥的办法是优先用静态编译，代价是二进制体积大一些，但依赖少；如果确实要动态链接，就确认板端 /lib 下是否有对应的 .so，而不是想当然地以为一定有。我们是先静态编译跑通流程，后面需要优化体积再改成动态链接。

2.3 用模拟环境先跑通纯逻辑，再上真机

提到龙芯开发，如果手头板卡数量紧张，或者早期调试不想反复烧写，可以先用龙芯提供的系统模拟环境做一轮纯逻辑验证。模拟环境里能跑Linux用户态程序，也能做 gdb 断点调试，用来验证寄存器初始化顺序、数据解析函数这些“纯计算”逻辑是足够的。

但有一条必须说清楚：模拟环境里的I2C总线并不对应真实硬件时序，它只是软件模拟出来的行为。你在模拟环境里没法验证上拉电阻是否起作用、时钟速率是否满足传感器要求、中断引脚是否真的产生了边沿。所以模拟环境能帮你验证的是“代码逻辑对没对”，不能验证“硬件线路通没通”。我们当时在模拟环境里先跑通了初始化序列和数据解析，把不少低级笔误提前消灭了，但最终读写是否成功，还是得真机上用 i2cdetect 探测才知道。

如果你也想在模拟环境里跑传感器相关代码，建议在移植开始前就先把I2C访问层抽象好，提供一个“模拟文件描述符”版本。比如代码里用 open 打开的路径，在模拟环境里可以指向一个本地文件，文件内容模拟寄存器值；或者在用户态代码外面套一个单元测试框架来mock底层读写函数。这样逻辑层的测试不依赖硬件，跑起来快得多。

2.4 固件的版本也会影响驱动表现

前期我们遇到一个奇怪现象：同一个I2C控制器，按照设备树里的配置应该是引出到某个排针，但电平怎么量都不对。反复排查后才发现，不是设备树配置错了，而是板子上固件版本比较旧，GPIO复用控制器在固件初始化阶段把某组引脚占用了。后来按官方烧录流程更新了板级固件，I2C引脚才恢复正常。

这里要单独提醒一下：更新固件前务必先确认当前固件版本和更新方法，和团队里负责硬件的人同步，避免更新到一半断电造成板子变砖。如果板子目前的系统运行正常、I2C也能正常使用，其实没必要为了“追新”去刷固件。固件更新是为了解决具体硬件配置问题，不是日常操作。更新完固件后，还要重新确认内核版本和设备树是否配套，不然旧设备树配新固件也可能出现外设状态不符合预期。

3. 核心代码改造过程：寄存器逻辑不变，HAL替换是重点

我前面说过，真正需要动手的代码集中在I2C HAL层。下面把我们在STM32H750上的原始接口和龙芯Linux上的新实现并列写出来，看完你就能知道这类驱动移植到底改的是哪几行。

3.1 梳理原先H750上所有I2C操作点

原工程里MPU6050驱动涉及I2C操作的函数其实不多，核心就两个：读寄存器和写寄存器。在STM32H750裸机上，读寄存器是这么做的：

c复制HAL_StatusTypeDef ret;
ret = HAL_I2C_Mem_Read(&hi2c1,
                       MPU6050_I2C_ADDR << 1,  // 8位地址
                       reg,
                       I2C_MEMADD_SIZE_8BIT,
                       data,
                       len,
                       100);

注意这里有个经典细节：HAL库要求传入的是8位地址，也就是把7位I2C地址左移一位，而后面Linux环境下的用户态接口，通常直接接受7位地址。如果你照搬H750的代码习惯，先把地址左移再传给Linux的接口，就会怎么调都找不到设备。这是整个项目里最容易踩的一个坑，后面我会专门再讲。

另外，H750里还有个隐藏的时基依赖。HAL库的 HAL_I2C_Mem_Read 最后一个参数是超时时间，它的内部计时依赖 HAL_GetTick()。在裸机上，这个函数来自SysTick中断。到了Linux用户态，不存在这套HAL时钟环境，所以I2C超时控制也要一并改掉，通常用文件描述符的操作超时或者ioctl内部超时来表示。

3.2 用ioctl和struct i2c_msg封装用户态I2C访问

Linux内核提供的 /dev/i2c-x 接口有几种用法，最简单的是 I2C_SLAVE_FORCE 加 read/write，适合单设备挂载且无总线竞争的场景。但我们更倾向于用 I2C_RDWR 方式，因为它能在一个ioctl调用内完成“先发寄存器地址、再收数据”的复合事务，不依赖系统调用多次访问，从时序上也更接近MCU里的单次 HAL_I2C_Mem_Read。

我们的用户态I2C HAL大致长这样：

c复制#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/i2c-dev.h>
#include <linux/i2c.h>
#include <sys/ioctl.h>
#include <string.h>

#define MPU6050_I2C_ADDR 0x68

int mpu_i2c_open(const char *bus_path)
{
    int fd = open(bus_path, O_RDWR);
    if (fd < 0) {
        perror("open i2c bus");
        return -1;
    }
    return fd;
}

int mpu_i2c_write_reg(int fd, uint8_t reg, uint8_t val)
{
    uint8_t buf[2];
    buf[0] = reg;
    buf[1] = val;

    struct i2c_msg msg;
    msg.addr = MPU6050_I2C_ADDR;
    msg.flags = 0;
    msg.len = sizeof(buf);
    msg.buf = buf;

    struct i2c_rdwr_ioctl_data data;
    data.msgs = &msg;
    data.nmsgs = 1;

    if (ioctl(fd, I2C_RDWR, &data) < 0) {
        perror("I2C_RDWR write");
        return -1;
    }
    return 0;
}

int mpu_i2c_read_regs(int fd, uint8_t reg, uint8_t *data, uint16_t len)
{
    struct i2c_msg msgs[2];

    msgs[0].addr = MPU6050_I2C_ADDR;
    msgs[0].flags = 0;
    msgs[0].len = 1;
    msgs[0].buf = &reg;

    msgs[1].addr = MPU6050_I2C_ADDR;
    msgs[1].flags = I2C_M_RD;
    msgs[1].len = len;
    msgs[1].buf = data;

    struct i2c_rdwr_ioctl_data data;
    data.msgs = msgs;
    data.nmsgs = 2;

    if (ioctl(fd, I2C_RDWR, &data) < 0) {
        perror("I2C_RDWR read");
        return -1;
    }
    return 0;
}

写寄存器那边我们没有使用带寄存器描述的write封装，而是直接把寄存器地址和值拼成两个字节发出去。MPU6050本身是寄存器顺序递增访问的设备，一次只写一个寄存器，两个字节就够了。但如果以后要操作带自动地址递增的寄存器块，也可以把这个函数扩展成 mpu_i2c_write_regs，发送 reg + data 的多字节组合。

这个HAL层里面还有一点容易被忽略：打开设备文件之后，我们没有调用 I2C_SLAVE_FORCE 去绑定从机地址，而是让每次 I2C_RDWR 消息里的 addr 来指定目标设备。这样做的好处是同一文件描述符可以被多条I2C总线上的设备复用，或者在一根总线上挂多个7位地址不同的传感器时，不需要重新执行ioctl切换地址。缺点就是每条消息都要写出目标地址，稍微繁琐一点，但更可控。

3.3 MPU6050初始化参数在移植中一个字都不用改的部分

MPU6050的关键初始化序列基本是所有平台上通用的。我们初始化时用到的一组核心配置如下：

移植时这些值不需要因为换了CPU就改。真正需要改的是寄存器读写的入口，也就是把上面的 mpu_i2c_write_reg 和 mpu_i2c_read_regs 填进原来写好的上层调用里。如果原来的上层代码风格是裸机HAL风格的 MPU_WriteReg(MPU_PWR_MGMT_1, 0x00)，那么C语言的函数指针调用方式很好替换。如果原来的代码是直接在一个硬编码函数里调用HAL库函数，那就先把这些调用替换成我们新封装的 mpu_i2c_write_reg，再放到合适的顺序里去执行。

3.4 数据读取的两种模式：寄存器直读和FIFO读

MPU6050内部数据寄存器从 ACCEL_XOUT_H（0x3B）开始，到 GYRO_ZOUT_L（0x48）结束，连续占14个字节。如果不想折腾FIFO，可以每隔一段时间直接把这14个字节读出来。这是最简单也最不容易出错的模式。我们在裸机调试初期就是这么干的，移植时也保留了这种方式。

FIFO读则稍复杂。芯片会把采样到的数据按序写入FIFO，你通过 FIFO_COUNTH/L 寄存器判断当前有多少数据，然后去读FIFO缓冲区。这种模式更适合需要精确控制数据时序的场合，比如配合DMP输出四元数时，很多信息都在FIFO里。但代价是你要监控溢出位，还得处理FIFO里数据对齐的问题。如果只是做基础姿态观察，直读模式足够，而且更容易排查问题。

我们移植后的代码主循环每个周期调用一次 mpu_i2c_read_regs(fd, 0x3B, raw_data, 14)，然后调用统一的解析函数换算成加速度和角速度。先把这步跑通，再谈要不要上FIFO和DMP。

3.5 数据换算过程中最容易算翻车的字节顺序

MPU6050输出的加速度和角速度原始值是16位有符号整数，大端字节序。也就是说高字节在低地址。从Linux接口读回来的数据数组，item[0]是 ACCEL_XOUT_H，item[1]是 ACCEL_XOUT_L，要拼成有符号数，不能简单地把两个字节左移再相加了事，因为符号位在高字节的最高位。正确做法是先把两个字节拼成无符号16位，再把指针强转成有符号16位，或者按下面的方式处理：

c复制int16_t accel_x = (int16_t)((raw[0] << 8) | raw[1]);

这一行代码在不同编译器上的行为基本一致，因为 (raw[0] << 8) | raw[1] 是先形成int类型，再窄化到int16_t，符号扩展由转换规则处理。用的时候可以把量程对应的灵敏度列成一张表，方便换算成物理值：

这个表如果查错一个数，后面算法出来的角度就会成倍偏大或偏小。而且它不像编译错误那么容易被发现，因为波形趋势看着很像，就是数值不对。我们早期在 ±500dps 下用了131的灵敏度去换算，结果角速度比实际慢了一半还多，排查了半天才发现是查表时没有看量程。

4. 真机调试实录：验证方法、信号排查与常见问题对照

代码写完只是第一步，真机调试才是耗时间的大头。这一节把调试阶段遇到的现象、原因和排查手段整理成清单，建议保存备用。

4.1 第一步先跑i2cdetect，确认设备在总线上

接到板子上电后，先别跑自己的程序，直接用系统工具确认硬件链路通不通。我们板子上的MPU6050挂在了 /dev/i2c-2，所以执行：

bash复制i2cdetect -y 2

如果设备正常，输出里应该在 68 位置出现一个地址块。这个 0x68 是MPU6050的经典7位地址，由AD0引脚电平决定：AD0接地是 0x68，接高是 0x69。如果扫描结果里 68 和 69 都没有，先把传感器断开，量一下排针上SDA和SCL是否有上拉电压。I2C总线需要上拉电阻，如果你们是拿模块直接插的，模块上通常已经有上拉；如果是自己画的板子或者飞线，要确保上拉接好了。没有上拉时，i2cdetect 的结果可能是一片空白，也可能不稳定地乱跳。

这里要特别提醒一句：不要对总线上所有地址都执行写操作探测。i2cdetect默认的扫描方式会读取设备地址，比较安全，但某些I2C设备对未知访问比较敏感，可能导致设备状态错乱。如果总线后面挂了别的I2C设备，尤其是不太熟悉的芯片，尽量用 i2cdetect -y -r 2 只用读模式扫描，降低风险。

4.2 用WHO_AM_I寄存器做二次确认

i2cdetect发现设备后，还需要读 WHO_AM_I 寄存器（0x75）确认挂在总线上的确实是MPU6050而不是其他地址碰巧相同的芯片。正常读到的是 0x68，也有一部分模块由于厂商配置原因读到 0x70 或 0x72，更高位可能因批次不同略有变化，但低四位一般是 0x08 之外的固定型号特征。拿到这个值后，对照数据手册第几页的说明，就能确定型号无误。

读WHO_AM_I也可以用来验证你封装的i2c读函数是否正常。如果 i2cdetect 能找到设备，但程序里 mpu_i2c_read_regs 读0x75总是返回失败，那大概率是打开的文件路径不对，或者你在程序里使用地址时习惯性地左移了一位。这时回看一下HAL库的例子：STM32H750的HAL接口要左移地址，而Linux i2c-dev里地址不要左移，这个差异真的很容易坑到从MCU转Linux的人。

4.3 数据全零的排查顺序

初始化完成后，如果读出来的加速度和角速度全为0，不要急着怀疑芯片坏了。先检查 PWR_MGMT_1（0x6B）是不是真的被写成了0。芯片上电默认处于睡眠模式，如果没有成功退出睡眠，数据寄存器不会更新，很多值就保持0或者固定初始值。你可以在初始化后把这个寄存器读回来打印出来看看，确认写入是否真的生效。打印寄存器值这个习惯在Linux用户态调试里特别有用，因为你不像在IDE里那样能直接用JTAG看寄存器。

第二个常见原因是采样率配置太低，或DLPF设置导致数据更新极慢，刚好在你读取的瞬间还没刷新。遇到这种情况时，可以把 SMPLRT_DIV 设成0，再把 CONFIG 寄存器里的低通滤波档位放宽一点，比如设成2，对应约94Hz带宽，数据刷新速度会明显提升，方便观察波形。

第三个原因是你在读取的14字节中，把某个量程位和采样率位的偏移搞错了。MPU6050的寄存器分布不难，但手滑写错一个地址也很要命。排查方法是先读取 ACCEL_XOUT_H 到 GYRO_ZOUT_L 的连续14字节，打印成十六进制，肉眼观察静止时哪些字节在跳。静止状态下加速度计Z轴应该有大约1g分量，对应的数值换算出来接近9.8。如果每个字节都纹丝不动，多半寄存器地址或者I2C读函数有问题。

4.4 数据恒定满量程，可能是什么原因

有一种现象比全零更迷惑人：静止时三个轴的加速度计数值都接近满量程，比如配置成±2g，读出来却一直是32767附近。这通常是配置寄存器没有真正写进去，或者I2C写入时寄存器地址偏移了一位。比如你本来想写0x1C（加速度量程寄存器），实际写到0x1D，那量程寄存器保持上电默认状态，同时0x1D这个保留位可能被写坏，引起后续数据异常。

应对方法很简单：每次写寄存器之后，马上读回来对照打印。我们为此写了一个简单的 mpu6050_reg_dump(fd) 调试函数，把0x19到0x1C这几个关键寄存器全部读出来，肉眼核对。真机上跑驱动，多写几个辅助打印函数，比任何调试器都好用。

4.5 中断方案怎么处理：轮询在实际项目里也不丢人

在H750裸机上，我们用HAL的GPIO外部中断响应MPU6050的INT引脚。但在Linux用户态，直接响应GPIO中断写起来比较绕，需要用一个专门的 gpiod 用户态库或者写一个小的内核模块把事件传递上来。走马观碑组这次的应用场景主要看姿态趋势，更新频率要求不高，因此我们采用了“定时轮询数据寄存器”的方式，10ms读一次，完全够用。

如果你在后边的项目里必须用中断，建议不要把中断处理逻辑跟业务代码写在一起，而是先写一个非常小的内核模块，只做一件事：监听GPIO中断，用中断线程化或工作队列把事件上报给用户态。这样可以保留中断实时性，同时避免在用户态反复轮询浪费CPU。不过轮询方案也有一个隐性问题需要考虑：你轮询太快，传感器FIFO没新数据，读到的会重复上一个周期的旧值；轮询太慢又可能丢中间变化。最简单的规避手段是先根据初始化设定的输出速率算出理论数据周期，然后让轮询周期略小于它，并添加上一次读数比较，同一个值连续两次出现时可以认为数据还没更新。

4.6 常见问题速查表

整理一个直接能拿去对照的表格，覆盖我们这次现场遇到过的问题。

这几点不见得覆盖所有异常，但覆盖了我们在这次项目中遇到的90%以上问题。调试新驱动时我也习惯先写好一个独立的“寄存器读写测试小程序”，不带上层算法，只做初始化、读WHO_AM_I、读加速度，然后打印。这个程序越小，越容易定位问题到底是驱动层还是算法层，强烈建议你也这样做。

5. 写在移植之后：代码规范和团队经验的沉淀

项目收尾阶段，我们做了一套小的代码整理，这里分享给同样以小组形式维护代码的团队参考。

5.1 把平台差异代码集中放一个目录

不管项目规模大小，我都建议把平台相关代码集中在一个明确的子目录或文件组里。像这次移植，最终结果可以概括成：

text复制mpu_driver/
  ├── mpu6050_core.c      // 寄存器配置、数据解析、DMP相关，与平台无关
  ├── mpu6050_core.h
  ├── plat/
  │   ├── i2c_hal.h       // 抽象出的I2C读写接口
  │   ├── i2c_hal_arm.c   // H750 HAL库实现
  │   └── i2c_hal_linux.c // 龙芯Linux i2c-dev实现
  └── main_loongarch.c    // 板级入口

这样做的好处是多人协作时不会互相踩代码。走马观碑组内部习惯是：谁改了 mpu6050_core.c，要跑全平台回归测试；谁只动 plat/ 下的文件，只需要在自己对应的板子上验证。这个约定让代码评审变得很快，基本不用关心对方改了哪几行逻辑，只要能过各自的硬件测试，就可以合入。

5.2 记录一份“移植操作单”比代码注释更有效

代码注释当然要写，但有些平台知识写注释里未必能表达清楚。我们组项目快结束时建立了一份移植操作单，用文档记录每一步操作而不是只解释函数在干什么。里面包含了几类关键信息：板卡I2C总线与物理引脚的对应关系、编译用的工具链前缀完整命令、密钥文件或权限配置的路径、复位和固件更新时要注意的断电顺序。为什么这样记录？因为代码注释回答的是“代码想干什么”，操作单回答的是“后续接手的人该按什么顺序做完整个流程”。驱动移植这种工作，新来的同事花在环境搭建上的时间常常比改代码多得多，一份准确的操作单能让新人少问好多问题。

我之前没有这个习惯，总以为代码清晰能跑就够了，直到有一次隔了三个月再碰同一块板子，忘了设备树里I2C总线对应的是哪个排针，又重新翻了一下午资料。那次以后，凡是涉及板子型号、固件版本、交叉编译链、设备树路径之类的环境信息，我都会落到项目的README里，写得越啰嗦越好。

5.3 我的一点实际体会

这次从STM32H750到龙芯Linux的MPU驱动移植，最大的收获不是学会了某个函数怎么调用，而是意识到“驱动移植的核心是抽象边界”。一开始只看代码，觉得要改的地方很多，但当把I2C访问层、寄存器配置层、数据解析层分开之后，真正要动手的代码量其实很小。后面在真机调试阶段，我总会想起那句话说：移植最耗时的不是代码本身，而是对平台资源的不熟悉。如果你也在做类似的事情，我建议在写任何业务代码前，先花半天把平台的I2C、GPIO、中断相关文档和设备树过一遍，这个时间后面一定会省回来。最后留一个小建议：真机验证时，优先做一个极简的寄存器读写测试程序和寄存器dump工具，不要一上来就上完整姿态算法。基础链路通了，后面所有问题都会变得容易定位很多。