滴答處理程序不是調(diào)度程序

實(shí)時(shí)內(nèi)核通常使用定時(shí)器或類似的周期性中斷源來為多任務(wù)應(yīng)用程序?qū)崿F(xiàn)延遲和其他有用的服務(wù)。盡管利用此類服務(wù)所需的代碼通常只涉及對內(nèi)核 API 函數(shù)的調(diào)用，但似乎周期性中斷（或俗稱的滴答聲）已成為混淆甚至爭論的主要來源。內(nèi)核用戶。

新內(nèi)核用戶之間的一個常見誤解是滴答處理程序是內(nèi)核的任務(wù)調(diào)度程序。換句話說，滴答中斷被認(rèn)為是可以使任務(wù)運(yùn)行的唯一機(jī)制?，F(xiàn)實(shí)情況是，在搶占式、基于優(yōu)先級的內(nèi)核中，服務(wù)滴答的代碼是可能導(dǎo)致 CPU 控制權(quán)從一個任務(wù)傳遞到另一個任務(wù)的眾多代碼之一。在此類內(nèi)核中，任何中斷通常都可能導(dǎo)致新任務(wù)運(yùn)行，如圖 1 所示，涉及 UART 中斷。此外，任務(wù)本身可能有多種方式來放棄 CPU 并進(jìn)入掛起或等待狀態(tài)。

當(dāng)任務(wù)需要能夠控制它在等待狀態(tài)中花費(fèi)的時(shí)間量時(shí)，滴答中斷就變得必要了。例如，μC/OS-II 和 μC/OS-III 操作系統(tǒng)提供了一種方法來控制超時(shí)參數(shù)，這些參數(shù)指定非滴答事件的最大等待時(shí)間（例如接收 UART 字符），并通過延時(shí)函數(shù)，如 OSTimeDly（）。

圖 2 基于 μC/OS-II，突出顯示滴答中斷在實(shí)現(xiàn) OSTimeDly（） 中的作用。在圖的左側(cè)，一個相對高優(yōu)先級的任務(wù)調(diào)用 OSTimeDly（） 來產(chǎn)生一個 5 個滴答的延遲，導(dǎo)致內(nèi)核在與該任務(wù)關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)中初始化一個延遲字段，并將該任務(wù)移出允許另一個任務(wù)運(yùn)行的就緒狀態(tài)。延遲字段被初始化為值 5，并且在調(diào)用 OSTimeDly（） 之后的每個滴答中斷中，該字段遞減。在調(diào)用后的第五次中斷時(shí)，該字段達(dá)到 0，并且內(nèi)核的滴答處理程序（在 μC/OS-II 中是 ISR 的一部分，但在 μC/OS-III 中有自己的任務(wù)）使高優(yōu)先級任務(wù)準(zhǔn)備好再次運(yùn)行。然后，該任務(wù)將獲得 CPU 控制權(quán)，因?yàn)樗膬?yōu)先級超過了在第五個滴答發(fā)生時(shí)正在運(yùn)行的任務(wù)的優(yōu)先級。

從技術(shù)上講，可以編寫一個沒有超時(shí)和延遲函數(shù)（如 OSTimeDly（））的多任務(wù)應(yīng)用程序。然而，大多數(shù)多任務(wù)系統(tǒng)至少包含一項(xiàng)可以從基于滴答的服務(wù)中受益的任務(wù)。在接下來的文章中，我將考慮兩個重要的滴答參數(shù)——頻率和優(yōu)先級——對此類系統(tǒng)的影響。

審核編輯：郭婷