RTX51 tiny——51MCU上的多任务操作系统(转)

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