基于RTX51实时操作系统的用户专用键盘软件设计

摘要：随着单片机应用的扩展，原有的编程思想难以满足复杂多任务系统的要求，为此将操作系统引入单片机软件设计。文章在用户专用键盘软件开发中引入PTX51实时操作系统，介绍了整个系统的任务分配，分析了各个任务的运行机制，并给出流程图及主要程序代码。通过采用RTX51实时操作系统，不仅提高了软件开发效率，而且控制方案更加科学合理。
关键词：RTX51；多任务；单片机；软件设计

0 引言
    传统的用户专用键盘单片机软件采用结构化设计方法，主程序循环执行，依次完成按键扫描、按键处理、串口命令接收、串口命令处理等任务。由于任务的数量少，并且每个任务执行的操作简单，此种设计可以使得软件较好地满足功能要求。但仔细分析，会发现程序一些可以改进的地方，如：执行时间短的任务不得不排队等待执行时间长的任务的完成。此外，如果用户的设计要求发生变化(如：专用键盘功能增加、按键数量增多、串口协议复杂化等)，原有的编程思想将很难满足要求，程序因此无法进行移植升级而不得不重新开发。
    基于RTX51实时操作系统进行单片机软件设计，可以真正做到各任务并行执行，同时，由于程序结构更加科学合理，可以方便地实现修改升级，以满足功能较多的设计要求。

1 用户专用键盘简介
    用户专用键盘多使用在工业控制场合，它由按键和指示灯组成，对外采用RS232接口，当某个按键按下时，键盘将命令(码值)发送计算机，同时，键盘接收来自计算机的命令(码值)点亮(熄灭)某个指示灯，以指示系统工作状态，从而实现快速人机交互。用户专用键盘硬件原理框图如图1所示。

    图中，可编程逻辑芯片实现单片机输出接口扩展，其内部包含多个输出锁存器。工作时，单片机输出的地址信号经可编程芯片内部译码器译码产生片选信号，使能不同的输出锁存器，将数据信号输出控制各个指示灯的亮／灭。

2 RTX51实时操作系统介绍
    RTX51是德国Keil公司开发的一种应用于MCS51系列单片机的实时多任务操作系统，它有两个版本，RTX51 Full和RTX51 Tiny，本文采用
RTX51 Tiny进行软件设计。RTX51 Tiny是一个很小的内核，完全集成在Keil C51编译器中，它可以很容易地运行在没有扩展外部存储器的单片机系统上，并且仅占用800字节左右的程序存储空间。
    RTX51 Tiny允许最大16个任务循环切换，在实现上，它采用时间片轮转算法，系统每次调度时，把CPU分配给一个就绪的任务，并令其执行一个时间片，构成微观上轮流运行、宏观上并行执行的多任务效果。RTX51 Tiny支持任务间的信号传递，还能并行地利用中断功能。
    RTX51 Tiny的用户任务主要具有以下几个状态：
    ·运行(RUNNING)：任务正处于运行中。同一时刻只有一个任务可以处于“RUNNING”状态。
    ·准备好(READY)：等待运行的任务处于“READY”状态。在当前运行的任务退出运行状态后，就绪队列中的任务根据调度策略被调度执行，进入到运行状态。
    ·等待(BLOcKED)：等待一个事件的任务处于“BLOCKED”状态。如果等待的事件发生，则此任务进入“READY”状态，等待被调度。
    RTX51 Tiny内核用以下事件进行任务问的通信和同步：
    ·超时(TIMEOUT)：由OS-wait函数调用引发的时间延时，持续时间可由定时节拍数确定。带有TIMEOUT值调用OS-it函数的任务将被挂起，直到延时结束，才返回到“READY”。
    ·间隔(INTERVAL)：由OS-wait函数调用引发的时间间隔，其间隔时间可由定时节拍数确定。带有INTERVAL值调用wait函数的任务将被挂起，直到间隔时间结束，然后返回到READY状态。与TIMEOUT不同的是，任务的节拍计数器不复位，典型应用是产生时钟。
    ·信号(SIGNAL)：系统定义的位变量，可以由系统函数置位或清除。可以调用OS-wait函数暂停一个任务并等待从另一任务发出的信号，这可以用于协调两个或更多的任务。如果某个任务在等待一个信号并且信号标志为0，则在收到这个信号之前，这个任务将一直处于挂起状态。如果信号标志已经被置1，则当任务查询信号时，信号标志会被清除，任务将可以被继续执行。

3 用户专用键盘软件设计
3．1 任务分配
    根据前面对用户专用键盘功能的描述，它主要实现以下两个功能：
    (1)按键处理；
    (2)串口数据处理。
    其中功能(1)又可细分为以下三个任务：
    任务1：按键状态扫描；
    任务2：按键码值查询；
    任务3：串口发送；
    同样，功能(2)也可细分为以下两个任务：
    任务4：串口接收；
    任务5：串口数据处理；
    以上两个功能需要并行运行，而内部的子任务之间为前级驱动后级的关系，在程序实际运行过程中，功能二(2)的任意子任务可能与功能(1)的任务1或任务2或任务3处于同时并行运行状态，鉴于此，需要在程序设计时创建5个子任务。
    采用时间轮询的方式决定了某个任务在执行完时间片后，在下一次执行前需要等待固定的时间，这个时间与系统的任务数及每个任务的执行时间密切相关，为避免数据丢失，串口接收任务应及时读取接收缓存器中的数据。由于中断处理过程与正在运行的任务是相互独立的，即中断处理过程在RTX51系统内核之外和任务切换规则没有关联，因此可以在串口中断服务程序中完成串口接收任务。另外，串口发送时要求将整个按键码值数据包一次性发送完毕，如果将串口发送过程在中断服务程序中完成，在SBUF缓存器发送完一个字节后触发串口发送中断标志，再次进入中断服务程序继续下一字节数据的发送，则可以方便地实现上述要求。根据以上分析，串口接收、串口发送两个子任务的功能在中断服务程序中完成，将系统子任务的个数由5个减少为3个，调整后的任务分配如下：
    任务1：按键状态扫描(TASK SCAN)；
    任务2：按键码值查询(TASK KEY)；
    任务3：串口数据处理((TASK LIGHT))；
    中断服务程序：串口接收、发送。
    任务间信号关系如图2所示。

    如图，任务1在检测到按键状态变化后向任务2发送信号，任务2随后由等待状态进入“准备好”状态，在本任务的下一个时间片，任务2开始进行指定位置按键的码值查询，然后通过串口完成码值发送。
    同时，串口数据通过中断服务程序接收，串口数据接收后即发送信号给任务3，使后者进入“准备好”状态，并在下一个时间片到来后进行数据处理。
    以上三个任务中，任务l始终处于“运行”或“准备好”状态，任务2、任务3大多数时间处于“等待”状态，任务2、任务3分别在接收到按键状态扫描任务、中断服务程序的信号后被“唤起”。另有任务0，负责创建任务1、2、3，然后删除自己。任务0简化程序如下所示：
    #define INIT 0／*任务0：初始化及创建*／
    #define SCAN 1／*任务1：按键状态扫描*／
    #define KEY 2／*任务2：按键码值查询*／
    #define LIGHT 3／*任务3：串口数据处理*／
    Init()_task_INIT{
    Serial_init()；
    Os_create task(SCAN)；
    Os_create_task(KEY)；
    Os_create_task(LIGHT)；
    Os_delete-task(INIT)；
    }
    以下对中断服务程序及各个任务分别予以介绍。
3．2 中断服务程序
    用户专用键盘串口接收、发送中断服务程序流程如图3所示。

    由于中断可能由发送控制器或接收控制器引起，因此在程序中首先要判断是接收中断还是发送中断，然后分别进行处理。对于接收的数据，程序将其存入接收缓冲区，然后通知串口数据处理任务进行处理。
    用户专用键盘数据的发送在中断服务程序中完成，上一字节的数据发送完毕产生中断，进入中断服务程序继续完成下一字节的发送，而发送缓冲区中的数据由系统在按键码值查询任务中存入。简化的中断服务程序如下：

3．3 串口数据处理任务(TASK_LIGHT)
    中断服务程序只处理串口缓存器SBUF的读取或写入，数据一旦接收完毕即存入缓冲区，并在专门的任务中进行处理。在多任务系统的用户专用键盘程序中，串口数据处理任务在创建后即被“挂起”，此时该任务处于“等待”状态，不占用任何时间片，只有当任务接收到“唤起”信号后才继续执行。本程序中“唤起”信号来自中断服务程序。由于中断处理过程可以同RTX51任务互发信号或交换数据，因此，中断服务程序在接收到数据后立即发送信号量给串口数据处理任务，使后者处于“准备好”状态，当下一时间片来到时，串口数据处理任务继续执行，完成数据解析及控制指示灯等操作。由于该任务为循环操作，当所有接收的数据处理完毕后，任务再次进入“等待”状态，等待下一次串口数据接收后的处理。图3中，斜体部分即为中断服务程序发送信号至串口数据处理任务的过程。串口数据处理任务的简化程序如下：

3．4 按键状态扫描任务(TASK SCAN)
    按键状态扫描为一个循环执行的任务，程序通过不断地读取单片机IO口的值获取每个按键的当前状态，然后将当前状态值与存储在内存中的上一次状态值进行比较，通过比较结果判断该按键状态是否发生变化。为消除按键按下时抖动造成的多次状态变化，在扫描到某个按键状态发生改变后，延时一段时间后进行第二次扫描，如果两次扫描结果相同则认为该按键状态确实发生改变，并转入下一步处理。按键状态扫描任务流程如图4所示。

    下面给出按键状态扫描任务简化的源程序：
    Scan()_task_SCAN{／*按键状态扫描任务*／
    …
    While(1){
    Key_first_scan()；／*第1次扫描*／
    If(Keychanged=1){
    Os_wait(K_TMO，2，0)／*延时*／
    Key_second_scan()；／*第2次扫描*／
    If(first scan=second scan){／*如果两次扫描的按键状态一致*／
    os_send_signal(2)；／*发送信号至按键码值查询任务+／
    }
    }
    }
    }
    程序中，采用等待超时信号(K_TMO)来实现两次扫描间的延时，这样设计的好处是，在延时期间，由于本任务处于“等待”状态，系统可以进行任务切换，使其它任务继续执行，从而在保证系统功能的前提下，提高整个系统的工作效率。需要注意的是，K_TMO是等待产生超时信号，当信号产生后，只是将相应的任务置上“准备好”标志位，任务并不是立即就能够运行，任务需要等到其它任务轮流执行，到自己的时间片后才会执行。这样，最后的延时效果是延时时间加上正在运行的任务的执行时间。在用户专用键盘软件中，同时可能在运行的任务只有“串口数据处理”。由于该任务运行时间与K TMO延时时间比较少很多，因此可以忽略不计，而认为两次扫描间的延时时间就是K_TMO的时间。假设同时运行的任务较多，并且每个任务占用的时间较长，则延时时间应该取K_TMO加上所有同时运行任务的执行时间之和，即按键按下的时间必须不小于此时间，才能保证每次按键操作都能正确响应。
3．5 按键码值查询任务(TASK KEY)
    按键码值查询任务程序流程如图5所示。

    由于发送数据在串口中断服务程序中完成，因此，在将数据存入发送缓冲区之前必须确认缓冲区中有数据即串口发送中断会被再次触发，否则只有将数据写入串口发送缓存器SBUF直接发送。
    下面给出按键码值查询任务简化的源程序：
    Encode()_task_KEY{
    …
    While(1){
    Os_wait(K_SIG,0,0)；／*等待键码查询信号*／
    Keygetcode()；／*获取键码值*／
    If(sendempty=1){／*判断发送缓冲区是否为“空”*／
    SBUF=keycode；／*发送缓冲区为”空”，则直接发送*／
    }Else{
    Outbuf[i++]=keycode；／*否则，将数据存入缓冲区，*／
    ／*待上一数据发送完后自动发送*／
    }
    }
    }

4 结论
    实践证明，在引入RTX51 Tiny实时操作系统后，软件开发周期缩短，程序结构更加清晰，系统实时性和并行性大大增强，开发出的程序具有较高的可维护性和可移植性。