本文詳細系統地介紹了uC/OS-II在51單片機上的移植、重入實現方法、硬件仿真、固化、人機界面等關鍵內容。
關鍵詞：嵌入式實時多任務操作系統、uC/OS-II、C51
引言：隨著各種應用電子系統的復雜化和系統實時性需求的提高,并伴隨應用軟件朝著系統化方向發展的加速,在16位/32位單片機中廣泛使用了嵌入式實時操作系統。然而實際使用中卻存在著大量8位單片機,從經濟性考慮,對某些應用場合,在8位MCU上使用操作系統是可行的。從學習操作系統角度,uC/OS-II for 51即簡單又全面,學習成本低廉,值得推廣。
結語：μC/OS-II具有免費、簡單、可靠性高、實時性好等優點,但也有缺乏便利開發環境等缺點,尤其不像商用嵌入式系統那樣得到廣泛使用和持續的研究更新。但開放性又使得開發人員可以自行裁減和添加所需的功能,在許多應用領域發揮著獨特的作用。當然,是否在單片機系統中嵌入μC/OS-II應視所開發的項目而定,對于一些簡單的、低成本的項目來說,就沒必要使用嵌入式操作系統了。

uC/OS-II原理：
uCOSII包括任務調度、時間管理、內存管理、資源管理（信號量、郵箱、消息隊列）四大部分,沒有文件系統、網絡接口、輸入輸出界面。它的移植只與4個文件相關：匯編文件（OS_CPU_A.ASM）、處理器相關C文件（OS_CPU.H、OS_CPU_C.C）和配置文件（OS_CFG.H）。有64個優先級,系統占用8個,用戶可創建56個任務,不支持時間片輪轉。它的基本思路就是 “近似地每時每刻總是讓優先級最高的就緒任務處于運行狀態” 。為了保證這一點,它在調用系統API函數、中斷結束、定時中斷結束時總是執行調度算法。原作者通過事先計算好數據,簡化了運算量,通過精心設計就緒表結構,使得延時可預知。任務的切換是通過模擬一次中斷實現的。
uCOSII工作核心原理是：近似地讓最高優先級的就緒任務處于運行狀態。
操作系統將在下面情況中進行任務調度：調用API函數(用戶主動調用),中斷(系統占用的時間片中斷OsTimeTick(),用戶使用的中斷)。
調度算法書上講得很清楚,我主要講一下整體思路。
(1)在調用API函數時,有可能引起阻塞,如果系統API函數察覺到運行條件不滿足,需要切換就調用OSSched()調度函數,這個過程是系統自動完成的,用戶沒有參與。OSSched()判斷是否切換,如果需要切換,則此函數調用OS_TASK_SW()。這個函數模擬一次中斷(在51里沒有軟中斷,我用子程序調用模擬,效果相同),好象程序被中斷打斷了,其實是OS故意制造的假象,目的是為了任務切換。既然是中斷,那么返回地址(即緊鄰OS_TASK_SW()的下一條匯編指令的PC地址)就被自動壓入堆棧,接著在中斷程序里保存CPU寄存器(PUSHALL)……。堆棧結構不是任意的,而是嚴格按照uCOSII規范處理。OS每次切換都會保存和恢復全部現場信息(POPALL),然后用RETI回到任務斷點繼續執行。這個斷點就是OSSched()函數里的緊鄰OS_TASK_SW()的下一條匯編指令的PC地址。切換的整個過程就是,用戶任務程序調用系統API函數,API調用OSSched(),OSSched()調用軟中斷OS_TASK_SW()即OSCtxSw,返回地址(PC值)壓棧,進入OSCtxSw中斷處理子程序內部。反之,切換程序調用RETI返回緊鄰OS_TASK_SW()的下一條匯編指令的PC地址,進而返回OSSched()下一句,再返回API下一句,即用戶程序斷點。因此,如果任務從運行到就緒再到運行,它是從調度前的斷點處運行。
(2)中斷會引發條件變化,在退出前必須進行任務調度。uCOSII要求中斷的堆棧結構符合規范,以便正確協調中斷退出和任務切換。前面已經說到任務切換實際是模擬一次中斷事件,而在真正的中斷里省去了模擬(本身就是中斷嘛)。只要規定中斷堆棧結構和uCOSII模擬的堆棧結構一樣,就能保證在中斷里進行正確的切換。任務切換發生在中斷退出前,此時還沒有返回中斷斷點。仔細觀察中斷程序和切換程序最后兩句,它們是一模一樣的,POPALL+RETI。即要么直接從中斷程序退出,返回斷點;要么先保存現場到TCB,等到恢復現場時再從切換函數返回原來的中斷斷點(由于中斷和切換函數遵循共同的堆棧結構,所以退出操作相同,效果也相同)。用戶編寫的中斷子程序必須按照uCOSII規范書寫。任務調度發生在中斷退出前,是非常及時的,不會等到下一時間片才處理。OSIntCtxSw()函數對堆棧指針做了簡單調整,以保證所有掛起任務的棧結構看起來是一樣的。
(3)在uCOSII里,任務必須寫成兩種形式之一(《uCOSII中文版》p99頁)。在有些RTOS開發環境里沒有要求顯式調用OSTaskDel(),這是因為開發環境自動做了處理,實際原理都是一樣的。uCOSII的開發依賴于編譯器,目前沒有專用開發環境,所以出現這些不便之處是可以理解的。
移植過程：
(1)拷貝書后附贈光盤sourcecode目錄下的內容到C:\YY下,刪除不必要的文件和EX1L.C,只剩下p187(《uCOSII》)上列出的文件。
(2)改寫最簡單的OS_CPU.H
數據類型的設定見C51.PDF第176頁。注意BOOLEAN要定義成unsigned char 類型,因為bit類型為C51特有,不能用在結構體里。
EA=0關中斷;EA=1開中斷。這樣定義即減少了程序行數,又避免了退出臨界區后關中斷造成的死機。
MCS-51堆棧從下往上增長(1=向下,0=向上),OS_STK_GROWTH定義為0
#define OS_TASK_SW() OSCtxSw() 因為MCS-51沒有軟中斷指令,所以用程序調用代替。兩者的堆棧格式相同,RETI指令復位中斷系統,RET則沒有。實踐表明,對于MCS-51,用子程序調用入棧,用中斷返回指令RETI出棧是沒有問題的,反之中斷入棧RET出棧則不行。總之,對于入棧,子程序調用與中斷調用效果是一樣的,可以混用。在沒有中斷發生的情況下復位中斷系統也不會影響系統正常運行。詳見《uC/OS-II》第八章193頁第12行
(3)改寫OS_CPU_C.C
我設計的堆棧結構如下圖所示：

TCB結構體中OSTCBStkPtr總是指向用戶堆棧最低地址,該地址空間內存放用戶堆棧長度,其上空間存放系統堆棧映像,即：用戶堆棧空間大小=系統堆棧空間大小+1。
SP總是先加1再存數據,因此,SP初始時指向系統堆棧起始地址(OSStack)減1處(OSStkStart)。很明顯系統堆棧存儲空間大小=SP-OSStkStart。
任務切換時,先保存當前任務堆棧內容。方法是：用SP-OSStkStart得出保存字節數,將其寫入用戶堆棧最低地址內,以用戶堆棧最低地址為起址,以OSStkStart為系統堆棧起址,由系統棧向用戶棧拷貝數據,循環SP-OSStkStart次,每次拷貝前先將各自棧指針增1。
其次,恢復最高優先級任務系統堆棧。方法是：獲得最高優先級任務用戶堆棧最低地址,從中取出“長度”,以最高優先級任務用戶堆棧最低地址為起址,以OSStkStart為系統堆棧起址,由用戶棧向系統棧拷貝數據,循環“長度”數值指示的次數,每次拷貝前先將各自棧指針增1。
用戶堆棧初始化時從下向上依次保存：用戶堆棧長度（15）,PCL,PCH,PSW,ACC,B,DPL,DPH,R0,R1,R2,R3,R4,R5,R6,R7。不保存SP,任務切換時根據用戶堆棧長度計算得出。
OSTaskStkInit函數總是返回用戶棧最低地址。
操作系統tick時鐘我使用了51單片機的T0定時器,它的初始化代碼用C寫在了本文件中。
最后還有幾點必須注意的事項。本來原則上我們不用修改與處理器無關的代碼,但是由于KEIL編譯器的特殊性,這些代碼仍要多處改動。因為KEIL缺省情況下編譯的代碼不可重入,而多任務系統要求并發操作導致重入,所以要在每個C函數及其聲明后標注reentrant關鍵字。另外,“pdata”、“data”在uCOS中用做一些函數的形參,但它同時又是KEIL的關鍵字,會導致編譯錯誤,我通過把“pdata”改成“ppdata”,“data”改成“ddata”解決了此問題。OSTCBCur、OSTCBHighRdy、OSRunning、OSPrioCur、OSPrioHighRdy這幾個變量在匯編程序中用到了,為了使用Ri訪問而不用DPTR,應該用KEIL擴展關鍵字IDATA將它們定義在內部RAM中。
(4)重寫OS_CPU_A.ASM
A51宏匯編的大致結構如下：
NAME 模塊名 ;與文件名無關
;定義重定位段 必須按照C51格式定義,匯編遵守C51規范。段名格式為：?PR?函數名?模塊名
;聲明引用全局變量和外部子程序 注意關鍵字為“EXTRN”沒有‘E’
全局變量名直接引用
無參數/無寄存器參數函數 FUNC
帶寄存器參數函數 _FUNC
重入函數 _?FUNC
;分配堆棧空間
只關心大小,堆棧起點由keil決定,通過標號可以獲得keil分配的SP起點。切莫自己分配堆棧起點,只要用DS通知KEIL預留堆棧空間即可。