整個移植工作可以分為兩個方面，一部分是和 ARM 相關，一部分是和移植原理相關。在開始實際的移植工作前，需要對這兩部分有一定的背景知識，尤其是和側重于和移植工作相關的概念和原理，下面分別做一些介紹。
ARM的體系結構
ARM（Advanced RISC Machines）是目前在嵌入式領域里應用廣泛的RISC微處理器結構，以其低成本、低功耗、高性能的特點占據了嵌入式系統應用領域的地位。ARM系列的處理器當前有ARM7、ARM9、ARM9E、ARM10等多個產品，此外ARM公司合作伙伴，例如Intel 也提供基于XScale微體系結構的相關處理器產品。所有的ARM處理器都共享ARM通用的基礎體系結構，所以開發者在不同的ARM處理器上做操作系統移植時，可以將節省相當多的工作量，這無疑將大大降低軟件開發成本。
要詳細完整的了解ARM的體系結構，當然是去讀 ARM Architectur Reference Manual ，這是一個13M 的pdf 文檔，有800多頁，可以從ARM的網站下載，也可以到北京亞嵌教育研究中心的FTP服務器( http://www.akae.cn/ftp/ )上找到。北航出的一本《ARM 嵌入式處理器結構與應用基礎》基本上翻譯了這個pdf中大部分重要的內容，可以作為入門的中文教材。這里我們僅僅對其中和移植工作密切相關的概念做簡要介紹。
1.處理器模式： ( cpu mode )
ARM 的處理器可以工作在 7 種模式，如圖1所示。
圖1
這里除 usr 模式以外的其他模式都叫做特權模式，除 usr 和 sys 外的其他5種模式叫做異常模式。在 usr 模式下對系統資源的訪問是受限制的，也無法主動地改變處理器模式。異常模式通常都是和硬件相關的，例如中斷或者是試圖執行未定義指令等。這里需要強調的是和移植相關的兩種處理器模式：svc態和 irq 態，分別指操作系統的保護模式和通用中斷處理模式。這兩種模式之間的轉換可以通過硬件的方式，也可以通過軟件的方式。uC/OS-II內核在執行過程中，大部分時間都是工作在 svc 態，當有硬件中斷，例如時鐘中斷到來時，cpu 硬件上會自動完成從svc態進入 irq態，在中斷處理程序的結束處，則需要通過編程的方法使得 cpu 從irq 態恢復到 svc 態，這個在移植代碼中可以找到。
2.程序狀態寄存器： ( PSR：Program status register )
在任何一種處理器模式中，都使用同一個寄存器來標識當前處理器的工作模式：這個寄存器叫做CPSR ( Current Program Status Register )，它的 [0--4] 位用來表示cpu mode，如圖2、圖3所示。
圖2
每一種處理器異常模式，都有一個對應的SPSR ( Saved Program Status Register )寄存器，用來保存進入異常模式前的CPSR。SPSR的作用就是當從異常模式退出時，可以通過一條簡單的匯編指令就能夠恢復進入異常模式前的CPSR，而這個值都是保存在當前異常模式的SPSR中的。例如：當從usr態進入中斷irq 態時，原先的 CPSR_all 將被保存在當前的 SPSR_irq中，類似的異常模式下的 SPSR 還有SPSR_fiq、SPSR_svc、SPSR_abt、SPSR_und。非異常模式的 usr和sys模式下沒有 SPSR，只有CPSR。不能顯式的指定把 CPSR 保存到某個異常模式下的 SPSR，比如 SPSR_irq，而必須是變更到 irq態之后cpu自動完成的，不能在其他態下硬性賦值，因為SPSR_irq是其他狀態下不可見的。
圖3
3.ARM寄存器：( register )
ARM處理器一共有37個寄存器，其中31個是通用寄存器，包括一個程序計數器 PC。另外6個就是上面提到的程序狀態寄存器。
a）通用寄存器：
i.R0－R7：與所有處理器模式無關的寄存器，可以用作任何用途。
ii.R8－R14：與處理器模式有關的寄存器，在不同的模式下，對應到不同的物理寄存器。其中 R13又叫做 sp，一般用于堆棧指針。R14又叫做lr，一般用于保存返回地址。這兩個寄存器在每種異常模式下都對應到不同的物理寄存器上，例如lr_irq、lr_svc、lr_fiq 等。
iii.R15：又叫做程序計數器，即pc，所有的模式下都使用同一個 pc。
b）狀態寄存器：
i.CPSR：當前程序狀態寄存器，所有的模式下都使用同一個 CPSR。
ii.SPSR：保存的程序狀態寄存器，每種異常模式下都有自己的SPSR，一共有5種SPSR，即SPSR_irq、SPSR_fiq、SPSR_svc、SPSR_abt、SPSR_und。usr和sys 態下沒有 SPSR 。
所有的ARM寄存器的命名和含義，可以用下面的這張表來說明，其中相同命名的都是同一個物理寄存器，不同命名的寄存器都對應不同的物理寄存器，如圖4所示。
圖4
uCOS-II 移植工作介紹
uCOS-II 實際上可以簡單地看作是一個多任務的調度器，在這個任務調度器之上完善并添加了和多任務操作系統相關的一些系統服務，如信號量、郵箱等。它的90%的代碼都是用C語言寫的，因此只要有相應的C語言編譯器，基本上就可以直接移植到特定處理器上，這也是uC/OS-II具有良好的可移植性的原因。移植工作的絕大部分都集中在多任務切換的實現上，因為這部分代碼主要是用來保存和恢復處理器現場（即相關寄存器），因此不能用C語言，只能使用特定的處理器匯編語言完成。
uCOS-II的全部源代碼量大約是6000－7000行，一共有15個文件。將 uC/OS-II 移植到ARM處理器上，需要完成的工作也非常簡單，只需要修改三個和ARM體系結構相關的文件，代碼量大約是500行。以下分別介紹這三個文件的移植工作：
1.OS_CPU.H 文件
數據類型定義
這部分的修改是和所用的編譯器相關的，不同的編譯器會使用不同的字節長度來表示同一數據類型，比如int，同樣在x86平臺上，如果用GNU的gcc 編譯器，則編譯為4 bytes，而使用MS VC＋＋則編譯為2 bytes。我們這里使用的是 GNU 的 arm-elf-gcc，這是一個免費并且開放源碼的編譯器。相關的數據類型的定義如下，如圖5所示。
圖5
堆棧單位
因為處理器現場的寄存器在任務切換時都將會保存在當前運行任務的堆棧中，所以OS_STK 數據類型應該是和處理器的寄存器長度一致的。
圖6
堆棧增長方向
堆棧由高地址向低地址增長，這個也是和編譯器有關的，當進行函數調用時，入口參數和返回地址一般都會保存在當前任務的堆棧中，編譯器的編譯選項和由此生成的堆棧指令就會決定堆棧的增長方向。
圖7
宏定義
包括開關中斷的宏定義，以及進行任務切換的宏定義。
圖8
2.OS_CPU_C.C 文件
任務堆棧初始化
這里涉及到任務初始化時的一個堆棧設計，也就是在堆棧增長方向上如何定義每個需要保存的寄存器位置，在ARM 體系結構下，任務堆棧空間由高至低依次將保存著pc、lr、r12、r11、r10、…r1、r0、CPSR、SPSR。
圖9
這里需要說明兩點，一是當前任務堆棧初始化完成后，OSTaskStkInit 返回新的堆棧指針stk，在OSTaskCreate（）執行時將會調用 OSTaskStkInit 的初始化過程，然后通過OSTCBInit（）函數調用將返回的sp指針保存到該任務的TCB塊中。二是初始狀態的堆棧其實是模擬了一次中斷發生后的堆棧結構，因為任務被創建后并不是直接就獲得執行的，而是通過OSSched（）函數進行調度分配，滿足執行條件后才能獲得執行的。為了使這個調度簡單一致，就預先將該任務的pc指針和返回地址lr都指向函數入口，以便被調度時從堆棧中恢復剛開始運行時的處理器現場。
圖10
系統hook函數
此外，在這個文件里面還需要實現幾個操作系統規定的hook函數，如下：
OSSTaskCreateHook( )
OSTaskDelHook( )
OSTaskSwHook( )
OSTaskStatHook( )
OSTimeTickHook( )
如果沒有特殊需求，則只需要簡單地將它們都實現為空函數就可以了。
3.OS_CPU_A.S 文件
OSStartHighRdy（）
此函數是在OSStart（）多任務啟動之后，負責從優先級任務的TCB控制塊中獲得該任務的堆棧指針sp，通過sp依次將cpu現場恢復，這時系統就將控制權交給用戶創建的該任務進程，直到該任務被阻塞或者被其他更高優先級的任務搶占cpu。該函數僅僅在多任務啟動時被執行一次，用來啟動個，也就是優先級的任務執行，之后多任務的調度和切換就是由下面的函數來實現。
OSCtxSw（）
任務級的上下文切換，它是當任務因為被阻塞而主動請求cpu調度時被執行，由于此時的任務切換都是在非異常模式下進行的，因此區別于中斷級別的任務切換。它的工作是先將當前任務的cpu現場保存到該任務堆棧中，然后獲得優先級任務的堆棧指針，從該堆棧中恢復此任務的cpu現場，使之繼續執行。這樣就完成了一次任務切換。
OSIntCtxSw（）
中斷級的任務切換，它是在時鐘中斷ISR（中斷服務例程）中發現有高優先級任務等待的時鐘信號到來，則需要在中斷退出后并不返回被中斷任務，而是直接調度就緒的高優先級任務執行。這樣做的目的主要是能夠盡快地讓高優先級的任務得到響應，保證系統的實時性能。它的原理基本上與任務級的切換相同，但是由于進入中斷時已經保存過了被中斷任務的cpu現場，因此這里就不用再進行類似的操作，只需要對堆棧指針做相應的調整，原因是函數的嵌套。
OSTickISR（）
時鐘中斷處理函數，它的主要任務是負責處理時鐘中斷，調用系統實現的OSTimeTick函數，如果有等待時鐘信號的高優先級任務，則需要在中斷級別上調度其執行。其他相關的兩個函數是OSIntEnter（）和OSIntExit（），都需要在ISR中執行。
ARMEnableInt（）& ARMDisableInt（）
分別是退出臨界區和進入臨界區的宏指令實現。主要用于在進入臨界區之前關閉中斷，在退出臨界區的時候恢復原來的中斷狀態。它的實現比較簡單，可以采用方法1直接開關中斷來實現，也可以采用方法2通過保存關閉/恢復中斷屏蔽位來實現。
我的移植體會
移植 uC/OS-II 的絕大部分工作都集中在 os_cpu_a.S 文件的移植，這個文件的實現集中體現了所要移植到處理器的體系結構和uC/OS-II 的移植原理；在這個文件里，困難的工作又集中體現在OSIntCtxSw 和 OSTickISR 這兩個函數的實現上。這是因為這兩個函數的實現是和移植者的移植思路以及相關硬件定時器、中斷寄存器的設置有關。在實際的移植工作中，這兩個地方也是比較容易出錯的地方。
OSIntCtxSw 重要的作用就是它完成了在中斷ISR中直接進行任務切換，從而提高了實時響應的速度。它發生的時機是在 ISR 執行到 OSIntExit 時，如果發現有高優先級的任務因為等待的 time tick 到來獲得了執行的條件，這樣就可以馬上被調度執行，而不用返回被中斷的那個任務之后再進行任務切換，因為那樣的話就不夠實時了。
實現 OSIntCtxSw 的方法大致也有兩種情況：一種是通過調整 sp 堆棧指針的方法，根據所用的編譯器對于函數嵌套的處理，通過精確計算出所需要調整的 sp 位置來使得進入中斷時所作的保存現場的工作可以被重用。這種方法的好處是直接在函數嵌套內部發生任務切換，使得高優先級的任務能夠快的被調度執行。但是這個辦法需要和具體的編譯器以及編譯參數的設置相關，需要較多技巧。
另一種是設置需要切換標志位的方法，在 OSIntCtxSw 里面不發生切換，而是設置一個需要切換的標志， 等函數嵌套從進入 OSIntExit => OS_ENTER_CRITICAL() => OSIntCtxSw() =>OS_EXIT_CRITICAL() => OSIntExit退出后，再根據標志位來判斷是否需要進行中斷級的任務切換。這種方法的好處是不需要考慮編譯器的因素，也不用做計算，但是從實時響應上不是快，不過剛開始學習這種方法比較容易理解，實現起來也簡單。SkyEye 目前的移植就是基于第二種方法的。
在中斷態下進行任務切換，需要特別說明的一個問題是如何獲得被中斷任務的 lr_svc 。因為進入中斷態后，lr 變成了lr_irq ，原來任務的 lr_svc 無法在中斷態下獲得，這樣要得到 lr_svc ，就必須在中斷ISR 里面進行一次 cpu mode 強制轉換，即對 CPSR 賦值為0x000000d3 ，只有返回到 svc 態之后才能得到 原來任務的 lr ，這個對于任務切換很重要。還有一個需要留意的問題是在強制 CPSR 變成 svc 態之后，SPSR 也會相應地變成 SPSR_irq ，這樣就需要在強制轉變之前保存 SPSR ，也就是被中斷任務中斷前的 CPSR 。
全部移植代碼在SkyEye仿真器上調試通過，在SkyEye的主頁上可以下載獲得。歡迎大家訪問我們的主頁 【 http://www.skyeye.org 】。 另外在 Linuxfans.org的論壇上 【http://www.linuxfans.org/bbs/forum-58-1.html 】， 有關于 SkyEye 進展的討論， 和另一個嵌入式開源項目【www.lumit.org 】的大量資料下載， 【 http://www.linuxfans.org/bbs/forum-66-1.html 】。希望大家對我們的工作提出建議和批評，更希望有越來越多的人關注和參與進來。
總結
移植 uC/OS-II到 SkyEye 上，既是對 uC/OS-II 的學習和實驗，同時也是對 SkyEye仿真器的驗證和實踐。uC/OS-II 作為一個的實時操作系統已經被移植到各種體系結構的微處理器上，也是目前較為常用的公開源碼的實時內核。從這里入手學習嵌入式系統開發的基本概念，以及在 SkyEye 里構造一個可以運行的RTOS，能夠使我們更深入地了解嵌入式開發的流程，在沒有硬件的條件下也能對ARM的體系結構有個初步的認識。