微秒很重要：减少工业控制系统中的中断延迟

性能是大多数嵌入式系统开发人员永远不会偏离的话题。但是，相对而言，我们中的许多人都过得很轻松。我们开发了软实时系统，在该系统中，响应事件的额外几微秒甚至几毫秒的延迟不会引起关注。

不过，还有很多其他开发商不喜欢这种奢侈。工业控制项目是硬实时要求非常普遍的应用领域。对于该领域的开发人员，尤其是那些工作涉及电机控制的开发人员，我们中的一些人认为理所当然的微秒可能至关重要。

为了满足紧迫的响应时间，工业控制工程师可能有必要做出在其他情况下看起来很荒谬的妥协。一些做出此类设计决策的工程师倾向于避免使用实时操作系统 (RTOS)。虽然在许多圈子中，RTOS 被视为编写多任务应用程序代码的高效软件平台，但开发人员放弃 RTOS 的情况并不少见，因为它感知到的开销，特别是它对中断延迟的影响。

中断延迟基础知识

为什么 RTOS 尽管有“实时”标签，却在某些嵌入式系统开发人员中获得了这种负面声誉？要回答这个问题，我们首先应该简要回顾一下中断延迟的概念。

尽管中断可以描述为立即响应硬件事件的一种方式，但从事件到执行该事件的代码的转换肯定不是瞬时的。给定系统中的每个中断服务程序 (ISR) 都会经历一定程度的延迟或延迟。如图1 所示，这种延迟可以分为硬件和软件组件。

图 1：硬件和软件都会影响中断延迟。

硬件中断延迟通常反映了操作所需的时间，例如在 CPU 中完成当前正在执行的指令、定位中断处理程序的地址以及保存所有寄存器——这些操作在大多数情况下不属于开发人员的范围。控制。当然，它还受到 CPU 架构的影响。另一方面，软件延迟取决于系统的中断禁用时间和系统 ISR 序言的大小——在中断处理程序启动之前手动保存寄存器和执行其他内务操作的代码。至少在应用程序代码中，开发人员通常能够限制这些数量，从而将系统的中断延迟降低到可接受的低水平。

如果使用 RTOS，等式会发生一些变化。RTOS 通常会有自己的 ISR 格式——包括序言和尾声——而且，也许更重要的是，它会包含许多禁用中断的关键代码部分。临界区代表了任何系统的额外中断延迟源，否则该系统将具有零中断禁用时间。

当然，为了促进他们的软件的采用，RTOS 开发人员试图使关键部分尽可能简短，并尽量减少这些代码段落的数量。然而，这可能是一项具有挑战性的工作，因为任何有可能在 ISR 中访问的 RTOS 变量或数据结构（可能是通过 API 调用）都必须使用关键部分进行保护，以避免出现竞争条件。即使在高效、编写良好的 RTOS 中，最长的关键部分也可能超出硬实时控制系统的允许范围。  

中断延迟问题使此类系统的开发人员处于困境，因为 RTOS 可以带来许多好处。尽管它可能会产生任何开销，但 RTOS 最终是一种有效利用 CPU 的工具。利用 RTOS 的开发人员拥有一个可以相对轻松地维护和扩展的便携式多任务软件平台。 

零添加中断延迟 RTOS

幸运的是，有一种方法可以消除 RTOS 造成的中断延迟，而且结果非常简单，前提是 RTOS 运行在配备有足够可配置的中断硬件的处理器上。该方法背后的想法是，如果只有部分系统中断处理程序有可能（再次通过 API 调用）访问 RTOS 变量，则无需在 RTOS 临界区禁用所有系统中断。采用这种方法的 RTOS 不使用全局中断禁用和启用，而是在关键部分的开始和结束处简单地更新中断优先级或级别寄存器，假设底层处理器确实提供了这样的寄存器。说明这种方法的伪代码如下所示。

#define CRITICAL_ENTER() set_int_prio(5)

#define CRITICAL_EXIT() set_int_prio(0)

无效 RTOS_function (无效)

{

CRITICAL_ENTER(); /* 增加优先级 */

访问 RTOS 变量；

CRITICAL_EXIT(); /* 将优先级返回低级 */

}

为了使优先级调整按预期工作，使用在关键部分采用这种技术的 RTOS 的应用程序开发人员必须根据图 2 所示的方案确定其中断处理程序的优先级。此方案中的最高优先级对应于不进行 RTOS 调用且不依赖任何 RTOS 服务的处理程序。这些处理程序（有时称为“非内核感知”ISR）的优先级超过了与关键部分相关的级别，因此它们绝不应该被 RTOS 延迟。

图 2：最高优先级的中断永远不会被 RTOS 禁用。 

在“非内核感知”处理程序之后是能够利用 RTOS 服务的“内核感知”ISR。用于实现此优先级方案的中断控制器预计会阻止“内核感知”ISR 在关键部分期间执行。因此，这些处理程序的中断延迟将超过“非内核感知”例程的延迟。权衡是较低优先级的处理程序可以调用 RTOS API，例如，向位于优先级层次结构底部的任务之一发出信号。 

硬件和软件支持

对于所有中断硬件或所有微控制器/处理器，都不可能以建立关键部分为目标来操纵优先级。然而，优先中断控制器已成为现代 32 位 MCU 的标准，目前为工业控制项目选择的许多硬件平台都配备了此类控制器的高度可配置实现。这意味着曾经避免使用 RTOS 的硬实时系统开发人员现在可以选择为他们的项目带来高效的多任务处理能力。例如，大多数或所有基于 ARM Cortex-M 的微控制器和 Renesas RX 系列设备都可以很好地使用这种中断方案。所需资源只不过是一个优先级中断控制器，它可以在软件中调整优先级。 

在决定利用哪些特定 RTOS 来实现这些功能时，开发人员必须谨慎行事。可以想象，纳秒、微秒和毫秒范围内的延迟都可能被 RTOS 提供商解释为“低”，但对运行速度有要求的潜在 RTOS 用户可能会持不同的看法。

两个 RTOS 示例是 Micrium 的 µC/OS-II 和 µC/OS-III。两者在工业控制系统中的使用历史悠久，并支持本文中描述的临界区格式。对于希望将 RTOS 强大的多任务处理能力来应对工业设计中硬实时系统的挑战的开发人员来说，它们是两个可行的选择。

审核编辑 黄昊宇