bernard
bernard

注册于 13 years ago

回答
131
文章
3
关注者
26

2、比对平台及测试方法

2.1 比对测试平台介绍
  
为了更好地对嵌入式系统中各层次的软件系统(包括操作系统、Bootloader、用户应用程序以及其他系统程序)进行评测,我们设计并实现了双嵌入式系统比对实验平台。实验平台以2块研华PCM7230开发板(基于PXA255处理器)和1个CPLD器件为核心,开发板上运行被测操作系统,保证了测试环境的完全相同;CPLD器件负责产生中断负载、双系统的同步置位复位触发与计时功能,保证了测试结果的精确,并且易于比对、观察,突出评测过程比对的特点。图4是比对测试平台的逻辑结构。
figure_4.JPG
下面列出的是比对平台中主要的硬件型号与种类。
  
◇ CPU:XScale (400 Hz)。
◇ 时钟:HT1381。
◇ ROM:1 MB AMD。
◇ SDRAM:64 MB。
◇ Flash:32 MB。
◇ IO资源: 包含RS232(COM1~4),RS485(COM5),2个USB Host和1个USB Client,Ethernet DM9000.10100 basedT,以及AMI120扩展总线接口。

2.2 测试与计时方法
  
在测试过程中,采用当前比较流行的基准测试程序法(benchmark)对上述实时性指标进行评测。针对每一指标,编写相应的测试程序。在测试过程中,一个最基本原则是尽可能地减小测量误差,采用多种策略减小其他因素对测试的影响,例如关闭内核中部分不需要的进程,以缩短内核占用CPU时间;禁用数据 Cache和指令Cache,以避免高速缓存对RTOS相应指标的影响;对同一指标进行高频度重复测试,统计其最大值、最小值和平均值等,得到尽可能客观的结果。
  
与通常的基准测试方法相比较,本测试方法的特点是采用CPLD器件与测试程序相结合的方法,利用CPLD与开发板上丰富的引脚资源,通过CPLD进行编程,可方便地对被测试系统产生中断负载、同步触发,而且不会增加被测系统的额外负载。同时,减少系统调用的次数,使测试结果更加精确,更接近内核自身的运行值。
  
另外,测试过程的计时功能通过CPLD编程实现,与传统的利用RTOS内核的时间系统调用计时方式相比,解决了不同操作系统系统调用返回值精度不够、单位不统一的问题。由于比对平台中的CPLD器件选用的是Xilinx公司的XC9500系列,其最高系统时钟频率为100 MHz,引脚到引脚的最大时延为10 ns,因此实现的计数器计时精度可以达到数十ns,几乎可以忽略不计,极大提高了计时精度,如图5所示。
figure_5.JPG
整个测试过程主要分为4部分:准备工作,内核测试程序编程,CPLD编程,与外界交互部分的实现。准备工作包括编译内核、修改Bootloader 等,Bootloader通过对i?boot?lite?1.8进行修改,使其可应用于比对平台上;内核测试程序按照前面所提到的6个指标,划分为6个模块,分别编写;CPLD编程主要包括计时程序、中断负载加载程序等;外界交互部分主要包括串口通信、以太网卡驱动。下面是部分CPLD上的VHDL程序源码。其中,fenpin为时钟频率,flagreci为接收信号;当使用按键人工控制时,flagsend和flagstop为计时开始和结束。


process(fenpin,flagsend,flagreci,flagstop)
begin
flag=flagsend & flagreci & flagstop;
if(fenpin′ event and fenpin='1') then
if(flag=0010000) then
if(tempsendout=0000000000000111) then
tempsendout=tempsendout;
else
tempsendout=tempsendout+'1';
end if;
countout=countout+'1';
if(tempsendout=0000000000000111) then
outsend='0';
outsendled='0';
iscounting='1';
else
outsend='1';
outsendled='1';
end if;
else
iscounting='0';
signdisp='1';
end if;
end if;
end process;


测试程序的代码较多,这里不一一列出,仅给出程序中嵌入的与CPLD交互的部分代码片段供参考。


#define base_add ((volatile unsigned )0x40E00000)
#define gpio3_derect ((volatile unsigned )(0x40E00000+0x0C))
#define gpio3_out1 ((volatile unsigned )(0x40E00000+0x18))
int to_CPLD(void) {
gpio3_derect = 0x8;设置引脚为输出
gpio3_out1 = 0x8;输出一个高电平
}


代码的前段定义了相关寄存器的地址,在测试过程中,使用PXA255的GPIO3引脚与CPLD交互,实现计时功能。由于需要在内核态运行,故该函数作为一个模块编译进内核,测试程序中通过ioctl系统调用执行此段代码,将信号发送给CPLD,CPLD计算2次信号的间隔时间,实现计时功能。

3、Linux、WinCE的测试结果及分析
  
根据上述指标体系及测试方法,我们对Linux和WinCE进行了相关的测试。其中,Linux版本为2.4.19,WinCE版本为 WinCE.Net。由于当硬件平台与运行环境不同时,即使同一内核运行时体现的性能指标也会不同,所以对不同RTOS的评测只有在相同平台环境下进行比对才有其价值,测试以评价为目标,评价以比对为依据。表1是对上述两种内核的评测结果。由于篇幅所限,这里只列出了平均时间,最大、最小值没有列出。
table_1.jpg
从表1中可以看出,在任务切换时间、线程切换时间、系统调用平均运行时间几项指标中,Linux2.4.19和WinCE.Net相差不大;但在任务抢占时间、信号量混洗时间、中断响应时间几项指标中,WinCE.Net明显优于Linux2.4.19。总的来说,WinCE.Net的实时性优于 Linux2.4.19。下面从两种操作系统的特点、内部实现机制等方面来解释说明上述测试结果。

Linux与WinCE均允许不同进程的优先级相同,这一点不同于μCOS等实时内核(μCOS中每个任务的优先级唯一),所以采用的调度算法都是抢占式和时间片轮转的混和式调度策略。因此,在同优先级的进程切换时,二者指标相差不大。

测试中使用的Linux2.4.19并非是为嵌入式实时系统设计的专用操作系统,只是对原有的通用内核进行了一定的裁剪;而WinCE.Net虽然也不是一个严格意义上的实时内核,但却是专门为嵌入式系统设计的。所以,在任务抢占和中断响应方面,WinCE要显著强于Linux。另外,Linux2.4.19在内核级并不支持抢占,这也是它的抢占时间大于WinCE的一个主要原因。不过,这一点在2.6版本的Linux内核中已经得到了解决。

系统调用效率上,WinCE.Net要优于Linux2.4.19,但是Linux的系统调用更加符合POSIX标准,更加规范,而且更加开放。

综上所述,在对实时性要求较高的嵌入式系统中,WinCE.Net要比Linux2.4.19更加适用,并且WinCE.Net在开发类桌面系统中继承了微软的一贯优势,使得开发更加容易。但是,如果系统的实时性要求不高,Linux也许是更合适的选择,因为使用它可以降低成本,并且完全对用户透明,便于修改定制。若想使用Linux作为操作系统开发实时性要求较高的系统,则应对其做适当的实时性改造,或者直接使用已经过实时改造的Linux内核,如 RTLinux等。

4、总结与展望

本文介绍的测试方法与传统的纯软件测试方法相比,具有精度高、易于比对的特点,且测试的复杂度并没有显著地增加;与单纯的硬件测试方法相比,具有性价比高、需要设备少、扩展性强等特点,且测试精度差别不大,但功能不如逻辑分析仪、示波器等专用硬件设备强大。本文介绍的嵌入式操作系统实时性指标体系还有着较大的完善和扩展空间,每一个指标都可以进一步细化。若能在不同的负载条件下利用本文的测试方法进一步测试,则可使得测试结果更加全面客观。

嵌入式操作系统实时性比对与评价
李庆诚 唐德凯 单片机与嵌入式系统应用

引言
  
嵌入式实时操作系统(RTOS,Real Time Operating System)为嵌入式应用的开发者提供了系统级的支撑环境,极大地简化了嵌入式软件系统的设计过程,成为操作系统中一个非常重要的分支。随着RTOS在嵌入式系统中的大量应用,RTOS的选择与评价成为了一个重要的问题。一个RTOS的评价要从很多角度进行,如体系结构、API的丰富程度、网络支持、可靠性等。其中,实时性是RTOS评价的最重要的指标之一,实时性的优劣是用户选择操作系统的一个重要参考。评价一个操作系统的实时性应该着重考察它的哪些指标,以及如何进行测试,是本文着重讨论的问题。
1、操作系统实时性的主要指标
  
严格地说,影响嵌入式操作系统实时性的因素有很多。限于篇幅,本文只列出影响操作系统实时性的6个主要因素。

(1)常用系统调用平均运行时间
  
即系统调用效率,是指内核执行常用的系统调用所需的平均时间。可以参考POSIX标准,按照进程、线程、同步原语(信号量和互斥体等)、文件、内存、中断处理、时钟、时间分类,选取部分常用的系统调用进行测试,如建立删除进程与线程、建立删除文件、读写文件、设置得到优先级、创建释放信号量、分配释放内存空间、加载卸载中断处理模块等。选取的样本不可能十分完整,在这里只是作为一种方法提出,仅供参考。

(2)任务切换时间
  
任务切换时间是指事件引发切换后,从当前任务停止运行、保存运行状态(CPU寄存器内容),到装入下一个将要运行的任务状态、开始运行的时间间隔,如图1所示。
[attachment=-2]
需要注意的是,要使任务进行切换,需要一定的事件触发。通常,这个事件是同步原语,使任务切换,并且过程可被监控。但是,同步原语的操作会带来一定的系统开销,而且不同操作系统的各种同步原语操作效率不同。因此,对被测操作系统使用其支持的各种同步原语进行任务切换测试,选取各自用时最少者——这里称为“ 最佳原语”,作为测量值,以使误差最小。经过对Mutex、Semaphore、Critical Section、SVR5 Semaphore、POSIX Semaphore、pthread_mutex的测试之后,测得WinCE的最佳原语为Critical Section,而Linux的最佳原语为 pthread_mutex。

(3)线程切换时间
  
线程是可被调度的最小单位。在嵌入式系统的应用系统中,很多功能是以线程的方式执行的,所以线程切换时间同样是考察的一个要点。测试方法及原理与任务切换类似,不再介绍。

(4)任务抢占时间
  
任务抢占时间是高优先级的任务从正在运行的低优先级任务中获得系统控制权所消耗的时间,如图2所示。
[attachment=-1]
(5)信号量混洗时间
  
信号量混洗时间指从一个任务释放信号量到另一个等待该信号量的任务被激活的时间延迟,如图3所示。
[attach]0[/attach]
在嵌入式系统中,通常有许多任务同时竞争某一共享资源,基于信号量的互斥访问保证了任一时刻只有一个任务能够访问公共资源。信号量混洗时间反映了与互斥有关的时间开销,是RTOS实时性的一个重要指标。

(6)中断响应时间
  
中断响应时间是指从中断发生到开始执行用户的中断服务程序代码来处理该中断的时间。中断处理时间通常不仅由RTOS决定,而且还由用户的中断处理程序决定,所以不应包括在测试框架之内。
  
针对这些指标的部分或全部,已经有了为数不少的测试方法和测试程序,例如Rhealstone方法,大量的benchmark(lmbench、 HbenchOS等)。但这些测试方法及程序或者是由于计时方法的不足导致计时精度不够,或者是由于需要过多的专业硬件设备(如逻辑分析仪、示波器,等),使得测试要求过高,测试条件不易达到,均存在着一定的缺陷。针对这些问题,本文中提出了一种基于CPLD与目标系统结合的测试方法,较好地解决了这些问题。

现在RT-Thread推荐用winarm的gcc编译器,这个应该是支持C++的
winarm主页:
http://www.siwawi.arubi.uni-kl.de/avr_p ... m_projects

它这个上面也说了如何在lpc上进行C++编程:
http://www.siwawi.arubi.uni-kl.de/avr_p ... /#lpc_cpp1

另外,RT-Thread要支持C++也应该包含链接脚本的修改的。其他的,似乎RT-Thread和操作符相关的应该不多了吧

文件系统已经搞定了,不用加那个绝对路径了,应该快了

发觉文件系统中的Makefile真是难折腾,硬加了个包含文件,是否有办法把它给整掉?

或者干脆在原来的结构中实施一些破坏,不再向下兼容?

目前仓库里的文件基本都整得差不多了,就还剩这个文件系统。试着再编译一次s3c2410的代码,然后放到开发板里跑跑。。。不过模拟器也很重要,以后我得先在上面干活的说。另外一个,原来的zaurus分支也许可以变成PXA分支,而且是强劲的930 [s:175]

呵呵,是否可以加个头像呀 [s:193]

原来LTE在功耗上很有竞争力!WIFI和WiMax都是吃电池的大户,也许等到采用核燃料电池会好些吧 [s:186]

嗯,RTT也应该要么不出手,否则一定是大手笔, [s:175] [s:175] [s:175]

QNX开源了

symbian在开源的路上,看来开源是大势所趋 [s:187]

请抬头仰望公告 [s:154]

下载见楼上;

一个类似于ucos的实时操作系统,当然不仅仅包括kernel还有文件系统,网络协议栈及GUI。

RTGUI的Alpha绘图支持
RTGUI Alpha支持构思了很久。因为Alpha绘图(即透明模式绘图)是现代GUI的基本特性之一,其视觉特性效果显著,RTGUI对alpha的支持是必需具备的。

    Alpha混合操作
    [/list:u]
    原像素点:pixel_old,它由r, g, b三种色彩构成
    欲进行Alpha混合绘制的像素点:pixel,它除了r, g, b之外,应该指定alpha的效果是多少,例如说执行80%的透明效果,alpha=0.8
    那么要实现alpha混合绘制,应该在原来位置上填充的像素点为:
    pixel_new.r = pixel_old.r * alpha + pixel.r * (1 - alpha)
    pixel_new.g = pixel_old.g * alpha + pixel.g * (1 - alpha)
    pixel_new.b = pixel_old.b * alpha + pixel.b * (1 - alpha)


      RTGUI的Alpha支持
      [/list:u]
      RTGUI的实现和传统的GUI有着非常大的差别,其差别体现在:RTGUI虽然也采用客户端/服务端模式的体系结构,但它把传统服务端执行的绘图全部放到了客户端执行,而服务端仅仅保留客户端窗口信息及其剪切相关的信息,即客户端仅仅在自己可视剪切域中进行绘图。这样就会产生一个问题,对一个窗口,如果它被其他窗口所剪切,那么被剪切的部分相对于原窗口将留下一个空洞(因为这块空洞是由剪切窗口负责绘图),如果上层窗口需要实现Alpha效果,那么是不可能的,因为按照上面的alpha绘图公式,pixel_old像素点不能获得。

      为了在RTGUI中加入Alpha支持,RTGUI服务端中将加入相关信息以指明哪个窗口需要执行透明操作(RTGUI中view应该不存在这种问题,而且如何实现alpha将完全是view客户端的事情)。因为RTGUI服务端会保存有所有窗口的列表(可视窗口列表和隐藏窗口列表,可视窗口列表也即Z序),这个窗口列表的节点中将新增一项field以指明此窗口是否是透明窗口。

        涉及透明窗口的操作
        [/list:u]

          剪切域更新,目前的实现是从最上端的窗口一直更新到最底端的窗口。加入alpha后,那么当遇到是透明窗口时:(1)在透明窗口上的窗口剪切域需要发送给透明窗口(因为针对透明窗口,其上层的非透明窗口是能够显示并不透明);(2)透明窗口之下的窗口不应包含透明窗口的剪切域。[/*:m]
          当一个窗口更新时(窗口绘图完成时),如果此窗口之上存在透明窗口,需要发送Paint事件给透明窗口通知它需要重新刷新,即从新绘制透明窗口。[/*:m]
          透明窗口绘图时,先绘图到自己的dc buffer中,然后从dc buffer统一刷新到dc hardware。[/*:m][/list:u]

RT-Thread for AT91RM9200 [K9I开发板]

这几天在空的时候把RT-Thread for AT91RM9200 [K9I开发板]调通了,现在能正常跑起来了(基本的移植 + Finsh)
下一步把协议栈给整上去,希望能发挥它100M口的优势。

由于这个并不是一个新的发布,需要代码的可以联系我。
K9I开发板:
http://www.icdew.com/forumdisplay.php?fid=4&page=1
http://shop34437679.taobao.com/

----
这个是RT-Thread/AT91RM9200的移植信息,个人感觉对于ARM学习入门采用这块开发板比较方便,价格便宜,能够完成基本的功能(USB,网络,JTAG口)。虽然RT-Thread主要采用gcc为编译器,但此版本的RT-Thread/AT91RM9200是可以直接用ADS进行单步调试的。

发布
问题