4. 软件层面优化：临界区保护、ISR设计原则与优先级分组策略
中断延迟优化，硬件是基础，软件才是大头。很多工程师把精力花在选更快的CPU上，结果发现延迟还是降不下来——问题往往出在软件写法上。
这一章，我们聊聊软件层面最关键的三个点：临界区怎么保护、ISR怎么写才快、优先级怎么分组才合理。我自己的经验是，把这三点吃透了，中断延迟至少能砍掉30%-50%。
4.1 临界区保护：别让共享数据坑了你
临界区，说白了就是一段不能被打断的代码。通常是操作共享数据的地方。比如一个全局变量，主循环在写，中断在读——不保护的话，读到一半数据被改了，那就全乱套了。
4.1.1 临界区的典型场景
- 读写全局标志位：比如一个
g_irq_flag，主循环检查它，中断设置它。 - 操作共享缓冲区：比如环形队列的读写指针。
- 访问外设寄存器：某些外设寄存器不支持原子操作。
- 多级中断嵌套：高优先级中断和低优先级中断访问同一块内存。
4.1.2 临界区保护方法对比
| 方法 | 原理 | 延迟影响 | 适用场景 |
|---|---|---|---|
| 全局关中断 | 进入临界区前关总中断，退出时恢复 | 高（所有中断都被屏蔽） | 极短临界区（< 1μs） |
| 按优先级关中断 | 只关闭比当前任务优先级高的中断 | 中（部分中断仍可响应） | 中等长度临界区 |
| 自旋锁/信号量 | 通过原子操作加锁，忙等待 | 低（仅阻塞冲突任务） | 多核系统或RTOS环境 |
| 无锁编程 | 使用原子指令（如LDREX/STREX） | 极低（无阻塞） | 高性能场景，但实现复杂 |
我曾经踩过的坑： 在一个电机控制项目里，我用全局关中断保护了一个临界区，结果关中断时间太长（大概5μs），导致另一个高优先级中断丢失了脉冲计数。后来改成按优先级关中断，问题就解决了。记住：关中断时间越短越好，能按优先级关就别全局关。
4.1.3 临界区保护的最佳实践
- 临界区要短：只保护真正需要保护的那几行代码，别把无关操作包进去。
- 嵌套要小心：如果临界区里又调用了另一个临界区，一定要处理好嵌套深度。我习惯用一个计数器来跟踪嵌套层数。
- 避免在临界区里调用函数：你不知道那个函数会不会又去关中断，或者有很长的执行路径。
- 用宏封装：把进入/退出临界区的操作封装成宏，方便统一管理。
/* 临界区保护宏示例（Cortex-M系列） */
#define ENTER_CRITICAL() do { \
uint32_t __primask = __get_PRIMASK(); \
__disable_irq(); \
/* 保存中断状态，用于恢复 */ \
(void)__primask; \
} while(0)
#define EXIT_CRITICAL() do { \
__set_PRIMASK(__primask); \
} while(0)
/* 使用示例 */
void update_shared_data(void) {
ENTER_CRITICAL();
g_shared_counter++;
g_shared_flag = 1;
EXIT_CRITICAL();
}4.2 ISR设计原则：快进快出，别拖泥带水
ISR（中断服务程序）的设计原则，我总结成四个字：快进快出。中断来了，赶紧处理完核心事情，然后退出。别在ISR里干太多活。
4.2.1 ISR里该做什么，不该做什么
| 该做的（ISR内） | 不该做的（ISR内） |
|---|---|
| 清除中断标志位 | 调用printf、malloc等非重入函数 |
| 读取/写入硬件寄存器 | 执行复杂的浮点运算 |
| 设置事件标志或信号量 | 等待信号量或互斥锁 |
| 将数据放入轻量级队列 | 进行文件I/O操作 |
| 更新全局状态（原子操作） | 执行长循环或递归调用 |
我的习惯： ISR里只做三件事——清标志、读数据、发信号。剩下的处理全部放到任务级（主循环或RTOS任务）去做。这样ISR的执行时间可以控制在1-2μs以内。
4.2.2 中断延迟的分解与优化
中断延迟 = 硬件延迟 + 软件延迟。硬件延迟由CPU决定，我们改不了。但软件延迟是可以优化的。
- 中断响应时间：从硬件触发到ISR第一条指令执行。这部分受中断优先级和当前是否在临界区影响。
- 中断处理时间：ISR本身的执行时间。这部分是我们优化的重点。
- 中断恢复时间：ISR退出后，恢复现场的时间。这部分通常由编译器优化，我们干预不多。
4.2.3 ISR优化实战技巧
- 使用纯汇编或内联汇编：对于时间要求极苛刻的ISR，可以考虑用汇编手写。不过我个人不推荐，除非你真的很熟悉CPU架构。
- 避免函数调用：ISR里尽量不调用函数，尤其是那些有复杂栈操作的函数。
- 数据对齐：确保ISR访问的数据是自然对齐的，避免CPU做额外的对齐处理。
- 使用快速中断（FIQ）：如果CPU支持FIQ，把最紧急的中断挂到FIQ上。FIQ有自己的寄存器组，省去了压栈开销。
/* 一个高效的ISR示例（Cortex-M3） */
void TIM2_IRQHandler(void) {
/* 1. 清除中断标志（必须第一步做） */
TIM2->SR = ~TIM_SR_UIF;
/* 2. 读取硬件数据 */
uint32_t captured = TIM2->CCR1;
/* 3. 通过信号量通知任务处理 */
osSemaphoreRelease(g_sem_capture);
/* 4. 更新全局状态（原子操作） */
__atomic_store_n(&g_last_capture, captured, __ATOMIC_RELEASE);
/* ISR结束，总耗时约0.8μs（72MHz） */
}4.3 中断优先级分组策略：别让优先级变成灾难
中断优先级分组，很多人觉得随便分分就行。其实不然。分组分不好，轻则延迟抖动，重则死锁。
4.3.1 优先级分组的核心原则
- 时间关键型中断最高优先级：比如电机控制的PWM中断、通信协议的帧同步中断。
- 数据吞吐型中断中等优先级：比如UART、SPI、I2C的数据接收中断。
- 非关键型中断最低优先级：比如按键扫描、LED闪烁、看门狗喂狗。
4.3.2 常见的优先级分组策略
| 策略 | 分组方式 | 优点 | 缺点 |
|---|---|---|---|
| 固定优先级 | 每个中断一个固定优先级，不嵌套 | 简单、可预测 | 低优先级中断延迟可能很大 |
| 分组嵌套 | 按功能分组，组内可嵌套 | 灵活性好，延迟可控 | 配置复杂，容易出错 |
| 动态优先级 | 运行时根据负载调整优先级 | 适应性强 | 实现复杂，有额外开销 |
我建议： 对于大多数嵌入式系统，使用分组嵌套策略就够了。把中断分成3-4个组，每组内部再细分优先级。这样既保证了关键中断的实时性，又不会让低优先级中断饿死。
4.3.3 优先级分组避坑指南
- 避免优先级反转：高优先级中断等待低优先级中断释放资源，这是最典型的坑。我曾经在一个项目中遇到过，一个高优先级的中断等一个信号量，而那个信号量在低优先级中断里释放，结果高优先级中断被阻塞了整整200μs。
- 避免中断嵌套过深：嵌套超过3层，栈空间和延迟都会失控。我一般限制嵌套不超过2层。
- 注意优先级分组与RTOS的配合：如果用了RTOS，中断优先级分组要和RTOS的任务优先级协调好。通常RTOS的Tick中断优先级要高于普通任务，但低于关键硬件中断。
4.4 知识结构总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个检查清单，做项目时对照着看。
4.5 本章小结
软件层面的优化，说白了就是管好两件事：临界区别太长，ISR别太胖。优先级分组则是给这两件事搭好框架。
我个人做项目时，会先画一张类似上面的结构图，把每个中断的优先级、临界区位置、ISR执行时间都标出来。然后对着图优化，哪里长了砍哪里。这个方法很笨，但很有效。
嗯，这一章的内容就到这里。记住：中断延迟优化没有银弹，只有把每个细节都做到位，系统才能跑得又快又稳。