标签: 实时操作系统

在工业4.0时代，人工智能和工业物联网的发展走上了快车道，越来越多的行业对实时操作系统有了更加迫切的需求。基于此，飞凌嵌入式推出了在OK3568-C开发板上运行的实时操作系统，本文中小编将为大家介绍飞凌嵌入式在OK3568-C开发板上实现实时性的方式，以及实时内核的效果测试。 1 为什么选择实时操作系统 ？ 我们都知道，操作系统可以分为实时操作系统和分时操作系统。分时操作系统其实就是将系统处理机时间与内存空间按一定的时间间隔轮流地切换给各终端用户的程序使用。目前市面上绝大多数板卡上运行的Linux系统都是分时操作系统。 但是随着自动驾驶、智能机器人等行业的兴起，对板载操作系统的实时性也提出了更高的要求。这时候，分时系统就无法满足某些对实时性要求较高的行业的需求了，必须对Linux系统进行改进，使其具有更好的实时性，以顺应行业的发展。 例如无人驾驶技术，系统需要根据复杂的路况情况及时做出分析判断，做出反应，执行刹车或变道操作；又比如车载安全气囊，在遇到突发事故时，系统必须第一时间做出反应弹出安全气囊，保护车内乘客人身安全。这些实际应用场景都离不开实时操作系统。 2 如何实现“实时性” ？ Linux系统可以采用打补丁的方式来实现“实时性”。RT-Linux就是在Linux的基础上加入了一个实时补丁，从而将Linux改进成实时操作系统。简单地说，“实时补丁”的主要工作就是针对Linux系统的优先级倒置、自旋锁等问题进行改进，以达到实时操作系统的要求。 基于这个思路，我们就可以通过对内核打实时补丁的方法让OK3568-C开发板上的Linux系统满足实时性的需求。 飞凌提供了两个补丁文件： 0001-patch-patch-4.19.206-rt87.patch-fix-kernel-sched-cor.patch 0002-fix-kernel-sched-core.c.patch 将两个补丁文件拷贝到源码/OK3568-linux-source/kernel路径下，执行以下命令： patch-p1 <0001-patch-patch-4.19.206-rt87.patch-fix-kernel-sched-cor.patch patch-p1 < 0002-fix-kernel-sched-core.c.patch 然后，在源码执行./build.sh kernel命令，即可在/OK3568-linux-source/kernel目录下生成boot.img镜像文件。 客户也可以直接单步烧写飞凌制作完成的boot.img镜像文件。 使用Type-C线连接开发板和主机，按住recover键不松开，然后再按reset键系统复位，大约两秒后松开recover键。系统将提示发现一个loader设备。 点击左侧勾选boot分区。 最后，点击右侧选择您编译生成的boot镜像文件路径，点击“执行”按钮将自动烧写并重新启动。 想要了解有关实时补丁的详细资料，您可以在公众号留言联系飞凌嵌入式销售工程师。 3 实时内核效果测试 测试实时性的关键指标便是“延时” ，延时指的是不论系统运行在代码的什么位置，当事件发生时，系统响应该事件的时间。 其中 中断延时 指的是中断触发到中断服务函数执行完毕的时间； 调度延时 指的是进程在队列中等待直到获取CPU控制权被执行的时间。 实时性，也可以表现为对这两段延时最大的容忍程度。这里通过cyclictest软件测量中断延时和调度延时时间。 由于在真实的使用环境下并不能触发最大的延时时间，因此在没有合适负载的情况下运行cyclictest所测得的延时统计数据是没有意义的。这里我们采用官方提供的hackbench工具来模拟部分类型的负载，然后在此基础上运行cyclictest软件来测试事件发生时，系统响应该事件的时间。 这里我们着重比较两者Max得出的参数，因为系统的实时性能是由最大延时时间决定的。通过对打实时补丁前后测试结果进行对比， 打实时补丁以后，可以明显看出延时从213μs降低到80μs以内，实时效果还是十分明显的 。（不同测试条件下的延时不同，这里的测试结果仅供大家参考） 希望这个实时性方案能够满足您的需求，了解有关飞凌嵌入式OK3568-C开发板的详情请搜索飞凌嵌入式官网 。

运动控制系统已被广泛应用于工业控制领域。近年来，工业控制对运动控制系统的要求越来越高。传统的基于PC及低端微控制器日渐暴露出高成本、高消耗、低可靠等问题，已经不能满足现代制造的要求 。随着嵌入式技术的日益成熟，嵌人式运动控制器已经初露锋芒。基于ARM技术的微处理器具有体积小、低成本、低功耗的特点，决定其在运动控制领域具有良好的发展前景。 PCL6045BL是一种新型专用DSP运动控制芯片，它具有强大的数据处理能力和较高的运行速度，可以实现高精度的多轴伺服控制。为解决精密制造对低成本、可移植性强的通用型多轴数控系统的迫切需求，文中给出一种基于ARM 微处理器S3C2440与DSP专业运动控制芯片PCL6045BL构成的嵌入式四轴运动控制器。该运动控制器具有高性能、低成本、体积小、可独立运行等特点，可以满足运动控制系统高速、高精度的 要求。它可广泛应用于雕刻机、机器人、绣花机以及数控加工等工业控制领域。 为解决精密制造对低成本、可移植性强的通用型多轴数控系统的迫切需求，给出一种基于ARM微处理器S3C2440和专用DSP运动控制芯片PCL65045BL组合的嵌入式四轴运动控制器。硬件上该控制器采用ARM+DSP的主从式双CPU结构，结合ARM在人机界面显示、通信接口方面的优势以及PCL6045BL高控制精度的优点。软件上在S3C2440上移植μC/OS-II实时操作系统来管理运动控制系统。该控制系统通用性较强，可广泛应用于雕刻机、机器人、绣花机以及数 控加工等工业控制领域。 1 系统总体设计 嵌入式四轴运动控制器主要由硬件部分和软件部分构成。 硬件主要包括S3C2440嵌入式主控板和PCL6045BL运动控制板两个部分。S3C2440嵌入式主控板和PCL6045BL运动控制板之间通过通用的IDE通信接口进行连接。 软件方面在硬件平台的基础上移植S3C2440实时嵌入式操作系统，设计Boot Loader、外设驱动以及运动控制系统的应用程序。采用上述的软硬件平台，嵌入式运动控制器可以达到开放性能好、精度高的要求。本嵌入式四轴运动控制器的结构如图1所示。 图1 嵌入式四轴运动控制器的构成 ARM具有丰富的片内外围电路，如USB接口、IIS接口、LCD控制器等，在人机界面的显示、通信接口以及系统移植方面具有更强大的功能。PCL6045BL运动控制芯片速度快，可靠性高，性能好，在运动控制方面有很大的优势。 实时操作系统μC/OS-II包含了实时内核、任务管理、时间管理、任务间通信同步和内存管理等功能，可以使各个任务独立工作，互不干涉，很容易实现准时而且无误地执行，使实时应用程序的设计和扩展变得容易，使应用程序的设计过程大为减化 。将S3C2440处理器、PCL6045BL 以及μC/OS-II三者的优势应用到本嵌入式四轴运动控制器中可以使其具有强大的功能，并缩短开发时间。 本嵌入式四轴运动控制器以S3C2440为主控平台，在ARM上移植μC/OS-II实时操作系统来进行人机界面的显示、I/O的管理、任务问的通信、指令的编译等工作。PCL6045BL运动控制模块主要负责位置控制，插补驱动，速度控制。用户的指令通过S3C2440指令编译系统的编译，通过与PCL6045BL之问的专用通信接口来控制DSP运动控制芯片发出脉冲以达到使伺服电机高速运行。 2 系统硬件设计 2．1 系统硬件平台设计 在控制系统中，以S3C2440处理器为主控核心，PCL6045BL运动控制芯片为从CPU，构建的嵌入式运动控制器结构如图2所示。 图2 系统硬件 S3C2440是一款16/32位ARM920T RISC处理器，它实现了MMU、AMBA总线和独立的16 KB指令和16 KB数据哈佛结构的缓存，每个缓存均为8个字长度的流水线。S3C2440提供全面的、通用的片上外设，不需要配置额外的部件。 PCL6045BL运动控制芯片，由NPM公司生产，是一种通过总线接收CPU命令、并产生脉冲控制步进电机或脉冲驱动型伺服电机的CMOS大规模集成芯片，可提供多种输出运动控制功能，包括连续、定长、回原点等输出方式。PCL6045BL可以实现2～4轴线性插补及任意两轴圆弧插补。 在这种主从结构框架基础上，主CPU S3C2440主要负责数据的存储、人机界面的显示、网络通信等管理工作。从CPU PCL6045BL输出的脉冲发送给4个轴的伺服驱动器。S3C2440只需要通过发送简单的指令给PCL6045BL，便可实现各种控制功能。 2．2 ARM 与PCL6045BL的连接 PCL6045 BL与ARM的通信是通过读写I/O总线上的几个地址来进行指令和数据的传输。PCL6045BL每个轴的内部寄存器地址由A0、A1 和A2地址线输人决定，其控制地址范围由输入端子A3和A4进行选择。因此在这种主从结构的设计中，ARM与PCL6045BL的连接如图3所示。 图3 PCL6045BL与S3C2440的接口电路 2．3 I/O接口电路 嵌入式四轴运动控制器与伺服电机之间是通过I/O接口电路进行连接的。I/O接口电路主要任务是完成输入信号的光电隔离以及对输出脉冲的驱动。设计中采用光电耦合器将PCL6045BL芯片与后面的伺服电机驱动器以及其他控制反馈等线路隔离。由于光耦合器输入输出问互相隔离，电信号传输具有单向性等特点，因而具有良好的电绝缘能力和抗干扰能力。又由于光耦合器的输入端属于电流型工作的低阻元件，因而具有很强的共模抑制能力。将PCL6045BL的输出信号(如CP、CW等)和输入信号(如报警、限位等)都使用光耦器件与PCL6045BL隔离，这样能有效地防止干扰信号进入主芯片损坏PCL6045BL。 3 软件设计 系统软件部分由μC/OS-II实时嵌入式操作系统及相关应用软件组成。μC/OS-II实时嵌入式操作系统仅仅提供了一个任务调度的实时内核，因而需要自行开发一系列与系统运行相关的设备驱动程序、API函数及应用程序，才能将μC/OS-II扩展为一个完整、实用的实时操作系统。 3．1 Boot Loader的设计 嵌入式系统中，通常并没有像BIOS那样的固件程序，因此整个系统的加载启动任务就完全由Boot Loader来完成。Boot Loader是系统加电后运行的第一段代码，负责初始化系统并启动操纵系统，相当于PC机的程序。Boot Loader初始化硬件设备，建立内存空间的映射图，为最终调用操作系统内核准备好正确的环境。 Boot Loader分为阶段1和阶段2两个部分，与CPU核以及存储设备密切相关的处理工作通常都放在阶段1中，且可以用汇编语言来实现；而阶段2则通常用C语言来实现一般的流程以及对板级的一些驱动支持。 阶段1主要进行定义入口、设置中断向量、系统寄存器配置、初始化寄存器等操作。而阶段2主要完成调用初始化函数、初始化闪存设备、初始化内存分配函数等操作。Boot Loader是嵌入式系统软件开发的第一个环节，把实时操作系统和硬件平台紧密地结合起来，对于嵌入式系统的软件开发尤为重要。 3．2 μC/OS-II在S3132440的移植 嵌入式实时操作系统μC/OS-II是一个源代码公开的多任务实时操作系统内核，它简化了应用软件的设计，使控制系统的实时性得到保障。良好的多任务设计，有助于提高控制系统的稳定性和可靠性。所谓移植，就是通过修改操作系统内核与处理器相关部分的源代码，使一个实时内核能在微处理器或微控制器上运行。μC/OS-II的文件系统结构包括核心代码部分，配置代码部分，处理器相关代码部分，如图4所示。其中处理器相关代码部分包括OS_CPU.H,OS_CPU.A.ASM,OS_CPU.C.C 3个文件。将μC/OS-II移植到S3C2440只需要修改与处理器相关的代码即可。 图4 μC/OS-II的文件系统结构 3．3 系统应用程序设计 实时应用程序的设计过程包括如何把问题分割为多个子任务，每个子任务都是整个系统的一部分，都被赋予一定的优先级，有自己的一套CPU寄存器和堆栈空间。一个任务，也叫一个线程，是一个简单的程序，该程序可以认为CPU完全只属于自己。在本设计中将任务划分为人机界面的设计、数控指令编译解释、伺服单元采集任务、状态监视等。μC/OS-II可以按照优先级启动各个任务，并通过内核来完成任务之间的调度。系统的基本流程如图5所示。 图5 用户程序流程 S3C2440根据系统的应用程序对指令进行解释，调用运动控制函数，继而PCL6045BL发出脉冲控制伺服电机去控制执行机构动作，实现运动控制的结果。 3．4 NC代码解释 运动控制器接受来自上位机发送过来的加工文件，但加工文件指令在程序中不能直接被识别，在执行指令之前必须先对其进行解析译码。解释器的主要功能就是将用户程序以程序段为处理单位，将程序中的轮廓信息、运行速度和辅助功能信息，转换成嵌入式运动控制器能够执行的格式。解释过程主要包括数控文件的读入、词法分析、语法分析以及加工信息存储数据结构等过程，如图6所示。 图6 程序处理流程 4 实例分析 上位机通过RS485总线与S3C2440连接，把NC指令文件输入到ARM 中，经过NC代码解释器，变成PCL6045BL能够识别的代码，从而完成规定的运动控制功能。用NC代码编写如下加工程序： N001 COO X15 Y25//起始点选定 N002 G18//XY平面选择 N003 G90 G01 X15 Y5//准备直线插补 N004 X30 Y5//(15，5)到(30，5) N005 X30 Y15//前行至点(30，15) N006 X45 Y15//前行至点(45，15) N007 X45 Y5//前行至点(45，5) N008 X60 Y5//前行至点(60，5) N009 X60 Y25//前行至点(60，25) N010 X15 Y25／／回到始点(15，25) 根据上面所给的代码可以完成如图7所示的多点之间直线插补的功能。 图7 多线段直线插补运动轨迹 5 结语 该运动控制器的硬件结构是基于微处理器S3C2440和PCL6045BL运动控制芯片设计的，它较好地发挥了ARM处理器的高性能、低成本和运动控制芯片的高可靠性、开发周期短的优点；在控制器硬件平台上移植μC/OS-II实时操作系统既能使整个软件系统结构简结、层次清晰，又能很好地达到运动控制实时性的要求。

对许多嵌入式项目来说，系统设计师都倾向于选择实时操作系统(RTOS)。但RTOS总是必要的吗？答案是取决于具体的应用，因此了解我们要达到什么目标是决定RTOS是必要的还是花瓶的关键。 一般来说，在采用非实时操作系统(non-RTOS)的任何场合，也都可采用RTOS。但是，要找到一款具有完全相同应用编程接口(API)的匹配RTOS就相当困难了。因此，许多传统的操作系统(OS)在其内嵌入了一个RTOS。例如，Lynux-Works LynxOS和Bluecat Linux共享一个Linux API。LynxOS是一款硬RTOS，而Bluecat是Linux的一个衍生产品。 Linux继续在努力改善其实时性能，但其最长中断时延仍无法满足对RTOS来说至关重要的硬(hard)实时要求。这些问题最后都会归结为服务质量(QoS)。像RTLinux Free这样的平台补充了Linux，因为它们可提供硬实时级别的QoS。 要指出的很重要一点是：这类补充常常是在原始OS上集成一个RTOS编程环境。与传统台式或服务器OS相比，RTOS通常要小很多。RTOS常常针对更小和资源有限的MCU。例如，CMX的CMX-RTX和CMX-Tiny+可运行在8位MCU到64位处理器上。 8位处理器不断增加的计算能力和存储容量正使得RTOS对这些平台具有更大吸引力。但是，通常16位或以上平台才需要OS或RTOS，常见的RTOS选择有Express Logic的ThreadX、Wind River的VxWorks、Micrium的uCOS-II、以及Green Hills Software的velOSity。取决于需求，MontaVista的Linux可在几个微秒的水平上满足16位和32位平台的要求。 RTOS核心：调度和分割 大多数程序员不熟悉RTOS的限制和要求。大多数人通常因其性能选择RTOS。大多数RTOS产品代码少和速度快，现在RTOS还提升了一致性。RTOS除能很快完成任务外，还能保证很好地完成任务。 在许多应用中，一个迟到的结果可以是灾难性的。因此，人们宁愿在一个要求的时限内获得较差的结果。这些应用通常被称为硬实时系统。硬实时不是指系统响应有多快或多快一个系统能响应，而是指系统能多可靠地满足特定的要求。 一个硬实时系统可能有一个一分钟的固定周期时间，它要求的响应时间为一秒。理论上，这样的要求几乎所有的操作系统都能实现。但事实并非总是如此，正如任何一个人都能证明等待台式计算机应用在一分钟之内做出响应需要等多久。 硬实时系统通常具有更短的周期时间和更紧苛的响应要求。更快的处理器速度总是有帮助的，多内核平台也能改善响应速度。对开发人员来说，窍门在于把系统需求与硬件和软件匹配起来，然后才是RTOS在嵌入式应用中的重要性。 一个RTOS可以实现一系列调度策略，但应用经常会制约一个程序员的选择（见表）。非优先式调度(non-preemptive scheduling)的实现虽不重要，但在一些应用中很有用。另一方面，任务内的非优先式调度可在优先式系统的顶部实现。 不应该轻忽非优先式调度，特别在新型多内核处理器出现以后。这里，硬件可被调整到处理一个基于事件的操作，其中线程将等待外部事件的发生。对处理多线程的单核处理器来说，该方法一般不适用。但对有许多内核的多核系统说，典型情况是为一个外设指定一个核。所以，在等待事件发生期间，使该核空闲起来是有意义的。 其结果是，优先式、中断驱动的RTOS架构占据了业已部署的大部分平台。这些平台有一系列的要求、问题和解决方案（见图）。虽然借助硬件手段(多个寄存器组合、硬件调度、任务切换、以及分层中断优先级系统等)可显著缩短中断时延，但该时延永远是一个问题。 优先式处理会带来若干问题。它们大多是与时序关联的，如竞争条件、死循环、空耗等待和优先级转换，它们发生在低优先级任务A拥有更高优先级任务B的同步资源，而优先级比A高的任务C正在运行。 如果没有像优先级置顶(priority ceilings)这样的特性，任务C就可以阻止任务A和任务C运行。优先级置顶特性可以把任务A的优先级改变成与任务C的优先级一样，从而允许任务A运行并最终释放任务C所需的资源。至此，任务A的优先级复原，任务C就可以继续运行。 程序员必须解决的其它与时序相关的问题通常是难以定位和纠正的缺陷源。在定位这些缺陷时跟踪工具就变成了很有价值的手段，因为诸如受阻的任务等症候是这些问题的唯一表现形式。 就操作系统所需的特性来看，重入库(reentrant library)特性在RTOS环境下是可有可无的。但在一个典型的操作系统中，由于任务和程序常常是随机的和变化的，而且常公用库，因此重入库是一个必须的特性。 在嵌入式环境中，对在系统中运行的程序和任务一般会有更多的控制要求。通常，除操作系统接口(可以是重入也可能是非重入的)外，各任务从不共享任何代码。程序员(特别是那些负责设备驱动程序的)需要注意这一重入性问题。 现在业内已有很多的任务同步机制，从互斥(mutex)到消息系统。从RTOS的角度，这些机制在诸如竞争条件此类的同步问题上，没有什么差异。 在MCU和操作系统中，定时器很常见。至少，一个定时器可被用作时钟。但由于定时器是如此的有用，以至于它常以一种特殊方式实现出来。POSIX规范甚至把定时器定义为组件。定时器还可当作看门狗来用。 在许多MCU中，一个定时器可以设置用来唤醒处在休眠模式的系统。一些实现允许操作系统把其用作一个通用定时器，尽管这一唤醒特性独立于操作系统。 一些系统具有带不同特性的多种定时器来满足不同的要求。一些定时器可被同步用以为电机控制应用提供同时的脉宽调制(PWM)流。对RTOS来说，一个定时器通常可用以实现时钟和提供时间切片支持。 定时器也支持时间切片。时间切片常见于时间共享系统，它给每种应用一个合理的时间片断来执行。可在任一中断层级上实现这种轮询调度。 通常，由时钟提供的时间切片是固定时长的，每个任务在获得优先权前将被给予同样长度的时间切片来执行。当然，该策略是随机的且可有多种实现。例如，可变的时间切片宽度将允许时间以每个任务为单位进行分配，其中一些任务获得的时间会比另一些长；而若采用任务优先级方法，则有可能使低优先级任务得不到响应。 许多RTOS采用固定调度器。其它RTOS则允许替换或定制，但RTOS中的另一部分支持各种策略。这一灵活方法使得像Linux这样的操作系统能够提供实时支持，与此同时，它们还能在时间切片环境下运行多种应用。实时任务具有高优先级，且在一般用户任务前得到执行。 Linux实际上具有一个更复杂的调度系统，它对任务是通过轮询方法把控制权转交给具有相同优先级的其它任务还是一直运行到结束做出了具体约定。像Open Kernel Labs的OKL4虚拟化RTOS平台解决了该问题。 《电子设计技术》网站版权所有，谢绝转载 基本通信 一些文献把任务同步和通信分开来说，但总的来说，它们是一回事。实际上就是讲信息是如何交换的。基于消息传递的RTOS最清楚地体现出这点。这里，消息系统处理所有通信且不区分通信和同步。 至少，RTOS必须提供一个相互排斥的本原，如互斥。其它东西可构建在该本原上。在许多场合，如消息传递系统，对相互排斥的支持隐藏在操作系统内。只有更高级别的消息功能显露于外。 消息系统有各种名称，从管道到队列。其实现可横跨从单处理器、单存储器模式到多内核群集系统。Enea的OSE RTOS和QNX的Neutrino是基于消息传递的两个主线RTOS。 不管选择了什么方法或API，通信系统必须在某一程度上被整合进操作系统。因此，若主动队列中的任务必须等待一个事件，则该任务可被移走。类似，引发一个事件从而导致另一个任务活动的任务将产生一个调度行为。 通信、事件和调度可与硬件关联起来，这是RTOS必须处理的其它一些事。TI的DSP/BIOS是一款RTOS，它设计用于运行在像TI的DaVinci双核系统的DSP上。DSP/BIOS的一个主要功能是处理 ARM 核和DSP 核间的通信。 向更多大内核的发展将很可能会保留RTOS或OS。不过，小内核阻止或限制了采用RTOS的可能性。Intellasys的SEAforth 40C18芯片带有40个运行Forth的小型18位内核。指令很精简，每个字包含四条指令。 每个内核有64个字的 ROM和RAM，该芯片只能容纳10,000指令。当然，这只够装下一个程序，安装RTOS是不可能的。不过，整个芯片上有足够空间安装一个操作环境的特定部分。同样，适于该平台的应用常常是特定的。于是，由于硬件可处理内核之间通信和任务调度，因此RTOS类的支持并不需要。 资源管理 使RTOS脱颖而出的是其管理资源(包括时间和存储器)的能力。时序问题与中断响应时间有关，但资源管理时序问题也会出现。虽然中断解决了一系列时序问题，但各应用仍必须利用资源。 考虑存储器分配情况。许多实时应用不采用动态存储器分配，以确保存储器分配和回收时所产生的不同不会变成一个问题。需要动态存储器分配的应用常把存储器划分为实时和非实时。后者处理动态存储器分配。典型情况下，在使用前，实时部分必须被分配有足够的存储器。 在实时嵌入式应用中采用C和C++是因为存储器和其它资源的用法是显式的。实时任务需要避免采用C和C++。特别是，当存储器分配和回收更容易隐藏时采用C++是很困难的。 像Java和C#这样的语言带来的挑战更大，它们与生俱来地采用动态存储器分配。程序员可控制存储器分配和回收。在某些情况下，编程环境可以强化存储器分配和回收。 Java实时规范(RTSJ)定义了创建不需要垃圾回收的Java应用的方法。RTSJ是在Java框架内这样做的，从而使程序员在不被存储器分配限制的条件下享有Java的好处。 Sun和DDC-I都实现了RTSJ。DDC-I的实现支持x86和PowerPC平台。Aonix有一个称为PERC的类似平台。这些平台以实时、同时的垃圾回收为特征，从而使在不受存储器分配限制的情况下，在Java内编写实时应用成为可能。 但因系统必须允许线程为垃圾回收器进行转换，所以实时要求并非那么紧迫。另一方面，垃圾回收器将耗费时序资源，所以，只有实时任务方可保证满足一定的期限要求。快是好事，但及时才是RTOS的天条。 考察实时平台时，考虑之一是存储器分配对系统的整体影响。许多系统可工作在从不改变的静态分配环境，但更多的动态系统可从实时垃圾回收中获益。研究表明，垃圾回收的效益与确定的存储器分配是可比的。 围绕诸如Java和C#等虚拟机类型平台的另一个问题是对just-in-time(JIT)编译器的使用限制。基于这些系统的实时系统必须采用类似C和C++等所用的提前（ahead-of time，AOT）编译器。 设计师会因其更高的生产力、更低的出错率以及安全性等特点选用Java 或C#。所以，对制定一个称为 JSR-302的用于对安全有至高要求应用的Java规范就不足为奇了。 保护RTOS RTOS受到其运行的硬件平台的限制。可对缺少存储器保护的硬件加以保护，但安全级别会受到限制。但存储器和虚拟机可以更高水平的安全性支持引导。诸如SE Linux、Green Hills Integrity和 LynuxWorks LynxSecure Embedded Hypervisor以及 LynxOS-SE RTOS内的安全策略可比典型RTOS提供可靠得多的保护。但成本也高，所以开发者需对此进行权衡。 实时系统开发者不得不应对策略实现和边界问题。取决于信息的来所去处，安全支持会花很长时间。正是为此引入了分区系统，所以，可在边界采取安全措施且把应用的非实时部分放在这部分空间内。 可感知OS的调试器 当考虑选用操作系统时，对调试器的支持是个关键。这种支持体现在两个方面：内核和设备驱动器调试以及操作系统感知。 内核调试对设备驱动器的创建和支持以及内核强化很重要。在许多情况，为处理RTOS的内核，需要专用调试器。它也要求能理解内核环境以及应用环境。 OS感知可更深入地了解操作系统。支持方式可以是从提供有关OS服务状态的信息到调整任务调度等方方面面。同样，能感知OS的调试器可在停止其它应用或线程的同时允许其它应用或线程的运行。 《电子技术设计》网站版权所有，谢绝转载

对许多嵌入式项目来说，系统设计师都倾向于选择实时操作系统(RTOS)。但RTOS总是必要的吗？答案是取决于具体的应用，因此了解我们要达到什么目标是决定RTOS是必要的还是花瓶的关键。 一般来说，在采用非实时操作系统(non-RTOS)的任何场合，也都可采用RTOS。但是，要找到一款具有完全相同应用编程接口(API)的匹配RTOS就相当困难了。因此，许多传统的操作系统(OS)在其内嵌入了一个RTOS。例如，Lynux-Works LynxOS和Bluecat Linux共享一个Linux API。LynxOS是一款硬RTOS，而Bluecat是Linux的一个衍生产品。 Linux继续在努力改善其实时性能，但其最长中断时延仍无法满足对RTOS来说至关重要的硬(hard)实时要求。这些问题最后都会归结为服务质量(QoS)。像RTLinux Free这样的平台补充了Linux，因为它们可提供硬实时级别的QoS。 要指出的很重要一点是：这类补充常常是在原始OS上集成一个RTOS编程环境。与传统台式或服务器OS相比，RTOS通常要小很多。RTOS常常针对更小和资源有限的MCU。例如，CMX的CMX-RTX和CMX-Tiny+可运行在8位MCU到64位处理器上。 8位处理器不断增加的计算能力和存储容量正使得RTOS对这些平台具有更大吸引力。但是，通常16位或以上平台才需要OS或RTOS，常见的RTOS选择有Express Logic的ThreadX、Wind River的VxWorks、Micrium的uCOS-II、以及Green Hills Software的velOSity。取决于需求，MontaVista的Linux可在几个微秒的水平上满足16位和32位平台的要求。 RTOS核心：调度和分割 大多数程序员不熟悉RTOS的限制和要求。大多数人通常因其性能选择RTOS。大多数RTOS产品代码少和速度快，现在RTOS还提升了一致性。RTOS除能很快完成任务外，还能保证很好地完成任务。 在许多应用中，一个迟到的结果可以是灾难性的。因此，人们宁愿在一个要求的时限内获得较差的结果。这些应用通常被称为硬实时系统。硬实时不是指系统响应有多快或多快一个系统能响应，而是指系统能多可靠地满足特定的要求。 一个硬实时系统可能有一个一分钟的固定周期时间，它要求的响应时间为一秒。理论上，这样的要求几乎所有的操作系统都能实现。但事实并非总是如此，正如任何一个人都能证明等待台式计算机应用在一分钟之内做出响应需要等多久。 硬实时系统通常具有更短的周期时间和更紧苛的响应要求。更快的处理器速度总是有帮助的，多内核平台也能改善响应速度。对开发人员来说，窍门在于把系统需求与硬件和软件匹配起来，然后才是RTOS在嵌入式应用中的重要性。 一个RTOS可以实现一系列调度策略，但应用经常会制约一个程序员的选择（见表）。非优先式调度(non-preemptive scheduling)的实现虽不重要，但在一些应用中很有用。另一方面，任务内的非优先式调度可在优先式系统的顶部实现。 不应该轻忽非优先式调度，特别在新型多内核处理器出现以后。这里，硬件可被调整到处理一个基于事件的操作，其中线程将等待外部事件的发生。对处理多线程的单核处理器来说，该方法一般不适用。但对有许多内核的多核系统说，典型情况是为一个外设指定一个核。所以，在等待事件发生期间，使该核空闲起来是有意义的。 其结果是，优先式、中断驱动的RTOS架构占据了业已部署的大部分平台。这些平台有一系列的要求、问题和解决方案（见图）。虽然借助硬件手段(多个寄存器组合、硬件调度、任务切换、以及分层中断优先级系统等)可显著缩短中断时延，但该时延永远是一个问题。 优先式处理会带来若干问题。它们大多是与时序关联的，如竞争条件、死循环、空耗等待和优先级转换，它们发生在低优先级任务A拥有更高优先级任务B的同步资源，而优先级比A高的任务C正在运行。 如果没有像优先级置顶(priority ceilings)这样的特性，任务C就可以阻止任务A和任务C运行。优先级置顶特性可以把任务A的优先级改变成与任务C的优先级一样，从而允许任务A运行并最终释放任务C所需的资源。至此，任务A的优先级复原，任务C就可以继续运行。 程序员必须解决的其它与时序相关的问题通常是难以定位和纠正的缺陷源。在定位这些缺陷时跟踪工具就变成了很有价值的手段，因为诸如受阻的任务等症候是这些问题的唯一表现形式。 就操作系统所需的特性来看，重入库(reentrant library)特性在RTOS环境下是可有可无的。但在一个典型的操作系统中，由于任务和程序常常是随机的和变化的，而且常公用库，因此重入库是一个必须的特性。 在嵌入式环境中，对在系统中运行的程序和任务一般会有更多的控制要求。通常，除操作系统接口(可以是重入也可能是非重入的)外，各任务从不共享任何代码。程序员(特别是那些负责设备驱动程序的)需要注意这一重入性问题。 现在业内已有很多的任务同步机制，从互斥(mutex)到消息系统。从RTOS的角度，这些机制在诸如竞争条件此类的同步问题上，没有什么差异。 在MCU和操作系统中，定时器很常见。至少，一个定时器可被用作时钟。但由于定时器是如此的有用，以至于它常以一种特殊方式实现出来。POSIX规范甚至把定时器定义为组件。定时器还可当作看门狗来用。 在许多MCU中，一个定时器可以设置用来唤醒处在休眠模式的系统。一些实现允许操作系统把其用作一个通用定时器，尽管这一唤醒特性独立于操作系统。 一些系统具有带不同特性的多种定时器来满足不同的要求。一些定时器可被同步用以为电机控制应用提供同时的脉宽调制(PWM)流。对RTOS来说，一个定时器通常可用以实现时钟和提供时间切片支持。 定时器也支持时间切片。时间切片常见于时间共享系统，它给每种应用一个合理的时间片断来执行。可在任一中断层级上实现这种轮询调度。 通常，由时钟提供的时间切片是固定时长的，每个任务在获得优先权前将被给予同样长度的时间切片来执行。当然，该策略是随机的且可有多种实现。例如，可变的时间切片宽度将允许时间以每个任务为单位进行分配，其中一些任务获得的时间会比另一些长；而若采用任务优先级方法，则有可能使低优先级任务得不到响应。 许多RTOS采用固定调度器。其它RTOS则允许替换或定制，但RTOS中的另一部分支持各种策略。这一灵活方法使得像Linux这样的操作系统能够提供实时支持，与此同时，它们还能在时间切片环境下运行多种应用。实时任务具有高优先级，且在一般用户任务前得到执行。 Linux实际上具有一个更复杂的调度系统，它对任务是通过轮询方法把控制权转交给具有相同优先级的其它任务还是一直运行到结束做出了具体约定。像Open Kernel Labs的OKL4虚拟化RTOS平台解决了该问题。 《电子设计技术》网站版权所有，谢绝转载 基本通信 一些文献把任务同步和通信分开来说，但总的来说，它们是一回事。实际上就是讲信息是如何交换的。基于消息传递的RTOS最清楚地体现出这点。这里，消息系统处理所有通信且不区分通信和同步。 至少，RTOS必须提供一个相互排斥的本原，如互斥。其它东西可构建在该本原上。在许多场合，如消息传递系统，对相互排斥的支持隐藏在操作系统内。只有更高级别的消息功能显露于外。 消息系统有各种名称，从管道到队列。其实现可横跨从单处理器、单存储器模式到多内核群集系统。Enea的OSE RTOS和QNX的Neutrino是基于消息传递的两个主线RTOS。 不管选择了什么方法或API，通信系统必须在某一程度上被整合进操作系统。因此，若主动队列中的任务必须等待一个事件，则该任务可被移走。类似，引发一个事件从而导致另一个任务活动的任务将产生一个调度行为。 通信、事件和调度可与硬件关联起来，这是RTOS必须处理的其它一些事。TI的DSP/BIOS是一款RTOS，它设计用于运行在像TI的DaVinci双核系统的DSP上。DSP/BIOS的一个主要功能是处理 ARM 核和DSP 核间的通信。 向更多大内核的发展将很可能会保留RTOS或OS。不过，小内核阻止或限制了采用RTOS的可能性。Intellasys的SEAforth 40C18芯片带有40个运行Forth的小型18位内核。指令很精简，每个字包含四条指令。 每个内核有64个字的 ROM和RAM，该芯片只能容纳10,000指令。当然，这只够装下一个程序，安装RTOS是不可能的。不过，整个芯片上有足够空间安装一个操作环境的特定部分。同样，适于该平台的应用常常是特定的。于是，由于硬件可处理内核之间通信和任务调度，因此RTOS类的支持并不需要。 资源管理 使RTOS脱颖而出的是其管理资源(包括时间和存储器)的能力。时序问题与中断响应时间有关，但资源管理时序问题也会出现。虽然中断解决了一系列时序问题，但各应用仍必须利用资源。 考虑存储器分配情况。许多实时应用不采用动态存储器分配，以确保存储器分配和回收时所产生的不同不会变成一个问题。需要动态存储器分配的应用常把存储器划分为实时和非实时。后者处理动态存储器分配。典型情况下，在使用前，实时部分必须被分配有足够的存储器。 在实时嵌入式应用中采用C和C++是因为存储器和其它资源的用法是显式的。实时任务需要避免采用C和C++。特别是，当存储器分配和回收更容易隐藏时采用C++是很困难的。 像Java和C#这样的语言带来的挑战更大，它们与生俱来地采用动态存储器分配。程序员可控制存储器分配和回收。在某些情况下，编程环境可以强化存储器分配和回收。 Java实时规范(RTSJ)定义了创建不需要垃圾回收的Java应用的方法。RTSJ是在Java框架内这样做的，从而使程序员在不被存储器分配限制的条件下享有Java的好处。 Sun和DDC-I都实现了RTSJ。DDC-I的实现支持x86和PowerPC平台。Aonix有一个称为PERC的类似平台。这些平台以实时、同时的垃圾回收为特征，从而使在不受存储器分配限制的情况下，在Java内编写实时应用成为可能。 但因系统必须允许线程为垃圾回收器进行转换，所以实时要求并非那么紧迫。另一方面，垃圾回收器将耗费时序资源，所以，只有实时任务方可保证满足一定的期限要求。快是好事，但及时才是RTOS的天条。 考察实时平台时，考虑之一是存储器分配对系统的整体影响。许多系统可工作在从不改变的静态分配环境，但更多的动态系统可从实时垃圾回收中获益。研究表明，垃圾回收的效益与确定的存储器分配是可比的。 围绕诸如Java和C#等虚拟机类型平台的另一个问题是对just-in-time(JIT)编译器的使用限制。基于这些系统的实时系统必须采用类似C和C++等所用的提前（ahead-of time，AOT）编译器。 设计师会因其更高的生产力、更低的出错率以及安全性等特点选用Java 或C#。所以，对制定一个称为 JSR-302的用于对安全有至高要求应用的Java规范就不足为奇了。 保护RTOS RTOS受到其运行的硬件平台的限制。可对缺少存储器保护的硬件加以保护，但安全级别会受到限制。但存储器和虚拟机可以更高水平的安全性支持引导。诸如SE Linux、Green Hills Integrity和 LynuxWorks LynxSecure Embedded Hypervisor以及 LynxOS-SE RTOS内的安全策略可比典型RTOS提供可靠得多的保护。但成本也高，所以开发者需对此进行权衡。 实时系统开发者不得不应对策略实现和边界问题。取决于信息的来所去处，安全支持会花很长时间。正是为此引入了分区系统，所以，可在边界采取安全措施且把应用的非实时部分放在这部分空间内。 可感知OS的调试器 当考虑选用操作系统时，对调试器的支持是个关键。这种支持体现在两个方面：内核和设备驱动器调试以及操作系统感知。 内核调试对设备驱动器的创建和支持以及内核强化很重要。在许多情况，为处理RTOS的内核，需要专用调试器。它也要求能理解内核环境以及应用环境。 OS感知可更深入地了解操作系统。支持方式可以是从提供有关OS服务状态的信息到调整任务调度等方方面面。同样，能感知OS的调试器可在停止其它应用或线程的同时允许其它应用或线程的运行。 《电子技术设计》网站版权所有，谢绝转载