滴答处理程序不是调度程序

实时内核通常使用定时器或类似的周期性中断源来为多任务应用程序实现延迟和其他有用的服务。尽管利用此类服务所需的代码通常只涉及对内核 API 函数的调用，但似乎周期性中断（或俗称的滴答声）已成为混淆甚至争论的主要来源。内核用户。

新内核用户之间的一个常见误解是滴答处理程序是内核的任务调度程序。换句话说，滴答中断被认为是可以使任务运行的唯一机制。现实情况是，在抢占式、基于优先级的内核中，服务滴答的代码是可能导致 CPU 控制权从一个任务传递到另一个任务的众多代码之一。在此类内核中，任何中断通常都可能导致新任务运行，如图 1 所示，涉及 UART 中断。此外，任务本身可能有多种方式来放弃 CPU 并进入挂起或等待状态。

当任务需要能够控制它在等待状态中花费的时间量时，滴答中断就变得必要了。例如，µC/OS-II 和 µC/OS-III 操作系统提供了一种方法来控制超时参数，这些参数指定非滴答事件的最大等待时间（例如接收 UART 字符），并通过延时函数，如 OSTimeDly（）。

图 2 基于 µC/OS-II，突出显示滴答中断在实现 OSTimeDly（） 中的作用。在图的左侧，一个相对高优先级的任务调用 OSTimeDly（） 来产生一个 5 个滴答的延迟，导致内核在与该任务关联的数据结构中初始化一个延迟字段，并将该任务移出允许另一个任务运行的就绪状态。延迟字段被初始化为值 5，并且在调用 OSTimeDly（） 之后的每个滴答中断中，该字段递减。在调用后的第五次中断时，该字段达到 0，并且内核的滴答处理程序（在 µC/OS-II 中是 ISR 的一部分，但在 µC/OS-III 中有自己的任务）使高优先级任务准备好再次运行。然后，该任务将获得 CPU 控制权，因为它的优先级超过了在第五个滴答发生时正在运行的任务的优先级。

从技术上讲，可以编写一个没有超时和延迟函数（如 OSTimeDly（））的多任务应用程序。然而，大多数多任务系统至少包含一项可以从基于滴答的服务中受益的任务。在接下来的文章中，我将考虑两个重要的滴答参数——频率和优先级——对此类系统的影响。

审核编辑：郭婷