中断源
产生请求的硬件或系统事件，例如定时器溢出、串口接收、外部引脚变化等。 中断源的类型决定了事件标志、清除方式和处理时限。
中断基础：ISR、中断嵌套与实时响应
中断机制使处理器能够响应异步事件。对于 RTOS， 中断不仅影响事件处理延迟，还可能改变任务状态、触发调度决策， 并影响系统的最坏情况响应时间。
阅读本页时需要区分三个事件：中断被响应、调度器决定运行哪个任务、处理器实际切换到另一个任务。这三个事件有关联，但并不等同。
一、中断的本质
中断是一种改变处理器执行路径的事件响应机制。
当外设、定时器或其他受支持的事件产生中断请求时， 处理器会依据当前中断使能状态、优先级规则和架构定义的响应条件， 决定是否以及何时进入相应的中断处理路径。
中断服务程序（ISR，Interrupt Service Routine） 通常负责确认事件、读取或写入硬件状态、记录必要信息， 并在需要时通知任务或更新内核状态。
中断机制与轮询是不同的事件处理方式。中断可以避免处理器持续检查某些事件， 但中断也有入口、现场保护、处理与返回开销；选择哪种方式需要结合事件频率、 时限要求和硬件能力。
二、中断在 RTOS 执行链中的位置
事件可能改变任务状态，但是否发生任务切换取决于后续决策。
01 · 事件
外设或定时器产生请求
02 · 中断入口
处理器进入中断处理路径
03 · ISR 处理
确认事件、更新状态
04 · 调度判断
根据内核策略决定后续执行
05 · 继续运行
返回原任务或切换到目标任务
这是通用的概念模型，不代表所有 RTOS 都使用相同的中断退出流程或调度入口。具体行为取决于处理器架构和内核实现。
三、中断的典型执行流程
硬件入口、软件处理与中断返回需要分别理解。
1. 外设或内部事件产生中断请求
2. 处理器根据使能状态和优先级规则判断是否响应
3. 处理器执行架构规定的中断入口操作
4. 必要的执行现场得到保护
5. 跳转到相应的 ISR
6. ISR 处理事件并确认或清除相关中断状态
7. 内核按其设计处理待运行任务和调度请求
8. 恢复需要继续执行的现场
9. 返回被中断的执行流，或转入另一个可运行任务
上述步骤是帮助理解的抽象流程。某些现场由硬件保存，另一些由软件保存； 有些内核在中断退出时检查调度请求，有些则通过专门的内核路径处理。 因此，不应将这份列表视为所有处理器都必须遵循的固定指令顺序。
四、中断系统的关键组成
具体名称与结构会随芯片和处理器架构而变化。
中断使能与优先级
控制中断是否能够被响应，以及多个请求之间的处理顺序。 优先级语义、屏蔽规则和可嵌套条件由具体处理器及配置决定。
中断向量与入口
将中断源关联到相应的处理入口。向量布局、跳转形式和入口开销取决于芯片架构及工具链。
中断服务程序（ISR）
执行必要的事件处理工作。ISR 应关注时限、执行路径和资源访问， 并避免不必要的长时间处理或不可控阻塞。
五、中断上下文保存与恢复
保存哪些状态，取决于处理器架构、编译器约定和内核实现。
中断处理必须遵守处理器与软件之间的调用约定，确保被打断的执行流在中断结束后能够正确继续。 但这并不意味着每次中断都必须由软件显式保存所有寄存器。
| 状态或资源 | 作用 | 需要注意的区别 |
|---|---|---|
| 程序计数器（PC） | 确定被中断程序后续的执行位置。 | 保存方式由处理器中断入口和返回机制决定。 |
| 堆栈指针（SP） | 定位当前使用的堆栈区域。 | SP 是否需要额外保存，以及何时切换堆栈，取决于实现。 |
| 通用寄存器 | 保存计算、指针与临时数据等执行状态。 | 实际保存集合取决于 ISR、编译器约定和内核上下文设计。 |
| 处理器状态 | 包含条件标志、控制状态或其他执行属性。 | 具体寄存器名称与保护规则随架构而异。 |
| 扩展寄存器 | 某些处理器还具有浮点或向量等扩展状态。 | 并非所有 MCU 都具备这些资源，也不一定在每次中断时保存。 |
上下文保护的目标是保证执行正确性，而不是无条件保存尽可能多的寄存器。保存范围越大，通常需要处理的数据越多，但实际延迟还取决于指令、存储位置和实现方式。
六、中断与任务调度的关系
中断可以影响任务状态，但中断本身不是任务调度器。
情况 A：无需任务切换
ISR 完成事件处理后，没有改变可运行任务的选择结果， 内核可能直接恢复原来的执行流。
情况 B：需要重新评估调度
ISR 可能通知等待事件的任务，或更新内核状态。 内核根据调度策略判断是否需要在适当的执行边界切换任务。
中断请求
↓
进入 ISR 并处理事件
↓
是否改变可运行任务或调度条件？
├─ 否 → 按内核路径返回
└─ 是 → 依据调度策略检查是否需要切换
↓
恢复原执行流或切换任务
图示为概念流程。任务通知方式、就绪队列更新时机及调度检查位置，需以具体内核实现为准。
七、中断优先级与嵌套
中断嵌套会改变响应关系，也会增加执行路径和资源管理复杂度。
优先级与抢占
处理器根据优先级与屏蔽状态决定哪些中断可以打断当前执行流。 高优先级请求是否能立即抢占，取决于架构规则和当前处理器状态。
嵌套与现场管理
允许嵌套时，必须考虑现场保护、堆栈使用、共享状态和返回顺序。 更深的嵌套可能增加堆栈需求与高优先级中断之间的干扰。
嵌套中断并非越多越好。设计时需要权衡紧急事件的响应需求、堆栈容量、临界区长度和系统可分析性。
八、8051 平台需要特别注意什么？
通用 RTOS 理论需要结合具体 MCU 的中断与寄存器机制理解。
经典 MCS-51 / 8051 与许多 Cortex-M 处理器的中断入口机制并不相同。 不能直接把 Cortex-M 的自动压栈行为套用到 8051 上，也不能假设所有上下文状态都由硬件自动保存。
分析 8051 中断实现时，尤其需要确认：
寄存器组与状态寄存器
检查 PSW、当前寄存器组以及 ISR 与任务之间的寄存器使用约定， 确保现场保护和恢复规则一致。
内部 RAM 与堆栈
评估中断入口、函数调用、嵌套层级和任务上下文保存带来的堆栈消耗， 避免现场被覆盖或内存越界。
中断入口与返回路径
以目标芯片、Keil C51 编译器生成的代码和实际内核实现为准， 核对入口跳转、现场保护及中断退出逻辑。
内核与 ISR 的协作
确认 ISR 可以调用哪些内核接口、何时允许请求调度， 以及任务切换如何与中断返回路径衔接。
以上是 8051 系统的审查要点，并不代表所有 8051 RTOS 都采用相同实现。HRTOS 的具体执行顺序和现场布局，应以对应版本的内核代码及反汇编结果为依据。
九、中断如何影响实时响应？
单一的中断延迟指标不能代表完整的系统响应时间。
中断响应延迟通常用于描述从中断请求产生到处理器开始执行相应处理路径之间的时间。 实际定义应明确起止事件，并说明是否包含请求屏蔽、当前指令完成和入口开销。
如果中断用于唤醒任务，那么事件到任务动作完成的时间还可能包括 ISR 执行、 调度等待、任务切换、其他任务的干扰以及任务本身的执行时间。
事件发生
↓
中断响应延迟
↓
ISR 执行与事件处理
↓
调度等待与可能的上下文切换
↓
任务执行
↓
目标动作完成
实时分析的关键问题
中断屏蔽时间是否受控？ISR 的最坏执行路径是否清楚？ 高优先级中断会产生多少干扰？任务会阻塞多久？ 从事件发生到目标动作完成的总时间，是否满足规定的截止时间？
十、核心总结
中断是嵌入式系统响应异步事件的重要机制，也是 RTOS 与硬件事件协作的关键路径。
它可能改变任务状态并触发调度判断，但不意味着每次中断都会发生任务切换。
要正确理解中断，需要同时关注硬件入口、现场保护、ISR 执行、嵌套规则、
调度策略和目标平台的时间约束。对 8051 系统，还必须以真实寄存器布局、
堆栈使用与实际执行路径为依据进行分析。
系统关联路径
从中断机制继续深入调度、上下文切换与系统执行路径。
建议阅读顺序：中断基础 → 上下文切换 → 任务调度 → 中断流程系统视图。