开源FreeRTOS作为研究实时操作系统演变的案例外文翻译资料

 2022-05-18 20:13:57

英语原文共 17 页,剩余内容已隐藏,支付完成后下载完整资料


开源FreeRTOS作为研究实时操作系统演变的案例

摘要

本文研究实时操作系统 - 开源FreeRTOS的发展。我们关注过去十年中实时绩效和行为的变化。以基准测试为基础的六个主要发布版本提出了定量和定性发展趋势。我们还使用可用的源代码来发现更改的原因。通过分析结果,我们得出了一些与RTOS发展有关的结论,这对FreeRTOS组,其他RTOS开发以及RTOS用户都很有用。

1.介绍

实时操作系统(RTOS)用户通常关注最新版本产品的性能。但是,每个成功的RTOS版本都需要通过多年的努力才能获得大规模的开发。

为了更深入地观察这个过程,本研究重点关注开源FreeRTOS的实时行为和性能的变化。正如雷曼在他的软件进化理论中指出的那样,这将为RTOS用户提供一些见解,并为作者提供重要的反馈(Lehman和Fernaacute;ndez-Ramil,2006; Lehman,1980b,1984,1996; Lehman和Belady,1985; Lehman 和Ramil,2001,2003; Lehman等,1997; Lehman,1980a)。

我们选择了FreeRTOS(Barry,2006; 2008; 2010),因为它是一个广泛使用的RTOS,它有从第一个版本到V8.0.0的将近100个版本。它也是开源的,所有从V2.4.2开始的10年发布的代码都可以在网站上找到。这为我们的研究提供了数据。

RTOS通常用于每个操作都有严格时间要求的嵌入式系统(Silberschatz和Galvin,1998)。它与其他通用操作系统的不同之处在于它应该:提供先发制人和基于优先级的调度,在线程同步中表现出可预见性,并具有确定性的行为(Tan和Tran Nguyen,2009)。这里,任务同步的可预测性指的是将线程应用信号量,互斥锁,队列或任何同步机制时的可预测性。确定性行为是指线程创建和删除,线程切换和中断响应的可预测和一致的延迟,而不管有多少线程存在(Tan和Tran Nguyen,2009)。为了验证所有这些特征,我们设计了评估测试并将它们分为两组:行为测试和性能测试。行为测试评估线程创建和循环是否行为,信号量锁定和释放行为,以及互斥锁定和释放行为。性能测试需要确定线程切换延迟,线程创建和删除时间,中断延迟以及信号和互斥锁获取 - 释放时间。

通过这些测试,我们测试了FreeRTOS的六个主要版本:V3.0.0,V4.0.0,V5.0.0,V6.0.0,V7.0.0和V8.0.0。所有的测试都在相同的硬件平台上实施(基于瑞萨RX63N的处理器)。我们想回答以下几个问题:考虑到它的实时行为,每个版本的错误有哪些? 他们是否在下一个版本中得到纠正; 版本更新中的开销和延迟变化有多大; 以及如何使开源操作系统遵循不断变化的用户需求?

本文的结构如下。第2节简要介绍了现有的软件进化研究和FreeR-TOS;第3部分是实验装置的描述以及我们如何进行这些测试;第4节解释测试结果的细节以及不同版本之间的比较; 第五部分从演化过程的角度分析结果;第6节讨论了本研究设计的有害性威胁和局限性;第7节给出了我们的结论。

2.相关工作

2.1 软件演变

由于Lehman等人在着名的软件系统IBM OS / 360的基础上建立了软件进化理论,并在FEAST项目(Lehman,1996; Lehman等人,1997)中继续进行了研究,考虑到各种软件的演变,成功的案例研究。以色列和Feitel - son(2010)和戈弗雷和涂(2001); 2000)研究了Linux操作系统的演化,作为大规模开源软件系统的案例研究。Capiluppi等人介绍了ARLA(AFS文件系统的开源实现)的演变研究(Capiluppi et al。,2004)。Mockus等人。侧重于开源软件Apache服务器和Mozilla(Mockus等,2002)。Tamary和Feitelson(2015)比较了多年来三种浏览器的性能变化。然而,除了Tamary和Feitelson(2015)之外,所有其他研究都将重点放在代码结构的演变和增长上或功能扩展上,只给出关于软件性能变化的定量数据以及进化。

在Tamary和Feitelson(2015)中,Tamary和Feitelson试图确定浏览器的普及是否可以由技术原因来解释。他们对Chrome,Firefox和Internet Explorer的发布版本进行了5年的基准测试,并考虑了功能和功能方面的比较。

与Tamary和Feitelson(2015年)中介绍的不同,我们的研究不关注市场上不同产品的比较。我们选择了一个开源的RTOS,这不仅使我们能够测试软件在开发过程中的行为和性能如何变化,而且使我们有机会挖掘源代码中的原因。每个样本所需的时间和精力有限,我们无法检查所有以前的出版物中的样本数量。然而,在演进的每个阶段都有代表性的样本,可以看到同样精确的软件发展趋势。

2.2 FreeRTOS概述

FreeRTOS最初是由Richard Barry从他的一个咨询项目中开发出来的,并逐渐发展成为一个RTOS,每月下载量超过7000次,并且全球拥有大量用户(Barry,2008)。

有几个功能可以让人们在他们的设计中考虑FreeR-TOS。它是开源的,有两个许可证选择:修改后的GPL许可证和商业许可证。它具有相对较高的更新和维护频率:从2005年到2016年77次发布。最重要的是,它是一个小型RTOS,支持多种调度策略:先占式,循环式,协作式和混合式调度 巴里,2008年)。

图1显示FreeRTOS内核从V3.0.0开始的每个发行版本的代码行。V3.2.0到V3.2.1的规模有很大的跳跃,主要是由于支持不同处理器的V3.2.1增加了代码。除此之外,FreeRTOS内核的规模增长几乎是线性的,从V4.0.0到最新版本(本文准备时为V8.2.3)没有明显的波动。FreeRTOS的这种发展模式与Feitelson(2012)提到的Linux的“永续发展模式”不同,后者将主要开发分支与维护分支明确区分开来。这一方面表明,FreeRTOS内核的每个版本可能包含所有以前版本(主要或次要版本)所做的累积更改。这已经在FreeRTOS的更改日志中得到确认。另一方面,它也意味着每个版本的行为和性能改进或减少。但是,由于时间和精力的限制,我们选择仅测试主要版本(Vx.0.0)。这一选择未能确定所有FreeRTOS版本中功能行为和性能的详细变化,但仍可看到所有测试部件的清晰轨迹。

实验设置

本节介绍了目标实验系统的体系结构,并概述了如何进行测试。

    1. 系统架构

图2显示了用于测试的目标系统的体系结构。基础硬件是基于瑞萨RX63N的评估板YLCDRX63N。此硬件的一些重要功能是:

(1)最高工作频率为100MHz的32位瑞萨RX63N微控制器单元(MCU);

(2)片上存储器:128K字节RAM,2M字节闪存;

(3)模块内存:16M字节RAM,16M字节串行闪存;

(4)四个片内8位定时器(TMR),四个片内16位比较匹配定时器(CMT)和六个16位片上多功能定时器(MTU2);

(5)USB A主机连接器(USB 2.0 FS 150mA);

(6)2个UART连接器。

瑞萨外设驱动程序库(RPDL)是一个统一的API,用于控制瑞萨电子生产的微控制器上的外设模块。它用于支持定时器功能(一个用于系统时钟的比较匹配定时器,一个用于中断产生的比较匹配定时器和两个用于时间测量的多功能定时器)以及UART。

RX600系列USB主机海量存储类驱动器与M3S-TFAT-Tiny(TFAT)结合使用,使USB功能可保存所有测试结果。

评估测试应用程序高于所有层次。所有的编译工作都是在Windows下完成的,编译工具Renesas RXC Toolchain V2.00.01的试用版。开发和调试环境是瑞萨eclipse studio V2.2.0.13。脱钩和闪光书写工具是J-Link。

虽然USB和UART是实施测试和保存结果所必需的,但我们确保在测试期间没有任何与它们相关的任务或中断正在运行或启用。

3.2测试实施概述

为了满足实时系统的要求,底层操作系统应该在所有情况下都表现出可预测的行为(Buttazzo,2011)。为了在目标操作系统中验证这一点,我们使用两种方法。第一种方法是使用行为测试,讨论操作系统的确定性和行为。第二种方法使用性能测试,重点关注吞吐量和响应或等待时间。我们的测试是RT应用程序。一些具有实时嵌入式系统的作者拥有超过30年的实践经验,帮助我们定义了一般测试模式,它们复制了许多不同应用领域常用的RT机制。

测试基于时间间隔的测量。使用选定的待测硬件来测量这些时间间隔的便宜和高效的方法是在级联工作模式下使用两个16位MTU2定时器,以获得与32位定时器相同的功能。定时器配置为以48MHz运行。因此,评估测试结果的分辨率为0.02mu;s。本文中显示的结果四舍五入到最接近的0.1mu;s( /- 0.1mu;s)。这种精确度比跟踪系统开销快大约10倍(见第4.1节)。定时器在处理器中可用,与我们想要测量的内容不同步。

图3显示了测试方法。创建具有最高运行优先级的实时线程来完成以下循环:获取时间并将其放入本地内存,启动测试操作,再次获取时间并将其放入本地内存。所以t1和t2标志着测试操作的开始和结束,它们的不同之处在于执行时间。这个测试操作只会被中断处理程序延迟。对于不属于中断测试序列的测试,除时钟节拍定时器中断之外的所有中断源都被禁用。对于中断测试系列,我们使用CMT定时器以可编程间隔生成中断。每个测试循环超过1000次,为统计分析提供足够的样本。

测试细节和结果

4.1开销

跟踪系统开销比操作系统相关的硬件更多。跟踪系统开销的一个来源是定时器寄存器读取:虽然每个读出定时器需要4-6个总线周期,即80纳秒到120纳秒,但开销的主要部分是由该硬件上的存储器写入速度限制引起的,大约是800纳秒。

这个测试的目的是准确地测量跟踪系统的开销,以提高整体的准确性。图4显示了测试程序。两个时间戳写操作之间没有操作,所以t2和t1之间的差异是跟踪开销。

t2 - t1 = OH(1)

测试结果(表1)显示评估曲线的开销中只有非常有限的抖动。

4.2时钟滴答处理持续时间

周期性时钟滴答是通用和RT操作系统的重要组成部分(Tsafrir等,2005)。虽然通常在RT系统的高电平中断上使用时钟滴答定时器并不是一个好习惯,但在最高级别上,该缺省时钟会预设很多硬件。RT应用程序设计人员应该在其应用程序框架中考虑正确的中断级别,并尝试选择适合此级别的硬件。

我们把自己置于最坏的情况下,即最高I / O级别中断上的时钟滴答,以查看这种选择对RT行为的影响。因此,我们首先要量化时钟节拍处理时间。

该测试使用时钟滴答中断以比硬件平台上的任何其他中断更高的优先级测量时钟滴答处理时间。因此,在几乎所有其他测试期间,时钟滴答都会出现,并增加测量的开销。在FreeRTOS中,时钟节拍被用作时间基准来指定调度器和其他定时功能的时间片。调度程序将在每个时间片结束时执行,以决定接下来要运行的任务。我们使用四个片内16位比较匹配定时器(CMT0)中的一个来产生系统时钟节拍,该节拍已被配置为在我们的测试中以1 KHz运行,这是一个经典值。

图5显示了这个测试的过程。在两次获取动作之间,有一个繁忙的循环线程执行一些计算。这个繁忙的循环只会被时钟滴答定时器中断处理程序延迟。当忙循环中断时,执行时间增加(2)中指定的值。

t2 minus; t1 minus; (t2 minus; t1) = tc (2)

图6显示了FreeRTOS V3.0.0到V8.0.0的平均时钟周期。我们可以看到FreeRTOS拥有稳定的时钟处理时间,而且只有很少的波动。这对于实时操作系统来说是一个很好的功能。但是,我们观察到两个严重的变化:一个发生在V4.0.0和V5.0.0之间,另一个发生在V7.0.0和V8.0.0之间。正如源代码中所证实的,这些更改是由于这些不同版本中时钟节拍处理方法的调整所致。

从这个测试中我们可以看到时钟滴答的处理时间并不一定会随着演进而下降。实际上,从V5.0.0到V7.0.0,它仍然处于相对较高的水平,然后在版本V8.0.0中有了很大的改进。

4.3.Behaviour测试

4.3.1线程创建和轮询行为

在实时编程中,例如应用速率单调调度原则,最好为不同的线程分配不同的优先级。

但是,并非所有的RT设计人员都知道这个原则,或者他们使用的操作系统的优先级数量有限,并最终将线程分配给相同的优先级。考虑到在大多数RTOS中,特别是在FreeRTOS中,循环调度是针对同一优先级级别的线程预见的一个选项,同样,我们将自己置于最坏情况(错误设计)的情况下,优先级相同。

创建并结束。图7显示了该测试如何实现以及质量RTOS的预期结果。

假设系统中有四个优先级:最低,低,中和高。首先创建线程T1并将其设置为中间优先级,然后按照以下步骤进行测试:

(1)创建低优先级的线程T2。

在创建线程仍处于活动状态时,T2不能运行。

(2)创建中间优先级的另一个线程T3。

T

全文共16898字,剩余内容已隐藏,支付完成后下载完整资料


资料编号:[12174],资料为PDF文档或Word文档,PDF文档可免费转换为Word

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

以上是毕业论文外文翻译,课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。