中断在嵌入式开发里的地位，很像武侠小说里的内功——排课表的时候它排在GPIO、UART这些模块后面，大家都觉得基础，可真到系统出了怪问题时，十有八九都跟中断沾边：中断进不去、标志位没清、优先级配错、共享变量被撕开。这个系列写到第二十三篇，我特意把这几年跟中断打交道的内容整理成一篇能直接照着用的实战笔记，把“原理—配置—链路—优先级—ISR规范—延迟实测”一条线讲透。不管你是在学单片机的小白，还是被某个诡异bug折磨的中级工程师，这篇文章都能让你少走一段弯路。
1. 轮询与中断：差的不只是效率，而是事件响应的确定性
1.1 一个按键处理的两种写法
先看一个最土的场景：检测一个按键有没有被按下。
轮询的写法是这样的：
while (1) { if (read_button() == PRESSED) { handle_button_event(); } /* 中间可能还有一堆别的任务 */ task_a(); task_b(); task_c(); }问题大家都能想到：主循环跑一圈的时间是不固定的。假如task_c()里有一段耗时的运算，耗时200ms，那这个循环跑完一圈可能就要210ms。也就是说，从按键按下到程序真正执行handle_button_event()，最坏情况下要等差不多210ms。
注意“最坏”这两个字。轮询模式下，事件响应的延迟等于“当前这圈循环的剩余时间”，它由循环里最长的那个模块决定。这就是轮询最本质的软肋：延迟没有上界。
中断的写法完全不一样。中断机制下，按键引脚的电平变化由硬件自己盯着，CPU该干吗干吗。一旦检测到指定边沿，硬件会像拍肩膀一样通知CPU：“按键事件来了，你处理一下。”CPU放下手里的事，跳进中断服务函数（ISR）跑完再回来。
void EXTI_KEY_IRQHandler(void) { g_key_event_count++; }如果再加上简单的消抖或时间戳判断，整个主循环完全不需要关心按键这件事。主程序哪怕在跑一个500ms的运算任务，按键事件依然能在微秒级被记录并响应。
1.2 “实时”不等于“快”，而是延迟有上界
很多初学者有个误解，觉得“实时系统=反应很快的系统”。实际上，实时性拼的不是“快”，而是确定性。中断给出的承诺是：只要条件满足，从事件发生到ISR开始执行的延迟会被限制在一个已知范围内，这个范围不随主程序的繁忙程度变化。
这个特性在工业控制里特别重要。比如你用一个定时器中断去驱动步进电机的脉冲输出，脉冲间隔必须精确。如果改用轮询，主循环里任何一个任务的耗时变化都会直接体现在脉冲抖动上，电机的运行轨迹就会忽快忽慢。用中断，每次定时器溢出到脉冲引脚翻转的时间差基本恒定，电机才能走出平滑的加减速曲线。
所以，选中断还是选轮询，先问自己一个问题：这个事件如果晚响应500ms，系统能不能接受？如果不能，就必须走中断；如果能，轮询往往更简单、更好调试。
1.3 哪些场景其实不该用中断
中断不是越多越好，也不是所有输入都适合中断。有几种情况我劝你还是别硬上：
- 事件频率高到接近CPU处理上限。假设有一个100kHz的信号，每个周期你都要在ISR里干点事，而一次中断从触发到返回要花掉几百个周期，那CPU基本就挂在ISR里了，主程序被饿死。这种场景应该用定时器输入捕获、硬件比较器或者DMA去处理。
- 输入本身噪声大、抖动厉害。比如机械按键或者干簧管，不做好消抖就开中断，一次按下能触发七八次中断，业务逻辑全乱套。要么加RC滤波，要么在ISR里做时间戳消抖。
- 低速周期轮询就够用。比如读取温度传感器，每秒采集一次，中断带来的收益很小，反而增加了代码复杂度。
一句话总结：中断是为“必须立刻响应、且响应延迟可控”的事件准备的，不是给所有IO口做监听用的。
2. 向量表与中断控制器：中断是怎么找到你的ISR的
2.1 向量表：一张由硬件查表的跳转登记表
中断的关键问题之一是：CPU被“拍肩膀”之后，怎么知道该跳到哪个函数去执行？答案在中断向量表（Vector Table）。
以常见的Cortex-M内核为例，芯片上电后从地址0开始放一张表：第一个字是初始栈指针，第二个字是复位向量，后面依次是各种异常和中断的入口地址。每个表项4个字节，存的就是对应中断服务函数的地址。这张表可以理解成“酒店的分机号码表”：硬件收到某个中断号，就按号码查表，跳转到对应的函数。
向量表里通常有两类条目：
- 系统异常：复位、NMI、各种Fault、SVCall、PendSV、SysTick等。
- 外部中断：由芯片厂商根据外设资源定义，比如串口接收中断、定时器更新中断、外部GPIO中断。
写ISR的时候，函数名必须和启动文件里预留的符号完全一致。大部分厂商的启动文件里都有一段弱定义处理器：
void Default_Handler(void) { while (1); /* 默认处理：死循环，方便调试时定位 */ }如果你把UART中断服务函数写成了UART_IRQ_Handler，但启动文件里叫UARTx_IRQHandler，链接器不会报错，因为函数符号对不上，向量表里依然是那个weak的默认函数。结果就是：中断明明触发了，你的代码就是不跑，卡在while(1)里。我见过太多人在这上面耗掉一下午。
2.2 NVIC与外设中断线的分工
Cortex-M内核里管中断的硬件叫NVIC（嵌套向量中断控制器），但它不是唯一的角色。拿一个GPIO外部中断举例，信号的旅程是这样的：
- GPIO模块检测到引脚电平变化，产生一个边沿事件；
- 外部中断/事件控制器（通常叫EXTI之类）把这个事件过滤、转换成一根中断线；
- 中断线把请求送进NVIC；
- NVIC根据使能位、挂起位和优先级决定什么时候打断CPU核心。
NVIC和外设中断源的职责要分清。GPIO、UART、定时器这些外设负责“产生中断请求”，NVIC负责“决定这个请求能不能插队、什么时候插队”。很多新手只知道使能外设中断，忘了在NVIC里也开一遍，结果中断永远不触发，或者触发了进不了ISR。
在NVIC层面，你至少要确认三件事：
- 这条中断是否被使能；
- 挂起位（Pending）是不是残留了旧标记；
- 优先级配置是否符合预期。
写寄存器的时候，NVIC的操作一般走“置位”而非“覆盖写”。比如使能某个IRQ，应该用类似NVIC_EnableIRQ()的接口，而不是直接对整个寄存器赋值，否则容易把别的中断线也改乱。
2.3 向量表被“带偏”的两个经典事故
向量表本身不难，难的是它被挪了地方之后没人想起要“重新登记”。
事故一：Bootloader跳App后中断失效。很多产品有Bootloader，先跑引导程序，再跳转到应用程序。App为了把Flash空间腾出来，链接地址往往放在0x08010000之类的位置。如果App里没有把向量表偏移寄存器（Cortex-M里叫VTOR）的值改成新的首地址，中断一触发，硬件还是去老地方查表，读到的要么是Bootloader的向量表，要么是一堆乱七八糟的数据，系统必挂。
/* 跳转进App后第一件事：把向量表指向App自己的地址 */ SCB->VTOR = APP_BASE_ADDR;事故二：把向量表搬到RAM。有些场景为了追求中断响应速度，或者需要动态改中断入口，会把向量表拷贝到RAM，再把VTOR指过去。搬完之后如果忘了确认VTOR的新地址和内存对齐要求（通常要求按一定字节数对齐），中断一样会跑飞。
一句话：只要代码的实际运行地址和链接地址不一样，第一件事就是检查向量表是否还找得到。
3. 一次外部中断的完整生命周期：从引脚边沿到ISR返回
3.1 配置外部中断的六步套路
不管哪家芯片，配置外部中断的套路都差不多，无非是寄存器名字不同而已。下面这六步是通用骨架：
/* 伪代码：以某Cortex-M内核单片机的EXTI配置为例，具体寄存器名看芯片手册 */ void EXTI_Key_Init(void) { /* 1. 开启GPIO与EXTI的时钟 */ enable_gpio_clock(); enable_exti_clock(); /* 2. 把引脚配成输入模式，并选好上下拉 */ gpio_set_mode(KEY_PIN, INPUT); gpio_set_pull(KEY_PIN, PULL_UP); /* 3. 把引脚映射到对应的EXTI线 */ exti_select_source(KEY_PIN); /* 4. 配置触发边沿：上升沿/下降沿/双边沿 */ exti_set_trigger(KEY_PIN, RISING_EDGE); /* 5. 使能EXTI中断 */ exti_enable_irq(KEY_PIN); /* 6. 在NVIC里使能对应IRQ，并设置优先级 */ nvic_enable_irq(EXTI_KEY_IRQn); nvic_set_priority(EXTI_KEY_IRQn, 1); }这六步的顺序是有讲究的。我习惯先配外设（GPIO、触发方式），再开EXTI中断，最后开NVIC。为什么？因为如果先把NVIC开了，中断信号源还没准备好，一个悬空的引脚抖动就可能立刻产生一个假中断，进到ISR里又发现标志位半清不清，很恶心。
引脚上下拉也值得多说一句。浮空输入开中断是大忌，引脚电平不定，中断就会像抽风一样乱触发。上拉还是下拉的选择，要结合外部电路决定，原则是：静态时引脚电平要稳定，按键按下时电平变化方向才符合你的触发边沿预期。
3.2 从触发到返回：硬件悄悄做了什么
很多人写中断服务函数，眼里只有自己的代码，完全没想过硬件在进入ISR之前已经做了大量工作。以Cortex-M内核为例，一次中断流程大致是：
- 外设把中断标志置位，把请求送进NVIC；
- NVIC仲裁：如果有多个中断同时来，根据优先级决定谁先响应；
- 处理器开始响应：硬件自动把8个关键寄存器压栈，包括PC、xPSR、LR、R0-R3、R12；
- 从向量表读取ISR地址，跳转执行；
- 编译器生成的ISR前导代码把ISR会用到的其他寄存器也保存起来；
- ISR跑完，触发异常返回指令，弹出的PC和xPSR，回到被中断前的下一条指令。
这里有两个知识点值得记住。
一个是硬件自动压栈的内容是固定的。它保证ISR里只要不破坏编译器没保存的寄存器就不会出错。如果你写汇编级ISR，私自改了R0-R3之外的东西，又不手动恢复，程序当场崩。
另一个是尾链优化。如果ISR A执行期间，另一个中断B已经挂起，传统做法是A返回后弹出上下文，再为B压栈，一来一回浪费不少周期。但Cortex-M会做尾链：A结束时不恢复现场，直接进B，省掉一次压栈出栈。这意味着在工程设计上，连续的中断事件比“来了一个打断一个”在时序上更可控。
3.3 中断标志清除：谁负责，先清还是后清
这是现场问题里最常见的翻车点。中断服务函数返回之前，必须确保产生中断的条件被解除，否则同一个中断会立刻再次触发，ISR被无限重入，主程序永远跑不出去。
但“解除条件”这件事因外设而异，没有统一答案：
| 中断类型 | 清除方式 | 常见坑 |
|---|---|---|
| 外部GPIO中断 | 写标志清除寄存器对应的位 | 忘了清，ISR连环触发 |
| UART接收中断 | 读数据寄存器即自动清除 | 先清再读，可能丢新数据 |
| 定时器更新中断 | 写标志位清除（有些要求先读再写） | 清除时序不对导致多跑一次 |
| DMA传输完成中断 | 清完成标志 | 多通道共用中断时误清其他通道 |
清标志的顺序也很有讲究。以外部中断为例，我建议的处理顺序是：先把引起中断的数据或状态读走，再清标志，最后做业务逻辑。如果你进ISR第一件事就清标志，然后慢悠悠读数据，这期间新的边沿来了又把标志置上，等你ISR返回，新的中断又紧接着进来。表面看是丢了“合并触发”，但实际上如果新事件发生在你读数据之前，你读到的还是旧数据，等于把新事件吞了。
反过来也有问题。如果最后才清标志，而事件处理过程中新的边沿已经把标志置位，你清完老标志后新标志还在，ISR返回后还会再进一次。对边缘触发的中断来说，这其实是符合预期的——两个边沿就是两次事件。关键是你要想清楚：这个中断代表的是“电平状态”还是“边沿事件”？概念搞混，清标志永远清不对。
4. 优先级分组、抢占与临界区：嵌套中断的甜头与苦头
4.1 抢占优先级和子优先级，很多人到离职都没分清
NVIC里每个中断的优先级设置通常分两部分：抢占优先级和子优先级。
- 抢占优先级决定“能不能打断别人”。抢占优先级高的中断，可以打断正在执行的抢占优先级低的中断，这就是嵌套。
- 子优先级决定“同时来了谁先跑”。当两个抢占优先级相同的中断同时挂起时，子优先级高的先执行；但子优先级不能产生嵌套，两个相同抢占优先级的中断谁也不能打断谁。
举例说明。中断A：抢占优先级1，子优先级0。中断B：抢占优先级1，子优先级1。中断C：抢占优先级0，子优先级3。
场景1：A正在执行，B到来。因为抢占优先级相同，B不能打断A，只能挂起，A跑完后B再进。
场景2：A和B同时挂起，C不在场。A先执行，因为A的子优先级比B高。这不是抢占，只是排队的规则。
场景3：B正在执行，C到来。C的抢占优先级0高于B的1，所以C直接打断B，等C返回后B继续执行。
很多人在配置两个中断时，只关注“谁的优先级数字小”，却忽略了它们是否处于同一个抢占层级。如果两个中断的抢占优先级相同，想靠子优先级实现“让A打断B”，是做不到的。
4.2 优先级分组：不配置就等于没有嵌套
优先级寄存器里那几位，到底多少给抢占优先级、多少给子优先级，由优先级分组（PRIGROUP）决定。最坑的是，很多芯片默认的分组把所有位都分给了子优先级，相当于没有抢占功能。你配置了A的优先级是1、B的优先级是2，想着B能打断A，结果因为所有中断都在同一个抢占层级，根本嵌套不了。
以Cortex-M为例，配置分组需要写系统控制块里的AIRCR寄存器：
/* 以4位有效优先级为例：高3位为抢占优先级，低1位为子优先级 */ #define SCB_AIRCR (*(volatile uint32_t *)0xE000ED0C) #define SCB_AIRCR_VECTKEY 0x5FA0000u #define SCB_AIRCR_PRIGROUP_MASK 0x700u #define PRIGROUP_3PRE_1SUB 0x400u /* 0b100 */ void SetPriorityGrouping_3Pre_1Sub(void) { uint32_t reg = SCB_AIRCR; reg &= ~SCB_AIRCR_PRIGROUP_MASK; reg |= SCB_AIRCR_VECTKEY | PRIGROUP_3PRE_1SUB; SCB_AIRCR = reg; }不同内核有效优先级位数不一样，Cortex-M0/M0+一般只有2位，M3/M4/M7通常是4位，具体看参考手册。重要的是你要形成肌肉记忆：拿到一块新板子，先确认优先级分组，再谈配置优先级，否则后面所有嵌套逻辑都是空中楼阁。
另外提醒一句，Cortex-M的优先级数值是“越小越优先”。0最高，数值越大优先级越低。有些IDE或HAL库封装之后，传入接口的形参顺序是反的，让你觉得“数值越大优先级越高”，一旦混用底层寄存器和封装接口，很容易犯迷糊。我自己的习惯是统一用裸寄存器思维控制，少依赖封装里那层“人性化”设计。
4.3 临界区保护的三个层级
中断一多，代码里总有一段不想被打断的逻辑，也就是临界区。保护手段分三个层级，按“粒度从粗到细”排：
第一层：全局关中断。
void EnterCritical(void) { __disable_irq(); /* 关掉所有可屏蔽中断 */ } void ExitCritical(void) { __enable_irq(); }这招简单粗暴，但副作用是：你关中断期间，所有中断事件全部延迟响应。如果这段临界区里有耗时的运算，系统的实时性会显著恶化。更隐蔽的问题是，如果你在一个已经处于中断上下文的地方调用__disable_irq()，退出时直接__enable_irq()，可能会把嵌套层数打乱，导致中断状态不对。所以更稳妥的写法是保存并恢复前一个状态：
void EnterCriticalSave(uint32_t *saved) { *saved = __get_PRIMASK(); __disable_irq(); } void ExitCriticalRestore(uint32_t saved) { __set_PRIMASK(saved); }第二层：按优先级阈值屏蔽。
Cortex-M3/M4/M7的寄存器里有个BASEPRI，可以设定一个阈值，屏蔽所有优先级数值大于等于这个阈值的中断，但更高优先级的中断依然能进。这在RTOS里特别实用，比如可以屏蔽所有普通中断，但保留时钟节拍中断来维持系统调度。
/* 屏蔽优先级数值>=0x50的中断，高优先级照常 */ __set_BASEPRI(0x50); /* 受影响代码 */ __set_BASEPRI(0);第三层：原子性操作拆解。
有些临界区其实根本不需要关中断，比如你要修改的只是一个32位寄存器里的某些位。如果硬件支持“写入置1”或“写入清零”的单次写操作，直接利用这种原子操作就能避开关闭中断。这年头很多外设的寄存器就是为原子操作设计的，比如GPIO的置位/复位寄存器。能用原子操作解决，就绝不要动全局中断开关。
5. ISR里该写什么不该写什么：共享数据、volatile与无锁队列
5.1 volatile不是万能药，但少了它一定出事
先跑一个小例子。主循环在等待一个标志位，这个标志位在ISR里被置位：
uint32_t g_flag = 0; int main(void) { while (g_flag == 0) { /* 等待中断 */ } /* 继续 */ } void Some_IRQHandler(void) { g_flag = 1; }不开优化的时候，程序跑着没问题。一开优化，编译器发现main的循环里没有改变g_flag的语句，就可能把g_flag塞进寄存器，然后不停比较“寄存器里的值是否等于0”，根本不会再从内存里重新读。结果就是：ISR把内存里的g_flag改成了1，主循环依然死等。
把定义改成volatile uint32_t g_flag = 0;，编译器就老实了，每次使用该变量都从内存重新加载。这是volatile在嵌入式里最重要的用法：让编译器不要对你的共享变量做激进的缓存优化。
但我要泼一盆冷水：volatile不等于原子操作，也不能代替临界区。它解决的只是“编译器优化导致的内存可见性”问题。两个地方同时对一个变量做“读-修改-写”时，volatile无能为力。比如有一个32位计数变量，ISR里做g_count++，主循环里做g_count--，这两个操作在底层都是先把值读到寄存器、加/减、再写回内存，完全可能被打断，丢了更新。这种场景，volatile救不了你，得靠原子操作或临界区。
5.2 共享变量的撕裂读与单一写者原则
主循环和ISR共享一个多字节变量，最典型的坑叫“撕裂读”。假设你的单片机是8位内核，共享变量是32位：
- 主循环正在读这个变量的高16位；
- 此时中断发生，ISR修改了这个变量的值；
- 中断返回后，主循环继续读低16位，结果读出一个“旧高半截+新低半截”的缝合怪数值。
解决方案有几个层次。
第一，能单写者就单写者。如果变量只有ISR会写、主循环只读，或者反过来，那么只要读操作本身是单次对齐访问，问题就小得多。这也是我极力推荐用“ISR只往缓冲里写，主循环只从里面读”这种模式的原因。
第二，必须多写者时上临界区。只要写操作不是原子的，访问共享数据时就用临界区保护起来。
第三，用无锁的“生产者-消费者”缓冲。这是一个非常经典的嵌入式模式，性能好，又不会关中断。
5.3 一个无锁环形缓冲区的实现与边界
下面这个环形缓冲区是我项目里的常用模板，它天然符合“单一写者vs单一读者”原则：ISR只写head，主循环只写tail，两边各自修改自己的索引，互相不竞争。
#define RING_SIZE 256 typedef struct { volatile uint8_t buf[RING_SIZE]; volatile uint16_t head; /* 写位置，ISR专用 */ volatile uint16_t tail; /* 读位置，主循环专用 */ } ring_buffer_t; ring_buffer_t g_uart_rx; /* ISR中调用：写入一字节，满则返回0 */ uint16_t RingBuf_Write(ring_buffer_t *rb, uint8_t data) { uint16_t next = (uint16_t)((rb->head + 1) % RING_SIZE); if (next == rb->tail) return 0; /* 满了 */ rb->buf[rb->head] = data; rb->head = next; return 1; } /* 主循环中调用：读出一字节，空则返回0 */ uint16_t RingBuf_Read(ring_buffer_t *rb, uint8_t *out) { if (rb->head == rb->tail) return 0; /* 空了 */ *out = rb->buf[rb->tail]; rb->tail = (uint16_t)((rb->tail + 1) % RING_SIZE); return 1; }这个方案的巧妙之处在于：ISR读tail判断有没有剩余空间，主循环读head判断有没有数据。与此同时，ISR写buf和head，主循环写buf和tail。每个字段都只有一个写者，读方只做“看一眼对方索引”的动作，这是单核单片机场景下公认安全的无锁套路。
要注意的边界条件是“满”和“空”的判断方式：这种写法牺牲一个缓冲区单元来区分满和空，否则满和空时head==tail会混淆。容量是256，实际可用就是255。如果你改成2的幂次大小，取模运算可以用位与代替，速度更快：
#define RING_SIZE_EXP 8 #define RING_SIZE (1 << RING_SIZE_EXP) #define RING_MASK (RING_SIZE - 1) /* next = (rb->head + 1) & RING_MASK; */5.4 ISR禁忌清单：我在代码里看到过的最坏写法
这些年看过不少ISR，有些实现真是让人血压升高。给你一份禁忌清单，碰到这些写法，能改就赶紧改：
- ISR里调printf。串口打印本身要时间，库函数还可能不重入，多个中断同时来的时候直接崩。
- ISR里malloc/free。动态内存的堆管理通常不是线程安全的，更不是中断安全的。
- ISR里做长延时或死等。延时期间所有同级或低优先级中断全被堵死，整个系统的实时性毁于一旦。
- ISR里做浮点运算。没有FPU或者FPU上下文切换开销大的内核，浮点运算在ISR里是重量级操作，能挪走就挪走。
- ISR里直接操作其他模块的全局状态。比如在串口ISR里直接改电机状态机，还不上锁，改到一半被另一个中断打断，状态就烂了。
- ISR里调用一些看起来无害的库函数。很多标准库函数内部有全局状态，不保证可重入。你用的时候压根不知道它背后干了什么。我当时排查最费劲的一个bug，就是ISR里调用了某库函数，函数内部用了全局缓冲区，恰好被同优先级的中断再进入，数据全错。
ISR的正确姿势永远是：尽快把数据搬到一个安全的地方（环形缓冲区、事件标志），置个标志，然后立刻返回。真正的业务处理放到主循环或者低优先级任务里做。
6. 实测中断延迟：用GPIO翻转和定时器把“感觉”变成“数值”
6.1 中断延迟到底由哪些环节构成
讨论中断性能，绕不开“中断延迟”这个词。它不是某一个具体的常数，而是从事件发生到ISR第一条指令执行之间的时间，通常包含这些环节：
- 外设检测事件、置位中断标志的时间；
- NVIC仲裁与路由时间；
- 处理器硬件自动压栈的时间；
- 从向量表取地址、跳转的时间；
- 编译器生成的ISR入口指令时间；
- 如果更高优先级的中断正在跑，等待它跑完的时间（这部分通常不是固定的）。
前五项加起来，在Cortex-M3/M4这类内核上通常十几个到几十个时钟周期。真正导致延迟抖动的，往往是第6项，也就是被高优先级ISR阻塞的时间。所以，想让某个中断延迟稳定，不只是调它自己的优先级，还要看它上面压着哪些“大爷”中断。
6.2 GPIO翻转法实测：手把手流程
测延迟最朴素也最直观的办法，是GPIO翻转配示波器。
操作步骤：
- 找一个空闲引脚，配置为推挽输出，名称记为
MEASURE_PIN； - 在该中断的ISR入口处，把
MEASURE_PIN拉高； - ISR返回之前，把
MEASURE_PIN拉低； - 用信号发生器给触发源一个稳定的边沿信号；
- 示波器同时接触发源和
MEASURE_PIN，量两个信号之间的时间差。
void Target_IRQHandler(void) { GPIO_SetPin(MEASURE_PIN); /* 入口翻转 */ /* 实际处理... */ GPIO_ClearPin(MEASURE_PIN); }如果想让测量更精细，可以用两个引脚：一个在ISR入口翻转，一个在ISR出口翻转。两个引脚互相配合，既能看响应延迟，也能粗略估算ISR执行时间。
这个方法的局限是它测量的是“从外部信号到ISR执行”的端到端延迟，包含了外部滤波、比较器延时等外围因素。如果你想测的是纯内核延迟，可以改用定时器：让定时器的输入捕获通道直接捕获同一个触发边沿，同时在ISR里读另一个定时器的实时值，两者相减，就能把外部电路的干扰剥掉，看到内核层面的延迟。
6.3 减少延迟的六个实用手段
在实测发现问题之后，下面这些手段按投入产出比排序：
- 让重要中断的抢占优先级尽可能高。但不要把所有中断都设成最高，否则谁都插不了谁，嵌套形同虚设。
- 把ISR本身写短。这是最有效、最便宜的一招。所有能在主循环里做的事，都不要放ISR。
- 关闭全局中断的代码段要短。用临界区的地方，进去前想清楚是不是真的需要关闭全部中断；能用BASEPRI，就不要关全局。
- 避免ISR里的浮点和库调用。前面已经说过，不再重复。
- 利用中断的尾链特性。某些场景下，与其在高优先级ISR里处理完再退出，不如把任务拆成分段处理，让系统自然利用尾链衔接，减少上下文切换开销。
- 考虑把ISR和向量表放到更快的存储区。比如把常用ISR放到RAM里执行，省掉Flash取指等待。这个优化对延迟敏感的项目有效，但会增加RAM占用，得自己权衡。
6.4 一版我一直在用的中断配置检查清单
文章最后，分享一个我每换一块板子、每建一个新工程都会对着走的检查清单。别嫌它琐碎，绝大多数中断相关的线上事故，回头一查都是清单里某一项没做到：
- 向量表地址是否指向当前程序所在位置（Bootloader跳App后最容易忘）；
- 外设时钟、GPIO时钟是否都已开启；
- 引脚上下拉是否配置，空闲电平是否稳定；
- 触发边沿与外部电路是否匹配；
- EXTI中断和NVIC中断是不是都开了；
- 优先级分组是否按预期配置，抢占和子优先级是否搞混；
- ISR函数名与启动文件中的向量符号是否严格一致；
- 中断标志位由谁清除、先清还是后清，是否已确认；
- 共享变量是否加volatile，是否遵循单一写者原则；
- ISR里有没有printf、malloc、长延时、浮点、非重入库函数；
- 用GPIO翻转法实测过延迟和ISR耗时，结果是否在可接受范围。
这套清单看着朴素，但照着走一遍，能省下大把在示波器面前挠头的时间。中断这东西，玩明白了是顺手的工具，玩不明白就是系统性bug的温床。我每次调试遇到“时不时卡死”“偶发丢数据”这类问题，第一反应永远是先把清单过一遍，基本都能定位到根因。
