中断模型（Interrupt Model）

概述

中断模型是实时操作系统（RTOS）中用于处理异步事件的核心机制，它定义了系统如何接收外部事件，并在不破坏实时性的前提下完成响应与恢复。

在 HRTOS 中，外部事件可能来自定时器、串口、GPIO 等硬件设备。当事件发生时，中断控制器负责将中断请求发送到 CPU，并根据预设优先级进行仲裁。系统随后跳转到对应的中断服务程序（ISR），在最短时间内处理事件。

中断模型的设计目标包括：

• 保证关键事件可以及时响应，最大限度降低中断延迟。
• 维持系统整体确定性，防止高优先级任务被长时间阻塞。
• 支持中断嵌套与优先级抢占，以提高系统响应灵活性。
• 与任务调度机制无缝配合，确保任务恢复或切换的顺畅。

理解中断模型是掌握 HRTOS 架构的第一步，它不仅影响系统的实时性能，也关系到任务调度、资源管理和系统稳定性。

更完整地看，中断模型可以分成四层：中断源负责产生事件，中断控制器负责仲裁与屏蔽，ISR 负责最短路径处理，调度器负责把处理结果扩散到线程世界。四层责任清楚时，异步事件才不会在系统中演化为无序抢占。

中断模型真正描述的，其实是“外部世界如何被允许进入系统”。不是所有事件都应该直接获得打断当前任务的资格，也不是所有中断都应该在 ISR 中完成完整业务处理。模型的意义在于明确哪些事件只需要被记录，哪些事件必须立即抢占，哪些事件应在内核尾部再决定是否把控制权交给更高优先级线程。

• 中断源层负责表达外部扰动，但不直接决定系统恢复路径。
• 控制器层负责排序和屏蔽，避免多个异步入口无序竞争。
• ISR 层负责最小必要处理，调度器层负责把结果折叠为线程执行权变化。

工作原理

在 HRTOS 中，中断工作流程主要包括事件检测、中断请求、优先级仲裁、ISR 执行和任务恢复。具体步骤如下：

1. 事件产生：外部硬件（如定时器、串口或 GPIO）产生中断信号。
2. 中断请求：中断信号送入 CPU 或中断控制器，触发硬件中断逻辑。
3. 优先级仲裁：中断控制器根据预设的优先级判断哪个中断先被处理，高优先级事件可抢占低优先级 ISR。
4. ISR 执行：CPU 根据中断向量跳转至对应 ISR，保存上下文并开始处理中断逻辑。
5. 任务恢复/切换：ISR 执行完成后，CPU 根据调度器判断是否需要恢复被打断任务或切换到高优先级任务。

通过这一机制，HRTOS 能保证系统在处理异步事件时的实时性和稳定性。中断的快速响应和正确的任务切换对于系统性能至关重要。

如果用状态机描述，中断对象至少会经历 pending、accepted、servicing 和 post-schedule 四个阶段。每个阶段都对应不同的可见状态和可执行操作，例如 pending 阶段可以被更高优先级覆盖，servicing 阶段则应严格限制阻塞和共享资源访问。

工作原理页还应该回答一个关键边界：哪些事情绝不能在 servicing 阶段发生。典型禁区包括无界等待、复杂锁竞争、动态内存分配和长路径日志输出。因为一旦这些行为进入 ISR，整个中断模型就会把本来短小可控的异步入口，变成可以把线程世界全部拖慢的抖动源。

• pending 阶段强调可仲裁性，重点是优先级和屏蔽规则。
• servicing 阶段强调最短路径，重点是快速确认和最小状态记录。
• post-schedule 阶段强调收敛，重点是是否需要把结果交给线程继续处理。

关键接口 / 结构

以上是 HRTOS 中断模型的核心结构，每一部分都可以独立配置或扩展。更多细节请参阅 中断架构概览、 中断流程 与 中断延迟分析。

在底层实现上，这些结构通常还会对应向量表、挂起位、屏蔽寄存器和优先级字段等硬件对象。RTOS 文档把它们抽象为统一接口，是为了让开发者关注控制关系而不是芯片差异，但真正的时序行为仍然取决于这些底层对象的组合方式。

因此，关键接口不仅是 API 名称，更是责任分配边界。Interrupt Controller 不应该承担线程语义，Scheduler Trigger 不应该反向操控硬件优先级，Task Resume 也不应该在对象状态未闭合前过早运行。接口越清楚，越能避免“跨层偷改状态”这种最难定位的中断类故障。

• 向量表负责把事件映射到确定入口，保证每类中断都有唯一服务路径。
• 屏蔽寄存器负责建立可控窗口，而不是长期压制高优先级事件。
• 调度触发接口负责把 ISR 结果转换为统一的线程调度语义。

运行流程

上述流程展示了 HRTOS 中断从事件产生到 ISR 执行再到任务恢复的完整路径。

值得注意的是，中断模型中的“任务恢复”并不总是恢复原任务。只要 ISR 解除阻塞了更高优先级任务，运行权就会在中断尾部重新分配，因此中断模型本质上同时定义了事件处理路径和一次潜在的调度切换路径。

这也是为什么中断运行流程需要和调度模型一起观察。仅仅看到 ISR 很短，并不能证明系统响应就一定优秀；如果 ISR 在退出时唤醒了一条很长的线程处理链，真正的端到端效果仍可能偏离预期。中断流程分析必须把“入口耗时”和“尾部扩散路径”一起纳入。

• 硬件入口决定事件能否及时被捕获。
• ISR 决定事件能否在最短路径上被确认并整理。
• 调度恢复决定事件影响能否及时传导到真正需要运行的任务。

扩展说明

HRTOS 支持多种高级中断机制，用于提升系统对复杂场景的响应能力：

• 中断嵌套：允许高优先级中断打断正在执行的低优先级 ISR，从而确保紧急事件能够立即响应。
• 优先级抢占：系统可根据任务和中断优先级动态调整 CPU 控制权，保证高优先级任务优先执行。
• 软中断：通过软件触发中断，可以在内核中灵活调度异步事件，而不依赖硬件中断信号。
• 延迟处理机制：对于非紧急中断或耗时操作，可以延迟处理，避免阻塞关键任务执行。

这些扩展功能让 HRTOS 在复杂的实时场景中既能保证快速响应，又能维持系统整体稳定性和确定性。

在复杂 SoC 中，硬中断、软中断和任务通知往往会被组合使用：硬中断负责抢占式入口，软中断负责聚合批量事件，任务通知负责完成耗时处理。这样的多层模型可以同时兼顾响应速度、系统吞吐和可预测性。

扩展机制的设计思想，其实都是在寻找“入口速度”和“处理深度”之间的最优切分点。过多工作留在硬中断中会损害确定性，过度延迟又会增加线程恢复链长度。成熟系统通常会把最硬的时序动作保留在 ISR，把重负载或可合并处理的动作迁到软中断或线程上下文。

• 高频事件应优先考虑聚合，避免重复创建过多调度点。
• 低价值噪声事件应优先考虑屏蔽或批处理，避免侵蚀关键预算。
• 关键控制事件应优先保留短、直、可重复的硬中断路径。

从系统设计思想上看，中断模型的成功标准不是“支持多少中断特性”，而是“能否把异步性控制在系统可证明的边界内”。一套功能丰富但入口语义混乱的中断体系，往往不如一套入口极少、责任极清、恢复统一的模型更适合硬实时产品。真正可维护的模型，必须让任何一次中断都能迅速回答三个问题：它为何出现、它在哪里结束、它是否应该立即影响线程世界。

这也是中断模型文档需要长期保守的原因。每增加一种新的延迟处理机制、批处理策略或软中断桥接方式，都应先确认它不会引入第二套恢复语义。只要系统开始存在多套“中断之后怎么办”的答案，调试和验证成本就会成倍上升。

• 模型越统一，实机现象越容易回映到文档中的固定阶段。
• 恢复语义只能有一套主规则，扩展机制应围绕主规则服务。
• 异步性必须被限制在可证明边界内，而不是任其自由扩散。

换句话说，中断模型不是为了让系统“更会打断”，而是为了让系统在必须被打断时，仍然保持一套可以持续解释、持续验证、持续维护的执行秩序。

模型越统一，异步事件就越不容易在系统内部演化成难以追踪的隐性复杂度。