如果你是第一次把 ST 的 LSM6DSV 接到自己项目里，多半会遇到这样一个场景：驱动代码已经能从 WHO_AM_I 寄存器读到正确的设备 ID，加速度计和陀螺仪的数据也能正常更新，但当你准备用中断功能，打算把 INT1 拉出来做唤醒或者数据就绪信号时，问题就来了——中断怎么都不触发，或者信号乱跳到你以为传感器坏了。回头看配置代码，里面同时涉及 ACC 和 Gyro 相关的寄存器和位，于是开始纠结：INT1 的中断源，到底该选 Acc 还是 Gyro？
这篇文章不打算只丢一个“应该这样配”的结论，而是把我实际调试这颗传感器时记录的笔记完整还原一遍：中断线的映射机制、两种最常见的配置姿势、排障过程和验证方法都会展开讲。适合正在写 LSM6DSV 驱动的嵌入式工程师，也适合刚从 LSM6DSO/LSM6DSR 迁移过来、被新寄存器版本搞糊涂的朋友。如果你只是想在 I2C/SPI 上把数据读出来，那这篇可能帮不上太多；但只要你的板子上有“INT1 接 MCU 外部中断”这种设计，这篇就值得花十分钟看完。
1. 为什么 INT1 的中断源问题会成为一个真问题
先说结论：ACC 和 Gyro 都可以成为 INT1 的中断源，但它们是以“事件”为单位配置的，不是以“传感器”为单位配置的。这句话听起来像绕口令，但实际调试中，几乎所有困惑都源于这里。
LSM6DSV 这颗料和 ST 前几代高端 IMU 一样，内部集成了三轴加速度计和三轴陀螺仪，同时还带了一套复杂的中断管理逻辑。芯片对外只暴露两个物理中断引脚：INT1 和 INT2。这两个引脚本质上是两个“出口”，可以承载多种内部事件。事件种类很多，包括：
- 加速度计数据就绪（DRDY_XL）
- 陀螺仪数据就绪（DRDY_G）
- FIFO 相关事件（满、溢出、阈值）
- 唤醒检测（Wake-Up）
- 自由落体检测（Free Fall）
- 单击/双击检测（Single/Double Tap）
- 6D/4D 方向检测
- 计步器事件
- Tilt 倾斜检测
- 机器学习核（MLC）输出事件
这里存在一个天然的“不对称”：DRDY（数据就绪）这种事件是 Acc 和 Gyro 各自独立产生的，而 Wake-Up、Free Fall、Tap、6D 这类功能事件，底层几乎全部由加速度计数据计算得到，陀螺仪并不参与。所以当你打开 INT1_CTRL 寄存器，看到 INT1_DRDY_XL 和 INT1_DRDY_G 两个 bit 并列时，你以为自己在选择“INT1 到底接哪颗传感器”；但当你准备做唤醒功能时，你会发现根本没有“INT1_GYRO_WU”这个选项——因为唤醒检测本来就不依赖陀螺仪。
从实际项目需求出发，INT1 挂哪个源，取决于你到底想用中断干什么：
| 需求 | 正确的 INT1 中断源 | 核心理由 |
|---|---|---|
| 每次 Acc+Gyro 数据都准备好，通知 MCU 去读 | 同时开 INT1_DRDY_XL + INT1_DRDY_G | 两个传感器各自产生数据就绪，需要同时监听 |
| 只要读 Acc 数据，不关心陀螺仪 | 只开 INT1_DRDY_XL | 陀螺仪此时可以完全不配置或保持低功耗 |
| 低功耗运动唤醒 MCU | 开 INT1_WU（功能事件，来自 Acc） | 唤醒检测链路只使用加速度计，功耗最低 |
| 检测设备自由落体 | 开 INT1_FF（功能事件，来自 Acc） | Fall Detection 只基于加速度计 |
| 检测按键双击或屏幕双击唤醒 | 开 INT1_DOUBLE_TAP（来自 Acc） | Tap 检测只对加速度计做特征分析 |
所以你看到的问题“Acc or Gyro”，严格来说不是一个二选一问题，而是一个“事件源”和“绑定传感器”错位的问题。理解这一点之后，再去看数据手册里的寄存器位，就顺多了。
2. 中断路由机制拆解：事件源、路由寄存器和最终引脚的三层关系
要把 LSM6DSV 的中断系统理顺，可以把它拆成三层。最底层是事件源，也就是 Acc、Gyro 以及各种算法引擎产出的信号；中间层是路由开关，由若干寄存器位决定某个事件能不能流向某个物理引脚；最顶层才是INT1/INT2 物理引脚。
2.1 INT1_CTRL 到底在控制什么
很多人最大的误解是：INT1_CTRL 这个名字听上去像“INT1 引脚控制寄存器”，那它应该就是控制 INT1 引脚的所有行为吧？实际上不是。
INT1_CTRL 只是一组路由开关，决定哪些内部事件可以“走到”INT1 引脚上。它控制的是“有没有资格”，而不是“引脚本身怎么工作”。引脚的电平极性、上拉/推挽这些，由更底层的寄存器（如 CTRL3_C 的 H_LACT、PP_OD 等位）控制。
以 LSM6DSV 的 INT1_CTRL 寄存器为例，常见位定义大致是：
- bit7：INT1_DRDY_XL，加速度计数据就绪事件
- bit6：INT1_DRDY_G，陀螺仪数据就绪事件
- bit5：INT1_CNT_OVR，计步器计数溢出
- bit4：INT1_FIFO_TH，FIFO 阈值事件
- bit3：INT1_FIFO_OVR，FIFO 溢出
- bit2：INT1_FIFO_FULL，FIFO 满
- bit1：INT1_FF，自由落体
- bit0：INT1_WU，唤醒运动检测
（不同批次或系列的子版本，bit 顺序可能有细微差异，建议以你手上的数据手册为准。）
注意看，这一组位里同时包含了 Acc 相关的 DRDY_XL、Gyro 相关的 DRDY_G，以及一堆“功能事件”（FF、WU）。也就是说，寄存器设计者从一开始就预期你会把一个物理引脚同时分配给多种事件，而不是只能绑定某颗传感器。这正好回扣了第一节的结论：INT1 中断源是事件级的，不是传感器级的。
2.2 另一组容易漏掉的路由寄存器：MD1_CFG / MD2_CFG
只配 INT1_CTRL 往往不够完整。LSM6DSV 沿用了 ST 高端 IMU 的双寄存器组设计：除了 INT1_CTRL 之外，还有一组 MD1_CFG / MD2_CFG（Master Data Configuration？有的文档叫 Motion Detection Configuration），用来路由另外一批高级事件到 INT1/INT2。
MD1_CFG 里你能找到 Tilt、6D/4D 检测、单双击、计步器事件等。以 MD1_CFG 为例，大致包含：
- INT1_TILT：倾斜检测事件
- INT1_6D：6D 方向检测
- INT1_4D：4D 方向检测
- INT1_DOUBLE_TAP：双击事件
- INT1_SINGLE_TAP：单击事件
- INT1_MOTION：运动检测（另一种基于加速度计的运动判定）
- INT1_STEP_DETECTOR：计步器步数检测
- INT1_STEP_COUNT_OV：计步器溢出
调试中最常见的坑是：你在 INT1_CTRL 里翻了半天没找到 Tap 事件，以为这颗芯片不支持单击中断，其实 Tap 的路由位被放在了 MD1_CFG 里。所以拿到新料号不要只看一个寄存器的表，要把 INT1_CTRL 和 MD1_CFG 两张表拼在一起看。
2.3 事件源的真实绑定关系
把常用事件和底层传感器绑在一起，大概是这张表：
| 事件类型 | 底层数据源 | 是否需要陀螺仪 |
|---|---|---|
| DRDY_XL | 加速度计 | 否 |
| DRDY_G | 陀螺仪 | 是 |
| Wake-Up | 加速度计 | 否 |
| Free Fall | 加速度计 | 否 |
| Single/Double Tap | 加速度计 | 否 |
| 6D/4D Orientation | 加速度计 | 否 |
| Tilt | 通常使用重力向量变化 | 不需要 |
| Step Counter | 加速度计 | 否 |
| MLC 输出 | 取决于你训练模型输入 | 可能 |
你会发现，绝大部分功能事件都绑定加速度计。这背后是产品定位的考虑：高精度、高数据率的陀螺仪适合做姿态、防抖、导航这类实时计算；但唤醒、Tap、方向检测更看重“持续运行且功耗低”。加速度计在低数据率下功耗可以压得很低，适合做常开传感器。ST 把中断检测的主力压在加速度计这边，是符合可穿戴和 IoT 设备功耗预期的设计。
2.4 一个拿来类比形象的比喻
把整个中断系统想象成一栋办公楼：Acc 和 Gyro 是两个部门，数据就绪事件是部门门外的“叫号屏”亮灯；Wake-Up、Tap 这些功能事件则像保安系统，只归 Acc 部门管，Gyro 部门不参与。INT1_CTRL、MD1_CFG 是楼里的“通行许可清单”，INT1 引脚是大门。只有当某个事件既被登记在通行许可清单上，又实际产生了信号，门口的电铃才会响。你问“INT1 Source 是 Acc 还是 Gyro”，就好比问“大门入口的人来自哪个部门”——既可能是 Acc 部门的普通职员（DRDY_XL），也可能是 Acc 部门的保安（WU/TAP），甚至可能是 Gyro 部门的职员（DRDY_G）。单独说“Acc or Gyro”，永远说不全，得具体到“哪个事件”。
3. 两种典型需求下的寄存器配置实操
光讲原理不够，直接上可跑的配置。下面两套示例代码是实际调试中用到的，寄存器地址和位定义基于 LSM6DSV 的手册思路整理，具体到你的编译环境，请对照数据手册一次确认。
3.1 场景 A：每来一帧 Acc+Gyro 数据，拉一次 INT1
这是最常见的用法，尤其在做姿态解算时，MCU 不想轮询，希望传感器数据准备好了，INT1 来一个上升沿，MCU 再进入读取。
配置逻辑：
- 把 LSM6DSV 软复位，等待复位完成。
- 配置加速度计：量程 ±4g，ODR 52Hz（根据需求选）。
- 配置陀螺仪：量程 ±250dps，ODR 52Hz。
- 打开 CTRL3_C 的 BDU 和 IF_INC，保证数据读取时不会出现高低字节错位，同时寄存器自动递增方便连续读。
- 在 INT1_CTRL 中同时打开 INT1_DRDY_XL 和 INT1_DRDY_G。
// 软复位 reg_write(LSM6DSV_CTRL3_C, 0x01); while (reg_read(LSM6DSV_CTRL3_C) & 0x01); // 加速度计：52Hz, ±4g reg_write(LSM6DSV_CTRL1_XL, 0x2C); // 具体ODR和FS组合需查表 // 陀螺仪：52Hz, ±250dps reg_write(LSM6DSV_CTRL2_G, 0x2C); // 使能BDU和IF_INC reg_write(LSM6DSV_CTRL3_C, 0x04 | 0x08); // INT1路由：Acc数据就绪 + Gyro数据就绪 reg_write(LSM6DSV_INT1_CTRL, 0x80 | 0x40); // 中断服务函数中： void on_int1_falling_or_rising(void) { // 先读状态寄存器确认中断来源 uint8_t status = reg_read(LSM6DSV_STATUS_REG); if (status & 0x01) { reg_read(LSM6DSV_OUTX_L_A); // 读加速度计X低字节，触发后续连读 // 连续读 OUTX_H_A, OUTY_L_A ... OUTZ_H_A } if (status & 0x02) { reg_read(LSM6DSV_OUTX_L_G); // 连续读陀螺仪6字节 } }这里我特意强调“同时开两个 bit”。有些工程师图省事，只开 DRDY_XL，认为反正在一个中断回调里把 Acc 和 Gyro 都读了。问题是：DRDY_XL 每来一次只代表 Acc 的 6 个字节准备好了，Gyro 的 6 个字节可能是上上次的旧数据，也可能是读到一半被更新过的半新半旧数据。如果不挂 DRDY_G 或不用 BDU 保护，Acc 和 Gyro 的数据很难保证来自同一时刻。真要做数据同步，还得关注 CTRL9_XL 里 Acc/Gyro 数据对齐相关配置或者用 FIFO 的批处理功能，但至少先把两个 DRDY 都打开，是正确起步。
3.2 场景 B：低功耗唤醒，让 INT1 只响应 Acc 的运动事件
再来看唤醒场景。设备平时在低功耗模式，MCU 睡了，LSM6DSV 还在运行，当检测到运动超过阈值时，INT1 拉起来唤醒 MCU。这种功能如果让陀螺仪参与，功耗会立刻上去；所以 ST 的方案天然就是“用 Acc 做唤醒源”。
配置逻辑：
- 把加速度计配置成较低 ODR（例如 52Hz 或更低，功耗优先），量程根据应用选 ±2g/±4g。
- 配置 WAKE_UP_THS，设定运动阈值。
- 配置 WAKE_UP_DUR，设定去抖时间，防止误触发。
- 在 INT1_CTRL 打开 INT1_WU。
- 可选：在 MD1_CFG 里打开 INT1_MOTION，配合更精细的运动检测。
// 软复位 reg_write(LSM6DSV_CTRL3_C, 0x01); while (reg_read(LSM6DSV_CTRL3_C) & 0x01); // 加速度计：52Hz, ±4g，适合一般唤醒场景 reg_write(LSM6DSV_CTRL1_XL, 0x2C); // 唤醒阈值：4g量程下，假设1 LSB约16mg，设置约500mg reg_write(LSM6DSV_WAKE_UP_THS, 500 / 16); // 具体转换方式需看手册，这里是示意 // 去抖时间：1个采样周期 reg_write(LSM6DSV_WAKE_UP_DUR, 0x01); // 打开INT1唤醒事件 reg_write(LSM6DSV_INT1_CTRL, 0x01);这里有三个容易踩的点。第一，WAKE_UP_THS 的 LSB 权重不是随便猜的，它和量程有关，手册里有明确表格，不要拿网上旧平台的参数直接套。第二，去抖时间单位是“多少个 ODR 周期”，如果你把 ODR 改了，去抖的物理时间也跟着变。第三，唤醒检测判据是加速计模值超过阈值，静止设备放在桌面上，重力加速度 1g 会一直加在 Z 轴上，所以阈值必须大于“重力加速度 + 预期运动幅度”，否则设备放在桌上静止也频繁触发。我见过不少人把阈值设成 100mg，设备放在桌上不停唤醒 MCU，大概率就是这个原因——阈值是绝对值，不是变化量。
3.3 为什么场景 B 没法用 Gyro 替代
有人可能会问：我偏要用 Gyro 的角速度变化来唤醒，比如检测设备被转动。LSM6DSV 有没有办法把陀螺仪的角速度变化映射到 INT1？
方案层面，你可以用 FSM（有限状态机）或者 MLC（机器学习内核）对陀螺仪数据进行模式识别，然后把 FSM/MLC 输出事件路由到 INT1。这不是不行，但 FSM/MLC 本身会消耗更多功耗，而且配置复杂度比 Acc Wake-Up 高一整个量级。ST 内置的 Wake-Up 功能之所以只用加速度计，是因为加速度计功耗比陀螺仪低得多，适合作为“常开”传感器。如果主控被唤醒后需要高精度数据，可以在中断服务程序里再打开陀螺仪和更高 ODR，形成“先低功耗唤醒，再高性能运行”的分级策略。这是目前可穿戴、便携设备上被验证过且非常省电的架构。
4. 排障日志：中断不触发、误触发和标志位陷阱的三类记录
理论讲完，配置也给了，接下来进入实际调试中最磨人的部分。以下三个问题是我在这颗传感器上真实遇到过的，按排查链路复现一遍。
4.1 中断完全不触发：IF_INC 导致配置写错了位置
现象：寄存器 WHO_AM_I 能读对，Acc/Gyro 数据也能出来，但 INT1 引脚纹丝不动。用逻辑分析仪去抓，也有上拉电平，但从来没有脉冲。
排查过程：先用 I2C/SPI 回读 INT1_CTRL，发现写入的值变成了 0x00。反复写了几次都一样。然后又发现，如果写 0x80，读出来是 0x10。这不是初始化时序问题，是寄存器地址在“移动”。
最终定位到 CTRL3_C 的 IF_INC（寄存器地址自动递增）位。这颗芯片的设计是，当 IF_INC = 1 时，I2C/SPI 可以在一次事务中连续读取多个寄存器，地址会自动加 1。但我的控制代码在配置阶段，用的是单寄存器写入函数，理论上不受影响。问题出在代码别处：我初始化时先写 CTRL3_C 把 IF_INC 打开了，但后续写别的寄存器时，总线驱动误把地址自增模式带出来了，导致后续的寄存器写请求实际落在了错误地址上。INT1_CTRL 回读值偏移，就是被这种地址错位污染了。
解决办法：把配置序列改成“每写一个寄存器前都重新设置目标地址”，或者在写完 CTRL3_C 后，确认后续所有多字节操作都符合自动递增语义。简单说：如果发现中断配置写进去、回读不对，第一时间回读寄存器，别先怀疑芯片坏了。回读值偏移不是芯片故障，八成是总线层地址处理出了偏差。
4.2 唤醒事件误触发：阈值和去抖时间的配合问题
现象：设备静止放在桌上，INT1 却不定期拉高，看起来像随机误触发。用示波器抓，中断频率不高，但每几十秒一次，毫无规律。
排查过程：我一开始怀疑是电源纹波造成加速度计数据波动，于是给板子加了电容滤波，没用。又怀疑是 I2C 总线上拉干扰，调整后依然存在。最后回读 WAKE_UP_SRC 寄存器，发现中断标志位里 Z 轴阈值触发的 bit 被置位了。
这时才意识到问题关键：静止状态下，加速度计 Z 轴输出接近 1g。Wake-Up 阈值做的是“原始值比较”，不是“去除重力后的变化量比较”。如果我把阈值设得很小，比如 250mg，Z 轴数据本身的噪声、温度漂移，加上测量噪声，就足够偶尔越过阈值。而设备又没在运动，这个越线完全不是真实运动，纯粹是阈值设置太接近静态重力值了。
解决办法有两个方向。一是把阈值调大到超过“静态重力 + 实际噪声余量”，比如 500mg 甚至 1g，让静止状态稳如泰山；二是增加去抖时间（WAKE_UP_DUR），要求连续多个采样点都超阈值才触发，把瞬时噪声抖掉。实际使用中最好两者一起调：先根据应用确定最小有效运动幅度，再倒推阈值；去抖时间至少设 2~4 个 ODR 周期，能大幅降低误触发概率。
4.3 DRDY 中断只触发一次：标志位不清除
现象：中断能触发，但只触发一次，第二次开始就不来了。断电重上电又只触发一次。
排查过程：这类“只有第一次”的现象，大概率不是中断事件没发生，而是中断线电平被一直保持在有效状态，MCU 侧的中断控制器以为还是同一次中断，没有再次触发。DRDY_XL 置位后，如果不读取数据，XLDA 标志会一直保持为 1，INT1 引脚也一直保持有效电平，不会产生新边沿。
解决办法：在中断服务函数里完整读取对应传感器的数据，或至少通过读 STATUS_REG/数据寄存器把标志清掉。这颗芯片各类中断标志的清除方式不一样，我整理了一个参考表：
| 中断类型 | 标志清除方式 |
|---|---|
| DRDY_XL / DRDY_G | 读取对应传感器的数据输出寄存器 |
| Wake-Up | 读取 WAKE_UP_SRC 寄存器 |
| Free Fall | 读取 FF_SRC 寄存器 |
| Single/Double Tap | 读取 TAP_SRC 寄存器 |
| 6D 方向变化 | 读取 D6D_SRC 寄存器 |
| FIFO 相关事件 | 读取 FIFO_STATUS，必要时读取 FIFO 数据清空 |
如果中断服务函数里不清标志，隐患不只是“少几次中断”这么简单：由于 INT1 一直维持有效电平，如果 MCU 外部中断配置的是上升沿触发，后续所有事件都会被忽略；如果配置的是电平触发，会导致中断服务函数反复被调用，一直读不到新数据时还可能死循环。所以中断服务函数里第一件事，应该根据中断类型读取对应状态寄存器并确认标志位，这既是清标志，也是隔离故障的手段。
5. 如何验证 INT1 事件确实来自 Acc 或 Gyro：系统化检查方法
配置完、排完坑，最后一步是“证明给你的板子和同事看，这个中断确实来自 Acc/Gyro”。调试时全凭感觉是不行的，我用过四类方法，由易到难列一下。
5.1 方法一：逻辑分析仪观察脉冲周期
如果你配置的是 DRDY_XL/DRDY_G，可以拿逻辑分析仪夹住 INT1 引脚，把 ODR 配成 100Hz，然后数一下一秒内的脉冲个数。如果一秒钟出了 100 个脉冲，说明 Acc/Gyro 数据就绪事件确实在按预期频率产生。
这个方法对验证中断是否触发最直观。之前排查过一个案例：客户说 DRDY 频率不对，示波器抓出来每 5 秒才一个脉冲。查到最后发现是 Acc 的 ODR 被无意中改成了 0.2Hz，传感器低频跑，逻辑分析仪自然看不到高频脉冲。
5.2 方法二：状态寄存器与实际波形对照
中断服务函数里读 STATUS_REG、WAKE_UP_SRC、TAP_SRC 这些寄存器，把标志位和逻辑分析仪波形在时间轴上对齐。如果波形显示有脉冲，但 STATUS_REG 里 XLDA 和 GDA 都没有置位，说明脉冲可能来自 FIFO 或另一个功能事件，你的中断配置和服务函数对不上。反过来，波形没脉冲但状态寄存器置位了，说明中断引脚路由被芯片内部某处挂了，排查 MD1_CFG/MD2_CFG 的配置。
5.3 方法三：ST 官方工具 Unico GUI 辅助验证
ST 官方的 Unico GUI 软件支持 LSM6DSV，可以在 PC 上通过评估板读寄存器。如果手头有官方评估板，或者你的板子支持 USB 转 I2C/SPI，就可以在 Unico 的寄存器视图里实时看到 INT1_CTRL、STATUS_REG、WAKE_UP_SRC 等寄存器的变化，还能手动置位控制位。
这个工具对初学最大的帮助是：把“我改了一个寄存器的某个 bit”和“中断引脚波形变化”直接对应起来，减少了代码里反复烧写的调试时间。我把寄存器配置写进代码前，通常先在 Unico 手工点一遍，确认行为符合预期再固化到驱动里。
5.4 方法四：隔离变量法，确认某一路中断的来源
假如中断服务函数收到了中断，但不确定到底是 Acc 数据就绪还是 Gyro 数据就绪产生的，可以先把 INT1_CTRL 里所有位清零，只开 INT1_DRDY_XL，跑一段，再只开 INT1_DRDY_G，跑一段，对比触发情况。如果两次都能独立触发，说明两条路径都正常。如果只开某一项时反而完全不触发，那问题就缩小到对应传感器的配置链路上——比如陀螺仪 ODR 没设置，DRDY_G 永远不会触发。
这也是为什么我建议在中断里加一个“来源登记”：每次进入 ISR，把读到的状态寄存器和当前时戳记录到环形缓冲区。调试结束后查看这些记录，能直接看到中断来源组成，比看逻辑分析仪盲猜靠谱得多。
以下是一个快速排查清单，适合现场用：
| 现象 | 可能原因 | 检查项 |
|---|---|---|
| INT1 完全无脉冲 | 路由位没开、ODR 没配、引脚复用冲突 | 回读 INT1_CTRL 确认 bit、确认 Acc/Gyro ODR 非 0、检查 MCU 侧 GPIO 配置 |
| 脉冲频率过低/过高 | ODR 设置与预期不符 | 读 CTRL1_XL/CTRL2_G 的 ODR 位，与实际波形对照 |
| 静止时频繁误触发 | 唤醒阈值太低、去抖时间不够 | 调大 WAKE_UP_THS，增加 WAKE_UP_DUR |
| 只在第一次触发 | 标志位未清除 | ISR 里读取对应数据的输出寄存器或 SRC 寄存器 |
| 回读配置值与写入值不一致 | IF_INC 地址自增导致总线错位 | 断开自动递增，或每步设置绝对地址，重读确认 |
最后说点个人的体会
这颗 LSM6DSV 本身不算复杂，真正让“INT1 Source 是 Acc 还是 Gyro”变成问题的，是我们习惯用“传感器轴”的直觉去理解一套“事件路由”系统。Acc 和 Gyro 是数据源，事件路由寄存器是开关矩阵，INT1/INT2 是出口。先认清这层映射关系，再回头看寄存器表和代码，很多迷惑当场就能解开。
如果让我给一个建议：拿到新料号后，不要急着抄老平台的初始化代码。先把数据手册里中断路由相关的寄存器表从头到尾翻一遍，把每个 bit 和它关联的数据源标记出来，哪怕先写一份注释型路由表。这个准备工作看起来花时间，实测能省下至少一个下午的调试时间。毕竟，中断不触发的时候，你根本不知道是源没产生信号，还是路由没配通，还是引脚配置把信号吞了——提前建立好映射关系，能让你在三条可能路径里快速锁定问题所在。
