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

MOVE.L (A1)，A7;

MOVEM.L (A7)+，A0-A6/D0-D7;

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

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

MOVEM.L (A7)+，D0-D7/A0-A5;

UNLK A6;

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

解決這個問題的方法很多，可以改定任務初始化的代碼以適應C編譯器的這個“優(yōu)化”，也可以在進入OSCtxSw()函數(shù)時首先調用如下語句恢復堆棧，抵消C編碼器的影響：

MOVEM.L (A7)+，D0-D7/A0-A5;

UNLK A6;

而在退出OSCtxSw()函數(shù)前再調用如下語句模擬出更動的堆棧：

LINK #$0000，A6

MOVEM.L D0-D7/A0-A5，-(A7);

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

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;

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

分析一下，當只有空閑任務運行時，代碼為：

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的時候產生了中斷，

就會執(zhí)行中斷(因為正要關中斷，但還沒有關上);而中斷程序調用的OSIntENTER和OSIntEXIT都會調用OS_ENTER_CRITICAL()來關閉中斷，遞增中斷嵌套層數(shù)全局變量。這時，再次執(zhí)行MOVE.W SR，SR_TEMP變量就被改寫成關中斷的值，當從中斷返回到IDLE任務執(zhí)行MOVE.W SR_TEMP，SR時，就關閉了中斷，而不是恢復原來的狀態(tài)寄存器。這樣就導致內核無法響應中斷，無法調度任務，只有IDLE任務在運行。

如何解決?最容易想到的方法是再增加一個全局變量，用來保存進入中斷時的中斷開關信息，退出中斷恢復這個信息;但如果考慮到中斷嵌套，相同的情況又出現(xiàn)了，并且如果一個任務在執(zhí)行MOVE.W SR，SR_TEMP時被中斷打斷并且發(fā)生了任務調度，那么當個任務恢復時，它使用的中斷信息SR_TEMP可以已經是被其他任務更改后的值了。內核無法響應中斷，無法調度的任務可能依然存在。

給每個任務和中斷都定義一個這樣的全局變量，在不考慮中斷嵌套的情況下似乎可以解決問題，但想象一下為每一個任務和中斷提供一個單獨的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;

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

使用了這個方法后，必須小心地計算堆棧的使用情況，修改 OS_CPU_A.ASM和OS_CPU_C.C文件里的函數(shù)。以OSIntCtxSw()函數(shù)為例，這個函數(shù)將導致中斷級的任務調度，即被中斷打斷的程序不能繼續(xù)運行，退出中斷中另一個優(yōu)先級更高的任務得以運行。在這個函數(shù)中必須對被中斷的任務堆棧進行清理，使得這個任務的堆?？雌饋砗鸵淮握５娜蝿涨袚Q后的情況相同，這樣，才能保證這個任務被正確地恢復運行。OSIntCtxSw()函數(shù)僅僅在OSICntExit()函數(shù)中被調用。

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

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

ADDA #10，A7;

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