中断进入
从硬件事件和中断控制条件出发，进入相应的中断处理路径。
01. 中断机制的职责
中断处理负责响应异步事件；任务调度负责决定哪个任务获得处理器。 两者相互协作，但中断发生并不意味着一定发生任务切换。
在典型的微控制器系统中，中断源可以来自定时器、串口、外部引脚 或其他外设。事件发生后，硬件和软件共同决定中断何时被接受、 由哪个处理入口执行，以及如何返回先前的执行路径。
阅读本页时需要区分：
中断请求、中断被接受、ISR 开始执行、ISR 结束和任务切换是不同阶段。
它们之间存在执行顺序和条件约束，不能直接视为同一事件。
02. 中断处理的整体流程
机制级流程示意。实际硬件接受规则、中断入口、状态处理及退出分支应以目标芯片和 HRTOS 实现为准。
中断请求可能因屏蔽状态、优先级或芯片规定的接受条件而不能立即执行。 ISR 结束后，内核也不一定马上选择新任务：如果没有满足切换条件， 执行流可以继续原来的路径。
03. 中断源与接受条件
不同中断源的触发方式、标志处理方式和硬件约束并不完全相同。 在分析中断路径时，需要把外设行为与处理器的中断控制机制分开考察。
| 中断来源 | 典型用途 | 分析重点 |
|---|---|---|
| 定时器 | 系统时基、周期性采样 | 计数周期、溢出标志、入口延迟 |
| 串口或通信外设 | 接收、发送与通信事件 | 数据读取时机、标志清除和缓冲区处理 |
| 外部中断 | 引脚边沿或电平事件 | 触发模式、信号持续时间与优先级 |
| 其他片上外设 | PWM、捕获比较等事件 | 芯片手册规定的专用中断行为 |
在传统 8051 及其兼容扩展中，中断源、优先级数量、寄存器布局和响应规则 可能随具体芯片而变化。因此，涉及 STC 系列增强型 8051 时， 应使用目标型号的数据手册，而不是只依赖经典 8051 的通用描述。
04. 中断入口与现场保护
中断入口是从当前执行流进入 ISR 的边界。 在 8051 架构下，硬件中断响应会涉及程序执行位置的保存和跳转， 但完整的任务或 ISR 现场保护仍可能需要软件完成。
01
硬件接受中断
处理器依据中断使能、优先级及相关硬件条件接受请求， 并转入对应中断入口。具体接受时机还受到当前指令执行状态等因素影响。
02
执行入口处理
入口代码根据系统设计完成必要的状态保护、寄存器处理和执行环境准备。 对由跳转方式进入的专用内核路径，应特别核对它与普通函数调用的区别。
03
建立 ISR 执行环境
ISR 使用其实际配置的寄存器、栈和共享数据。 如果 ISR 会调用内核 API 或允许嵌套中断，还需要核对相应的现场保护约束。
8051 特别注意：
硬件保存返回地址并不意味着 ACC、PSW、DPTR、工作寄存器或其他软件状态都已自动保存。
必须依据实际入口汇编及编译器生成代码确定保护范围。
05. ISR 的设计原则
中断服务程序直接影响其他中断和任务的等待时间。 因此，ISR 的设计不仅要保证功能正确，还应使执行时间、共享数据访问和嵌套行为容易分析。
| 设计原则 | 工程原因 |
|---|---|
| 控制执行路径 | 减少不必要的分支和不受约束的循环，使执行时间更容易评估。 |
| 避免阻塞等待 | 阻塞式操作可能延长 ISR 占用处理器的时间，并影响其他事件响应。 |
| 谨慎访问共享数据 | 避免 ISR 与任务之间出现竞态、数据不一致或额外的临界区开销。 |
| 明确标志处理 | 按照外设手册处理待处理中断标志，避免重复进入或丢失事件。 |
| 限制嵌套复杂度 | 嵌套会增加现场保护成本、栈使用量及执行时间分析难度。 |
| 将非紧急工作移至任务层 | 缩短中断占用时间，并将复杂逻辑放入更适合管理和测试的执行环境。 |
ISR 越短并不自动代表系统实时性越好。还需要确保必要的事件处理没有遗漏，
数据传递机制正确，并且延后处理不会违反事件截止时间。
06. 中断嵌套机制
中断嵌套允许符合条件的更高优先级中断在当前中断处理尚未完成时进入执行。 这样可以缩短高优先级事件的等待时间，但同时增加现场保护、栈空间和返回顺序的复杂性。
嵌套中断需要满足的条件
- 当前执行环境允许接受更高优先级中断。
- 目标中断的硬件优先级、使能状态及芯片规则允许进入。
- 现场保存和恢复路径能够正确处理嵌套前后的状态。
- 中断栈或相应的栈空间能够容纳允许的嵌套层级。
- 中断退出顺序与实际入口方式保持一致。
不能忽略内核状态约束：
在 RTOS 中，允许嵌套的条件还可能受内核执行状态限制。
不能仅凭硬件支持中断优先级，就推断任意内核执行位置都允许嵌套。
对 HRTOS 的具体嵌套行为，应结合内核对中断入口、嵌套处理和退出路径的实际实现进行核对， 并使用目标芯片验证允许的中断优先级组合与栈预算。
07. 中断退出与任务调度
中断退出不仅是 ISR 最后一条语句之后的返回操作。 对 RTOS 而言，还需要确保现场恢复、中断状态与可能发生的任务切换相互兼容。
ISR 完成必要的事件处理
↓
执行相应的中断退出逻辑
↓
检查适用的内核与调度条件
├── 无需任务切换
│ ↓
│ 恢复原执行路径
│
└── 需要任务切换
↓
进入对应的任务切换路径
↓
恢复目标任务执行环境
不同内核的中断入口和退出机制可能存在明显差异。 有的实现直接使用标准中断返回指令，有的实现则通过专门的汇编入口、 内核状态管理或中断退出接口完成后续处理。
HRTOS 实现提示：
对于通过跳转进入的专用中断路径，不能直接假定其与普通 C 函数调用具有相同的现场与返回语义。
应结合对应版本的中断入口代码和 os_interrupt_exit()
调用约定，确认返回地址、现场保护和退出流程。
08. 中断响应时间与实时性
中断响应时间应当首先明确测量边界。 从物理事件发生到 ISR 开始执行的时间，与从事件发生到 ISR 完成的时间， 是两个不同的指标。
| 指标 | 典型边界 | 需要考虑的因素 |
|---|---|---|
| 中断响应延迟 | 中断事件或请求到 ISR 开始执行 | 硬件接受条件、当前指令、屏蔽状态、优先级和入口开销 |
| ISR 执行时间 | ISR 开始到 ISR 处理结束 | 指令路径、分支、数据访问、调用和中断标志处理 |
| 嵌套干扰时间 | 低优先级 ISR 被更高优先级中断延迟的时间 | 允许的嵌套中断、嵌套深度与各层执行时间 |
| 中断到任务响应时间 | 事件发生到目标任务开始处理 | 中断响应、ISR、调度决策、任务切换及其他干扰 |
最坏情况分析的基本要求
- 明确起点、终点以及需要覆盖的执行路径。
- 依据目标芯片和实际编译产物分析指令周期。
- 考虑中断屏蔽区间、允许的嵌套干扰和分支路径。
- 区分静态分析得到的上界、测试观测值与平均耗时。
- 记录芯片型号、时钟、编译选项和测量条件，确保结论可复现。
实时性分析的关键：
单次测量可以提供实际执行路径的耗时证据，但不能单独证明最坏情况上界。
要得到可信的上界，还需要覆盖相关控制流路径，并对中断与硬件时序条件作出合理约束。
09. 工程验证与排查
对中断机制进行工程验证时，可以把问题拆分为入口、服务执行、嵌套与退出四个部分， 逐项确认硬件行为和软件执行路径。
01
核对目标芯片配置
确认中断源、使能位、优先级设置、触发方式及相关外设标志。
02
检查入口与现场保护
检查中断入口指令、程序计数器处理、寄存器保存、栈变化及编译器生成代码。
03
验证嵌套和返回
在受控条件下检查嵌套是否符合预期，并确认每一层中断均按正确顺序退出。
04
测量并交叉验证
结合 GPIO、逻辑分析仪、反汇编和指令周期统计，核对实际测量边界与静态分析路径。
测量工具本身也可能影响时序。GPIO 操作、调试输出和额外的变量访问会引入开销；
应明确哪些开销属于被测路径，哪些属于测量方法。
10. 小结
中断机制的核心不只是快速进入 ISR，而是确保异步事件能够按照硬件规则和内核约束被正确处理， 并在中断结束后安全地返回原执行路径或进入适用的任务切换路径。
在 8051 上，入口方式、硬件堆栈、寄存器保护、中断优先级和返回语义都直接影响实现正确性。 对 HRTOS 的进一步分析，应以具体内核版本、汇编清单和目标芯片行为为依据， 逐步建立可验证的执行路径与实时性结论。
本页中的流程图用于解释中断处理的一般机制，并非对所有芯片和 HRTOS 版本的逐指令描述。
有关具体嵌套限制、寄存器保存顺序、调度触发条件和最坏情况时间，
应以对应实现及测试证据为准。