概述
中断是实时操作系统响应异步事件的核心机制，允许 CPU 在任意时刻打断当前任务执行，并转向执行中断服务程序（ISR）。常见中断来源包括定时器、串口、GPIO、DMA 以及硬件异常。
HRTOS 中断体系支持优先级嵌套、中断屏蔽与延迟最小化设计，确保高实时性和系统可预测性。通过合理设计 ISR 与调度器的交互，系统能够快速响应外部事件，同时维持任务执行的确定性。
开发者可参考 内核结构 了解中断与调度器的协作，或通过 系统中断流模型 可视化中断执行流程。
在严格实时系统里，中断流程更像一条受限管线而不是自由跳转。CPU 只能在规定的入口点保存现场，只能在约束内执行 ISR，只能在中断尾部把结果交还给调度器，这种受限性正是确定性来源。
把中断流程理解为“受限管线”非常重要，因为它直接决定优化方向。开发者不应试图让 ISR 处理更多功能，而应努力让每一级管线都更短、更清楚、更容易测量。只有这样，中断入口的随机性才能被逐层收敛成可接受的确定性时序。
- 入口段关注事件捕获和现场保存是否稳定。
- 服务段关注 ISR 是否只保留最小必要逻辑。
- 退出段关注调度器是否能快速把结果扩散到正确任务。
工作原理
中断是实时操作系统（RTOS）中响应异步事件的核心机制。其基本原理是：当外部或内部事件触发中断信号时，CPU 会暂停当前任务的执行，保存当前上下文（寄存器、程序计数器等），并跳转至对应的 中断服务程序（ISR） 进行处理。ISR 执行完毕后，系统根据中断优先级和调度策略恢复原任务或切换到高优先级任务。
中断分类与触发
中断通常分为 外部中断（如 GPIO 输入、外设事件）和 内部中断（如定时器、软件异常）。RTOS 会根据中断号将其映射到相应的 ISR，并维护中断向量表。
上下文保存与恢复
在 ISR 执行之前，CPU 需要保存当前任务的上下文，包括通用寄存器、程序计数器、状态寄存器等，以确保中断处理完成后能够准确恢复任务执行。上下文保存通常由硬件自动完成，也可以通过 RTOS 内核扩展实现更高效率。
中断嵌套与优先级
高级 RTOS 支持 中断嵌套 和 优先级管理：低优先级 ISR 在执行时可以被高优先级 ISR 打断，从而保证关键事件的实时响应。嵌套深度需控制在安全范围内，以防栈溢出或系统不可预测。
中断屏蔽与延迟处理
为了保护临界区和保证数据一致性，RTOS 提供 中断屏蔽（禁止部分或全部中断）机制。同时，对于不需要立即处理的事件，可以使用 延迟处理（Deferred / Bottom Half）策略，将耗时操作推迟到任务上下文中执行，减小 ISR 执行时间，提高系统可预测性。
与调度器的关系
中断执行结束后，ISR 会调用 内核调度器 检查是否有高优先级任务就绪。如果有，则发生任务切换；否则继续执行原任务。这种机制确保实时任务能够快速响应外部事件。
工程实现里经常把 ISR 拆成上半部和下半部：上半部负责快速确认硬件状态并记录最小必要信息，下半部由任务上下文继续完成解析、搬运或协议处理。这样可以把真正不可延迟的部分锁在 ISR 内，把可等待的负载迁出关键路径。
这种拆分不是单纯的软件风格偏好，而是一种时间控制策略。上半部负责保证入口可预测，下半部负责承接复杂语义和较大数据量。若两者界限不清，系统往往会表现为平均响应还不错，但在压力测试下出现极少量却很致命的长尾中断。
- 上半部应该只做确认、清标志、记录最小状态和必要唤醒。
- 下半部适合承接协议解析、批量搬运、日志记录和统计汇总。
- 拆分边界必须可复用，否则同类驱动会在不同实现中形成不同时间语义。
关键接口 / 结构
这些接口的意义不只是“能调用什么”，更在于“应该在哪个阶段调用什么”。例如 os_interrupt_disable() 只适合保护极短的关键窗口，os_isr_register() 更强调优先级与入口职责的匹配，而 os_isr_exit() 则是 ISR 世界向调度世界交接控制权的关键边界。
- 接口必须保持轻量，避免在中断上下文中引入额外复杂度。
- 注册阶段应明确每个 ISR 的优先级意义和后续唤醒责任。
- 退出阶段应优先保证状态闭合，再决定是否触发重调度。
运行流程
中断触发 → 保存CPU上下文 → 执行ISR → 可选嵌套中断处理 → ISR退出 → 调度器检查 → 恢复任务或切换任务
若从观测点布置的角度理解，这条流程通常至少需要在中断请求到达、ISR 入口、ISR 退出、调度判定和目标任务开始执行五个位置打点。只有把这些时刻串起来，开发者才能区分问题究竟来自硬件响应、ISR 负载还是调度恢复。
对流程的进一步拆解还能帮助团队建立端到端预算。很多项目表面上已经测量了“中断延迟”，但实际只测了从 IRQ 到 ISR 入口的片段，忽略了 ISR 退出后的调度恢复时间。对控制任务而言，真正重要的是事件何时影响到目标线程，而不仅仅是 CPU 何时跳进了中断向量。
- 硬件响应时间负责定义最早可能开始处理的时刻。
- ISR 处理时间负责定义事件整理和确认的时长。
- 调度恢复时间负责定义事件真正到达业务任务的最终时刻。
扩展说明
高级中断系统通常提供更多功能，以提高实时性和系统可预测性，包括：
- 优先级嵌套：允许高优先级中断打断低优先级中断，保证关键任务优先响应。详细模型请参考 中断模型 页面。
- 中断屏蔽与屏蔽寄存器：支持在关键代码段暂时屏蔽某些中断，防止被打断造成数据不一致。
- 延迟处理：对于低优先级或非关键任务中断，可延迟执行 ISR，以降低系统开销并优化响应时间。
- 中断向量管理：通过中断向量表快速定位对应 ISR，支持动态注册与卸载，提高系统灵活性。
- 嵌套中断限制：在 HRTOS 中可以配置最大嵌套层级，防止 ISR 过度嵌套导致栈溢出或延迟不可控。
这些扩展机制与 系统中断流模型、中断延迟分析 等页面紧密相关，帮助开发者全面理解中断在 HRTOS 内核中的行为。
典型案例是 UART + DMA 接收链路：中断上半部只确认 DMA 半满或满缓冲状态，并设置事件唤醒解析任务；真正的帧组包、校验和上报在任务中完成。这样的分工既保留了快速响应，又避免串口中断把系统长期困在 ISR 上下文中。
扩展说明页还应关注边界场景，例如嵌套中断深度过高、多个外设突发同时到达、DMA 完成与错误中断交错发生等。真正成熟的中断流程设计，不仅能处理理想路径，还能在这些复杂组合下继续保持固定的恢复语义，不让系统进入“偶发正确”的不稳定状态。
- 高频外设应优先考虑与 DMA、事件通知配合，减轻 ISR 重负载。
- 异常中断路径也必须回到统一的退出和调度判定逻辑。
- 嵌套深度、共享栈和恢复路径应在设计期就完成预算与上界估算。
若把中断流程放到系统联调场景里看，它还是一条天然的责任分界线。驱动团队负责保证入口可靠、清标志正确、上半部足够短；内核团队负责保证退出路径统一、调度恢复稳定；应用团队则负责保证被唤醒任务不会把本应在 ISR 外完成的逻辑重新拖回关键链路。只有三方都沿着同一条流程工作，中断系统才不会在交付后逐步变形。
流程页最后还应该提醒一个现实问题：许多“偶发中断问题”其实不是偶发，而是缺少长期观测。只要持续记录中断入口到任务恢复的全链路数据，很多看似随机的长尾样本都会暴露出清晰模式，比如总线繁忙、批量唤醒或同级中断聚集。把流程写清楚，就是为了让这些模式能够被稳定复现和解释。
- 中断流程既是执行链，也是团队之间的接口合同。
- 长期观测比单次成功更重要，因为长尾样本最能暴露真实边界。
- 只有把 ISR 外恢复链一并纳入流程，系统响应分析才算完整。
因此，中断流程页最终要建立的是一种共识：任何异步事件都不应只在“能处理”层面被接受，更要在“能稳定处理、能稳定恢复、能稳定解释”层面被系统吸收。
只有这样，中断才是实时能力的来源，而不是确定性被不断侵蚀的入口。