📚 课程目录第4章零延迟中断

零延迟中断：ThreadX 的硬实时杀手锏

各位做嵌入式的老铁，咱们做 RTOS 最头疼的是什么？

中断响应慢。尤其是那些对时间要求苛刻的外设——电机控制、高速通信、传感器采集——中断晚来 1 微秒，系统可能就崩了。

ThreadX 的零延迟中断（ZLI），说白了就是给这些“急性子”中断开了一条绿色通道。它不经过内核调度，不排队，不等待。中断来了，直接跑你的 ISR。

我当年在一个伺服驱动器项目里，就吃过中断延迟的亏。电机每转一圈要发 4096 个脉冲，每个脉冲都得在 2μs 内响应。用普通 RTOS 中断，偶尔会丢脉冲，电机就抖。后来换成 ThreadX 的 ZLI，问题直接解决。

什么是零延迟中断？

传统 RTOS 里，中断来了要经过一层“壳”——保存上下文、判断是不是内核服务、再跳转到用户 ISR。这层壳就是延迟的来源。

ThreadX 的 ZLI 呢？它把中断向量表里某些中断直接指向你的 ISR，不经过任何 RTOS 代码。中断来了，CPU 直接跳过去。延迟就是 CPU 硬件响应时间，零软件开销。

核心要点：ZLI 中断不调用 ThreadX 的任何 API，不触发调度，不改变系统状态。它就是一个“裸奔”的中断。

ZLI 与普通中断的对比

特性	普通 ThreadX 中断	零延迟中断 (ZLI)
入口路径	经过 __tx_irq_handler 包装	直接跳转用户 ISR
上下文保存	自动保存全部寄存器	用户自己决定保存哪些
可调用 API	所有 ThreadX API	不能调用任何 API
触发调度	ISR 退出后可能调度	不触发调度
延迟	几十到几百个周期	CPU 硬件延迟（通常 < 10 周期）
适用场景	通用中断处理	硬实时、高频、短 ISR

你看这个表就明白了。ZLI 牺牲了 API 调用能力和自动调度，换来了极致的速度。

ZLI 的工作原理

ThreadX 怎么做到“不经过内核”的？

嗯，这里要讲一下中断向量表的处理。

普通 RTOS 启动后，会把中断向量表里所有中断都替换成自己的入口函数。比如 IRQ 号 10，原本指向你的 ISR，RTOS 把它改成指向 __tx_irq_handler。然后 __tx_irq_handler 里再跳转到你的 ISR。

ZLI 的做法是：保留某些中断的原始向量，不让 RTOS 劫持。ThreadX 提供了一个配置宏，叫 TX_ZERO_LATENCY_INTERRUPT。你在这个宏里声明哪些中断号要走 ZLI 模式。

我的习惯：我会把项目中所有硬实时中断都列出来，比如 TIM 的更新中断、ADC 的转换完成中断、编码器的索引中断。这些中断的 ISR 通常只有几十行代码，跑完就完事，不需要跟任务通信。

配置方法

配置 ZLI 其实就两步。我拿 STM32 平台举个例子。

第一步：在 tx_port.h 中使能 ZLI

/* 使能零延迟中断特性 */
#define TX_ZERO_LATENCY_INTERRUPT

/* 定义 ZLI 中断向量表 */
/* 这里声明哪些中断号走 ZLI 模式 */
/* 格式：中断号, ISR 函数名 */
#define TX_ZERO_LATENCY_INTERRUPTS \
    { 23, my_tim_isr },           \
    { 28, my_adc_isr },           \
    { 35, my_encoder_isr }

第二步：编写 ISR 函数

/* ZLI 模式的 ISR，不能调用任何 ThreadX API */
void my_tim_isr(void)
{
    /* 清除中断标志 */
    TIM->SR = ~TIM_SR_UIF;

    /* 直接操作硬件寄存器 */
    /* 比如：更新 PWM 占空比 */
    TIM3->CCR1 = g_new_duty;

    /* 注意：不能调用 tx_semaphore_put 等 API */
    /* 不能触发任务切换 */
}

我曾经踩过的坑：在 ZLI 的 ISR 里调用了 tx_semaphore_put，结果系统直接 HardFault。因为 ZLI 模式下，ThreadX 的全局变量和栈指针状态是不确定的。记住：ZLI 的 ISR 里只能做寄存器操作，不能碰任何 RTOS 对象。

ZLI 的适用边界

不是所有中断都适合 ZLI。我总结了一个判断标准：

适合 ZLI：ISR 执行时间 < 5μs，只操作硬件寄存器，不需要唤醒任务。
不适合 ZLI：ISR 需要发信号量、发消息队列、或者处理时间 > 10μs。

你想想看，如果一个中断既要快，又要跟任务通信，怎么办？

我的做法是：用 ZLI 做第一级快速处理，把关键数据写到共享缓冲区，然后触发一个普通中断（或者用 DMA 完成中断）来做第二级处理，由普通中断去调用 ThreadX API 唤醒任务。

ZLI 与内存优化的关系

咱们这个课程的主题是“内存优化下的中断管理”。ZLI 怎么跟内存扯上关系？

嗯，这里有个细节：ZLI 模式下，ThreadX 不会为这些中断分配额外的栈空间。普通中断的栈是 ThreadX 统一管理的，每个中断嵌套层都要消耗系统栈。而 ZLI 中断用的是主栈（MSP），而且 ISR 里不能调用函数（除非你自己保证栈安全），所以栈消耗极小。

我在一个资源紧张的 Cortex-M0 芯片上，通过把 3 个高频中断改成 ZLI 模式，省出了 256 字节的系统栈空间。对于只有 8KB RAM 的芯片来说，这 256 字节很珍贵。

ZLI 的调试注意事项

调试 ZLI 中断比普通中断麻烦。因为调试器可能不认识你的 ZLI 向量表。我分享几个经验：

断点问题：在 ZLI 的 ISR 里设断点，有时候会触发 HardFault。因为调试器断点也是中断，跟 ZLI 冲突。我一般用 GPIO 翻转来测量时序，不用断点。
栈溢出：ZLI 的 ISR 如果调用了函数，函数内部的局部变量可能会溢出到系统栈。我建议在 ZLI 的 ISR 里只用寄存器变量，或者用 __attribute__((naked)) 声明。
嵌套中断：ZLI 中断可以被普通中断打断，但普通中断不能打断 ZLI（取决于优先级设置）。我习惯把 ZLI 中断的优先级设成最高（0），这样它不会被任何东西打断。

调试技巧：我会在 ZLI 的 ISR 入口和出口各放一个 GPIO 翻转。用逻辑分析仪看这两个 GPIO 的宽度，就能精确测量 ISR 的执行时间。比断点靠谱多了。

ZLI 的典型应用场景

我列几个实际项目里用过 ZLI 的场景：

电机 FOC 控制：PWM 周期中断，每 50μs 触发一次，读取电流值、更新占空比。用 ZLI 后，延迟从 1.2μs 降到 0.15μs。
高速 SPI 通信：SPI 的 RXNE 中断，每接收一个字节就要处理。用 ZLI 保证不丢数据。
编码器索引脉冲：电机每转一圈产生一个索引脉冲，需要精确记录位置。ZLI 确保脉冲到来时立即锁存计数器值。

ZLI 的配置流程图

下面这张图展示了 ZLI 的配置流程和中断处理路径。你可以看到 ZLI 中断和普通中断在入口处的分叉。

从这张图可以看得很清楚：ZLI 路径就是一条直路，没有任何软件开销。普通路径要经过内核包装器，多了上下文保存和调度判断的步骤。

总结一下

零延迟中断是 ThreadX 给硬实时场景准备的一把快刀。用好了，你的系统响应速度能提升一个数量级。但要注意它的限制——不能调 API、不能触发调度、ISR 要短小精悍。

我个人建议：每个项目开始前，先梳理一下所有中断，把那些“时间敏感、逻辑简单、不需要跟任务通信”的中断挑出来，配置成 ZLI 模式。剩下的走普通中断。这样既保证了实时性，又不牺牲系统的灵活性。

嗯，ZLI 的内容就这些。记住一句话：快，是有代价的。ZLI 的代价就是你不能在 ISR 里做任何跟 RTOS 相关的事情。想清楚这个 trade-off，你就能用好它。