LAYER 01
处理器与外设
负责产生中断请求，并依据目标芯片的硬件规则响应中断。
Architecture / Interrupt
中断模型 Interrupt Model
从 8051 硬件中断请求到 HRTOS 中断入口、ISR 执行和退出处理， 梳理硬件响应与内核上下文管理之间的关系。
01 / 中断模型的职责
中断机制用于响应异步于当前任务执行流的事件。 在典型 8051 系统中，中断请求由定时器、串口、外部中断等硬件功能产生； 处理器根据芯片规定的中断使能和优先级规则决定何时响应。
HRTOS 的中断模型不仅涉及处理器如何进入中断入口， 还涉及软件如何管理中断执行期间需要维护的状态，以及中断退出时如何衔接内核的后续执行。
LAYER 02
中断入口
将硬件中断响应衔接到实际入口代码，处理内核要求的软件状态。
LAYER 03
ISR 处理逻辑
执行与中断源有关的必要处理，完成状态读取、确认或其他受约束的操作。
LAYER 04
退出与后续执行
完成中断退出所需的处理，再依据实际控制流继续执行或进入内核安排的其他路径。
架构边界：
以上是理解中断机制的分层模型，不代表 HRTOS 每次中断都经过完全相同的函数调用序列。
实际路径应以目标芯片、HRTOS 4.0 源码及最终编译结果为准。
02 / 硬件响应与软件入口
8051 的中断响应由具体芯片的硬件规则决定。 请求产生后，处理器是否能够立即响应，取决于当前指令、中断使能状态、优先级以及正在执行的中断等条件。
进入硬件中断入口，不等于处理器已经保存了完整的任务上下文。 处理器的硬件响应动作与 HRTOS 所需的软件上下文管理，是两个需要分别理解的层次。
| 层次 | 主要职责 | 核对依据 |
|---|---|---|
| 硬件响应 | 按芯片规则识别可响应的请求，并转入对应中断入口。 | 芯片数据手册与指令集说明。 |
| 入口代码 | 执行实际固件安排的跳转、状态保存及相关处理。 | 汇编源代码与反汇编结果。 |
| 内核上下文管理 | 维护 HRTOS 执行路径所要求的任务或内核状态。 | 内核实现、头文件与目标编译结果。 |
| 中断退出 | 完成相应退出处理，并衔接内核定义的后续执行路径。 | 退出接口实现及实际控制流。 |
不能仅凭通用 RTOS 的工作方式，就断定 HRTOS 使用某个固定的 ISR 包装函数、
完整自动寄存器保存方案或统一的中断控制器抽象层。
03 / 一次中断的执行链路
从架构视角，可以把一次中断处理拆分为以下阶段。 这张流程用于说明各阶段之间的关系；具体指令、函数调用和分支条件应以实际实现为准。
01
中断请求形成
外设或外部输入产生请求。请求的具体来源与清除方式由芯片和外设定义。
02
处理器响应
处理器依据当前执行状态、使能条件与优先级规则判断何时进入中断入口。
03
入口与必要状态处理
执行目标固件实际定义的入口指令及软件状态管理，不能假定所有上下文都由硬件自动保存。
04
ISR 执行
运行中断服务逻辑，并遵守该中断路径对寄存器、共享状态及执行时间的约束。
05
退出处理
通过目标实现规定的退出路径完成中断相关处理，再继续后续执行。
06
继续执行或发生切换
实际结果取决于 HRTOS 的退出逻辑和当时的内核状态，不能假定每次中断退出都会切换任务。
Conceptual execution path
Interrupt Request
|
v
Hardware Response
|
v
Interrupt Entry / Required State Handling
|
v
ISR Execution
|
v
Interrupt Exit Processing
|
v
Continue Execution or Kernel-Controlled Transition
中断响应延迟、ISR 执行时间与退出后的任务切换时间是不同的测量对象。 若分析事件到任务完成响应的总时间，应将相关阶段分别测量或计算后再建立完整模型。
04 / 上下文管理与退出机制
上下文管理的目标是确保控制流转换前后，内核所要求保留的状态能够按约定得到维护。 在资源受限的 8051 平台上，寄存器使用、堆栈布局、入口方式与编译器生成代码都可能影响实现。
因此，不能把任务上下文切换与硬件中断响应视为同一个动作。 前者服务于任务执行环境之间的转换；后者负责响应中断请求。 两者可以在内核执行路径上相互衔接，但其触发条件和状态管理目标并不相同。
HRTOS 中断退出接口
os_interrupt_exit() 是 HRTOS 中断退出路径中需要重点关注的接口。
在阅读其实现时，应同时核对入口代码如何进入、软件保存了哪些状态，以及退出后实际跳转到何处。
源码核验原则：
不应仅凭函数名称推断该接口内部一定执行调度、恢复全部寄存器或切换任务。
这些职责应通过 HRTOS 4.0 的真实实现确认。
05 / 中断嵌套与优先级约束
中断优先级决定不同请求在目标硬件规则下的响应关系。 但“优先级较高”并不意味着在任何时刻都能无条件抢占正在执行的中断。 是否允许嵌套，还取决于芯片的中断控制规则、当前使能状态和内核入口实现。
核对嵌套行为时，应确认
- 目标芯片实际支持的中断优先级和嵌套规则。
- 中断入口与执行期间的中断使能状态。
- 内核对中断期间寄存器、堆栈和执行状态的管理方式。
- 不同中断路径之间是否共享资源或存在重入风险。
- 退出处理如何与正在执行的中断及内核状态衔接。
嵌套支持不仅是优先级配置问题，还涉及上下文正确性、堆栈预算和共享状态安全。 未经源码与目标芯片验证，不应将固定嵌套层数、任意重入能力或通用软件中断机制写成系统既定特性。
06 / ISR 设计与系统协作
ISR 应优先完成对当前中断源必要的处理，并谨慎控制执行时间和共享状态访问。 复杂工作是否适合移交任务执行，需要根据 HRTOS 实际提供的通信与同步机制决定，不能默认系统存在通用的 Bottom Half 或所有常见的 FromISR API。
DESIGN 01
限制处理范围
只在中断路径内执行必要工作，避免无必要的长循环与高成本处理。
DESIGN 02
保护共享状态
检查 ISR 与任务之间的数据访问，明确原子性、可重入性及同步约束。
DESIGN 03
核对资源预算
结合目标编译结果检查堆栈使用、寄存器保存与嵌套情况下的资源需求。
DESIGN 04
验证真实路径
用源码、反汇编和实测确认入口、退出及任务衔接行为，而非只依赖概念图。
实时性不是单纯追求最短 ISR。正确性、共享状态安全、堆栈预算和可验证的响应时间必须同时满足。
07 / 本页小结
HRTOS 的中断模型需要同时理解处理器硬件响应与内核软件管理。 硬件中断入口、ISR 执行、上下文维护和退出后的控制流是相互关联的阶段，但不应被混为同一操作。
对具体机制的判断应以目标芯片资料、HRTOS 4.0 源码、反汇编和可重复测试为依据。 这种以实际实现为中心的描述方式，能够为中断流程、响应延迟与最坏情况分析提供一致的技术基础。