近年來，實時操作系統 (RTOS) 非常流行。大多數嵌入式開發工程師會在設計周期的早期選擇 RTOS，有時甚至在需求確定之前。RTOS 的一個有趣之處在于，對于許多基于 MCU 的應用程序來說，RTOS 是多余的。當應用程序需要任務搶占(暫時掛起任務以切換到更高優先級的任務并稍后恢復)并且具有嚴格的實時要求時，RTOS 的魔力才真正發揮作用。在很多情況下，一個更簡單的協作調度器也能輕松滿足要求。

　　協作調度器仍然允許通過使用后臺周期性定時器來調度任務，該定時器創建系統滴答，就像在RTOS中一樣。不同之處在于，協作調度器不具有優先級和搶占權，而是只執行在某個時間周期間隔發生的任務。如果兩個任務同時運行，任務列表中位置較高的任務首先運行，然后是第二個任務，依此類推。協作調度器允許軟實時行為，但是通過使用中斷和其他機制也可以滿足硬實時需求。

　　使用協作調度器的一個很大的優點是，與RTOS相比，它們相當簡單和直接。調試RTOS可能極其復雜，而且通常非常痛苦。另一方面，協作式調度器只有很少的幾個部分，并且更容易調試。事實上，只需幾個簡單的步驟就可以設計和實現一個協作調度器。它們也使用很少的閃存和RAM。

　　步驟1——定義調度器要求

　　嵌入式開發人員在寫任何代碼之前，了解將要寫的到底是什么是一個好主意。這通常意味著查閱項目需求文檔并理解需要什么。對于協作調度器，應該記住一些基本要求:

　　調度器應使用單一中斷驅動定時器來跟蹤系統時間

　　應編寫調度器，以便可以從一個項目到下一個項目重復使用

　　調度器應能夠調度周期性和后臺任務

　　調度器應易于通過使用配置表進行配置

　　步驟2——創建軟件架構

　　當開發可重用軟件時，實現一個好的軟件架構是至關重要的。當談到將在多種類型的硬件上使用的調度器時，分層的體系結構可能是永遠重用的代碼和在第一個項目后丟棄的代碼之間的區別。創建一個由硬件相關代碼的驅動程序層、調度器核心的應用層和配置應用程序的配置層組成的架構，效果非常好!

　　步驟3——定義任務的組成部分

　　為了正確運行周期性任務，調度器至少需要三條信息;任務連續運行之間的時間間隔、任務最后一次執行的系統節拍以及任務到期時應該執行的功能。有了這些信息，嵌入式開發人員就有可能定義一個C結構，用來定義處理器必須執行的每個任務。

　　步驟4–任務配置表

　　一旦定義了TaskType結構，現在就可以創建一個TaskType數組，數組中的每個元素定義一個任務。對于小型應用，該表相對較短。Tasks數組應該定義為一個靜態變量，如果可能的話，應該定義為const，這將有助于確保任務定義在程序執行期間不會改變。

　　步驟5——第一個任務功能

　　在進一步開發調度程序之前，最好確保任務配置表中定義的任務已經定義。這將有助于防止編譯器因為函數沒有被定義而生氣。任務本身可以全部存儲在一個模塊中，或者按照作者的喜好存儲在單獨的模塊中。任務函數的定義就像任何其他C函數一樣。

　　步驟6——一些支持配置功能

　　此時，幾乎所有與任務配置相關的東西都已經設置好了，準備就緒。唯一缺少的是調度器遍歷配置表所需的兩個輔助函數。第一個，*Tsk_GetConfig，是一個函數，它返回一個指向 Tasks[] 配置表的指針。這將允許調度程序訪問表結構。第二個，Tsk_GetNumTasks，是一個函數，它返回存儲在配置表中的任務數。這兩個函數之所以存在，是因為使用了良好的數據封裝編程實踐。該信息僅限于模塊范圍，嵌入式開發人員使用調度器需要這兩個輔助函數來訪問數據。

　　第7步——調度器的誕生

　　最后，所有部分都準備就緒，可以編寫程序的實際調度器部分。協作調度器的調度算法通常直接寫在 main 函數中。調度器通過創建指向任務配置表的指針來初始化，還會檢索表中的任務數。

　　有了這兩條信息，主循環將從檢索當前系統節拍開始。在32位系統中，這是微不足道的工作，因為32位刻度變量的讀寫是原子性的。接下來，循環檢查任務配置表中存在的每個任務條目。如果任務的間隔設置為0(一個不斷運行的后臺任務)，則執行該任務。另一方面，如果間隔不為0，則執行一些數學運算來確定任務運行的最后時間和當前時間之間的差是否大于或等于任務間隔。如果是，那么任務將被執行。

　　結論

　　可以看出，協作調度器的實現非常簡單直接。沒有多少移動部件，一旦構建了調度器，如果做得好，它可以從一個項目重用到下一個項目。嵌入式開發人員唯一需要更改的是系統滴答計時器，然后是任務配置表。雖然這樣一個簡單的調度器并沒有配備當今RTOS的所有花里胡哨，但這個簡單的調度器實際上適用于多少應用程序確實令人驚訝。