中断架构（Interrupt Architecture）

中断架构概览

HRTOS 的中断架构决定了系统如何处理外部异步事件，同时保证任务调度和系统确定性。通过清晰划分中断源、控制器、ISR 和调度接口，系统能够在响应外部事件的同时保持高性能和可靠性。

本模块内容涵盖三大核心主题：中断流程、延迟分析以及中断模型。每个主题独立阐述实现细节与优化方法，同时通过案例展示在实际系统中的应用。

从架构角度看，中断层是系统唯一允许异步打断当前执行链的入口，因此它既要足够快，又不能绕开内核的时序约束。一个设计良好的中断架构，会把外部世界的随机事件转换为内核可分析的有限状态转移。

这意味着中断架构不仅关心 ISR 怎么写，还要关心中断控制器分组、优先级编码、中断屏蔽策略以及 ISR 与线程上下文的责任边界。只有这些边界明确，系统才能在高负载下保持确定性。

对于多外设系统，中断架构还承担隔离噪声的职责。频繁但低价值的外设事件必须被限制在局部路径内，不能持续撕裂关键控制任务的时间预算。

设计原则

• 快速响应：中断机制必须保证高优先级事件能够尽快被 CPU 处理。
• 最小延迟：通过优化 ISR 和中断嵌套策略，减少对关键任务的阻塞。
• 可扩展性：中断架构允许用户根据外设需求增加新的中断源或自定义 ISR。
• 系统确定性：即使存在多个并发中断，调度器和任务恢复机制也能保持系统行为可预测。

在 RTOS 中，快速响应并不等于在 ISR 内做更多工作。更常见的工程做法是把中断上半部缩短为采样、清标志和投递事件三个动作，把协议解析、滤波或日志记录下沉到任务上下文执行。

此外，优先级设计必须与任务模型同时评审。高频但低价值的中断不应该挤压控制回路任务的恢复时间，关键控制中断也不应因过长的全局屏蔽窗口而失去响应上界。

架构示意

系统中断架构可以简化为以下流程：

上述流程显示了中断从事件产生到任务恢复的完整路径，每一环节都可以优化，以平衡响应速度与系统稳定性。

如果把这条链路展开，就会看到一个完整的延迟预算：中断请求仲裁、入口现场保存、ISR 执行、调度判断以及目标任务恢复。中断架构优化的目标并不是只缩短某一个点，而是让这五段时间都保持稳定且可重复。

学习建议

如果你是第一次接触 RTOS 中断机制，建议先浏览：

• 中断流程 — 理解事件到 ISR 的执行路径。
• 中断延迟 — 学习延迟来源和优化策略。
• 中断模型 — 掌握中断源、优先级和任务恢复机制。

通过阅读上述内容，你可以完整理解 HRTOS 中断架构的实现与设计理念。

建议的阅读顺序通常是先看流程，再看延迟，最后回到模型抽象。这样可以先建立“事件如何进入系统”的直觉，再理解“为什么某些路径会超时”，最后把这些现象收敛为统一的中断控制模型。

在调试现场问题时，也可以反过来使用这三页：先从延迟页定位时间消耗，再回到流程页找具体转移点，最后用模型页确认这类转移在体系内是否被正确约束。这样可以更快把“现象”追溯到“机制”。

核心主题

浏览中断机制的关键结构与运行模型。

这三个主题分别回答三个不同层面的问题：中断流程说明控制权如何转移，中断延迟解释时间预算消耗在哪里，中断模型则定义源、控制器、ISR 与调度器之间的系统关系。三者合起来，才能形成完整的 RTOS 中断认知框架。

对维护者而言，这三页还分别对应 tracing、预算和抽象三类工作成果，能够帮助团队把设计、调试和验证放到同一语境里。

相关主题

中断架构从来不是孤立存在的。只要 ISR 结束后需要唤醒任务，它就会立即与调度器、内核上下文切换以及内存访问路径形成耦合，所以阅读相关模块时应始终带着“中断之后谁接手”这个问题继续追踪执行链路。

例如一次“中断响应慢”的现象，真正原因可能出在内核临界区过长、调度器 ready queue 更新复杂或共享缓存竞争加剧。把问题只留在中断页里往往只能看到表象，跨模块追踪才能找到链路根因。