构建在中小规模CPU上的实时UML框架程序设计环境

通过状态机部件、基础框架、任务管理内核和跟踪调试器的移植证明了这种平台在中小型CPU上运行的可行性、便捷性和高可靠性等优点。最后，通过航天相机控制器应用程序设计实例中各个任务线程的执行时间测量结果及可调度结果进一步验证了该平台的实用性。

0 引言

随着高级编程语言和操作系统在越来越多种类的CPU构架上的应用，系统应用程序变得越来越大，越来越复杂。并且实际应用大多对于程序的设计周期、可靠性都具有很高的要求。基于传统的嵌入式实时操作系统的软件设计，虽然可使程序的实时性能得到提高，但是并行程序设计过程中存在着更多的竞争状态，而且这些竞争状态极难被发现。如何能够找到一种符合软件工程学的程序设计方法成为每个嵌入式软件工程师所面临的问题。

传统的实时操作系统虽然可以完成任务管理，但是往往代码量较大，任务切换要求复杂，完全摒弃编译器提供的程序调用机制，采用任务堆栈机制，接口程序设计要求高，实现任务切换时占用资源较大，不适合应用于8位和16位总线构架的CPU上。

另一方面，基于UML 的实时框架程序设计方法对于当今的高复杂性、短开发周期的商业环境来说变得越来越重要。主要是因为UML 语言是可执行的，所以根据UML 建立的系统行为模型可以生成可执行代码，从而节约了从抽象模型到手工编写可执行代码的费时、费力的工作量。但是所有的UML 代码生成工具是为类似PC上应用而设计的，不适合应用于中小型的CPU,且售价昂贵。

如果将RTOS的实时性与UML模型设计的直观性、安全性和便捷性相结合，应用于中小规模的CPU 芯片无疑会给深度嵌入式系统开发带来更多的手段。

1 实时UML 框架程序设计平台(QP)简介

QP是使用实时抢占式任务管理内核、基于UML状态图的软件设计方法的轻量级软件平台，是一种新式操作系统。QP软件平台结构如图1所示由以下4个部件组成。

1.1 任务管理内核(QK)

QK也采用了类似其他商业内核的优先级的抢占机制以保证关键任务得到实时执行。但是QK 实现抢占的原理有别于任何一种操作系统。QK采用的是Moore状态机的“运行到结束”的机制，因此当系统还在忙于处理前较低优先级事件时，当较高优先级的事件到来时，系统将新事件存储在消息队列中，直到低优先级事件完成后，再执行新事件。QK 的实现原理不同于传统RTOS的堆栈操作，仅使用C 语言编译器的中断服务程序(ISR)机制就可完成。也就是QK的移植完全不需要插入额外的汇编语句。所以，任务切换时没有额外的开销，执行速度快，相当于子程序调用。当然如果使用其他RTOS 的任务管理功能也能代替QK,稍候在QP 到TMS320LF2407的接口程序设计部分介绍。

1.2 基础框架平台

该框架平台完成了驱动事件管理功能、状态机架构管理和实时任务管理功能。

实时UML框架序设计平台(QF)中任务是由能实现轻量级UML状态机和用来接收触发事件的消息队列组成。因此基于实时UML框架的任务具有UML状态机的特点。QF 将任务分为激活状态和休眠状态，QF 根据触发事件和任务优先级对其进行管理。实际工作时任务间采用异步的事件发送和接收机制进行通信。任务使用消息队列接收其他活动对象的事件消息;同时，不同任务产生的事件也会利QF投送给其他订阅该消息的任务。对于触发事件的交换，排队，收集，销毁等工作则由QF统一完成。可见，任务间通过QF框架进行间接通信，实现了事件松耦合。因此，基于QF的程序设计可以采用模块化的设计方法，给设计过程中方案的修改和设计后期的软件维护提供了极大的方便。正像使用UML 的自动设计工具软件进行程序设计的过程一样，使用QF的程序设计也遵循以下过程：使用UML语义进行模型设计，根据QP平台代码转换方法将UML模型转化为源代码。

总之，基于QF的程序设计实现了可视化程序设计和“自动”代码生成的目的;另外，在嵌入式系统中也可以将QF当作为一个软件总线，将QF的接口移植到其他OS之上，以隐藏下层硬件和软件的差异。

1.3 状态机部件(QEP)

上节提到的QF任务的状态机的特性是由状态机部件(QEP)完成的。QEP是一个简化的轻量级的UML状态机部件，实现了状态机的状态转换触发事件响应等功能。QEP提供了两种状态机类型：层次化状态机(HSM)和平面状态机(FSM)。

1.4 跟踪调试器(QSPY)

QSPY 使用缓存机制采集系统内运行状态，事后在空闲任务时再编码输出，再有在整个QP 平台中QSPY调试插件有机的与系统关键运行环节有机的结合在一起，因此基于QSPY的调试可以获得更多的系统的信息的同时又不会过多地干扰程序的正常运行。在这一点上比传统RTOS中的跟踪调试器更领先一步。

2 QP 到TMS320LF2407 的接口移植

QP存在C和C++版本。基于C语言版本的精简版QP平台的代码量可以在4 KB左右，可以轻易的放入到大多数的小规模CPU的片上存储器中。并且该平台的实现原理如上节所述可以使用C编译器实现[4],因此移植工作量极少，仅需几十行的C语言程序就可完成。显然在诸如TMS320LF2407 的中小型的CPU 上更适合使用基于C 的版本。QP 移植主要的工作集中在改写qep_port.h,qf_port.h,qf_port.c,qk_port.h 和qs_port.h 这4 个文件。

2.1 QEP的接口移植

QEP 完成了状态机的实现机制。配置和移植QEP需修改qep_port.h头文件中关于各种数据类型和主要参数的定义。其中主要的有Q_ROM,Q_ROM_VAR 和QEP_SIGNAL_SIZE 三个宏定义。Q_ROM 宏是用来定义常变量到程序存储区域的，比如使用较大的表或数组等常数时不希望占用RAM资源时，将其定义在程序区，可以使用Q_ROM宏。定义方法根据不同的编译器而不同，比如在Keil C51 中Q_ROM 被定义为code 关键字。

Q_ROM_VAR 宏用来定义如何采用指针类型取程序存储器变量。QEP_SIGNAL_SIZE 宏用来定义信号宽度，通常为1,2或4.针对TMS320LF2407的硬件结构特点定义了8位、16位和32位有符号和无符号数的类型。

2.2 QF的接口移植

QF 的移植主要集中在对于状态机和任务管理方面。在qf_port.h 中根据实际的软件需求修改状态机实现相关的定义，例如触发事件的类型、事件队列的深度和事件缓存的容量。QF中事件初始位置存放在事件缓存区中，所有的任务间的事件传递使用指针方式进行，从而有效地减少了事件传递对内存的开销。任务管理方面定义了最大任务数、中断嵌套相关的定义以及任务切换的机制。

在pf_port.c中需要编写有关诸如QF平台开始和退出代码，如无特殊需要这些函数可以使用空函数代替。

QP平台中对于程序的运行关键位置使用了断言手段进行约束，在平台运行异常时会给出诊断信息。在pf_port.c 的Q_assert_handler()函数可以返回平台错误信息。

2.3 QK的接口移植

QP平台的任务调度机制在QK中完成。因此QK的移植需要根据TMS320LF2407 的编译工具进行接口函数的设计。所有调度相关的定义在qk_port.h 头文件中。其中主要的是中断相关的定义，如：开关中断的机制和中断响应程序的进入和退出机制等。

QK 中使用QK_INT_KEY_TYPE,QK_INT_LOCK(key_)，QK_INT_UNLOCK(key_)三个宏接口定义了中断开关机制。其中QK_INT_KEY_TYPE 定义了中断嵌套时中断优先级传递参量类型。QK_INT_LOCK(key_)定义了关中断的机制，QK_INT_UNLOCK(key_)定义了开中断的机制。在TMS320LF 因为在TMS320LF2407 的C 编译器中没有直接对ST0、ST1 寄存器进行操作的方法，此处使用嵌入汇编实现中断使能和中断禁止功能。还有，在TMS320LF2407 中具有中断优先级管理器，因此中断传递参数类别QK_INT_KEY_TYPE在本移植中不用定义。

QP 中中断服务程序相当于最高优先级的任务，因此中断的进入动作QK_ISR_ENTRY()和退出动作QK_ISR_EXIT()需要特殊规定：QK_ISR_ENTRY(pin,ISR_PRIO)：首先是，将当前QK 优先级保存到变量pin上;然后将当前QK的优先级ISR_PRIO改变为最高优先级别;最后使能中断。QK_ISR_EXIT(pin)中断服务程序退出动作的过程是：关中断，清中断寄存器结束中断标记，从变量pin中恢复以前的优先级，调用QK的任务切换函数进行任务调度。

需要注意，TMS320LF2407 中断有2 种类型：一种由事件管理模块管理，不需要使用程序清中断标志位，如定时器，计数器，PWM 等设备;另一种需要任务清中断标记，如串行外设接口(SPI)、串行通信接口(SCI)、CAN 总线等。所以在中断退出时需要分别处理，一般在BSP中进行。[!--empirenews.page--]

2.4 QS 的接口移植

QS 完成了软件系统运行信息的收集和输出功能。

QS移植需要修改qs_port.h文件。其中定义了系统信息缓存区的深度，定义了在空闲时系统信息的输出方式等。

3 基于QP 的航天相机控制器控制软件的实例通过上节所述的构建过程QP 平台被移植到了TMS320LF2407上，下面通过某航天相机控制器的控制软件的设计实例说明基于QP的软件架构设计过程和实际运行结果。

3.1 基于QP的航天相机控制器的软件设计

基于QP 平台的软件设计过程完全采用UML 的图形可视化方法。使用用例图分析软件任务、需求。使用类图描述软件架构。使用活动图或顺序图描述软件结构中的对象间的消息交换细节。使用顺序图与状态图描述软件系统对象间的行为转换。如图2中描述了航天相机控制器软件总体架构的状态转换图。

其中分为4个状态，正常工作时系统在程控模式和正常模式间转换，触发信号为程控结束和E5.4 信号。

在正常模式内部又有工况参数轮询和摄像2种模式，通过相应的触发信号系统在两种状态间转换。另外E5.1.1到E5.1.7信号为内部转换触发信号。

3.2 软件源程序的生成

在QP中有关状态机的所有的要素，如状态、层次状态、状态转换、输入事件触发和输出事件触发均可以对应为固定的源代码，在将活动对象转化为源代码时几乎无需编程人员的参与。例如，对于状态机中的状态，QP中使用带有事件参数指针的函数来表示，其返回值指向另一个QP状态。对于信号的传递采用指针消息队列来表示。

3.3 控制器软件的测试结果

由于使用了QS动态调试手段，所以可以在最为接近全速运行的状态下收集软件运行信息。如图3所示控制器采集模拟量工况参数场景的实测各个触发事件发生的时间信息，时间刻度为1 μs.

如图3中所示模拟量遥测任务在t1时刻执行，采集系统内的模拟量参数。采集完成后在t2时刻向系统“发布”数据信号量。在t4时刻“订阅”了数据信号的数据合成任务得以执行。在数据合成任务以某种方式对数据打包编码后，在t5 时刻向系统“发布”打包后的数据消息。最后通讯任务在t6时刻，将打包数据通过数据链路输出。对于模拟遥测任务，t1 为任务执行的起始时刻，t3 为任务结束时刻，任务执行时间可由下面表达式(1)来描述。

根据上面的测量方法可以统计一个软件运行周期内所有任务的执行时间，下表是本相机控制器软件在2 s的运行周期内，常规工况下，所有任务执行时间的统计结果。

通过上表可见，QP 平台完成了软件中各个任务的管理工作，但是QP 平台对于系统资源的占用时间极少。另外采用速率单调调度[1](RMS)算法可以看到本应用软件是完全可调度系统。通过上面讲述的工作后，证明整个系统已经能够正常运行，移植成功。

4 结论

综上，QP下的程序设计完全是基于可视化的UML状态图方式，因此提高了程序设计的效率，缩短了设计周期，并且减少了不确定的、无法预测的状态从而加强了软件的安全性;QP 的实现原理有别于传统的RTOS,因此QP具有紧凑的代码结构，代码量小，QP的代码量非常少，即使是在所有的功能都被使能的情况下也只有4 K左右[1],更适合于深度的嵌入式系统。

因此，在完成了QP 平台在TMS320LF2407 上的构建的同时也证明了基于实时UML状态机的应用软件是完全可以在中小型CPU上运行的。