一种嵌入式实时操作系统的性能测试平台的构建
王劲松孙文生
北京邮电大学电信工程学院，北京 (100876)
E-mail：urika.bupt@gmail
摘要：本文提出一种基于Thread-Metric测试套件和ARM平台的RTOS性能测试平台的构建方案。该测试平台实现原理比较简洁，能有效地测量实时操作系统的运行速度等实时特性。本文以针对μC /OS II的移植和配置为例，详细阐述了平台的搭建和配置过程。
关键词：Thread-Metric，ARM，嵌入式操作系统测试平台
1. 引言
RTOS的应用中，对于其评价可以从很多角度来进行[1]，如体系结构、API的丰富程度、网络支持、可靠性等。其中，实时性是RTOS评价的最重要的指标之一，实时性的优劣是用户选择操作系统的一个重要参考。评价一个操作系统的实时性应该着重考察它的哪些指标，以及如何进行测试，是本文着重讨论的问题。
本文提出了使用Thread-Metric测试套件在ARM电路板上搭建测试平台的一种方案[2] [3]。该方案没有采用昂贵的硬件设备，成本不高，能相对有效地衡量不同操作系统技术之间的相对性能。
2.  RTOS简介
Thread-Metric是一个开源且免费的测试套件，同时Thread-Metric还提供了ThreadX的测试结果供使用者进行比较参考。ThreadX本身是一个非常优秀的商业化实时内核，在行业里有着许多非常成功的应用，通过与ThreadX测试结果的比较，我们可以对自己所测试的RTOS有个更加直观的了解。
2.1 Thread-Metric的测试原理
整个Thread-Metric测试套件由几个独立的测试项目组成，每个项目分别用于测试实时内核中的某一基本功能（如任务切换、中断处理、信号量处理等等）。测试的基本原理是通过计算一定周期时间长度里内核反复处理某一事务的次数，并将结果通过“printf”函数输出给PC终端获取。
Thread-Metric中的第一个测试项目为“基准测试（Basic Processing Test）”，该测试用于获取一个称之为“校准值（Calibration）”的数据，校准值的大小反映的是测试中所使用的硬件平台的能力，它的引入是为了屏蔽硬件平台对测试结果的影响，因为我们所需要评估的是RTOS的性能，而并非整个系统的性能。
除第一个测试项目（基准测试）外，在其它测试项目中，我们将会获取到一个称之为“迭代值（Iteration）”数据，迭代值的就是在一个测试周期长度里内核所处理的这一事务的次数，于是我们使用公式：
得分 = 迭代值÷校准值
即可得到实时内核在这一测试项目的得分。
2.2 Thread-Metric的文件结构
Thread-Metric测试套件全部由C语言编写，因此它适用于绝大部分实时内核，使用Thread-Metric也需要一个移植过程，不过Thread-Metric的移植非常简单，其移植过程只是一些API的重映射操作。Thread-Metric测试套件的源文件的组成如表1所示：文件“tm_porting_layer_threadx.c”是Thread-Metric提供的一个已经完成的基于ThreadX 的移植文件，它只是用来帮助我们快速的将Thread-Metric移植到其它实时内核，在我们实际利用Thread-Metric测试其它RTOS时，它是不需要使用的。
表1  Thread-Metric中的文件
Tab.1 List of each file in the Thread-Metric Suit
文件名功能描述
tm_api.h API声明和宏定义常量
tm_basic_processing_test.c 基准测试
tm_cooperative_scheduling_test.c 协同式的任务调度测试
tm_preemptive_scheduling_test.c 抢占式的任务调度测试
tm_interrupt_processing_test.c 中断处理测试
tm_interrupt_preemption_processing_test.c 中断当中的任务抢占处理测试
tm_synchronization_processing_test.c  任务同步处理测试
tm_message_processing_test.c 消息处理测试
tm_memory_allocation_test.c 内存分配测试
tm_porting_layer.c Thread-Metric移植相关文件
tm_porting_layer_threadx.c Thread-Metric移植于ThreadX内核的参考实例
2.3 Thread-Metric的使用要求
在使用Thread-Metric测试套件时，为了得到一个客观公正的测试结果，我们应当遵循Thread-Metric建议的几点要求，
一、测试周期长度应至少大于30秒。越大的测试周期长度越有利于消除调用“printf”函数输出测试结果时对于测试结果本身的影响；
二、关闭所有编译器优化选项，不允许将代码缓存在处理器的任何高速Cache中运行；
三、在移植Thread-Metric的过程中，API的重映射不能采用宏定义的方式；
四、内核的时钟节拍周期应设置为10毫秒；
3. Thread-Metric中的测试项目
当前版本的Thread-Metric总共包含8个测试项目，这些测试项目基本覆盖了实时操作系统最重要的核心功能[4]。
测试1：基准测试（Basic Processing Test）
模拟串口使用printf函数
测试1的主要目的就是获取硬件平台的性能校准值，校准值越大说明硬件平台的性能越强。在这个测试中将只创建一个运行任务。
测试2：协同式的任务调度测试（Cooperative Scheduling Test）
该测试中包含5个相同优先级的任务，各个任务在在执行过程中会先将自己的计数器加1，然后通过调有“relinquish”函数主动将CPU使用权交给下一个任务。图1是测试2的运行示意图：
图1  协同式的任务调度测试
测试3：抢占式的任务调度测试（Preemptive Scheduling Test）
该测试中包含5个由高到低不同优先级的任务，各个任务在执行过程中会将自己的计数器加1。在测试开始时，只有优先级最低的任务处于就绪，其它任务都被挂起。优先级最低的任务先唤醒优先级次低的任务被抢占，这样依次抢占下去后，最高优先级的任务获的CPU 使用权后又将自己挂起，次高优先级的任务也将自己挂起，到最后优先级最低任务又获得CPU使用权，一个新的循环又开始。图2是测试3的运行示意图：
图2  抢占式的任务调度测试
测试4：中断处理测试（Interrupt Processing Test）
该测试中只包含1个任务，该任务通过调用软中断（SWI）指令的方式来连续模拟中断的发生，中断服务程序会释放一个信号量，中断返回后，任务去获取该信号量。获取成功后再次调用软中断。图4-3是测试
4的运行示意图：
图3  中断处理测试
测试5：中断当中的任务抢占处理测试（Interrupt Preemption Processing Test）
该测试中包含2个优先级不同的任务，低优先级的任务通过调用软中断（SWI）指令的方式来模拟中断，中断服务程序中另外一个高优先级的任务被唤醒，中断返回时发生任务抢占。图4是测试5的运行示意图：
图4  中断当中的任务抢占处理测试
测试6：消息处理测试（Message Processing Test）
该测试包含1个任务，任务先想邮箱中发送一条消息，然后紧接着又再去邮箱中获取，并将获取的消息与发送的做对比，图5是测试6的运行示意图：
图5  消息处理测试
测试7：任务同步处理测试（Synchronization Processing Test）
该测试包含1个任务，任务通过不断获取和释放信号量的操作来模拟信号量的任务同步功能，图6是测试7的运行示意图：
图6  任务同步处理测试
测试8：内存分配测试（Memory Allocation Test）
该测试包含1个任务，任务通过不断获取和释放一个内存块来的测试内核的内存管理功能。图7是测试8的运行示意图：
图7  内存分配测试
4. 测试步骤与方法
在开始使用Thread-Metric进行测试之前，以下几个预备条件应当确保已经满足：
欲测试的实时内核已经成功移植到某硬件平台
硬件平台的核心处理器支持软中断功能
ARM处理器具有专门的软中断指令(SWI指令) [2][3]
欲测试的实时内核具有将任务延迟特定时间长度的能力
μC /OS II具有任务延迟API（函数slp_tsk()）
系统可以使用“printf”函数将测试结果输出
printf函数的输出在ARM7TDMI评估板上可以串口输出到PC终端
4.1 如何移植Thread-Metric
Thread-Metric的移植非常简单，其移植过程就是将文件“tm_porting_layer.c”中已经定义好的API进行重影射，对于μC /OS II来说，其映射关系如下：
(1) int  tm_thread_create()
Thread-Metric使用此API创建一个任务，使用μC /OS II的OSTaskCreate()进行映射。
(2) int  tm_thread_resume()
Thread-Metric使用此API恢复一个任务，使用μC /OS II的OSTaskResume()进行映射。
(3) int  tm_thread_suspend()
Thread-Metric使用此API挂起一个任务，使用μC /OS II的OSTaskSuspend()进行映射。
(4) void  tm_thread_relinquish()
Thread-Metric使用此API让任务主动交出CPU使用权给同优先级的其它任务，μC /OS II不支持同优先级调度，所以没有对应的函数与之映射。
(5) void  tm_thread_sleep()
Thread-Metric使用此API让任务延迟，使用μC /OS II的OSTimeDly()进行映射。
(6) int  tm_queue_create()
Thread-Metric使用此API创建消息队列，使用μC /OS II的OSQCreate()进行映射。
(7) int  tm_queue_send()
Thread-Metric使用此API发送消息，使用μC /OS II的OSQPost()进行映射。
(8) int  tm_queue_receive()
Thread-Metric使用此API接收消息，使用μC /OS II的OSQAccept()进行映射。
(9) int  tm_semaphore_create()
Thread-Metric使用此API创建信号量，使用μC /OS II的OSSemCreate()进行映射
(10) int  tm_semaphore_get()
Thread-Metric使用此API获取信号量，使用μC /OS II的OSSemPend()进行映射
(11) int  tm_semaphore_put()
Thread-Metric使用此API释放信号量，使用μC /OS II的OSSemPost()进行映射
此外，Thread-Metric中还有几个与内存管理相关的API，由于μC /OS II没有相关功能，在这里我们无需对相关API进行映射。
将测试套件和操作系统经过编译后，我们将最后需要测试的二进制系统文件下载到开发板上[5]，这样我们就搭建好了一个ARM平台下针对μC /OS II的测试平台。
5. 结论
对于嵌入式实时操作系统的研究是当前的研究热门。在针对性能的改进中，一个有效而相对简单的性能测试平台能大大提高工作效率。本文介绍的测试平台经过实践证明，能很好的满足对于一般性能测试的需求。由于该测试平台的主要是基于软件的，所以有着很好的扩展性，稍加修改即可针对操作系统的各项功能进行测试。
www.paper.edu
参考文献
[1] Jean J. Labrosse.嵌入式实时操作系统 uC/OS-II[M].第二版.邵贝贝等译. 北京：北京航空航天大学出版
社：112-128
[2] ARM Limited. ARM Architecture Reference Manual. Jun-2000
[3] ARM Limited. ARM7TDMI Technical Reference Manual. Apr-2001
[4] Express Logic, Inc., Thread-Metric RTOS Test Suite Guide, Apr-2004
[5] IAR Systems, ARM IAR Embedded Workbench IDE User Guide, Jun-2006
A Scheme of Light RTOS Performance Test Platform
Wang Jinsong, Sun Wensheng
(School of Telecommunication Engineering, Beijing University of Posts and
Telecommunications, Beijing 100876, China)
Abstract
A scheme of RTOS test platform, which is based Thread-Metric software suit and ARM architecture, is brought about. The test scheme is simple, and can effectively measure the real time performance such as context switch duration time. The paper also carefully discussed the configuration with the example of μC /OS II.
Keywords:  Thread-Metric，ARM，embedded RTOS test platform

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。