在您确定系统中滴答处理的优先级之前，重要的是要注意与滴答相关的延迟，正如我上一篇文章所指出的，可能并不总是在您的系统中实现周期性行为的最佳方式。您可能希望避免在某些任务中依赖滴答作响的一个原因是延迟往往会因调用而波动。如果您的系统任务之一重复调用 OSTimeDly（） 以延迟 5 个滴答声，并且您的系统的滴答声周期为 1 毫秒，则该任务不会始终保持等待状态正好 5 毫秒。在某些情况下，它可能会经历接近 4 毫秒的延迟，而在其他情况下，它可能会延迟 6 毫秒或更长时间。

在许多系统中，这种波动或抖动的原因之一是多个任务使用延迟函数。如图 1 所示，如果三个任务的延迟周期都在同一个内核节拍上到期，那么只有那些任务中最高优先级的任务会在节拍处理程序之后立即运行。随着时间的推移，较低优先级的任务将在其延迟中经历更多的抖动，因为总是存在它们无法在将它们移动到就绪状态的滴答声之后立即运行的可能性。

当然，滴答处理程序优先级的可变性是延迟波动的另一个潜在来源。在 µC/OS-III 的例子中，它预留了一个系统任务来处理滴答中断，如果这个任务被赋予了一个相对较低的优先级并且在一个高优先级任务运行时发生了一个滴答，那么内核将不会被能够处理滴答并执行任何相关的调度，直到 CPU 被高优先级任务放弃，如图 2 所示。在完全在 ISR 中处理滴答的 µC/OS-II 中，如果这ISR 的优先级相对较低，并且在执行更重要的 ISR 期间发生了滴答声。

在设置滴答优先级时，您需要牢记应用程序对波动延迟的容忍度。如果您的代码可以适应几毫秒的波动——也许是因为您将使用滴答延迟仅用于轮询用户 I/O——那么您可以选择优先级相对较低的滴答。另一方面，如果您的任务需要相当一致的延迟，那么您应该采用高优先级，并且您还应该采取措施限制使用延迟函数的任务数量。

RTOS 内核用户在配置滴答优先级和频率方面可能具有的灵活性肯定会给刚接触内核的开发人员带来一些困难。然而，通过设置刻度所涉及的权衡信息，这种灵活性成为定制多任务系统以满足各种应用程序需求的宝贵手段。我已尝试在本系列博客中提供滴答使用和配置所需的一些关键信息。