AUTOSAR 中断处理说明（Explanation of Interrupt Handling within AUTOSAR）

1 介绍与文档目的（Introduction and purpose of document）

本文档阐述了中断在 AUTOSAR 中的工作方式及其配置方法。文档的目的是为那些以某种方式与中断交互的模块规范工作提供指导。

2 缩略语与术语（Acronyms and abbreviations）

3 相关文档（Related documentation）

3.1 输入文档

无。

3.2 相关标准与规范

无。

4 中断配置概述（Summary of Interrupt Configuration）

本章总结了中断所需的配置参数及其所在模块（即哪个模块负责）。本总结是从 ECU 配置的角度出发，假定某个具有 ECU 高层视图的系统配置编辑器负责将参数值放入 ECU 配置。

注意：上表中未包含时序信息。原因在于目前尚无时序模型，因此尚不清楚 BSW 调度器如何被配置为使用除"中断使能/禁止"以外的方式来处理临界区。

注意：本文档引用了 BSW 调度器。虽然 BSW 调度器已并入 RTE，但本文的论述仍然有效。

5 中断操作概述（Overview of Interrupt Operation）

本概述首先解释处理中断所涉及的步骤，然后将这些步骤映射到所涉及的不同 BSW 模块。

5.1 Cat1 与 Cat2 中断的区别（Distinction between cat1 and cat2 interrupts）

Cat1 和 Cat2 中断之间存在显著差异，详见下表：

ISR(Can_tx) {
  /* some code */
}

6 中断操作的步骤（Steps in the operation of interrupts）

由于 Cat1 和 Cat2 中断之间存在显著差异，它们在 OS 和应用代码中的处理方式非常不同。本节给出处理方式的概述。

我们将分别讨论中断发生前需要建立的状态，以及由谁来负责建立该状态。

6.1 Cat1 中断的处理（Handling cat1 interrupts）

6.1.1 初始状态（Initial state）

需要设置中断的向量表条目，使其指向中断处理程序。

对于 Cat1 中断，该设置与目标相关。AUTOSAR OS 的某些实现可能支持设置向量表，其他则不支持。在 OS 不支持的情况下，需要采用其他方法，例如编译器指令或修改向量表。

中断处理程序应当被正确声明。通常编译器对此提供支持，例如：

__interrupt Can_tx() {
   /* some user application code */
}

但有时编译器不支持，且不同编译器之间的语法和语义会变化。因此可能需要提供特定于处理器和编译器的支持来声明 Cat1 处理程序。

处理器的中断逻辑应当被设置为可请求中断。Cat1 情况下通常没有 OS 支持，因此需要按目标逐一执行。

产生中断的设备应当被设置为在所需条件下产生中断。Cat1 和 Cat2 都需要此设置，通常是设备驱动的一部分（即在用户域内）。

6.1.2 硬件请求中断时（When the hardware requests an interrupt）

以下是从设备请求中断到返回被中断线程所发生的一系列步骤：

图：Cat1 InterruptHandler 逻辑
设备 → IRQ → 中断逻辑 → IRQ → 中断分发（CPU/MCU）→ 中断帧入口 → 用户代码 → 中断帧出口。

6.2 Cat2 中断的处理（Handling cat2 interrupts）

Cat2 中断提供了比 Cat1 中断更高层次的抽象，但运行时开销更高，且占用 OS 更多的 RAM 和 ROM。

6.2.1 初始状态（Initial state）

处理器的中断向量表条目应当设置为指向 OS。Cat2 中断的该设置由 OS 的代码生成器完成。

中断处理程序应当被正确声明。AUTOSAR 中定义为：

ISR(Can_tx) {
     /* some user application code */
}

ISR 宏可能会导致中断发生时进入 OS，也可能不会。但该宏的核心是封装一个 Cat2 中断处理程序。因此 ISR 展开得到的代码是实现细节。

处理器的中断逻辑应当被设置为可请求中断。Cat2 情况下由 OS 处理。

产生中断的设备应当被设置为在所需条件下产生中断。Cat1 和 Cat2 都需要此设置，通常是设备驱动的一部分。

6.2.2 硬件请求中断时（When the hardware requests an interrupt）

Cat2 中断所需的 CPU 行为与 Cat1 相同，大多数其他方面则不同。

图：Cat2 ISR 逻辑
设备 → IRQ → 中断逻辑 → IRQ → 中断分发（CPU/MCU）→ 中断帧入口 → OS 调用 → 用户代码 → 任务分发 → 中断帧出口。

7 中断的配置（Configuration of Interrupts）

第 5 章中讨论了处理中断的以下参与方：

• 设备驱动
• OS
• BSW 调度器
• 未配置项

下面将分别讨论 Cat1 和 Cat2 情况下每个参与方的配置问题。

7.1 设备驱动的配置与代码（Device Driver configuration and code）

每个设备驱动都需要包含中断处理程序的代码，即设备驱动的作者必须将中断处理程序的代码作为设备驱动实现的一部分来编写。但 Cat1 和 Cat2 情况下的代码不同。

Cat2 ISR 是最简单的情况，因为有 OS 支持。代码基于以下模板：

ISR(<name>) {
      <user code to handle ISR>
      <user code to dismiss interrupt>
}

<name> 必须与 OS 配置中选择的名称一致。

Cat1 中断处理程序较为麻烦，因为没有 OS 支持。典型模板为：

<some target specific preamble to mark this function as an interrupt handler>
<name>() {
     <user code to handle ISR>
     <user code to set up interrupt controller>
     <user code to dismiss interrupt>
}

然而，所需的精确代码非常依赖于处理器和编译器，不可移植。这可能不是问题，因为设备驱动本身的可移植性也较差。

编写处理程序是设备驱动作者的责任，特别是在 Cat1 情况下，必须确保与中断控制器的正确交互。¹

¹ 根据作者的经验，这种交互很难正确实现，预计将成为 bug 来源。

7.1.1 中断处理程序的放置（Placement of Interrupt Handlers）

类别 1 中断处理程序被使用是因为它们具有最快的响应时间。因此，任何使类别 1 中断变慢的做法都是适得其反的。所以类别 1 中断处理程序应当位于该中断设备的驱动中。

类别 2 处理程序较慢，因此在其放置位置上可以有更多余地。然而，将它们放在类别 1 处理程序之外的位置会成倍增加复杂度，却没有实际收益。

因此类别 2 中断处理程序也应当位于该中断设备的驱动中——在 BSW 调度器或其他位置没有"thunk"。此处的"thunk"是指 BSW 调度器中的一小段代码，仅用于调用设备驱动中的真正处理程序。

7.2 OS 配置（OS configuration）

为了正确配置中断，OS 需要知道一些相当复杂的信息。在 Cat1 和 Cat2 情况下，都必须知道：

• 中断向量
• 中断优先级
• 中断处理程序的 <name>
• 类别

在某些目标上，一个参数会限制另一个参数的取值范围。例如在 TriCore 上，向量隐含优先级。因此并非所有"向量、优先级、类别"的组合都合法。

中断处理程序的 <name> 可以由配置 OS 的人或配置设备驱动的人来设置。其实由谁起名并不重要，只要在 OS 配置和设备驱动中使用相同的名称即可。

设置向量、优先级和类别则更有意思。²

OS 配置中选择的类别（Cat1 或 Cat2）必须与驱动和接口中选择的实现策略一致。对于"validator 2"风格的配置³，编写配置的人必须确保驱动、接口和 OS 类别中的实现策略相互一致。

² 特别是 AUTOSAR XML 尚无用于向量或优先级的参数。
³ 即所有模块均手动配置，没有自动的跨模块检查或一致性检查。

从长远来看，更好的做法是提供一些自动支持。例如，每个模块的 XML 描述了允许哪些类别，配置则捕获实际使用的类别。这将使自动代码生成成为可能。

因此对于 validator 2 来说，GCE 和操作员基于 BSW 模块实现的信息手动选择类别，可能是足够的。

设置向量和优先级在 validator 2 中也是手动的（即通过 GCE）。但同样，从长远来看，需要一些自动辅助。

通常类别、向量、优先级之间存在一定的依赖关系⁴。GCE 不检查这些依赖关系，因此必须由 GCE 的使用者结合 OS 手册进行检查。

⁴ 许多实现要求 Cat1 中断的优先级高于所有 Cat2 中断。

从中期来看，可以预期这些依赖关系知识会被构建到更高级的创作工具中，从而由创作工具保证正确的关系。

因此优先级和向量也是 OS 的配置项。

OS 提供的 RESOURCE 也必须被指定。为了使 RESOURCE 正确工作，OS 必须知道引用每个 RESOURCE 的所有对象（TASK 和 ISR）⁵。BSW 调度器负责处理临界区，因此逻辑上也负责配置 OS。但 BSW 调度器需要知道每个 BSW 模块需要哪些临界区。

⁵ 如果 OS 未正确获取所有这些信息，临界区将产生难以排查的 bug。

对于"挂起和恢复所有中断"的调用，不需要额外的 OS 配置。

7.3 BSW 调度器配置（BSW Scheduler configuration）

BSW 调度器有两个目的：

1. 提供一个 TASK 调用 BSW 主函数；
2. 提供负责锁定临界区的代码。因此临界区仅通过 BSW 调度器实现。

下面讨论这两个方面的配置。本讨论很大程度上依赖于作者对通信栈的经验。

作者还假设 BSW 调度器将被编写成尝试使用最合适的方法来保护临界区。⁶

⁶ 详情见 [1]。

7.3.1 主函数的 TASK（TASK for main functions）

BSW 调度器的配置需要知道调用哪些主函数以及调用顺序。通常 BSW 调度器的代码生成器会生成按顺序调用主函数的代码。例如（虚构的合理名称）：

void Run_com_stack() {
      canif_main_rx();
      linif_main_rx();
      frif_main_rx();
      pdur_main_rx();
      pdumux_main_rx();
      com_main_rx();
      com_main_gw();
      com_main_tx();
      etc…
      TerminateTask();
}

这意味着 BSW 调度器需要知道包含主函数的 TASK，以便通知 OS 配置正确地配置 RESOURCE。BSW 调度器还需要知道 BSW 模块之间的控制流以及所引用的临界区。BSW 调度器需要能够从其配置数据中找到这些信息。

7.3.2 栈中的其他 TASK（Other TASKs in the stack）

通常，BSW 模块也会从主函数以外的控制流进入。因此同样值得关注的是 BSW 从 RTE 进入的上下文。这是因为 RTE 的 TASK（或其多个 TASK 之一）最终也会访问一个临界区，并因此调用 BSW 调度器。因此 RTE 的 TASK（或 TASK）需要被添加到引用 RESOURCE 的列表中。

所有进入 BSW 的此类控制流必须被识别，并用于配置 BSW 调度器，进而配置 OS。

7.3.3 临界区（Critical sections）

本章包含 3 个子节。前两个子节讨论两类中断处理程序中临界区的问题。最后一个子节讨论 BSW 调度器中临界区的实现。前两个子节描述中断处理程序面临的问题，第三个子节描述 BSW 调度器如何帮助解决这些问题。

7.3.3.1 类别 1 处理程序中的互斥（Mutual exclusion in category 1 handlers）

1. 假设有一个 Cat1 中断 C1 和某个其他线程（TASK 或中断）T1。
2. 假设 priority(C1) > priority(T1)。

假设 2 意味着：当 C1 运行时 T1 不能抢占，而 T1 运行时 C1 可以抢占。因此必须在 T1 中放置保护。典型做法是用匹配的 SuspendAllInterrupts 和 ResumeAllInterrupts 调用包含临界区。

对应的情况是：

3. 假设 priority(C1) < priority(T1)。

在这种情况下，T1 必须是另一个 Cat1 中断（即不能是其他任何东西），因此保护临界区的责任在 C1 一方。我们假设 AUTOSAR 中没有这种用例。不过，为了完整性，我们描述这种情况下的相关问题。

代码与配置之间的依赖关系必须保证一致。可以通过两种方式实现：

• 手动：在驱动中放入 suspend 和 resume 调用，开销低，但出错的概率高；
• 自动：使用 BSW 调度器模块，将 suspend 和 resume 调用放入 BSW 调度器中，并在驱动中调用 BSW 调度器。这样开销更高，但出错概率低。

我们建议由 BSW 调度器处理此问题，即采用自动方式。因此 BSW 调度器的配置必须知道一个中断处理程序的类别。

7.3.3.2 类别 2 处理程序中的互斥（Mutual exclusion in category 2 handlers）

为实现 TASK 与 Cat2 ISR 之间的互斥，可使用 OS RESOURCE。也可以使用中断锁定，并将一并讨论。RESOURCE 在 TASK/ISR、ISR/ISR 两种交叉情况下均有效。

关闭中断也可用于互斥。如果两个 ISR 优先级相同，则不需要互斥，因为它们不能同时运行。

在用户代码中，临界区由调用 BSW 调度器进入和离开临界区。在 BSW 调度器中，这些进入/离开调用被解析为资源加锁/解锁调用或中断挂起/恢复调用。选择由 BSW 调度器的配置算法决定。但无论做出何种决定，BSW 调度器都需要有正确的信息来做出决定，并且还必须将任何额外的配置对象通知 OS。

7.3.3.3 BSW 调度器中的临界区（Critical sections in the BSW Scheduler）

在 BSW 调度器中，临界区通常以以下两种方式之一实现：

• 挂起/恢复 或 使能/禁止 中断
• RESOURCE

从配置的角度看，这是一个重要观点。为了保护临界区，BSW 调度器可以简单地挂起/恢复所有中断以进入/离开临界区。这非常容易配置，几乎不需要了解应用行为（即不需要额外的 RESOURCE，因此不需要知道哪些 TASK/ISR 引用它们）。然而，如果临界区中停留的时间较长，这可能导致非常长的高优先级阻塞时间。

更好的 BSW 调度器将使用 RESOURCE，从而减少高优先级阻塞的时间。但这需要多得多的信息。在上述讨论中，我们试图识别这些信息的来源。

另一种解决方案是将所有东西设为 Cat2 ISR 或 TASK。然后可以使用 OS Suspend/Resume Interrupts。这种方式不需要知道哪个 BSW 需要哪个 RESOURCE，但会在每个临界区阻塞所有 TASK 和 Cat2 ISR。

哪种方案最合适取决于许多 BSW 软件部分的时序数据和时序模型。目前这两者都不存在。

如果使用 BSW 调度器来解耦 Cat1 中断（见第 8 章），则只允许使用"suspend/resume 所有中断"。

7.3.4 小结（Summary）

BSW 调度器的配置是个难题。以最简单方式（suspend/resume 中断）配置很简单，但存在显著的缺点，例如高优先级阻塞时间长。更好的配置（RESOURCE）需要在 BSW 调度器中放入大量信息，然后传递给 OS。这些信息如何获取尚不清楚。

8 Cat1 中断的使用建议（Recommendations for the use of cat1 interrupts）

大多数设备驱动能够使用 Cat2 ISR，并且应当将 Cat2 ISR 作为处理中断的首选方法。

Cat1 中断应当仅在以下有限场景中使用：

• 当中断到达率导致 OS 中 Cat2 包装器的开销不可接受时；
• 当中断延迟必须非常低，以至于 Cat2 ISR 不够快时；
• 当所定义的中断处理程序需要低抖动（jitter）时。

当驱动中使用 Cat1 中断时，应当尽快解耦。最晚应位于驱动之上的紧邻层。

8.1.1 使用 Cat1 中断的相邻模块通信（Communication between adjacent modules using cat1 interrupts）

将 Cat1 中断传播到驱动之外太远是个问题，因为这意味着对于临界区，栈的大量部分（内存、通信等）需要知道 Cat1 中断，且阻塞时间会很长。

Cat1 中断的长时间阻塞尤为令人担忧，因为所有中断都会被阻塞，而不仅仅是其中一部分。

因此 Cat1 中断应当尽快解耦。实际工作方式如下：下图显示了两个相邻模块：处理 Cat1 中断的驱动和接口。

图：Cat1 中断相邻模块

  Upper layer
      ↕
  Interface
      ↕ (通过 buffer / Main function)
  Driver
      ↕ interrupt
  Hardware
  

当上层想要向下发送数据时，它向接口请求。接口通过 BSW 调度器挂起所有中断来锁定缓冲区，将数据复制到缓冲区或直接复制到驱动中，然后通过 BSW 调度器恢复中断。

当驱动通过中断接收到数据时，驱动会请求接口对数据进行缓冲，然后退出。这最大限度地减少了在 Cat1 优先级停留的时间。在稍后的某个时间点运行主函数。它会锁定 Cat1 中断，然后通过调用上层将数据从缓冲区向上复制。

如果复制到上层的数据较多，可能需要将主函数编写为一系列小临界区。例如，下面的代码展示了一个大临界区：

Suspend interrupts();
While data in buffers {
      Copy single buffer
}
Resume interrupts();

这是最小、最快的实现，但阻塞时间最长。类似的实现是：

While data in buffers {
      Suspend interrupts();
      Copy single buffer
      Resume interrupts();
}

这种方式效率较低，但阻塞时间更短，因此不太可能延迟快速发生的 Cat1 中断。

8.1.2 信任（Trust）

OS 的时间与空间保护被规范化以支持不受信任的代码，目的是检测并防止时间或空间的越界。但这些检查不能为 Cat1 中断实现。因此所有 Cat1 中断处理程序必须是受信任的。

然而，情况比上一段所述还要糟糕。任何通过"挂起所有中断"来锁定所有中断的代码，也会阻止监控执行时间的定时器中断。因此，任何即使在其不知情的情况下（即这是 BSW 调度器的决策）锁定所有中断的模块，都必须是受信任的。

其结果是：简单的 BSW 调度器实现（仅使用"关闭中断"实现互斥）意味着在该 ECU 中所有 BSW 模块都必须是受信任的。