4. OSEK OS中断处理：中断分类、嵌套规则与ISR实现

中断处理，说白了就是操作系统的“应急响应机制”。

我做了这么多年嵌入式，见过太多因为中断没处理好导致的系统崩溃。有的跑着跑着就死机了，有的中断响应慢得像蜗牛。其实很多问题，根源都在于对OSEK中断机制的理解不够深。

今天咱们就聊聊OSEK OS里的中断处理。我个人习惯把中断比作“VIP通道”——它比普通任务优先级高，能随时打断正在执行的任务。但VIP也得守规矩，不然整个系统就乱套了。

4.1 中断分类：1类中断与2类中断

OSEK把中断分成了两类。这个分类很关键，它决定了你的ISR能不能调用系统服务。

特性	1类中断（Category 1）	2类中断（Category 2）
系统服务调用	不允许	允许
中断嵌套	不支持（通常）	支持
典型用途	简单硬件响应、时间戳捕获	需要触发任务、释放信号量等
实现复杂度	低	高

1类中断：这是最“纯粹”的中断。它只做最少的硬件处理，比如清中断标志、读个寄存器。为什么不能调系统服务？因为OSEK内核在1类中断里不保存上下文，你调了也没用。我在项目中遇到过有人非要在1类中断里调SetEvent，结果系统直接跑飞了。

2类中断：这才是“正经”的OSEK中断。它允许你调用大部分系统服务，比如ActivateTask、SetEvent、ReleaseResource等。内核会为2类中断保存和恢复上下文，所以你可以放心使用。

4.2 中断嵌套规则

中断嵌套，就是高优先级中断打断低优先级中断。听起来简单，但规则很严格。

OSEK的中断嵌套遵循以下规则：

• 优先级决定一切：只有更高优先级的中断才能嵌套当前中断。
• 同优先级不能嵌套：相同优先级的中断必须排队执行。
• 嵌套深度有限制：通常硬件和OS会限制最大嵌套层数（比如8层）。
• 2类中断可以嵌套1类中断：但反过来不行——1类中断里不能调系统服务，自然也无法处理嵌套。

为什么会这样？因为每次嵌套都要保存和恢复上下文，这需要时间。如果嵌套太深，栈空间也可能溢出。我建议你：嵌套深度控制在2-3层以内，除非你有充分的理由。

4.3 中断服务程序（ISR）的实现

写ISR，其实有套路。我总结了一个“三步法”：

1. 入口处理：保存必要寄存器，清中断标志。
2. 核心逻辑：处理中断事件，调用系统服务（仅限2类）。
3. 出口处理：恢复寄存器，返回。

下面是一个2类中断的典型实现：

// 2类中断ISR示例
ISR(TimerISR) {
    // 1. 清中断标志（硬件相关）
    Timer_ClearInterruptFlag();

    // 2. 读取定时器值
    uint32_t currentValue = Timer_GetValue();

    // 3. 调用系统服务：激活任务
    ActivateTask(TimerTask);

    // 4. 如果需要，可以设置事件
    SetEvent(TimerTask, TIMER_EVENT);
}

注意看，这个ISR里调用了ActivateTask和SetEvent。这是2类中断的典型用法——它不直接处理复杂逻辑，而是把工作交给任务去完成。

1类中断就简单多了：

// 1类中断ISR示例
ISR(SimpleISR) {
    // 只做硬件级处理
    GPIO_ClearInterruptFlag();
    // 不能调用任何系统服务！
}

4.4 实现注意事项

嗯，这里要注意几个关键点：

• 栈空间：每个中断嵌套层都需要额外的栈空间。我建议你预留足够的栈，至少能支持最大嵌套深度。
• 资源访问：如果ISR和任务共享资源，必须用GetResource/ReleaseResource保护。别用关中断——那会影响实时性。
• 中断延迟：2类中断的延迟比1类大，因为要保存上下文。如果你对延迟敏感，优先用1类。
• 不要阻塞：ISR里绝对不能调用WaitEvent或Schedule。这些是任务才用的。

最后，送你一句话：中断是系统的“心脏”，处理不好，整个系统都会停摆。多花点时间在设计中断架构上，绝对值得。