μC/OS-II在ARM平臺上移植的深入探討

王琨強,趙志珩

（汽車管理學院 基礎部，蚌埠 233011）

μC/OS-II在ARM平臺的移植是一個重要的學習過程，有助于提高對RTOS的認識與理解，從而提高嵌入式工作者的理論與技術水平。μC/OS-II是一個小的實時內核，源代碼公開，有詳盡的解釋。正是因為其內核小，才便于研究、理解和掌握。另外，參照TCP/IP協議、標準和一些公開的圖書，在μC/OS-II上增加TCP/IP協議棧，藍牙通信軟件、紅外通信協議也十分方便，商業價值得到了認可。

隨著科技的發展，嵌入式應用的復雜性越來越高，同時ARM體系處理器的價格越來越低，ARM平臺 +實時操作系統的架構體系的使用會越來越廣泛。有鑒于此，本文對μC/OS-II在ARM平臺下的移植進行了深入探討。

1 操作系統μC/OS-II及S3C2410開發平臺簡介

1.1 μC/OS-II簡介

μC/OS最早出自于1992年美國嵌入式系統專家Jean J.Labrosse在《嵌入式系統編程》雜志5月和6月上刊登的文章連載，并把μC/OS的源代碼發表在該雜志的BBS上。μC/OS-II是目前最新的版本。

μC/OS-II是專門為計算機的嵌入式應用而設計的，絕大部分代碼用C語言編寫。CPU的相關部分采用匯編語言編寫，總量在200行左右的匯編語言被壓縮到最低限度，目的是便于移植到任何一種其他的CPU上去。μC/OS-II具有執行效率高、占用空間小、實時性優良、可擴展等特點，最小內核可編譯至 2 KB。μC/OS-II可移植到幾乎所有知名的CPU上。

1.2 μC/OS-II的組成

嚴格地說μC/OS-II只是一個實時操作系統內核，它僅僅包含了任務調度、任務管理、時間管理、內存管理和任務間的通信和同步等基本功能。沒有提出輸入輸出管理、文件系統、網絡通信等額外的服務。但由于μC/OS-II良好的可擴展性和源代碼開放，這些非必須的功能完全可以由用戶根據自己的需要分別實現。

μC/OS-II可以大致分成核心、任務處理、時間處理、任務同步與通信、CPU的移植等5個部分[1]。

(1)核心部分（OSCore.c）:操作系統的處理核心，包括操作系統的初始化、操作系統運行、中斷進出的前導、時鐘節拍、任務調度、事件處理等多部分。

(2)任務處理部分(OSTask.c):與任務操作密切相關的部分。包括任務的建立、刪除、掛起、恢復等等。

(3)時鐘部分(OSTime.c):μC/OS-II中最小的時鐘單位是timetick（時鐘節拍）。任務延時等操作在此完成。

(4)任務同步和通信部分：為事件處理部分，包括信號量、郵箱、郵箱隊列、事件標志等部分，主要用于任務間的相互聯系和對臨界資源的訪問。

(5)與CPU的接口部分：這里是指 μC/OS-II針對所使用的CPU需要改寫的部分。由于μC/OS-II是一個通用性的操作系統，其開放的源代碼是以X86內核為例而編寫的，在應用到其他處理器平臺上時，這部分代碼必須做相應的改變。

1.3 ARM硬件開發平臺簡介

調試時所用的硬件開發平臺是一款基于三星S3C2410A芯片的開發平臺。S3C2410開發板是一款通用的ARM9開發板,其基本配置采用三星公司的S3C2410 ARM920T芯片，主頻 203 MHz。集成有SDRAM控制器、NAND Flash控制器、SD讀卡器、USB Host和 USB Device控制器、LCD控制器、I2C總線控制器、SPI總線接口等。開發板上Flash空間為32 MB，SDRAM容量為128 MB。

2 S3C2410引導程序

開發板原有引導程序由VIVI公司提供，其運行過程分成兩個階段。第一階段的代碼用匯編語言編程，主要完成以下任務：(1)初始化CPU速度、存儲器、存儲器配置寄存器，以及串口等硬件資源的配置；(2)建立內存空間的映射圖，將系統的軟硬件環境帶到合適的狀態，為最終調用操作系統內核做準備；(3)裝載操作系統映像到內存中；(4)設置相關寄存器和資源，跳轉到main（）函數，進入第二階段。

第二階段的代碼用 C語言編寫，從 main（）函數開始,主要工作有:開發板外部接口初始化(I/O接口、UART接口、LCD接口等)、內存映射和內存管理單元初始化等，最后啟動linux內核。有大量文章對此開發板引導程序作了詳細的分析[3]，本文在這里不做重復，本文的重點是將引導程序與μC/OS-II操作系統二者融合，既利用了開發板源代碼提供的關于UART口、LCD和觸摸屏接口程序；時鐘、內存管理等豐富的驅動程序和接口程序，又成功地完成了對μC/OS-II實時操作系統的移植和整合。

3 移植要點

μC/OS-II的內核分成2個部分，與處理器無關的代碼和與處理器有關的代碼。移植過程中需要根據S3C2410處理器和ADSV1.2開發平臺（這里特地強調編譯平臺的因素，主要考慮到各個編譯平臺對數據格式的理解略有差別）的特點來重新編寫3個文件，用C語言編寫的OS_CPU.H、OS_CPU_C.C和用匯編語言編寫的OS_CPU_A.ASM，此外，要將S3C2410開發板引導程序和μC/OS-II內核程序融合在一起，還必須將各自main（）函數融為一體。

3.1 OS_CPU.H 的移植

μC/OS-II內核中 OS_CPU.H代碼是根據 X86內核而寫的，其中的數據格式定義與ARM9內核以及ADSv1.2開發平臺不完全相符。OS_CPU.H的移植分為以下4個部分：

(1)數據類型定義:在調試時發現，雖然定義 8 bit或16 bit數據類型時,在編譯過程中不會報錯，但這些變量并不會按要求被正確初始化或賦值，運行過程常常出錯。所以，在改寫OS_CPU.H代碼時，將所有變量都定義成 32 bit或 64 bit；

(2)堆棧生長方向定義:ARM的堆棧是從上往下生長的，OS_STK_GROWTH定義為 1；

(3)開關中斷的宏定義:用開關中斷的匯編函數實現，放在OS_CPU_A.ASM文件中。

(4)宏定義OS_TASK_SW（）:這個宏定義是在 ARM 中斷處理之外時，μC/OS-II從低優先級切換到高優先級任務時所調用的代碼，它總是在任務級代碼中被調用。在有些資料中[1]，將 OS_TASK_SW()和 OSIntCtxSw（）等同起來，這在ARM內核中是不行的，因為后者是ARM內核在中斷模式下的任務切換函數，而不同模式下處理器的寄存器組是不同的，所要保護的寄存器內容也不相同，經過調試，發現以下代碼可達到目的。

3.2 OS_CPU_C.C.H 的移植

在OS_CPU_C.C中,最主要的函數是OSTaskStkInit（），它在任務建立時,用來初始化任務堆棧結構，其余鉤子函數可以不用動,這個函數的代碼比較簡單[2]。需要說明的是，由于本文所述系統，用戶任務運行在SVC模式下，沒有保存SPSR寄存器。

3.3 OS_CPU_A.ASM 的移植

OS_CPU_A.ASM文件的匯編程序是μC/OS-II移植工程的重點和難點。它通常包括OSStartHighRdy()、OS-IntCtxSw()、OSTickISR（）和開關 中斷代 碼等 。 其中 ，OSStartHighRdy()的主要工作是將優先級最高任務對應的所有寄存器按順序從任務堆棧中恢復出來,其代碼簡單[2]。對于開關中斷函數，在調試時所用代碼如下：

需要指出的是，在每次成對調用這兩個函數時，需要提前聲明變量r，代碼如下所示:

需要慎重對待的是 OSIntCtxSw()、OSTickISR（）函數。在調試時發現，用一般參考資料所介紹的代碼都無法實現多任務的正常運行，其主要原因是，對ARM9內核而言，其每種特定的中斷返回，都有特定的返回指令，在中斷處理過程中，強制使用模式切換指令，使處理器的中斷處理機制發生混亂，程序無法正常執行。例如在ISR模式中使用指令：

其目的是返回ISR發生之前的模式，然后保存一些寄存器。但調試時發現，在上述指令執行之后，處理器重新響應ISR中斷，并沒有順序執行，而是立即回到ISR模式下。

還有，對于 S3C2410的 ARM920T內核而言，其 ISR模式的返回指令是：

其他任何形式的指令都無法使處理器正確返回。有些資料用下述指令：

Ldmfd sp!,{r0-r12,lr，pc};執行之前堆棧中相應存儲單元的內容為（lr-4）。

看起來與前面的兩行代碼意義相同，但后面的代碼僅僅讓處理器實現PC指針的跳轉，而無法實現處理器的模式轉換，即從ISR模式回到中斷發生之前的模式。

但在中斷發生時，無法在中斷處理過程中保存所有的處理器寄存器。例如，在ISR模式下，無法保存SVC模式的LR寄存器等。為了解決這個問題，本文采取了如圖1所示的框圖結構來編寫中斷處理代碼和OSIntC-txSw()函數。

因為S3C2410在進入ISR模式后,自動屏蔽ISR中斷，所以粗存在中斷嵌套,可以表明2個全部變量ISR_LR和ISR_SPSR用于保存ISR中斷發生之時處理器的lr和spsr寄存器。其代碼的特別之處在于，在ISR中斷處理過程中通過修改lr寄存器，而使處理器在退出ISR模式時能根據任務的需要返回至ISR中斷發生之處或者代碼指定地點。在代碼指定地點，可以保存上次中斷發生時被中斷任務的處理器的所有寄存器數據。這里需要注意一點，當處理器退出ISR模式時跳轉到Saveregister處開始執行命令，需要提前將Saveregister處的地址加上4，然后賦值給lr寄存器。因為在ISR退出時，需要將lr減去4再賦值給程序計數器pc。

圖1 中斷處理過程

4 S3C2410啟動代碼和μC/OS-II的融合

本文1.1節已經介紹過，S3C2410的啟動代碼開始部分是匯編語言的初始化過程，然后跳轉到main（）函數。融合的工作就從改造S3C2410的main（）函數和μC/OS-II的 main（）函數（在 test.c中）開始。 在 S3C2410的main（）函數中，保留原啟動代碼中關于端口、內存、外部設備初始化代碼，刪去跳轉到Linux操作系統的代碼；在 μC/OS-II的 test.c文件的 main（）函數中，刪去一切與X86內核有關的初始化代碼和輸入輸出函數代碼（因為這部分代碼在S3C2410的啟動代碼中已經實現），并將 與 μC/OS-II內 核 有 關 的 3個 函 數 OSInit()、OSTaskCreate(…)、OSStart()復 制 到 S3C2410 的 main（）函 數中，同時刪去 μC/OS-II的 test.c文件。融合后的 main（）函數主要代碼如下：

至此，處理器已執行完S3C2410的啟動代碼,并開始執行μC/OS-II內核代碼。當然，要實現多任務，處理器的中斷必須是打開的。這個工作在OSStart()函數中完成，在執行OSStartHighRdy之前，要按照系統的需求完成處理器的中斷初始化工作，同時打開中斷。至此，融合工作基本完成，剩下的工作就是按照系統的需求在μC/OS-II的TaskStart（…）函數中自由添加實際工作所需的任務了。

在本文所述系統中，在μC/OS-II所帶3個系統任務的基礎上添加了3個任務Task1、Task2和 Task3，方法是在 OSStatInit()之前添加 OSTaskCreate(Task1,…)等代碼，然后按下述格式和自己的需求編寫Task1、Task2和Task3函數。代碼為：

因篇幅所限，無法詳述在融合過程中遇到的所有問題，尤其是在ADSv1.2環境下編譯、調試過程出現的語法問題和各種細節問題。

隨著科技的發展和實際任務復雜性的逐步增加，傳統的單片機前后臺編程模式漸漸不能滿足實際應用的要求。在嵌入式應用開發中使用嵌入式操作系統已經成為一種趨勢，本文在S3C2410開發板上將原有的引導程序和μC/OS-II操作系統結合在一起，開發出能自引導的μC/OS-II操作系統，該系統除了3個系統任務外，還自帶3個實際任務，在ADSV1.2環境下編譯、調試，并在板卡上成功運行，對μC/OS-II在ARM平臺上的移植有一定借鑒意義。

[1]任哲,潘樹林,房紅征,編著.嵌入式操作系統基礎 μC/OS-II和 Linux[M].北京：北京航空航天大學出版社，2007.

[2]韓山,郭云,付海艷,編著.ARM微處理器應用開發技術詳解與實例分析[M].北京：清華大學出版社，2007:284-286.

[3]蔣維.基于ARM S3C2410嵌入式系統的Bootloader分析與設計[J].電子工程師，2008(10).