MPU6050中断方式完全指南：寄存器配置、中断源选择与避坑实践

简介：针对MPU6050中断方式实现角度测量与小车转角控制的工程资料包，适合嵌入式开发者、无人机与平衡车爱好者以及STM32学习者使用。资源围绕MPU6050数据就绪中断驱动思路，讲解如何通过I2C配置寄存器、触发外部中断读取加速度与陀螺仪数据，并结合互补滤波或卡尔曼滤波消除噪声，最终经PID控制器驱动电机完成精确转向。资源共200个文件，压缩包5.18MB，以55个h头文件、52个c源码文件为核心，另含27个d调试信息、24个o目标文件、26个crf报告文件，以及hex烧录文件、uvprojx工程文件等，构成一套完整的Keil MDK开发工程，可直接编译烧录验证。已有5664人学习，内容覆盖MPU6050寄存器配置、I2C通信、中断引脚使用、滤波处理、PID控制及小车转向逻辑，同时附带工程清理脚本和备份文件，便于反复调试与二次开发。相比传统轮询方式，该资源提供了更高效率的角度采集触发机制，是学习IMU中断驱动控制的实用参考。

1. 为什么把 MPU6050 中断方式单独拎出来讲：从丢数据到数据连贯

做机械臂姿态闭环那阵子，我最先接触的 MPU6050 数据读取方式是轮询，主循环里定时读加速度计和陀螺仪，看似简单，但等到把采样频率拉到 200Hz 以上，问题就来了：I2C 总线被频繁占用，姿态解算一抖动，机械臂末端跟着画圈，调试时被那个低频抖动折磨了两天。后来把 MPU6050 的中断方式用起来，数据由传感器主动“通知”主控，轮询压力没了，姿态更新节奏也稳定了。这篇就把 MPU6050 中断方式从头拆到尾：寄存器怎么配、中断源怎么选、中断服务程序怎么写、哪些参数影响中断频率，以及我翻车过的几个坑。适合正在做单片机传感器采集、飞控姿态解算或者学生竞赛项目的开发者，新手能照着把中断跑通，熟手可以对照参数和边界做优化。

2. 中断先从寄存器说起：0x37、0x38、0x3A 三个地址决定行为

2.1 中断引脚配置寄存器 0x37：电平、锁存与清除策略

MPU6050 的中断是一个物理引脚 INT，默认配置时它是个低电平有效的高电平输出。很多第一次接触的人以为“开了中断就能用”，实际上 INT 脚的电气行为完全由 0x37 寄存器控制，这个寄存器叫 INT_PIN_CFG。

我把 0x37 一般写成0xC1，也就是INT_LEVEL=1、LATCH_INT_EN=1、INT_RD_CLEAR=1。这样配置在大多数 MCU 上都通用。

脉冲方式的中断只在事件发生时拉出约几微秒到几十微秒的脉冲，如果主控的 GPIO 中断响应不及时，这个脉冲就丢了；锁存方式则把中断状态保持住，直到寄存器被读取或清除，主循环再忙也不怕漏。代价是如果忘了读状态寄存器，中断脚会一直拉高，主控会误以为持续有中断。

这里有个容易被忽略的点：当INT_RD_CLEAR=1时，主控读取 0x3A 状态寄存器的那一个 I2C 事务本身就会清中断，所以中断服务程序里的读取顺序要固定为“先读状态、再读数据”，不然数据还没取走，中断标志就被清了。

2.2 中断使能寄存器 0x38：哪些事件能上报就看它

0x38 叫 INT_ENABLE，控制哪些事件可以触发 INT 脚变化。数据就绪中断、FIFO 溢出中断、运动检测中断都在这里使能。

数据就绪中断是最常开的一个位，它告诉主控“这一组加速度和角速度已经采样完成”，主控收到通知后再启动一次 I2C 读取，这样能保证读到的是最新的一组数据，而不是读到新旧拼接的过渡数据。配合SMPLRT_DIV采样率分频，中断频率就是采样频率，节奏非常固定。

FIFO 溢出中断更适合开了 DMP 或高采样率的场景：传感器内部 FIFO 能缓存 512 字节，当主控因为高优先级任务暂时没有过来读数据时，FIFO 兜住了。但如果 FIFO 满了，新数据会覆盖旧数据，溢出中断就是用来告诉主控“你来得太慢了”。

运动检测中断则很少用于连续数据采集，它适合用在低功耗唤醒场景：平时主控和传感器都睡过去，检测到运动以后通过 INT 脚把主控拉醒。我调过一次某便携设备项目，就是用运动检测中断做自动唤醒，把待机功耗压到了 0.5mA 以下。

2.3 采样率与数字低通滤波：中断频率由谁决定，参数怎么定

很多人把中断频率理解成“按一个任意时间周期触发”，这不准确。MPU6050 的数据采样环路是固定的：内部以 1kHz 为基准时钟，经过SMPLRT_DIV分频得到实际采样频率，再经过 DLPF 数字低通滤波器，最终产生一帧数据。只有当一帧新数据完成时，数据就绪中断才会被触发。

采样频率计算公式：

采样频率 = 1kHz / (1 + SMPLRT_DIV)

其中SMPLRT_DIV是 0x19 寄存器的值。写0x09就是 100Hz 采样，写0x63就是 10Hz 采样。我一般做姿态解算时用 100Hz 到 200Hz 的采样率，对应0x19分别写4和9。

DLPF 配置在 0x1A，它影响的是传感器原始数据进入采样环节前的带宽。带宽越低，噪声越小，但信号延迟越大。0x1A 的配置位DLPF_CFG从 0 到 6，对应不同的加速度计和陀螺仪带宽：

要注意一个隐藏参数：当DLPF_CFG非 0 时，内部采样率会被强制设为 1kHz，SMPLRT_DIV才完全生效。如果DLPF_CFG=0且SMPLRT_DIV=0，内部采样率其实是 8kHz，中断触发频率会变高很多，很多人对不上中断频率就是栽在这个组合上。

2.4 我惯用的初始化顺序：先复位、再配引脚、后开使能

MPU6050 的寄存器有内部状态相关性，配置顺序错了，中断要么不触发，要么触发得乱七八糟。我惯用的初始化顺序如下，这段代码可以直接放到 MCU 工程里跑通。

void mpu6050_irq_init(void) { // 1. 复位整个器件：写 0x80 到 PWR_MGMT_1 i2c_write_byte(0x68, 0x6B, 0x80); delay_ms(100); // 2. 唤醒并选择时钟源：写 0x01，用 X 轴陀螺仪时钟 i2c_write_byte(0x68, 0x6B, 0x01); // 3. 关闭温度传感器，不影响后续数据读取 i2c_write_byte(0x68, 0x6B, 0x01); // 4. 配置采样率分频：0x19 = 9，得到 100Hz 采样 i2c_write_byte(0x68, 0x19, 0x09); // 5. 配置 DLPF：0x1A = 0x03，44Hz 陀螺仪带宽 i2c_write_byte(0x68, 0x1A, 0x03); // 6. 配置中断引脚电平、锁存和自动清除 i2c_write_byte(0x68, 0x37, 0xC1); // 7. 清除中断状态：读一次 0x3A i2c_read_byte(0x68, 0x3A); // 8. 最后使能数据就绪中断 i2c_write_byte(0x68, 0x38, 0x01); }

第 1 步的复位操作会清空所有寄存器，复位后器件默认睡在低功耗状态，所有中断都是关闭的，必须等 100ms 级别的时间让内部上电时序走完。第 2 步和第 3 步看起来重复，其实一个是唤醒，一个是锁时钟源，某些批次芯片必须先写外部时钟源才能稳定输出中断，这就是一个已知的硬件玄学。第 4 步和第 5 步决定了中断触发频率和信号质量，采样频率设太高而带宽设太低，中断间隔会明显抖动，后面会细说。第 6 步把中断脚配置成高电平锁存模式，第 8 步再开使能，避免初始化过程中产生毛刺触发误中断。

3. 三种中断源怎么选：数据就绪、FIFO 溢出与运动检测

3.1 数据就绪中断：低频常规采集的首选

如果你的项目只是周期性地读加速度计和陀螺仪，对实时性要求又不是极端苛刻，数据就绪中断是最直观的方案。每产生一帧新数据，INT 脚就拉高一次，主控在中断服务程序里直接读取 0x3B 开始的 14 个字节寄存器，把加速度计和陀螺仪的数据一起拿回来。

这个方式的好处是数据永远不会读重或读漏。轮询方式最大的问题就是不知道传感器什么时候更新数据，读快了读到旧数据，读慢了丢数据；数据就绪中断等于把时序同步的责任交给了传感器硬件，主控只要在中断里读取即可。

我实际测试过，100Hz 采样率下，数据就绪中断的触发间隔非常稳定，偏差在微秒量级。这主要归功于内部采样时钟固定，不像很多外部 RTC 芯片那样有温漂。做姿态融合算法时，稳定的数据采样间隔是算法不发散的前提。

它的局限在于：如果中断服务程序里读取太慢，超过了采样周期，那每次中断还没来得及读完，下一次就绪事件已经发生了。这时 INT 脚可能因为电平锁存而保持高电平，主控会反复进入中断，数据反而变得混乱。所以数据就绪中断适合采样率不太高、中断服务程序足够短的应用。

3.2 FIFO 溢出中断：DMP 姿态解算和突发数据量的兜底

MPU6050 内部的 FIFO 可以缓存最多 512 字节的数据，当开了 DMP 时，加速度计、陀螺仪、四元数都会往 FIFO 里写，数据速率可能超过 400Hz。如果主控忙于处理其他事务，比如通信协议栈或屏幕刷新，短暂离开传感器读取，FIFO 就能缓冲这段时间的数据。

FIFO 溢出中断的思路是：主控不用频繁进入中断，而是等到 FIFO 快满或者溢出时才被通知，然后一次性把 FIFO 里积累的数据全读出来。这段时间里传感器一个数据都没丢，只是读得晚了一点。

使能 FIFO 溢出中断需要两步：先要把 FIFO 使能打开，然后开中断位。只配 0x38 而不打开 FIFO 功能，这个中断永远不会触发。FIFO 使能位在 0x6A 的FIFO_EN和 0x23 的FIFO_EN寄存器里，前者是总开关，后者决定哪些数据源写入 FIFO。

// 使能 FIFO，并开启 FIFO 溢出中断 i2c_write_byte(0x68, 0x6A, 0x40); // USER_CTRL: 打开 FIFO i2c_write_byte(0x68, 0x23, 0x78); // 加速度计+陀螺仪+温度写入 FIFO i2c_write_byte(0x68, 0x38, 0x10); // FIFO_OFLOW_EN

0x23的0x78表示同时把加速度计、陀螺仪和温度数据写入 FIFO，如果你的应用不需要温度数据，可以改成0x70或者0x60，节省 FIFO 空间。FIFO 溢出中断的频率不是固定的，它取决于数据生产速度和主控消费速度的差值，生产快、消费慢，溢出就来得频繁。

3.3 运动检测中断：低功耗等待，而不是采集数据

运动检测中断的设计意图和上面两种完全不同。它不关心具体数值，只关心“有没有运动”。MPU6050 内部有一个运动检测引擎，当加速度的变化超过阈值时，会在 0x3A 状态寄存器里置位运动标志，并触发 INT 脚。

这个中断适合做跌落检测、振动唤醒、防盗报警这类应用。我做过一个电池供电的小设备，平时系统睡眠，只有传感器在低功耗模式下侦测运动，一旦检测到动作，INT 脚唤醒主控，主控再正常读取数据并执行后续逻辑。

配置运动检测时，需要同时设置 0x69 的检测阈值和 0x1F 的检测时间窗口。阈值设置得越低，越灵敏，但也会越容易误触发。我一般把阈值设为 10 到 20，对应加速度变化量大约 0.16g 到 0.31g，具体数值要结合安装姿态标定。

3.4 中断状态寄存器判读：先读状态，再决定下一步

无论使能了哪种中断，中断服务程序的第一件事都应该是读取 0x3A 中断状态寄存器，确认到底是哪个事件触发了这次中断。因为同一时刻可能有多个事件，比如数据就绪和 FIFO 溢出同时发生，如果不读状态而直接处理数据，会漏掉另一个事件。

uint8_t mpu6050_get_int_status(void) { uint8_t status = 0; i2c_read_byte(0x68, 0x3A, &status); return status; }

返回的状态值按位解析：0x01是数据就绪，0x10是 FIFO 溢出，0x40是运动检测。我一般会在中断服务程序里先把这个状态读出来缓存，然后在主循环里做分支处理。注意读 0x3A 这个动作同时会清除中断标志，所以读出来的状态值如果还需要后续用，必须立刻存到一个全局变量里，不能等中断服务程序跑到后面再读寄存器，那时状态已经被清掉了。

4. 中断服务程序设计：把 I2C 读时延变成可控事件

4.1 中断服务程序的“读、清、存”三段论

中断服务程序虽然代码短，但结构必须固定。我总结成三个步骤：读状态、清标志、存数据。这三个步骤的顺序和实现方式，直接影响系统可靠性。

volatile uint8_t mpu_int_status = 0; volatile int16_t mpu_accel[3] = {0}; volatile int16_t mpu_gyro[3] = {0}; void EXTI_IRQHandler(void) { // 第一步：读中断状态，同时清中断 i2c_read_byte(0x68, 0x3A, (uint8_t *)&mpu_int_status); // 第二步：如果是数据就绪，读取传感器数据 if (mpu_int_status & 0x01) { uint8_t buf[14]; i2c_read_bytes(0x68, 0x3B, buf, 14); // 第三步：把原始字节拼成有符号整数，存入全局变量 mpu_accel[0] = (int16_t)((buf[0] << 8) | buf[1]); mpu_accel[1] = (int16_t)((buf[2] << 8) | buf[3]); mpu_accel[2] = (int16_t)((buf[4] << 8) | buf[5]); mpu_gyro[0] = (int16_t)((buf[8] << 8) | buf[9]); mpu_gyro[1] = (int16_t)((buf[10] << 8) | buf[11]); mpu_gyro[2] = (int16_t)((buf[12] << 8) | buf[13]); mpu_data_ready = 1; } }

第一步读 0x3A 是必须的，因为配置了INT_RD_CLEAR=1后，读这个寄存器就是清中断的动作。第二步读数据紧跟在清中断之后，避免中断标志清了但数据还没读，新中断又闯入导致数据错位。第三步把大端字节序转换为有符号整数，MPU6050 所有数据寄存器都是高位在前，直接拼接即可。

这里会有人问：I2C 读取在中断服务程序里执行，会不会阻塞太长时间？对于大多数主控，I2C 时钟在 400kHz 时读 14 个字节大约耗时 300 微秒左右，100Hz 采样周期是 10 毫秒，这个耗时完全可接受。如果主控还有更高优先级的中断，比如 USB 通信或电机控制，可以把 I2C 读取放到主循环，但那就需要更复杂的握手协议，一般 MCU 场景不必这样设计。

4.2 用环形缓冲区解决突发数据：中断里只放，主循环里取

数据就绪中断适合低频采样，但如果你把采样率调到 500Hz 以上，中断服务程序每 2 毫秒就要执行一次，而主循环还要处理显示、通信、控制逻辑，单靠全局变量交换数据很容易丢帧。这时候可以引入一个简单的环形缓冲区。

#define MPU_RING_SIZE 16 volatile int16_t mpu_ring[MPU_RING_SIZE][6]; volatile uint8_t mpu_ring_head = 0; volatile uint8_t mpu_ring_tail = 0; static uint8_t mpu_ring_next(uint8_t idx) { return (idx + 1) % MPU_RING_SIZE; } void EXTI_IRQHandler(void) { uint8_t status; uint8_t buf[14]; uint8_t idx; i2c_read_byte(0x68, 0x3A, &status); if (!(status & 0x01)) { return; } i2c_read_bytes(0x68, 0x3B, buf, 14); idx = mpu_ring_head; mpu_ring[idx][0] = (int16_t)((buf[0] << 8) | buf[1]); mpu_ring[idx][1] = (int16_t)((buf[2] << 8) | buf[3]); mpu_ring[idx][2] = (int16_t)((buf[4] << 8) | buf[5]); mpu_ring[idx][3] = (int16_t)((buf[8] << 8) | buf[9]); mpu_ring[idx][4] = (int16_t)((buf[10] << 8) | buf[11]); mpu_ring[idx][5] = (int16_t)((buf[12] << 8) | buf[13]); mpu_ring_head = mpu_ring_next(idx); } uint8_t mpu_ring_pop(int16_t out[6]) { uint8_t idx; uint8_t count; if (mpu_ring_head == mpu_ring_tail) { return 0; } idx = mpu_ring_tail; out[0] = mpu_ring[idx][0]; out[1] = mpu_ring[idx][1]; out[2] = mpu_ring[idx][2]; out[3] = mpu_ring[idx][3]; out[4] = mpu_ring[idx][4]; out[5] = mpu_ring[idx][5]; mpu_ring_tail = mpu_ring_next(idx); return 1; }

缓冲区的容量MPU_RING_SIZE设为 16，可以暂存最近 16 组数据。中断里只往环形缓冲区写数据，主循环用mpu_ring_pop()取数据，缓冲区空时返回 0，主循环不用等待。这套结构的关键在于对head和tail的维护：中断里只能改head，主循环里只能改tail，两者不会竞争同一个变量，这是无锁环形缓冲区能工作的根本原因。

如果缓冲区满，也就是head追上tail，新数据会覆盖最旧的数据。对于姿态控制这类应用，丢弃最旧数据比丢最新数据更合理，因为控制算法关心的是最新的状态。如果你关心的是完整的录波数据，那要反过来丢最新数据或直接增大缓冲区。

4.3 FIFO 与中断的竞争条件：FIFO 计数和数据的配对问题

FIFO 溢出中断场景下，主控在中断里读取 FIFO 时，中断服务程序里也一直有数据写入。数据生产方是传感器硬件，消费方是主控，两者之间不是同步关系。最典型的坑是：先读 FIFO_COUNT，再读 FIFO_DATA，中间有新的数据写进来，导致读出的数量和你预期的对不上。

uint16_t mpu_fifo_count(void) { uint8_t buf[2]; uint16_t count = 0; i2c_read_bytes(0x68, 0x72, buf, 2); count = (uint16_t)((buf[0] << 8) | buf[1]); return count; }

FIFO_COUNT 是 16 位寄存器，表示当前 FIFO 中寄存的字节数。读完计数寄存器后，再去读 FIFO_DATA 数据寄存器，这中间每次 I2C 事务都有新数据可能进入 FIFO。当传感器数据速率快、FIFO 又比较满时，读出数量会低于实际写入数量。

解决办法是设置一个允许误差。比如按计数读出的字节数假设是 12 字节，实际可能已经变成 20 字节，就按 20 字节把数据都读出来，多读的字节再放进环形缓冲区排队。最稳妥的方式是每次把 FIFO 读完，读到一个空标志为止，而不是依赖计数器的绝对值。不过每次中断里全量读空 FIFO，中断处理时间可能会有较大波动，所以更推荐的策略是：读计数之后立即连续读数据，中断结束时如果再读计数不为零，说明这次没有读干净，下次中断先处理残留。

4.4 完整初始化与中断服务代码：可以直接跑的最小工程

把上面的片段拼起来，一个最小可用的 MPU6050 中断方式工程是这样。中断配置走前面第 2 章的初始化序列，中断服务程序处理数据、写环形缓冲区，主循环不断弹出数据做姿态解算。

int main(void) { int16_t data[6]; // 初始化 I2C 硬件 i2c_init(400000); // 配置 MPU6050 中断 mpu6050_irq_init(); // 配置外部中断 GPIO，上升沿触发 gpio_irq_init(MPU_INT_PIN, GPIO_IRQ_RISING); nvic_enable_irq(EXTI_IRQn); while (1) { if (mpu_ring_pop(data)) { // 这里放姿态解算、控制逻辑或日志输出 process_sensor_data(data); } } }

主循环里不做任何传感器读取动作，只消费环形缓冲区里的数据。中断服务程序和主循环天然解耦，主循环里即使临时跑了一段耗时任务，数据也不会丢，最多是消费延迟了一点。这个设计在裸机环境下够用，如果上 RTOS，可以把mpu_ring_pop放到一个高优先级任务里，逻辑完全一致。

5. 中断方式避坑：五个我踩过的真实问题

5.1 读取中断状态寄存器后，中断标志仍然不消失

现象：中断触发后主控进入中断服务程序，读 0x3A 也清了标志，但 INT 引脚依然维持高电平，主控反复进入中断，系统卡死。仔细检查发现读到的状态值一直是 0x01，清不掉。

原因：当LATCH_INT_EN=1和INT_RD_CLEAR=1同时配置时，读取 0x3A 的清中断动作只对“当前已经置位的中断源”有效。但如果数据就绪事件发生得比读取动作更快，比如采样率 500Hz、中断服务程序执行时间超过 2 毫秒，上一次中断还没处理完，下一次数据就绪已经置位，中断脚永远有新的标志挂着。

解决：把采样率调低，或者缩短中断服务程序的耗时。我后来把 I2C 时钟从 100kHz 提到 400kHz，中断里 14 字节读取时间从约 1.1 毫秒缩到约 300 微秒，问题明显改善。如果主控 I2C 外设支持 DMA，可以直接开 DMA 传输，中断里只启动 DMA，由 DMA 传输完成中断再处理数据。

5.2 中断脚拉电平配置反了，主控收不到中断

现象：GPIO 中断配置成上升沿触发，INT 脚也配置成高电平有效，但按中断后主控完全没有反应。用万用表测 INT 脚电压，发现平时和触发时都是低电平。

原因：MPU6050 的 INT_LEVEL 位在不同批次寄存器手册里存在新旧命名差异，有些手册把INT_LEVEL=0定义为高电平有效，有些定义为低电平有效。某个开发者沿用旧代码把 0x37 写成0x81，型号新一批的芯片行为完全相反，电平逻辑反了。

解决：先写一个不带中断的测试代码，把 INT 脚配成普通 GPIO 输入，然后开数据就绪中断，用轮询方式持续读 GPIO 电平，看它平时是什么电平、数据就绪瞬间是什么电平。确认实际极性后再配置外部中断的触发边沿。从那以后我拿到任何一个传感器模块，第一件事都是先测引脚静态电平和事件电平，不再盲信手册里的定义。

5.3 芯片睡眠后重新唤醒，中断配置全部丢失

现象：低功耗项目里，主控睡眠前关掉 MPU6050 中断，唤醒后再打开中断，却始终收不到数据就绪信号。重新跑一遍完整初始化才恢复。

原因：MPU6050 进入睡眠模式后，部分寄存器会回到复位值，比如 0x38 中断使能寄存器、0x37 中断引脚配置寄存器、0x19 采样率分频寄存器。唤醒时只写了 0x6B 清除睡眠位，并没有重新配置中断相关寄存器，中断自然不工作。

解决：把整个初始化函数抽成一个mpu6050_irq_init()，睡眠前不单独操作传感器寄存器，唤醒后直接调用初始化函数。初始化函数内部自带 100ms 延时，刚好覆盖器件唤醒时间。我一般还会在初始化函数末尾读取一次 0x3A 状态寄存器，把可能残留的中断状态清干净，避免唤醒瞬间误触发。

5.4 中断服务程序里做了太多事，导致中断嵌套和数据错乱

现象：中断里既读传感器，又做了一部分姿态解算，还往串口打印日志，结果串口输出的是乱码，姿态数据偶尔跳变。

原因：中断服务程序里调用了串口发送函数，而串口发送本身会等待发送完成标志，这个等待过程可能超过采样周期，导致新中断触发。多个中断嵌套执行时，全局变量被中途改写，数据尚未拼完整就被下一个中断覆盖。

解决：中断服务程序只做最少量的事。我后来的习惯是中断里只有“读 0x3A、读 14 字节、写环形缓冲区、置标志”四步，串口打印、姿态解算、控制输出全部挪到主循环。如果确实需要保留高优先级操作，也要把串口这类慢速外设放到主循环。

5.5 采样率和滤波器带宽不匹配，中断间隔忽长忽短

现象：采样率按公式设置为 400Hz，SMPLRT_DIV写 1，但用逻辑分析仪抓 INT 脚，发现中断间隔不是固定的 2.5 毫秒，而是 2.1、2.8、2.4 毫秒抖动明显。

原因：前面提到过DLPF_CFG=0时内部采样率是 8kHz，这时SMPLRT_DIV=1对应的实际采样率是 4kHz，远超预期。主控中断处理不过来，数据就绪事件排队，表现为中断间隔抖动。另外 DLPF 带宽设得太低时，滤波器本身有建立时间，采样事件产生周期也会有微小波动。

解决：先把DLPF_CFG设为非 0 值，比如 0x03 对应 44Hz 带宽，强制采样率回到 1kHz，再用SMPLRT_DIV设置目标频率。同时用逻辑分析仪实测中断间隔，如果抖动超过采样周期的 10%，优先检查 I2C 是否被其他总线事务干扰，以及中断服务程序里有没有非固定耗时的函数调用。

6. 中断调试三板斧：用逻辑分析仪和 GPIO 脉冲验证时序

中断驱动代码跑起来之后，最重要的验证不是看姿态数据对不对，而是确认中断本身的节奏是否稳定。我每次调完都会做三个检查。

第一，把 INT 脚、SDA、SCL 三根线并到逻辑分析仪上，采样率设到 4MHz 以上，触发条件设成 INT 上升沿。跑几秒数据，观察中断波形：理想情况是等间隔脉冲，脉冲宽度对应锁存电平保持时间。如果中断间隔忽大忽小，说明采样率配置或者中断服务程序耗时有问题。如果波形中出现连续两个紧挨着的脉冲，说明中断服务程序在两次中断之间没有及时读完数据。

第二，拿一个空闲 GPIO 脚做“探针”。进入中断服务程序时把探针脚拉高，退出时拉低，逻辑分析仪同时抓探针脚和 INT 脚。探针的高电平时间就是中断服务程序的实际执行时间。我调过的系统里，一个干净的中断服务程序执行时间一般在 300 到 500 微秒，如果超过 1 毫秒，就要考虑精简代码。

void EXTI_IRQHandler(void) { GPIOB->BSRR = GPIO_PIN_7; // 探针脚拉高，开始计时 // 读取 MPU6050 数据 GPIOB->BRR = GPIO_PIN_7; // 探针脚拉低，计时结束 }

第三，在中断服务程序里放一个连续计数器，每进入一次中断加一。主循环每秒打印一次计数器的值和理论中断次数做对比。比如 100Hz 采样率跑 10 秒，计数器应该接近 1000，误差在个位数以内算正常。如果差得很多，要么中断被更高优先级任务长期屏蔽，要么中断脚配置有误。

这套验证做完，MPU6050 中断方式才算真正稳了。中途的翻车经历让我养成一个习惯：从那以后我每次拿到传感器，不管是不是 MPU6050，都先把数据就绪中断跑通、用逻辑分析仪测一遍触发间隔和中断服务耗时，再决定要不要继续调数据解算。顺序对了，问题就少一半。希望帮到你。

本文还有配套的精品资源，点击获取