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

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

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

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

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

這5句語(yǔ)句在循環(huán)運行，而中斷（這時(shí)只有定時(shí)中斷）可以在任意一句語(yǔ)句中間切入。那么，如果在MOVE.W SR，SR_TEMP的時(shí)候產(chǎn)生了中斷，就會(huì )執行中斷（因為正要關(guān)中斷，但還沒(méi)有關(guān)上）；而中斷程序調用的OSIntENTER和OSIntEXIT都會(huì )調用 OS_ENTER_CRITICAL（）來(lái)關(guān)閉中斷，遞增中斷嵌套層數全局變量。這時(shí)，再次執行MOVE.W SR，SR_TEMP變量就被改寫(xiě)成關(guān)中斷的值，當從中斷返回到IDLE任務(wù)執行MOVE.W SR_TEMP，SR時(shí)，就關(guān)閉了中斷，而不是恢復原來(lái)的狀態(tài)寄存器。這樣就導致內核無(wú)法響應中斷，無(wú)法調度任務(wù)，只有IDLE任務(wù)在運行。

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

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

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

這樣，每次調用OS_ENTER_CRITICAL（），都將當前的中斷開(kāi)關(guān)信息保存到當前任務(wù)堆?；蛳到y堆棧中斷OS_EXIT_CRITICAL（）時(shí)，恢復這個(gè)信息。

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

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

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

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

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

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

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

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

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