2002/12/23

gdtyy 你好，幾個問題想請教一下 

這些天我仔細看了很多ucosii的資料，但有些疑問，我想真要能將ucosii應用起來，我們需要理解的問題分為三個
ucosii工作原理
ucosii 移植
ucosii 和應用程序的接口（用戶程序如何嵌入到操作系統中運行）
首先ucossii 的工作核心原理是：讓最高優先級的任務處于運行狀態。這需要操作系統在某個時間得運行任務調度的一個算法（操作系統提供了這個函數），她將自動完成調度運算并完成任務的切換。調度操作在下面情況中將被運行：調用api函數（用戶主動調度），中斷（系統、用戶的）
我現在不能理解的是調度算法的api函數到底是怎么實現的（對于任務的優先級運算（查表）這個我知道），她怎么實現調度前運行的任務的數據（特別是pc地址）保存？如果任務從運行到就緒再到運行，它是否將從新開始運行任務程序，還是從調度以前的斷點處運行？任務為什么需要被寫成無限循環方式？還有，中斷結束后，系統也要進行調度操作，那么她怎么實現的？因為按照常理，中斷結束后，系統應該直接回到原先任務的斷點處運行，除非她在中斷函數中將調度函數用軟件方式入棧了，這樣reti退出后，系統運行調度函數。。。如果是這樣，用戶自己的中斷函數是否也需要這樣編寫（用軟件將調度函數入棧）才能實現調度運算呢？否則系統就不執行調度算法，直到系統的定時中斷到了才執行調度算法（系統的中斷函數是否有這樣的特殊處理），當然系統可能還有其他的什么方式來實現調度算法（我是想不出來了），請賜教~~~謝謝~~~~~~~~~~~

TO:XXX
    uCOSII工作核心原理是：近似地讓最高優先級的就緒任務處于運行狀態。
    操作系統將在下面情況中進行任務調度：調用API函數(用戶主動調用)，中斷(系統占用的時間片中斷OsTimeTick(),用戶使用的中斷)。
    調度算法書上講得很清楚，我主要講一下整體思路。
    (1)在調用API函數時，有可能引起阻塞,如果系統API函數察覺到運行條件不滿足，需要切換就調用OSSched()調度函數，這個過程是系統自動完成的，用戶沒有參與。OSSched()判斷是否切換，如果需要切換，則此函數調用OS_TASK_SW()。這個函數模擬一次中斷(在51里沒有軟中斷，我用子程序調用模擬，效果相同)，好象程序被中斷打斷了，其實是OS故意制造的假象，目的是為了任務切換。既然是中斷，那么返回地址(即緊鄰OS_TASK_SW()的下一條匯編指令的PC地址)就被自動壓入堆棧，接著在中斷程序里保存CPU寄存器(PUSHALL)……。堆棧結構不是任意的，而是嚴格按照uCOSII規范處理。OS每次切換都會保存和恢復全部現場信息(POPALL)，然后用RETI回到任務斷點繼續執行。這個斷點就是OSSched()函數里的緊鄰OS_TASK_SW()的下一條匯編指令的PC地址。切換的整個過程就是，用戶任務程序調用系統API函數，API調用OSSched()，OSSched()調用軟中斷OS_TASK_SW()即OSCtxSw，返回地址(PC值)壓棧，進入OSCtxSw中斷處理子程序內部。反之，切換程序調用RETI返回緊鄰OS_TASK_SW()的下一條匯編指令的PC地址，進而返回OSSched()下一句，再返回API下一句，即用戶程序斷點。因此，如果任務從運行到就緒再到運行，它是從調度前的斷點處運行。
    (2)中斷會引發條件變化，在退出前必須進行任務調度。uCOSII要求中斷的堆棧結構符合規范，以便正確協調中斷退出和任務切換。前面已經說到任務切換實際是模擬一次中斷事件，而在真正的中斷里省去了模擬(本身就是中斷嘛)。只要規定中斷堆棧結構和uCOSII模擬的堆棧結構一樣，就能保證在中斷里進行正確的切換。任務切換發生在中斷退出前，此時還沒有返回中斷斷點。仔細觀察中斷程序和切換程序最后兩句，它們是一模一樣的，POPALL+RETI。即要么直接從中斷程序退出，返回斷點；要么先保存現場到TCB，等到恢復現場時再從切換函數返回原來的中斷斷點(由于中斷和切換函數遵循共同的堆棧結構，所以退出操作相同，效果也相同)。用戶編寫的中斷子程序必須按照uCOSII規范書寫。任務調度發生在中斷退出前，是非常及時的，不會等到下一時間片才處理。OSIntCtxSw()函數對堆棧指針做了簡單調整，以保證所有掛起任務的棧結構看起來是一樣的。
    (3)在uCOSII里，任務必須寫成兩種形式之一(《uCOSII中文版》p99頁)。在有些RTOS開發環境里沒有要求顯式調用OSTaskDel()，這是因為開發環境自動做了處理，實際原理都是一樣的。uCOSII的開發依賴于編譯器，目前沒有專用開發環境，所以出現這些不便之處是可以理解的。