中断流程 Interrupt Flow & Task Switching
本文说明中断处理与 HRTOS 内核运行之间的关系。 重点是区分中断入口、ISR 执行、中断退出、调度决策与任务上下文切换， 避免将它们简化为一个连续且固定的操作。
中断流程概述
中断机制使处理器能够响应异步事件。对于运行在 8051 平台上的 HRTOS， 分析中断流程时，需要同时考虑处理器的中断行为、内核对执行状态的管理， 以及中断处理与任务调度之间的联系。
中断入口不等同于完整的任务上下文切换；ISR 执行结束也不意味着 一定会切换到另一个任务。具体行为取决于中断处理路径、内核状态和调度条件。
中断处理的主要阶段
中断请求与处理器响应
外设或定时器产生中断请求后，处理器根据当前中断使能状态、 优先级规则及自身执行状态决定何时响应。
进入中断处理路径
处理器转入相应的中断入口。硬件与软件分别承担哪些状态保存工作， 取决于 8051 具体实现、编译器生成代码及 HRTOS 的中断入口设计。
执行 ISR
中断服务程序处理对应事件。ISR 中使用的寄存器、共享数据和内核接口， 都需要符合 HRTOS 的中断上下文约束。
可能发生的中断嵌套
如果当前执行状态与中断优先级规则允许更高优先级的中断被接纳， 执行路径可能进入嵌套处理。可嵌套条件和实际深度必须以实现为准。
中断退出与后续处理
ISR 按照规定的退出路径完成处理。是否需要调度、何时恢复任务上下文， 取决于内核的中断退出机制及当前系统状态。
上述阶段是用于理解机制的概念模型，不代表每次中断都必然经过完全相同的路径， 也不代表所有阶段都由同一段代码完成。
中断入口与上下文保存
上下文是程序继续执行所需的处理器状态。对 8051 系统而言， 具体涉及哪些寄存器、寄存器组和栈内容，取决于当前执行环境与中断处理实现。
硬件中断响应
不能笼统地认为硬件会自动保存完整的 C 程序或 RTOS 任务上下文。 硬件响应、中断入口代码与内核上下文管理之间的责任需要分别确认。
ISR 执行状态
ISR 可能使用寄存器、栈空间或共享变量。若中断能够嵌套， 还需要分析嵌套层次对这些资源的影响。
任务上下文切换
任务切换涉及保存当前任务的可恢复状态，并恢复目标任务的状态。 这与进入 ISR 时所需的状态处理有关联，但两者不能直接等同。
中断嵌套与优先级
中断优先级用于控制不同中断请求之间的响应关系，但需要区分 8051 硬件中断优先级和 HRTOS 内部用于描述任务或内核执行顺序的优先级概念。
嵌套中断并不是只由“数值更高”决定。处理器的中断接纳规则、 中断使能状态、当前执行路径以及 HRTOS 的入口与退出设计， 都可能影响中断能否嵌套。
- 确认目标芯片实际支持的中断优先级和响应规则。
- 确认 HRTOS 对中断入口、嵌套与退出的具体处理方式。
- 结合 ISR 的栈使用量评估嵌套带来的额外资源开销。
- 不要在缺少源码或测量依据时假定固定的嵌套层数。
中断退出与任务调度
中断处理可能改变系统状态，例如产生待处理事件或使任务具备继续运行的条件。 但“发生中断”“请求调度”和“实际切换任务”是三个不同层次的问题。
调度请求
中断处理路径可能向内核提出调度需求。提出需求本身不等于 已经完成任务选择或上下文切换。
调度决策
调度器依据当前任务状态和系统调度规则确定后续执行安排。 是否在某个中断退出点执行调度，需要以 HRTOS 实际实现为准。
任务恢复或切换
后续执行可能恢复被中断的执行环境，也可能沿着内核允许的路径 切换到其他任务。两种情况需要通过具体代码路径加以区分。
关键实现与接口核对
在 HRTOS 中，具体中断接口应以当前版本的头文件和内核实现为准。 不应仅依据通用 RTOS 的命名习惯推断某个接口存在或具有特定行为。
该接口需要结合其实际定义、调用位置及对应的汇编或 C 实现阅读。 由于中断入口和普通函数调用的执行环境可能不同， 不能仅凭函数名推断它内部完成的所有操作。
- 核对接口声明、实现位置和合法调用上下文。
- 核对 ISR 是如何进入，以及退出路径如何返回。
- 核对是否存在嵌套中断专用的执行路径。
- 核对调度请求与实际任务切换之间的关系。
os_enter_critical()、
os_exit_critical()、
os_in_isr() 或 os_interrupt_id()
列为已确认接口。使用前请先核对 HRTOS 当前版本的真实声明。
本页小结
理解 HRTOS 中断流程的关键，不是简单记住一条固定箭头链， 而是明确处理器中断响应、ISR 执行、嵌套处理、中断退出、 调度决策和任务上下文切换各自的职责。
在进一步分析响应延迟或最坏执行时间时，应将这些阶段拆分， 明确测量边界，并结合目标芯片、编译结果与 HRTOS 具体实现验证。