摘要：Cortex-M3是ARM公司最新推出的基于ARMv7-M架構的低功耗處理器。在深入了解μC/OS-II工作原理和Cortex-M3特性的基礎上，給出了在STWl32F103ZE處理器上的詳細移植過程。將移植后的μC/OS-Ⅱ操作系統應用于移動多媒體直放站CMMB項目中，驗證了移植的成功。這對于管理硬件資源，縮短開發周期和提高系統穩定性方面有著重要的意義。
嵌入式系統已經廣泛滲透到了人們工作、生活中的各個領域，嵌入式處理器已占分散處理器市場份額的94％，其中ARM的應用最為廣泛。基于ARM內核的處理器以其諸多優異性能而成為各類產品中選用較多的處理器之一。
當系統越來越大，應用越來越多時，就出現了如何管理眾多的硬件資源，以及如何滿足系統的實時控制要求和如何提高系統軟件開發效率等不可回避的問題。這時，使用嵌入式操作系統很有必要。操作系統的主要作用有：統一管理系統資源；為用戶提供訪問硬件的接口；調度多個應用程序和管理文件系統等。
1 概述
μC/OS-II是著名的、源碼公開的實時內核，是專為嵌入式應用設計的，可用于各類8位、16位和32位處理器。μC/OS-II已經在世界范圍內得到廣泛使用，包括諸多領域，如手機、飛行器、醫療設備及工業控制等。實際上，μC/OS-II已經通過了非常嚴格的測試，并且得到了美國航空管理局的認證，可以用在飛行器上。這說明μC/OS-II是穩定可靠的。
Cortex-M3是一款低功耗處理器，具有門數目少，中斷延遲短，調試成本低的特點，是為要求有快速中斷響應能力的深度嵌入式應用而設計的。該處理器采用最新的ARMv7-M架構。還具有如下特性：
(1)采用Thumb-2指令集。在Thumb-2中，16位指令首次與32位指令并存，代碼密度得到很大改善。
(2)Cortex-M3處理器可配置為具有SW-DP或JTAG-DP調試端口。
(3)使用可選的MPU對處理器提供存儲器保護。
(4)具有嵌套向量中斷控制器(NVIC)，低延遲的異常處理。
本論文采用的是意法半導體ST公司生產的基于Cortex-M3內核的STM32F103ZE處理器，詳細論述了μC/OS-Ⅱ的移植過程。編譯環境采用的是RVMDKV3．7。
2 移植工作
所謂移植，就是使一個實時內核能在指定的微處理器上運行。為了方便移植，大部分μC/OS-II的代碼都是用C語言編寫的，但是仍需要用C語言和匯編語言編寫一些與處理器硬件相關的代碼。μC／OS-II是第一個支持Cortex的RTOS，圖1顯示應用程序、μC/OS-II、port和BSP四者之間的關系。具體移植工作主要涉及到頭文件OS_CPU．H、C語言文件OS_CPU_C．C以及匯編格式文件OS_CPU_A．ASM。
2. 1 OS_CPU.H
OS_CPU．H包含處理器需要的用#defines語句定義的、與處理嘉相關的常數、宏以及類型。因為不同的處理器有不同的字長，μC/OS-II的移植包括了一系列的數據類型定義，以確保其可移植性。μC/OS-II內核代碼不使用C語言中的short、int及long等數據類型，因為它們是編譯器相關的，是不可移植的。Cortex-M3是32位處理器，同時參照RVMDK編譯器文檔，對μC/OS-II內核中的數據類型作如下定義：
…
typedef unsigned int OS_STK；
typedef unsigned int OS_CPU_SR；
OS_STK定義的是32位寬的堆棧入口地址數據類型，OS_CPU_SR定義的是32位寬的Cortex-M3處理器狀態寄存器數據類型。
和所有的實時內核一樣，μC/OS-II為了訪問臨界區的代碼需要關閉中斷，訪問完，重新使能中斷。為了增加可移植性，μC/OS-II定義了兩個宏分別關閉和使能中斷一OS_ENTER_CRITICAL()、OS_EXIT_CRITICAL()。μC/OS-II定義了三種關閉和使能中斷方法，只需要使用其中一個。多數情況下，推薦使用OS_CRITICAL_METHOD#3。
OS_CRITICAL_METHOD#3通過寫一個保存CPU狀態寄存器在一個臨時變量里的函數，實現OS_ENTER_CRITICAL()。OS_EXIT_CRITICAL()調用另一個函數從臨時變量恢復CPU狀態寄存器。
絕大多數微處理器和控制器的堆棧是從上往下遞減的，但是也有些處理器使用的是相反的方式。μC/OS-II對兩種都可以處理，只要配置常數OS_STK_GROWTH指定堆棧的方向就可以了。ARM Cortex-M3的堆棧增長是從高內存地址往低內存地址，因此，OS_STK_GROWTH應該設置為l。
2. 2 OS_CPU_C．C
移植μC/OS-Ⅱ要求編寫10個簡單的C語言函數，但唯一必要的函數是OSTaskStkInit()，其他9個函數必須申明，但并不一定要包含任何代碼，允許用戶在必要時添加擴展OS功能的代碼。
OSTaskCreate()和OSTaskCreateExt()通過調用OSTaskStklnit()，初始化任務堆棧。因此，堆棧看起來像中斷剛發生過一樣，所有寄存器都保存在堆棧中。多數CPU寄存器的初始值并不重要，但是為了方便調試和檢查堆棧，用寄存器序號去初始化它們。寄存器的順序是重要的，應該和ARM Cortex-M3在發生異常時的堆棧順序一樣。
2. 3 OS_CPU_A．ASM
移植μC／OS-II要求編寫5個簡單的匯編語言函數。
OS_CPU_SR_Save()
OS_CPU_SR_Restore()
OSStartHighRdy()
OSCtxSw()
OSIntCtxSw()
OS_CPU_SR_Save()按照OS_CRITICAL_METHOD#3的方式，首先保存中斷屏蔽寄存器，接著關閉中斷。這個函數被宏OS_ENTER_CRITICAL()調用。當這個函數返回時，RO包含關閉中斷前的中斷屏蔽寄存器的狀態。
OS_CPU_SR_Restore()恢復在調用OS_ENTER_CRITICAL()之前中斷屏蔽寄存器的原值。也就是說，若在調用OS_ENTER_CKJTICAL()之前中斷是關閉的，調用之后仍是關閉的。
OSStart()調用OSStartHighRdy()來運行在調用OSStart()之前創建的最高優先級任務。OSStart()設置OSTCBHighRdy指向最高優先級任務的OS_TCB。
當一個任務放棄對CPU的控制時，OS_TASK_SW()宏被調用，實際最終調用的是OSCtxSw()函數。通常，OSCtxSw()應該實現任務上下文切換，但是在ARM Cortex-M3中，所有的上下文切換由pendSV句柄來完成。OSCtxSw()僅僅觸發PendSV句柄，再返回到調用處。
ISR完成后，調用OSIntExit()查看是否有比中斷任務更重要的任務需要去執行。若確實如此，OSIntExit()調用OSIntCtxSw()決定下一步將要運行哪一個任務。然而，和OSCtxSw()一樣，僅僅觸發PendSV句柄，再返回到調用處。
限于篇幅，不詳細列出5個函數的源代碼。
2．4 PendSV句柄及系統滴答
PendSV句柄函數為μC/OS-Ⅱ實現所有的上下文切換。這是ARM Cortex-M3推薦的上下文切換方法。這是因為ARM Cortex-M3發生任何異常時，自動保存多個寄存器，異常返回時自動恢復這些寄存器。PendSV僅僅需要保存R4-Rll和調整堆棧指針。不管是任務的初始化還是中斷或異常引發的PendSV異常都是采用同樣的方法實現保存和恢復上下文。
μC/OS-Ⅱ要求用戶提供一個周期性的時鐘源來實現時間的延時和超時功能。Cortex-M3的系統滴答定時器是專門為RTOS設計的。可以在OSStart()運行后，μC/OS-II啟動運行的第一個任務中調用OS_CPU_SysTickInit()初始化系統滴答定時器并使能中斷。
需要注意的是：在系統啟動代碼中，初始化中斷向量時，向量14和15應放置PendSV和SysTick對應的句柄。
3 測試移植代碼
至此，基本完成移植源代碼的編寫和修改，緊接著的工作就是驗證移植的μC/OS-Ⅱ是否正常工作，而這可能是移植中最復雜的一步。應該首先不加任何應用代碼來測試移植好的μC/OS-Ⅱ，也就是說測試內核自身的運行情況。若有些部分沒有正常工作，可以明白是移植本身的問題，而不是應用代碼產生的問題。若將基本的任務和時鐘節拍運行起來，接下來添加應用任務將是非常簡單的。
首先在RVMDK中建立新工程，添加STM32F103ZE的啟動代碼，確保C編譯器、匯編器和鏈接器能正常工作。將μC/OS-II移植代碼添加到工程中，使用源代碼調試器逐一驗證移植函數。工程管理窗口如圖所示：
4 結語
在成功驗證移植代碼之后，將μC/OS-II應用于移動多媒體直放站CMMB項目中，系統穩定運行，說明本移植是成功的。在CMMB項目采用μC/OS-Ⅱ實時操作系統，提高了研發效率，增強了系統的可維護性和擴展性。