在您確定系統中滴答處理的優先級之前，重要的是要注意與滴答相關的延遲，正如我上一篇文章所指出的，可能并不總是在您的系統中實現周期性行為的最佳方式。您可能希望避免在某些任務中依賴滴答作響的一個原因是延遲往往會因調用而波動。如果您的系統任務之一重復調用 OSTimeDly（） 以延遲 5 個滴答聲，并且您的系統的滴答聲周期為 1 毫秒，則該任務不會始終保持等待狀態正好 5 毫秒。在某些情況下，它可能會經歷接近 4 毫秒的延遲，而在其他情況下，它可能會延遲 6 毫秒或更長時間。

在許多系統中，這種波動或抖動的原因之一是多個任務使用延遲函數。如圖 1 所示，如果三個任務的延遲周期都在同一個內核節拍上到期，那么只有那些任務中最高優先級的任務會在節拍處理程序之后立即運行。隨著時間的推移，較低優先級的任務將在其延遲中經歷更多的抖動，因為總是存在它們無法在將它們移動到就緒狀態的滴答聲之后立即運行的可能性。

當然，滴答處理程序優先級的可變性是延遲波動的另一個潛在來源。在 μC/OS-III 的例子中，它預留了一個系統任務來處理滴答中斷，如果這個任務被賦予了一個相對較低的優先級并且在一個高優先級任務運行時發生了一個滴答，那么內核將不會被能夠處理滴答并執行任何相關的調度，直到 CPU 被高優先級任務放棄，如圖 2 所示。在完全在 ISR 中處理滴答的 μC/OS-II 中，如果這ISR 的優先級相對較低，并且在執行更重要的 ISR 期間發生了滴答聲。

在設置滴答優先級時，您需要牢記應用程序對波動延遲的容忍度。如果您的代碼可以適應幾毫秒的波動——也許是因為您將使用滴答延遲僅用于輪詢用戶 I/O——那么您可以選擇優先級相對較低的滴答。另一方面，如果您的任務需要相當一致的延遲，那么您應該采用高優先級，并且您還應該采取措施限制使用延遲函數的任務數量。

RTOS 內核用戶在配置滴答優先級和頻率方面可能具有的靈活性肯定會給剛接觸內核的開發人員帶來一些困難。然而，通過設置刻度所涉及的權衡信息，這種靈活性成為定制多任務系統以滿足各種應用程序需求的寶貴手段。我已嘗試在本系列博客中提供滴答使用和配置所需的一些關鍵信息。

審核編輯：郭婷