實時內核通常使用定時器或類似的周期性中斷源來為多任務應用程序實現延遲和其他有用的服務。盡管利用此類服務所需的代碼通常只涉及對內核 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（））的多任務應用程序。然而，大多數多任務系統至少包含一項可以從基于滴答的服務中受益的任務。在接下來的文章中，我將考慮兩個重要的滴答參數——頻率和優先級——對此類系統的影響。

審核編輯：郭婷