RTX51 TINY的分析

　　RTX51 TINY是一種應用于MCS5l系列單片機的小型多任務實時操作系統。它完全集成在Keil C5l編譯器中，具有運行速度快、對硬件要求不高、使用方便靈活等優點， 因此越來越廣泛地應用到單片機的軟件開發中。它可以在單個CPU上管理幾個作業（任務），同時可以在沒有擴展外部存儲器的單片機系統上運行。

　　RTX51 TINY允許同時“準并行”地執行多個任務：各個任務并非持續運行，而是在預先設定的時間片(time slice)內執行。CPU執行時間被劃分為若干時間片，RTX51 TINY為每個任務分配一個時間片，在一個時間片內允許執行某個任務，然后RTX51 TINY切換到另一個就緒的任務并允許它在其規定的時間片內執行。由于各個時間片非常短，通常只有幾ms，因此各個任務看起來似乎就是被同時執行了。

　　RTX51 TINY利用單片機內部定時器0的中斷功能實現定時，用周期性定時中斷驅動RTX51 TINY的時鐘。它最多可以定義16個任務，所有的任務可以同時被激活，允許循環任務切換，僅支持非搶占式的任務切換，操作系統為每一個任務分配一個獨立的堆棧區，在任務切換的同時改變堆棧的指針，并保存和恢復寄存器的值。RTX51 TINY沒有專門的時間服務函數和任務掛起函數，而是通過os_wait()中的參數設定實現的。使用RTX51 TINY時用戶程序中不需要包含main()函數，它會自動地從任務0開始運行。如果用戶程序中包含有main()函數，則需要利用os_create_task函數來啟動RTX51實時操作系統。

2? 任務切換

2.1 ?RTX51 TINY任務狀態

　　RTX51 TINY的用戶任務具有以下幾個狀態：

　　① 運行(RUNNING)——任務正處于運行中。同一時刻只有一個任務可以處于“RUNNING”狀態。
　　② 就緒(READY)——等待運行的任務處于“READY”狀態。在當前運行的任務退出運行狀態后，就緒隊列中的任務根據調度策略被調度執行，進入到運行狀態。
　　③ 阻塞(BLOCKED)——等待一個事件的任務處于“BLOCKED”狀態。如果等待的事件發生，則此任務進入“READY”狀態，等待被調度。
　　④ 休眠(SLEEPING)——被聲明過但沒有開始運行的任務處于休眠狀態。運行過但已經被刪除的任務也處在休眠狀態中。
　　⑤ 超時(TIMEOUT)——任務由于時間片用完而處于“TIMEOUT”狀態，并等待再次運行。該狀態與“READY”狀態相似，但由于是內部操作過程使一個循環任務被切換，因而單獨算作一個狀態。

　　處于“READY/TIMEOUT”、“RUNNING”和“BLOCKED”狀態的任務被認為是激活的狀態，三者之間可以進行切換。“SLEEPING”狀態的任務是非激活的，不能被執行或認為已經終止。

2.2? RTX51 TINY任務切換

　　任務切換是RTX51 TINY提供的基本服務。RTX51 TINY是基于時間片調度算法的操作系統，它支持的是非搶占式的任務切換。所以在一個任務被執行時不能對其進行中斷，除非該任務主動放棄CPU的資源，中斷才可以打斷當前的任務，中斷完成后把CPU的控制權再交還該被中斷的任務。任務切換有兩種情況，一種是當前任務主動讓出CPU資源；另一種情況是在當前任務的時間片已經用完的情況下，進行任務切換。CPU執行時間被分成若干個時間片，RTX51 TINY為每個任務分配一個時間片。時間片是通過對變量TIMESHARING的設置來確定的，即用“TIMESHARING EQU 5;”設置多少個系統時鐘周期為一個時間片。系統默認5個系統時鐘為一個時間片，如果晶振頻率為11.059 2 MHz，則時間片為10.850 7×5＝54.253 5 ms。

　　RTX51 TINY的任務切換共有TASKSWITCHING 和SWITCHINGNOW兩個入口，前者供定時器T0的中斷服務程序調用，后者供系統函數os_delete和os_wait調用。相應地也有兩個不同的出口，分別是恢復保護現場和清除狀態標志位。系統首先將當前任務置為“TIMEOUT”狀態，等待下一次時間片循環，然后找到下一個處于“READY”狀態的任務，通過堆棧管理，將自由堆棧空間分配給該任務，使其成為當前任務。清除使該任務進入“READY”或“TIMEOUT”狀態的相關位后，執行該任務。任務切換的流程如圖1所示。

圖1? 任務切換流程

3? 共享資源實現[1]

　　RTX51 TINY由于是一個多任務的操作系統，那么就不免會有幾個任務使用同一個資源，這些資源可能是一個變量，也可能是輸入/輸出設備。這就要求一個任務在使用共享資源時必須獨占該資源，否則可能會造成數據被破壞。

　　在RTX51 TINY中實現共享資源獨占的方法比較多。比如，可以通過TIMESHARING這個變量來禁止時間片輪轉，使其值為0，就可以實現禁止任務切換，從而當前任務就可以獨占共享資源。還可以關閉中斷來實現，使EA＝0，定時器T0的中斷被關閉，不能再為時間片輪轉提供基準，從而禁止了任務切換。但這兩種方法都帶有一定的局限性，前一種方法只能適用于實時性要求不高的場合，后一種方法由于T0中斷關閉時間不能太長，只能適用于一些簡單變量操作的場合。基于以上情況，下面通過另一種方法來實現共享資源的使用。

　　在RTX51 full中可以利用信號量很好地實現對共享資源的操作，也可以把這種思想應用到RTX51 TINY中；而在RTX51 TINY中不支持信號量，這就要求用戶自己定義信號量及其操作過程。以下是部分代碼：

　　struct signal {//定義信號量結構體
　　　　uchar count；//該信號量的當前計數值
　　　　uint list_tasks；//等待該信號量任務表
　　} signal_list[3]；
　　/*初始化信號量 */
　　void init_signal(uchar task_id,uchar count) {
　　　　signal_list[task_id].count=count；
　　　　signal_list[task_id].list_tasks=0；
　　}
　　/*等待信號量 */
　　char wait_signal(uchar task_id) {
　　　　if(signal_list[task_id].count>0) {
　　　　　　signal_list[task_id].count；//獲取信號量
　　　　　　return(-1)；
　　　　}
　　　　signal_list[task_id].list_tasks|=(1?os_running_task_id())；//標記為等待狀態
　　　　return(0)；
　　}
　　void wait_sem(uchar task_id) {
　　　　if(wait_signal(task_id==0)
　　　　　　while(os_wait(K_TMO，255，0)!=RDY_EVENT)；//等待，直到該任務就緒
　　}
　　/*釋放信號量 */
　　char release_signal(uchar task_id) {
　　　　uchar i：
　　　　uint temp=1；
　　　　if((signal_list[task_id].count>0)||( signal_list[task_id].list_tasks==0))? {
　　　　　　signal_list[task_id].count++； //釋放信號量
　　　　　　return(-1)；
　　　　}
　　　　for(i=0；i<16；i++) {
　　　　　　if((signal_list[task_id].list_tasks&(temp))!=0){//查找任務表
　　　　　　　　signal_list[task_id].list_tasks&= ~(1< 　　　　　　}
　　　　　　temp<<=1：
　　　　}
　　}
　　void release_sem(uchar task_id) {
　　　　char task_temp；
　　　　task_temp=release_signal(task_id)；
　　　　if(task_temp!=-1) {
　　　　　　os_set_ready(task_temp)； //任務task_id進入就緒狀態
　　　　　　os_switch_task()；
　　　　}
　　}

　　有了以上幾個函數的定義和實現，就可以應用等待信號量和釋放信號量來完成對共享資源的獨占。例如：

　　void job()_task_ id {
　　　　　　――――用戶代碼――――
　　　　　　wait_sem(task_id)；//等待任務task_id的信號量
　　　　　　――――對共享資源使用代碼――――
　　　　　　release_sem(task_id)；//釋放任務task_id的信號量
　　　　　　――――用戶代碼――――
　　}

　　應用信號量來實現共享資源的使用，不用禁止時間片輪轉和關閉T0中斷，可以有效地實現對共享資源的獨占；但增加了代碼，等待和釋放信號量花費了一定的時間，在具體應用中要視情況而定。

4? 需要注意的問題

　　在應用RTX51 TINY時應注意以下幾點：

　　① 盡可能不使用循環任務切換。使用循環任務切換時要求有13個字節的堆棧區來保存任務內容(工作寄存器等)。如果由os_wait()函數來進行任務觸發，則不需要保存任務內容。由于正處于等待運行的任務并不需要等待全部循環切換時間結束，因此os_wait()函數可以產生一種改進的系統響應時間。
　　② 不要將時鐘節拍中斷速率設置得太高，設定為一個較低的數值可以增加每秒的時鐘節拍個數。每次時鐘節拍中斷大約需要100~200個CPU周期，因此應將時鐘節拍率設定得足夠高，以便使中斷響應時間達到最小化。
　　③ 在os_wait()函數中有3個參數： K_TMO、K_IVL和K_SIG。其中對于K_TMO和K_IVL的使用要加以區別。在使用時，兩者似乎差別不是很大。其實不然,兩者存在很大的區別：K_TMO是指等待一個超時信號， 只有時間到了，才會產生一個信號。它產生的信號是不會累計的，產生信號后，任務進入就緒狀態。而K_IVL是指周期信號， 每隔一個指定的周期，就會產生一次信號，產生的信號是可以累計的。這樣就使得在指定事件內沒有響應的信號，通過信號次數的疊加，在以后信號處理時，重新得以響應，從而保證了信號不會被丟失。而通過K_TMO方式進行延時的任務，由于某種原因信號沒有得到及時的響應，那么這樣就可能會丟失一部分沒有響應的信號。不過兩者都是有效的任務切換方式，在使用時要根據應用場合來確定對兩者的使用。

結語

　　RTX51 TINY實時操作系統既能保證對外界的信息以足夠快的速度進行相應處理，又能并行運行多個任務，具有實時性和并行性的特點，因此能很好地完成對多個信息的實時測量、處理，并進行相應的多個實時控制。任務切換是RTX51 TINY的一個基本服務。本文對任務切換做了詳細的分析，在實際應用中還要對任務切換時的堆棧管理有一定了解，這樣才能更好地掌握任務切換的機制。共享資源的使用在多任務操作系統中是不可避免的，RTX51 TINY中沒有專門的處理共享資源函數，所以在實際應用中要視情況來應用文中提到的幾種方法。