嵌入式实时操作系统性能测试方法研究
- 格式:docx
- 大小:171.64 KB
- 文档页数:7
摘要实时系统实现了对事件响应和处理的严格时间控制。
实时操作系统分为嵌入式和普通系统两种。
大部分的嵌入式系统也需要提供实时响应和控制能力。
虽然嵌入式实时系统与普通实时系统的规模,应用,性能及可靠性要求都不同,但是这两种实时操作系统都一般是基于微内核的和模块化的。
系统可以在最小规模下工作时,操作系统仅仅提供一些最基本的服务,大量的在一般系统中由操作系统完成的任务由作为应用运行的系统级任务完成。
为了测试实时系统的性能,我们设计了分别在实时环境(RTLinux)与非实时环境(普通Linux)下运行的两个程序,通过他们之间任务执行时间的比较,达到我们测试的目的。
本论文详细阐述了作者在实时环境下的测试,以及与非实时环境下测试的比较。
首先,简要的介绍了Linux操作系统,嵌入式操作系统,实时系统以及嵌入式实时系统,这些都是一些相关的信息。
其中,对于实时系统(RTOS),我们给出了比较详细的介绍,包括实时系统的定义,分类,结构以及衡量指标等。
然后,详细的说明了实时Linux系统---RTLinux,阐述了RTLinux的实现机理,特点,应用等。
RTLinux编程是本论文的另一个重点,我们的设计使用的就是RTLinux的API接口。
RTLinux编程主要涉及的方面包括模块,线程及其调度,FIFO,中断以及串口API。
接下来,是本设计的实现与分析,通过对总体模块以及程序各个模块的分析,解释出总体设计思路,以及一些具体的设计方法,然后是实时与非实时系统测出的数据的比较,实现我们设计的初衷---测试实时系统的性能。
最后,在已完成工作的基础上,对设计进行了总结。
ABSTRACTReal-time system implements the rigid time requirements of task response and handling.Real-time system can be devide into embedded and ordinary system. Most of the embedded system also require the ability of real-time response and control. Although embedded and ordinary real-time systems have so many differences in size, application, performance and credibility etc.This two systems are both based on micro kernel and modulity. The system can work with minimal resources. The operating system only provides some basic services. Most of the services, that is provided by operating system in ordinary systems, are implemented as system application task.In ordre to test the performance of read-time system, we designed two progammes which are respectively run in the enviroment of real-time and non real-tiem. Through the comparision of the execution time, we can get the result we want, that is real-time system implements the rigid time requirements.This thesis elaborates the test in real-time enviroment and the comparision between real-time and non real-time systems. First, I introduce Linux operating system, embedded operating system, real-time system and embedded real-time system. These are all something related to my designation. Among them, I describe the real-time system (RTOS) in detail, including definition, classification, configuration and judging standard. Then, wo elaborated a real-tiem Linux system---RTLinux, includnig implementing methods, characristics, application and so on. RTLinux programming is another focas points of this thesis. I use RTLinux API interfaces to build up my progarmmes. RTLinux programming involves modules, thread and its scheduling, FIFO, interrupts, and serial port API. After that, it is the implementation and analysis of my design. Through the analysis of the overall modules and every modules, I explain my designing mechanism and the concrete designing methods. Then we get the data that is execution time in both real-time and non real-time systems. Via comparision, we can test the performance of the real-time systems. At last, based on the work that I have done, I reach my conclusion.第一章绪论51.1 Linux操作系统·································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································································51.2 嵌入式操作系统61.2.1 嵌入式系统的定义61.2.2 嵌入式系统的发展61.2.3 嵌入式系统的特点71.3 实时系统(RTOS)71.3.1 实时系统的定义71.3.2 实时系统的分类81.3.3 RTOS的结构91.3.4 RTOS的基本功能91.3.5 实时系统的设计问题91.3.6 RTOS的衡量指标111.4 嵌入式实时Linux系统12第二章实时Linux系统---RTLinux 132.1 RTLinux简介132.2 RTLinux的实现132.3 RTLinux的特点162.4 RTLlinux的应用172.5 RTLinux 应用编程接口(API)182.6 RTLinux的调度策略18第三章 RTLinux编程介绍193.1 简介193.2 程序基本结构203.3RTLinux时钟203.4 实时Linux POSIX线程及调度223.5 使用实时FIFOs253.6 内存共享263.7 中断273.8 浮点运算293.9 RT_COM 串口驱动程序293.9.1 安装293.9.2 接口函数303.9.3 模块装载与卸载313.9.4 数据结构313.9.5 RT_COM模块分析33第四章程序实现354.1 概述354.2 实现方法阐述354.3 总体代码分析364.3.1 程序总体流程图364.3.2 文件介绍374.3.3 公用常量与数据结构384.4 各模块代码分析404.4.1 服务器端( Server )··························································································································································································································································································································404.4.2 客户端 ( Client )434.4.3 rtopenf模块454.5 数据分析46第五章总结与展望47参考文献49致谢错误!未定义书签。
嵌入式报告实验报告1. 引言嵌入式系统作为一种特殊的计算机系统,应用广泛且日益重要。
嵌入式报告实验是对嵌入式系统进行实际操作和测试的过程,旨在验证嵌入式系统的功能和性能,以评估其是否满足设计要求。
本报告将详细介绍嵌入式报告实验的设计与实施,并对实验结果进行分析与总结。
2. 实验设计2.1 实验目的嵌入式报告实验的目的是通过设计和实施一系列测试来评估嵌入式系统的性能和功能。
具体目标包括但不限于:验证系统的实时性、稳定性和可靠性;测试系统的各种输入输出功能;评估系统对异常情况的处理能力。
2.2 实验环境实验使用的嵌入式系统硬件为XX处理器,集成了XX模块和XX接口。
软件方面,使用XX嵌入式操作系统和XX开发工具进行系统开发和测试。
2.3 实验步骤1) 配置硬件环境:将嵌入式系统与外部设备连接,确保硬件环境正常。
2) 编写测试程序:根据实验目标,编写相应的测试程序,包括输入输出测试、性能测试和异常情况测试等。
3) 软件调试:通过软件调试工具对测试程序进行调试,确保程序逻辑正确。
4) 硬件调试:通过硬件调试工具对嵌入式系统进行调试,确保硬件模块正常工作。
5) 实验运行:将测试程序下载到嵌入式系统中,运行测试程序并记录实验数据。
6) 数据分析与总结:对实验数据进行分析和总结,评估嵌入式系统的性能和功能是否满足设计要求。
3. 实验结果与分析3.1 输入输出测试通过设计一系列输入输出测试用例,测试嵌入式系统的输入输出功能。
测试包括但不限于:按键输入、传感器数据采集、外部设备通信等。
实验结果表明,嵌入式系统的输入输出功能正常,能够准确获取和处理各种输入信号,并成功输出相应的结果。
3.2 性能测试通过设计一系列性能测试用例,测试嵌入式系统的处理能力和实时性。
测试包括但不限于:任务切换速度、响应时间、系统负载等。
实验结果表明,嵌入式系统具有较高的处理能力和实时性,能够快速响应各种任务并保持系统的稳定性。
3.3 异常情况测试通过设计一系列异常情况测试用例,测试嵌入式系统对异常情况的处理能力。
如何做好嵌入式软件开发测试嵌入式软件测试是确保嵌入式系统的稳定性和可靠性的关键步骤之一、嵌入式软件的特点是运行在嵌入式系统中,并受到硬件限制、资源限制以及实时性要求的约束。
因此,嵌入式软件测试需要特别的关注点和方法。
下面是一些关键的步骤和技巧,以保证嵌入式软件开发测试的质量。
1.理解需求和软件架构:在进行嵌入式软件测试之前,必须对软件系统的需求和架构有充分的理解。
这将有助于测试人员了解系统的功能和性能要求,从而制定相应的测试策略和计划。
2.制定详细的测试计划:测试计划是一个指导测试活动的重要文档。
它应该明确规定测试的范围、目标、方法、资源和时间等方面的内容。
测试计划还应该包括测试的策略、用例和检查点等详细信息。
3.设计和制定测试用例:测试用例是测试的基本单元,用于验证系统的各种功能和性能。
在嵌入式软件测试中,测试用例的设计和制定可能会受到资源和实时性要求的限制。
因此,测试人员应该注意测试用例的覆盖率和效率,以确保尽可能多地测试到系统中的错误。
4.搭建适当的测试环境:在进行嵌入式软件测试之前,必须搭建适当的测试环境。
这包括硬件、软件、工具和数据等方面的准备。
嵌入式系统的测试环境应尽可能接近实际使用环境,以确保测试结果的准确性和可靠性。
5.进行功能测试:功能测试是嵌入式软件测试的核心。
它涉及对软件的各种功能进行验证和确认,以确保其满足需求和规范。
功能测试应包括正常情况下的功能测试和异常情况下的功能测试,以确保软件在各种情况下都能正常工作。
6.进行性能测试:性能测试是确定系统响应时间、吞吐量和资源利用率等方面的测试。
在嵌入式软件测试中,性能测试可能针对处理速度、内存占用和能耗等方面进行。
性能测试应尽可能接近实际使用情况,以确保软件在实际运行时能够满足性能要求。
7.进行安全测试:安全测试是确保嵌入式系统的安全性和可靠性的关键测试。
在进行安全测试时,测试人员应注意系统的漏洞和错误,以及可能的攻击和破坏方式。
嵌入式系统硬件测试的最佳实践嵌入式系统硬件测试是确保嵌入式设备能够正常运行和达到预期功能的重要环节。
在批量生产和使用前,经过全面的硬件测试可以大大降低故障率和提高产品质量。
本文将介绍一些嵌入式系统硬件测试的最佳实践,并探讨如何增强测试效果和提高测试效率。
一、测试需求分析在进行硬件测试之前,我们需要进行测试需求分析。
这一阶段的目标是明确测试的目标和范围,并制定相应的测试计划。
测试需求分析包括以下几个方面:1. 功能需求:明确系统的功能需求,确保测试能完整覆盖所有功能点。
2. 性能需求:确定系统的性能要求,例如响应时间、吞吐量等指标,以此来设计相应的性能测试用例。
3. 可靠性需求:定义系统的可靠性要求,确定测试的目标和相关指标。
4. 安全需求:针对嵌入式系统的安全性要求和漏洞进行测试,以确保系统的安全性。
测试需求分析的好处是能够更好地理解系统的功能和性能,有针对性地进行测试计划的制定,为后续的测试工作奠定基础。
二、测试环境搭建在进行嵌入式系统硬件测试之前,需要搭建相应的测试环境。
测试环境需要满足以下要求:1. 硬件设备:根据测试需求配置相应的硬件设备,包括嵌入式开发板、传感器、外设等。
2. 测试工具:选择合适的测试工具,例如示波器、逻辑分析仪、频谱仪等,用于监测和分析系统的信号和电气特性。
3. 软件工具:选用合适的软件测试工具,例如测试自动化工具、性能测试工具等,以提高测试效率和准确性。
4. 测试台架:根据测试需求设计和制作相应的测试台架,以方便测试人员进行测试操作。
三、测试用例设计在进行嵌入式系统硬件测试时,测试用例设计非常重要。
测试用例设计需要满足以下几个原则:1. 全面性:测试用例应该覆盖系统的各个功能点和场景,以确保所有功能都能够被测试到。
2. 精确性:测试用例应该具有针对性和特定性,能够准确地测试系统的某个功能或性能指标。
3. 可复用性:测试用例应该能够被多次使用,以节省测试资源和提高测试效率。
1、前言跟着经济的发展和科技的进步 ,信息技术的发展令人类进入数字时代 ,而陪伴着计算机技术发展起来的嵌入式技术获取了巨大的发展 ,改变了人们的平时。
跟着对嵌入式产品对各方面的要求愈来愈高 ,对嵌入式产品的性能有着决定性影响的嵌入式软件的测试显得尤其重要。
嵌入式的目的是保证软件知足需求规格说明 ,与非嵌入式软件的测试目的是同样的。
系统无效是系统没有知足—个或多个正式需求规范中所要求的需求项 , 嵌入式软件有其特别的无效判断准则。
并且嵌入式软件对靠谱性的要求比较高。
安全性的缺点常常会致使灾害性的结果 ,即便是非安全性系统 ,因为大量量生产也会致使严重的经济损失。
这就要求对嵌入式系统 ,包含嵌入式软件、嵌入式硬件进行严格的测试、确认和考证。
一般来说 ,软件测试有 7 个基本阶段 ,即单元或模块测试、集成测试、外面、回归测试、统测试、查收测试、安装测试。
嵌入式软件测试在 4 个阶段长进行 , 即模块测试、集成测试、系统测试、硬件 / 软件集成测试。
前 3 个阶段合用于任何软件的测试 ,硬件 / 软件集成测试阶段是嵌入式软件所独有的 ,目的是考证嵌入式软件与其所控制的硬件设施可否正确地交互。
2、嵌入式软件测试环境嵌入式软件测试的测试环境主要有两种:1 目标环境测试 :鉴于目标的测试测试全面有效,可是耗费许多的经费和时间。
2 宿主环境测试 :鉴于宿主的测试代价较小 ,可是有些对环境要求高的功能和性能宿主机没法模拟 ,测试没法实现。
当前的趋向是把更多的测试转移到宿主环境中进行,把宿主环境测试没法实现的复杂和独到功能放在目标环境测试。
我们的要点是鉴于宿主环境的测试 ,鉴于目标环境的测试作为增补。
文档在两个环境中能够出现不一样的软件缺点 ,重要的是目标环境和宿主环境的测试内容有所选择。
在宿主环境中 ,能够进行逻辑或界面的测试、以及与硬件没关的测试。
在模拟或宿主环境中的测试耗费时间往常相对较少 ,用调试工具能够更快地达成调试和测试任务。
嵌入式实时操作系统性能测试方法研究 发布时间: 2009-7-08 16:22 作者: 未知 来源: 网络转载 字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签: 嵌入式系统 性能测试 软件测试技术
引 言 随着计算机技术的迅速发展和芯片制造工艺的不断进步,ERTOS的研究和应用日益广泛,从民用的手机、电子书等手持移动设备到航空航天、医学设备、工业控制等各个领域都有它的身影。然而,在设计和选择ERTOS时,如何确定其是否能够满足所需的应用成为一个棘手的问题,必须用一种有效的方法对它们的各个方面进行对比测试,以选择符合要求的系统。本文首先分析三种常用的系统实时性能测试方法,接着介绍一套测试实验平台,对于ERTOS的测试和分析有一定的指导意义。
1 Rheaostone方法 Rhealstone方法对ERTOS中六个关键操作的时间量进行测量,并将它们的加权和称为Rhealstone数。这六个时间量如下:
◆任务切换时间(task switching time),也称上下文切换时间,定义为系统在两个独立的、处于就绪态并具有相同优先级的任务之间切换所需要的时间。它包括三个部分,即保存当前任务上下文的时间、调度程序选中新任务的时间和恢复新任务上下文的时间。切换所需的时间主要取决于保存任务上下文所用的数据结构以及操作系统采用的调度算法的效率。
◆抢占时间(preemption time),即系统将控制从低优先级的任务转移到高优先级任务所花费的时间。为了对任务进行抢占,系统必须首先识别引起高优先级任务就绪的事件,比较两个任务的优先级,最后进行任务的切换,所以抢占时间中包括了任务切换时间。
◆中断延迟时间(interrupt latency time),指从中断第一条指令所持续的时间间隔.它由四部分组成,即硬件延迟部分(通常可以忽略不计)、ERTOS的关中断时间、处理器完成当前指令的时间以及中断响应周期的时间。
◆信号量混洗时间(semaphore shuffling time),指从一个任务释放信号量到另一个等待该信号量的任务被激活的时间延迟。在ERTOS中,通常有许多任务同时竞争某一共享资源,基于信号量的互斥访问保证了任一时刻只有一个任务能够访问公共资源。信号量混洗时间反映了与互斥有关的时间开销,因此也是衡量ERTOS实时性能的一个重要指标。 ◆死锁解除时间(deadlock breaking time),即系统解开处于死锁状态的多个任务所需花费的时间。死锁解除时间反映了RTOS解决死锁的算法的效率。
◆数据包吞吐率(datagram throuShput time),指一个任务通过调用ERTOS的原语,把数据传送到另一个任务去时,每秒可以传送的字节数。
2 进程分派延迟时间法 进程分派延迟时间PDLT(Process Dispatcb LatencyTime)是另一个常用的测量ERTOS性能的方法。在实时系统中,实时任务总是等待外部事件引发的中断来激活它。当一个中断产生后,系统必须迅速停止当前运行的低优先级任务,将控制权交给被激活的实时任务。PDLT定义为从中断的产生到由中断激活的实时任务开始执行之间的时间间隔。这段间隔由几个部分组成,如图1所示。
不同操作系统中,PDLT差异的主要部分是内核延迟部分。目前绝大多数ERTOS为了减少内核延迟,采用可抢占式的内核,有效地提高了系统对外部事件的响应速度。
3 三维表示法 有人将实时系统定义为能够从外部进程获取输入,处理所获得的数据,并能在足够快的时间内将正确的响应返回给外部进程的系统。由这个定义,可以将ER丁OS的工作分为三个阶段:
◆响应传感器或者其他输入设备的请求,并获取数据; ◆对获得的数据进行处理(主要由应用程序进行处理); ◆输出处理结果。 相应地,ERTOS的性能可以用对应的三个特性来描述: ◆CPU的计算能力,其度量单位为MIPSl(Millions of Instructions Per Second); ◆中断处理能力,其度量单位为MIPS2(Millions of Interrupts Per Second); ◆I/O吞吐率,其度量单位为MIPS3(Millions of I/O Per Second)。 上述三个特性的最大值可分别单独测得,但这三个特性之间并不是相互独立的。为了直观地表现ERTOS的实时性能,可以用一个三维的图形来表达三个特性之间的依赖关系,如图2所示。
图2中用曲面来表现ER70S三个特性之间的依赖关系。如果随着一个特性的增加,另外两个特性下降的速度比较缓慢,可以认为该曲面所表现的系统是ERTOS;反之,如果随着一个特性的增加,另外两个特性下降的速度超过了一定的范围,就可以认为该系统非ERTOS,如图2中的阴影部分所示。
4 系统实时性能测试实验平台 为了对RTOS的实时性能进行测试,我们设计并实现了一套测试实验平台。实验平台由两块开发板(被测系统)构成,便于对不同的ERTOS进行对比。由于实验平台的主要设计目标是对相同硬件架构下的不同操作系统及操作系统的不同层次进行比较,所以两块开发板均采用了研华的PCM 7230。其主要硬件特性如下:
CPU:Intel Xscale PXA255 400MHz SDRAM:64 MB LCD:10.4” I/O接口:CompactFlash、PCMCIA、RS232、RS485、 USB、Ethernet等。 实验平台的整体结构如图3所示。
4.1 实验平台功能 (1)实时性能测试 由于大多数ERTOS的内核是不可更改的,所以对其实时性能的测试主要在用户层实现。开发者可以将现有的用于测量Rhealstone性能指标和PDLT延迟时间的benchmark程序方便地移植到PCM 7230开发板与不同RTOS组合的平台上,也可以根据应用需要自己编写测试程序,对感兴趣的延迟时间进行测量。
除此之外,PCM7230开发板从CPU引脚上引出了一个120针的扩展接口AMI-120(ARM Module Interface)。将这120针引脚引出至实验平台上的两个测试端口1和2,可以通过示波器或逻辑分析仪对引脚上的信号进行分析;配合benchmark测试,可以得出更加精确和可信的测试结果。另外,对引脚中的部分控制信号通过CPLD单独引出至一个测试端口3,便于对不同的系统进行对比测试。
(2)负荷发生 由三维表示法得知,ERTOS的实时性能可以用三个特性来表示。相应地,实验平台可以产生三种类型的负荷;计算负荷(CPU负荷)、I/O负荷以及中断负荷。
计算负荷由I/hrystone或Whetstone改编的进程实现,每秒钟消耗一定的MIPS数。 I/0负荷由系统时钟控制,通过PCM 7230开发板上丰富的I/O接口产生流量。另外,通过配置不同的I/O接口,还可以测试不同存储介质对ERTOS性能的影响。
中断负荷的产生可以用CPLD进行控制.通过DIP开关设置中断发生的频率,在CPLD中实现一个分频器用于产生中断信号,并将中断信号通过AMI-120接口中的GPIO引脚传送给CPU。
在进行ERTOS实时性能的测试时,这三类负荷可以模拟应用的真实环境。另外,通过指定三种负荷的变化,可以获得它们在三维图中的一系列坐标点,由此也可以绘制ERTOS的三维表示曲面。
此外,由于CPLD为可编程器件,方便对其再编程以重新定义与其相连的各种器件的功能,使得测试平台有很大的灵活性和扩展性。
4.2 计时方法 评价ERTOS实时性能的具体指标多数是用延迟时间来表示的,比如Rhealstone方法中的前五个指标和PDLT方法。可以将这些对时间的测量过程简化为图4所示的流程。 图4中对t1、t2的计时可以用以下三种方法实现。 (1)系统调用 ERTOS一般有用于计时的系统调用,例如RTLlnux的系统调用gettimeofday(),其精度可以达到μs级,可以满足多数延迟时间的计时。但是,由于系统调用时有一个压栈、出栈的过程,以及从用户空间到系统空间的转换,这个过程对计时会产生一定的影响。
(2)OS时钟寄存器 PXA 255处理器内包含一个32位的OS时钟寄存器,由一个3.6864 MHz的晶振驱动。可以在计时开始和结束时分别读取该寄存器的值,换算出对应的延迟时间。
(3)GPIO引脚 AMI-120接口上有许多GPIO引脚,可以考虑在计时往一个空闲的GPIO引脚上写一个特定的信号,利用CPLD中实现的计数器对两个信号间的时间间隔进行计数。驱动CPLD的时钟是可以更换的,其最大允许频率为200 MHz。这样,考虑到CPLD的引脚间延迟,用这种方法计时的精度可以达到数+ns。
5 ERTOS对比测试 操作系统是数字系统中进行资源管理的软件。狭义的操作系统只包括进行进程管理、内存管理、中断管理等基本功能的内核部分;而广义上讲,操作系统除了内核外,还包括GUI、API、大量的驱动程序,甚至一些应用程序也可以认为是操作系统的一部分。现代操作系统在其内部提供了丰富的功能模块,而嵌入式操作系统的一个显著的特点就是,可以根据需要对这些功能模块进行裁剪。典型的ERTOS层次结构如图5所示。
操作系统提供的功能模块一方面扩展了系统的功能,方便了用户的使用;另一方面,又在一定程度上会影响系统的性能。ERTOS在对系统的功能进行选择和剪裁时,就需要在功能和性能之间选择一个折中点,使得系统能够提供尽可能多的功能,同时又能满足其实时性的需要。这就要求在进行系统的设计、选择或者裁剪时,对操作系统增减或替换不同模块时的性能进行对比分析。
利用上文中的测试实验平台,可以在两块开发板上分别配置有/无某个功能模块的系统,将测试方法分别应用于两个系统上。由于被测的系统采用的是相同的硬件架构,消除了硬件对系统性能的影响。对得到的测量结果进行对比分析,就可以比较精确和客观地得出该功能模块对整个系统性能影响的大小。
同样,该实验平台也可以用于测试分析不同ERTOS系统的性能。 6 总 结 本文对三种ERTOS性能测试方法进行了研究,对一些指标和特性进行了分析。文章的后半部分给出了一个测试实验平台的结构及其功能说明,并针对实验平台给出了系统计时的三种方法。文中提供的测试方法和手段对ERTOS的选择和开发有一定的参考价值。