第4章中断服务程序设计

4、中断服务程序设计：ISR设计原则、临界区保护、中断上下文切换、中断延迟分析

各位同学，咱们今天聊聊中断服务程序的设计。这玩意儿，说难不难，说简单也不简单。我见过太多工程师，写应用代码一把好手，一到ISR就翻车。嗯，今天咱们就把这些坑一个个填上。

4.1 ISR设计原则：短小精悍是王道

ISR的设计，核心就四个字：短小精悍。为什么？因为中断是异步的，它随时可能打断正在执行的任务。你想想看，如果ISR里跑了个大循环，整个系统的实时性就全毁了。

ISR黄金法则：

只做最必要的事：清除中断标志、读取数据、设置事件标志
把繁重计算扔给任务：ISR里别做浮点运算、别调printf
别在ISR里等资源：信号量、互斥锁这些，能不用就不用

我个人习惯，ISR里只做三件事：读硬件、清标志、发信号。剩下的，交给任务去处理。举个例子，串口接收中断，我就在ISR里把数据扔进环形缓冲区，然后发个信号量通知接收任务。就这么简单。

// 好的ISR设计
void UART_IRQHandler(void) {
    uint8_t data = UART->DR;          // 读数据
    ringbuf_push(&rx_buf, data);      // 入队
    osSemaphoreRelease(rx_sem);       // 通知任务
    UART->ICR |= (1 << 0);           // 清中断标志
}

// 糟糕的ISR设计
void UART_IRQHandler(void) {
    uint8_t data = UART->DR;
    process_data(data);               // 在ISR里处理数据，大忌！
    printf("Received: %c\n", data);   // 调printf，死路一条
    delay_ms(10);                     // 阻塞等待，实时性全无
}

⚠️ 我曾经见过一个项目，工程师在ISR里调了malloc()。结果呢？系统跑着跑着就挂了。为什么？malloc不是可重入的，而且它可能触发缺页中断，造成中断嵌套死锁。记住：ISR里永远别调动态内存分配！

4.2 临界区保护：别让中断搞乱你的数据

临界区，说白了就是一段不能被打断的代码。为什么需要保护？因为中断可能在任意时刻发生，如果它访问了和主程序共享的数据，那数据就乱套了。

我举个例子。你有个全局变量 counter，主程序在自增它，ISR也在自增它。你想想看，如果主程序读到counter=5，正要加1，这时候中断来了，ISR把counter加到了6。等中断返回，主程序继续执行，把6写回去。结果呢？本该是7的counter，变成了6。这就是经典的“读-改-写”问题。

临界区保护，常用的方法有：

关中断：最简单粗暴，但关中断时间不能太长
使用互斥锁：适合任务间保护，但ISR里慎用
使用原子操作：硬件级别的保护，效率最高

// 关中断保护临界区
void critical_section_enter(void) {
    __disable_irq();    // 关全局中断
}

void critical_section_exit(void) {
    __enable_irq();     // 开全局中断
}

// 使用示例
void update_counter(void) {
    critical_section_enter();
    counter++;          // 临界区，不会被中断打断
    critical_section_exit();
}

💡 小技巧：关中断的时间要控制在微秒级。我一般要求团队，关中断不超过10微秒。超过这个时间，系统的实时性就会受影响。如果你需要长时间保护，考虑用其他同步机制。

4.3 中断上下文切换：谁在背后默默干活

中断上下文切换，就是CPU从中断服务程序返回时，恢复之前被打断的任务现场。这个过程，说白了就是保存现场、执行ISR、恢复现场三步走。

为什么会这样？因为中断是异步的，CPU不知道什么时候会来中断。所以它必须把当前任务的所有寄存器都保存下来，等ISR执行完了再原样恢复。这样被打断的任务才能继续执行，就像什么都没发生过一样。

我记得有一次调试一个系统，发现中断响应越来越慢。查了半天，原来是ISR里嵌套了另一个中断，导致上下文切换次数暴增。每次切换都要压栈出栈几十个寄存器，时间全耗在这上面了。

中断上下文切换的开销，主要来自：

寄存器压栈/出栈：CPU自动完成，但次数多了也慢
栈空间消耗：每个中断都要占用栈空间，嵌套多了可能栈溢出
Cache/TLB刷新：切换可能导致缓存失效，影响性能

实际数据：以ARM Cortex-M4为例，一次完整的中断上下文切换大约需要12个CPU周期。如果系统时钟是100MHz，那就是120纳秒。看起来很快？但如果每秒有10万次中断，光切换就占了12毫秒，占CPU时间的1.2%。

4.4 中断延迟分析：你的系统能多快响应

中断延迟，就是从硬件发出中断请求，到CPU开始执行ISR第一条指令的时间。这个指标，直接决定了系统的实时性。

中断延迟由三部分组成：

组成部分	典型时间	影响因素
硬件延迟	10-50 ns	信号传播、电平转换
CPU响应延迟	50-200 ns	当前指令执行、中断优先级
软件延迟	100-500 ns	关中断时间、ISR入口处理

你想想看，如果系统正在执行一个长指令（比如除法），或者CPU关了中断，那中断就得等着。这就是为什么我前面强调，关中断时间要短。

⚠️ 我曾经在一个工业控制项目里，要求中断响应时间不超过10微秒。结果测试发现，有时候延迟会飙到50微秒。查到最后，是某个驱动在关中断后调了一个耗时的校验函数。嗯，从那以后，我要求所有关中断的代码都必须标注预期时间，超过10微秒的要特别审批。

中断延迟的优化，可以从这几个方向入手：

减少关中断时间：能用原子操作就别关中断
提高中断优先级：关键中断设高优先级，减少等待
优化ISR入口：用汇编手写ISR入口，减少不必要的寄存器保存
使用中断分组：把不紧急的中断放到低优先级组

最后，我给大家画个图，把今天讲的知识点串起来。这样你们对整个中断处理流程，心里就有数了。

好了，今天的内容就到这里。中断服务程序设计，说白了就是快进快出、保护数据、控制延迟。记住这三点，你的系统实时性就不会差。下次咱们聊聊中断嵌套和优先级配置，那又是另一番天地了。

📚 课程目录

4、中断服务程序设计：ISR设计原则、临界区保护、中断上下文切换、中断延迟分析

4.1 ISR设计原则：短小精悍是王道

4.2 临界区保护：别让中断搞乱你的数据

4.3 中断上下文切换：谁在背后默默干活

4.4 中断延迟分析：你的系统能多快响应