隨著嵌入式技術的快速發展，實時多任務操作系統作為一種軟件平臺已逐步成為國際嵌入式系統的主流，目前世界上已經有一大批成熟的實時嵌入式操作系統，通常，對嵌入式軟件的基本要求是體積小、指令速度快、具有較好的裁減性和可移植性，目前，實時操作系統很多，如 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- Ⅱ 的移植方法是相當重要的。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的ucos-ii在ARM7上移植的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。