在MSP430F149上移植μC/OS Ⅱ实现人机界面系统的设计

人机界面（human-computer interface），又称用户界面、人机交互、人机接口等，是人与机器之间传递、交换信息的媒介．是用户使用计算机系统的综合操作环境。在商品竞争中，一个应用系统的成功与否在某种程度上也取决于用户使用界面的感受好坏，因此，人机界面的设计在应用系统的设计中有着重要的作用。嵌入式系统强调人机界面操作的实时性，简单化，强调在特定平台上特定应用的时间空间效率。在传统的小系统设计中。程序设计一般采用前后台工作方式。应用程序是一个无限的循环，循环中调用相应的函数完成相应的操作，时间相关性很强的关键操作（crltical operation）是靠中断服务来保证的。因为中断服务提供的信息一直要等到后台程序走到该处理此信息这一步时才能得到处理．这种系统在处理信息的及时性上，比实际可以做到的要差。最坏情况下的任务级响应时间取决于整个循环的执行时间。因为循环的执行时间不是常数，程序经过某一特定部分的准确时间也是不能确定的。如果程序修改了，循环的时序也会受到影响．

实时操作系统将应用分解成多任务，简化了应用系统软件的设计。良好的多任务设计，有助于提高系统的稳定性和可靠性，并使系统的实时性得到保证。很多实时操作系统提供了专用函数，简化了程序的测试。

1 系统设计

如图1所示，人机界面系统采用小键盘操作的文本菜单方式，使用在嵌入式数字视频录像DVR（Digital Video Record）系统中。在MSP430F149上移植μC/OS—Ⅱ来独立实现人机界面的功能，用户通过键盘输入指令，经过单片机处理后发往主系统，同时把相应信息通过专用芯片的OSD（0n Screen Display）功能显示在监视器上；用户根据监视器上的信息进行菜单操作，形成人与机器的交互。

把人机界面部分从主系统中独立出来，用户所有输入的指令由单片机来处理，减少了主系统的工作量，使整个系统模块化，便于开发和调试，提高了可靠性和稳定性．另外，这种人机界面设计具有通用性，便于移植到各种嵌入式系统中。本系统选用MSP430nF149单片机，是基于以下三个方面的原因：

①OSD功能需要经常刷新，并且要处理与主机部分的数据交换，要求单片机的计算速度足够高，并且要求嵌入式系统能够长时间正常运转，且芯片功耗低。

②实时操作系统本身要耗费一部分内存，同时0SD功能要求建立字库，要求内存空间足够大，否则要外接闪存，增加设计的复杂度及成本。

③要连接键盘电路，需较多I／O口。

MSP430系列单片机是由TI公司开发的16位单片机。其突出特点是强调超低功耗，适合于各种功率要求低的应用；有较高的处理速度，在8 MHz晶振的驱动下，指令周期为125ns;MSP430F149具有60 KB的Flash ROM和2 KB RAM，可满足系统程序量和数据量大的要求，可以解决因为加载实时操作系统而增加的内存需求，具有2个串行通信接口，其中一个串口用于跟主系统通信，另一个可用于控制其他外围模块；具有48个可独立编程的I／O口，其中有2个具有中断功能的8位并行端口，在设计按键电路时，可方便地采用中断方式识别键值。

2 软件设计与实现

2.1 实时操作系统

μC／OS—II是一个源码开放，拥有抢占式内核，支持多任务的实时操作系统；任务被分为休眠态、就绪态、运行态、挂起态和被中断态五种状态，内核根据任务所处的状态对任务作相应的处理，已经准备就绪的高优先级任务可以剥夺正在运行的低优先级任务对CPU的使用权。系统大部分代码采用C语言编写，与硬件相关的部分很集中，并给出了规范的接口说明，移植相当方便，可应用于目前大多数型号的8位、16位、32位CPU。μC／OS—II提供的仅仅是一个操作系统内核，对硬件系统要求很低，很适合在低端CPU上开发小系统。

将μC／OS—II移植在MSP430F149单片机上，对其进行裁减，只保留消息队列一种任务间通信方式，利用它的任务优先级抢占机制，使人机界面很好地满足嵌入式系统对实时性和可靠性的要求。下面详细介绍基于μC／0S—II操作系统的程序设计。

2.2 软件设计

本系统的软件部分设计基于E-O模型的思想，划分事件和目标。以有限状态机的方式，在实时操作系统μC／OS一Ⅱ中，用状态机把目标和事件联系起来，实现OA （Object-Action）行为模式完成人机交互的过程，使以小键盘操作的文本菜单方式设计更清晰。

2.2.1 事件-目标驱动的用户界面模型

事件-目标驱动的用户界面模型，即E-O模型（E-vent-Object Drive User Interface Model），将人机交互活动归结为事件与目标的相互作用．事件是人机交互活动中传递的信息，目标是交互活动的对象；事件引发交互活动，目标是交互活动的承受者。E-O模型基于的基本行为模式是“目标-动作”（OA），以目标为核心，具有面向对象风格。

E-O模型由四个逻辑部件组成：①设备管理模块（device management module），提供与各种交互设备的接口，实现设备无关特性；②事件管理子系统（event Man-agement subsystem），它读取输入设备的输入信息形成事件并进行统一管理，将反馈信息的事件解释为适当的输出指令并传送给输出设备；③目标管理子系统（object Man-agement subsystem），创建、装载、保存用户界面中各类目标，并对目标进行管理，④事件-目标管理子系统（event-object management subsystem），主要职责是实现事件与目标的整合，按适当策略控制事件在各目标结点之间流动，以形成和维持交互的过程，是整个用户界面系统的核心。

2.2.2 有限状态机的形式化描述

有限状态机FSM（Finite State Machine）由状态、事件、转换和活动组成。每个状态有1个状态进入动作（entryaction）和1个状态退出动作（exit action），每个转换有1个源状态和目标状态并且与1个事件相关联。当在源状态时，该事件发生且触发转换的监护条件为真，则顺序执行下列一些动作：①源状态的退出动作；②转换动作；③目标状态的进入动作。

FSM可以形式化表示为1个五元组：M=（0，I，λ，S，δ，S0）。

其中，S为有限状态集；

I为有穷的事件输入集；

0为有穷的输出集，

S0为初始状态集；

δ：S×I→S，进入下一个状态的过程；

λ：S×I→O，产生输出的过程。

T=δUλ。T中的每个元素又可以表示为1个五元组，T=（Soure-State，Target-State，Input-Event，Con-straint，Action）。其中“Source-State”和“Target-State”分别表示T的初始状态和目标状态，“Input-Event”表示来自于I的输入事件或为空，“Constramt”表示监护条件及输入事件参数等约束，Action表示转换执行的动作。

用软件实现有限状态机有两种方法：表格法和过程驱动法。表格驱动法利用一个二维数组。该数组中的短一行与一个状态相对应，每一列与一个输入事件相对应，每一项则与某一状态下对事件的处理相对应。表格驱动法适用于具有结构规则、操作简单的有限状态机。

过程驱动法为每一个状态都定义一个处理过程，处理过程实现在此状态时对事件的响应，包括输出处理及对当前状态值的转换。这个过程可以用case语句区分事件，并采用相应的处理。无论采用何种方法实现FSM，当FSM收到一条消息时必须知道当前的状态。为此，对应每一个状态机必须能够保存当前所处的状态。过程法适用于实现一个具有几种转换和复杂操作的有限状态机。

2.3 程序设计与实现

基于消息驱动的程序设计思想，为了保证系统的实时性，在中断中只负责发送消息到相应的任务的消息队列，由应用级的任务来处理，保证各个处理的时间是可确定的．主程序在消息循环中不断地判断各个任务的状态，执行进入就绪态的任务。这就允许采用异步方式处理各种中断及任务。

本系统程序中采用了两组有限状态机，运用消息驱动的方式来驱动状态的变更。一组是通信任务中以串口接收数据驱动为事件对象的有限状态机，另一组是以用户按键和命令码驱动为事件对象的有限状态机．在实时操作系统μC／OS一Ⅱ下，整个人机界面分为三个模块，即三个任务来实现，分别是键值处理模块、与主机通信模块和时钟模块。

（1）键值处理模块

OSTaskCreate（KEYTaskStart，（void*）O，&TaskKey-Stk［］，7）；

先初始化所有的模块，然后在循环中接收并处理键盘的输入，Key-Process（char KeyValue）根据相应的输入键值和系统所处的状态，对菜单进行相应的操作。

State_Trans（char RxData）根据键值输入事件负责调度系统的状态，并在相应的状态下，根据从主系统收到的信息显示菜单。

（2）主机通信模块

OSTaskCreate（UARTTaskskStart，（void *）O，& TaskU-artStk［］，6）；

通过消息队列OSQPend（OS_EVENT*pevent，INTl6U timeout，INT8U*err），接受串口中断发来的消息队列，对其中的数据进行处理。在人机交互的过程中，需要大量的与主系统的交互，单独用一个任务负责与主系统的通信，实现串口接收数据驱动的有限状态机。

（3）时钟模块

OSTaskCreate（TimcTCk，（void*）O，&TimeTickStk［］，5）；

时钟任务，使用单片机的时钟中断，可以设置各个任务需要的定时器，通过消息队列发给需要定时的任务。

2.3.1 串口接收数据驱动的有限状态机

为了保证通信的可靠，系统中采用停止等待协议。在发送数据前要对数据打包，接收到数据要先解包，单片机在接收主系统发过来数据包的后需要去掉通信协议字段，然后对有效数据进行正确的处理。为此，定义了一个Frame-FSM类型的数据结构，用来对接收到的数据进行处理。

typedefstruct{

byte State； ／／当前所处的状态

byte SYM_Plas；／／转义字符标志，若为1，表示需对当前

／／数据转义

bytc DatoLenoth；／／数据长度

byte CheekSum；／／校验和

byte Offset； ／／偏移地址，对应当前接收到的数据在

／／该帧中的位置

byteFrame_Data；／／帧内的有效数据

}Frame_FSM；

利用主机发送过来的消息驱动有限状态机，串口接收数据驱动的有限状态机包括以下几种状态；

①任意状态。无论单片机原来处于何种状态，收到字符0xaa，都表明1帧新的数据即将开始发送。此时，如果单片机处于1帧正在接收的状态。就会丢弃原数据重新进入收到同步字符状态。

②任意状态（除了INIT_STATE之外）。无论单片机原来处于何种状态．收到字符0xfc，都表明系统中出现了转义字符。此时，将转义字符标志置1，丢弃当前接收的数据后返回；每一次进入重建帧处理函数后，系统会首先判断转义字符标志是否为l。若为l，则根据当前字符进行转义（当前字符为0x00，则转义为Oxaa；当前字符为0x01，则转义为Oxfc；如果为其他字符则丢弃），然后将转义字符标志重新清O。

③INIT_STATE，初始状态。在这个状态下，将重建帧的偏移地址和校验和清0，然后等待接收数据。收到起始宇符Oxaa后，将状态转入AA_SYN_STATE；收到其他字符都丢弃不理。

④AA_SYN_STATE，收到同步字符状态。在这个状态下，MCU将重建帧的偏移地址和校验和清0，然后将状态置为接收源地址状态。

⑤SRC_ADDR_STATE，收到源地址状态。此时比较源地址是否是主机地址。若是，则转接收目的地址状态；否则，转初始状态。

⑥DEST_ADDR_STATE，收到目的地址状态。此时比较目的地址是否是MCU地址。若是，则转接收数据长度状态；否则，转初始状态；

⑦DATA_LEN_STATE，接收数据长度状态。将数据长度备份，转入接收数据状态。

⑧DATA_STATE，接收正常数据状态。将接收的数据存入接收数组REBUF中，每接收到一个数据就将对应的偏移地址加l，接收数据长度减1，并且计算此时的校验和。当数据长度减为0时，表明l帧数据已经全部接收完毕，转入检验校验和状态。

⑨CHECKSUM_STATE，接收校验和状态。将接收的校验和与本地计算的校验和进行比较。如果两者相等，将状态转为INIT_STATE，然后对正确的数据帧进行处理，并给主系统发送一个确认帧；如果两者不等，丢弃该帧，状态转入INIT_STATE，等待接收新的数据帧。

对应的状态转换图（state transition diagram）如图2所示。

2.3.2 键值和命令码驱动的有限状态机

这组有限状态机主要依靠用户对菜单的操作进行状态转换，即把键值和命令码作为FSM的激励源，其中键盘消息是最主要的激励源。应用层的FSM具有多种主状态，用户未按键或者是没有接收到新的数据帧时，状态处于IDLE_STATE；接收到消息后，转入对应的主状态。然后，根据按键的不同或者是接收命令码的不同，转入对应的子状态进行处理。任务处理完毕，再将状态置为IDLE_STATE，按取消键，可回到上一级状态。

以用户控制云台上下左右转动为例，系统开始处于IDLE_STATE。若用户按云台镜头控制键，则进入云台镜头选择状态，并显示云台镜头控制菜单．选择云台控制选项后，进入云台方向设置状态；选择向上键，转入向上状态。在该状态执行向上命令操作后，状态重新转入IDLE_STATE，并伴随着输出菜单的相应变化，按取消键可回到上一级云境选择状态。对于其他按键，系统全部过滤掉不作响应，状态也不进行转换。云台控制的状态转换图如图3所示。

3 测 试

μC／OS—IIV2.52较以前的版本，增加了两个系统任务一一CPU负荷监测任务与堆栈容量检查任务。这两个任务给程序的调试带来很大的方便。

将系统配置常数OS_TASK_STAT_EN设为l，统计任务OSTaskStat（）就会建立。它每秒钟运行1次，计算出当前CPU的利用率，放在一个有符号的8位整数0SCPUUsage中，精确度是l％。

μC／OS-Ⅱ内存是固定分配的，通过0STaskStkChk（）可确定每个任务实际需要的最大堆栈空间，根据测得结果合理地分配内存空间。表l是用以上函数测出的系统参数。

与MSP430单片机系统相应的调试工具Embedded Workbench，可跟踪程序的运行。通过运行在PC机上Embedded Workberlch能够追踪程序中各种参数的变化，查看单片机内存的使用情况。

结 语

本系统使用μC／OS-II后，系统的总体性能有了很大提高。使用实时操作系统前。运用前后台的程序设计方式。在需要显示较多数据在屏幕上，同时又需要接收数据时，单片机处理不及时，可以通过调试工具WorkbenCh看到接收缓存接收的数据帧不完整，而不能正确地在屏幕上显示数据。移植操作系统之后，工作可靠，同时系统的反应速度，即实时性有了很大提高。文中介绍的人机界面与嵌入式主系统是独立的模块，可以灵活地在单片机上加载控制模块，适合应用于各种嵌入式系统中。