BSP(Board Support Package)学习之中断的机制

Linux流中断处理的基础

为什么需要中断

最近的微型计算机内置了一个高性能中断控制器，可以将许多中断事件传输到每个CPU核心，包括内部中断，触发内置定时器等，以及捕获外部信号变化的外部中断等。那么，到底为什么微型计算机需要中断处理呢？

如果定序器只专注于捕捉一个外部信号的变化，只需继续读取该信号，并立即执行必要的处理，如果信号发生变化，则不需要中断。以这种方式，周期性地读取信号的过程被称为轮询。如果您能够通过轮询一直专注于监控信号变化，则可以最短的时间内响应中断事件。为了充分利用这一特点，将专用CPU核心分配给捕获变化的一部分外部信号，即可在软件轮询过程中实现与专用硬件完全相同的性能。
　　但是，在现实中，CPU的核心数是有限的，一个核心必须同时并行地做很多的工作，因此，CPU有时间限制的处理优先实行的中断的结构。
　　为了在不同的环境中运行相同的应用程序，Linux也实现了处理芯片内部和外部中断事件的机制，该Linux具有抽象单个硬件规格并将其展示给应用程序的功能。

巧妙地使用诀窍确保中断处理不占用CPU

在中断实现中，重要的是在一定的限制时间内结束从中断因素发生到实际中断处理执行的延迟时间。因此，在装有RTOS的嵌入式设备中，一般在中断处理程序中完成中断处理。
　　通常，在中断处理程序执行期间，中断禁止模式不接受另一个中断。当中断处理长时间占用CPU时，通常的主程序几乎不再运行。如果是简单的内置设备，这样的实现也可以取得一致性，但是在Linux的情况下，以多用户为前提，有陌生人独占CPU资源的风险，所以在中断处理内长时间禁止其他中断的处理是不可取的。

从硬件中断到告诉应用程序的路

应用程序不能直接知道有中断

Linux在控制物理硬件的内核空间和运行应用程序的用户空间之间提供了清晰的边界。这是为了实现即使在不同的硬件环境下也能由相同的应用程序执行的虚拟硬件环境。单个应用程序关闭并运行在称为进程的独立虚拟内存空间中。这里的问题是中断事件不能直接通知用户空间。

中断传递到应用程序的流程：key入力

以应用程序接受键输入事件为例进行说明。在内核空间中放置一个捕获键输入中断的设备驱动程序，并在发生中断事件时通知您的应用程序。与像RTOS一样简单地直接在中断处理程序中处理的结构相比，Linux的中断处理是一个绕远而复杂的结构。键入事件到达应用程序的路径可以分解和思考如下：

1. 键值输入。
2. 内核空间的键入力中断处理程序启动。
3. 将键入力信息通知用户空间应用程序。
4. 等待这个事件的应用程序等到启动为止。
5. 用户空间应用程序内的处理。
6. 进一步从应用程序启动对应于键输入的处理，例如显示更新。
7. 键输入结果可以在屏幕上确认

中断处理所需的时间

中断响应延迟时间①

①是从CPU捕获中断到相应的中断处理程序启动的时间。
在禁止中断的情况下，可能会在这里等待。

中断处理程序处理时间②

②是处理实际中断处理程序所需的时间。在RTOS中，在处理程序中执行诸如网络数据包接收之类的重处理，但是在Linux中，处理程序本身实现为在短时间内完成。

调度程序处理时间③

③是调度程序处理本身所需的时间。调度程序是决定在Linux内核中运行下一个程序的过程。在运行许多程序时，调度程序顺序确定的处理本身可能会变得相当沉重。但是，实现在最近的内核中的调度器被设计成使得即使程序的数量增加，判断处理时间也不会以指数函数增加。在多核CPU的情况下，独立的调度器处理会移动核心的数量。查看名为/proc/interrupt的虚拟文件，您可以查看每个CPU核心收到的中断数量。这是一种有用的信息，可以很容易地检查哪些中断发生在任何频率，哪些核心正在处理中断等。图5显示了在4核Linux PC上运行cat/proc/interrupts的示例。

可以认为②和③之间几乎没有时间间隔

在②和③之间只有一点时间，但你可以认为这个延迟几乎是没有的。在从中断处理返回的时间，调度程序处理总是被调用。

调度程序延迟时间④

④的延迟时间是从中断处理程序的处理完成到等待事件的应用程序启动的延迟。Linux应用程序将被困在一个名为进程的虚拟CPU环境中运行。进程中的程序以进一步划分的并行可执行线程为单位在调度器中注册。调度程序优化执行顺序，以便每个线程都可以公平运行。但是，不一定会立即执行中断事件的处理。这种等待调度器授予执行权的时间被称为调度延迟。