<acronym id="xonnx"></acronym>
      <td id="xonnx"></td>
    1. <pre id="xonnx"></pre>

      1. 專注電子技術學習與研究
        當前位置:單片機教程網 >> MCU設計實例 >> 瀏覽文章

        RTX51 Tiny 實時內核理解

        作者:佚名   來源:本站原創   點擊數:  更新時間:2014年08月19日   【字體:

         聲明:以下來自網絡整理而來并非本人作品,覺得挺容易懂所以放入博客以便后來學習者參考

         
        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兩個參數。這兩個參數決定了每個任務使用時間片的大。篒NT_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無關;蛘哒f,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” 狀態的任務,通過堆棧管理,將自由堆?臻g分配給該任務,使其成為當前任務。清除使該任務進入“READY”或“TIMEOUT”狀態的相關位后,執行該任務。任務切換的流程如圖1所示。(圖沒有下載下來)
         
         
        3 共享資源實現[1]
         
          RTX51 TINY由于是一個多任務的操作系統,那么就不免會有幾個任務使用同一個資源,這些資源可能是一個變量,也可能是輸入/輸出設備。這就要求一個任務在使用共享資源時必須獨占該資源,否則可能會造成數據被破壞。
         
           在RTX51 TINY中實現共享資源獨占的方法比較多。比如,可以通過TIMESHARING這個變量來禁止時間片輪轉,使其值為0,就可以實現禁止任務切換,從而當前任務就可以獨占共享資源。還可以關閉中斷來實現,使EA=0,定時器T0的中斷被關閉,不能再為時間片輪轉提供基準,從而禁止了任務切換。但這兩種方法都帶有一定的局限性,前一種方法只能適用于實時性要求不高的場合,后一種方法由于T0中斷關閉時間不能太長,只能適用于一些簡單變量操作的場合;谝陨锨闆r,下面通過另一種方法來實現共享資源的使用。
         
          在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<<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中沒有專門的處理共享資源函數,所以在實際應用中要視情況來應用文中提到的幾種方法。
         
        關閉窗口
        欧美性色欧美精品视频,99热这里只有精品mp4,日韩高清亚洲日韩精品一区二区,2020国自产拍精品高潮