这个问题可能看起来有些模糊，但我正在研究中断系统的工作方式和延迟时间。我试图了解ARM中的FIQ等架构设施如何帮助减少延迟时间。这与使用无法访问或无法访问此工具的操作系统有何不同？例如 - Windows RT是为ARM等制作的，并且此操作系统无法移植到其他体系结构。
简单地说 - 与可以移植到许多不同体系结构（例如Linux）的操作系统相比，具有专用操作系统的专用体系结构中的中断延迟有何不同？
对不起咆哮 - 我很可能会说，我很困惑。
答案 0 :(得分：1)
我将从您的Windows RT示例开始，Windows RT是ARM体系结构的Windows端口。它不是“专用操作系统”。有（可能）许多操作系统只能在1个体系结构上运行，但由于某种原因，这更多的功能是无法移植它们。
'端口'究竟意味着什么？
Windows有一个内核（我们在这里称之为NT，无所谓），并且NT内核有一堆需要实现的概念。这些概念是定时器，内存虚拟化，异常等......
这些概念在架构之间以不同的方式实现，因此内核和驱动程序的端口（我将忽略操作系统的其余部分，通常只是重新编译）将是使用可用的硅片实现的问题所需的概念。此实现称为“端口”。
让我们放大具有FIQ和IRQ的ARM上的中断（AKA异常）。 通常，中断可以异步发生，我的意思是在任何时候。当IRQ被断言时，CPU通常忙于做某事，因此在CPU可以使用UserContext1使用的任何资源之前，需要存储上下文（我们称之为UserContext1）。通常这意味着在使用它们之前将寄存器存储在堆栈中。 在ARM发生IRQ时，CPU将切换到IRQ模式。寄存器r13和r14有自己的IRQ模式副本，如果使用它们则需要保存 - 这就是发生的事情。那些存储到内存需要一些时间。处理IRQ，UserContext1从堆栈弹回，然后退出IRQ模式。
因此，在这种情况下，延迟可能是从IRQ断言到IRQ向量开始执行的时间。根据IRQ发生时CPU正在做什么，这将是一些设定的时钟周期数。 可以发生IRQ处理之前的延迟是从IRQ断言到CPU完成存储上下文的时间。 用户模式代码可以执行之前的延迟取决于OS / Kernel中的太多东西来解释这里，但最小的归结为从IRQ断言到恢复UserContext1 + OS上下文切换时间之后的返回时间。 / p>
FIQ - 如果你是指甲程序员，你可能只需要使用7个寄存器来完全处理你的中断服务。我提到IRQ模式有自己的2个寄存器副本，因此FIQ模式有7个寄存器的副本。是的，这是28个字节的上下文，不需要被推出到堆栈中（实际上其中一个是链接寄存器，所以你真的有6个）。这可以消除存储UserContext1然后恢复UserContext1的需要。因此，延迟可以减少达到保存/恢复所需的时间长度。
这些与操作系统无关。操作系统可以选择使用或不使用这些功能。操作系统可以选择保证执行中断处理程序的操作系统概念需要多长时间，否则可能不会。这是RTOS的基本概念之一，即关于处理程序运行多长时间的合同。 操作系统是出于某种目的而设计的（而且这个目的可能是“一般的”） - 目标设计目标对延迟的影响要大于操作系统移植到目标的许多目标。
去读一下像freertos这样的东西，而不是购买一些硬件并尝试一下。注释代码以找出您真正想要查看的延迟。这可能是让您了解它的最佳方式。
（*多CPU系统的功能相同但具有一些同步和屏障功能以及复杂性）