中断延迟（Interrupt Latency）

01 / 概念与测量边界

中断延迟（Interrupt Latency）描述中断请求发生后，处理器到达某个明确的中断处理测量点所经历的时间。在工程测试中，常将 ISR 入口或 ISR 中的指定标记点作为终点，但两种测量口径并不相同。

T_latency = T_measurement_end − T_interrupt_request

其中，起点可以是外部引脚上的有效边沿、外设中断请求形成的时刻，或测试系统能够可靠识别的其他事件。终点则必须明确规定，例如 ISR 第一条软件指令、入口代码完成后的标记点，或用户 ISR 中的 GPIO 翻转位置。

响应延迟

请求到达指定处理测量点的时间，不应默认包含整个 ISR 的执行过程。

中断处理时间

从所选 ISR 起点到所选处理终点的执行时间，取决于代码路径与运行条件。

响应链路总时间

从外部事件到任务完成相应工作的时间，还可能包含 ISR、调度、切换与任务处理。

关键原则： 比较不同系统或不同版本的延迟数据时，必须统一起点、终点、时钟条件、编译配置和中断负载。单独给出一个延迟数字，并不足以说明完整的实时性能。

02 / 延迟由哪些因素组成

8051 的中断响应不是单一的固定软件函数调用。从请求产生到用户 ISR 开始执行，可能经历处理器当前指令完成、中断使能与优先级条件检查、更高优先级中断的影响，以及内核或编译器相关的入口处理。

01

请求产生与识别

外设或引脚产生中断请求。请求形成时刻与测试仪器实际观察到的信号边沿，可能并不完全相同。

02

处理器响应条件

当前指令执行、中断使能状态、优先级规则以及正在处理的中断，都会影响何时能够响应新请求。

03

中断入口处理

处理器进入相应中断入口后，还可能执行跳转、软件保存、寄存器或内核状态处理等操作。具体开销取决于目标实现。

04

到达测量终点

执行到所选 ISR 标记点时，记录响应延迟。若测量点放在更靠后的代码中，结果也会包含此前执行的指令。

不应把所有阶段都视为每次必然出现、开销固定且可以直接相加的独立项。应根据实际中断入口、编译结果和测试路径，建立与目标固件相符的时间模型。

03 / 影响延迟的主要因素

因素	影响方式	分析重点
当前指令	处理器通常需要遵循目标指令集规定的中断响应时序。	检查指令周期与指令边界。
中断使能状态	中断被屏蔽时，请求可能无法立即进入相应处理路径。	统计屏蔽窗口的长度与发生条件。
优先级与嵌套	已在执行的中断及优先级规则可能推迟其他请求的处理。	核对实际硬件与内核的优先级行为。
入口代码	跳转、软件状态保存和其他入口操作会影响指定测量点的到达时间。	结合反汇编与目标编译配置核算。
测试方法	GPIO 翻转、探针插入和测量仪器均可能改变或影响观测结果。	记录测量点及测试开销。

在 8051 内核中，尤其需要区分处理器硬件完成的中断响应动作与软件实现的上下文管理。不能假定硬件已经自动保存了所有 C 运行环境或 HRTOS 任务上下文。

同样，不能仅凭系统是否使用抢占式调度，就推断某次硬件中断的入口延迟。中断响应与任务调度相关，但它们对应不同的时间边界。

04 / 中断屏蔽与最坏情况

对实时响应而言，中断屏蔽窗口是必须重点检查的因素之一。如果某段代码暂时禁止目标中断响应，那么该窗口可能直接推迟中断处理。即使平均延迟很低，偶发的长屏蔽区间也可能显著抬高最大观测值。

分析时应关注

全局中断禁止与单个中断源屏蔽的区别。
屏蔽开始和恢复的位置是否覆盖了所有相关代码路径。
嵌套中断、较高优先级中断以及重复请求是否影响目标事件。
临界区执行时间是否随分支、循环、编译优化或共享状态变化。
测试是否覆盖了响应最不利的指令与系统运行状态。

避免混淆： 缩短 ISR 本身通常有助于降低处理占用时间和后续请求的等待；但对一个已经可以被处理器接纳的中断来说，ISR 后半段的执行时间不等同于它到达 ISR 入口之前的延迟。

平均值与最坏情况

平均延迟可以描述常见负载下的表现，却不能单独证明实时响应上界。测试得到的最大值也只代表已覆盖样本中的最大观测结果，不能自动等同于数学上已经证明的最坏情况上界。

对最坏情况中断延迟（Worst-Case Interrupt Latency）的分析，需要结合目标芯片的中断响应规则、实际指令路径、中断屏蔽行为、优先级约束和明确的环境假设。如果条件尚未全部覆盖，应将结果表述为实测最大值或限定条件下的分析结果，而不是无条件的硬实时保证。

05 / 测量与验证方法

对 HRTOS 这类面向 8051 的系统，推荐将示波器或逻辑分析仪测量与固件反汇编分析结合起来。外部测量有助于观察真实的引脚时间关系；反汇编则用于解释入口指令、标记指令和相关执行路径的成本。

方法 A：外部信号与 GPIO 标记

选择可重复触发的外部中断事件，并确定请求的观测起点。
在指定 ISR 测量点翻转 GPIO，确保标记代码本身足够简单。
使用示波器或逻辑分析仪测量请求信号与标记信号的时间差。
在记录中说明标记位于硬件入口、内核入口之后，还是用户 ISR 的某个位置。
分别测试典型状态与不利状态，并保存时钟、编译配置及测试条件。

方法 B：反汇编与周期审计

确认测试使用的 HEX、目标芯片、时钟频率和编译选项。
定位实际中断向量及从入口到测量点的指令路径。
按照目标芯片的指令周期规则，计算每条相关指令的执行成本。
检查中断屏蔽、嵌套条件与可能的入口路径差异。
将静态计算与实测结果交叉验证，并解释测量偏差。

测量记录建议

Target MCU       : 实际目标芯片型号
Clock / Mode     : 实际时钟频率及工作模式
Compiler Config  : 编译器版本与关键选项
Request Point    : 中断请求的观测起点
Measure Point    : ISR 中明确指定的测量终点
Interrupt State  : 中断使能、屏蔽与优先级条件
Instrumentation  : GPIO 标记方式及测量设备
Result           : 样本数、最小值、平均值、最大值
Analysis         : 反汇编周期核算与结果差异

GPIO 标记位置越靠后，测量值中包含的软件执行成本越多。若目标是测量内核入口延迟，不能直接将用户 ISR 中较晚位置的测量结果当作入口延迟。

06 / HRTOS 中断路径与调度的关系

HRTOS 的中断响应分析需要结合 8051 处理器行为、实际中断入口代码以及内核对上下文的管理方式。硬件中断进入、内核状态处理、ISR 执行和中断退出，属于一条相互关联但各有测量边界的执行链。

os_interrupt_exit() 是 HRTOS 中需要重点核对的中断退出接口。对 ISR 入口、上下文处理以及退出后的实际控制流，应以当前 HRTOS 4.0 的源代码、汇编实现和目标编译结果为准。

外部事件 → 中断请求 → 处理器响应 → 内核 / ISR 入口处理 → ISR 执行 → 中断退出处理 → 后续执行路径

中断退出后是否以及何时发生任务切换，需要结合内核实现和当时的调度条件判断。任务切换时间不应直接计入所有中断入口延迟的定义中；如果关注的是事件到任务响应的总时间，则应单独测量或分析调度与上下文切换阶段。

本页不将未经核对的通用 RTOS API 当作 HRTOS 已有接口。中断编号获取、ISR 上下文判断、临界区控制及中断内通信接口，均应以 HRTOS 4.0 实际公开的头文件与实现为准。

07 / 优化原则与验证闭环

优先优化可证明的时间来源

检查屏蔽窗口：找出不必要的长时间中断屏蔽，并确认修改后共享状态仍然安全。
核对入口路径：使用反汇编识别实际执行的入口指令，而不是仅凭 C 代码估算开销。
控制 ISR 工作量：避免不必要的循环、长时间计算和无必要的阻塞操作。
检查嵌套条件：验证优先级与嵌套行为是否符合目标芯片及内核的真实实现。
重复测量：在相同条件下比较修改前后的延迟分布，并保留固件版本与测试记录。

建立闭环

明确指标 → 建立测量方法 → 获取实测数据 → 分析反汇编路径 → 定位时间来源 → 修改实现 → 重复验证

对实时内核而言，优化的目标不只是降低某一次测量的数字，而是理解延迟来自哪里、哪些条件会使它增大，以及修改后能否在可重复的测试和明确的假设下得到验证。

08 / 本页小结

中断延迟是实时系统响应分析的重要指标，但只有在测量边界清晰的前提下才具有可比性。对 HRTOS 8051 平台，应把处理器响应、入口处理、ISR 执行、中断退出和任务切换分开分析，再根据实际需求组合成完整的响应时间模型。

实测数据用于观察真实运行表现，反汇编与周期审计用于解释指令路径，而最坏情况上界则需要明确的系统假设和足够严谨的分析。三者相互补充，不能互相替代。