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

       1 μC/OS-Ⅱ操作系統簡介

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

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

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

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

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

       3.1 與應用相關的代碼

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

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

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

       3.2 與處理器相關的代碼

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

       3.2.1 OS_CPU.H

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

       （1）不依賴于編譯的數據類型

       μC/OS-Ⅱ不使用C語言中的short，int和long等數據類型的定義，因為他們與處理器類型有關，隱含著不可移植性，代之以移植性強的整數數據類型，這樣，既直觀又可移植。根據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處理器核具有兩個指令集，用戶任務可以使用兩種處理器模式，為了使底層接口函數與處理器狀態無關，同時在任務調用相應函數時不需要知道該函數位置，本例使用軟中斷指令SWI作為底層接口，使用不同的功能號區分不同的函數，其SWI服務函數代碼為：
   

       （3）OS_STK_GROWTH

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

       #define OS_STK_GROWTH 1

       3.2.2 OS_CPU_C.C

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

       3.2.3 OS_CPU_A.S

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

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

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

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

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

       4 μC/OS-Ⅱ的測試

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

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

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

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

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

       5 結語

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



 

關于μC/OS-II系列軟件版權的說明

Micrium 公司產品包括μC/OS-II，μC/GUI，uC/FS，μC/TC P-IP，μC/USB等。Micrium 公司提供嵌入式系統應用方面的產品，并對其軟件擁有知識產權。Micrium花費了大量的時間和財力為嵌入式領域提供高質量的軟件產品。所有上述產品都以源代碼的形式提供給客戶，具有極大的適用性。產品不是免費軟件，也不是開放源碼的軟件，因此，不能免費使用，需要清楚的闡明μC/OS-II和系列的軟件不是開放源碼的免費軟件，這是和Linux完全不一樣的。

開發和研究者可以通過購買Micrium公司的Jean先生的μC/OS-II的書籍，而得到μC/OS-II源代碼,但是僅可以作為個人和學校學習使用，所有和μC/OS-II直接和間接相關的商業目的行為，必須購買使用μC/OS-II及系列產品的商業授權，包括芯片/單板/系統廠家的任何參考設計，教學設備和最終的產品，如果沒有得到Micrium公司Jean先生簽字的合法授權都是不合法的使用, 這在μC/OS-II的書籍Micrium公司(www.micrium.com)和中國代理商-北京麥克泰軟件公司網站（www.bmrtech.com）上面中有明確規定。

Micrium公司其它軟件如μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等的銷售模式與μC/OS-II不同，如果沒有購買使用授權，完全不可以擁有該源代碼，也不能將源代碼用于產品的設計，培訓，教學和生產。

μC/OS-II, μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等授權方式有：單個產品、產品線（系列）、按照CPU 劃分的產品三種形式，μC/OS-KA，μC/OS-VIEW 等工具是按照使用人的數目收取費用的，相對起傳統的RTOS 動輒2-3萬美圓的開發費用和每塊單板的使用費（根據數量從數百到幾個美圓），μC/OS-II及系列產品是采用一次性的收費方式，應該只是大約相當于傳統RTOS 的10-20% 的總體費用。

如果您正在將μC/OS-II系列軟件用于您的產品，您需要購買并獲得正式使用授權。

北京麥克泰軟件技術有限公司