引 言：
就目前而言，μC/OSII[1]稱得上是最小的操作系統內核軟件。它由Jean J. Labrosse于1992年推出第一版，立刻在嵌入式系統領域引起強烈反響，而其本人也早已成為嵌入式系統會議（美國）的顧問委員會成員。μC/OS最鮮明特點就是源碼公開，便于移植和維護，而且對于學校研究完全免費，只有在應用于盈利項目時才需要支付少量的版權費，特別適合一般使用者的學習、研究和開發。自問世以來，μC/OS的穩定性和可靠性得到了廣泛認可，現已通過美國FAA認證，并被眾多的研究開發者作為操作系統的樣板，移植到各種的硬件平臺上。
1 μC/OS任務用戶接口的缺點 　　μC/OSII中任務的用戶接口并不友善，與眾多程序員熟悉的Windows多任務接口相異較大。
首先，μC/OSII中任務的棧空間完全由用戶自行管理，系統只是簡單的要求用戶創建任務時傳入棧地址，而不參與棧空間的申請和釋放。為了簡化，μC/OS的示例程序以靜態數組作為任務棧。棧空間的放任自流在帶來一定靈活性的同時也會帶來問題。有些用戶仿照示例程序，大量以靜態數組形式作為任務棧，極大地浪費了嵌入式系統極為珍貴的內存空間；而有些用戶在任務開始時申請了棧空間，在任務結束時卻忘記釋放，造成難以跟蹤的內存漏洞。
其次，在μC/OSII中任務結束時，需要手工調用OSTaskDel使該任務進入睡眠態，不能簡單的返回。這是因為μC/OSII規定任務必須為無限循環或自銷毀形式，而流行的大多數操作系統，任務結束后只是簡單的返回，由系統幫助釋放任務占據的資源。
2002年，隨著我國相關下游產業，包括移動通信、信息家電以及工業控制等領域的快速發展，嵌入式軟件產業迎來了極佳的發展時機。強勁的市場需求帶來了研發的快速增長，越來越多的軟件公司投入到嵌入式產品的研發中。但是國內嵌入式產品的產業現狀是，程序員素質在數量上呈現金字塔狀況，高級程序員很少，廣大對Windows編程熟悉但對嵌入式開發陌生的普通程序員占據金字塔的底端。
若希望在數量龐大的普通程序員中應用μC/OSII，減少Bug產生的來源，那么對其任務接口作出簡化處理是必要的。
2 對μC/OS調度算法的改善　
本文參考國內程序員很熟悉的Windows多線程接口，對μC/OS任務接口做出改進，增強易用性和用戶親和力。本文在任務創立時幫助用戶申請棧空間，并在初始化用戶棧時，將任務銷毀函數壓入棧中，使其能在用戶任務返回時自動調用，自動釋放棧空間，并調用OSTaskDel使該任務進入睡眠態。
增加接口OSNewTaskCreate和OSAutoTaskDel。OSNewTaskCreate用于創建任務，該函數在系統內核中代替用戶申請棧空間，并在初始化棧內容時壓入OSAutoTaskDel地址。改進后的OSNewTaskCreate接口如下:
INT8UOSNewTaskCreate（任務地址pThead,參數pData,棧大小dwStackSize，優先級prio）；
用戶傳入需要棧空間的大小（dwStackSize）而不是棧地址，如果dwStackSize為零，則棧空間為系統預設的大小。系統調用OSMemGet在棧內存分區（MemoryPartition）中申請該空間。該棧內存分區在系統初始化時調用OSMemCreate分配，用來統一管理所有的用戶棧。接下來的步驟和μC/OS完全相同，這里不再詳述。

棧空間申請了，在哪里釋放呢？可以通過修改棧初始化函數OSTaskStkInit，把OSAutoTaskDel地址壓入任務棧中。修改前，OSTaskStkInit形成的棧在x86平臺上的內容如圖1所示。
任務第一次被調度進入運行態時，系統模仿從中斷返回，會開始執行用戶任務[1]。圖1中“任務開始地址”處，理論上應該為任務的返回地址，但在μC/OSII中，任務函數必須為無限循環結構或自銷毀形式，不能有返回點。因此，僅僅簡單添入任務開始地址，如果用戶任務返回，則會有不可預料的后果。修改OSTaskStkInit使棧的內容如圖2所示。

此時，用戶任務的棧內容與OSAutoTaskDel函數用pdata作參數調用它的棧內容完全相同。所以在用戶任務返回時，自動調用OSAutoTaskDel函數，省去了手工調用OSTaskDel的麻煩。在OSAutoTaskDel中，先釋放棧空間，之后調用OSTaskDel使該任務進入睡眠態。
結語
本文對μC/OSII中任務的用戶接口進行了改善，使之更加方便易用、易于維護，并減少了錯誤出現的機會。通過以上方法，希望能使μC/OSII為普通嵌入式程序員所接受。