RTX51 Tiny中容易混淆的問題

 

 

 

RTX51 Tiny是 Keil uVision中自帶的一個小型嵌入式RTOS,具有小巧、速度快、系統開銷小、使用方便等優點。使用RTX51 Tiny能夠提高系統的穩定性,優化程序的性能;而且它是為51單片機專門定制的,所以在51單片機上的運行效率比其它一些通用的RTOS性能也要好一些。

 

　　但是,由于RTX51 Tiny的相關資料和書籍比較少,大部分只是對程序自帶幫助文件的簡單翻譯,很少進行深入探討。下面就RTX51 Tiny使用中經常遇到的一些問題進行探討。

 

1  關于時間片的問題

 

　　RTX51 Tiny使用的是無優先級時間片輪詢法,每個任務使用相同大小的時間片,但是時間片是怎樣確定的呢?

 

　　RTX51 Tiny的配置參數(Conf_tny.a51文件中)中有INT_CLOCK和TIMESHARING兩個參數。這兩個參數決定了每個任務使用時間片的大小：INT_CLOCK是時鐘中斷使用的周期數,也就是基本時間片;TIMESHARING是每個任務一次使用的時間片數目。兩者決定了一個任務一次使用的最大時間片。如假設一個系統中INT_CLOCK設置為10000,即10ms,那么TIMESHARING=1時,一個任務使用的最大時間片是 10ms;TIMESHARING=2時,任務使用最大的時間片是20ms;TIMESHARING=5時,任務使用最大的時間片是50ms;當 TIMESHARING設置為0時,系統就不會進行自動任務切換了,這時需要用os_switch_task函數進行任務切換。這部分功能是RTX51 Tiny 2.0中新增加的。

 

2  關于os_wait延時的問題

 

　　os_wait 是RTX51 Tiny中的基本函數之一。它的功能是將當前任務掛起來,等待一個啟動信號(K_SIG)或超時信號(K_TMO)或周期信號(K_IVL)或者是它們之間的組合。雖然os_wait很簡單,但是因為涉及到多任務的操作方式,很容易產生誤解。

 

2.1  關于K_TMO的延時時間

 

　　在RTX51 Tiny中,如果一個任務中使用了os_wait(K_TMO,1,0),那么它的延時時間是多少呢?

很多人都會認為是一個時間片,其實這不完全對。正確的理解是,延時時間與正在運行的任務相關。因為RTX51 Tiny是一個非占先或多優先級的實時操作系統,是一個平級的時間片輪詢實時操作系統,所有的任務平等運行。K_TMO是等待產生超時信號,當信號產生后,只是將相應的任務置上就緒標志位,任務并不是立即就能夠運行。任務需要等到其它任務輪流執行,到自己的時間片后才會執行。

 

　　這就是說,最后的效果是延時時間加上正在運行的任務執行時間,而這個時間是與任務數和任務運行情況相關的。如果其它任務執行的時間短,那么延時可能只是一個時間片;如果其它任務執行的時間長,那么就需要多個時間片了。用os_wait做時鐘是不準確的。

 

　　關于延時時間還有一個很容易理解錯的地方,那就是os_wait中無論使用K_TMO還是K_IVL參數,延時的時間都只與INT_CLOCK有關,而與TIMESHARING無關。或者說,os_wait函數一次只使用一個基本時間片,而不是任務的時間片。

 

2.2  關于K_TMO和K_IVL參數的區別

 

　　在os_wait中有三個參數：K_TMO、K_IVL和K_SIG。其中,K_TMO與K_IVL是最容易讓人混淆的,特別是搞不清楚 K_IVL到底是什么含義,好像使用起來與K_TMO效果差不多。一般的書上和Keil自帶的RTX51 Tiny的幫助中,也沒有清楚解釋K_IVL的含義。

 

　　K_IVL與K_TMO有很大區別,但是在一定環境下最終產生的效果卻差不多。

 

　　K_TMO是指等待一個超時信號,只有時間到了,才會產生一個信號。它產生的信號是不會累計的。產生信號后,任務進入就緒狀態。K_IVL是指周期信號,每隔一個指定的周期,就會產生一次信號,產生的信號是可以累計的。這里累計的意思是,如果在指定的時間內沒有對信號進行響應,信號的次數會迭加,以后進行信號處理時就不會漏掉信號。比如說,在系統中有幾個任務,其中一個任務使用K_TMO方式延時,另外一個任務使用K_IVL延時,延時的時間相同。如果系統的任務很輕,兩個任務都可以及時響應,那么這兩種延時的效果是一樣的。如果系統的負擔比較重,任務響應比較慢,不能及時響應所有的信號,那么使用K_TMO方式的任務就有可能丟失一部分沒有及時響應的信號,而使用K_IVL方式的任務就不會丟失信號。只是信號的響應方式會變成這樣：在一段時間內不響應信號,然后一次把所有累計的信號都處理完。

 

　　下面的一個例子可以將上面兩個關于os_wait的問題解釋清楚。

 

　　在x1++和x2++這兩個地方加上斷點,進行仿真,觀察執行到斷點的時間。然后,去掉任務job4中的語句“//os_wait(K_TMO,1,0);”這一行前面的注釋符號,再次仿真。比較一下運行的結果,就可以清楚地知道它們的細微差別了。

 

　　軟件環境：Keil uVision 7.08

　　仿真CPU：AT89C52 12MHz

　　RTX51 Tiny：使用Keil自帶的RTX51 Tiny操作系統,v2.02。

　　RTX51 Tiny的參數：INT_CLOCK=10000,TIMESHARING＝5

 

　　其它參數使用默認設置。(需要自己建立一個工程文件,再將下面的文件添加到工程文件中。)

#include

unsigned long int x1,x2,x3;

void job0(void) _task_ 0{

　　x1=x2=x3=0;

　　os_create_task(1);

　　os_create_task(2);

　　os_create_task(3);

　　os_create_task(4);

　　while(1) {

　　　　os_wait(K_TMO,1,0);

　　　　x1++;

　　}

}

void job1(void) _task_ 1{

　　while(1) {

　　　　os_wait(K_IVL,1,0);

　　　　x2++;

　　}

}

void job2(void) _task_ 2{

　　while(1) {

　　　　os_wait(K_IVL,1,0);

　　　　x3++;

　　}

}

void job3(void) _task_ 3{

　　while(1) {

　　　　os_wait(K_TMO,1,0);

　　}

}

void job4(void) _task_ 4{

　　while(1) {

　　　　//注釋下面一句使系統的負擔變得很重,不能及時響應job0和job1的延時信號

　　　　//取消注釋后,系統負擔變輕,可以及時響應

　　　　//os_wait(K_TMO,1,0);

　　}

}

 

　　當job4中os_wait(K_TMO,1,0)的注釋不取消時,job0每執行一次,job1就連續執行5次,x2是x1的5倍。因為 job1中的os_wait(K_IVL,1,0)產生了5次信號,并累計下來;而job0中的os_wait(K_TMO,1,0)雖然也產生了5次信號,但是沒有累計,只有最后一次是真正有效的。

 

　　當job4中os_wait(K_TMO,1,0)的注釋取消時,job0和job1的執行次數是一樣的,x1=x2。

 

關于RTX51 TINY的分析與探討

 

 

 

1 概述

 

　　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所示。（圖沒有下載下來）

　

 

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�頾s_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<<i)；return(i)； //返回等待信號量的任務號

　　　　　　}

　　　　　　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中沒有專門的處理共享資源函數，所以在實際應用中要視情況來應用文中提到的幾種方法。

 

單片機操作系統RTX51原理分析與移