c - ISR vs main：在其中一个或另一个中运行的权衡是什么？

Question

我知道这与时间和效率有关，以及 ISR 如何从其他流程中占用时间，但我不清楚这是为什么。我总是被告知要保持 ISR 非常短。我有点困惑为什么会这样。

Answer 1

通常，当硬件设备需要与 CPU 交互时，ISR 就会出现。它们发送一个中断信号，使 CPU 离开它正在做的任何事情来服务中断。这是 ISR 必须关心的。

现在，这取决于许多因素，硬件环境和中断的性质可能是最相关的因素，但通常情况下，为了正确处理中断，ISR 会在禁用中断的情况下运行，因此它们不能被中断。这意味着 CPU 在运行 ISR 代码时不能在其他进程之间共享，因为用于运行调度程序的系统计时器中断（这是内核的一部分，负责制造 CPU 可以执行多个任务的错觉）同时执行任务）将不起作用。

因此，如果您的 ISR 花费太多时间来执行设备上的某个操作，您的系统将作为一个整体受到影响，因为 CPU 可用于其余进程的时间百分比将比平时少。这在带有 PIO 硬盘的旧系统上很明显，它会为要传输到 CPU 的每个磁盘扇区中断 CPU，并且 ISR 必须执行实际传输。如果有很多磁盘流量，您可能会注意到鼠标移动生涩（因为鼠标设备发送到 CPU 的中断未被处理）

像 Linux 这样的操作系统允许 ISR 将耗时的硬件设备操作推迟到 tasklet：一种可以与其他进程共享 CPU 时间的内核线程，同时保持硬件设备操作的原子性（操作系统确保不会超过一个小任务函数 - 用于与 ISR 关联的特定小任务 - 同时在系统中运行）。从磁盘到内核缓冲区的 PIO 传输就是这种操作的一个示例。

Answer 2

一些精度与公认的答案有关。

运行中断时不一定要禁用中断，这也不一定是内核在返回线程之前处理所有中断的原因。

有中断优先级的概念。更高优先级的中断将抢占正在运行的 ISR：如果定时器中断的优先级高于正在运行的 ISR，它将运行。但是，此时内核不会处理上下文切换，而是将它们推迟到所有排队/待处理的 ISR 都运行后。

此外，在某些处理器（例如 ARM Cortex-M3）上，处理中断的概念是处理器本身的一种操作模式。处理器在退出中断模式之前无法返回运行线程。一旦发生这种情况，所有中断都会得到充分服务：您无法返回运行 ISR。

但是所有 ISR 必须在返回线程之前完成的主要原因是内核没有 ISR 的类似线程的运行上下文的概念。因此，ISR不能挂起：它必须运行到完成。因此，ISR 会占用 CPU，除了更高优先级的中断，直到它完成其目的。

Answer 3

通常，主线程的优先级低于 ISR。根据调度程序，通常主代码将在所有挂起的 ISR 运行后执行。

在一个或多个 ISR 中包含大量计算密集型代码通常是不可取的，因为它可能会导致延迟甚至低优先级 ISR 或线程的 CPU 饥饿，如果需要执行时间关键的代码，这可能是有害的。

但是，当需要在发生中断事件时立即采取措施时，最快的方法是从相关的 ISR 执行代码（并可能为其分配高优先级）。

如果您计划使用多个执行耗时代码的中断源，则可以使用 RTOS 来允许安全高效地交错多个线程来为每个中断提供服务。