在MOTOROLA A68K系列MCU上移植μC/OS-II

一、MC68K CPU簡介

MC68K及68020、68040等的著名的MOTOROLA32位微處理器，和與之兼容的68K、CPU32、CPU32+等CPU擴充定時處理單元TPU、隊列串行模塊QSM、系統(tǒng)控制模塊和RAM等組成MC683xx系列單片機。

CPU32 內(nèi)部有8個32位通用數(shù)據(jù)寄存器，8個32位通用地址寄存器。8個通用數(shù)據(jù)寄存器可作為累加器使用，也可看成C語言中各種類型的變量；8個通用地址寄存器，可作為變址寄存器使用，也可看成C語言中的指針型變量。CPU32有獨立的用戶堆棧指針和系統(tǒng)堆棧指針，可區(qū)分程序區(qū)、數(shù)據(jù)區(qū)、系統(tǒng)區(qū)、用戶區(qū)等存儲空間，有7級中斷。

要實現(xiàn)μC/OS-II向MC68K的移值，需要有MC68K的C編譯器。我們使用的HIWARE公司的C編譯器。該C編譯器允許嵌入行匯編。

二、移植中所需修改的文件

和CPU相關的文件主要有三個：C語言文件OS_CPU32.C、頭文件OS_CPU32.H和匯編文件OS_CPU32.ASM。

1.INCLUDES.H文件

INCLUDES.H 是主頭文件，在所有后綴名為.C文件的開始都包含INCLUDES.H文件。對于不同類型的處理器，用戶需要改定INCLUDES.H文件，增加自己的頭文件，但必須加在文件末尾。在安裝μC/OS-II的時候，附帶了幾個移植實例，例如，針對Intel 80x86的代碼安裝到IIL目錄。我們?yōu)镸C68K編寫的移植實例都放在II下，在INCLUDES.H文件中增加有：
#include "iiK_CPU32.ASM"
#include "iiK_CPU32.C"
#include "iiK_CPU32.H"

2.OS_CPU32.H文件
OS_CPU32.H文件中定義了與硬件相關的基本信息：
typedef unsigned char INT8U； /*無符號8位數(shù)*/
typedef signed char INT8S； /*帶符號8位數(shù)*/
typedef unsigned int INT16U； /*無符號16位數(shù)*/
typedef signed int INT16S； /*帶符號16位數(shù)*/
typedef signed long INT32S； /*帶符號32位數(shù)*/
typedef unsigned int OS_STK； /*堆棧入口寬度為16位*/
#define OS_STK_GROWTH1 /*堆棧由高地址向低地址增長*/
#define UCOS 0 /*用于任務切換的軟中斷*/
define OS_TASK_SW() _TRAP(UCOS)
#define OS_ENTER_CRITICAL() move.w#$2700,SR /*進入臨界區(qū)*/
#define OS_EXIT_CRITICAL() move.w #$2000,SR /*退出臨界區(qū)*/

（1）數(shù)據(jù)類型

由于不同的處理器有不同的字長，μC/OS-II的移植需要重新定義一系列的數(shù)據(jù)結構。由于 MC68K為32位MCU，整數(shù)（int）類型數(shù)據(jù)為16位，長整開有（long）為32位。在MC68K中堆棧都是按字進行操作的，所以堆棧數(shù)據(jù)類型 OS_STK聲明為16位。所有的堆棧必須用OS_STK聲明。

（2）代碼臨界區(qū)

μC/OS -II在進入系統(tǒng)臨界代碼區(qū)之間要關中斷，等到退出臨界區(qū)后再打開，從而保護核心數(shù)據(jù)不被多任務環(huán)境下的其他任務或中斷破壞。在MC68K中，開關中斷可以通過設置狀態(tài)寄存器SR中的中斷屏蔽位來實現(xiàn)。μC/OS-II中的宏OS_ENTER_CRITICAL（）定義將狀態(tài)寄存器的中斷屏蔽位置位，屏蔽所有的七級中斷；OS_EXIT_CRITICAL（）定義將狀態(tài)寄存器的中斷屏蔽位清零，打開所有的七級中斷。這種處理方法非常簡單，但CPU32提供分級中斷機制得不到使用。如果要使用分級中斷，必須改寫一些相關的函數(shù)，將在第4節(jié)中闡明。

（3）堆棧方向

MC68K處理器的堆棧是由高地址向低地址遞減的，所以OS_STK_GROWTH必須設置為1。

（4）OS_TASK_SW（）函數(shù)的定義

在μC/OS -II中，OS_TASK_SW（）用來實現(xiàn)任務切換。就緒任務的堆棧初始化應該模擬一次中斷發(fā)生后的樣子，椎棧中應該按入棧次序設置好各個寄存器。 OS_TASK_SW（）函數(shù)模擬一次斷過程，在中斷返回的進修進行任務切換。CPU32有16個軟中斷可供選用，稱為陷阱TRAP調(diào)用。中斷程序程序的入口必須指向匯編函數(shù)OSCtxSw()。

我們在μC/OS-II所提供的例程中使用的0號陷阱調(diào)用，由下面的語句完成定義：

#define OS_TASK_SW() -TRAP(UCOS)

3.OS_CPU32.ASM文件

μC/OS-II的移植需要用戶改寫OS_CPU_A.ASM中的4個函數(shù)：OSStartHighRdy()、OSCtxSw()、OSIntCtxSw()和OSTickISR()。

（1）OSStartHighRdy()函數(shù)

該函數(shù)由OSStart()函數(shù)調(diào)用，功能是運行優(yōu)先級最高的就緒態(tài)任務。在調(diào)用OSStart() 之前，用戶必須先調(diào)用OSInit()，并且已經(jīng)至少創(chuàng)建了一個任務。為啟動任務，OSStartHighRdy（）首先找到當前就緒的優(yōu)先級最高的任務，OSTCBHighRdy中保存有優(yōu)先級最高任務的任務控制塊（TCB）的地址，并從任務的任務控制塊中找到指向堆棧的指針，然后運行指令 MOVEM.L（A7）+，A0-A6/D0-D7，從堆棧中彈出全部寄存器的內(nèi)容，運行RTE中斷返回。由于任務創(chuàng)建時堆棧的結構就是按中斷捕撈堆棧結構初始化的，執(zhí)行RET指令后就切換到了新任務。有關μC/OS- II的任務切換機制，請參考系列計座（3）.
OSStartHighRdy的匯編代碼如下：
_OSStarHighRdy
MOVE.L（_OSTCBHighRdy），A1
；獲取最高優(yōu)先級就緒任務的TCB地址
MOVE.L A1，（_OSTCBCur）
MOVE.L （A1），A7 ；取得堆棧指針
MOVEM.L （A7）+，A0-A6/D0-D7
RTE ；中斷返回，切換任務

（2）OSCtxSw( )函數(shù)

OSCtxSw( )是一個任務級的任務切換函數(shù)（在任務中調(diào)用，區(qū)別于在中斷程序中調(diào)用的OSIntCtxSw()，在MC68K系統(tǒng)上，通過執(zhí)行一條軟中斷指令來實現(xiàn)任務切換。軟中斷向量指向函數(shù)，而該函數(shù)的執(zhí)行結構可能造成系統(tǒng)任務重新調(diào)度（例如，試圖喚醒一個優(yōu)先級更高的任務），則在函數(shù)的末尾會調(diào)用OSSched ()，OSSched()將查找當前就緒的優(yōu)先級最高的任務。如果不是當前任務，則判斷是否需要進行任務調(diào)度，再找到該任務控制塊OS_TCB的地址，并將該地址拷貝到變量OSTCBHighRdy中，然后通過寵OS_TASK_SW（）執(zhí)行軟中斷，進行任務切換。在此過程中，變量OSTCBCur始終包含一個指向當前運行任務OS_TCB的指針。OSCtxSw()的匯編代碼如下：
_OSCtxSw
MOVEM.L A0-A6/D0-D7,-(A7) ;存儲當前任務環(huán)境
MOVE.L （_OSTCBCur），A1 ；保存當前任務TCB指針
MOVE.L A7，（A1）
MOVE.L （_OSTCBHighRdy），A1 ；獲取最高優(yōu)先級就緒任務的TCB地址
MOVE.L A1，（_OSTCBCur） ；將就緒任務設置為當前運行任務
MOVE.L （A1），A7 ；取得新任務的堆棧指針
MOVEM.L （A7）+，A0-A6/D0-D7 ；
RTE ；中斷返回，切換任務

（3）OSIntCtxSw()函數(shù)

在μC/OS -II中，由于中斷的產(chǎn)生可能會引起任務切換，在中斷服務程序的最后會調(diào)用OSICntExit()函數(shù)檢查任務就緒狀態(tài)。如果需要進行任務切換，將調(diào)用 OSIntCtxSw()，所以，OSIntCtxSw()又稱為中斷級的任務切換函數(shù)。由于在調(diào)用OSIntCtxSw()之前已經(jīng)發(fā)生了中斷， OSIntCtxSw()默認CPU寄存器已經(jīng)保存在被中斷任務的堆棧了。OSIntCtxSw()的代碼與OSCtxSw()的大部分相同，不同之處是：第一，由于中斷已經(jīng)發(fā)生，此處不需要再保存CPU寄存器；第二，OSIntCtxSw()需要調(diào)整堆棧指針，去掉堆棧中一些不需要的內(nèi)容，以使堆棧中包含任務的運行環(huán)境。
_OSIntCtxSw
ADDA #10，A7 ；忽略掉由于函數(shù)嵌套調(diào)
；用而壓入堆棧的內(nèi)容
MOVE.L （_CSTCBCur），A1 ；在TCB中保存當前
；任務的堆棧指針
MOVE.L A7，（A1）
MOVE.L （_OSTCBHighRdy），A1
；獲取最高優(yōu)先級就緒任務的TCB地址
MOVE.L A1，（_OSTCBCur） ；將就緒任務設備為當前
；運行任務
MOVE.L （A1），A7 ；取得堆棧指針
MOVEM.L （A7）+，A0-A6/D0-D7 ；
RTE ；中斷返回，切換任務

（4）OSTickISR()函數(shù)

在μC/OS-II中，當調(diào)用OSStart()啟動多任務環(huán)境后，時鐘中斷非常重要。在時鐘中斷中處理所有與定時相關的工作，如任務的延時、等待操作等等。在時鐘中斷中將查詢處于等待狀態(tài)的任務，判斷是否延時結束，以重新進行任務調(diào)度。

和μC/OS -II中的其他中斷服務程序一樣，OSTickISR()首先在被不斷任務堆棧中保存CPU寄存器的值，然后調(diào)用OSIntEnter()。ΜC/OS- II要求在中斷服務程序開頭調(diào)用OSIntEnter()，其作用是將記錄中斷嵌套層數(shù)的全局變量OSIntNesting加1。如果不調(diào)用 OSIntEnter()，直接將OSIntNesting加1也是允許的。隨垢，OSTickISR()調(diào)用OSTimeTick（），檢查所有處于延時等待狀態(tài)的任務，判斷是否有延時結束并就緒的任務。在OSTickISR()的最后調(diào)用OSIntExit()，如果在中斷中（或其他嵌套的中斷）有更高優(yōu)先級的任務就緒，并且當前中斷為中斷嵌套的最后一層，OSIntExit()將進行任務調(diào)度。注意，如果進行了任務調(diào)度，OSIntExit（）將不再返回調(diào)用者，而是用新任務堆棧中的寄存器數(shù)值恢復CPU現(xiàn)場，然后用RTE實現(xiàn)任務切換。如果當前中斷不是中斷嵌套的最后一層，或中斷中沒有改變?nèi)蝿盏木途w狀態(tài)，OSIntExit()將返回調(diào)用者OSTickISR()，最后OSTickISR()返回被中斷的任務。

4.OS_CPU32.C文件

μC/OS-II的移值需要用戶在OS_CPU32.C中定義6個函數(shù)，而實際上需要定義的只有OSTaskStkInit()一個函數(shù)，其他5個函數(shù)需要聲明，但不一定有實際內(nèi)容。這5個函數(shù)都是用戶定義的，所以OS_CPU32.C中沒有給出代碼。如果用戶需要使用這些函數(shù)，請將文件OS_CDG.H中的#define constant OS_CPU_HOOKS_EN設為1，設為0表示不使用這些函數(shù)。

OSTaskStkInit ()函數(shù)由任務創(chuàng)建函數(shù)OSTaskCreate()或OSTaskCreateExt()調(diào)用，用來初始化任務的堆棧。初始狀態(tài)的堆棧模擬發(fā)生一次中斷后的堆棧結構。按照中斷后的進棧次序預留各個寄存器的存儲空間，而中斷返回地址指向任務代碼的起始地址。當調(diào)用OSTaskCreate()或 OSTaskCreateExt（）創(chuàng)建一個新任務時，需要傳遞的參數(shù)是：任務代碼的起始地址、參數(shù)指針、任務堆棧頂端的地址、任務的優(yōu)先級。 OSTaskCreateExt()還需要一些其他參數(shù)，但與OSTaskStkInit()沒有關系。OSTaskStkInit（）只需要以上提到的 3個參數(shù)：task、pdata、ptos。由于MC68K堆棧是16位寬的（以字為單位），OSTaskStkInit()將創(chuàng)立一個指向以字為單位的內(nèi)存區(qū)域的指針，同時要求堆棧指針指向空堆棧的頂端。堆棧初始化工作結束后，OSTaskStkInit（）返回新的堆棧頂指針， OSTaskCreate()或OSTaskCreateExt()將指針保存在任務的OS_TCB中。

三、移植中的幾點注意事項

由于μC/OS-II運行的實時性，調(diào)試內(nèi)核幾乎不可能。一旦移植過程中內(nèi)核運行不穩(wěn)定，很難確定是什么地方的問題，更困難的是有些現(xiàn)象幾乎是不可重復的。這就需要詳細了解內(nèi)核運行機理，認真分析，找出可能存在的問題。下面就來分析這些移植過程中的問題。

1.編譯器的優(yōu)化選項

在移植過程中，除了要熟悉μC/OS-II和目標芯片之外，熟悉使用的C編碼器也非常重要。通常C編譯器都會提供一些優(yōu)化代碼的選項，在移植μc/OS-II的過程中，這些選項往往會帶來麻煩。下面是移植中與HIWARE的C編譯器有關的例子。

通常在調(diào)用子程序或進入中斷時，C編譯器會自動保存CPU內(nèi)部寄存器到堆棧中。例如，在進入中斷時編譯器會加入下面2條指令：

LINK #$0000，A6；
MOVEM.L D0/D1/D3/D4/D5/D6/D7/A0/A1/A2/A3/A4/A5，-（A7）；

這2 條匯編指令的作用是將CPU的數(shù)據(jù)寄存器D0～D7、地址寄存器A0～A5保存到堆棧中，再將此時的堆棧指針A7也保存到堆棧中，并使用A6作為臨時的堆棧指針。這本是一個非常好的優(yōu)化選項，可以防止在中斷中偶然地更改了數(shù)據(jù)寄存器或地址寄存器；但在μC/OS-II中，這個機制將對OS_CPU_C.C 和OS_CPU_ASM.ASM中的幾個子程序和中斷服務例程產(chǎn)生致命的影響。

OS_CPU_C.C和OS_CPU_ASM.ASM中的子程序中斷引發(fā)任務調(diào)度，當前的任務被掛起。掛起任務是通過下面的語句來完成的：
MOVEM.L A0-A6/D0-D7，-（A7）；
MOVE.L @OSTCBCur，A2；
MOVE.L （A2），A1；
MOVE.L A7，（A1）；

保存任務的指針和所有數(shù)據(jù)地址寄存器的值，那么理想情況下，此時的任務堆棧應該是如圖1所示的情況（以OSCtxSw()函數(shù)為例，可以對應到OS_CPU_C.C和OS_CPU_ASM.ASM中的其他函數(shù)和中斷處理例程）。

那么恢復掛起的任務時，只要通過如下語句：
MOVE.L OSTCBHighRdy，A1；
MOVE.L @OSTCBCur，A2；
MOVE.L A1，（A2）；
MOVE.L （A1），A7；
MOVEM.L （A7）+，A0-A6/D0-D7；

將保存在任務TCB中的任務堆棧指針恢復，再恢復數(shù)據(jù)地址寄存器，最后執(zhí)行OSCtxSw()的中斷返回，就可以順利地恢復被掛起的任務。

如果C編譯器在OSCtxSw()函數(shù)入口處插入了2條保存數(shù)據(jù)地址寄存器和堆棧指針的語句后，再執(zhí)行掛起任務的語句，任務的堆棧會變成圖2所示的情況。編譯器引起了堆棧的變化，如果所有的任務都是用這種方式掛起和恢復的，并不會產(chǎn)生致命的問題，因為編碼器退出OSCtxSw()函數(shù)時會插入如下語句恢復堆棧：

MOVEM.L （A7）+，D0-D7/A0-A5；
UNLK A6；

問題在于初始化任務的時候，每個任務實際上是按照圖1所示的堆棧結構被初始化的，那么，按照圖2的堆棧結構來恢復自然會導致堆棧崩潰。

解決這個問題的方法很多，可以改定任務初始化的代碼以適應C編譯器的這個“優(yōu)化”，也可以在進入OSCtxSw()函數(shù)時首先調(diào)用如下語句恢復堆棧，抵消C編碼器的影響：
MOVEM.L （A7）+，D0-D7/A0-A5；
UNLK A6；

而在退出OSCtxSw()函數(shù)前再調(diào)用如下語句模擬出更動的堆棧：
LINK #$0000，A6
MOVEM.L D0-D7/A0-A5，-（A7）；

較好的方法當然是調(diào)整編譯器，取消這個優(yōu)化選項。如果無法調(diào)整編譯器，就只有用以上辦法來適應編譯器了。

2.開關中斷的方法

在μC/OS -II中，開關中斷是非常重要的，它可以保證關鍵代碼或訪問全局變量時不受中斷的意外影響。CPU32的中斷控制比較復雜，提供了7級具有不同級別的中斷；可以選擇關閉或打開某幾級中斷。但多級中斷會使得μC/OS-II的中斷處理變得復雜。在簡單的應用或初次嘗試移植μC/OS-II時，可以使用全開全關的方法。

如果考慮多級中斷，必須注意到中斷開關級別的控制是一個重要的信息，在關閉中斷之前需要將這個信息保存起來，在對應的開中斷時恢復這個中斷級別控制信息。最容易想到的方法是用一個全局變量存存這個信息。

使用這個方法的程序如下：
#define OS_EXIT_CRITICAL() asm move SR_TEMP,sr；
#define OS_ENTER_CRITICAL() asm move.w SR,SR_TEMP;
asm ori.w #0x0700,SR;

接著構造兩個任務，每個任務分別向屏幕輸出一句話，同時修改內(nèi)核的代碼，讓空閑任務也輸出一句話。運行內(nèi)核，通常在幾分鐘內(nèi)會發(fā)現(xiàn)內(nèi)核停止調(diào)試，只有空閑任務不停地向屏幕輸出。這種情況非常麻煩，因為根據(jù)無法通過調(diào)試手段判斷何時何處導致內(nèi)核停止調(diào)度。

分析一下，當只有空閑任務運行時，代碼為：
move.w sr,sr_temp
ori.w #0700,sr
addi.1 #1,OSIdleCtr
move.w sr_temp,sr
jmp ****

這5句語句在循環(huán)運行，而中斷（這時只有定時中斷）可以在任意一句語句中間切入。那么，如果在MOVE.W SR，SR_TEMP的時候產(chǎn)生了中斷，就會執(zhí)行中斷（因為正要關中斷，但還沒有關上）；而中斷程序調(diào)用的OSIntENTER和OSIntEXIT都會調(diào)用 OS_ENTER_CRITICAL（）來關閉中斷，遞增中斷嵌套層數(shù)全局變量。這時，再次執(zhí)行MOVE.W SR，SR_TEMP變量就被改寫成關中斷的值，當從中斷返回到IDLE任務執(zhí)行MOVE.W SR_TEMP，SR時，就關閉了中斷，而不是恢復原來的狀態(tài)寄存器。這樣就導致內(nèi)核無法響應中斷，無法調(diào)度任務，只有IDLE任務在運行。
 
如何解決？最容易想到的方法是再增加一個全局變量，用來保存進入中斷時的中斷開關信息，退出中斷恢復這個信息；但如果考慮到中斷嵌套，相同的情況又出現(xiàn)了，并且如果一個任務在執(zhí)行MOVE.W SR，SR_TEMP時被中斷打斷并且發(fā)生了任務調(diào)度，那么當個任務恢復時，它使用的中斷信息SR_TEMP可以已經(jīng)是被其他任務更改后的值了。內(nèi)核無法響應中斷，無法調(diào)度的任務可能依然存在。

給每個任務和中斷都定義一個這樣的全局變量，在不考慮中斷嵌套的情況下似乎可以解決問題，但想象一下為每一個任務和中斷提供一個單獨的OS_ENTER_CRITICAL（）和OS_EXIT_CRITICAL（）函數(shù)所帶來的工作量。顯然這不一個好辦法。

將中斷信息推入堆棧是一個好主意，但我們會看到由此帶來的一些更加隱蔽而復雜的問題。實現(xiàn)這個方法的程序代碼如下：
#define OS_ENTER_CRITICAL() asm move SR,-(A7);
asm ori.w #0x0700,SR;
#define OS_EXIT_CRITICAL() asm move (A7)+,sr;

這樣，每次調(diào)用OS_ENTER_CRITICAL（），都將當前的中斷開關信息保存到當前任務堆?；蛳到y(tǒng)堆棧中斷OS_EXIT_CRITICAL（）時，恢復這個信息。

使用了這個方法后，必須小心地計算堆棧的使用情況，修改OS_CPU_A.ASM和 OS_CPU_C.C文件里的函數(shù)。以OSIntCtxSw()函數(shù)為例，這個函數(shù)將導致中斷級的任務調(diào)度，即被中斷打斷的程序不能繼續(xù)運行，退出中斷中另一個優(yōu)先級更高的任務得以運行。在這個函數(shù)中必須對被中斷的任務堆棧進行清理，使得這個任務的堆棧看起來和一次正常的任務切換后的情況相同，這樣，才能保證這個任務被正確地恢復運行。OSIntCtxSw()函數(shù)僅僅在 OSICntExit()函數(shù)中被調(diào)用。

須指出的是，在中斷發(fā)生時，CPU32已經(jīng)將全部的寄存器和狀態(tài)寄存器，PC指針內(nèi)容保存到了堆棧中，這樣已經(jīng)為被打斷的任務的恢復作好了準備。如果按照正常的中斷流程，在退出中斷時，被打斷的任務應該恢復運行。現(xiàn)在，由于執(zhí)行了中斷級的任務切換，被打斷的任務不能立刻恢復，而是被掛起，這就要求在執(zhí)行任務調(diào)度前調(diào)整堆棧，使得被中斷打斷的任務處于隨時可以被恢復的狀態(tài)。

在中斷處理程序中，當執(zhí)行到OSIntExit（）時，堆棧的情況和剛剛進入中斷還是相同的，是能夠隨時恢復被打斷的任務的情況。那么，只需要忽略 OSIntExit（）函數(shù)造成的堆棧變化。首先，是OSIntExit（）函數(shù)本身的返回地址，長度為2個字；調(diào)用OS_ENTER_CRITICAL （）壓入堆棧的狀態(tài)寄存器，長度為1個字；最后，是OSIntCtxSw()函數(shù)的返回地址，長度為2個字。那么在OSIntCtxSw()進行任務切換時，首先要把這5個字的堆棧的內(nèi)容清除，才能保證被中斷任務的正確恢復。該語句如下：
ADDA #10，A7；

在完成了這些調(diào)整后，由于開關中斷可能導致的內(nèi)核調(diào)度死鎖的可能已經(jīng)不存在了。但是在這種情況下，另一個更加隱蔽的問題會出現(xiàn)，這個問題又是和使用的C編碼器相關的。

問題出現(xiàn)在使用OSSemPend()函數(shù)時，一旦調(diào)用這個函數(shù)，CPU就會出現(xiàn)地址錯誤而進入異常處理，內(nèi)核被終止。這個問題相當奇怪，因為， OSSemPend()函數(shù)完全是一個C語言寫成的子函數(shù)，函數(shù)本身不應出現(xiàn)地址錯誤。通過閱讀編譯器編譯出來的目標碼發(fā)現(xiàn)了問題。EmPend()函數(shù)，發(fā)現(xiàn)這個函數(shù)沒有任何局部變量。在進入OSSemPend()函數(shù)時，編譯器不需要產(chǎn)生LINK指令來提供局部變量空間。所有的參數(shù)都是使用帶偏移量的地址寄存器間接尋址方式直接從堆棧中取得，而且使用的地址寄存器就是A7寄存器。問題可能就在這里，OS_ENTER_CRITICAL（）和 OS_EXIT_CRITICAL（）對堆棧的操作都會調(diào)整A7寄存器，這就會導致下面的語句在利用A7作寄存器間接尋址時發(fā)生錯亂，出現(xiàn)地址錯誤。

這需要詳細研究編譯器的特性。我們使用的HIWARE的編譯器實際上已經(jīng)考慮到了這一點，當調(diào)用 OS_ENTER_CRITICAL（）或 OS_EXIT_CRITICAL（）函數(shù)更加了A7寄存器后，使用A7的地址寄存器間接尋址也會做出相應的調(diào)整，保證仍然能夠得到函數(shù)調(diào)用時傳遞的變量。每出現(xiàn)一個OS_ENTER_CRITICAL（），接下來的A7寄存器間接尋址的偏移量就會加2；每出現(xiàn)一個OS_EXIT_CRITICAL （），接下來的A7寄存器間接尋址的偏移量就會減2。但是問題卻依然存在，對OSSemPend()的調(diào)用會導致地址錯誤，這應該是一個更深層次的錯誤。

這個問題的解決方法是：定義一個局部變量，迫使編譯器生成LINK指令，構造內(nèi)部參數(shù)尋址指針A6，這樣調(diào)用OS_ENTER_CRITICAL（）或OS_EXIT_CRITICAL（）時，更動的只是A7，而對參數(shù)尋址用的是A6，不受影響。

如果強迫編譯器在調(diào)用函數(shù)時都加上LINK和UNLINK指令也可以解決這個問題，但是又會面臨最先提到的編譯器的優(yōu)化選項問題?？梢钥闯?，編譯器的特性對移植μC/OS-II是非常重要的，并且往往這些特性是相互制約的。

在移植和運行μC/OS-II的過程中，也許還會有新的問題出現(xiàn)，遇到問題時只要仔細分析，分析堆棧的使用、中斷的影響，分析編譯生成的代碼，就可以實現(xiàn)μC/OS-II的穩(wěn)定可靠運行.