RTX51 tiny——51MCU上的多任務操作系統(轉)

最近迷上了rtx51這個RTOS，折騰了一個星期，把先前寫好的整個控制系統代碼移植到rtx51 tiny上。
摘錄一下rtx51及rtx51 tiny的介紹說明：
RTX51是Keil公司提供的一個用于8051系列處理器多任務實時操作系統，RTX51可以簡化那些復雜而且時間要求嚴格的工程的軟件設計工作，有二個不同的RTX51版本可以利用： RTX51 Full 使用四個任務優先權完成同時存在時間片輪轉調度和搶先的任務切換。RTX51工作在與中斷功能相似的狀態下，信號和信息可以通過郵箱系統在任務之間互相傳遞，你可以從一存儲池中分配和釋放內存，你可以強迫一個任務等待中斷超時或者是從另一個任務或中斷發出的信號或信息。


RTX51 Tiny 是一個 RTX51的子集，支持許多RTX51中的基本特征，可以很容易地在沒有任何外部存儲器的單片8051系統上運轉。相對于RTX51，RTX51 Tiny僅支持時間片輪轉任務切換和使用信號進行任務切換，不支持搶先式的任務切換，不包括消息歷程，沒有存儲器池分配程序。 rtx51也能完成時間片輪轉多重任務而且允許準并行執行多個無限循環或任務，任務并不是并行執行的而是按時間片執行的。可利用的中央處理器時間被分成時間片由RTX51分配一個時間片給每個任務，每個任務僅允許執行一段預先確定好的時間，然后由rtx51內核切換到另一準備運行的任務，并且允許這個任務執行一個小時間段。時間片非常短，通常為幾個毫秒，因此它表現得如同各個任務是同時地執行的。


?
簡單而又形象點打個比喻，先前寫的代碼就像是DOS下的程序，單一任務不斷循環執行，而移植后的代碼就像是基于WINDOWS的程序，雖然微觀上來看某一時刻實際上還是只有一個任務在執行，但宏觀運行效果來看，同時存在多個任務在同時運行。
?
個人認為，使用RTX51(tiny)至少有以下好處：
1、 對于復雜的控制系統應用，必然是多任務同時運行的（譬如一個任務在掃描鍵盤接受輸入時，同時有另外一個任務在驅動電機運動，再有另外一個任務在計算著電機的工作位置，還有另外一個任務在把電機的工作狀態、工作位置不斷刷新顯示到LCD上……），因此使用RTX51(tiny)更能符合思維設計習慣，不再需要為如何兼顧多個任務同時執行傷腦筋，大大簡化軟件設計工作。


2、 MCU的利用率更高，系統的響應性更好。程序里通常需要延時程序，不用RTX51(tiny)的話，通常的做法是讓CPU不斷循環執行一段無用的代碼來消耗時間，在執行延時函數時，MCU無法執行其他代碼，而使用了RTX51后，不再需要自己編寫延時函數，使用RTX51(tiny)內核提供的os_wait函數可以更加精確地進行延時，而且在等待延時完畢的過程中，MCU是在執行其他任務，一旦延時時間到達，MCU會跳回原任務繼續往下執行代碼。


3、 對防破解防盜版有一定作用。使用了操作系統后，編譯出來的二進制代碼包括了操作系統的代碼，其中有大量的跳轉、中斷切換、堆棧操作指令，很難跟蹤執行。盜版者能復制出一樣功能的軟硬件，但很難對軟件進行消化和改進。


?
心得如下：
1、 該選擇RTX51(tiny)還是其他的RTOS？ 51MCU上能用的RTOS有不少，有RTX51(tiny)，還有基于RTX51(tiny)改造出來的Small RTOS(51)，以及uCosII51。個人認為，RTX51畢竟是Keil公司的拳頭產品，浸淫了多年的技術力量，比較成熟。最后一個版本發布已經是幾年前的事，到現在都沒有用戶發現bug，可見非常穩定。而Small RTOS(51)及uCosII51畢竟是網絡愛好者的個人修改作品，穩定性如何，有沒有人真正用于復雜的控制系統，還是一個未知數。一旦用上操作系統，那么對它的穩定性要求非常嚴格，因為如果操作系統本身都有bug的話，基于其上的應用代碼無論寫得多穩健，都有可能發生一些不可預料的錯誤。對于工控設備來說，這是不能容忍的。因此個人選擇還是傾向于RTX51(Tiny)。


2、 該選擇RTX51 Full還是RTX51 Tiny？從系統要求來看，RTX51 Full對硬件要求比較高，不但需要至少650byte的片外RAM，編譯出來的代碼還會增大6～8KB，從這兩點來看，現有的大部分51單芯片都無法滿足要求，需要增加片外RAM及片外ROM，成本大大增加，而RTX51 Tiny僅需要7byte的片內RAM即可運行，編譯后的代碼也只是增加大約900個Byte，現有的絕大部分51芯片都很容易滿足這個要求。RTX51 full跟tiny之間的主要區別是tiny不支持任務搶占式運行，因此如果對控制的實時性要求不是極端苛刻的話，RTX51 Tiny完全可以滿足應用，應優先考慮使用。（嚴格來說，RTX51 Full才是實時操作系統，RTX51 Tiny不是實時操作系統，因為它不支持搶占式任務運行，只能叫多任務操作系統。）


3、 RTX51里中斷程序的編寫。RTX51系統本身占用了定時器0中斷作為時間片計時調度，也就是說EA必須置1，應用代碼里不能有對定時器0的中斷或EA的操作，也不要另行編寫定時器0的中斷代碼（如果必須要利用定時器0中斷來執行一些額外代碼，請修改conf_tny.a51里HW_TIMER_CODE段，把額外代碼插入到這個段里），否則會影響整個rtx核心的正常運行。


Rtx51里編寫中斷服務程序可以有兩種方法，一種是按常規無操作系統時的C寫法，譬如：


void int1(void) interrupt 1


{


//中斷服務代碼


}


使用這種方法時要注意中斷服務代碼要盡量優化，整個中斷服務的執行時間不能超過時間片的時間。因為缺省狀態下，所有的中斷是同一優先級別，萬一在執行其他中斷服務程序的過程中又發生了時間片任務調度中斷，那么時間片調度將由于優先級不高的原因而不執行，導致任務無法切換。因此使用這種方法的話，最好在應用程序里把定時器0的中斷優先級設置成高，保證時間片調度中斷為最優先執行。另外中斷服務里不能使用os_wait函數，否則也會導致任務切換失敗。


另一種方法是在中斷服務里使用isr_send_signal函數，把信號發給另外一個任務，讓另外一個任務來處理中斷服務。這樣內核在執行isr_send_signal函數時會自動做好相應的設置以保證時間片的調度工作正常進行。這種方法是Keil公司推薦的，穩定性高。譬如：


void fast_int (void) interrupt 1


{


isr_send_signed (5);


}


void int_handle (void) _task_ 5


{


os_wait(K_SIG,0,0); //中斷服務代碼


}


4、 RTX51 tiny信號參數的傳遞。RTX51 tiny不支持os_send_message函數，僅支持os_send_signal函數，而且這函數無法傳遞參數的，實際使用時往往需要把信號及參數傳遞給一個任務，可以使用如下方法：


uchar par1;


void task1 (void) _task_ 1 //任務1


{


par1=XXXX; //設置信號參數


os_send_sinal(2); //發送信號給任務2


……


}


void task2 (void) _task_ 2 //任務2


{


os_wait(K_SIG,0,0); //等待信號


switch (par1) //對任務信號進行處理


{ …… }


}


5、 在只有128byteRAM的51MCU上使用RTX51 tiny RTX51 tiny甚至能在簡化版的51MCU譬如AT89C2051上使用，但由于此類MCU只有128byte的可用RAM區，必須把conf_tny.a51里的“RAMTOP EQU 0FFH”設置成“RAMTOP EQU 07FH”。


6、 哪里有RTX51的參考資料最權威最詳細的RTX51tiny參考資料就是Keil公司提供的《RTX51 Tiny User's Guide》幫助文件，這個文件位于Keil uvision3安裝目錄下C51\hlp\tr51.chm.


另外Keil uvision3安裝目錄下C51\RtxTiny2\Examples目錄下有參考范例，初學者可以用uvision3 IDE調入這些范例跟蹤執行以了解RTX51的工作原理。


------*************---------
從asm51到C51，讓我從內存分配、堆棧分配、如何有效進行程序跳轉這些煩瑣的工作解放出來，專心于編寫功能代碼；而從C51到RTX51，又讓我從安排多個任務同時進行的焦頭爛額中解放出來，輕松編寫各種任務模塊，最后把這些任務用信號串起來形成一個完整的系統。每一次技術的轉變，在提高編程效率的同時，也給我帶來了全新的編程理念和全新的編程體驗。
.
原文地址:http://blog.21ic.com/user1/4836/archives/2009/54803.html

總結

以上是生活随笔為你收集整理的RTX51 tiny——51MCU上的多任务操作系统(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。