mC/OS-II操作系統向ARM7開(kāi)發(fā)平臺的移植

在ARM工程開(kāi)發(fā)中，為了實(shí)現功能復雜的資源復用，提高軟件功能設計效率，簡(jiǎn)化開(kāi)發(fā)難度，需要采用高性能的實(shí)時(shí)嵌入式操作系統mC/OS-II作為軟件設計平臺。因此，將mC/OS-II移植到ARM開(kāi)發(fā)平臺是一項難度極高但十分必要的工作。通常移植工作對開(kāi)發(fā)人員有非常高的要求，開(kāi)發(fā)人員不僅要熟練掌握嵌入式系統的開(kāi)發(fā)模式和方法，而且還要對操作系統、處理器和硬件系統的特性有深入的認識和研究。mC/OS-II移植工作已由作者獨立完成，在實(shí)際應用后，證明mC/OS-II工作十分穩定。
移植的硬件平臺采用高性能ARM7TDMI內核的AT91m40800嵌入式處理器，開(kāi)發(fā)調試平臺采用ARM SDT2.51，軟件平臺采用實(shí)時(shí)嵌入式操作系統mC/OS-II。

mC/OS-II實(shí)時(shí)操作系統的結構及可移植性分析
mC/OS-II操作系統特點(diǎn)
mC/OS-II是一個(gè)高性能的嵌入式實(shí)時(shí)操作系統，是由多任務(wù)、多中斷和高效實(shí)時(shí)內核組成的一個(gè)有機整體。應用系統在實(shí)時(shí)內核的統一管理下協(xié)調工作，能夠高效地實(shí)現任務(wù)切換、任務(wù)調度、任務(wù)間通信、同步、互斥、實(shí)時(shí)時(shí)鐘管理、中斷管理等功能。
為了提高系統的實(shí)時(shí)能力，mC/OS-II可以將一個(gè)復雜的應用劃分為多個(gè)相互獨立的任務(wù)，并根據任務(wù)的重要性來(lái)分配優(yōu)先級。每個(gè)任務(wù)擁有自己的堆?？臻g，并且當前任務(wù)運行時(shí)獨占CPU資源。任務(wù)的調度完全由mC/OS-II的實(shí)時(shí)內核完成，主要包括任務(wù)的狀態(tài)管理、選擇最高優(yōu)先權的任務(wù)、執行任務(wù)和撤消任務(wù)等。mC/OS-II內核還負責CPU時(shí)間分配，CPU時(shí)間總是優(yōu)先分配給中斷事件，其次是任務(wù)隊列中當前優(yōu)先級最高的任務(wù)。不同任務(wù)間的通信可以通過(guò)mC/OS-II提供的信號量、郵箱、消息隊列等機制完成。
作為一個(gè)優(yōu)秀的實(shí)時(shí)操作系統，mC/OS-II具有如下優(yōu)點(diǎn)：
?可移植—絕大部分的mC/OS-II代碼由ANSI C編寫(xiě)，只有和處理器相關(guān)的部分才使用匯編，這使得mC/OS-II便于移植；
?可裁減—如果只使用部分功能，可以通過(guò)條件編譯來(lái)裁減mC/OS-II的代碼；
?多任務(wù)—mC/OS-II可以管理64個(gè)任務(wù)，目前系統保留了8個(gè)，用戶(hù)的應用程序最多可以有56個(gè)任務(wù)。每個(gè)任務(wù)的優(yōu)先級不同，這意味著(zhù)mC/OS-II不支持時(shí)間片輪轉調度法；
?占先式—mC/OS-II是占先式的實(shí)時(shí)內核，它總是運行就緒條件下優(yōu)先級最高的任務(wù)；
?可確定性—mC/OS-II的全部函數調用與服務(wù)的時(shí)間是可知的，mC/OS-II系統服務(wù)的時(shí)間不依賴(lài)于應用程序任務(wù)的多少；
?任務(wù)?！總€(gè)任務(wù)有自己?jiǎn)为毜亩褩＃?BR>?系統服務(wù)—mC/OS-II提供郵箱、消息隊列、信號量、塊大小固定的內存申請與釋放、時(shí)間相關(guān)函數等；
?中斷管理— 中斷可以使正在執行的任務(wù)掛起，可能會(huì )在中斷結束的時(shí)候發(fā)生任務(wù)切換，中斷嵌套層數可達255層；
?穩定性與可靠性—mC/OS -II和mC/OS自1992年以來(lái)已經(jīng)有幾百個(gè)商業(yè)應用；
?公開(kāi)源代碼—使得系統在商業(yè)應用中具有明顯的價(jià)格優(yōu)勢。
mC/OS-II的硬件和軟件體系結構及可移植性分析
圖1說(shuō)明了mC/OS-II的結構及其與硬件的關(guān)系。
由圖1可以看出，mC/OS-II的移植的主要工作是修改與處理器相關(guān)部分的代碼，它們集中在三個(gè)文件中。其中，OS_CPU.H包含與處理器相關(guān)的常量、宏和結構體的定義；OS_CPU_C.C和 OS_CPU_ASM中定義了用于底層的任務(wù)切換，退出中斷服務(wù)程序，在CPU級屏蔽中斷、打開(kāi)中斷，對任務(wù)棧初始化以及時(shí)鐘的中斷服務(wù)程序的函數。
為了使應用程序運行于mC/OS-II上，還要相應地修改應用中使用的硬件設備驅動(dòng)。
要使mC/OS-II正常運行，處理器必須滿(mǎn)足以下要求：
1． 處理器的C編譯器能夠產(chǎn)生可重入代碼。
2． 用C語(yǔ)言就可以打開(kāi)和關(guān)閉中斷。
3． 處理器支持中斷，且能產(chǎn)生定時(shí)中斷(通常在10~100Hz之間)。
4． 處理器支撐能夠容納一定容量數據(可能是幾千字節)的硬件堆棧。
5． 處理器有將堆棧指針和其他CPU寄存器讀出，并存儲到堆?；騼却嬷械闹噶?。
ARM7處理器及開(kāi)發(fā)環(huán)境ARM SDT2.51所使用的編譯器armcc可以滿(mǎn)足上述要求。但是根據對mC/OS-II工作原理的分析，上述第3點(diǎn)并不是運行mC/OS-II所必需的。如果應用中不需要定時(shí)器，就沒(méi)有必要在系統中加入時(shí)鐘節拍功能。在某些系統中沒(méi)有使用時(shí)鐘節拍，應用中任務(wù)的切換完全依靠任務(wù)間的消息機制來(lái)完成，這大大提高了系統的實(shí)時(shí)性。上述要求是能夠移植mC/OS-II全部代碼的條件。
下面將結合mC/OS-II中與操作系統有關(guān)部分的功能分析、ARM7處理器體系結構說(shuō)明mC/OS-II向ARM SDT開(kāi)發(fā)環(huán)境的移植。

mC/OS-II向ARM SDT2.51開(kāi)發(fā)環(huán)境的移植
將mC/OS-II向ARM移植，需要修改與處理器相關(guān)的數據類(lèi)型和函數。修改數據類(lèi)型的聲明，需要對ARM處理器的字長(cháng)及開(kāi)發(fā)平臺編譯器使用的數據類(lèi)型進(jìn)行綜合分析。修改與處理器相關(guān)的函數，需要對ARM處理器體系結構，ARM匯編程序的編寫(xiě)，操作系統在任務(wù)或中斷切換時(shí)對被中斷的任務(wù)的現場(chǎng)保護和恢復機制進(jìn)行綜合分析。下文將結合ARM處理器說(shuō)明數據類(lèi)型及相關(guān)函數的修改。
數據類(lèi)型及宏的聲明
移植中對OS_CPU.H的修改主要是，改變了與處理器有關(guān)的數據類(lèi)型和宏定義。
由于不同處理器有不同字長(cháng)，mC/OS-II的移植需要重新定義一系列的數據類(lèi)型。使用armcc編譯器，Char類(lèi)型長(cháng)度8位，Short類(lèi)型長(cháng)度16位，Int和Long類(lèi)型長(cháng)度32位。ARM寄存器都是32位的，所以將堆棧數據類(lèi)型OS_STK聲明為32位。所有的堆棧都必須使用OS_STK聲明。
在該文件中，還將開(kāi)關(guān)中斷的宏OS_ENTER_CRITICAL和OS_EXIT_CRITCAL定義為OS_CPU_ASM.S中的函數ARMDisableINT和ARMEnableINT。
mC/OS-II任務(wù)堆棧及任務(wù)切換
ARM處理器模式及寄存器
ARM處理器共有7種運行模式，如表1所示。
mC/OS-II作為操作系統可以工作在sys模式和svc模式下。
ARM處理器共有31個(gè)通用寄存器(包括程序計數器PC)和6個(gè)狀態(tài)寄存器(PSR)，具體組成為：
?未備份寄存器R0~R7。在所有的處理器模式下指的都是同一個(gè)物理寄存器。
?備份寄存器R8~R12。每個(gè)寄存器對應兩個(gè)不同的物理寄存器。   
?R13和R4，每個(gè)寄存器對應6個(gè)不同的物理地址，usr模式和sys模式公用一個(gè)物理寄存器，其余每個(gè)模式有各自的R13和R14。寄存器R13常用做棧指針(sp)，R14存放函數或異常模式的返回地址。
?程序計數器R15。
?當前程序狀態(tài)寄存器(CPSR)和5個(gè)備份程序狀態(tài)寄存器(SPSR)。
mC/OS-II任務(wù)堆棧
mC/OS-II為每個(gè)任務(wù)建立堆棧，用于保存處理器的寄存器。其結構體定義為OS_STK[16]，保存處理器工作模式(svc模式)的R0~R12、R14、CPSR和SPSR。
mC/OS-II在OS_CPU_C.C中由任務(wù)堆棧初始化函數OSTaskStkInit，需要將任務(wù)棧內的CPSR和SPSR設為svc模式。
mC/OS-II的任務(wù)切換
mC/OS-II的任務(wù)調度函數OSShed()獲得當前就緒的優(yōu)先級最高任務(wù)的TCB(任務(wù)控制塊)指針，存入全局變量OSTCBHighRdy，將當前任務(wù)的TCB指針存入OSTCBCur。然后調用函數OS_TASK_SW()進(jìn)行最底層的任務(wù)切換。
OS_CPU_ASM.S內的任務(wù)切換函數OS_TASK_SW()完成的工作有兩步：將被掛起任務(wù)的微處理器寄存器推入任務(wù)堆棧(OSTCBCur->OSTCBSTK)，然后將較高優(yōu)先級的任務(wù)的寄存器從棧(OSTCBHighRdy->OSTCBSTK)恢復到寄存器。
屏蔽中斷與開(kāi)中斷
PSR寄存器格式說(shuō)明
程序寄存器構造如下：
位  31  30  29  28  27-----
      N    Z   C    V  
-----7  6  5  4  3  2  1  0
       I  F  T   工作模式
I位為1屏蔽處理器的外部中斷，為0允許外部中斷。
F位為1屏蔽處理器的快速中斷，為0允許快速中斷。
屏蔽中斷與開(kāi)中斷
OS_CPU_ASM.S中的屏蔽中斷函數ArmDisableInt()將CPSR的I位置1實(shí)現在處理器級將中斷屏蔽；開(kāi)中斷函數ArmEnableInt()將CPSR的I位置0允許處理器響應中斷。
進(jìn)入中斷程序和中斷返回程序
ARM處理器的中斷處理程序
處理器響應IRQ異常中斷時(shí)的處理過(guò)程是，在irq模式的R14保存程序返回的地址；在irq模式的SPSR保存CPSR；切換到irq模式，將CPSR中斷位(I位)置1，跳轉到中斷向量的地址。
mC/OS-II的中斷服務(wù)程序
在OS_CPU_ASM.S中的時(shí)鐘中斷服務(wù)程序OSTickISR是標準的中斷服務(wù)程序，函數的入口寫(xiě)入AIC的中斷向量表，其實(shí)現的過(guò)程是：向m40800的AIC_IVR寫(xiě)入任意的數，讀取m40800的狀態(tài)寄存器清除中斷，保護CPU寄存器入棧，調用OSIntEnter對中斷嵌套標志加1。調用中斷服務(wù)程序OSTimeTick，調用OSIntExit判斷是否需要任務(wù)切換，如果需要會(huì )調用OSIntCtxSW來(lái)進(jìn)行任務(wù)切換。此處沒(méi)有調用任務(wù)切換函數OS_TASK_SW()是因為CPU寄存器入棧的工作已經(jīng)在進(jìn)入中斷時(shí)完成。
OSIntCtxSW是OS_CPU_ASM內的函數，完成的工作如下：向m40800的AIC_EOICR寄存器寫(xiě)入值，將IRQ棧內保存的中斷CPU寄存器的值寫(xiě)入被中斷的任務(wù)棧，將就緒的高優(yōu)先級的任務(wù)棧內容寫(xiě)入對應的CPU寄存器。
OSTickISR是標準的中斷服務(wù)程序，其他設備的中斷服務(wù)程序可以仿照這一程序的結構編寫(xiě)，只是對應的設備寄存器地址不同。
測試mC/OS-II內核
基于上述分析，對與處理器有關(guān)的4個(gè)匯編函數(ArmIntEnter，ArmIntExit，OSIntCtxSw，OS_Task_Sw)，一個(gè)C函數(OSTaskStkInit)及相關(guān)的數據類(lèi)型和宏定義進(jìn)行分析修改就是mC/OS-II移植需要做的工作。
一旦代碼移植結束，下一步工作就是測試。測試一個(gè)mC/OS-II的多任務(wù)實(shí)時(shí)內核需要細致地考慮測試步驟。調試的過(guò)程應該由簡(jiǎn)到繁，可以從一些最簡(jiǎn)單的任務(wù)，甚至在沒(méi)有應用程序的情況下開(kāi)始測試。這樣做有兩個(gè)好處：第一，避免使原本復雜的事情更加復雜；第二，如果出現問(wèn)題，可以知道問(wèn)題出現在內核代碼上而不是應用程序。剛開(kāi)始的時(shí)候，可以添加一些簡(jiǎn)單的任務(wù)和時(shí)鐘節拍的中斷服務(wù)例程。一旦多任務(wù)調度成功運行了，再添加應用程序就非常簡(jiǎn)單了。
在實(shí)際測試中，按照由簡(jiǎn)到繁的過(guò)程不斷使測試變得復雜，如下所述：
1. 添加三個(gè)任務(wù)，每個(gè)任務(wù)通過(guò)m40800的一個(gè)PIO口控制一個(gè)LED，在三個(gè)任務(wù)間互拋信號量。測試mC/OS-II系統內任務(wù)調度，任務(wù)間通信機制是否工作正確；測試移植的任務(wù)棧結構和任務(wù)切換函數OS_Task_SW是否正確(見(jiàn)圖2)。
2. 在上一步的基礎上，打開(kāi)時(shí)鐘中斷，但沒(méi)有任務(wù)調用OSTimeDly等與時(shí)鐘中斷有關(guān)的操作。在時(shí)鐘中斷的OSTimeTickHook中通過(guò)一個(gè)PIO控制一個(gè)LED的亮滅。測試時(shí)鐘中斷的中斷服務(wù)程序OSTimeTickISR和中斷后沒(méi)有任務(wù)切換的情況系統運行是否正確(見(jiàn)圖3)。
3. 在上一步的基礎上，三個(gè)基本任務(wù)中的延時(shí)使用OSTimeDly實(shí)現，即在時(shí)鐘中斷的中斷服務(wù)程序完成后需要任務(wù)切換。測試移植的OSIntCtxSW是否正確(見(jiàn)圖4)。
4. 在上一步的基礎上，加入第四個(gè)任務(wù)Task4和串口收數中斷，在中斷服務(wù)程序中將收到字節放入郵箱，在Task4等待郵箱，被喚醒后從串口發(fā)出收到的字節。這種情況接近一般工程設計的應用情況(見(jiàn)圖5)。

mC/OS-II向其他基于A(yíng)RM7內核芯片的移植
以上所述的移植工作大部分針對ARM7內核，但其中涉及到中斷控制器及時(shí)鐘控制器的代碼是針對Atmel公司的AT91m40800芯片的專(zhuān)用外設編寫(xiě)的，在向其他基于A(yíng)RM7內核的芯片移植mC/OS-II時(shí)，只需修改相關(guān)外設的驅動(dòng)程序或系統中OS_CPU文件的相關(guān)代碼即可。在使用中，還完成了將mC/OS-II向三星公司的S3C44B0芯片移植的工作?！?/P>