目前，嵌入式技術已被廣泛應用到汽車電子、無線通信、數碼產品等各個領域。嵌入式操作系統及嵌入式處理器技術發展迅猛，嵌入式操作系統典型代表有μCOS—II、μClinux、Winclow CE、VxWorks等；嵌入式處理器包括ARM、MIPS、PowerPC等。隨著軟硬件技術的發展，人們開始意識到基于嵌入式操作系統的程序開發模式的便利性及可靠性，并且在程序開發過程中開始傾向于從傳統超循環開發模式轉向基于嵌入式操作系統的開發模式。
1 軟硬件開發環境及處理器介紹
1．1 軟件硬開發環境
本移植過程使用的軟件環境是RealView MDK開發套件，此產品是ARM公司最新推出的針對各種嵌入式處理器的軟件開發工具，該開發套件功能強大，包括了μVision3集成開發環境和RealView編譯器。使用的硬件平臺是深圳英蓓特公司推出的全功能評估板STMl03V100，其上所采用的處理器是ST意法半導體公司生產的32位哈佛結構ARM處理器STM32F103VBT6，該處理器內置ARM公司最新的Cortex—M3核，并且具有非常豐富的片上資源。
1．2 關于基于Cortex-M3" title="Cortex-M3">Cortex-M3的ARM處理器的介紹
基于Cortex—M3核的ARM處理器支持兩種模式，分別稱為線程模式和處理模式。程序可以在系統復位時或中斷返回時兩種情況下進入線程模式，而處理模式只能通過中斷或異常的方式來進入。處于線程模式中代碼可以分別運行在特權方式下和非特權方式下。處于處理模式中的代碼總是運行在特權方式下。運行在特權方式下的代碼對系統資源具有完全訪問權，而運行在非特權方式下的代碼對系統資源的訪問權受到一定限制。處理器可以運行在Thumb狀態或Debug狀態。在指令流正常執行期間，處理器處于Thumb狀態。當進行程序調試時，指令流可以暫停執行，這時處理器處于Debug狀態。處理器有兩個獨立的堆棧指針，分別稱為MSP和PSP。系統復位時總是處于線程模式的特權方式下，并且默認使用的堆棧指針是MSP。本移植過程中假設任務總是運行在線程模式的特權方式下且總是使用堆棧指針PSP。
2 移植過程詳解
2．1 μCOS-II內核介紹
μCOS—II是一個實時可剝奪型操作系統內核，該操作系統支持最多64個任務，但每個任務的優先級必須互不相同，優先級號小的任務比優先級號大的任務具有更高的優先級，并且該操作系統總是調度優先級最高的就緒態任務運行。此內核的代碼是美國人Jean J．Labrosse用C語言編寫的，具有很好的可移植性，其2．52版本通過了美國航天航空管理局的安全認證，可靠性非常高。文中所述的移植過程使用的就是該版本的源代碼。
2．2 開始移植
μCOS—II v2．52的源代碼按照移植要求分為需要修改部分和不需要修改部分。其中需要修改源代碼的文件包括頭文件OS_CPU．H、C語言文件OS_CPU．C以及匯編格式文件OS_CPU_A．ASM。
2．2．1 修改頭文件OS_CPU．H
頭文件OS_CPU．H中需要修改的內容有與編譯器相關的數據類型重定義部分和與處理器相關的少量代碼。由于本移植過程中使用的是RealView編譯器，因此通過查閱此編譯器的相關說明文檔可以得到其所支持的基本數據類型，據此修改OS_CPU．H中與編譯器相關的數據類型重定義部分。修改后代碼如下所示：
其中定義的數據類型OS_STK指出了處理器堆棧中的數據是32位的，OS_CPU_SR指出了處理器狀態寄存器字長也為32位。
頭文件中與處理器相關部分代碼包括臨界區訪問處理、處理器堆棧增長方向及任務切換宏定義。臨界區代碼訪問涉及到全局中斷開關指令，由文獻可以得知關中斷和開中斷可以分別由指令CPSID i和CPSIE i實現，文中臨界段訪問處理如下：
其中INT_DIS()和INT_EN()分別對應關中斷和開中斷處理過程。
根據文獻可知文中所使用的處理器支持的堆棧為滿遞減方式，即堆棧的增長方向是從內存高地址向低地址方向遞減并且堆棧指針總是指向棧頂的數據。在頭文件OS_CPU．H中相應代碼只須修改一條，如下所示
#define OS_STK_GROWTH1
此定義中的1代表堆棧方向是向下遞減的。
頭文件OS_CPU．H中最后一個要修改的地方是任務切換宏定義，μCOS—II內核就是通過這個宏調用來觸發任務級的任務切換。任務切換一般是通過陷阱或軟件中斷來實現的，在基于Cortex—M3核的處理器中支持一條稱為超級用戶調用的指令SVC，此指令是ARM軟件中斷指令SWI的升級版。此處的宏定義代碼修改為如下形式
#define OS_TASK_SW()OS_SVC()
其中OS_SVC()之中包含了SVC指令，它可以由嵌入匯編的方式在C語言代碼中進行定義，如下所示
_asm void OS_SVC(void){SVCOx00}
以上代碼以嵌入匯編的方式定義了一個輸入參數和返回值都為空的C語言函數，嵌入匯編的格式在RealView編譯器的說明文檔中有詳細的說明。
2．2．2 修改C語言文件OS_CPU．C
根據文獻可知文件OS_CPU．C中有10個C語言函數需要編寫，這些函數中唯一必要的函數是OSTaskStkInit，其他9個函數必須聲明，但不一定要包含任何代碼。為了簡潔起見，本移植過程只編寫了OSTaskStkInit，此函數的作用是把任務堆棧初始化成好像剛發生過中斷一樣。要初始化堆棧首先必須了解微處理器在中斷發生前后的堆棧結構，根據文獻易知微處理器在中斷發生前后的堆棧結構，并且可知寄存器xPSR、PC、LR、R12、R3、R2、R1、RO是中斷時由硬件自動保存的。初始化時需要注意的地方是xPSR、PC和LR的初值，對于其他寄存器的初值沒有特別的要求。xPSR比特位是Thumb狀態位，初始化時須置1，否則執行代碼時會引起一個稱為Invstate的異常，這是因為內置Cortex—M3核的微處理器只支持Thumb和Thumb2指令集。堆棧中PC和LR須初始化為任務的入口地址值，這樣才能在任務切換時跳轉到正確的地方開始執行。此函數可以用以下代碼來實現
2．2．3 修改匯編語言文件OS_CPU_A．ASM
匯編文件OS_CPU_A．ASM中需要編寫的函數分別為OSStartHighRdy、OSCtxSw、OSIntCtxSw和OSTickISR。第一個函數的作用是啟動多任務調度，此函數只在操作系統開始調度任務前執行一次，以后不再調用。按照文獻中所述須將堆棧中的寄存器依次彈出，然后執行一條中斷返回指令來開始第一個用戶任務的調度。但基于Cortex—M3核的ARM處理器在執行中斷返回指令時必須處于處理模式下，否則將會引起內存訪問異常。當系統上電啟動時或程序重置后，處理器會進入線程模式，而要在函數OSStartHighRdy中執行中斷返回指令就首先需要進行模式轉換，進入處理模式，而進行同步可控制模式轉換的途徑是超級用戶調用，即通過SVC指令產生軟件中斷可轉換到處理模式。實際上考慮到此函數只在啟動多任務調度開始前被調用一次，并且第一次調度任務運行時任務堆棧中除了xPSR、PC和LR的初值以外，其他寄存器的初值無關緊要。因此可以簡化該函數的編寫，只須從第一個任務的堆棧中取出該任務的首地址，然后修改堆棧指針使其指向任務堆棧中內存地址最高處，即相當于拋棄任務堆棧中所有數據，最后根據取出的地址直接跳轉到任務入口地址處開始執行。這樣可以免去軟件中斷和模式切換，從而簡化了對此函數的編寫。需要說明的是在拋棄任務堆棧中所用數據的同時也將xPSR的初值拋棄了，但這并不影響第一個任務投人運行，因為在跳轉到第一個任務運行之前，指令流是在Thumb狀態下正常執行的，xPSR已經有了確定的值。此函數代碼如下所示
BX r0；直接跳轉到第一個任務的入口地址
第二個匯編語言函數OSCtxSw是任務級的任務切換函數。若在任務執行過程中有一個比當前任務優先級更高的任務進入就緒態，μCOS—II內核就會啟動OSCtxSw進行任務切換。該函數會保存當前任務狀態，然后恢復那個優先級更高的任務狀態，使之投入運行。前述的宏定義#defineOS_TASK_SW()OS_SVC()中的OS_SVC()包含了SVC軟件中斷指令，此中斷的中斷向量應該設為函數OSCtxSw的入口地址，即OSCtxSw是SVC指令產生中斷的中斷服務程序，其源代碼如下
由于微處理器在進入中斷時按堆棧增長方向自動順序保存了如下8個寄存器：xPSR、PC、LR、R12、R3、R2、R1、R0，因此在程序中只須保存另外8個寄存器，保存順序可以隨意，但注意彈棧時要按照先進后出的方式進行。按照本文開頭的假定，任務總是運行在線程模式的特權方式下且總是使用堆棧指針PSP。而中斷產生后，中斷服務程序將處于處理模式下，并且默認使用的堆棧指針是MSP。因此在保存堆棧指針的時候需要保存的是當前任務的PSP。中斷返回前新任務的堆棧指針需要恢復到PSP中。中斷返回使用如下指令
MOVrO，#Oxfffffffd
BXr0
其中立即數#0xfffffffd包含了返回信息，用這兩條指令可以使中斷返回時使用任務堆棧指針PSP，返回后任務處于線程模式且使用任務堆棧指針PSP。
第三個匯編語言函數OSIntCtxSw與OSCtxSw類似。若任務執行過程中產生了中斷，且中斷服務程序使得一個比當前被中斷的任務具有更高優先級的任務就緒時，μCOS—II內核就會在中斷返回之前調用函數OSIntCtxSw。在此函數中不需要像任務級任務切換函數那樣保存當前任務狀態，因為當前任務已經被中斷，在進入中斷服務程序的時候任務狀態已被保存。其源代碼與函數OSctxSw中保存當前任務堆棧PSP指令以后部分相同，此處不再列出。
第4個匯編語言函數OSTickISR是系統時鐘節拍的中斷服務函數。處理器STM32F103VBT6中有一個專用系統時鐘節拍定時器SysTick，本移植過程使用此定時器產生每100 ms一次的時鐘節拍中斷。此函數源代碼如下
3 程序開發模式討論
傳統應用程序開發模式稱為超循環模式，即通常主程序是由C語言中的for語句或while語句構成的一個無限循環，程序在此循環中檢測事件的發生，從而轉向不同的任務。這種程序開發模式有兩個主要的不足之處。首先從程序維護和可靠性的角度來看，所有任務都需要程序開發人員來進行全局性的維護，當系統變得龐大和復雜時，任務的維護會變得非常麻煩，同時程序的可靠性也受到影響。其次，從任務級響應時間來看，這個時間是不確定的，因為程序在循環體中檢測事件發生的位置是固定的，但事件的發生是隨機的，因此從事件發生到程序檢測到事件發生這段時間也是不確定的。
在基于嵌入式操作系統的應用程序開發過程中，應用程序開發人員只需關心各個任務本身，而任務調度由操作系統代勞。以下的例子說明了基于μCOS—II嵌入式操作系統的應用程序開發模式
其中函數SysInit的作用是根據具體應用對處理器芯片進行必要的初始化，例如對系統的時鐘分配以及通用輸入輸出端口配置。函數OSInit是μCOS—II操作系統的內核初始化程序。第一個OSTaskCreate函數創建了任務Taskl，此任務的入口地址是Taskl，優先級是0。第二個OSTaskCreate函數創建了任務Task2，此任務的入口地址是Task2，優先級是1。函數OSTaskCrate還會將其創建的任務置于就緒態。文獻敘述了函數OSTa-skCreate的各個參數的含義。函數OSStart用于啟動多任務調度。OSTimeDly是μCOS—II內核提供的系統調用函數，用于延時或定時，這里的參數5表示延時5個時鐘節拍。應用程序開發人員需要做的就是通過調用μCOS—II內核提供的任務創建函數OSTaskCreate將編寫好的任務程序交給操作系統管理。
該例中在調用OSStart后，操作系統發現任務Taskl的優先級最高，于是操作系統就調度任務Taskl使其投入運行，而任務Task2暫時不能獲得處理器的使用權。任務Taskl首先點亮一個LED，然后延時一段時間，當運行到OSTimeDly處時，該任務被掛起而處于等待狀態，此時任務Task2成為優先級最高的就緒態任務，于是操作系統調度Task2運行。當5個時鐘節拍的延時時間結束時，系統時間節拍中斷服務子程序會重新將任務Taskl置于就緒狀態，此時任務Taskl再一次成為優先級最高的就緒態任務，于是操作系統保存任務Task2的狀態，并恢復任務Taskl的狀態使其又一次獲得處理器的使用權。此后程序執行過程將重復上述步驟?？梢钥吹?，在這個例子中的現象是某個LED燈不停的閃爍。
μCOS—II操作系統內核是實時可剝奪型的，這意味著在任務執行過程中或中斷服務子程序中，一旦有一個新的更高優先級的任務就緒，內核將立刻調度此新任務運行，這說明響應任務的時間是即刻的、確定的。
綜上所述，基于嵌入式操作系統的應用程序開發過程相對于以往傳統應用程序開發大為簡化而且任務級響應時間也得到最優化。
4 結束語
通過將移植過程中修改的μCOS—II內核代碼與上述例子中的應用程序代碼在μVision3集成開發環境中編輯整合后進行編譯、鏈接并且下載到目標硬件平臺進行長時間觀察，發現LED不停的閃爍，說明本移植過程是成功的。