|
uC/OS-II是最早進入國內的一款開源RTOS，因為代碼開源，又有配套的書籍，加上不大的代碼量，在嵌入式群體中最為流行。在寫“實用單片機系統”第一版之后，就接觸了uC/OS-II，雖然大致的明白其工作原理，但一直似懂非懂，尤其有太多的宏定義，嚴重的干擾了源碼的閱讀，加上RTOS帶來太多的概念，而這些概念都沒有實際用過，不知道如何應用，并且聽說有很多陷阱，所以心里有些空，把握不住風險，一直都回避RTOS。高頻機開發的后期，菜單界面編程的復雜性嚴重的干擾了業務邏輯，逼迫我設計msOS的時候，考慮把業務邏輯與菜單界面分離開，這必須要引入RTOS，而uC/OS-II因為廣為人知又相對簡單一些，所以選擇了uC/OS-II。 這一次正式選用uC/OS-II，必須要深入理解透徹每一個細節，否則因為自己對uC/OS-II的理解不到位，尤其是任務之間的通訊等細節問題引起的缺陷可能讓自己的項目失敗，這是不可接受的，所以參考書籍仔細的閱讀源碼，然而一接觸這個源碼，就讓我犯暈，uC/OS-II為了實現可配置、可裁減，運用了大量的宏定義，考慮到各種情況，這嚴重的干擾了我的閱讀，同時也有很多網友向我反應類似的問題，因為要了解uC/OS-II的核心原理，卻經常被很多沒用的源碼干擾，他們迫切需要一份簡單、清晰的源碼，于是我決定先弄出一份可以清晰閱讀的源碼來。 第一步，去掉了絕大部分跟內核無關的事件管理功能，比如信號量、互斥型信號量、事件標志組、消息郵箱、內存管理這幾個功能，只保留了msOS今后需要用到的時間管理、消息隊列功能，這樣一來，幾乎就剩下內核部分源碼，閱讀大大簡化了，系統基本上沒有什么宏定義了，下圖為uC/OS-II的頭文件，非常簡單，只需要定義三個宏定義：任務數、事件數和消息隊列數，對于msOS來說，默認就是2、1、1，模式化了，不需要改變。 第二步，進一步去掉用不上的功能函數，比如時間管理中只保留OSTimeDly函數，消息隊列中只保留創建隊列、發送消息、等待消息三個必須要用的函數。任務管理中只保留了普通的創建任務函數，其它的刪除任務，掛起任務等都刪除了，因為msOS中不可能用到刪除任務，掛起任務這些函數，放著除了干擾我之外，沒有別的作用。這樣一來，基本上就沒有多少宏定義了，代碼較容易看懂了，下圖為前兩步精簡后的uC/OS-II接口函數。 第三步，因為能夠看懂代碼，就越覺得msOS不需要uC/OS-II這么多復雜的功能，比如msOS一般來說只需要兩個任務即可，uC/OS-II卻支持64個任務，因為支持64個任務，需要一個8*8bit的就緒表，為了實現快速查找最高優先級任務，需要一個算法和一個256字節的查找表，雖然這些不是很復雜，但卻把很多人搞的稀里糊涂的，比較繞，嚴重的干擾了內核的閱讀理解，所以要降低任務，只需要支持8個即可，對于msOS來說，8個都已經太多了，完全滿足了，而實際的項目，一般都是幾個任務即可，不建議大家開太多的任務，這樣嚴重影響效率，并且各個任務之間通訊，訪問資源等都容易引起很多沖突，理解不準確會導致一系列問題。 下圖為msOS雙任務查找表，數組中只有4個數據。實際上因為msOS只有兩個任務，MenuTask是永恒最低任務存在，只要LogicTask激活，就馬上執行LogicTask，處理完后再退到MenuTask，所以只需要識別LogicTask即可，根本不需要算法中的查找表，只是為了保留與uC/OS-II統一，預留擴展8個任務，所以還保留了任務查找表風格。 第四步，因為只有8個任務，而uC/OS-II默認有兩個內部任務：統計任務與空閑任務，所以需要去掉這兩個任務，msOS中必須要有業務邏輯與菜單界面兩個任務，優先級最低的任務是菜單界面，這樣還有6個任務可以供額外使用，6個已經足夠了，非特別情況下，不建議用。 第五步，uC/OS-II的任務塊和事件塊是采用鏈表結構的，可以動態增刪，但這一點對于絕大部分項目來說，沒有意義，尤其是對msOS來說，根本就不需要動態的，于是把鏈表結構改成數組結構，這樣非常容易看懂，也節省資源。 第六步，按C#語言風格標準化，跟msOS統一編程風格。 通過以上六步操作操作之后，uC/OS-II非常簡單明了，只有os.c、os.h和os_a.asm三個文件，os.c中只有寥寥15個函數，os_a.asm中只有4個匯編函數。考慮到擴展性，還是保留了uC/OS-II的一些影子，其實若再精簡下去，可能就只剩下一個內核切換，msOS只需要兩個任務即可，完全可以精簡到跟uC/OS-II無關了。 |
