嵌入式系统论文

嵌入式系统论文

姓名：陈东平

学号： 4091609

班级： 40916

专业: 电子信息工程

指导老师：李志华

嵌入式系统实时性方向的研究

摘要：本文叙述了嵌入式系统和嵌入式操作系统的概念，以及嵌入式实时系统的发展与问题和前景。文中重点介绍μC/OS-II和eCos的发展历史，并且对μC/OS-II与eCos进行比较；另外提出并进行了嵌入式实时系统的中断技术和一些问题的研究。

关键字：嵌入式系统实时性快速性操作系统μC/OS-II eCos 中断中断管理模式

引言：本文从嵌入式实时操作系统，实时系统的中断及其他问题方面对嵌入式实时系统进行研究与分析。

背景：随着后PC时代以及网络、通信技术时代的到来和芯片制造工艺的不断进步，大量的计算机专业人员进入了嵌入式应用领域：从民用的电视、手机等电路设备到军用的飞机、坦克等武器系统，到处都有嵌入式系统的身影。然而，有大量的嵌入式系统应用是以单片机的形式，应用在传统的电子技术领域中。因此，以计算机领域人员为主体的，远离对象系统的嵌入式系统的计算机工程应用模式，和以电子技术领域人员为主体，与对象系统紧耦合的电子技术应用模式产生了概念上的碰撞，使得嵌入式应用开发存在很大分歧。所以在嵌入式系统的应用开发中，采和嵌入式实时操作系统（简称RTOS）能够支持多任务，使得程序开发更加容易，便于维护，同时能够提高系统的稳定性和可靠性。

（一）嵌入式实时操作系统

1、嵌入式操作系统概述

嵌入式操作系统是一种支持嵌入式系统应用的操作系统软件。它是嵌入式系统（包括硬、软件系统）极为重要的组成部分，通常包括与硬件相关的底层驱动软件、系统内核、设备驱动接口、通信协议、图形界面、标准化浏览器Browser 等。嵌入式操作系统具有通用操作系统的基本特点，如能够有效管理越来越复杂的系统资源；能够把硬件虚拟化，使得开发人员从繁忙的驱动程序移植和维护中解脱出来；能够提供库函数、标准设备驱动程序以及工具集等。与通用操作系统相比较，嵌入式操作系统在系统实时高效性、硬件的相关依赖性、软件固态化以及应用的专用性等方面具有较为突出的特点。

嵌入式系统的出现至今已经有30多年的历史。纵观嵌入式技术的发展过程，大致经历了四个阶段。

（1）无操作系统的嵌入式算法阶段

这一阶段的嵌入式系统是以单芯片为核心的系统，具有与一些监测、伺服、指示设备相配合的功能。一般没有明显的操作系统支持，而是通过汇编语言编程对系统进行直接控制。主要特点是系统结构和功能都相对单一，针对性强，无操作系统支持，几乎没有用户接口。

（2）简单监控式的实时操作系统阶段

这一阶段的嵌入式系统主要以嵌入式式器为基础、以简单监控式操作系统为核心。系统的特点是：处理器种类繁多，通用性比较弱；开销小，效率高；一般配备系统仿真器，具有一定的兼容性和扩展性；用户界面不够友好，主要用来控制系统负载以及监控应用程序运行。

（3）通用的嵌入式实时操作系统阶段

以通用型嵌入式实时操作系统为标志的嵌入式系统，如VxWorks、pSos、Windows CE就是这一阶段的典型代表。这一阶段嵌入式系统的特点是：能运行在各种不同的微处理器上；具有强大的能用型操作系统的功能，如具备了文件和目录管理、多任务、设备驱动支持、网络支持、图形窗口以及用户界面等功能；具有丰富的API和嵌入式应用软件。

（4）以Internet为标志的嵌入式系统

伴随着通用型嵌入式实时操作系统的发展，面向Internet网络和特定应用的嵌入式操作系统正日益引起人们的重视，成为重要的发展方向。嵌入式系统与Internet的真正结合、嵌入式操作系统与应用设备的无缝结合代表着嵌入式操作系统发展的未来。

2、两种源码开放的RTOS

嵌入式实时操作系统有很多，如VxWorks、PalmOS、WindowsCE等。这些操作系统均属于商品化产品，价格昂贵且由于源泉代码不公开导致了诸如对设备的支持、应用软件的移植等一系列的问题；而开放源码的RTOS在成本和技术上有其特有的优势，在RTOS领域占有越来越重要的地位，本文将介绍μC/OS-II和eCos两种优秀的源码公开的实时操作系统，通过对它们各自的特点和性能进行分析和比较，给出相关的数据，为选择一种合适的RTOS提供参考。

（1）μC/OS-II

μC/OS-II的前射是μC/OS，最早出自于1992年美国嵌入式系统专家Jean https://www.360docs.net/doc/cd3638287.html,brosse在《嵌入式系统编程》杂志的5月和6月刊上刊登的文章连载，并把μC/OS的源码发布在该杂志的BBS上。当时就有500多人下载了这份源码。世界上数以千计的工程技术人员将μC/OS应用到了各个领域，如照相机业、发动机控制、网络接入设备、高速公路电话系统、ATM机和工业机器人等。许多大学用μC/OS作教材，用于实时系统教学。1998年，作者决定出版μC/OS的第二本书《μC/OS-II The Real Time Kernel》，并设立了正式的网站：www. ΜC/https://www.360docs.net/doc/cd3638287.html,，给μC/OS-II增加了一些新的功能，并且增加了约200页的解释。

μC/OS和μC/OS-II是专门为计算机的嵌入式应用设计的，绝大部分代码是用C语言编写的。CPU硬件相关部分是用汇编语言编写的、总量约200行的汇编语言部分被压缩到最低限度，为的是便于移植到任何一种其它的CPU上。许多移植的范例可以从网站上得到。用户只要有标准的ANSI的C交叉编译器，有汇编器、连接器等软件工具，就可以将μC/OS嵌入到开发的产品中。

μC/OS具有执行效率高、占用空间小、实时性能优良和可扩展性能等特点，最小内核可编译至2KB。μC/OS-II已经移植到了几乎所有知名的CPU上。

（2）eCos

eCos(embedded Configurable operating system)，即嵌入式可配置操作系统，最初起源于美国的Cygnus Solutions公司。Cygnus公司于1998年11月发布了第一个eCos版本eCos1.1，当时只支持有限的几种处理器结构。1999年11月，RedHat公司以6.74亿美元收购了Cygnus公司。在此后的几年里，eCos成为其嵌入式领域的关键产品，得到了迅速的发展。2002年，RedHat公司由于财务方面的原因，裁剪了eCos开发队伍，但并没有停止eCos的发展。RedHat公司随后宣称将继续支持eCos的发展，而由原eCos主要开发人员组建了eCos Centric 公司，并于2003年5月正式发布了eCos2.0。

虽然eCos是RedHat的产品，但是eCos并不是Linux或Linux的派生，eCos 弥补了Linux在嵌入式应用领域的不足。目前，一个最小配置的Linux内核大概有500KB，需要占用1.5MB的内存空间，这还不包括应用程序和其它所需的服务；eCos可以提供实时嵌入式应用所需的基本运行基件，而只占用几十KB或几百KB 的内存空间。eCOS是一个源码开放的可配置、可移植、无版税、面向深嵌入式应用的实时操作系统。从eCOS的名称可以看出，它最大的特点在于它是一个配置灵活的系统。ECOS的核心部分是由不同的组件组成的，包括内核、C语言库和底层运行包等。每个组件以能提供大量的可配置选项，利用eCOS提供的配置工具可以很方便地进行配置。通过不同的配置使得eCOS能够满足不同的嵌入式应用。

3、μC/OS-II与eCOS的比较

对于以上两种源泉码公开的实时操作系统，我们主要从以下几个方面进行比较。通过比较，能够为大家选择适合自己系统的RTOS提供参考。

（1）内核调度机制

RTOS内核的核心是调度器。当系统包含多个任务或多个线程时，必须使用调度器来决定当前执行哪一个任务或线程。调度器对线程的运行进行控制，并为线程提供一种同步机制。表1列出了这两种RTOS调度器（调度机制）的比较。

表1 调度器比较

调度方法

同优先级

调度

优先级数/

个

任务数量/

个

uC/OS-II

固定

优先级

抢占式

无

64

（8个保留）

56

C o s

位图

优先级

抢占式

无32 32 多级队列

优先级

抢占式

有32 无限奖券奖券法目前在测试中

μC/OS只支持固定优先级抢占式，不支持时间片轮转调度，调度方法简单、

实时性好，用法也简单；eCOS调度方法丰富，适应性好。当然，目前的eCOS只允许在其目标系统中使用一个单独的调度器，未来的版本将可以允许多个调度器协同工作。

（2）任务间同步、通信机制

RTOS的功能一般要通过若干任务和中断服务程序共同完成，任务与任务之间、任务与中断服务程序之间必须协调动作，互相配合，这就牵涉到任务间的同步与通信问题。表2为这两种操作系统同步与通信机制的比较。

表2 同步与通信机制的比较

uC/OS-II eCos

同步与通信机制

信号量、邮箱、消息

队列

互斥、条件变量、计数型信号量、邮箱和

事件标志

（3）任务切换时间和中断延迟时间

任务切换时间和中断延迟时间是评估RTOS性能的两个重要指标。任务切换时间可以反映出RTOS执行任务的速度，而中断延迟时间可以反映出RTOS对外界变化的反应速度。表3为这两种操作系统任务切换时间和中断延迟时间的比较。

表3 任务切换时间和中断延迟时间的比较

任务切换时间/us

中断延迟时间

/μs

测试环境

μC/OS-II 29.7～34.2 78.8 Intel80186(33MHz) eCos 15.84 19.2 MPC860A3(33MHz)

（4）对硬件的支持

μC/OS-II和eCOS支持当前流行的大部分嵌入式CPU，都具有很好的可移植特性。μC/OS-II支持从8位到32位的CPU；而eCOS可以在16位、32位和64位等不同体系结构之间移植。μC/OS-II和eCOS由于本身内核就很小，经过裁剪后的代码最小可以分别为小于2KB和10KB，所需的最小数据RAM空间可以为4KB和10KB，因此它们对硬件的要求很低，具有极高的经济性。

4、比较结果

通过比较可以看到：μC/OS-II相对eCOS来说，源代码最小很多，特别适合学习和研究。它最大的特点是小巧，适合应用在一些RAM和ROM有限的小型嵌入式系统中，如单片机系统。ECOS最大的特点是配置灵活，适合于用在一些商业级或工业级的嵌入式系统，如一些消费电子、汽车领域等等。总之，选用什么样的操作系统，要根据目标系统的硬件条件和用户应用程序的复杂度来确定。

（二）嵌入式实时系统中断管理技术的研究

1、嵌入式实时系统

嵌入式实时系统（Real-Time System）是一个能够在指定或者确定的时间内对外部事件作出响应的系统，其重要的特性是实时响应性。嵌入式实时系统对外部事件的响应一般都是通过中断来处理的，其对中断的处理方式，直接影响到系统的实时性能。所以说，嵌入式实时系统中断管理技术直接影响到系统的实时响应性能。

2、嵌入式内核的中断管理模式

2.1 简介

实时多任务操作系统是嵌入式应用开发的基础平台。早期的嵌入式实时应用软件直接在处理器上运行，没有RTOS支持，现在的大多嵌入式应用开发都需要嵌入式操作系统的支持。实际上，此时的嵌入式操作系统相当于一个通用而复杂的主控程序，为嵌入式应用软件提供更强大的开发平台和运行环境。因为嵌入式系统已经将处理器、中断、定时器、I/O等资源包装起来，用一系列的API提供给用户，应用程序可以不关注底层硬件，直接借用操作系统提供的功能进行开发，此时的嵌入式操作系统可以视为一个虚拟机。

随着嵌入式实时系统的发展，为了方便对中断的处理，系统内核常接管中断的处理，比如提供一些系统调用接口来安装用户的中断，提供统一的中断处理接口等。根据系统内核的可抢占或者非抢占性，系统内核接管中断又有两种不同处理模式。在非抢占式内核的中断处理模式中，当在中断处理过程中有高优先级任务就绪时，不会立即切换到高优先级的任务，必须等待中断处理完后返回到被中断的任务中，等待被中断的任务执行完后，再切换到高优先级任务。在抢占式内核的中断处理模式中，如果有高优先级任务就绪时，则立刻切换到高优先级的任务。

2.2 嵌入式内核接管中断的处理机制

嵌入式内核接管中断的处理机制主要包括两个部分：面向应用的编程接口部分和面向底层的处理部分。面向用户应用的编程接口的任务之一是供支持用户安装中断处理例程。面向底层处理部分可以分为两个部分：中断向量表部分和中断处理部分。中断向量表部分主要指中断向量表的定位和向量表中表项内容的形式，一般在嵌入式内核中都提供一个中断向量表，其表项的向量号应与处理器中所描述的向量对应；向量表表项的内容形式一般有两种形式。最常见的形式就是在具体的向量位置存储的是一些转移程序，转到具体的中断处理部分；另一种形式也就是中断向量位置存放具体的中断处理程序，此仅针对向量号之间彼此有一定的距离，此距离足以存放中断处理程序。面向底层部分的中断处理部分，是整个嵌入式内核中断管理的核心，在后面有详细的分析。对于嵌入式内核中断管理模式图中的中断处理部分，以Delta OS内核为例，详细说明其中断处理部分。

Delta OS内核中断处理部分采用了“统一接管”的思想，即Delta OS 为所有的外部中断都提供一个统一的入口_ISR_Handler。此入口的主要功能是保护中断现场，执行用户的中断服务程序，判断是否允许可抢占调度，中断现场的恢复等。

从Delta OS内核中断处理过程中，可看出嵌入式内核中一些专用的处理方式。

①在嵌入式内核中一般有两个堆栈：系统栈和任务栈。系统栈是系统为中断上下文处理而预留的堆栈；任务栈属于任务本身的私有堆栈，用来存储任务执行过程中一些临时变量等信息。因为中断上下文不隶属于任何任务的上下文中，所以嵌入式内核一般都有一个系统栈专门处理中断上下文的。当产生中断且非中断嵌套时，堆栈由被中断任务中的任务栈切换到系统栈；当在中断处理中又发生中断时，堆栈不再切换，仍用系统栈；当退出最外层中断时，堆栈又由系统栈切换到被中断的任务中的任务栈。

②一般嵌入式内核有两种形式：抢占式和非抢占式。为了更好地支持系统的实时性，很多嵌入式实时内核都是抢占式内核，如Vxworks、pSOS 等。从上面Delta OS 内核中断处理流程可知Delta OS是抢占式内核。因为在中断处理中，当检测到有高优先级任务就绪时，就会切换到高优先级任务里，而不是等到退出中断后，再进行任务调度。

③在嵌入式内核中，中断时机和调度时机直接影响到系统的实时性。关中断的时机一般在执行核心操作之前。核心操作包括对链表的操作，对核心数据项（如指示同步，反应重要信息状态）的修改等场合都须关中断。执行完相应的核心操作后，就可以开中断。开调度时机主要提供重新调度的机会，一般在执行操作系统核心调用前关调度，执行完后开调度。系统中开关中断与开关调度的关系大致如下：

开关中断的粒度比开关调度要深，要细。开关中断主要是为实时性提供各种可能的中断时机，允许响应外部中断。中断里也可以执行调度和系统调用，但中断的上下文与任务的上下文是不一样的，因此在中断里只能执行一些特定的系统调用。这些特定系统调用是不会引起调用阻塞的，不要试图在中断里执行获取信号量，执行I/O操作等这些很容易引起调用阻塞的系统调用。

3、中断管理模型

3.1 中断前－后段处理模型

在前面嵌入式内核中断管理模式分析中，嵌入式内核一般采用中断统一接管思想，在中断统一接管中调用用户的中断服务程序。中断管理模式中的中断处理部分又可以细化，如嵌入式Linux系统中关于中断管理机制中提出了“前半部”和“后半部”的处理思想。其实这种中断管理的思想把中断处理部分按照重要性分两部分，将必须要做的中断处理部分归为“前半部”，即这部分在中断处理部分实施；而将中断处理中可以延迟操作且影响不大的部分归为“后半部”，这部分在退出中断服务程序后实施。通过这样的中断管理思想减少的中断服务时间，为其它外部事件的中断响应提供了更多的时机。在实时内核中还有其它的中断处理机制，它们的思想都是尽量减少中断处理的时间。如在一些I/O处理部分，I/O 操作所引起的中断处理部分只做标记功能，即只设一个标志或者发一个消息说明外部中断来了，而具体的I/O传输操作放在中断外部实施。根据上面的分析，将前面的中断处理思想归结为：中断“前－后”段处理模型。

“中断前部”主要完成外部事件发生中断请求时，系统对其响应所完成的必要功能，如中断现场保护、数据预取和预放等；“置标”部分主要通知某个任务或者线程已有一个中断发生，且中断的前部已完成；“中断后部”并不是在中断服务程序里执行，而是由接收到标记或者通知的任务或者线程来完成的，主要是完成本应在中断服务里完成的后继工作。举个例子，当网络接口卡报告新的数据包到达时，“中断前部”主要将数据包送到协议层；“中断后部”完成对数据包的具体处理。

在此“中断前－后段处理模型”中，应该注意两个方面：

①如何划分“中断前部”和“中断后部”。基本的划分标准是，应该立即处理的和必要的功能部分放在“中断前部”完成，可以推迟处理或者可以在中断外处理的功能部分放在“中断后部”完成。

②“中断后部”何时执行，取决于用于完成“中断后部”功能的任务或者线程的优先级。如果要让中断的后继部分较快地执行，则可以通过提高获得标记的

任务或者线程的优先级。从极限角度思维，当获得标记的任务或者优先级很高时，在“中断前部”完成退出中断后，立即就执行获得标记的任务或者线程，这相当于获得标记的任务或者线程执行部分就在中断里执行。如果中断的后继部分并不要求较快的执行，则可以赋给获得标记的任务或者线程为普通的优先级。

3.2 单向量多中断处理映射技术

(1)问题的提出

在前面的嵌入式内核中断管理模式图中，中断向量表部分也属于模式图的一部分，不同嵌入式处理器体系中断向量的支持也不同。在PowerPC 8xx 系列的处理器中，所有外部中断对应的向量都是0x500。为了处理这种多个外部中断共用一个向量的情况，本节提出了单向量多中断处理技术。

此技术的思想如下：

当外设中断触发时，首先定位到实向量位置，调用中断统一接口函数，中断统一接口函数对外设中断触发的参数进行测试，寻找到其对应的虚向量，从而触发虚向量处的回调函数，从而实现多个外部中断通过同一的实向量到多个虚向量的映射，解决了单向量多中断处理的问题。

(2)实现方法

基于前面的分析，将单向量多中断处理映射技术运用于Delta OS 移植到PowerPC MPC860平台上。PowerPC MPC860处理器的外部中断向量号为0x500。设有n个外部设备分别为D1,D2,D3,…,Dn，这些外部设备中断触发时的中断标志分别为 PPC_D1,PPC_D2,PPC_D3,…,PPC_Dn；Delta OS 内核为这些外部设备分配的虚向量号分别为V_D1,V_D2,V_D3,…,V_Dn，在实现中分别取值：0x2000、0x2100、0x2200等，即每个虚向量号间距256个字节。在Delta OS内核中声明了一个全局虚向量表_ISR_VECTOR_TABLE，通过系统调delta_interrupt_catch，将用户的中断服务程序安装到指定的虚向量号处。Delta OS 用统一的中断接口函数_ISR_Handler 来处理外部中断。在模型实现中有两个重要的功能模块：用户中断安装模块和中断处理模块。下面分别用伪代码描述这两个模块的功能。

用户中断安装模块delta_interrupt_catch 的伪代码实现如下：

delta_interrupt_catch(vector, new_isr_handler,old_isr_handler) {①检查向量号的有效性②检查新中断服务程序的有效性

③保存旧的中断服务程序指针④安装用户指定的新中断服务程序

_ISR_VECTOR_TALBE[vector]=new_isr_handler}

外设中断触发时，中断处理模块_ISR_Handler的伪代码实现如下：

_ISR_Handler(void){

①中断现场的保护

②中断屏蔽位的设置

③外设中断标志的检测

switch ( 标志) {

case PPC_D1:F1=_ISR_VECTOR_TABLE[V_D1]且执行F1的功能

case PPC_D2:F2=_ISR_VECTOR_TABLE[V_D2]且执行F2的功能

case PPC_D3:F3=_ISR_VECTOR_TABLE[V_D3]且执行F3的功能

...

case PPC_Dn:Fn=_ISR_VECTOR_TABLE[V_Dn]且执行Fn的功能

default:执行系统默认的中断处理程序}

④中断屏蔽位的恢复

⑤根据调度标志进行调度

⑥中断现场的恢复}

此技术已成功解决了PowerPC MPC860中单向量多中断处理的问题，而且其实现并不影响嵌入式内核的体系，具有较好的移植性。

4、小结

以上内容主要研究了嵌入式实时系统中断管理技术，从硬件体系和系统管理两方面阐述了影响中断性能的因素，着重分析了嵌入式内核中断管理模式。在嵌入式内核中断管理中，归结出“中断前－后段处理”模型，并针对一些处理器的多中断共用一个向量的问题，引入了单向量多中断处理的映射技术，并给以实现，对提高嵌入式实时系统的实时性提供了一定的参考价值。

（三）嵌入式系统的实时性问题

嵌入式系统是嵌入到对象体系中的计算机应用系统，与对象系统交互，在实现对象系统某些任务过程时，对应用系统会提出响应时间的限定要求。由于应用系统中软件运行的时间耗费，常常不能满足限定的时间响应要求，由此而产生了嵌入式应用系统的实时性问题。

1、什么是电子系统的实时性

任何一个电子系统都可看成是一个激励-响应系统。每个特定的电子系统都有一个从激励输入到响应输出的时间，即激励-响应周期T，它表现为系统的响应能力。如果系统的响应能力T能满足嵌入对象所规定的响应时间ta要求，即T≤ta，这个系统便是实时的电子系统。

那么，什么是嵌入对象所要求的响应时间ta呢？通常，不论哪一种电子系统，实现对象体系的控制管理要求，这些控制管理通常都会有一定的时间限制。例如，一个振动监测系统，对振动波形的检测周期必须满足采样定理要求；饮料生产线上的计量、馐控制系统，必须在一个工位的移动周期里完成秤量、封口的控制输出；对于超市中使用的电子秤，在秤量时，希望能立即显示出重量和计价金额；我们日常使用的计算机，在敲击键盘时，也要求在显示屏上快速地出现键盘输入结果。因此，几乎所有的电子系统都有一个客观的响应时间ta要求。这就电子系统普遍存在的实时性问题，即要求T≤ta。

2、三类电子应用系统的实时性

ta是电子系统具体应用时，客观应用环境提出的具体响应时间要求；不同类型电子系统的激励-响应时间T的不同，形成不同的实时性问题。我们可以按

不同的激励-响应时间T的特点，将电子系统分为经典电子系统、通用计算机系统与嵌入式系统，来讨论不同类型的电子应用系统不同的实时性特点。

①经典电子系统：不含计算机的纯电子电路系统，例如，测量放大器、电子计数器、温度指示器（由ADC、译码器、LED显示器构成）等，电路的动态特性决定了系统响应能力T的大小。经典电子系统是一个激励-响应系统，从激励到响应的时间完全取决于电子在电路中的运动过程，因而，它具有极短的、相对固定不变的，从激励到响应的时间周期T。在大多数经典电子应用系统中，由电路的动态特性决定了T值的大小。一般情况下，应用系统的T远小于嵌入对象系统的响应（ta）要求，因此，在经典电子应用领域中，应用工程师的头脑中没有“实时性”名词的概念，而对一些极快速响应要求的应用系统，如振动测量系统，它的实时性要求常常反映为电路系统的“频率响应”要求。

②通用计算机系统：是一个人机交互的激励-运行-响应系统。它的激励-响应时间T表现为电路系统的激励-响应时间tc与软件运行时间ts，而电路系统的激励-响应时间与软件运行时间相比为高阶小量，因而软件运行时间形成了T 的主要成份，T=tc+ts≈ts。由于通用计算机系统只使用在人机交互环境中，对象（人）提出的响应时间ta要求，只是一个期望值（尽量快），而这种欲望一方面表现为永无止尽，另一方面又表现出现实的可容忍性。因此，通用计算机系统是一个非实时的电子系统，而快速性成为通用计算机系统发展的永恒主题。

③嵌入式系统：由于计算机的嵌入，嵌入式系统也是一个激励-运行-响应的电子系统。但是，它与嵌入对象体系交互时，要满足事件交互过程的响应要求。一方面，由于计算机的嵌入，嵌入式应用系统有十分可观的激励-响应时间ts，导致系统实时能力的降低；另一方面，由于嵌入对象体系的多样性、复杂性，不同的对象体系会提出不同的响应时间ta要求。因此，在嵌入式应用系统的具体设计中，必须考虑系统中每一个任务运行时，能否满足ts≤ta的要求，这就是嵌入式系统的实时性问题。

综上所述，经典电子系统应用中，没有显出实时性的概念，是因为电子系统的激励-响应时间T极短，绝大多数电子系统都能满足T≤ts要求；通用计算机系统应用中，没有实时性概念，是因为ta只有期望要求；而嵌入式系统应用中，

必须考虑实时性问题，是因为软件运行的时间耗费ts，会使系统的激励-响应时间T巨额增加，而不能满足嵌入对象系统提出的响应时间ta要求，现了嵌入式系统的实时性问题。

3、嵌入式系统的实时性分析

3.1 嵌入式系统实时性的出发点

嵌入式系统由于是嵌入到对象体系中的一个电子系统，与对象系统密切相关。而形形色色的对象系统会有不同的响应时间ta要求，如动态信号的采集系统、生产线的控制单元等，有严格的响应时间要求；超市的秤重、计量、收银机只要求有尽快的响应时间；在同样的动态信号采集系统中系统的响应时间与信号的动态特性有关。这些不同的嵌入式应用系统的不同响应要求，表现了嵌入对象响应要求（ta）的多样性。

嵌入式应用系统的激励-运行-响应特性，形成了以软件运行时间ts为主要内容的系统响应能力T。而软件运行时间ts与指令速度、编程技巧、程序优化等有关，是一个在应用系统设计中可以改变的参数，它表现了嵌入式应用系统实时能力的可变更性。

因此，ta的多样性要求与响应时间ts的可调整性，是嵌入式系统的实时性分析的基本出发点。根据嵌入对象ta的不同要求，调整、变更ts大小，以实现ts的最佳化，是嵌入式系统实时性设计的一项重要内容。

3.2 嵌入式系统的实时性分析

（1）实时性与快速性

嵌入式系统的实时性不是一个快速性概念，而是一个等式概念，即能否满足ts≤ta的要求。因而，快速系统不一定能满足系统的实时性要求，而某些情况下满足实时性要求时，系统的运行速度并不高。例如，满足温度采集实时性要求的嵌入式系统，运行速度并不高；而许多高速运行的系统，未必能满足冲击振动的信号采集的实时性要求。快速性只反映了系统的实时能力而已。

（2）系统的最佳实时

快速性是系统实时能力的表现。当系统不能满足实时性要求时，必须提高系统的运行速度，然而，运行速度的提高必然带来系统的一些负面效应，如导致系统功耗加大、电磁兼容性下降。因此，在设计一个具体的嵌入式系统时，在保证能满足实时性要求的条件下，应使系统的运行速度降到最低，以满足系统在功耗、可靠性、电磁兼容性方面获得最佳的综合品质。

（3）系统的实时性分配

在一个嵌入式应用系统中，有许多过程环节。例如，一个典型的智能仪表就有信号采集、数据处理、结果显示、键盘输入等过程。这些过程往往是在不同的时间与空间上进行，而且不同过程的实时性要求是不同的。键盘输入、结果显示是与人交互的，要满足人机交互的实时性要求；信号采集与对象系统领带的动态性密切相在，必须满足由动态信号采集的实时性要求；而数据处理则会形成从动态信号采集到结果显示的时间延迟，影响到结果显示的实时性要求。因此一个优秀的实时系统设计，必须研究系统中的每一个过程环节，满足每一个过程环节和整个系统的最佳实时要求。

3．3 实时系统的动态误差

当我们研究嵌入式应用系统的实时性时，与对象系统相关的过程，必然是一个动态过程，否则便不存在实时性问题。对于任何动态过程，由于时间的滞后，都不可能完成重现原过程，这之间的差异便是动态过程的动态误差。例如，对于一个动态信号的数据进行采集时，在时间点t上启动采集命令，由于要执行一系列控制指令，产生Δtm滞后；另外，A/D转换器有一个转换过程，产生Δtc滞后。由于这些时间滞后，致使在时间点t上采集的数据，实际上是时间点t+Δtm+Δtc上的信号数据，两者之差便是系统中数据采集的动态误差。在A/D转换中，常常会加入一个采样/保持电路，就是为了在Δtc窗口上，使动态信号值保持在Δtc的初始时间点上不变，便利信号值的变化只滞后t+Δtm，以减少动态误差。

由于系统在动态过程中控制的滞后，形成了某个任务环节上的动态误差，这个动态误差在对象系统的具体动态过程确定后，与动态过程的变化速率有关。在对象系统一个具体的动态过程确定之后，应根据对象动态过程的变化率和允许的

动态误差值，估算出系统的允许滞后时间，这一时间就是应用系统中实现该动态过程实时性要求的响应时间ta。例如，在某一个动态电压信号数据采集中，信号的最大变化速率为0.1V/ms，只考虑采集控制滞后的误差因素时，如该信号电压给定的误差应为1mV，就可以最粗略地估算出满足实练数据采集任务的响应时间ta要求，ta=1mV/(100mV/1ms)=0.01ms。如果系统的数据采集时间耗费ts能满足ts≤ta这一要求，系统就能实现数据的实时采集。

4、嵌入式应用系统的实时性设计

4.1 系统的实时性问题分析

由于嵌入式系统是嵌入到对象体系中的专用计算机应用系统，实现对象体系的智能化控制，因此，都存在着对象体系对控制过程的时间要求，与嵌入式系统能否满足这一要求的实时性问题。在很多情况下，应用系统设计中没有涉及实时性设计，这是因为目前计算机已有可观的运行速度，在大多数应用系统中，都能满足T≈ts≤ta，因此，在一般应用系统设计中，实时性设计并不突出。

通常，由于嵌入式系统实现的是对象系统的全面智能化控制，系统中会有许多相关的任务与过程。例如，一个数据采集系统不只是要实现对对象系统环境参数的采集，还要对采得的信号数据进行处理，对处理结果进行存储、显示，或实现对外部环境的控制输出，在这些进程中，还可能有人工的外界干预等。因此，一个实时的嵌入式应用系统，应该在所有的过程中都能满足T≈ts≤ta要求。由于系统中每个过程所要求的响应时间ta不同，例如，对对象系统环境参数采集时，时间响应要求决定于被采集参数的动态特性；控制输出时则取决了被控对象的控制品质要求；信号数据处理、存储，虽然表现为快速响应的期望要求，但占用了从激励输入到响应输出的中间环节。对这些环节的响应时间要求，必须纳入相关的任务中考虑。

因此，系统的实时性设计首先体现在应用系统总体设计中，要在总体设计中列出有实时性要求的任务，以及这些任务所要求的响应时间ta（如果所有任务的响应时间要求都是期望要求，则该应用系统不是一个实时的应用系统），然后考虑应用系统在实现这些任务时，必须耗费的时间ts。如果应用系统中所有

的任务过程都能满足ts≤ta，则该应用系统是一个本质性实时系统。由于在考虑每个任务所必须耗费的时间ts时，与使用的程序设计语言（是汇编还是高级语言）、程序应用环境（是否使用操作系统）、硬件环境（时钟系统、指令系统、CPU时序等）有关，因此本质性实时系统的实时性与所系统使用的软硬件平台有关。

如果系统中有一些任务无法满足ts≤ta要求，则必须进行系统的实时性设计。

4.2 嵌入式系统的实时性设计

根据系统的T≈ts≤ta要求，在一个具体的有实时性要求的应用系统中，当系统的任务确定以后，就可以估算出每个任务的时间响应要求ta，在不考虑电路系统的中动态过程时，嵌入式系统的实时性设计的中心任务是通过软、硬件设计加快任务的运行过程，以达到ts≤ta要求。然而，加快系统的运行速度全带来其它问题，应在实时性设计中一并考虑。

嵌入式系统的应用领域十分广泛，并不是所有的应用系统都要求是实时系统，只有当系统中对任务有严格时间限定时，才有系统的实时性问题。例如，对打印机这样一个嵌入式应用系统，人们并没有严格的时间限定，只有一个“尽可能快的”期望要求，因此，这样的系统不是实时系统。

嵌入式系统的实时性设计通常会有以下几种情况。

①本质性实时系统。在这一类应用系统中，系统总体及任务的时限要求ta都不高，常规的软硬件技术都能满足ts≤ta要求。因此，这种应用系统往往不必要考虑系统的实时性设计。例如，一个温度测量系统，由于温度的大惯量特性，满足一定动态误差条件下的温度采集、数据处理、实时显示与打印的响应时间要求ta值很大，不必采取任何特殊的实时设计方法，就能满足ts≤ta要求，因此，它是一个本质性实时系统。

②通过实时性设计实现的实时系统。这种嵌入式系统在常规设计下，无法满足实时性要求，但通过实时性设计，可以满足实时性要求的系统。例如，一个仓储监测系统，要巡回监测100点的入侵事件。从应用要求的可靠性出发，要

求系统对于任何一点入侵事件的响应速度（ta）不得大于1s；而系统对单个入侵事件的采集、处理、输出控制的实际激励-响应时间为0.2s。但在常规的巡回监测方式下，对某一点监测的时间间隔为ts=0.2×100=20s。ts远大于ta,是一个非实时系统。但这个系统的实时性是可以改变的，如果将每个监测点入侵事件的输入激励的查询方式变为中断输入方式，使某一监测点的激励-响应的操作处理时间（ts）降到0.25s以内，满足ts≤ta要求，系统能实时地处理任何一个监测点上入侵事件，而成为一个实时监测系统。

③通过实时性设计实现的系统的任务实时。在系统有实时要求的情况下，系统能满足实时性要求时，系统设计是成功的；但系统不能满足实时性要求时，我们常常会放弃它。例如，卫星发射时，控制大厅墙面上，显示卫星轨迹的卫星运行监测系统，实时地采集卫星运行参数，经处理后，在大屏幕上实时地显示出来，这是一个实时系统。但是，无法实现卫星发射过程中意外事件的实时显示。只能当卫星发射出现意外事故（如运载火箭爆炸）时，出现卫星轨迹的中断。但是，作为弥补，我们可以实现一个意外事故的数据采集系统，高速、实时地采集与存储火箭运行状态参数，并在火箭失事瞬间，将数据发回控制中心，实现意外事故监测系统中，事故数据采集任务的实时性。对于一个冲击振动的谱分析系统，要求有振动波形的采集、时域信号的频谱分析、频谱的图形显示等。由于冲击振动的信号过程时间极短，谱分析处理耗时过多，不可能实现整个系统的实时性（振动频谱的实时显示）要求，这时可以考虑将整个系统的操作过程分成一些独立的部分。例如，将冲击振动谱分析系统的全部操作分成冲击振动信号的波形采集、数据存储与波形信号的谱分析及其后续操作的两个独立的部分，实现振动信号采集、存储关键任务的实时性要求。

4.3 关于嵌入式操作系统

在系统的实时性设计中，核心的问题是降低软件运行时间。除了普遍的提高CPU指令运行速度、采用高速I/O口、计数器的捕获/比较、多机并行操作等软、硬件措施外，就是程序设计技巧。而在系统程序中使用操作系统支持时，由于操作系统介入操作管理带来的额外开销，以及对任务的灵活调度管理，成为系统实时性设计的重要问题。

嵌入式操作系统使用在嵌入式应用系统中。与通用操作系统相比，嵌入式操作系统有许多特点，如可靠性、可裁剪性、“实时性”等。前两者是嵌入式应用环境所要求的。，而“实时性”则是为了满足系统实时性要求的内容。在一些文章中提到某些嵌入式操作系统时，常常冠以“实时操作系统”，但它只是表现为该操作系统具有较好的实时能力。在没有置身在一个具体嵌入式应用系统中时，不存在实时性结论。不同的嵌入式操作系统比较时，可以有实时能力上的不同。任何一个嵌入式操作系统都应有满足系统实时性设计的内容（表现为任务的快速调度、快速运行等），实时能力强的嵌入式操作系统能更容易地实现应用系统的实时性。

5、小结

嵌入式系统的实时性设计要根据具体的系统，具体分析、具体设计，并不是所有的嵌入式系统都有实时性要求。嵌入式系统的实时性与快速性有关，在满足ts≤ta时并不是越快越好。考虑到系统的功耗及可靠性，应在满足ts≤ta 条件下，越慢越好。

总结：随着嵌入式系统运行速度，以及操作系统实时能力的提高，本质实时性的应用系统会越来越多。但是，嵌入式系统以及操作系统的实时性会产生各种各样的问题，这就需要我们更加认真地学习该系统的中断技术以及扩展自身对于嵌入式系统基于linux系统核心的理解与应用！