隨著嵌入式技術的快速發(fā)展，實時多任務操作系統(tǒng)作為一種軟件平臺已逐步成為國際嵌入式系統(tǒng)的主流，目前世界上已經(jīng)有一大批成熟的實時嵌入式操作系統(tǒng)，通常，對嵌入式軟件的基本要求是體積小、指令速度快、具有較好的裁減性和可移植性，目前，實時操作系統(tǒng)很多，如VxWorks，Windows CE，pSOS，QNX，LynxOS等，這些操作系統(tǒng)都具有高可靠性、強實時性等特點，但他們都是商業(yè)操作系統(tǒng)，價格昂貴，人們往往很難接受，μC/OS-Ⅱ操作系統(tǒng)的出現(xiàn)是對這些商業(yè)操作系統(tǒng)的一個很大的沖擊。

       1 μC/OS-Ⅱ操作系統(tǒng)簡介

       μC/OS-Ⅱ是源碼公開的實時操作系統(tǒng)，是一個自由操作系統(tǒng)。程序開發(fā)人員可以改寫源代碼，使之符合自己的要求，裁減掉不需要的部分，使操作系統(tǒng)變得小巧、靈活、并且能滿足用戶特定操作系統(tǒng)的需要。為了提高系統(tǒng)的實時能力，μC/OS-Ⅱ可以將一個復雜的應用劃分為多個相互獨立的任務，并根據(jù)任務的重要性來分配優(yōu)先級。任務的調度完全由μC/OS-Ⅱ的實時內核完成，主要包括任務的狀態(tài)管理、選擇最高優(yōu)先級的任務、執(zhí)行任務和撤銷任務等，μC/OS-Ⅱ內核還負責CPU時間分配，CPU時間總是優(yōu)先分配給中斷事件，其次是任務隊列中當前優(yōu)先級最高的任務，不同任務間的通信可以通過μC/OS-Ⅱ提供的信號量、郵箱、信息隊列等機制完成，他的絕大部分代碼是用C語言編寫的，可移植性強，因此1997年以后，在國際上逐漸被廣泛采用。

       2 其軟硬件體系及可移植性分析

       μC/OS-Ⅱ核心代碼很小，程序開發(fā)人員要把他移植到自己的目標板中只需做少量的工作。圖1是基于μC/OS-Ⅱ的嵌入式系統(tǒng)的軟硬件體系結構。

       雖然μC/OS-Ⅱ大部分源代碼是用C語言寫的，但是完成和處理器有關的代碼時，還是用匯編語言來實現(xiàn)的，由圖1可以看出，μC/OS-Ⅱ的移植的主要工作是修改與處理器相關部分的代碼，他們集中在3個文件中，其中，OS_CPU.H包含與處理器相關的常量、宏和結構體的定義；OS_CPU_C.C和OS_CPU_ASM中定義了用于底層的任務切換，退出中斷服務程序，在CPU級屏蔽中斷、打開中斷、對任務棧初始化以及時鐘的中斷服務程序的函數(shù)等，為了使應用程序運行于μC/OS-Ⅱ上，還要相應地修改應用中使用的硬件和設備驅動。

       3 μC/OS-Ⅱ的移植工作

       3.1 與應用相關的代碼

       這一部分是用戶根據(jù)自己的應用系統(tǒng)來定制合適的內核服務功能，包括2個文件：OS_CFG.H和INCLUDES.H。

       OS_CFG.H 用來配置內核，用戶根據(jù)需要對內核進行修改，留下需要的部分，去掉不需要的部分，比如系統(tǒng)可提供的最大任務數(shù)量，是否定制郵箱服務，是否提供優(yōu)先級動態(tài)改變功能等等，所有的配置更改包括頭文件的增減均在該文件中進行。

       INCLUDES.H 系統(tǒng)頭文件，整個實時系統(tǒng)程序所需要的文件，包括了內核和用戶的頭文件，這樣使得用戶項目中的每個.C文件不用分別去考慮他實際上需要哪些頭文件。

       3.2 與處理器相關的代碼

       這是移植中最關鍵的部分。內核將應用系統(tǒng)和底層硬件有機地結合成一個實時系統(tǒng)，要使同一個內核能適用于不同的硬件體系，就需要在內核和硬件之間有一個中間層，這就是與處理器相關的代碼，處理器不同，這部分代碼也不同，我們在移植時需要自己處理這部分代碼，在μC/OS中這一部分代碼分成3個文件：OS_CPU.H，OS_CPU_A.ASM，OS_CPU_C.C。

       3.2.1 OS_CPU.H

       包含了用#define定義的與處理器相關 的常量、宏和類型定義，具體有系統(tǒng)數(shù)據(jù)類型定義、棧增長方向定義、關中斷和開中斷定義、系統(tǒng)軟中斷的定義等。

       （1）不依賴于編譯的數(shù)據(jù)類型

       μC/OS-Ⅱ不使用C語言中的short，int和long等數(shù)據(jù)類型的定義，因為他們與處理器類型有關，隱含著不可移植性，代之以移植性強的整數(shù)數(shù)據(jù)類型，這樣，既直觀又可移植。根據(jù)ADS編譯器的特性，代碼為：

       typedef unsigned char BOOLEAN；
       typedef unsigned char INT8U；
       typedef signed char INT8S；
       typedef unsigned short INT16U；
       typedef signed short INT16S；
       typedef unsigned int INT32U；
       typedef signed int INT32S；
       typedef float FP32；
       typedef double FP64；
       typedef INT32U OS_STK；

       （2）使用軟中斷SWI做底層接口

       因為帶T變量的ARM7處理器核具有兩個指令集，用戶任務可以使用兩種處理器模式，為了使底層接口函數(shù)與處理器狀態(tài)無關，同時在任務調用相應函數(shù)時不需要知道該函數(shù)位置，本例使用軟中斷指令SWI作為底層接口，使用不同的功能號區(qū)分不同的函數(shù)，其SWI服務函數(shù)代碼為：
   

 [!--empirenews.page--]

       （3）OS_STK_GROWTH

       μC/OS-Ⅱ使用結構常量OS_STK_GROWTH指定堆棧的生長方式，其代碼為：

       #define OS_STK_GROWTH 1

       3.2.2 OS_CPU_C.C

       包含了與移植有關的C函數(shù)，包括堆棧的初始化和一些鉤子函數(shù)的實現(xiàn)，但是最重要的是OSTaskStkInit（）函數(shù)，該函數(shù)是在用戶建立任務時系統(tǒng)內部自己調用的，用來對用戶任務的堆棧初始化。在ARM7體系結構下，任務堆?？臻g由高至低遞減，依次保存著PC，LR，R12，…，R1，R0，CPSR的初始化堆棧結構，當用戶初始化了堆棧，OSTaskStkInit（）就返回新的堆棧指針STK所指的定地址。OSTaskCreate（）和OSTaskCreateExt（）會獲得該地址并將他保存到任務控制塊TCB中，其他的幾個鉤子函數(shù)必須聲明，但可以不包含任務代碼，這些鉤子函數(shù)在本移植中全為空函數(shù)。

       3.2.3 OS_CPU_A.S

       μC/OS-Ⅱ移植的絕大部分工作都集中在OS_CPU_A.S文件的移植上，在這個文件里，最困難的工作又集中體現(xiàn)在OSIntCtxSw和OSTickISR這兩個函數(shù)的實現(xiàn)上。這是因為這兩個函數(shù)的實現(xiàn)是和移植者的移植思路以及相關硬件定時器、中斷寄存器的設置有關，在實際的移植工作中，這兩個地方也是比較容易出錯的地方，這部分需要對處理器的寄存器進行操作，所以必須用 匯編語言編寫，包括4個子函數(shù)：OSStartHighRdy（）、OSCtxSw（）、OSIntCtxSw（）、OSTickISR（）。

       OSStartHighRdy（）該函數(shù)首先調用鉤子函數(shù)OSTaskSwHook（），然后將OSRunning標志位設置為真，表示任務開始執(zhí)行，從而保證任務切換操作的正確執(zhí)行，緊接著從具有最高優(yōu)先級的任務控制塊中取得任務的堆棧指針，初始化堆棧指針寄存器SP，然后恢復其他的寄存器，開始執(zhí)行最高優(yōu)先級的任務。

       OSCtxSw（）該函數(shù)在任務級任務切換函數(shù)中調用，首先保存處理器寄存器，將當前SP存入任務TCB中，載入就緒最高優(yōu)先級任務的SP，從新任務的任務堆棧中恢復處理器所有寄存器的值，然后執(zhí)行中斷返回指令。

       OSIntCtxSw（）該函數(shù)是在ISR中執(zhí)行任務切換功能，其原理基本上與任務級的切換相同，區(qū)別只是ISR已經(jīng)保存了CPU的寄存器，因此不要再進行類似的操作，只需對堆棧指針作相應的調整即可。

       OSTickISR（）該函數(shù)是系統(tǒng)時鐘節(jié)拍中斷服務函數(shù)，首先要保存處理器寄存器，接著調用OSIntEnter（）函數(shù)，以保證中斷嵌套層數(shù)不超過255層，如果滿足了該條件，則把堆棧指針保存到當前任務的任務控制塊TCB中，然后給產(chǎn)生中斷的設備清中斷，重新允許中斷，接下來調用OSTimeTick（）來維持μC/OS-Ⅱ內部的定時以及調用OSIntExit（）函數(shù)決定是否因為這個中斷服務程序的執(zhí)行，使得更高優(yōu)先級的任務就緒。

       4 μC/OS-Ⅱ的測試

       做完移植工作以后，就要測試移植是否正確，這其實是移植過程的最后一步，應該首先不加任何用代碼來測試移植好的μC/OS-Ⅱ，即應該首先測試內核自身的運行狀況，這樣做的目的是如果有些部分未能正常工作，那就是移植本身的問題，而不是應用代碼產(chǎn)生的問題，主要分為以下幾個步驟來進行移植的測試：

       首先，必須了解處理器所使用的編譯器系統(tǒng)，這個步驟取決于使用的編譯器，在這期間是無代碼的測試，其次，要驗證OSTaskStkInit（）和OSStartHighRdy（）函數(shù)，在OS_CFG.H文件中設置OS_TASK_STAT_EN為0，只讓一個空閑任務OS_TaskIdle（）運行，檢查是否出錯，然后需要驗證任務級切換OSCtxSw（）函數(shù)，在測試任務TaskTest（）中加入OSTimeDly（）函數(shù)，OSTimeDly（）函數(shù)接著調用OS_Sched（），OS_Sched（）調用匯編語言編寫的函數(shù)OSCtxSw（）函數(shù)，如果是正確配置了SWI，CPU就會開始執(zhí)行OSCtxSw（），最后，需要驗證OSIntCtxSw（）和OSTickISR（）函數(shù)。

       當上述的這些測試步驟都成功后，可以嘗試運行一些具體的任務，按照由簡到繁的過程不斷使測試變得復雜，來進一步驗證內核的穩(wěn)定性和系統(tǒng)性能。

       這里建立了一個簡單的LED燈閃爍控制任務，其代碼如下：
 

       加載后，LED燈閃爍控制正常，則測試成功，內核正常運轉，若測試出現(xiàn)問題，就要認真找出問題所在，不可忽略硬件的問題，還有編譯器等，當然也可以采用其他的測試，如串口的測試等。

       5 結語

       以上所述為μC/OS-Ⅱ在ARM7上移植的通用方法，但針對不同的處理器還需要作適當?shù)男薷?，RTOS是當今嵌入式應用的熱點，應用RTOS，可以提高產(chǎn)品的可靠性，降低研發(fā)周期，其中μC/OS-Ⅱ具有很好的實時性和很小的代碼量，占用空間少，執(zhí)行效率高，移植方法相對簡單，因此掌握μC/OS-Ⅱ的移植方法是相當重要的。