• 普适计算中的定位感知系统

     摘要:普适计算的目的是为了使计算机更好地为人类服务,提高人们的生活质量。普适计算中的定位感知系统是普适计算研究中的核心部分之一。如何确定室内用户的动态位置信息,如何主动向用户提供各种所需的信息,都是本文的研究话题。文章最后给出一种自行设计的普适计算室内定位感知系统的最小功能模型。     关键词:普适计算 定位系统 位置系统 定位感知系统 引 言 ??随着计算机计算能力不断呈指数型的增长以及硬件的微型化,各种计算型的小器件应运而生。由于其重量和体积都足够小,用户能够随身携带,因而被应用在各个领域。 ??Mark Weiser 在《21世纪的计算机》一文中这样描述:计算机硬件技术的飞速发展以及无线通信技术的不断成熟,造就了新一代普适计算(Ubiquitous Computing)的典范。普适计算设想这样一种计算环境:人们生活在一个充满各种各样的计算型小器件当中,这些器件通过足够带宽和速度的有线或无线网络完全互连。网络家电便属于这种计算机系统中的一个功能单元,它们能够积极有效地为用户提供各种所需的信息。 ??普适计算的特点是服务设备无处不在,并已完全融入人们的日常生活中,即这种计算机系统对用户是完全透明的,计算机技术已在人们生活中得到了充分的应用。普适计算的目的是充分发挥计算机系统的功能,利用它们更好地为人们服务,极大地提高人们的生活质量。 1 定位感知系统 ??定位感知系统是普适计算环境中的重要组成部分之一。在不考虑用户个人隐私问题的前提下,如何动态获取用户的位置信息,而且得到的位置信息必须能够达到一定的精确度,一般误差控制在几cm以内;如何为用户积极主动地提供各种所需服务,这些都是定位感知系统必须能够实现的功能。现在世界上已有的成熟系统大都只能实现简单的定位功能,这些系统一般都遵循传统的请求-应答模式。 ??在请求-应答模式中,用户要得到所需信息必须先向服务系统提出请求,系统响应后给出回复,按照要求的格式提供信息。我们称这种模式为被动模式。采用被动模式的系统无法满足用户动态信息的需求,无法积极智能地主动提供服务,而且同一时间服务的对象一般只能有一个。 ??定位感知系统必须采用主动模式系统,它能够同时为多个用户提供服务。系统能够根据自己取得的信息主动向用户进行广播,说明自己能够提供的服务;用户按照自己的所需,获取自己的信息。主动模式系统其最小规模必须拥有两个功能系统:定位系统(Locating System)和位置系统(Location System),我们称之为L2系统。     1.1 L2系统 ??首先必须正确区分定位系统与位置系统。它们之间的核心区别在于,定位系统的重点在于获取对象所在的位置信息,而位置系统则侧重于获取特定位置上的对象集。为了更好地说明问题,我们应用数学上映射的概念加以描述。 假设有位置集L={l1,l2,l3},有对象集O={o1,o2,o3,o4,o5,o6},对象o1、o2、o3在位置l1,对象o4、o5在位置l2,对象o6在位置l3。我们用映射λ:O→L来表示定位系统实现的功能,用映射:L→P(O)表示位置系统实现的功能,则有图1所示的映射图。 由映射图可知有如下等式成立: λ(o1)=λ(o2)λ(o3)= l1 λ(o4)=λ(o5)= l2 λ(o6)= l3 ω (l1) = P1 ={ o1,o2,o3} ω(l2) = P2 ={ o4,o5} ω(l3) = P3 ={ o6} ??目前应用比较成熟的相关系统主要有:3GPP(the 3rd Generation Partnership Project)工作组实施的GMLC(Gateway Mobile Location Center)系统,由AT&T实验室开发的Bat系统,由康斯坦斯大学开发的Mobile Shadow系统。 ??GMLC系统属于被动模式的定位系统,通过GSM系统,利用三角算法来定位对象。每一用户都配备一个蜂窝电话,并向GSM网络注册申请一个唯一的网络数据服务(NDS)号码,系统通过这一号码进行定位服务。此技术用映射关系表示为λ(NDS)=l。 ??AT&T实验室开发的Bat系统是一种主动模式的定位系统。其核心思想是利用一种无线设备Bat发射超声波脉冲来实时测量室内对象的三维位置。其功能用映射关系表示为λ(Bat)=l。这一系统的定位技术可用来为普适计算中的室内定位感知系统服务,但其缺陷是使用了有线网络而并非适用于普适计算的无线网络。 ??康斯坦斯大学开发的Mobile Shadow系统是一种主动模式的位置系统。它的基本思想是为每一个用户设置一个唯一的用户代理,用户代理利用WLAN单元来实现获取本地对象集P的功能,用映射关系表示为(WLAN 单元)= P。但是,实现这一系统的协议所使用的是专门为移动用户设计的移动代码技术。 ??普适计算中的定位感知系统必须是定位系统与位置系统两者的紧密结合。正如下面将要提出的简单模型一样,室内的用户每移动到一个新的位置,系统必须能够实时进行精确定位,然后确定这一特定位置的对象集信息。利用这些信息,定位感知系统能够积极主动地向用户广播所能提供的各种信息,从而使用户能够有效地选择自己所需要的信息。     1.2 几种可行的定位技术 ??① 低频射频。低频传感器一般工作在一些特定的频率,如418MHz、433MHz、900MHz等。采用低频射频技术的系统中必须存在射频发射器和射频接收器,系统利用信号的到达时差(TDOA)或者信号的长度来测量对象的三角位置。但是这种技术的定位误差太大,一般为1~3m,因此不能为普适计算所用。 ??② 红外线。采用红外线定位技术的系统,一般通过移动设备在一个预定的时间间隔内发射红外波来实现。系统通过接收这些红外波并计算到达时间(TOA)来测量对象的位置,但其缺点是容易受到太阳光的干扰,而且精确度不高,不能满足室内定位感知系统的要求。 ??③ 全球定位系统(GPS)。GPS是近几年来得到广泛应用的定位系统,它利用卫星系统来实现定位功能。但是一旦在室内,卫星信号便会丢失,GPS系统就失去了功能,无法进行定位服务;而且其定位的误差一般达到10m,因此无法被应用到模型中去。 ??④ 超声波。超声波传感器一般工作在40~130kHz的范围内,它利用信号的到达时间TOA进行精确的距离计算,系统利用这些距离信息进行三边测量运算。超声波接收器测量其与发射器的距离时使用一个预定的频率。通过使用多个接收器,一般一个二维定位测量必须最少有2个,最好用4个或更多个,才可能得出一个比较精确的结果。主要是因为超声波信号容易受到高频信号的干扰,而且容易因为反射而得到错误结果。在AT&T实验室的Bat系统中,定位所产生的误差能够被控制在3cm以内;因此,超声波技术是一项适合普适计算的技术。 2 一种普适计算定位感知系统模型 ??考虑到目前世界上已有的系统一般都是单一的定位系统或者位置系统,所实现的服务功能比较单一,都不太适于普适计算。     2.1 系统模型体系结构 ??下面一种我们自行设计的定位感知系统模型具有如下特点: ◇实现了最小功能的简单定位感知系统模型; ◇将定位系统与位置系统结合在一个体系结构中; ◇在不考虑误差的情况下,能够利用三角计算实时确定对象的二维位置及行动方向; ◇系统能够积极主动为用户提供信息服务; ??图2是这一模型的简单体系结构图。 ??定位系统是本模型的重点之一,系统利用它来精确定位每一个对象。这里采用的是改进的Bat系统,每一个室内用户都携带两个手掌大小的无线设备Bat。这种小器件配有一个蜂鸣器,能够发射超声波脉冲;在室内的天花板上安装有传感器,能够接收超声波脉冲,并能测量超声波脉冲信号的到达时间(TOA);传感器随即将TOA数据通过WLAN传送给控制处理器,控制处理器通过这些数据测量出用户的三维位置信息。基于这一思想,我们考虑这样一个实验环境:一个矩形的大厅,用户在大厅内活动,厅内安置各种智能服务设备,如报时器、报警器、语音提示器、摄像机等;但也应有一些障碍设备,比如带电的按钮、高温禁区等。每个用户的双肩都装有两个Bat,能够发射超声波信号,在大厅天花板的4个角落各安置一个超声波接收器。考虑到接收器的接收能力以及误差的因素,大厅的长与宽应在一个限度以内,如图3所示。 ??在二维位置及方向的测量中,我们选择离对象最近的两个超声波接收器所接收的距离信息,不妨设A1、A2离同一用户肩上同一Bat B1较近,测得距离分别为L1、L2,A1与A2相距L3,平面坐标如图4所示。 ??由图4可知,B1点的坐标可由三角公式算出: ??x = (L12+L32-L22)/ 2 L3 y 2 = L22-x2 ??于是得出Bat B1的坐标位置(x,y),同理可以算出另一Bat B2的位置,由B1与B2的动态位置信息即可以测出对象的行动方向。定位系统获得这些位置信息后,立即向系统控制中心传送。 ??系统控制中心是整个系统的控制管理中心,它负责将位置信息或者对象集信息向事务处理中心传送,将位置信息向位置系统传送。它必须能够实时处理大量的各种信息,并进行分析检测。 ??事务处理中心是整个系统的服务发送者与处理单元。它通过接收系统控制中心传来的各种信息,或者响应用户的服务请求,或者主动向用户广播各种有用信息,比如语音提示、智能报警等。 ??通信环境为所有部件的信息传送提供支持,在这里我们采用的是WLAN技术,这是符合网络未来发展趋势的一种有效的技术。对于协议类型,我们暂时考虑使用802.11系列协议中的一种。 ??位置系统也是本模型的重点,它的功能是实时获取特定位置的对象集信息,并将信息向系统控制中心传送。模型中我们采用了一种移动代理(Mobile Client)技术,其核心思想是:为大厅内的每一个用户配备一个用户代理,用户通过代理与本地其它对象,包括其它用户和一些设备,通过通信环境部件进行交互。当位置系统获得系统控制中心传送的用户位置信息后,立即启用其用户代理。此用户代理随着与这一位置的WLAN单元进行交互,从而来确定用户所在位置的对象集信息P,其功能用映射关系表示为:( WLAN单元)= P。    2.2 模拟实验的可能误差分析 ??考虑到普适计算所要实现的功能,应用本模型所进行的模拟实验必须达到相当的精确度才能满足准确定位的要求。在上面提到的模拟实验环境中,可能影响定位结果的误差因素一般有:实验环境、时钟频率、超声波的反射等。 ??实验环境误差的产生主要是由于超声波的易被干扰性。影响的主要因素是噪声的干扰,它导致超声波信号之间的碰撞。这种噪声同系统具有相同的频率,从而对实验中的超声波信号产生干扰或碰撞,导致正确信号的消散或是反射的产生。这些可能的噪声有收音机的无线波、钥匙的碰撞声或者击掌声等。解决的办法是将环境进一步智能化,如将收音机的功能融入系统中,不需人的接收;取消利用钥匙来开关门等。 ??时钟频率误差是在石英钟之间同步产生的,每个超声波接收器都利用时钟与其它接收器同步,才能测量它们与Bat之间的距离。这种误差的大小与距离呈线性关系:距离越远,误差越大。我们可以通过多次实验对误差进行测量,进而对误差定性,尽量减小误差大小。 ??反射误差是实验中可能遇见的最主要的误差。它主要因为超声波信号在发射途中碰上其它物体而导致反射的产生,从而将错误信号传送至接收器导致错误结果。这种误差与距离并非线性关系,因而无法定性;但我们可以根据测量的数据排除一些错误信息。它们与正常数据相差太大,主要是因为它们经过多次反射或不在接收器的接收范围内。改进的办法是,除了增强接收器的接收强度外,还可以将Bat置于用户头顶或者调整接收器的角度来 减少反射的产生。     2.3 模型的总结 ??本模型在将定位系统与位置系统结合的基础上,提出了一种普适计算中定位感知系统的雏形,并实现了系统所要求的最小功能。在以后的工作中,我们将进一步完善模型中的功能部件,并对实验中的误差因素做进一步检测。 结 语 ??由于普适计算广阔的应用前景,有越来越多的研究人员已经加入了这一行列。在他们的努力下,许多困扰普适计算发展的技术问题已经取得突破性进展,比如各种嵌入式小器件的发明与应用,各种定位技术的设计与改进。本文在此基础上提出了一种普适计算中定位感知系统的雏形,目的在于对今后的研究起到一种抛砖引玉的作用。由于普适计算是一个浩大的工程,还有许多技术难题有待解决,其中的定位感知系统就是一个重点工程,比如L2系统的更加有效的结合问题,室内无线网络通信的协议问题等。我们还有大量的工作要做;但我们应该相信,在不久的将来,人类一定会真正走进普适计算的世界。

    时间:2004-12-09 关键词: 设计教程

  • 基于Rhapsody和VxWorks的自动取款机系统

    摘要:介绍如何运用UML设计简单的自动取款机系统模型并在操作系统VxWorks上实现它:首先,介绍如何运用基于UML的嵌入式实时应用软件开发环境Rhapsody设计和实现自动取款机系统的模型,以使它能独立于实际的硬件和使用的操作系统;然后详细介绍上述模型如何在实时多任务操作系统VxWorks上实现。     关键词:Rhapsody VxWorks 自动取款机 引 言   随着嵌入式应用的不断增长,嵌入式系统需求的复杂性、不确定性不断提高,系统规模也逐步扩大;而产品的研发周期又在很快地缩短,给嵌入式应用软件的开发带来了新的挑战。同时,嵌入式软件的开发者必须面对由于芯片性能的增长、嵌入式操作系统平台等技术方面不断变化所带来的各种压力。嵌入式软件开发环境的发展,使一直“深埋”于系统的嵌入式应用软件变得开放而易于开发,从而促进了嵌入式技术的广泛应用。 1 基于UML的嵌入式软件开发环境结构 ??图1所示为一种支持基于UML(Unified Modeling Language,统一建模语言)的迭代式开发方法的开发环境的结构,虚框部分为基于UML的软件开发环境。 ??系统分析和设计用UML来描述,对系统建模;实现过程利用代码自动生成技术来实现;测试过程将依赖于生成的代码,通过在代码中拆装一些用于支持模型调试的调试信息来实现;而代码的编译、链接则采用目标系统的操作系统开发环境来完成,代码的运行与源程序级的调试仍然采用一般的嵌入式软件调试环境。 ??Rhapsody是一个基于UML的面向嵌入式实时应用开发的集成、可视化环境。软件开发者可以在这个环境里进行分析、设计、实现及验证。Rhapsody支持基于模型的调试;提供专门为实时嵌入式应用设计的可执行的框架,可以产生基于VxWorks、POS、OSE等多种操作系统的C语言、C++语言、Java语言的源程序。本文所给出的自动取款机系统的模型正是基于Rhapsody设计的。 2 自动取款机系统模型的设计     2.1 需求分析 ??我们设计的自动取款机系统要满足如下要求: ??在自动取款机系统中,当顾客在自动取款机操作面板上插入信用卡并输入密码和现金支取数额(每次最多只能取一千元)后,由自动取款机读取卡上的内容,并把相应信息传送到银行。银行把自动取款机送来的信息与银行帐号上的信息进行比较,如果两者一致,则银行传送确认信息到自动取款机,由自动取款机输出现金,然后顾客取出卡和现金;如果两者不一致,则要求顾客再次输入密码和现金支取数额,然后重复上述操作;若密码输入三次不正确,自动取款机就会吞掉信用卡,顾客就不能取出信用卡和现金。??该自动取款机系统包括1个键盘(10个数字键、ENTER键和CANCEL键)、1个LCD液晶显示屏、1个插卡孔和1个现金出口;通过双绞线与银行中的电脑进行串行通信。该自动取款机系统不包括银行中的电脑,只是通过软件与银行中的上位机进行串行通信。     2.2 可视化建模 ??建模是面向对象分析和设计的核心,也是分析和设计过程中最基本和最关键的活动之一。UML不仅适用于以面向对象技术描述的任何类型的系统,而且适用于系统开发的不同阶段。根据开发过程中不同阶段的具体要求,利用UML不同类型的图来描述系统的各种静态结构模型和动态行为模型。下面介绍如何利用基于UML的面向嵌入式实时应用开发的集成可视化环境Rhapsody创建自动取款机系统的模型。图3 取出现金的黑匣子场景    第一步:根据要求建立用例图。 ??图2所示为用例图。图中给出了自动取款机系统的主要用途,并表明由谁使用自动取款机系统。有一个主要成员——顾客。一个用例图应该具有这样的系统功能:对操作者而言,它返回可观察的结果但并不显示系统的内在结构。 ??自动取款机系统的主要用途是“取出现金”用例。顾客参与其中的两个实例是“输入密码”和“取出现金”。这两个实例都包含了另一个用例“读取卡上内容并验证”。对每一个用例而言,我们都可以增加文本描述。假如需要的话,这些用例能够被细化成另一张更多用例的图。这些用例并没有显示任何内在的结构,仅是一个功能性的视图。     第二步:设计黑匣子场景。 ??建立了一个用例图后,下一步便是细化用例,即设计一些黑匣子场景。这些黑匣子场景的主要作用是表明模型和对象之间的相互关系。把整个系统看作一个整体,对 “取出现金” 用例,我们细化为图3所示的场景。(由于每次最多只能取一千元,所以最多只需要按键4次。) ??图3所示的场景能被MSD(消息序列表)捕获,用来描述在顾客和自动取款机系统之间的通信行为。当创建这样的图表时,关于系统的更多细节被隐藏了;同时,这些场景帮助我们更好地理解使用者如何使用报警系统以及需要做哪些事情。总而言之,每一用例都有很多的场景需要捕获,每一个场景都是用例的一个有效的实例。    第三步:设计子系统图。 ??下一步是如何把模型分割成子系统。在UML中,一个子系统作为一个封装显示,即主要是一个类的集合。图4的子系统图表明自动取款机系统已经被分解成两个基本的部分:自动柜员机封装(AtmerPkg)和硬件封装(HardharePkg)。同时也表明:自动柜员机封装是完全独立于实际的硬件和硬件封装的,并且实现了Ihardware接口能够用于连接自动柜员机封装。接口类Ihardware描述了对自动柜员机封装的所有必需的操作,实现了应用与硬件环境的隔离。 ??一旦在自动柜员机封装和硬件封装之间定义了接口类,每一个子系统就能同步和独立地细化为更多的子系统。每一个子系统都知道它和其它子系统之间的接口。例如,我们可以开始分析自动柜员机子系统图,而不需要知道关于硬件的更多情况。     第四步:设计对象模型图。 ??对自动柜员机封装而言,我们设想有一个AtmerController类,其中包含Keypad类、Card类、LCD类和Cash类,这些类表示如图5所示。??图5表明:AtmerController类作为一个聚合类,包含了其它类的实例。我们也能看出,我们能选择显示“Keypad”类的不同的操作和属性。在上面的例子中,假如一个实例被AtmerControlle类创建,那么它将创建Keypad类的一个实例theKeypad、LCD类的一个实例theLCD、Cash类的一个实例theCash以及Card类的一个实例theCard。假如AtmerController类的实例被删除,这些包含的实例也同时被删除。 ??Ihardware类也有一些纯虚函数,所以为了测试AtmerController类,必须忽略这些操作。图6表示:ATM包含了AtmerController类的一个实例和从Ihardware类继承并忽略了其操作的Hw类的一个实例。     第五步:生成白匣子场景。 ??生成了一个新类AtmerController后,就可以开始为每一个黑匣子场景生成白匣子场景。消息序列表将用于获取以上不同场景的类的实例之间的通信行为。例如,图7消息序列描述了顾客输入支取现金数额并取出现金的场景。 ??消息通常对应于对象模型中操作和操作的返回值。消息值对应于类的属性或是类操作的返回值。消息可以是同步的,也可以是异步的。从图中可以看出,这些类都有动态行为:它们正在处理定时事件;调用其它类的操作;接受事件。对UML来说,这些动态行为都可以用一个状态图来表示。     第六步:创建状态图。 ??以顾客输入密码过程为例,创建状态图,如图8所示。通常,当一个问题很复杂时,它往往被分解成一些简单的问题,这也正是对顾客输入密码过程要做的事情。图8所示的状态图描述了顾客输入密码过程中的行为。图7 顾客输入支取数据并取出现金的白匣子场景    2.3 属性、操作和事件 ??属性来源于需求文档中定义的数据,应该简单,不考虑设计和实现的细节。每个类都可能有定义在其上的事件和操作。事件对应于明确的瞬时发生的影响类的动态行为。操作对应于类的服务和功能。Rhapsody中有3种事件。 ① 信号事件:对应于实例间的异步通信。 ② 时间事件:这种事件在进入一个状态并且经过一个指定的时间后触发。 ③ 触发操作:触发操作是同步的操作,通过能够迅速得到响应的事件得到执行。触发操作没有实现代码,却可以作为类的状态图转移的触发器。当调用触发操作时,同时产生响应的事件。 2.4 生成代码 ??一般嵌入式应用中有60%~90%的代码用于内务处理(如状态图的实现、任务间的通信等),这些代码在设计新的系统时一般都可以重用。这种重用一般是通过实时框架来实现的。Rhapsody就提供了这样一个实时框架,它提供了一套嵌入式和实时应用专门选择和优化的设计模板。嵌入式应用程序一般都运行在嵌入式操作系统的平台上,而实时框架就是一个在操作系统之上应用程序之下的中间件。应用程序的编写或自动产生都基于有统一接口的实时框架,这样就使应用软件的开发与具体的平台无关,解决了嵌入式应用软件的移植问题。 ??一旦画出其余的图表并创建好不同类的实例后,就能进行代码的生成和模型的测试工作。在Rhapsody中,需要进行一些配置,以告诉Rhapsody从哪些类生成代码及使用什么样的环境。首先,使用Microsoft环境(Windows操作环境和Visual C++编译器)。然后,代码在Rhapsody中生成和编译,以产生可执行程序。     2.5 使UML模型有效 ??Rhapsody能使用自动生成的代码,所以,当实际的代码运行时,它能返回一些信息给调试工具,以便Rhapsody进行模型的测试。通过模型级调试、验证,可以尽早发现系统的设计错误或缺陷,从而较早地确定或降低项目的风险。     2.6 测试模型 ??一旦自动柜员机封装被手工产生的事件测试通过并观察发生的情况后,就可以利用如微软的Visual C++产生一个GUI。用于创建GUI的类从Ihardware类继承而来,选中set选项,当按钮被按下时,调用ON操作。GUI也能促使模型在模型级再次被调试。 3 在VxWorks上运行 ??模型是系统整体的抽象。软件开发的最终形式必须生成程序代码,模型毕竟是一些漂亮的蓝图。虽然它对软件的设计有很大的作用,但用户的最终目的是希望得到可执行的程序。对于嵌入式实时系统,代码与系统要求(时间约束、资源的限制等)是紧密联系的,用最终形式的源程序验证系统的模型更准确。 ??Rhapsody可利用软件自动生成技术的成果,根据模型可以自动生成具有产品质量的代码。这种代码既可以作为系统模型验证的代码,也是系统最后提交的代码。所以产生的代码是基于某个具体平台的代码,通过编译即可运行在该平台上。本文采用的是美国 Wind River System 公司推出的一个实时操作系统VxWorks。它是一个运行在目标机上的高性能、可裁剪的嵌入式实时操作系统。 ??一旦自动取款机系统被设计、实现和测试后,它就能在实时多任务操作系统VxWorks上实现。1个键盘、1个LCD液晶显示屏、1个插卡孔、1根与银行的上位机相连的双绞线和1个输出现金口经由I/O板连接到1个目标板上。 ??从Ihardware类继承而来并选中set选项而创建新类HwIrq。这些操作的实例可以被写进Rhapsody中。为了写到I/O板中,使用VxWorks系统的操作sysOutByte。 ??HwIrq类已经被设置成一个活动类,所以它能在自己的线程运行,线程的参数被配置如下:线程名为tRhpHw,堆栈长度为4096字节,优先级为180。 ??HwIrq.cpp的部分程序见本刊网络补充版(http://www.dpj.com.cn)。 4 结 论 ??本文运用基于UML的嵌入式实时应用软件开发环境Rhapsody来设计和实现自动取款机系统的模型。与传统的嵌入式软件开发方法相比,具有明显的优势。它大大缩短了产品的开发周期,解决了嵌入式应用软件的移植问题,使软件的开发工作主要集中在高层的建模和模型的测试及验证上,从而使软件开发工作的焦点从编码转到了设计上。

    时间:2004-12-09 关键词: VxWorks rhapsody

  • 基于Rhapsody和VxWorks的自动取款机系统

    摘要:介绍如何运用UML设计简单的自动取款机系统模型并在操作系统VxWorks上实现它:首先,介绍如何运用基于UML的嵌入式实时应用软件开发环境Rhapsody设计和实现自动取款机系统的模型,以使它能独立于实际的硬件和使用的操作系统;然后详细介绍上述模型如何在实时多任务操作系统VxWorks上实现。     关键词:Rhapsody VxWorks 自动取款机 引 言   随着嵌入式应用的不断增长,嵌入式系统需求的复杂性、不确定性不断提高,系统规模也逐步扩大;而产品的研发周期又在很快地缩短,给嵌入式应用软件的开发带来了新的挑战。同时,嵌入式软件的开发者必须面对由于芯片性能的增长、嵌入式操作系统平台等技术方面不断变化所带来的各种压力。嵌入式软件开发环境的发展,使一直“深埋”于系统的嵌入式应用软件变得开放而易于开发,从而促进了嵌入式技术的广泛应用。 1 基于UML的嵌入式软件开发环境结构 ??图1所示为一种支持基于UML(Unified Modeling Language,统一建模语言)的迭代式开发方法的开发环境的结构,虚框部分为基于UML的软件开发环境。 ??系统分析和设计用UML来描述,对系统建模;实现过程利用代码自动生成技术来实现;测试过程将依赖于生成的代码,通过在代码中拆装一些用于支持模型调试的调试信息来实现;而代码的编译、链接则采用目标系统的操作系统开发环境来完成,代码的运行与源程序级的调试仍然采用一般的嵌入式软件调试环境。 ??Rhapsody是一个基于UML的面向嵌入式实时应用开发的集成、可视化环境。软件开发者可以在这个环境里进行分析、设计、实现及验证。Rhapsody支持基于模型的调试;提供专门为实时嵌入式应用设计的可执行的框架,可以产生基于VxWorks、POS、OSE等多种操作系统的C语言、C++语言、Java语言的源程序。本文所给出的自动取款机系统的模型正是基于Rhapsody设计的。 2 自动取款机系统模型的设计     2.1 需求分析 ??我们设计的自动取款机系统要满足如下要求: ??在自动取款机系统中,当顾客在自动取款机操作面板上插入信用卡并输入密码和现金支取数额(每次最多只能取一千元)后,由自动取款机读取卡上的内容,并把相应信息传送到银行。银行把自动取款机送来的信息与银行帐号上的信息进行比较,如果两者一致,则银行传送确认信息到自动取款机,由自动取款机输出现金,然后顾客取出卡和现金;如果两者不一致,则要求顾客再次输入密码和现金支取数额,然后重复上述操作;若密码输入三次不正确,自动取款机就会吞掉信用卡,顾客就不能取出信用卡和现金。??该自动取款机系统包括1个键盘(10个数字键、ENTER键和CANCEL键)、1个LCD液晶显示屏、1个插卡孔和1个现金出口;通过双绞线与银行中的电脑进行串行通信。该自动取款机系统不包括银行中的电脑,只是通过软件与银行中的上位机进行串行通信。     2.2 可视化建模 ??建模是面向对象分析和设计的核心,也是分析和设计过程中最基本和最关键的活动之一。UML不仅适用于以面向对象技术描述的任何类型的系统,而且适用于系统开发的不同阶段。根据开发过程中不同阶段的具体要求,利用UML不同类型的图来描述系统的各种静态结构模型和动态行为模型。下面介绍如何利用基于UML的面向嵌入式实时应用开发的集成可视化环境Rhapsody创建自动取款机系统的模型。图3 取出现金的黑匣子场景    第一步:根据要求建立用例图。 ??图2所示为用例图。图中给出了自动取款机系统的主要用途,并表明由谁使用自动取款机系统。有一个主要成员——顾客。一个用例图应该具有这样的系统功能:对操作者而言,它返回可观察的结果但并不显示系统的内在结构。 ??自动取款机系统的主要用途是“取出现金”用例。顾客参与其中的两个实例是“输入密码”和“取出现金”。这两个实例都包含了另一个用例“读取卡上内容并验证”。对每一个用例而言,我们都可以增加文本描述。假如需要的话,这些用例能够被细化成另一张更多用例的图。这些用例并没有显示任何内在的结构,仅是一个功能性的视图。     第二步:设计黑匣子场景。 ??建立了一个用例图后,下一步便是细化用例,即设计一些黑匣子场景。这些黑匣子场景的主要作用是表明模型和对象之间的相互关系。把整个系统看作一个整体,对 “取出现金” 用例,我们细化为图3所示的场景。(由于每次最多只能取一千元,所以最多只需要按键4次。) ??图3所示的场景能被MSD(消息序列表)捕获,用来描述在顾客和自动取款机系统之间的通信行为。当创建这样的图表时,关于系统的更多细节被隐藏了;同时,这些场景帮助我们更好地理解使用者如何使用报警系统以及需要做哪些事情。总而言之,每一用例都有很多的场景需要捕获,每一个场景都是用例的一个有效的实例。    第三步:设计子系统图。 ??下一步是如何把模型分割成子系统。在UML中,一个子系统作为一个封装显示,即主要是一个类的集合。图4的子系统图表明自动取款机系统已经被分解成两个基本的部分:自动柜员机封装(AtmerPkg)和硬件封装(HardharePkg)。同时也表明:自动柜员机封装是完全独立于实际的硬件和硬件封装的,并且实现了Ihardware接口能够用于连接自动柜员机封装。接口类Ihardware描述了对自动柜员机封装的所有必需的操作,实现了应用与硬件环境的隔离。 ??一旦在自动柜员机封装和硬件封装之间定义了接口类,每一个子系统就能同步和独立地细化为更多的子系统。每一个子系统都知道它和其它子系统之间的接口。例如,我们可以开始分析自动柜员机子系统图,而不需要知道关于硬件的更多情况。     第四步:设计对象模型图。 ??对自动柜员机封装而言,我们设想有一个AtmerController类,其中包含Keypad类、Card类、LCD类和Cash类,这些类表示如图5所示。??图5表明:AtmerController类作为一个聚合类,包含了其它类的实例。我们也能看出,我们能选择显示“Keypad”类的不同的操作和属性。在上面的例子中,假如一个实例被AtmerControlle类创建,那么它将创建Keypad类的一个实例theKeypad、LCD类的一个实例theLCD、Cash类的一个实例theCash以及Card类的一个实例theCard。假如AtmerController类的实例被删除,这些包含的实例也同时被删除。 ??Ihardware类也有一些纯虚函数,所以为了测试AtmerController类,必须忽略这些操作。图6表示:ATM包含了AtmerController类的一个实例和从Ihardware类继承并忽略了其操作的Hw类的一个实例。     第五步:生成白匣子场景。 ??生成了一个新类AtmerController后,就可以开始为每一个黑匣子场景生成白匣子场景。消息序列表将用于获取以上不同场景的类的实例之间的通信行为。例如,图7消息序列描述了顾客输入支取现金数额并取出现金的场景。 ??消息通常对应于对象模型中操作和操作的返回值。消息值对应于类的属性或是类操作的返回值。消息可以是同步的,也可以是异步的。从图中可以看出,这些类都有动态行为:它们正在处理定时事件;调用其它类的操作;接受事件。对UML来说,这些动态行为都可以用一个状态图来表示。     第六步:创建状态图。 ??以顾客输入密码过程为例,创建状态图,如图8所示。通常,当一个问题很复杂时,它往往被分解成一些简单的问题,这也正是对顾客输入密码过程要做的事情。图8所示的状态图描述了顾客输入密码过程中的行为。图7 顾客输入支取数据并取出现金的白匣子场景    2.3 属性、操作和事件 ??属性来源于需求文档中定义的数据,应该简单,不考虑设计和实现的细节。每个类都可能有定义在其上的事件和操作。事件对应于明确的瞬时发生的影响类的动态行为。操作对应于类的服务和功能。Rhapsody中有3种事件。 ① 信号事件:对应于实例间的异步通信。 ② 时间事件:这种事件在进入一个状态并且经过一个指定的时间后触发。 ③ 触发操作:触发操作是同步的操作,通过能够迅速得到响应的事件得到执行。触发操作没有实现代码,却可以作为类的状态图转移的触发器。当调用触发操作时,同时产生响应的事件。 2.4 生成代码 ??一般嵌入式应用中有60%~90%的代码用于内务处理(如状态图的实现、任务间的通信等),这些代码在设计新的系统时一般都可以重用。这种重用一般是通过实时框架来实现的。Rhapsody就提供了这样一个实时框架,它提供了一套嵌入式和实时应用专门选择和优化的设计模板。嵌入式应用程序一般都运行在嵌入式操作系统的平台上,而实时框架就是一个在操作系统之上应用程序之下的中间件。应用程序的编写或自动产生都基于有统一接口的实时框架,这样就使应用软件的开发与具体的平台无关,解决了嵌入式应用软件的移植问题。 ??一旦画出其余的图表并创建好不同类的实例后,就能进行代码的生成和模型的测试工作。在Rhapsody中,需要进行一些配置,以告诉Rhapsody从哪些类生成代码及使用什么样的环境。首先,使用Microsoft环境(Windows操作环境和Visual C++编译器)。然后,代码在Rhapsody中生成和编译,以产生可执行程序。     2.5 使UML模型有效 ??Rhapsody能使用自动生成的代码,所以,当实际的代码运行时,它能返回一些信息给调试工具,以便Rhapsody进行模型的测试。通过模型级调试、验证,可以尽早发现系统的设计错误或缺陷,从而较早地确定或降低项目的风险。     2.6 测试模型 ??一旦自动柜员机封装被手工产生的事件测试通过并观察发生的情况后,就可以利用如微软的Visual C++产生一个GUI。用于创建GUI的类从Ihardware类继承而来,选中set选项,当按钮被按下时,调用ON操作。GUI也能促使模型在模型级再次被调试。 3 在VxWorks上运行 ??模型是系统整体的抽象。软件开发的最终形式必须生成程序代码,模型毕竟是一些漂亮的蓝图。虽然它对软件的设计有很大的作用,但用户的最终目的是希望得到可执行的程序。对于嵌入式实时系统,代码与系统要求(时间约束、资源的限制等)是紧密联系的,用最终形式的源程序验证系统的模型更准确。 ??Rhapsody可利用软件自动生成技术的成果,根据模型可以自动生成具有产品质量的代码。这种代码既可以作为系统模型验证的代码,也是系统最后提交的代码。所以产生的代码是基于某个具体平台的代码,通过编译即可运行在该平台上。本文采用的是美国 Wind River System 公司推出的一个实时操作系统VxWorks。它是一个运行在目标机上的高性能、可裁剪的嵌入式实时操作系统。 ??一旦自动取款机系统被设计、实现和测试后,它就能在实时多任务操作系统VxWorks上实现。1个键盘、1个LCD液晶显示屏、1个插卡孔、1根与银行的上位机相连的双绞线和1个输出现金口经由I/O板连接到1个目标板上。 ??从Ihardware类继承而来并选中set选项而创建新类HwIrq。这些操作的实例可以被写进Rhapsody中。为了写到I/O板中,使用VxWorks系统的操作sysOutByte。 ??HwIrq类已经被设置成一个活动类,所以它能在自己的线程运行,线程的参数被配置如下:线程名为tRhpHw,堆栈长度为4096字节,优先级为180。 ??HwIrq.cpp的部分程序见本刊网络补充版(http://www.dpj.com.cn)。 4 结 论 ??本文运用基于UML的嵌入式实时应用软件开发环境Rhapsody来设计和实现自动取款机系统的模型。与传统的嵌入式软件开发方法相比,具有明显的优势。它大大缩短了产品的开发周期,解决了嵌入式应用软件的移植问题,使软件的开发工作主要集中在高层的建模和模型的测试及验证上,从而使软件开发工作的焦点从编码转到了设计上。

    时间:2004-12-09 关键词: VxWorks rhapsody 设计教程

  • Armboot在EV40评估板上的移植

    摘要:介绍Armboot以及EV40评估板的特点;详细讨论Armboot在EV40上的移植并给出主要代码;以Flash编程为例,介绍与评估板相关Armboot命令的实现。    关键词:Armboot AT91M40800 ARM 移植 1 Armboot简介 Armboot是一个bootloader,是为基于ARM或者StrongARM CPU的嵌入式系统所设计的。它支持多种类型的Flash;允许映像文件经由bootp、dhcp、tftp从网络传输;支持从串口线下载S-record或者binary文件;允许内存的显示及修改;支持jffs2文件系统等。Armboot源码公开,可以在http://www.sourceforg.net/projects/armboot下载。 2 EV40评估板简介 Micetek祥佑数码科技有限公司配合其Hitool for ARM开发工具推出了基于AT91X40系列微控制器的ARM EV40(简称EV40)评估板。可用来开发、调试和评估以Atmel ARM为硬件基础的嵌入式系统。EV40评估板包括一个AT91X40系列的微控制器AT91M40800以及一些外围器件。 主要的外围部分包括:2个串口、1个复位按钮、3个应用按键、3个LED指示灯、1个7段LED显示器、512KB以太网接口、USB接口、PC104接口、EBI扩展接口、I/O扩展接口、时钟源选择、触摸板接口和LCD接口。 3 Armboot在EV40上的移植 本文的主要目的是使读者尽快地能在EV40上运行Armboot,因此,去掉(或修改)了一些完整版本所具有的代码(比如中断处理),从而加快开发。同时,这里使用Hitool for ARM开发工具,完成代码的修改、编译及调试。 3.1 初始化 Armboot的运行,开始于cpu/$cpu/start.s,完成一系列的初始化后(中间调用board/$board/memsetup.s),调用common/board.c中的函数start_armboot作为C语言程序的入口。如果使用Hitool,并正确地配置startup config(使用初始文件micev40_em.inc)。使用Hitool自动生成的start_up.s代替start.s,把B_main替换为 ldr pc,_start_armboot startarmboot:.word start_armboot 如果没有micev40_em.inc,则自行创建,内容如下: long ffe00000 0x01002529 long ffe00014 0x02502021 long ffe00004 0x022028al long ffe00018 0x60000000 long ffe00008 0x03002529 long ffe0001c 0x70000000 long ffe0000c 0x40000000 long ffe00020 0x00000001 long ffe00010 0x02402021 long ffe00024 0x00000006 这部分的作用相当于borad$board.s。用来初始化EBI的各个寄存器。 接下来是串口的初始化。这部分比较重要,作用是实现主机与目标板的通信,从而在超级终端(console)上提供用户接口。 在start_armboot函数中,cpu_init(&bd)、board_init(&bd)可以屏蔽掉;serial_init(&bd)用来初始化串口。初始化过程的一个示例如下(使用USART0)。 ①计算时钟分频数CD,公式为: 异步模式 CD=选择的时钟/16×波特率(结果四舍五入) 同步模式 CD=选择的时候/波特率(CD必须为偶数) CD将作US_BRGR(波特率发生寄存器)的值。 ②设置PS_PCER(省电模块的外围时钟使能寄存器),它的各位和中断源对应。首先使能外围的时钟: #define PS_PCER_US0 0x04 PS_PCER=PS_PCER_US0; ③设置PIO_PDR(PIO禁止寄存器)。此寄存器用于禁止PIO控制器控制单个引脚,而用作外围引脚。并行I/O口线中一些为复用口线,可以由PIO控制器控制或作为其它外围引脚。如P13(SCK0,SUART0时钟信号)、P14(TXD0,USART0数据发送端)、P15(RXD0,USART0数据接收端)。 #define PIO_PDR_RXD0 0x8000 #define PIO_PDR_TXD0 0x4000 #define PIO_PDR_TXD0 0x2000 如果使用MCK(主时钟), PIO_PDR=PIO_PDR_RXD0|PIO_PDR_TXD0; 如果使用SCK(外部时钟), PIO_PDR=PIO_PDR_RXD0|PIO_PDR_TXD0|PIO_PDR_SCK0。 ④复位接收器和发送器。这是通过设置US_CR(USART控制寄存器)。 #define US_RSTRX 0x0004 #define US_RSTRX 0x0008 #define US_RXDIS 0x0020 #define US_TXDIS 0x0080 US_CR=US_RSTRX|US_RSTTX|US_RXDIS|US_TXDIS ⑤清除发送和接收计数寄存器。 US_TCR=0 US_RCR=0 ⑥设置波特率产生寄存器US_BRGR。 US_BRGR=CD ⑦设置USART模式寄存器US_MR。 #define US_CHMODE_NORMAL 0x0000 /*普通模式*/ #define US_NBSTOP_1 0x0000 /*停止位1*/ #define US_PAR_NO 0x800 /*无奇偶校验*/ #define US_CHRL_8 0xC0 /*数据位8*/ #define US_CLKS_MCK 0x00 /*主时钟*/ #define US_ASYNC_MODE(US_CHMODE_NORMAL +US_NBSTOP_1+US_PAR_NO+US_CHRL_8+US_CLKS_MCK) US_MR=US_ASYNC_MODE ⑧设置发送时间确保寄存器US_TTGR。 US_TTGR=0 ⑨使能接收器和发送器。 #define US_TXEN 0x0040 #define US_RXEN 0x0010 US_CR=US_RXEN|US_TXEN ⑩屏蔽所有USART中断。 US_IDR=0xFFFFFFFF ⑾最好在这里插入一个延时循环,保证初始化工作的顺利工作。 For(i=0;i<=10;i++); 为了让读者更清楚理解以上个寄存器的来源,这里以USART0各寄存器的定义为例: //USART的各个寄存器 typedef volatile unsigned int at91_reg; typedef struct { at91_reg US_CR ; /*控制寄存器*/ at91_reg US_MR ; /*模式寄存器*/ at91_reg US_IER ; /*中断使能寄存器*/ at91_reg US_IDR ; /*中断禁止寄存器*/ at91_reg US_IMR ; /*中断屏蔽寄存器*/ at91_reg US_CSR ; /*通道状态寄存器*/ at91_reg US_RHR ; /*接收保持寄存器*/ at91_reg US_THR ; /*发送保持寄存器*/ at91_reg US_BRGR ; /*波特率产生寄存器*/ at91_reg US_TTOR ; /*接收超时寄存器*/ at91_reg US_TTGR ; /*发送器时间确保寄存器* at91_reg Reserved ; at91_reg US_RPR ; /*接收指针寄存器*/ at91_reg US_RCR ; /*接收计数寄存器*/ at91_reg US_TPR ; /*发送指针寄存器*/ at91_reg US_TCR; /*发送计数寄存器*/ }StructUSART; #define USART0_BASE ((StructUSART*)0xFFFD0000) 3.2 通过串口接收数据 #define US_RXRDY 0x1 While((US_CSR & US_RXRDY)==0){} /*等待US_RHR(接收保持寄存器)收到字符*/character=US_RHR /*收到字符后,把它赋给某一变量供以后使用*/ 以上内容用于cpu$cpu.c中的serial_getc()函数。 3.3 通过串口发送数据 #define US_TXRDY 0x2 while((US_CSR & US_TXRDY)==0){} /*等待US_THR(发送保持寄存器)送出字符*/ US_THR=character /*当US_THR为空后,往里写下一个要发送字符* 以上内容用于cpu$cpu.c中的serial_putc()函数。 3.4 计数器的使用 在cpu$cpu.c中,有个udelay(unsigned long usec)函数,作用是延时usec ms。通过使用定时器/计数器TC(Timer/Counter)模块完成该功能。同串口使用制似,也需要初始化一系列的寄存器,然后执行某种触发,使计数器复位,时钟启动;当计数器值到这TC_RC时,会发生RC比较,导致TC_SR(状态寄存器)的CPCS位(0x10)置位。由此可见,适当设置TC_RC寄存器的值,可以产生不同长短的延时;通过判断CPCS位,可作为延时结束的标志。 3.5 设置自动引导命令 Armboot在开始会有几秒的延时,让你选择是否自动引导。如果不自动引导,则可通过console,敲入命令,手工引导。 自动引导采用的命令来源于环境变量。环境变量是由一些以“0”结束的形如“name=value”的字符串所组成的序列,整个序列以两个“0”结束。环境变量存储于结构env_t的data数组中。有3处可以存放环境变量,一是SDRAM,在env_init(&bd)(中完成初始化;二是Flash。这里定义放在第三个扇区,即 #define CFG_ENV_ADDR(PHYS_FLASH_1+0x20000)/*环境变量扇区地址*/ env_t*env=(env_t*)CFG_ENV_ADDR。 三是default_environment。Default_environment是一个定义好的全局数组,作用相当于env_t中的data。 使用getenv(bd_t*bd,uchar *name)从环境变量中条目(形如“name=value”;value可以为空"")查找匹配name的条目;成功返回value对应的地址,失败返回0。 通过源码我们可以看出,这里采用的环境变量是default_environment,而且,name=bootcmd;因此,如果采用自动boot,则会自动执行bootp,bootm。由于笔者并不打算让Armboot自动执行任何命令,所以,将CONFIG_BOOTCOMMAND置空。 4 Flash编程 到此为止,Armboot基本上可以说能够在板子上运行了。一些和板子无关的命令已经可以运行,比如查看内存md;下载binary文件loadb(使用kermit模式/协议)等等。也有些命令依然还不能运行,它们根据具体的目标板有不同的代码。比如loads、erase等。 这里我们以Flash编程为例,实现erase命令。Loads中也需要调用和Flash有关的函数。以下的编程是针对Fujitsu MBM29LV160TE的。不同的Flash,命令序列和命令地址都可能不同。 4.1 Flash擦除 Flash的擦除是按照扇区来擦除的,扇区的大小由具体的Flash规定。 EV40使用的Flash是Fujitsu MBM29LV160TE。它规定,一个存储体上有35个扇区s0~s34;s0~s30大小为64KB(0x10000),s31大小为32KB,s32~s33大小为8KB,s34大小为16KB。 具体实现6个命令序列: typedef volatile unsigned short flash_word; #define CFG_FLASH_BASE 0x100000 flash_word *flash_address=CFG_FLASH_BASE,*s_address; s_address=擦除扇区的起始地址; *(flash_address+0x555)=0xAA;/*命令1*/ *(flash_address+0x2AA)=0x55;/*命令2*/ *(flash_address+0x555)=0x80;/*命令3*/ *(flash_address+0x555)=0xAA;/*命令4*/ *(flash_address+0x2AA)=0x55;/*命令5*/ *s_address=0x30; /*命令6*/ //扇区的擦除需要时间,擦除成功的标志是*s_address==0xFFFF while((*s_address!=0xFFFF)&&(i++<1000000)); //*若超过 if(i>=1000000){ return ERR_TIMOUT; } 4.2 Flash写入 写入以字(2字节)为单位,地址要字对齐。具体实现为4个命令序列: s_sddress=写入处的起始地址(偶地址); *(flash_address+0x555)=0xAA; /*命令1*/ *(flash_address+0x2AA)=0x55; /*命令2*/ *(flash_address+0x555)=0xA0; /*命令3*/ *s_address=data; /*命令4;data为欲写入数据,要求是flash_word类型*/ //扇区的写入需要时间,写入成功的标志是*s_address==data while((*s_address!=data)&&(i++<100000)); //*若超时 if(i>=100000){ return ERR_TIMOUT; } 结语 到此为止,移植可以告一段落了,如果有已经修改好的uClinux内核文件,可以试试使用Armboot(源码见网站http://www.dpj.com.cn),让它来下载并引导内核。还有一点须提醒读者注意,Armboot官方网站使用arm-linux-gcc编译。如果在写Flash时遇到问题(高字节和低字节内容相同),试试arm-elf-gcc suite。

    时间:2004-12-09 关键词: Linux ev40 armboot

  • Armboot在EV40评估板上的移植

    摘要:介绍Armboot以及EV40评估板的特点;详细讨论Armboot在EV40上的移植并给出主要代码;以Flash编程为例,介绍与评估板相关Armboot命令的实现。    关键词:Armboot AT91M40800 ARM 移植 1 Armboot简介 Armboot是一个bootloader,是为基于ARM或者StrongARM CPU的嵌入式系统所设计的。它支持多种类型的Flash;允许映像文件经由bootp、dhcp、tftp从网络传输;支持从串口线下载S-record或者binary文件;允许内存的显示及修改;支持jffs2文件系统等。Armboot源码公开,可以在http://www.sourceforg.net/projects/armboot下载。 2 EV40评估板简介 Micetek祥佑数码科技有限公司配合其Hitool for ARM开发工具推出了基于AT91X40系列微控制器的ARM EV40(简称EV40)评估板。可用来开发、调试和评估以Atmel ARM为硬件基础的嵌入式系统。EV40评估板包括一个AT91X40系列的微控制器AT91M40800以及一些外围器件。 主要的外围部分包括:2个串口、1个复位按钮、3个应用按键、3个LED指示灯、1个7段LED显示器、512KB以太网接口、USB接口、PC104接口、EBI扩展接口、I/O扩展接口、时钟源选择、触摸板接口和LCD接口。 3 Armboot在EV40上的移植 本文的主要目的是使读者尽快地能在EV40上运行Armboot,因此,去掉(或修改)了一些完整版本所具有的代码(比如中断处理),从而加快开发。同时,这里使用Hitool for ARM开发工具,完成代码的修改、编译及调试。 3.1 初始化 Armboot的运行,开始于cpu/$cpu/start.s,完成一系列的初始化后(中间调用board/$board/memsetup.s),调用common/board.c中的函数start_armboot作为C语言程序的入口。如果使用Hitool,并正确地配置startup config(使用初始文件micev40_em.inc)。使用Hitool自动生成的start_up.s代替start.s,把B_main替换为 ldr pc,_start_armboot startarmboot:.word start_armboot 如果没有micev40_em.inc,则自行创建,内容如下: long ffe00000 0x01002529 long ffe00014 0x02502021 long ffe00004 0x022028al long ffe00018 0x60000000 long ffe00008 0x03002529 long ffe0001c 0x70000000 long ffe0000c 0x40000000 long ffe00020 0x00000001 long ffe00010 0x02402021 long ffe00024 0x00000006 这部分的作用相当于borad$board.s。用来初始化EBI的各个寄存器。 接下来是串口的初始化。这部分比较重要,作用是实现主机与目标板的通信,从而在超级终端(console)上提供用户接口。 在start_armboot函数中,cpu_init(&bd)、board_init(&bd)可以屏蔽掉;serial_init(&bd)用来初始化串口。初始化过程的一个示例如下(使用USART0)。 ①计算时钟分频数CD,公式为: 异步模式 CD=选择的时钟/16×波特率(结果四舍五入) 同步模式 CD=选择的时候/波特率(CD必须为偶数) CD将作US_BRGR(波特率发生寄存器)的值。 ②设置PS_PCER(省电模块的外围时钟使能寄存器),它的各位和中断源对应。首先使能外围的时钟: #define PS_PCER_US0 0x04 PS_PCER=PS_PCER_US0; ③设置PIO_PDR(PIO禁止寄存器)。此寄存器用于禁止PIO控制器控制单个引脚,而用作外围引脚。并行I/O口线中一些为复用口线,可以由PIO控制器控制或作为其它外围引脚。如P13(SCK0,SUART0时钟信号)、P14(TXD0,USART0数据发送端)、P15(RXD0,USART0数据接收端)。 #define PIO_PDR_RXD0 0x8000 #define PIO_PDR_TXD0 0x4000 #define PIO_PDR_TXD0 0x2000 如果使用MCK(主时钟), PIO_PDR=PIO_PDR_RXD0|PIO_PDR_TXD0; 如果使用SCK(外部时钟), PIO_PDR=PIO_PDR_RXD0|PIO_PDR_TXD0|PIO_PDR_SCK0。 ④复位接收器和发送器。这是通过设置US_CR(USART控制寄存器)。 #define US_RSTRX 0x0004 #define US_RSTRX 0x0008 #define US_RXDIS 0x0020 #define US_TXDIS 0x0080 US_CR=US_RSTRX|US_RSTTX|US_RXDIS|US_TXDIS ⑤清除发送和接收计数寄存器。 US_TCR=0 US_RCR=0 ⑥设置波特率产生寄存器US_BRGR。 US_BRGR=CD ⑦设置USART模式寄存器US_MR。 #define US_CHMODE_NORMAL 0x0000 /*普通模式*/ #define US_NBSTOP_1 0x0000 /*停止位1*/ #define US_PAR_NO 0x800 /*无奇偶校验*/ #define US_CHRL_8 0xC0 /*数据位8*/ #define US_CLKS_MCK 0x00 /*主时钟*/ #define US_ASYNC_MODE(US_CHMODE_NORMAL +US_NBSTOP_1+US_PAR_NO+US_CHRL_8+US_CLKS_MCK) US_MR=US_ASYNC_MODE ⑧设置发送时间确保寄存器US_TTGR。 US_TTGR=0 ⑨使能接收器和发送器。 #define US_TXEN 0x0040 #define US_RXEN 0x0010 US_CR=US_RXEN|US_TXEN ⑩屏蔽所有USART中断。 US_IDR=0xFFFFFFFF ⑾最好在这里插入一个延时循环,保证初始化工作的顺利工作。 For(i=0;i<=10;i++); 为了让读者更清楚理解以上个寄存器的来源,这里以USART0各寄存器的定义为例: //USART的各个寄存器 typedef volatile unsigned int at91_reg; typedef struct { at91_reg US_CR ; /*控制寄存器*/ at91_reg US_MR ; /*模式寄存器*/ at91_reg US_IER ; /*中断使能寄存器*/ at91_reg US_IDR ; /*中断禁止寄存器*/ at91_reg US_IMR ; /*中断屏蔽寄存器*/ at91_reg US_CSR ; /*通道状态寄存器*/ at91_reg US_RHR ; /*接收保持寄存器*/ at91_reg US_THR ; /*发送保持寄存器*/ at91_reg US_BRGR ; /*波特率产生寄存器*/ at91_reg US_TTOR ; /*接收超时寄存器*/ at91_reg US_TTGR ; /*发送器时间确保寄存器* at91_reg Reserved ; at91_reg US_RPR ; /*接收指针寄存器*/ at91_reg US_RCR ; /*接收计数寄存器*/ at91_reg US_TPR ; /*发送指针寄存器*/ at91_reg US_TCR; /*发送计数寄存器*/ }StructUSART; #define USART0_BASE ((StructUSART*)0xFFFD0000) 3.2 通过串口接收数据 #define US_RXRDY 0x1 While((US_CSR & US_RXRDY)==0){} /*等待US_RHR(接收保持寄存器)收到字符*/character=US_RHR /*收到字符后,把它赋给某一变量供以后使用*/ 以上内容用于cpu$cpu.c中的serial_getc()函数。 3.3 通过串口发送数据 #define US_TXRDY 0x2 while((US_CSR & US_TXRDY)==0){} /*等待US_THR(发送保持寄存器)送出字符*/ US_THR=character /*当US_THR为空后,往里写下一个要发送字符* 以上内容用于cpu$cpu.c中的serial_putc()函数。 3.4 计数器的使用 在cpu$cpu.c中,有个udelay(unsigned long usec)函数,作用是延时usec ms。通过使用定时器/计数器TC(Timer/Counter)模块完成该功能。同串口使用制似,也需要初始化一系列的寄存器,然后执行某种触发,使计数器复位,时钟启动;当计数器值到这TC_RC时,会发生RC比较,导致TC_SR(状态寄存器)的CPCS位(0x10)置位。由此可见,适当设置TC_RC寄存器的值,可以产生不同长短的延时;通过判断CPCS位,可作为延时结束的标志。 3.5 设置自动引导命令 Armboot在开始会有几秒的延时,让你选择是否自动引导。如果不自动引导,则可通过console,敲入命令,手工引导。 自动引导采用的命令来源于环境变量。环境变量是由一些以“0”结束的形如“name=value”的字符串所组成的序列,整个序列以两个“0”结束。环境变量存储于结构env_t的data数组中。有3处可以存放环境变量,一是SDRAM,在env_init(&bd)(中完成初始化;二是Flash。这里定义放在第三个扇区,即 #define CFG_ENV_ADDR(PHYS_FLASH_1+0x20000)/*环境变量扇区地址*/ env_t*env=(env_t*)CFG_ENV_ADDR。 三是default_environment。Default_environment是一个定义好的全局数组,作用相当于env_t中的data。 使用getenv(bd_t*bd,uchar *name)从环境变量中条目(形如“name=value”;value可以为空"")查找匹配name的条目;成功返回value对应的地址,失败返回0。 通过源码我们可以看出,这里采用的环境变量是default_environment,而且,name=bootcmd;因此,如果采用自动boot,则会自动执行bootp,bootm。由于笔者并不打算让Armboot自动执行任何命令,所以,将CONFIG_BOOTCOMMAND置空。 4 Flash编程 到此为止,Armboot基本上可以说能够在板子上运行了。一些和板子无关的命令已经可以运行,比如查看内存md;下载binary文件loadb(使用kermit模式/协议)等等。也有些命令依然还不能运行,它们根据具体的目标板有不同的代码。比如loads、erase等。 这里我们以Flash编程为例,实现erase命令。Loads中也需要调用和Flash有关的函数。以下的编程是针对Fujitsu MBM29LV160TE的。不同的Flash,命令序列和命令地址都可能不同。 4.1 Flash擦除 Flash的擦除是按照扇区来擦除的,扇区的大小由具体的Flash规定。 EV40使用的Flash是Fujitsu MBM29LV160TE。它规定,一个存储体上有35个扇区s0~s34;s0~s30大小为64KB(0x10000),s31大小为32KB,s32~s33大小为8KB,s34大小为16KB。 具体实现6个命令序列: typedef volatile unsigned short flash_word; #define CFG_FLASH_BASE 0x100000 flash_word *flash_address=CFG_FLASH_BASE,*s_address; s_address=擦除扇区的起始地址; *(flash_address+0x555)=0xAA;/*命令1*/ *(flash_address+0x2AA)=0x55;/*命令2*/ *(flash_address+0x555)=0x80;/*命令3*/ *(flash_address+0x555)=0xAA;/*命令4*/ *(flash_address+0x2AA)=0x55;/*命令5*/ *s_address=0x30; /*命令6*/ //扇区的擦除需要时间,擦除成功的标志是*s_address==0xFFFF while((*s_address!=0xFFFF)&&(i++<1000000)); //*若超过 if(i>=1000000){ return ERR_TIMOUT; } 4.2 Flash写入 写入以字(2字节)为单位,地址要字对齐。具体实现为4个命令序列: s_sddress=写入处的起始地址(偶地址); *(flash_address+0x555)=0xAA; /*命令1*/ *(flash_address+0x2AA)=0x55; /*命令2*/ *(flash_address+0x555)=0xA0; /*命令3*/ *s_address=data; /*命令4;data为欲写入数据,要求是flash_word类型*/ //扇区的写入需要时间,写入成功的标志是*s_address==data while((*s_address!=data)&&(i++<100000)); //*若超时 if(i>=100000){ return ERR_TIMOUT; } 结语 到此为止,移植可以告一段落了,如果有已经修改好的uClinux内核文件,可以试试使用Armboot(源码见网站http://www.dpj.com.cn),让它来下载并引导内核。还有一点须提醒读者注意,Armboot官方网站使用arm-linux-gcc编译。如果在写Flash时遇到问题(高字节和低字节内容相同),试试arm-elf-gcc suite。

    时间:2004-12-09 关键词: ev40 armboot 设计教程

  • 采用Nios定制指令的嵌入式系统优化设计

    摘要:Altera公司的Nios软核处理器以其低成本,设计灵活等特点,在嵌入式应用领域得到广泛的应用。采用Nios处理器的定制指令,可以把用户自定义的功能直接添加到Nios CPU的算术逻辑单元中,加快专项任务的执行,以达到优化目的。本文在阐述Nios定制指令设计的基础上,给出相应的设计例子说明。     关键词:Nios软核 定制指令 嵌入式处理器MP3 引言 Nios处理器是Altera公司推出的一个32/16位精简指令信处理器软核。在Altera公司推出的软件SOPC中加载Nios核 和相应的外围接口以及与定义相应的自定义指令,然后对设计进行综合,下载到FPGA中就可以方便地一个具有特定功能的嵌入式处理器。这种设计思路增加了系统设计的灵活性,加快系统运行速度,缩短产品研发和上市时间。 由硬件实现复杂的算法通常比软件实现更高效。利用Altera的Niso嵌入式处理器的定制指令,可以把用户自定义的功能直接添加到Niso CPU的算术逻辑单元(ALU)中(见图1),来加快专项任务的执行,从而达到系统优化的目的。因此,设计者可以针对关键的内部循环和耗时算法,创建Nios嵌入式处理器的定制指令,把复杂的顺序指令简化为硬件实现的单指令,这样就能够大大提高系统性能。例如,Nios CPU执行浮点乘法运算要2800多个时钟周期;而浮点乘法的定制指令采用了浮点单元(FPU),执行只需19个时钟周期。 1 定制指令 定制指令为Nios处理器的算术逻辑单元增加了定制逻辑,设计者通过定制指令,用快速高效的定制逻辑块替代复杂耗时的软件程序。在一个CPU中,可以运行多达五个组合或时序定制模块,还可以访问Nios系统模块外的存储器和/或逻辑。定制逻辑模块在两个寄存器Ra和Rb内容的基础上执行用户定义的操作,结果存放在寄存器Ra中。这些定制逻辑模块的功能只受限于器件内逻辑单元(LE)和设计得的想象力。 定制硬件模块能够通过Nios嵌入式处理器指令集中的五个用户定义操作码来访问。SOPC Builder在生成系统期间会为任何定制指令创建宏,通过这些自动产生的C和汇编语言宏就可以方便地访问自定义指令操作码。 2 实现定制指令 以Altera的Nios2.0版嵌入式处理器为例实现定制指令,同时点击Custom Instructions标签创建或编辑Nios CPU,如图2。 Custom Instruction标签是系统设计都 连接定制逻辑和Nios CPU的ALU的界面。首先,选择定制指令的操作码,有USR0~USR4五个操作码可供使用。然后,导入和扫描作为定制指令的HDL文件。Design Import Wizard扫描顶层模块的端口,进行合适连接。Design Import Wizard可以接受以下类型的文件:VerilogHDL/VHDL/EDIF/VQM以接受以下类型的文件:Verilog HDL、VHDL、EDIF、VQM和Altera QuartusII原理图。导入设计文件之后,分配定制指令所需的CPU时钟周期数目和定制指令名。 在系统生成期间,SOPC Builder工具用作ALU一部分的定制逻辑来创建Nios CPU,受所选的操作码控制软件开发包用定制指令名创建在C/C++和汇编语言中使用的软件宏。这些在定制软件开发包ince下。图2 定制指令设计界面    设计者通过创建的软件宏访问定制指令。在C/C++中,宏就像函数调用一样使用。如果使用前缀端口,就要用前缀创建不同的宏。例如,为浮点单元(FPU)创建两个C/C++宏。例如,为浮点单元(FPU)创建两个C/C++宏是: result=nm_fpu(data,datb); //不使用前缀 result=nm_fpu_pfx(prefix,data,data); //使用前缀 在汇编语言中,宏调用USR操作码,按标准汇指令一样使用。如果使用前缀,那么在宏之前必须有一个PFX指令。有关用户定义操作码(USR0~USR4)的详细资料可参Nios Software Development Reference Manual。 3 MP3播放器的定制指令设计 以MP3播放器设计为例,采用定制指令对设计进行优化。该设计通过增加两条定制指令,就能使系统执行性能提高大约3倍。图为该MP3系统设计框图。 (1)MP3解码器 在大多数MP3播放器中,处理器是用来管理函数和传输数据的。专用MP3解码器ASIC可用于执行密集计算量的解码和传数据给音频器件。本例中,Altera的Nios处理器用于完成处理控制信号,传输数据和进行MP3解码。通常,MP3解码器流程如下: ①通过IDE接口从CF(CompactFlash controler)中读取MP3数据; ②将MP3数据存入SPAM中缓存; ③对MP3数据解码; ④将MP3边带合成到脉冲编码调制(PCM)数据; ⑤把PCM数据传给脉宽调制器PWM。 此外,播放器采用MPEG Audio Decoder(MAD)进行MP3解码,是基于以下方面: ①100%定点(整数)计算; ②网上有可利用的源码; ③在GNU Ceneral Public License(GPL)下发布。 (2)定制指令    我们知道在执行MP3解码的过程中,大量时间花费在边带的合成上。因此,优化Altera MP3的重点就落在函数mad_synth_frame上。我们可通过使用定制指令f_mul和DCT32来优化该函数。 F_mul F_mul和mad_f_mul是MAD使用的宏,用整数乘法来模拟浮点乘法。定义如下: #define mad_f_mul(x,y) ((((x)+0x00002000L)>>14)×(((y)+0x00002000L))>>14) #define f_mul(x,y) (((x)|0x0001FFFFL) ((y)|0x0001FFFFL)) 这些函数完成的功能是一组易被硬件实现的操作,包括移位、加法、乘法和逻辑或运算。在Altera MP3的优化设计中,用硬件定制指令f_mul执行原先用软件宏;还可利用前缀选项,把两个宏合为一个单定制指令。以下就是用Altera的定制指令定义(f_mul和mad_f_mul): #define f_mul(x,y)nm_fmul((x),(y)); #define mad_f_mul(x,y)nm_fmul_pfx(1,(x),(y)); DCT32 在MP3解码中,DCT32完成离散余弦变换。MAD软件用优化过的DVT来增强性能。从软件角度来看,该优化算法比起一般DCT对提高性能具有重大意义。因为标准DCT需要1024个乘法,而用优化后的DCT只需80个乘法。图4 DCT32与mad_synth_frame软件流程    DCT32定制指令所用硬件由Celoxica提供,它是可重配置计算方案提供商,采用了基于HandelC的设计工具。Altera的DCT32定制指令按以下特点设计: |①可以存储32位输入和32位输出; ②在DCT计算时,能独立于CPU工作; ③用前缀指令接受命令 ——装入/卸载 ——启动DCT计算 ——轮询是否完成。 因为定制指令可以轮询,在DCT输出前其它代码可以并行运行。当需要DCT输出时,定制指令被查询,看是否已完成计算。如果完成,Nios处理器卸载输出数据,同时装入下组输入数据。图4给出了DCT32定制指令及mad_synth_frame的流程图。 (3)优化前后比较 表1给出了三种情况下完成mad_synth_frame函数的比较结果。三种情况分别是只用硬件乘法指令,单用定制指令f_mul及f_mul和DCT32共用。 从表1中可以看出,f_mul是最有效的定制指令,系统规模仅仅增加3%,却减少了77%的循环数目。规模增加很小是因为f_mul定制指令无需专用的硬件乘法器。表1 三种情况比较 所用硬件 循环数目 逻辑元件(IE) 内存位 只用硬件乘法 1 279 000 3 542 26 624 f_mul 293 000 3 642 26 624 f_mul和DCT32并行 231 600 4 331 30 528 DCT32指令运行在并行模式下,比起f_mul又减少了21%的循环数目,LE资源也只增加了18.9%。 把定制指令所需的额外资源和性能增加情况与只用硬件乘法的基准系统比较。用定制指令能减少执行mad_synth_frame函数时所需的80%循环数目而只增加系统22.3%的规模。该MP3是在Nios开发面板上设计并运行的,频率为33MHz。在不增加时钟频率的情况下,所有性能符合指标。如果需进一步提高性能,还可通过增大时钟频率,加大内存,增加指令和数据缓存等方法来实现。 4 结论 采用Nios定制指令,系统设计得能够把一系列顺序执行的指令简化为通过硬件执行的单个指令,从而简化系统软件设计并且 加快系统运行速度。同时充分利用了可编程逻辑器件通过硬件执行速度快的优点,和用于控制的Nios处理器进行了完美的结合。

    时间:2004-12-09 关键词: iOS NIOS

  • 采用Nios定制指令的嵌入式系统优化设计

    摘要:Altera公司的Nios软核处理器以其低成本,设计灵活等特点,在嵌入式应用领域得到广泛的应用。采用Nios处理器的定制指令,可以把用户自定义的功能直接添加到Nios CPU的算术逻辑单元中,加快专项任务的执行,以达到优化目的。本文在阐述Nios定制指令设计的基础上,给出相应的设计例子说明。     关键词:Nios软核 定制指令 嵌入式处理器MP3 引言 Nios处理器是Altera公司推出的一个32/16位精简指令信处理器软核。在Altera公司推出的软件SOPC中加载Nios核 和相应的外围接口以及与定义相应的自定义指令,然后对设计进行综合,下载到FPGA中就可以方便地一个具有特定功能的嵌入式处理器。这种设计思路增加了系统设计的灵活性,加快系统运行速度,缩短产品研发和上市时间。 由硬件实现复杂的算法通常比软件实现更高效。利用Altera的Niso嵌入式处理器的定制指令,可以把用户自定义的功能直接添加到Niso CPU的算术逻辑单元(ALU)中(见图1),来加快专项任务的执行,从而达到系统优化的目的。因此,设计者可以针对关键的内部循环和耗时算法,创建Nios嵌入式处理器的定制指令,把复杂的顺序指令简化为硬件实现的单指令,这样就能够大大提高系统性能。例如,Nios CPU执行浮点乘法运算要2800多个时钟周期;而浮点乘法的定制指令采用了浮点单元(FPU),执行只需19个时钟周期。 1 定制指令 定制指令为Nios处理器的算术逻辑单元增加了定制逻辑,设计者通过定制指令,用快速高效的定制逻辑块替代复杂耗时的软件程序。在一个CPU中,可以运行多达五个组合或时序定制模块,还可以访问Nios系统模块外的存储器和/或逻辑。定制逻辑模块在两个寄存器Ra和Rb内容的基础上执行用户定义的操作,结果存放在寄存器Ra中。这些定制逻辑模块的功能只受限于器件内逻辑单元(LE)和设计得的想象力。 定制硬件模块能够通过Nios嵌入式处理器指令集中的五个用户定义操作码来访问。SOPC Builder在生成系统期间会为任何定制指令创建宏,通过这些自动产生的C和汇编语言宏就可以方便地访问自定义指令操作码。 2 实现定制指令 以Altera的Nios2.0版嵌入式处理器为例实现定制指令,同时点击Custom Instructions标签创建或编辑Nios CPU,如图2。 Custom Instruction标签是系统设计都 连接定制逻辑和Nios CPU的ALU的界面。首先,选择定制指令的操作码,有USR0~USR4五个操作码可供使用。然后,导入和扫描作为定制指令的HDL文件。Design Import Wizard扫描顶层模块的端口,进行合适连接。Design Import Wizard可以接受以下类型的文件:VerilogHDL/VHDL/EDIF/VQM以接受以下类型的文件:Verilog HDL、VHDL、EDIF、VQM和Altera QuartusII原理图。导入设计文件之后,分配定制指令所需的CPU时钟周期数目和定制指令名。 在系统生成期间,SOPC Builder工具用作ALU一部分的定制逻辑来创建Nios CPU,受所选的操作码控制软件开发包用定制指令名创建在C/C++和汇编语言中使用的软件宏。这些在定制软件开发包ince下。图2 定制指令设计界面    设计者通过创建的软件宏访问定制指令。在C/C++中,宏就像函数调用一样使用。如果使用前缀端口,就要用前缀创建不同的宏。例如,为浮点单元(FPU)创建两个C/C++宏。例如,为浮点单元(FPU)创建两个C/C++宏是: result=nm_fpu(data,datb); //不使用前缀 result=nm_fpu_pfx(prefix,data,data); //使用前缀 在汇编语言中,宏调用USR操作码,按标准汇指令一样使用。如果使用前缀,那么在宏之前必须有一个PFX指令。有关用户定义操作码(USR0~USR4)的详细资料可参Nios Software Development Reference Manual。 3 MP3播放器的定制指令设计 以MP3播放器设计为例,采用定制指令对设计进行优化。该设计通过增加两条定制指令,就能使系统执行性能提高大约3倍。图为该MP3系统设计框图。 (1)MP3解码器 在大多数MP3播放器中,处理器是用来管理函数和传输数据的。专用MP3解码器ASIC可用于执行密集计算量的解码和传数据给音频器件。本例中,Altera的Nios处理器用于完成处理控制信号,传输数据和进行MP3解码。通常,MP3解码器流程如下: ①通过IDE接口从CF(CompactFlash controler)中读取MP3数据; ②将MP3数据存入SPAM中缓存; ③对MP3数据解码; ④将MP3边带合成到脉冲编码调制(PCM)数据; ⑤把PCM数据传给脉宽调制器PWM。 此外,播放器采用MPEG Audio Decoder(MAD)进行MP3解码,是基于以下方面: ①100%定点(整数)计算; ②网上有可利用的源码; ③在GNU Ceneral Public License(GPL)下发布。 (2)定制指令    我们知道在执行MP3解码的过程中,大量时间花费在边带的合成上。因此,优化Altera MP3的重点就落在函数mad_synth_frame上。我们可通过使用定制指令f_mul和DCT32来优化该函数。 F_mul F_mul和mad_f_mul是MAD使用的宏,用整数乘法来模拟浮点乘法。定义如下: #define mad_f_mul(x,y) ((((x)+0x00002000L)>>14)×(((y)+0x00002000L))>>14) #define f_mul(x,y) (((x)|0x0001FFFFL) ((y)|0x0001FFFFL)) 这些函数完成的功能是一组易被硬件实现的操作,包括移位、加法、乘法和逻辑或运算。在Altera MP3的优化设计中,用硬件定制指令f_mul执行原先用软件宏;还可利用前缀选项,把两个宏合为一个单定制指令。以下就是用Altera的定制指令定义(f_mul和mad_f_mul): #define f_mul(x,y)nm_fmul((x),(y)); #define mad_f_mul(x,y)nm_fmul_pfx(1,(x),(y)); DCT32 在MP3解码中,DCT32完成离散余弦变换。MAD软件用优化过的DVT来增强性能。从软件角度来看,该优化算法比起一般DCT对提高性能具有重大意义。因为标准DCT需要1024个乘法,而用优化后的DCT只需80个乘法。图4 DCT32与mad_synth_frame软件流程    DCT32定制指令所用硬件由Celoxica提供,它是可重配置计算方案提供商,采用了基于HandelC的设计工具。Altera的DCT32定制指令按以下特点设计: |①可以存储32位输入和32位输出; ②在DCT计算时,能独立于CPU工作; ③用前缀指令接受命令 ——装入/卸载 ——启动DCT计算 ——轮询是否完成。 因为定制指令可以轮询,在DCT输出前其它代码可以并行运行。当需要DCT输出时,定制指令被查询,看是否已完成计算。如果完成,Nios处理器卸载输出数据,同时装入下组输入数据。图4给出了DCT32定制指令及mad_synth_frame的流程图。 (3)优化前后比较 表1给出了三种情况下完成mad_synth_frame函数的比较结果。三种情况分别是只用硬件乘法指令,单用定制指令f_mul及f_mul和DCT32共用。 从表1中可以看出,f_mul是最有效的定制指令,系统规模仅仅增加3%,却减少了77%的循环数目。规模增加很小是因为f_mul定制指令无需专用的硬件乘法器。表1 三种情况比较 所用硬件 循环数目 逻辑元件(IE) 内存位 只用硬件乘法 1 279 000 3 542 26 624 f_mul 293 000 3 642 26 624 f_mul和DCT32并行 231 600 4 331 30 528 DCT32指令运行在并行模式下,比起f_mul又减少了21%的循环数目,LE资源也只增加了18.9%。 把定制指令所需的额外资源和性能增加情况与只用硬件乘法的基准系统比较。用定制指令能减少执行mad_synth_frame函数时所需的80%循环数目而只增加系统22.3%的规模。该MP3是在Nios开发面板上设计并运行的,频率为33MHz。在不增加时钟频率的情况下,所有性能符合指标。如果需进一步提高性能,还可通过增大时钟频率,加大内存,增加指令和数据缓存等方法来实现。 4 结论 采用Nios定制指令,系统设计得能够把一系列顺序执行的指令简化为通过硬件执行的单个指令,从而简化系统软件设计并且 加快系统运行速度。同时充分利用了可编程逻辑器件通过硬件执行速度快的优点,和用于控制的Nios处理器进行了完美的结合。

    时间:2004-12-09 关键词: NIOS 设计教程

  • MIDP2.0及其移植技术分析

    摘要:MIDP即移动信息设备规范,是专门基于资源和网络连接有限的移动设备之上的J2ME应用规范。本文在分析MIDP2.0的基础上,详细阐述MIDP的事件处理、文件系统、用户图形接口和网络等主要部分在不同平台间移植的实现过程。     关键词:J2ME MIDP 移植 平台无关 本地代码 1 MIDP2.0简介 随着现代信息化社会的发展,小型移动通信设备已经从最初的一种单纯的通信工具转变成如今集通信、工作、娱乐等功能为一体的综合设备;但仅有这些还不能满足用户的要求。个性永远是千变万化的,时尚也不会始终为一种模式。因此,在移动终端上开发通用的、丰富的应用已成为必然的趋势。这些应用可以按用户的意愿随时安装和删除。 J2ME(JAVA2 Micro Edition)正是这样一种JAVA应用开发平台。实际上,JAVA语言从其诞生起就以其运行的平台无关性这一强大的优势而成为网络应用的宠儿。J2ME是JAVA2标准版本的微型版本,专门为小型移动设备所设计。这些设备处理器的处理能力都不强,可使用的资源也有限。因此,J2ME只包含了J2SE中在移动通信设备上所必需的功能和组件,使其能够在移动设备及其有限的资源上开发出丰富多彩且平台无关的应用。J2ME在结构上分为CDC(Connecte Device Configuration)和基于其上,以Foundation Profile为主的规范,以及CLDC(Connecte Limited Device Configuration)和基于其上,以MIDP为主的规范。 MIDP(Mobile Information Device Profile)是移信息设备规范的简称。规范具体定义了J2ME适用的硬件和软件框架,并提供了这个框架要实现的基本功能及其标准接口;而应用开发者就可以基于这个框架开发出各种应用。2000年9月,SUN公司发布了MIDP的第一个正式版本MIDP1.0。它将J2ME适用的设备定位在至少拥有数百KB RAM和ROM,并具有基本网络和显示功能的移动通信设备上;在该基础上定义了一系列软件接的移动通信设备上;在该上基础上定义了一系列软件接口,其中包括基本输入输出、图形化用户接口(GUI)、网络、事件机制、文件系统、应用管理系统(AMS)等之后,随着JAVA技术的不断发展和用户需求的不断提高,SUN公司又于2002年11月发布了MIDP2.0。它对设备的内存资源和处理能力的要求较1.0要高,但MIDP2.0也为应用开发者提供了更方便、更丰富多彩的软件包,主要增加了游戏接口的实现、声音输出接口的实现安全网络机制的实现。MIDP2.0的这些特性将使基于移动设备的JAVA应用具有更加广阔的前景,也必将使新一代的移动设备发生革命性的变化并领导时尚潮流。MIDP2.0接口包如表1所列。表1 MIDP2.0接口包及其功能 包 功      能 javax.microedition.lcdui 提供一系列用户界面接口 javax.microedition.lcdui.game 专门用于游戏设计的接口 javax.microedition.rms 数据管理,用于保存数据记录 javax.microedition.midlet JAVA应用管理接口 javax.microedition.io 基本网络连接接口 javax.microedition.media 媒体接口规范(JSR-135)的实现包 javax.microedition.media.control 媒体播放器的控制类 javax.microedition.pki 数字签名规范的实现接口(用于安全网络) java.io JAVA基本输入输出接口 java.lang JAVA基本数据类型接口 java.util JAVA基本应用接口 2 MIDP2.0的移植 既然MIDP2.0是定位在移动通信设备之上的一系列JAVA应用开发接口,我们就必须考虑如何将整个MIDP系统嵌入到特定的硬件设备和其上的操作系统中。只有这样,JAVA应用程序才能运行在该设备上,并利用MIDP提供的强大功能将用户带入一个全新的JAVA世界。在一个完全不同的操作系统平台上,用该平台上对应的系统API调用(或一系列操作),替换MIDP参考实现中所有与操作平台相关的调用(或操作),使MIDP能在目标平台上正确地执行所有要求的功能;同时,调用该平台上特有的能充分发挥目标设备硬件特性的接口,替换参考实现中相应的接口,使MIDP能在目标平台上更高效地运行,这个过程就称为MIDP的移植。 MIDP由许多不同的部分组成,每一部分完成MIDP一个特定的功能接口。其中需要移植的部分主要包括事件处理、文件系统、用户图形化接口、网络、AMS、多媒体。它们都分为高端的JAVA层和低端的本地方法层。JAVA层是用JAVA语言实现的,由KVM解释执行;因此没有涉及到与操作系统平台相关的调用和操作,可以不经修改就在任何操作平台上运行,是平台无关的(PlateForm Independent)。它的移植主要是为满足用户的特殊要求而进行的个性化工作。本地方法层(NativeCode)是指为提高代码的执行效率,保持JAVA语言的平台无关性而使用C语言实现的部分MIDP功能的代码。本地即是指它是与当前的操作平台相关的,它的移植才是涉及到具体平台和执行效率而进行的具体调用和操作的替换过程,其结构如图1所示。 下面,我们就具体到MIDP的每一个部分的移植进行讨论。 2.1 事件处理 MIDP的事件处理部分要处理的事件主要来自两个方面:①来自虚拟机底层的事件,如虚拟机的异常消息;②来自MIDP内部的事件,如屏幕刷新、按键消息、触控笔点击消息、时钟消息等。由于不同的平台可能使用不同的事件消息获取和传递机制,因此MIDP事件处理的移植也集中在这上面,其实现被放在本地方法层的文件nativeGUI.c中的函数GetAndStoreKVMEvent中。我们只需根据目标平台获取和传递事件的要求修改该文件中的相应函数即可。 例如,Windows采用消息响应机制来处理各种事件,所有消息都可以通过系统API调用GetMessage获取,系统会调用消息处理函数WndProc(HWND hwnd、UINTiMsg、WPARAM wParam、LRARAM 1Param),在其中处理和传递不同的事件。其大致实现过程如下: void GetAndStoreNextKVMEvent(bool_t forever,ulong64 waitUntil){ MSG msg; …… while(GetMessage(&msg,NULL,0,0)){ …… TranslateMessage(&msg); DispatchMessage(&msg); if(gotEvent){ StoreMIDPEvent(&kvmEvent); Return; } } return; } static LRESULT CALLBACK WndProc (HWND hwnd,UINT iMsg,WPARAM wParam,LPARAM lParam){ …… switch(iMsg){ case WM_CREATE: …… case WM_KEYDOWN: case WM_KEYUP: …… } } MIDP在GetAndStoreNextKVMEvent中获取事件后,就完全独立地传递和处理事件消息,与平台无关,因此无需移植。    2.2 文件系统 基于MIDP的JAVA应用以及MIDP本身在某些时候要求数据能够长期保存,即使在应用退出或系统掉电的情况下,数据也不能丢失。这就必须借助于MIDP的文件系统。MIDP的文件系统同样分为JAVA层(称为RMS,即Record Manage System)和本地方法层。一般情况下,文件系统的JAVA层不用移植就可以在任何平台上运行,但如果目标平台的文件系统较为特殊,例如采用数据库的记录方式保存数据,甚至根本就没有提供高效的数据存取接口,我们就必须自己实现数据存取接口。这样,JAVA层就需要跳过RMS而直接通过本地方法调用本地接口,相应的RMS的JAVA代码就可以从MIDP中删去。 而在文件系统的本地方法层,MIDP会调用目标平台的数据存取接口来实现MIDP本身的数据存取。这些接口是平台相关的,是文件系统中需要移植的部分。这些调用被放在文件src/share/native/storage.c中,主要包括文件的打开(open)、文件的关闭(close)、文件的读写(read、write)、文件属性的获取(size、freesize等)、文件的删除(delete)、文件的定位(seek)、文件的删节(truncate)等。以下便是MIDP文件系统在Windows下的部分实现。 文件的打开: int storageOpen(char**ppszError,char*pszAsciiFilename,int ioMode){ …… handle=open(pszAsciiFilename,flags,creationMode); …… } 文件的关闭: void storageClose(char**ppszError,int handle){ …… status=close(handle); …… } 文件的读取: int storageRead(char**ppszError,int handle,char*buffer,int length) { …… bytesRead=read(handle,buffer,length); …… } 文件的写入: void storageWrite(char**ppszError,int handle,char*buffer,int length){ …… bytesWritten=write(handle,buffer,length); …… } 还有许多其它有关文件的操作,移植时只需使用目标平台的API替换以上的Widnows调用,这里就不再逐一列举。 2.3 用户图形化接口 用户图形化接口包括画点、画线、作圆、作椭圆、位图拷贝等基本作图函数(可在GRAPHICS.C中找到);有关定时器、屏幕刷新和键盘触控笔消息等有关与用户交互的操作(可在TEXT.C中找到),它是整个MIDP移植中工作量最大,也是对上层应用的执行效率影响最大的一个部分。这是因为用户在应用中看到的各种图形和文字都是调用底层的图形函数在屏幕上作图的结果。由于屏幕要频繁刷新,图形函数也就成为应用调用最多的接口。因此,移植者必须使每一个底层作图函数与硬件设备紧密配合起来,并使用最高效的算法。 在不同的平台上,能最大地发挥其作图功能的函数和算法不尽相,这就要求移植者作大量细致的工作,按照MIDP规范的要求逐一重新实现每一个作图函数和屏幕刷新函 数。下面我们就以将画线函数和位图拷贝函数在Windows上的实现为例,简单说明移植要做的工作(键盘、触控笔是以事件消息的方式实现的,它们的移植与事件消息的移植相同)。 Windows的画线函数接口: Void LCDUIdrawLine(int pixel,short*clip,void*dst,int dotted,int x1,int y1,int x2,int y2){ …… Polyline(hdc,pts,2);/*绘x1,y1点像素信号*/ …… } Windwos的屏幕刷新函数: Void refreshPaintWindow(int x1,int y1,int x2,int y2){ RECT r; If(x1<x2){ r.left=x1+x_offset;r.right=x2+x_offset; }else{ r.left=x2+x_offset;r.right=x1+x_offset; } if(y1<y2){ r.top=y1+y_offset;r.bottom=y2+y_offset; }else{ r.top=y2+y_offset;r.bottom=y1+y_offset; } ++r.bottom;++r.right; InvalidateRect(hMainWindow,&r,KNI_TRUE); } 如果目标平台对这些GUI接口函数有不同实现法,可以用这些方法替换以上的Windows系统调用,这样才能使MIDP图形化用户接口正确地工作,并充分发挥目标平台的工作效率。 2.4 网络 MIDP的网络功能是指基于MIDP的J2ME应用可以通过HTTP等网络协议进行下载安装,不同的MIDlet实体也可以通过它交换信息,实现资源共享。遵循HTTP协议的规定,移植者必须利用目标平台的底层网络接口重新实现网络的初始化(networkInit)、建立连接(open0)、断开连接(close0)、接收数据(read0)、获取缓冲区的剩余空间(available0)、关闭发送(shutdownOutput)。如果目标设备具有服务器功能,还要实现serversocket所有上述功能。所有上述接口都在文件socketProtocol_md.c中实现。 Windwos中获取IP地址的实现: Int prim_com_sun_midp_io_j2me_socket_Protocol_getIpNumber (char*host) { …… hp=gethostbyname(host); …… } 如果目标平台还需要其它网络协议(datagram、comm),其移植过程与Socket的移植基本相同。 2.5 应用管理系统(AMS) MIDP的应用管理系统(application management system)负责管理当前设备中安装的J2ME应用,其功能包括MIDlet的加载、安装、显示、更新和删除。AMS从main.c中的函数main()开始执行,根据其输入初始化一些系统参数,包括系统路径(classJ2ME MIDP 移植 平台无关 本地代码)、堆空间大小(heapsize)、命令行(command line)等,然后就启动KVM,而KVM就会从AMS的JAVA界面main.java开始解释执行java代码。AMS的所有管理功能都是用JAVA语言实现的,因此AMS的实现是与平台无关的。但不同的平台可能有不同的系统参数和格式,对AMS的界面网络也可能有不同的要求。所以,移植者有可能要修改main.c中解析系统参数的部分,保证AMS能正确解析目标平台的所有参数;同时修改AMS的JAVA层,使其界面网络满足用户的需求。 2.6 多媒体 MIDP2.0较MIDP1.0最大的改变就是在MIDP2.0中向应用提供了音频接口(Audio API)的支持。音频接口是移动设备媒体接口MMAPI(Mobile Media API)的一部分。音频的播放过程为5个部分(unrealized、realized、prefetched、started、closed),同时它有自己的音频播放事件的传道和处理过程。MIDP音频播放部分所要做的移植工作就主要集中在声音播放接口,事件的处理方式和兼容不同的音频文件格式上。 播放接口的移植:不同的目标平台,提供的音频系统API是不同的,有的系统甚至根本没有提供播放音频的API。这时,移植者就要根据目标平台的实现情况替换或自己实现音频的播放接口。 Windows的音频播放接口(win32/native/MMATONE.C): Java_javax_microedition_media_Manager_nPlayTone(KNITRAPS) { …… chn1=getMidiChnl(); if(chnl==-1){ KNI_ReturnInt(0); } tones[chn].msg=((note&0xff)<<8)|0x00000090|(chnl&0xf); msg=((vol&0xff)<<16)|((note&0xff)<<8)|0x90|(chnl &0xf); midiOutShortMsg(midiOut,msg); timerID=timeSetEvent(dur,TIMERES,(LPTIME CALLBACK)timeToneProc,(DWORD)chnl,TIME_ONESHOT); tones[chnl].timerID=timerID; …… } 事件传递的移植:MIDP中音频播放结束的事件(EOM)是专门通过系统的消息机制传递,而不是通过MIDP的事件传递,因此也需要移植: Windows---OM的传递(win32/native/MMAEVT.C):void injectNativeEvent(int pID,int curMTime){ PostMessage(hMain Window,WM_APP,(WPARAM)(pID),(LPARAM)(curMTime)); return; } 3 总结 综上所述,MID2.0的移植要以两个方面为出发点:①兼容性。移植后的MIDP实现必须能够在目标平台上正常运行,所有与目标平台不兼容的调用都必须替换为能完成相同功能且兼容的目标平台的系统调用或过程。②高效性。移植后的MIDP实现必须能充分发挥目标平台的效率和特性,用最小的代价完成MIDP的功能。另外,MIDP的移植还要分满足最终用户的个性化要求,为它们设计出丰富多彩的界面网络。

    时间:2004-12-09 关键词: 2.0 midp 设计教程

  • 微型抢占式多任务实时内核设计

    摘要:介绍引入事件驱动观念的抢占式多任务微型实时内核——MicroStar的设计与实现;提出基于事件的优先级这一新概念。     关键词:事件驱动 优先级 任务管理 消息 信号 同步     市面上有很多优秀的嵌入式实时操作系统(RTOS),但在中低端微控制器(MCU)上运行性能良好的RTOS内核并不多。在高档机下,功能强大、运行极好的嵌入式实时操作系统,移植到中低端机上时性能很可能大幅度下降。一个很重要的原因就是它的大部分功能对中低档系统来说是不需要的,反而成为制约性能的累赘。中低档微控制器与高档机相比,一方面,寻址能力有限,处理速度慢,在相同的实时性能要求下,对内核的代码效率的要求更为严格;另一方面,中低档机完成的任务相对简单,减少了对内核的功能需求,比如可以不需要内存管理。从嵌入式系统的共性来说,大多数情况下用户程序和系统内核是紧密结合在一起的,运行时存储器容量消耗、任务的数量、执行时间和结果都是可以预计的,这可进一步缩小对内核的功能需求。 ??事件驱动的观点认为,任务应该是被动地响应外界发生的各种事件,而不是主动地去“查询”,浪费处理器时间。采用事件驱动编程的方法,不仅提高了运行效率,而且降低了事件处理之间的耦合,使程序流程非常清晰,从而可大大提高开发效率。 ??充分考虑中低端微控制器的硬件特点和嵌入式系统软件的需求,引入“事件驱动”的观念,笔者开发了一个微型的抢占式多任务RTOS内核——MicroStar。支持任务的动态创建、删除、睡眠、挂起和恢复,提供消息(message)和信号(signal)两种任务间的通信方案、完善的定时器服务和功能齐全的任务同步函数库。限于篇幅,着重论述几个与众不同的设计思路和实现难点。 1 调度策略     1.1 基于事件的优先级 ??对内核的实时性能来说,调度策略是关键。好的调度策略,既要体现各任务因所处理的事件对实时性的不同要求而带来的优先级差异,又要保证一定的公平性,避免出现低优先级任务长时间得不到执行的极端情形。常用的调度策略有两种:一种是按时间片轮转(round robin)调度,如RTX51;另一种是严格按优先级的占先式调度,如μC/OS。 ??按时间片轮转调度能很好地保证公平,但优先级的差异是通过对处理器的占用时间的多少来体现的。如果各个任务都不主动放弃执行,高优先级的任务能够比低优先级任务获得更多的处理器时间;但在嵌入式系统中,某个事件要求实时处理,并不意味着该处理需要较长的时间,而往往是要求尽快响应。因此,采用按时间片轮转调度,实时性不会太好。 ??如果严格按任务的优先级来调度,可极大地提升系统的实时性,但却欠缺公平。如果高优先级任务是个无等待的死循环,低优先级任务就无法获得执行机会。 ??一个好的办法是两者的结合,即可由任务的优先级产生调度,也可以由时间片到产生新的任务调度,如VxWorks;但是实现起来较为复杂,不一定适合中低档MCU。为此,基于以下事实,提出“基于事件的优先级(events based priority)”这一新观念。 ??① 一个任务往往处理多个事件,各个事件对实时性的要求不尽相同。一般的RTOS下,任务的优先级是根据这些事件中对实时性要求最高的一个来确定的。因此,高优先级任务在处理对实时性要求不高的事件时,完全可能会妨碍低优先级任务处理具有一定实时性要求的事件。 ??② 有些情况下,对同一事件的处理可分为前台处理和后台处理:前台处理所需时间短,对实时性有较高的要求;后台处理花费时间长,对实时性则无多大要求。 ??如果根据正在处理和等待处理的事件对实时性的不同要求,更细致地按事件处理的前后台阶段,动态地调整任务的优先级,采用优先级调度策略,既可发挥实时性好的优点,又可在一定限度内保证公平。这种情况下,任务的优先级不再是一成不变的,而是动态地取决于所处理的事件和处理阶段,这就是所谓的“基于事件的优先级”。     1.2 在MicroStar中的实现 ??MicroStar中任务的优先级是由静态优先级和动态优先级共同决定的。静态优先级等同于其它RTOS中的优先级;动态优先级为基于事件的优先级——由内核根据任务正在处理和等待处理的事件动态调整。静态优先等级限定为0~15级,不允许创建静态优先级相同的任务。动态优先等级目前只有0(亦称紧急级)、1(亦称普通级)两级。任务的实际优先等级可由下式来计算: ??优先等级=动态优先等级×16 + 静态优先等级。 ??优先等级值越大,优先级越低。可以看出,动态优先级起决定作用。 ??怎样实现优先级动态可调呢?首先简要介绍MacroStar中任务的四个状态: ??休眠(dormant)——任务因调用睡眠函数、挂起函数或者等待内核同步对象而进入休眠态; ??等待(waiting)——任务因等待消息或者信号(勿与“信标”、“信号量”相混淆)而进入等待态; ??就绪(ready)——任务运行的条件都已俱备,只等被调度,称为就绪态,亦称可调度态; ??运行(running)——任务正在使用处理器的资源,称为运行态。 ??这些状态都是用标志位来实现的。16个静态优先级对应的任务的某一状态刚好可用一个16位的二进制数来标识。休眠态用os_slpState来表示,从高位算起,第N位为0表示静态优先级为N的任务处于休眠态。等待态是依据“事件驱动”观念而专为消息和信号而设计的,用os_rdyhState和os_rdyState两个16位的变量来记录。只有当os_rdyhState和os_rdyState的第N位均为0时,才表示静态优先级为N的任务处于等待态。如果任务处于非等待状态,意味着任务已在处理事件或者有事件要处理(可以认为任务一开始就处理“启动”这个“虚拟事件”),这时,才有动态优先级的概念。如果os_rdyhState中的第N位为1,表示静态优先级为N的任务的动态优先级为紧急级;如果os_rdyhState第N位为0,则表示静态优先级为N的任务的动态优先级为普通级。要求实时处理的事件发生后,内核简单将os_rdyhState相应位置1,提升任务的动态优先级;当前事件处理完毕后,如果已无实时性要求较高的事件等待处理,简单地将os_rdyhState相应位清0,降低任务的动态优先级。由此,即可实现优先级的动态可调。只有当任务既不处在休眠态也不处在等待态时,任务才是可以调度的。 2 任务管理     2.1 任务控制块 ??多任务系统中用任务控制块(TCB)来记录任务的各种属性。在这些属性中,最重要的是任务堆栈栈顶地址。进行上下文切换(context switch)时,被停止执行的任务的所有寄存器状态、下一条代码的地址都要入栈保护,因而这个属性是必需的。如果允许修改任务的优先级,优先级属性也是必需的。所以,将任务控制块简化如下: typedef struct{ uint_16 msg[2]; /*消息接收区*/ int * sp; /*堆栈栈顶指针*/ uchar priority; /*静态优先级*/ uchar reserved; /*保留 */ }TCB,*PTCB; TCB os_tcbs[ USER_TASK_NUM +1 ]; /*用户任务数最多为15个*/ ??msg用来存储发送给任务的消息,两个16位的二进制可按位存放32个消息。sp指向任务堆栈栈顶。priority记录任务的静态优先级。数组os_tcbs用来记录系统所有任务的信息,其下标与任务的ID号相对应,即ID号为N的任务的控制块为os_tcbs[N]。 2.2 任务的创建 os_CreateTask函数用来创建一个任务: void os_CreateTask( TASKPROC task, //任务函数的指针 uchar taskId, //任务的ID号 uchar priority, //优先级 int  * pStack, //任务堆栈栈底地址 void * param //任务函数的入口参数 ); typedef void (*TASKPROC)( void * param); ??创建任务时,内核要做以下几方面的工作:① 初始化任务控制块;② 初始化任务堆栈,使其如同被其它任务抢断时的情形;③ 将任务状态置为就绪态。该函数是依赖于处理器的,图1是较为通用的描述。 ??中断程序中,在高优先级任务剥夺低优先级任务之前,内核将断点时的各寄存器状态入栈保护,这部分区域即为寄存器映像区。将任务退出函数os_Exit的地址先于任务函数MyTask入栈,以使MyTask函数退出后返回到os_Exit中去,由此来实现任务的自动删除。     2.3 任务切换 ??与任务创建一样,任务切换代码与硬件相关。在PC机上,代码和步骤如下:  void interrupt os_Schedule( )  …………(1) { if( os_nLayers )return; os_nLayers++;   …………(2) _DX = (int)os_pCurTCB; /*os_pCurTCB指向当前任务的控制块*/   *(int*)(_DX+4) = _SP;   *(int*)(_DX+6) = _SS; …………(3)   os_GetReadyTask( ); …………(4)   _DX = (int)os_pCurTCB;   _SP = *(int*)(_DX+4);   _DX = *(int*)(_DX+6);   _SS = _DX;   …………(5)   os_nLayers--;?   …………(6)   UNLOCK_INT( );     }   …………(7)     (1)利用C语言interrupt关键字使各寄存器入栈保护。(2)锁定调度器,不允许重调度。(3)将当前任务的栈顶地址(由堆栈段寄存器SS和栈指针寄存器SP组成)保存在os_pCurTCB->sp中(PC机下,TCB中的sp定义为远指针类型)。(4)选出优先级最高的就绪任务(方法类似于μC/OS),并将os_pCurTCB指向新任务的控制块。(5)栈寄存器指向新任务的栈顶地址。(6)解锁调度器。(7)各寄存器出栈,恢复到上次被中断时的情形。 3 消息与信号 ??为很好地支持事件驱动编程,MicroStar借鉴了Windows的“基于消息,事件驱动”观念,并加以扩展。在MicroStar中,事件不仅可以触发消息、信号,而且由事件触发的消息或信号是有优先级的,这是因为不同事件对处理的实时性要求是不同的。内核正是根据消息、信号的优先级来动态调整任务的动态优先级的。     3.1 消 息 ??消息是一种很友好的通信方式。考虑中低档单片机的内存容量和需求,将消息简化为一个0~31的值。采用固定位图存储格式,将这32个值映射到任务控制块的msg域,这大大减小了存储空间。可将msg域看作一个32位的二进制变量,第i位为1,表示有值为i的消息,因此消息的存取只需通过简单的“与”、“或”运算。消息的优先级依值而定,值越大,优先级越低。在系统范围内,消息优先级又分为两级:紧急级(值0~15)与普通级(值16~31)。当有紧急消息发送给任务时,内核会提升任务的动态优先级,从而提高消息处理的实时性。当任务无紧急消息要处理时,内核就降低它的动态优先级。发送消息的核心代码如下: /*const uint_16 os_maskTable[16] ={ 0x8000,0x4000, .....,0x0008,0x0004,0x0002,0x0001 */ if( msg&0xF0 ) { /*普通级消息*/ pTCB->msg[1] |= os_maskTable[msg&0x0F]; /*普通级消息存在msg[1]中*/ os_rdyState |= os_maskTable[pTCB->priority]; } else { /*紧急级消息*/ pTCB->msg[0] |= os_maskTable[msg]; ; /*紧急级消息存在msg[0]中*/ os_rdyhState |= os_maskTable[pTCB->priority]; /*提升动态优先级*/ } ??与先进先出(FIFO)方式的消息队列不同,内核总是取出优先级最高的消息来交给任务处理。消息接收函数os_GetMessage设计思路如下:如果消息接收区中无紧急消息,则降低任务的动态优先级;如果消息接收区中有消息,则取出优先级最高的消息;如果没有消息,则将任务转为等待态。考虑有时候不希望任务进入等待态,MicroStar还提供了非阻塞的os_PeekMessage消息接收函数。     3.2 信 号 ??在嵌入式系统编程中,常利用标志位来实现前后台程序或不同的任务间的通信。MicroStar也提供了类似的任务间的通信方式——信号(signal)。它避免了用户程序因不断查询标志位而带来的时间浪费,而且支持信号间的“与”、“或”运算。通俗来说,信号就是标志位,用来标识某个事件的发生。同消息一样,信号也有紧急级与普通级之分。与消息不同的是,信号完全由用户程序创建和维护,内核只是帮助用户程序等待信号,以避免低效率的标志位查询。使用起来不如消息直观,但执行效率较高。实现起来非常简单,请参见源码。图14 定时器 ??定时器在嵌入式系统有着大量的用途,如LED的定时刷新、串口通信中的超时检查。对定时器的需求分为两类,一种是周期性重复定时,比如每隔10ms去刷新LED;另一种是仅需定时一次的一次性定时。定时时长以系统时钟节拍(tick,又译作滴达)作为单位。两次系统定时中断之间的时间间隔为一个节拍。定时器结构体如下: typedef struct{ uint_16 elapse; /*定时时长的余值*/ uint_16 backTime; /*定时时长的备份值*/ MSG timerId; /*定时器ID号*/ uchar taskId; /*拥有该定时器的任务的ID*/ TIMERPROC lpTimerFunc; /*定时调用的函数指针*/ }TIMER,*PTIMER; TIMER os_timers[USER_TIMER_NUM]; /*最多为16个*/ ??周期性定时和一次性定时是通过timerId来区分的。如果timeId为64,为一次性定时;如果timerId不大于32,则为周期性定时。用os_timers数组记录定时器信息,用16位的os_timerState表示定时器的状态。如果os_timerState的二进制数的第N位为1,则表示os_timers[N]空闲可用。 ??对周期性定时器,每隔定时时长的时间,内核就调用的lpTimerFunc指向的函数,并且将timerId以消息的方式发送给任务,对任务的动态优先级的影响与普通消息一样。因此,要想取得实时性较好的定时器,只需将timerId设在0~15之间。与一次性定时相关的是睡眠函数和限时等待同步对象的函数。任务使用这两个函数而进入休眠态后,在定时时间到时,内核将其恢复为就绪态,并自动释放定时器资源。系统定时处理的核心代码如下: if( !(--pTimer->elapse) ){ /*elapse减为零表示时间到*/ if( pTimer->lpTimerFunc)(*pTimer->lpTimerFunc)(pTimer-> taskId,pTimer->timerId); switch( pTimer->timerId&0xF0 ){ case SLEEP_ID: /*一次性定时*/ os_slpState |= taskMask; /*结束休眠态*/ os_timerState |= timerMask; /*释放定时器*/ break; case 0x00: /*发送紧急级定时器消息*/ pTCB->msg[0] |= os_maskTable[pTimer->timerId]; os_rdyhState |= os_maskTable[pTCB->priority ];; break; case 0x10: : /*发送普通级定时器消息*/ pTCB->msg[1] |= os_maskTable[pTimer->timerId&0x0f]; os_rdyState |= os_maskTable[pTCB->priority ];; } } 5 同 步 ??抢占式多任务下,低优先级的任务可以被高优先级任务打断执行。以常规方式访问共享变量或资源时,会出现奇怪的结果。比如,一个任务调用printf(“12345”)试图在输出设备上输出“12345”,但执行中被高优先级任务打断;而高优先级任务也调用printf(“67890”)试图输出“67890”,最终的输出结果可能是“1267890345”之类。这就是多任务环境下的任务同步问题。  ??同步方式有两种,一种为用户同步方式,不需要与内核打交道,具有速度快的优点,但只适合保护执行时间短的代码;另一种是内核同步方式,需要通过内核来实现,速度相对较慢,但可保护执行时间长的代码。     5.1 用户同步方式 ??用户方式下的同步是通过关键代码段(critical section)保护来实现。关键代码段是指这样一小段代码,它执行时必须独占对某些共享资源的访问权,不允行被其它试图访问该资源的代码打断。最简单的是得用关/开中断来实现,优点是速度极快,缺点是带来中断延迟,只适合执行时间极短的代码段。另一简单的方案是通过加锁/解锁调度器来实现,即在关键代码段执行期间禁止内核进行任务切换。采用这种方法,不会带来中断延迟,但带来了调度延迟。在MicroStar中,对os_nLayers加1即可锁定调度器,减1即可解锁。但直接利用解锁调度器来离开关键代码段并不合适。如果在关键代码段执行中,发生了中断,使更高优先级任务就绪。但由于调度器被锁定,中断程序退出时不能进行任务切换以使高优先级任务执行。因此我们希望,最好一旦调度器解锁,马上就切换到高优先级任务。为此,专门用变量os_flag的最低位作为标志位,中断程序中调用任何可以使任务就绪的系统函数都会影响到该标志位,如os_PostMessage、os_SetEvent,os_Notity。退出关键代码段时以此来判断是否需要进行任务调度。离开临界代码段时的代码如下: if( (os_flag&0x01) && (!(--s_nLayers ) ) ) {--os_Schedule( ); } 5.2 内核同步对象 ??如果要保护执行时间较长的代码,就要使用内核同步对象来同步。常用的内核同步对象有事件(event)、信标(semaphore,亦称信号量)和互斥量(mutex)。 事件对象用来通知事件或者操作已经完成,它用一个布尔值来表示该事件处于通知还是未通知状态。信标对象用于对资源进行计数。它记录了当前可用的资源数目。当用1来初始化信标对象的可用资源数目时,信标对象实际上成为了互斥对象。MicroStar提供事件和信标两种同步对象,支持查询、限时等待或无限时等待操作。内核同步对象的结构如下: typedef struct{ uint_16 waiter; /*等待列表*/ uchar num;  /*可用资源数目或者事件状态*/ uchar type; /*同步对象类型*/ }OBJECT,*POBJECT,*HOBJECT,*HEVENT,*HSEMAPHORE; ??当一个任务因等待同步对象而进入休眠态时,它的静态优先级按位存放在waiter域中。如果静态优先级为N的任务在等待某个同步对象,则waiter二进制数中第N位置1,以示等待。当type为EVENT_OBJECT时,表示事件对象,此时num为事件状态,1表示通知态,0表示未通知态;为SEMAPHORE_OBJECT时,表示信标对象,对应的num为可用资源数。 ??内核同步对象不是嵌入式多任务系统特有的,通用的多任务操作系统如Windows都提供齐全的同步函数,在此不作介绍。 6 运用和使用示例 ??在MicroStar中,各个功能模块是分开的,因而可裁减度高。移植MicroStar也比较容易,只需改写与硬件相关的任务创建和调度函数。MicroStar1.0的PC机完全版本的代码约为10KB,针对96单片机用汇编语言写成的版本为1.4KB。本文附带的演示示例,都在TC2.0下编译通过,可直接在PC机上运行。第一个示例启动了三个用户任务:① WatchTask任务在屏幕中央显示一个以10ms为计时单位的跑表。② KeyTask 任务每隔200ms读一次键盘,按“Q”键系统退出执行。③ MicroStar 任务显示MicroStar相关信息,每隔1.5s更新一帧。 ??演示程序及内核源码见本刊网站(www.dpj.com.cn)。 结 语 ??本文提出了基于事件的优先级这一观念,使任务优先级的安排更为合理。介绍了微型多任务实时内核——MicroStar的设计与实现。消息和信号两种通信方式的提供,使其对事件驱动编程有很好的支持。较为完善的定时器服务和齐全的任务同步函数库,给用户提供了更多、更灵活的选择。有限的功能,使其与其它实时操作系统相比,减小了从技术掌握上所花费的时间。加上较低的存储器消耗,总体上说,MicroStar是比较适合在中低端MCU平台上运行的。

    时间:2004-12-09 关键词: VxWorks 任务实

  • 微型抢占式多任务实时内核设计

    摘要:介绍引入事件驱动观念的抢占式多任务微型实时内核——MicroStar的设计与实现;提出基于事件的优先级这一新概念。     关键词:事件驱动 优先级 任务管理 消息 信号 同步     市面上有很多优秀的嵌入式实时操作系统(RTOS),但在中低端微控制器(MCU)上运行性能良好的RTOS内核并不多。在高档机下,功能强大、运行极好的嵌入式实时操作系统,移植到中低端机上时性能很可能大幅度下降。一个很重要的原因就是它的大部分功能对中低档系统来说是不需要的,反而成为制约性能的累赘。中低档微控制器与高档机相比,一方面,寻址能力有限,处理速度慢,在相同的实时性能要求下,对内核的代码效率的要求更为严格;另一方面,中低档机完成的任务相对简单,减少了对内核的功能需求,比如可以不需要内存管理。从嵌入式系统的共性来说,大多数情况下用户程序和系统内核是紧密结合在一起的,运行时存储器容量消耗、任务的数量、执行时间和结果都是可以预计的,这可进一步缩小对内核的功能需求。 ??事件驱动的观点认为,任务应该是被动地响应外界发生的各种事件,而不是主动地去“查询”,浪费处理器时间。采用事件驱动编程的方法,不仅提高了运行效率,而且降低了事件处理之间的耦合,使程序流程非常清晰,从而可大大提高开发效率。 ??充分考虑中低端微控制器的硬件特点和嵌入式系统软件的需求,引入“事件驱动”的观念,笔者开发了一个微型的抢占式多任务RTOS内核——MicroStar。支持任务的动态创建、删除、睡眠、挂起和恢复,提供消息(message)和信号(signal)两种任务间的通信方案、完善的定时器服务和功能齐全的任务同步函数库。限于篇幅,着重论述几个与众不同的设计思路和实现难点。 1 调度策略     1.1 基于事件的优先级 ??对内核的实时性能来说,调度策略是关键。好的调度策略,既要体现各任务因所处理的事件对实时性的不同要求而带来的优先级差异,又要保证一定的公平性,避免出现低优先级任务长时间得不到执行的极端情形。常用的调度策略有两种:一种是按时间片轮转(round robin)调度,如RTX51;另一种是严格按优先级的占先式调度,如μC/OS。 ??按时间片轮转调度能很好地保证公平,但优先级的差异是通过对处理器的占用时间的多少来体现的。如果各个任务都不主动放弃执行,高优先级的任务能够比低优先级任务获得更多的处理器时间;但在嵌入式系统中,某个事件要求实时处理,并不意味着该处理需要较长的时间,而往往是要求尽快响应。因此,采用按时间片轮转调度,实时性不会太好。 ??如果严格按任务的优先级来调度,可极大地提升系统的实时性,但却欠缺公平。如果高优先级任务是个无等待的死循环,低优先级任务就无法获得执行机会。 ??一个好的办法是两者的结合,即可由任务的优先级产生调度,也可以由时间片到产生新的任务调度,如VxWorks;但是实现起来较为复杂,不一定适合中低档MCU。为此,基于以下事实,提出“基于事件的优先级(events based priority)”这一新观念。 ??① 一个任务往往处理多个事件,各个事件对实时性的要求不尽相同。一般的RTOS下,任务的优先级是根据这些事件中对实时性要求最高的一个来确定的。因此,高优先级任务在处理对实时性要求不高的事件时,完全可能会妨碍低优先级任务处理具有一定实时性要求的事件。 ??② 有些情况下,对同一事件的处理可分为前台处理和后台处理:前台处理所需时间短,对实时性有较高的要求;后台处理花费时间长,对实时性则无多大要求。 ??如果根据正在处理和等待处理的事件对实时性的不同要求,更细致地按事件处理的前后台阶段,动态地调整任务的优先级,采用优先级调度策略,既可发挥实时性好的优点,又可在一定限度内保证公平。这种情况下,任务的优先级不再是一成不变的,而是动态地取决于所处理的事件和处理阶段,这就是所谓的“基于事件的优先级”。     1.2 在MicroStar中的实现 ??MicroStar中任务的优先级是由静态优先级和动态优先级共同决定的。静态优先级等同于其它RTOS中的优先级;动态优先级为基于事件的优先级——由内核根据任务正在处理和等待处理的事件动态调整。静态优先等级限定为0~15级,不允许创建静态优先级相同的任务。动态优先等级目前只有0(亦称紧急级)、1(亦称普通级)两级。任务的实际优先等级可由下式来计算: ??优先等级=动态优先等级×16 + 静态优先等级。 ??优先等级值越大,优先级越低。可以看出,动态优先级起决定作用。 ??怎样实现优先级动态可调呢?首先简要介绍MacroStar中任务的四个状态: ??休眠(dormant)——任务因调用睡眠函数、挂起函数或者等待内核同步对象而进入休眠态; ??等待(waiting)——任务因等待消息或者信号(勿与“信标”、“信号量”相混淆)而进入等待态; ??就绪(ready)——任务运行的条件都已俱备,只等被调度,称为就绪态,亦称可调度态; ??运行(running)——任务正在使用处理器的资源,称为运行态。 ??这些状态都是用标志位来实现的。16个静态优先级对应的任务的某一状态刚好可用一个16位的二进制数来标识。休眠态用os_slpState来表示,从高位算起,第N位为0表示静态优先级为N的任务处于休眠态。等待态是依据“事件驱动”观念而专为消息和信号而设计的,用os_rdyhState和os_rdyState两个16位的变量来记录。只有当os_rdyhState和os_rdyState的第N位均为0时,才表示静态优先级为N的任务处于等待态。如果任务处于非等待状态,意味着任务已在处理事件或者有事件要处理(可以认为任务一开始就处理“启动”这个“虚拟事件”),这时,才有动态优先级的概念。如果os_rdyhState中的第N位为1,表示静态优先级为N的任务的动态优先级为紧急级;如果os_rdyhState第N位为0,则表示静态优先级为N的任务的动态优先级为普通级。要求实时处理的事件发生后,内核简单将os_rdyhState相应位置1,提升任务的动态优先级;当前事件处理完毕后,如果已无实时性要求较高的事件等待处理,简单地将os_rdyhState相应位清0,降低任务的动态优先级。由此,即可实现优先级的动态可调。只有当任务既不处在休眠态也不处在等待态时,任务才是可以调度的。 2 任务管理     2.1 任务控制块 ??多任务系统中用任务控制块(TCB)来记录任务的各种属性。在这些属性中,最重要的是任务堆栈栈顶地址。进行上下文切换(context switch)时,被停止执行的任务的所有寄存器状态、下一条代码的地址都要入栈保护,因而这个属性是必需的。如果允许修改任务的优先级,优先级属性也是必需的。所以,将任务控制块简化如下: typedef struct{ uint_16 msg[2]; /*消息接收区*/ int * sp; /*堆栈栈顶指针*/ uchar priority; /*静态优先级*/ uchar reserved; /*保留 */ }TCB,*PTCB; TCB os_tcbs[ USER_TASK_NUM +1 ]; /*用户任务数最多为15个*/ ??msg用来存储发送给任务的消息,两个16位的二进制可按位存放32个消息。sp指向任务堆栈栈顶。priority记录任务的静态优先级。数组os_tcbs用来记录系统所有任务的信息,其下标与任务的ID号相对应,即ID号为N的任务的控制块为os_tcbs[N]。 2.2 任务的创建 os_CreateTask函数用来创建一个任务: void os_CreateTask( TASKPROC task, //任务函数的指针 uchar taskId, //任务的ID号 uchar priority, //优先级 int  * pStack, //任务堆栈栈底地址 void * param //任务函数的入口参数 ); typedef void (*TASKPROC)( void * param); ??创建任务时,内核要做以下几方面的工作:① 初始化任务控制块;② 初始化任务堆栈,使其如同被其它任务抢断时的情形;③ 将任务状态置为就绪态。该函数是依赖于处理器的,图1是较为通用的描述。 ??中断程序中,在高优先级任务剥夺低优先级任务之前,内核将断点时的各寄存器状态入栈保护,这部分区域即为寄存器映像区。将任务退出函数os_Exit的地址先于任务函数MyTask入栈,以使MyTask函数退出后返回到os_Exit中去,由此来实现任务的自动删除。     2.3 任务切换 ??与任务创建一样,任务切换代码与硬件相关。在PC机上,代码和步骤如下:  void interrupt os_Schedule( )  …………(1) { if( os_nLayers )return; os_nLayers++;   …………(2) _DX = (int)os_pCurTCB; /*os_pCurTCB指向当前任务的控制块*/   *(int*)(_DX+4) = _SP;   *(int*)(_DX+6) = _SS; …………(3)   os_GetReadyTask( ); …………(4)   _DX = (int)os_pCurTCB;   _SP = *(int*)(_DX+4);   _DX = *(int*)(_DX+6);   _SS = _DX;   …………(5)   os_nLayers--;?   …………(6)   UNLOCK_INT( );     }   …………(7)     (1)利用C语言interrupt关键字使各寄存器入栈保护。(2)锁定调度器,不允许重调度。(3)将当前任务的栈顶地址(由堆栈段寄存器SS和栈指针寄存器SP组成)保存在os_pCurTCB->sp中(PC机下,TCB中的sp定义为远指针类型)。(4)选出优先级最高的就绪任务(方法类似于μC/OS),并将os_pCurTCB指向新任务的控制块。(5)栈寄存器指向新任务的栈顶地址。(6)解锁调度器。(7)各寄存器出栈,恢复到上次被中断时的情形。 3 消息与信号 ??为很好地支持事件驱动编程,MicroStar借鉴了Windows的“基于消息,事件驱动”观念,并加以扩展。在MicroStar中,事件不仅可以触发消息、信号,而且由事件触发的消息或信号是有优先级的,这是因为不同事件对处理的实时性要求是不同的。内核正是根据消息、信号的优先级来动态调整任务的动态优先级的。     3.1 消 息 ??消息是一种很友好的通信方式。考虑中低档单片机的内存容量和需求,将消息简化为一个0~31的值。采用固定位图存储格式,将这32个值映射到任务控制块的msg域,这大大减小了存储空间。可将msg域看作一个32位的二进制变量,第i位为1,表示有值为i的消息,因此消息的存取只需通过简单的“与”、“或”运算。消息的优先级依值而定,值越大,优先级越低。在系统范围内,消息优先级又分为两级:紧急级(值0~15)与普通级(值16~31)。当有紧急消息发送给任务时,内核会提升任务的动态优先级,从而提高消息处理的实时性。当任务无紧急消息要处理时,内核就降低它的动态优先级。发送消息的核心代码如下: /*const uint_16 os_maskTable[16] ={ 0x8000,0x4000, .....,0x0008,0x0004,0x0002,0x0001 */ if( msg&0xF0 ) { /*普通级消息*/ pTCB->msg[1] |= os_maskTable[msg&0x0F]; /*普通级消息存在msg[1]中*/ os_rdyState |= os_maskTable[pTCB->priority]; } else { /*紧急级消息*/ pTCB->msg[0] |= os_maskTable[msg]; ; /*紧急级消息存在msg[0]中*/ os_rdyhState |= os_maskTable[pTCB->priority]; /*提升动态优先级*/ } ??与先进先出(FIFO)方式的消息队列不同,内核总是取出优先级最高的消息来交给任务处理。消息接收函数os_GetMessage设计思路如下:如果消息接收区中无紧急消息,则降低任务的动态优先级;如果消息接收区中有消息,则取出优先级最高的消息;如果没有消息,则将任务转为等待态。考虑有时候不希望任务进入等待态,MicroStar还提供了非阻塞的os_PeekMessage消息接收函数。     3.2 信 号 ??在嵌入式系统编程中,常利用标志位来实现前后台程序或不同的任务间的通信。MicroStar也提供了类似的任务间的通信方式——信号(signal)。它避免了用户程序因不断查询标志位而带来的时间浪费,而且支持信号间的“与”、“或”运算。通俗来说,信号就是标志位,用来标识某个事件的发生。同消息一样,信号也有紧急级与普通级之分。与消息不同的是,信号完全由用户程序创建和维护,内核只是帮助用户程序等待信号,以避免低效率的标志位查询。使用起来不如消息直观,但执行效率较高。实现起来非常简单,请参见源码。图14 定时器 ??定时器在嵌入式系统有着大量的用途,如LED的定时刷新、串口通信中的超时检查。对定时器的需求分为两类,一种是周期性重复定时,比如每隔10ms去刷新LED;另一种是仅需定时一次的一次性定时。定时时长以系统时钟节拍(tick,又译作滴达)作为单位。两次系统定时中断之间的时间间隔为一个节拍。定时器结构体如下: typedef struct{ uint_16 elapse; /*定时时长的余值*/ uint_16 backTime; /*定时时长的备份值*/ MSG timerId; /*定时器ID号*/ uchar taskId; /*拥有该定时器的任务的ID*/ TIMERPROC lpTimerFunc; /*定时调用的函数指针*/ }TIMER,*PTIMER; TIMER os_timers[USER_TIMER_NUM]; /*最多为16个*/ ??周期性定时和一次性定时是通过timerId来区分的。如果timeId为64,为一次性定时;如果timerId不大于32,则为周期性定时。用os_timers数组记录定时器信息,用16位的os_timerState表示定时器的状态。如果os_timerState的二进制数的第N位为1,则表示os_timers[N]空闲可用。 ??对周期性定时器,每隔定时时长的时间,内核就调用的lpTimerFunc指向的函数,并且将timerId以消息的方式发送给任务,对任务的动态优先级的影响与普通消息一样。因此,要想取得实时性较好的定时器,只需将timerId设在0~15之间。与一次性定时相关的是睡眠函数和限时等待同步对象的函数。任务使用这两个函数而进入休眠态后,在定时时间到时,内核将其恢复为就绪态,并自动释放定时器资源。系统定时处理的核心代码如下: if( !(--pTimer->elapse) ){ /*elapse减为零表示时间到*/ if( pTimer->lpTimerFunc)(*pTimer->lpTimerFunc)(pTimer-> taskId,pTimer->timerId); switch( pTimer->timerId&0xF0 ){ case SLEEP_ID: /*一次性定时*/ os_slpState |= taskMask; /*结束休眠态*/ os_timerState |= timerMask; /*释放定时器*/ break; case 0x00: /*发送紧急级定时器消息*/ pTCB->msg[0] |= os_maskTable[pTimer->timerId]; os_rdyhState |= os_maskTable[pTCB->priority ];; break; case 0x10: : /*发送普通级定时器消息*/ pTCB->msg[1] |= os_maskTable[pTimer->timerId&0x0f]; os_rdyState |= os_maskTable[pTCB->priority ];; } } 5 同 步 ??抢占式多任务下,低优先级的任务可以被高优先级任务打断执行。以常规方式访问共享变量或资源时,会出现奇怪的结果。比如,一个任务调用printf(“12345”)试图在输出设备上输出“12345”,但执行中被高优先级任务打断;而高优先级任务也调用printf(“67890”)试图输出“67890”,最终的输出结果可能是“1267890345”之类。这就是多任务环境下的任务同步问题。  ??同步方式有两种,一种为用户同步方式,不需要与内核打交道,具有速度快的优点,但只适合保护执行时间短的代码;另一种是内核同步方式,需要通过内核来实现,速度相对较慢,但可保护执行时间长的代码。     5.1 用户同步方式 ??用户方式下的同步是通过关键代码段(critical section)保护来实现。关键代码段是指这样一小段代码,它执行时必须独占对某些共享资源的访问权,不允行被其它试图访问该资源的代码打断。最简单的是得用关/开中断来实现,优点是速度极快,缺点是带来中断延迟,只适合执行时间极短的代码段。另一简单的方案是通过加锁/解锁调度器来实现,即在关键代码段执行期间禁止内核进行任务切换。采用这种方法,不会带来中断延迟,但带来了调度延迟。在MicroStar中,对os_nLayers加1即可锁定调度器,减1即可解锁。但直接利用解锁调度器来离开关键代码段并不合适。如果在关键代码段执行中,发生了中断,使更高优先级任务就绪。但由于调度器被锁定,中断程序退出时不能进行任务切换以使高优先级任务执行。因此我们希望,最好一旦调度器解锁,马上就切换到高优先级任务。为此,专门用变量os_flag的最低位作为标志位,中断程序中调用任何可以使任务就绪的系统函数都会影响到该标志位,如os_PostMessage、os_SetEvent,os_Notity。退出关键代码段时以此来判断是否需要进行任务调度。离开临界代码段时的代码如下: if( (os_flag&0x01) && (!(--s_nLayers ) ) ) {--os_Schedule( ); } 5.2 内核同步对象 ??如果要保护执行时间较长的代码,就要使用内核同步对象来同步。常用的内核同步对象有事件(event)、信标(semaphore,亦称信号量)和互斥量(mutex)。 事件对象用来通知事件或者操作已经完成,它用一个布尔值来表示该事件处于通知还是未通知状态。信标对象用于对资源进行计数。它记录了当前可用的资源数目。当用1来初始化信标对象的可用资源数目时,信标对象实际上成为了互斥对象。MicroStar提供事件和信标两种同步对象,支持查询、限时等待或无限时等待操作。内核同步对象的结构如下: typedef struct{ uint_16 waiter; /*等待列表*/ uchar num;  /*可用资源数目或者事件状态*/ uchar type; /*同步对象类型*/ }OBJECT,*POBJECT,*HOBJECT,*HEVENT,*HSEMAPHORE; ??当一个任务因等待同步对象而进入休眠态时,它的静态优先级按位存放在waiter域中。如果静态优先级为N的任务在等待某个同步对象,则waiter二进制数中第N位置1,以示等待。当type为EVENT_OBJECT时,表示事件对象,此时num为事件状态,1表示通知态,0表示未通知态;为SEMAPHORE_OBJECT时,表示信标对象,对应的num为可用资源数。 ??内核同步对象不是嵌入式多任务系统特有的,通用的多任务操作系统如Windows都提供齐全的同步函数,在此不作介绍。 6 运用和使用示例 ??在MicroStar中,各个功能模块是分开的,因而可裁减度高。移植MicroStar也比较容易,只需改写与硬件相关的任务创建和调度函数。MicroStar1.0的PC机完全版本的代码约为10KB,针对96单片机用汇编语言写成的版本为1.4KB。本文附带的演示示例,都在TC2.0下编译通过,可直接在PC机上运行。第一个示例启动了三个用户任务:① WatchTask任务在屏幕中央显示一个以10ms为计时单位的跑表。② KeyTask 任务每隔200ms读一次键盘,按“Q”键系统退出执行。③ MicroStar 任务显示MicroStar相关信息,每隔1.5s更新一帧。 ??演示程序及内核源码见本刊网站(www.dpj.com.cn)。 结 语 ??本文提出了基于事件的优先级这一观念,使任务优先级的安排更为合理。介绍了微型多任务实时内核——MicroStar的设计与实现。消息和信号两种通信方式的提供,使其对事件驱动编程有很好的支持。较为完善的定时器服务和齐全的任务同步函数库,给用户提供了更多、更灵活的选择。有限的功能,使其与其它实时操作系统相比,减小了从技术掌握上所花费的时间。加上较低的存储器消耗,总体上说,MicroStar是比较适合在中低端MCU平台上运行的。

    时间:2004-12-09 关键词: 任务实 设计教程

  • 使用C++构建嵌入式开发框架

     摘要:框架作为一种大粒度的重用技术在桌面软件开发中得到了广泛应用,而在嵌入式开发领域,目前还没有一套完整的标准框架可供使用。本文以通信领域的嵌入式软件开发为例,介绍使用C++语言,在ARM平台Nucleus plus操作系统下实现嵌入式开发框架EFC的方法和应用实例。     关键词:框架 C++ ARM Nucleus MFC EFC 面向对象 1 框架概述 1.1 什么是框架 国外著名的软件设计大师Ralph Johnson对面向对象技术进行了长期而深入的研究。在他的主页中,对框架进行了如下定义:A framework is a reusable design expressed as a set of abstract classes and the way their instances collaborate.It is a reusable design for all or part of a software system.(框架是整个系统或系统的一部分的可重用性设计,由一组抽象出来的类及其实例间的相互作用方式组成。) 框架把一个系统有机地分解成一组相对独立的构件,并定义了各个构件间的接口和作用关系,符合软件工程中设计的模块化、独立化和信息隐藏等特征。框架提供了一个大粒度的重用技术,即不仅支持源代码级的重用,而且支持分析和设计以及体系结构的重用,因而被认为是一种最有前途的面向对象技术。 框架必须是健壮的、可扩展的、灵活的,它要求基于开放或共享标准。框架的设计要力求做到完备性、灵活性、可扩展性、可理解性,同时抽象能用于不同的场合;用户能轻松地添加和修改功能,定制框架;用户和框架的交互清晰,文档齐全。框架设计的一个核心问题就是发现可重用的设计和“热点”,以保证框架具备充分的灵活性,使用户能在已有构件的基础上生成应用程序,实现“零代码编写”的理想目标。    1.2 如何设计框架 目前框架的设计大都采用实践法。实践法是指从若干个具体的典型应用中,抽象出现似点来构建框架;框架反过来又应用于不同的问题,并在解决不同问题的过程中得到更新;在框架的设计和实现的两步中,不断反复,等到框架逐渐成熟时,需要修改和反复的内容就会越来越小。具体步骤为:分析问题域,确定所需框架,从一类应用而不是单个的程序去分析、比较各种不同的软件解决方案,寻求这些方案的共性和每个程度的唯一性特性。这些共性,尤其是那些经常被多个程序使用的部分将成为框架的基础。然后,定义框架体系结构并设计,包括设计用户与框架间的交互、给用户提供的最终工具等。 框架的实现:包括框架核心类的实现、框架的测试、框架的试运行、框架的反复更新。 框架的部署:包括文档的提供和分发过程、为用户提供技术支持、维护和更新框架。 2 嵌入式框架EFC 框架技术在桌面软件的开发中得到了广泛的应用,但在嵌入式开发领域,由于嵌入式开发的多样性及嵌入式操作系统的多样性,目前还没有一套完整的开发框架可供使用。因此,在嵌入式软件开发中常常是从底层做起,应用程序和RTOS密不可分。这样的开发方式不但效率不高,也不利于软件的移植。 EFC(Embedded Foundation Classes)即嵌入式基础类库,是笔者借鉴Microsoft公司的MFC(微软基础类库—桌面系统框架库的工业标准)构建的一套在ARM平台Nucleus plus操作系统下的嵌入式开发框架。由于框架全部采用C++开发,没有和处理器相关的汇编代码,所以在其它硬件平台可不加修改地使用。如果更换不同的操作系统,则需要修改操作系统抽象层的部分代码;但由于EFC提供给上层应用程序的接口不变,所以应用程序不需要修改代码。图2 EFC静态结构图    就软件的层次来说,EFC是一个操作系统之上、应用程序之下的中间件,如图1所示。在EFC中有一个操作系统抽象层,对RTOS进行了抽象和封装,提供包括任务(task)、/O驱动(driver)、定时器(timer)、信号量(semaphore)、消息队列(quecue)、事件(event group)、邮箱(mailBox)、管道(pipe)以及高级中断(HISR)等基本服务的封装。为上层应用程序提供更高级的统一编程接口,它样就使应用软件的开发与具体的软件平台无关,解决了嵌入式应用软件的移植问题。 在图1中,各模块之间有交界表明模块之间有接口关系。EFC、应用程序以及RTOS都和硬件驱动有接口:EFC要使用一部分核心驱动(例如实时时钟的驱动、ARM串口和网口的驱动、I2C总线的驱动等);应用程序中调用的驱动是针对具体设备的;RTOS所需要的驱动就是系统的BSP部分。 EFC的静态结构图(类图)如图2所示。类图是在UML(统一建模语言)中用类和它们之间的关系描述系统的一种图示。类用类名、类的属性以及操作来表示,在图中为简单起见,省略了属性和操作;类与类之间的关系使用不同的连线表示,图中带空心三角箭头的连线表示继承关系,两端带数字的连线表示关联关系。在类图中,类的属性/方法的可见性使用“+”、“-”及“#”表示:“+”表示公共的(public),“-”表示私有的(private),“#”表示受保护的(protected)。 从图2中可以看出,CMessage、CRTApp、CDevice、Cboard及Cinterface都派生于公共的类CRTObject。CRTApp对象中有受保护的CMessage、CEventLog、Cuser及CDevice各一个。CDevice对象中有一个或多个CBoard对象,相应的每个CBorad对象中有0个到多个CxxxInterace对象。 2.1 基本数据类型 构建一个框架,需要一些基本的元素,这些元素要在框架的构造以及应用程序开发中大量使用。这些基本数据类型包括字符串类CString、集合类CArray、Clist及Cmap。CString包括一个长度可变的字符序列,提供使用非常直观方便的运算符(例如+,+=,=,==,!=)和一些Todouble()、Tolong()、Tohex()等);CArray是具有内建索元素很快的检索速度;Clist为其所存储的每一个元素,都提供了两个指针,分别指向位于其前和其后的元素,形成一个双向链表,这使得插入和删除操作十分快捷;CMap为其存储的每个数据都附带一个关键字,并以关键字所组成的一个hash表作为索引,从而使得元素搜索、增加和删除操作都具有很高的效率。 2.2 RTOS的抽象和封装 CRTObject是一个EFC中最基础的类,它不但是EFC中CRTApp、CDevice等类的基类,而且可以作为所有使用EFC的嵌入式开发人员定义新的类的超类。CRTObject类在EFC中主要承担RTOS抽象和封装任务。它提供了下面一些最基本的功能: *CRTObject对RTOS的常用对象进行了封装,提供包括Task、Driver、Timer、Event Group、Semaphore、Queue、Pipe、Mailbox等的创建、删除、查找等功能的成员函数。这些函数提供了一个简单有效的方法来使用RTOS的对象。使用这些函数能够保证对象创建与销毁的安全性,而不会造成内存泄漏。 *CRTObject提供了对RTTI(Run-Time Type Information,运行时类型信息)的支持,在新的C++标准中,RTTI已经是C++的一个功能,但并不是所有的编译器都提供支持这些新特性,ADS1.2就不支持。所以在这里参考MFC,通过宏的方式为每个类定义一个CRuntimeClass类型的静态常量和相关的成员函数。CRuntimeClass结构保证了类型的静态常量和相关的成员函数。CRuntimeClass结构保存了类的名称、大小等信息,这样我们就能在程序运行时确定对象的具体类型。 *CRTObject还提供了把类的成员函数作为任务及定时器的回调函数的功能。在Nucleus中,任务和定时器的回调函数只能是全局函数或者类的静态成员函数,这在面向对象的开发中很不方便。这里通过把成员函数指针和对象的this指针作为参数传递给RTOS,在RTOS调用公共回调函数时再取出来。通过函数指针的方式去调用类的成员函数,这样把有派生于CRTObject的类就可方便地使用成员函数作为任务、定时器等对象的回调函数。 2.3 应用程序类CRTApp CRTApp类用来定义整个应用程序对象,提供系统初始化、管理其它对象以及运行应用程序的功能。任何使用EFC框架的应用程序有且只能有一个派生于此类的对象。CRTApp对象中包含了动态创建的CMessage、CEventLog、CDevice及Cuser对象。 通过在Nucleus的入口函数Application_Initialize中创建系统初始化任务(回调函数为CRTApp类的成员函数InitTask),来把系统控制权交给CRTApp对象,在其中完成其它对象的创建、系统的配置以及初始化任务。 2.4 文件系统 在嵌入式设备中通常使用Flash存储器来保存程序代码和数据,每片Flash一般由一定数量大小不等的扇区组成。它在读取方面与普通RAM存储器类似,可以实现随机的读取,但在写入操作上却有很大的不同。Flash中只有空白的单元才可以进行写入操作,要向非空的单元写入数据,需要先擦除整个扇区。所以程序中如果直接对Flash进行操作会很不方便。最好的办法就是在其上构造一个文件系统,文件系统提供简便、可靠的接口供上层使用,而把复杂的操作屏蔽在文件系统内部。 这里文件系统包括内存文件系统和Flash文件系统。CFile是一个抽象类,只是定义文件系统的接口函数(例如Open、Read、Write、Seek、GetLength、Close等),具体的实现在CMemFile(内存文件)及CFlashFile(Flash文件)类中完成。 2.5 设备管理 在EFC中,设备管理由CDevice、CBoard、CInterface及其派生类完成。CDevice类代表整个设备,1个设备中包含1到多个CBoard对象,而每个CBoard对象中又包含0个到多个接口对象(CInterface类的派生类对象)。这样以来,嵌入式设备(仅限通信领域)都可由这几个类组合而成,大大简化了软件的设计。 2.6 命令处理 CMessage类是系统的命令处理模块,它直接派生于CRTObject类。它的功能主要是接收网管软件通过串口或网口发送未来的各种命令,完成对设备的配置管理、性能管理、告警管理、安全管理和维护管理等管理功能。CMessage类主要有表1所列的任务。表1 CMessage类中的任务 任务名称 任务处理函数 说      明 TCP服务器监听任务 TCPServerTask 用于监听客户端的连接请求 TCP响应任务 TCPEchoTask 对每客户端的连接都创建一响应任务 串口任务 UartTask 通过串口对系统进行管理 TFTP备分份任务 TFTPClientPutTask 备份应用程序和系统配置文件 TFTP升级任务 TFTPClientGetTask 用于升级应用程序及修改用户配置文件 2.7 其它模块 CFlash类封装对Flash芯片的操作,主要包括读、写、擦除等操作。从图2可以看出,CEventLog和CFlashFile类中都包含CFlash对象;CEventLog类记录系统中的发生的事件以及系统运行过程中产生的告警信息。为了实现掉电保存功能,这些事件都保存在Flash芯片中;Cuser类用来对系统的用户进行管理,防止对系统非授权的访问。 3 使用EFC的设计方案举例 这里以在通信和工业自动化领域使用较多的串口服务器为例,来说明使用FEC嵌入式开发框架的设计方案。串口服务器是一种可把多路异步RS232/RS485串行数据与通过以太网口传送的TCP/IP数据包进行相互转换,使传统的异步串行数据信息能通过Internet或Intranet传送或共享的设备。 设每个串口对应TCP/IP的一个端口,则可画出图3所示的静态结构图(图中SerSvr是Server的简写)。 从图3可以看出,共对五个类进行了派生。CSerSvrMessage类派生于CMessage类,用于通过网管对串口服务器进行管理(这里具体命令略);CserSvrDevice类派生于CDevice类,代表串口服务器设备;CserSvrDevice类对象中有一个或多个派生于CBoard类的CserSvrBoard类对象,而每个CserSvrBoard类对象拥有一个或多个派生于CasyInterface类的CSerSvrInterface类对象;ScerSvrApp类派生于CRTApp类,代表整个应用程序,并重载了虚函数OnCreateMessage()及OnCreateDevice(),用来在其中创建系统的CSerSvrMessage和CserSvrDevice类的实例来代替系统默认的CMessage和CDevice实例。图3 串口服务器系统软件静态结构图    串口类CSerSvrInterface的设计是整个设计的关键,在每个串口类中都有一个TCP监听任务TCPServerTask用来作为服务器去监听客户端的连接;一个TCP客户端任务TCPClientTask用来连接其它服务器。无论是通过TCPServerTask还是TCPClientTask建立连接后,就挂起这两个任务而启动另外两个任务TCPSendTask和TCPRecvTask,它们分别用来通过网口发送数据和接收数据。TCPSendTask每隔10ms(对波特率为115.2K的情况,10ms最多收到的字节数为115200/(8+2)/1000*10=115.2字节,所以串口的FIFO应大于116字节)把从串口读到的数据打包从网口发送出去;而TCPTecvTask使用阻塞方式读取网口数据。在读到数据后,根据串口发送缓冲区的情况慢慢通过串口往外发送,没发送完之前就不进行下一次从网口的数据读取。这样把串口类设计成一个完备的处理类,设备中每块板有多少串口就在CSerSvrBoard类的实例中有多少CSerSvrInterface类的实例。硬件模块化的结构简单地对应软件模块化的结构。 结语 本文讲述了在嵌入式软件开发中使用C++构建系统开发框架的方法,并给出了框架的模型和应用实例。可以看出,使用面向对象的框架技术对于提高开发效率、降低开发难度、规范开发模式、便于软件的移植和维护方面,具有传统面向过程的开发方法不可比拟的优势。

    时间:2004-12-09 关键词: c++ 设计教程

  • 嵌入式系统的定义与发展历史

    摘要:嵌入式系统诞生于微型机时代,经历了漫长的独立发展的单片机道路。给嵌入式系统寻求科学的定义,必须了解嵌入式系统的发展历史,按照历史性、本质性、普遍通用性来定义嵌入式系统,并把定义与特点相区分。由于嵌入式系统应用中,对象系统的广泛性与单片机的独主发展道路,使嵌入式系统应用在客观上存在两种模式,从学科建设上,可统一成嵌入式系统应用的高低端。     关键词:嵌入式系统发展史 嵌入式系统定义 应用模式 高低端应用 ??目前,在嵌入式系统应用领域中,不少人对什么是嵌入式系统不甚了解。有些人搞了十多年的单片机应用,不知道单片机就是一个最典型的嵌入式系统;也有些人在解释什么是嵌入式系统时,不是从定义出发,而是列举了嵌入式系统的一些特点,往往不知所云。因此,有必要从现代计算的发展历史,了解嵌入式系统的由来,从学科建设的角度来探讨嵌入式系统较为准确的定义。 1 现代计算机的技术发展史     (1)始于微型机时代的嵌入式应用 ??电子数字计算机诞生于1946年,在其后漫长的历史进程中,计算机始终是供养在特殊的机房中,实现数值计算的大型昂贵设备。直到20世纪70年代,微处理器的出现,计算机才出现了历史性的变化。以微处理器为核心的微型计算机以其小型、价廉、高可靠性特点,迅速走出机房;基于高速数值解算能力的微型机,表现出的智能化水平引起了控制专业人士的兴趣,要求将微型机嵌入到一个对象体系中,实现对象体系的智能化控制。例如,将微型计算机经电气加固、机械加固,并配置各种外围接口电路,安装到大型舰船中构成自动驾驶仪或轮机状态监测系统。这样一来,计算机便失去了原来的形态与通用的计算机功能。为了区别于原有的通用计算机系统,把嵌入到对象体系中,实现对象体系智能化控制的计算机,称作嵌入式计算机系统。因此,嵌入式系统诞生于微型机时代,嵌入式系统的嵌入性本质是将一个计算机嵌入到一个对象体系中去,这些是理解嵌入式系统的基本出发点。     (2)现代计算机技术的两大分支 ??由于嵌入式计算机系统要嵌入到对象体系中,实现的是对象的智能化控制,因此,它有着与通用计算机系统完全不同的技术要求与技术发展方向。 ??通用计算机系统的技术要求是高速、海量的数值计算;技术发展方向是总线速度的无限提升,存储容量的无限扩大。 而嵌入式计算机系统的技术要求则是对象的智能化控制能力;技术发展方向是与对象系统密切相关的嵌入性能、控制能力与控制的可靠性。 ??早期,人们勉为其难地将通用计算机系统进行改装,在大型设备中实现嵌入式应用。然而,对于众多的对象系统(如家用电器、仪器仪表、工控单元……),无法嵌入通用计算机系统,况且嵌入式系统与通用计算机系统的技术发展方向完全不同,因此,必须独立地发展通用计算机系统与嵌入式计算机系统,这就形成了现代计算机技术发展的两大分支。 ??如果说微型机的出现,使计算机进入到现代计算机发展阶段,那么嵌入式计算机系统的诞生,则标志了计算机进入了通用计算机系统与嵌入式计算机系统两大分支并行发展时代,从而导致20世纪末,计算机的高速发展时期。     (3) 两大分支发展的里程碑事件 ??通用计算机系统与嵌入式计算机系统的专业化分工发展,导致20世纪末、21世纪初,计算机技术的飞速发展。计算机专业领域集中精力发展通用计算机系统的软、硬件技术,不必兼顾嵌入式应用要求,通用微处理器迅速从286、386、486到奔腾系列;操作系统则迅速扩张计算机基于高速海量的数据文件处理能力,使通用计算机系统进入到尽善尽美阶段。 ??嵌入式计算机系统则走上了一条完全不同的道路,这条独立发展的道路就是单芯片化道路。它动员了原有的传统电子系统领域的厂家与专业人士,接过起源于计算机领域的嵌入式系统,承担起发展与普及嵌入式系统的历史任务,迅速地将传统的电子系统发展到智能化的现代电子系统时代。 ??因此,现代计算机技术发展的两大分支的里程碑意义在于:它不仅形成了计算机发展的专业化分工,而且将发展计算机技术的任务扩展到传统的电子系统领域,使计算机成为进入人类社会全面智能化时代的有力工具。 2 嵌入式系统的定义与特点 ??如果我们了解了嵌入式(计算机)系统的由来与发展,对嵌入式系统就不会产生过多的误解,而能历史地、本质地、普遍适用地定义嵌入式系统。     (1) 嵌入式系统的定义 ??按照历史性、本质性、普遍性要求,嵌入式系统应定义为:“嵌入到对象体系中的专用计算机系统”。“嵌入性”、“专用性”与“计算机系统”是嵌入式系统的三个基本要素。对象系统则是指嵌入式系统所嵌入的宿主系统。     (2) 嵌入式系统的特点 ?? 嵌入式系统的特点与定义不同,它是由定义中的三个基本要素衍生出来的。不同的嵌入式系统其特点会有所差异。 ??与“嵌入性”的相关特点:由于是嵌入到对象系统中,必须满足对象系统的环境要求,如物理环境(小型)、电气/气氛环境(可靠)、成本(价廉)等要求。 ??与“专用性”的相关特点:软、硬件的裁剪性;满足对象要求的最小软、硬件配置等。 ??与“计算机系统”的相关特点:嵌入式系统必须是能满足对象系统控制要求的计算机系统。与上两个特点相呼应,这样的计算机必须配置有与对象系统相适应的接口电路。 ??另外,在理解嵌入式系统定义时,不要与嵌入式设备相混淆。嵌入式设备是指内部有嵌入式系统的产品、设备,例如,内含单片机的家用电器、仪器仪表、工控单元、机器人、手机、PDA等。     (3)嵌入式系统的种类与发展 ??按照上述嵌入式系统的定义,只要满足定义中三要素的计算机系统,都可称为嵌入式系统。嵌入式系统按形态可分为设备级(工控机)、板级(单板、模块)、芯片级(MCU、SoC)。 ??有些人把嵌入式处理器当作嵌入式系统,但由于嵌入式系统是一个嵌入式计算机系统,因此,只有将嵌入式处理器构成一个计算机系统,并作为嵌入式应用时,这样的计算机系统才可称作嵌入式系统。 ??嵌入式系统与对象系统密切相关,其主要技术发展方向是满足嵌入式应用要求,不断扩展对象系统要求的外围电路(如ADC、DAC、PWM、日历时钟、电源监测、程序运行监测电路等),形成满足对象系统要求的应用系统。因此,嵌入式系统作为一个专用计算机系统,要不断向计算机应用系统发展。因此,可以把定义中的专用计算机系统引伸成,满足对象系统要求的计算机应用系统。 3 嵌入式系统的独立发展道路     (1)单片机开创了嵌入式系统独立发展道路 ??嵌入式系统虽然起源于微型计算机时代,然而,微型计算机的体积、价位、可靠性都无法满足广大对象系统的嵌入式应用要求,因此,嵌入式系统必须走独立发展道路。这条道路就是芯片化道路。将计算机做在一个芯片上,从而开创了嵌入式系统独立发展的单片机时代。 ??在探索单片机的发展道路时,有过两种模式,即“Σ模式”与“创新模式”。“Σ模式”本质上是通用计算机直接芯片化的模式,它将通用计算机系统中的基本单元进行裁剪后,集成在一个芯片上,构成单片微型计算机;“创新模式”则完全按嵌入式应用要求设计全新的,满足嵌入式应用要求的体系结构、微处理器、指令系统、总线方式、管理模式等。Intel公司的MCS-48、MCS-51就是按照创新模式发展起来的单片形态的嵌入式系统(单片微型计算机)。MCS-51是在MCS-48探索基础上,进行全面完善的嵌入式系统。历史证明,“创新模式”是嵌入式系统独立发展的正确道路,MCS-51的体系结构也因此成为单片嵌入式系统的典型结构体系。     (2)单片机的技术发展史 ??单片机诞生于20世纪70年代末,经历了SCM、MCU、SoC三大阶段。 ??SCM即单片微型计算机(Single Chip Microcomputer)阶段,主要是寻求最佳的单片形态嵌入式系统的最佳体系结构。“创新模式”获得成功,奠定了SCM与通用计算机完全不同的发展道路。在开创嵌入式系统独立发展道路上,Intel公司功不可没。 ??MCU即微控制器(Micro Controller Unit)阶段,主要的技术发展方向是:不断扩展满足嵌入式应用时,对象系统要求的各种外围电路与接口电路,突显其对象的智能化控制能力。它所涉及的领域都与对象系统相关,因此,发展MCU的重任不可避免地落在电气、电子技术厂家。从这一角度来看,Intel逐渐淡出MCU的发展也有其客观因素。在发展MCU方面,最著名的厂家当数Philips公司。 ??Philips公司以其在嵌入式应用方面的巨大优势,将MCS-51从单片微型计算机迅速发展到微控制器。因此,当我们回顾嵌入式系统发展道路时,不要忘记Intel和Philips的历史功绩。 ??单片机是嵌入式系统的独立发展之路,向MCU阶段发展的重要因素,就是寻求应用系统在芯片上的最大化解决;因此,专用单片机的发展自然形成了SoC化趋势。随着微电子技术、IC设计、EDA工具的发展,基于SoC的单片机应用系统设计会有较大的发展。因此,对单片机的理解可以从单片微型计算机、单片微控制器延伸到单片应用系统。 4 嵌入式系统的两种应用模式 ??嵌入式系统的嵌入式应用特点,决定了它的多学科交叉特点。作为计算机的内含,要求计算机领域人员介入其体系结构、软件技术、工程应用方面的研究。然而,了解对象系统的控制要求,实现系统控制模式必须具备对象领域的专业知识。因此,从嵌入式系统发展的历史过程,以及嵌入式应用的多样性中,可以了解到客观上形成的两种应用模式。     (1) 客观存在的两种应用模式 ??嵌入式计算机系统起源于微型机时代,但很快就进入到独立发展的单片机时代。在单片机时代,嵌入式系统以器件形态迅速进入到传统电子技术领域中,以电子技术应用工程师为主体,实现传统电子系统的智能化,而计算机专业队伍并没有真正进入单片机应用领域。因此,电子技术应用工程师以自己习惯性的电子技术应用模式,从事单片机的应用开发。这种应用模式最重要的特点是:软、硬件的底层性和随意性;对象系统专业技术的密切相关性;缺少计算机工程设计方法。 ??虽然在单片机时代,计算机专业淡出了嵌入式系统领域,但随着后PC时代的到来,网络、通信技术得以发展;同时,嵌入式系统软、硬件技术有了很大的提升,为计算机专业人士介入嵌入式系统应用开辟了广阔天地。计算机专业人士的介入,形成的计算机应用模式带有明显的计算机的工程应用特点,即基于嵌入式系统软、硬件平台,以网络、通信为主的非嵌入式底层应用。     (2)两种应用模式的并存与互补 ??由于嵌入式系统最大、最广、最底层的应用是传统电子技术领域的智能化改造,因此,以通晓对象专业的电子技术队伍为主,用最少的嵌入式系统软、硬件开销,以8位机为主,带有浓重的电子系统设计色彩的电子系统应用模式会长期存在下去。另外,计算机专业人士会愈来愈多地介入嵌入式系统应用,但囿于对象专业知识的隔阂,其应用领域会集中在网络、通信、多媒体、商务电子等方面,不可能替代原来电子工程师在控制、仪器仪表、机械电子等方面的嵌入式应用。因此,客观存在的两种应用模式会长期并存下去,在不同的领域中相互补充。电子系统设计模式应从计算机应用设计模式中,学习计算机工程方法和嵌入式系统软件技术;计算机应用设计模式应从电子系统设计模式中,了解嵌入式系统应用的电路系统特性、基本的外围电路设计方法和对象系统的基本要求等。     (3) 嵌入式系统应用的高低端 ??由于嵌入式系统有过很长的一段单片机的独立发展道路,大多是基于8位单片机,实现最底层的嵌入式系统应用,带有明显的电子系统设计模式特点。大多数从事单片机应用开发人员,都是对象系统领域中的电子系统工程师,加之单片机的出现,立即脱离了计算机专业领域,以“智能化”器件身份进入电子系统领域,没有带入“嵌入式系统”概念。因此,不少从事单片机应用的人,不了解单片机与嵌入式系统的关系,在谈到“嵌入式系统”领域时,往往理解成计算机专业领域的,基于32位嵌入式处理器,从事网络、通信、多媒体等的应用。这样,“单片机”与“嵌入式系统”形成了嵌入式系统中常见的两个独立的名词。但由于“单片机”是典型的、独立发展起来的嵌入式系统,从学科建设的角度出发,应该把它统一成“嵌入式系统”。考虑到原来单片机的电子系统底层应用特点,可以把嵌入式系统应用分成高端与低端,把原来的单片机应用理解成嵌入式系统的低端应用,含义为它的底层性以及与对象系统的紧耦合。

    时间:2004-12-09 关键词: 设计教程

  • MPC555微控制器与汽车电子

    摘要:介绍32位微控制器MPC555及其应用开发系统的技术特点,并分析比较国内外软硬件集成开发平台的应用现状。同时,对MPC555嵌入式系统在汽车电子领域的应用进行了总结和预测。     关键词:MPC555 集成开发环境(IDE) 实时操作系统(RTOS) 汽车电子 引言 随着汽车工业的飞速发展,汽车在控制、通信和网络方面的要求越来越复杂。以32位微控制器及嵌入式实时操作系统为基本技术特征的新一代电控单元ECU(Electronic Control Unit)成为汽车电子应用的主流。32位微控制器MPC555以其强大的性能在汽车电子等领域得到了广泛的应用。 1 MPC555微控制器简介 MPC555微控制器是Motorola PowerPC 555系列的代表产品,是专为汽车电子、航空航天、智能系统等高端嵌入式控制系统所设计。该产品可在高速移动及苛刻的环境下工作(工作温度:-40~125℃),性能优良,并具有高度的灵活性和可靠性,适合大批量低成本生产。 MPC555主要有以下功能模块: *主频40MHz的精简指令集CPU(RCPU); *四级存储器控制器; *U-Bus系统接口单元(USIU); *灵活的指令和数据存储保护单元; *448KB Flash EEPROM; *26KB SRAM; *双时间处理单元(TPU3); *18通道模块I/O系统(MIOS1); *双队列模数转换模块(QADC); *双CAN2.0B控制器模块(TouCANs); *队列串行多通道模块(QSMCM)。 在设计及开发应用MPC555微控制器过程中,厂商采取合作、联合推广等方式积极引导开发应用产品市场。MPC555微控制器采用了IBM微控制器的芯片结构技术、AMD闪存存储器技术。专业化嵌入式软硬件开发公司:ETAS、Pi-Technology、Axiom、ADI、Opti-NumSolution、dSPACE等开发出MPC555应用板、I/O模块、实时操作系统、集成开发工具、应用软件等嵌入式软硬件系统与集成开发环境。汽车电子产品开发商:BOSCH、德尔福等开发出相应的汽车电子应用产品。从而形成了对MPC555专业化分工、联合开发的产品链方式。这种产业/产品链的开发机制已成为高科技领域成功的发展模式。 2 MPC555应用软硬件平台及系统集成开发环境 针对目标系统,首先要选定与应用产品所处环境和功能参数相匹配的微控制器作为核心控制系统。另外,完备、强大的开发环境技术支持也至关重要。伴随着市场竞争越来越激烈,要求快速、灵活地开发应用产品,尽量减少和缩短从决策、设计、研发、测试、修正到最终批量生产的各个环节和周期。开发新产品的快慢往往与一个企业的生存紧密相连。为了适应这一要求。近几年,集成开发环境(Integrated Development Environment,IDE)技术得到了越来越广泛的重视。基于模型设计(Model-Based Design)、简化软件编程、软硬件一体化、快速原型(Rapid Prototyping)建立目标系统、应用程序模块化等先进的开发手段被广泛应用。另外,嵌入式实时操作系统(RTOS)对系统的安全运行、管理应用系统程序、系统的兼容通用性也至关重要。 一套完备的MPC555开发应用系统主要由软硬件平台和集成开发环境组成。集成开发环境的功能包括:提供控制操作界面;通过BDM接口浏览MPC555硬件平台状态和信息;建立控制模型;模拟仿真应用系统控制算法;与编译器连接将控制模型或C语言程序生成MPC555机器源代码;通过BDM接口将源代码传送到MPC555硬件平台;实时调试运行应用程序等。这种开发模式方便快捷,采用友好界面连接形象化模型框图、输入计算公式、经验公式等方式编制开发程序,由系统自动将其编译成目标代码。在应用程序经过反复模拟仿真,并实时调试运行成功后被装入MPC555硬件平台。MPC555系统配有各类应用I/O模块与通信接口,并装有一套实时操作系统(RTOS)。在操作系统的管理下,开发的应用程序在上位机监控下和脱离上位机两种环境下运行验证。一些特定、重复任务的应用程序被生成模块化的库文件已备调用。为了提高开发系统的实时性,系统具有HIL(Hardware-in-the-loop)、Bypass等硬件在环开发、实时嵌入加载等功能。模块化的应用程序可以实时在线导入导出而丝毫不影响系统的正常运行。 在硬件方面,MPC555微控制器是理想的汽车电子产品嵌入式硬件系统平台。表1列出了国内外专业公司开发的MPC555开发板情况比较。 在集成开发环境方面,各开发系统普遍采用MathWorks公司的MATLAB系列软件产品Simulink、Stateflow等,用于模拟仿真、建立模型,再配上相应的交叉编译器、控制界面连接程序与硬件平台相连,构成一完整的开发系统。在MPC555应用领域中,比较有代表的产品有ETAS公司的开发工具ASCET-SD;符合OSEK标准的实时操作系统OSEKWorks;调试工具LabCar和相应MPC555的硬件开发板;ADI公司的嵌入式系统的快速原型SIMsystem;开发平台BEACON,以及Axiom、Pi-technology的MPC555硬件开发系列产品等。 为了适应嵌入式计算机控制软件开发日益庞大的特点;实现软件开发的模块化和可移植性;确保各分布式控制子系统之间的通信畅通;尽可能地实现不同厂商的控制模块间的互换性和兼容性,应用系统的标准化成为迫切需要解决的课题。在汽车电子领域,CAN总线通信标准在物理层、数据链层定义了有关通信技术规范OSEK(Open Systems and the Corresponding Interfaces For Automotive Electronics)技术规范是针对符合汽车电子开放式系统及其接口的软件规范所研发的嵌入式实时操作系统。OSEK规范从实时操作系统和软件的开发平台两方面作了全面的定义与规定。该规范最先由德、法两国汽车行业所倡导并日趋完善。它所提出的一整套解决方案代表了未来汽车电子软件行业的发展方向,在国际车电子领域的影响力日益增强。 在国家高技术研究发展计算(863计划)电动汽车重大专项课题“燃料电池客车多能源动力总成控制器软硬件平台”中,北京西曼自动化技术有限公司配合课题承担方——清华大学计算机系智能技术与系统国家重点实验室,积极开发基于MPC500系列新一代汽车电子ECU软硬件平台以及集成开发环境,包括:MPC555评估板MPC565单板系统、OSEKLinux实时操作系统等。这些为MPC565单板系统、OSEKLinux实时操作系统等。这些为发展我国自主知识产权汽车电子关键核心技术,积极开发嵌入式软硬件及集成开发环境。表1 国内外MPC555应用开发板情况比较      公司产品项目 ETAS公司EVB555 Axiom公司CME0555 EST公司SBC555 ADI公司CE555 北京西曼公司BWM555 RAM 1MB 512KB(可扩展到1MB) 2MB 8MB 2MB ROM 512KB 512KB(可扩展到2.5MB) 1MB 4MB 2MB 逻辑分析接口 有 无 无 有 无 调试接口 BDM接口 BDM、JTAG接口 无 BDM、JTAG接口 BDM接口 仿真器支持 ETKP-1仿真器(Lauterbach公司) 仿真端口总线 VisionICE仿真系统 无 仿真端口总线 I/O接口 MPC555微控制配备 MPC555微控制器配备 MPC555微控制配备 MPC555微控制配备 MPC555微控制器配备 RS232接口 1 2 2 1 2 CAN总线 2 2 2 2 2 操作系统(OS)支持 OSEKworks(WindRiver公司)、ERCOSEK(ETAS公司) OSEKworks(WindRiver公司)、OSEK turbo(Metrowerks公司) OSEKworks(WindRiver公司) Rtexec(ADI公司),proOSEK(3SOFT公司) PowerOSEK(西曼) 模拟接口 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 其它 备选:以太网ETKP 420LCD液晶屏、44键盘 - VME总线、I/O信号调理 - 3 MPC555微控制器在汽车电子领域的应用 MPC555推出不久,便于1999年获得汽车行业国际PACE汽车创新产品优秀奖,并在嵌入式计算机控制领域,特别是汽车电子应用领域得到迅速发展。由于其优良的性能和强大的市场推广力度,MPC555在各个层次,从高科技研发项目、终端用户(汽车制造厂家)到各专业软硬件开发商都予以高度的重视,并积极开发应用MPC555产品。例如,美国MoBIES(Model-Based Integration of Embedded System)基于模型一体化嵌入式系统科研项目。MoBIES是由美国国防部DOD(Department of Defense)国防高技术研究项目局DARPA(Defense Advanced Research Projects Agency)信息处理技术办公室IPTO(Information Processing Technology Office)资助的项目。此项目旨在为嵌入式系统开发基于模型的软件组件集成技术。MoBIES项目日期从2000年6月开始到2003年11月结束。该项目的汽车OEP(Automobile Open Experimental Platform,汽车动力控制系统开放式试验平台)由Vehicle Dynamic Laboratory承担,采用MPC555为系统硬件控制单元。MPC555被重视的程度日益加强。 MPC555微控制器在汽车电子领域得到了广泛的应用,是目前被国际汽车电子系统广泛采用的新一代芯片。MPC555系列产品在2000年汽车行业的年销售额达10亿美元之多(据Motorola报道)。国外的汽车电子工业已形成了从半导体硬件到软件到部件开发,再到系统集成应用的一整套开发和生产体系。围绕着汽车制造商,形成了专业化、可提供全套应用系统的各类供应商:从硬件设计到软件开发,以及各种专用控制原型的提供,再配用先进的开发工具,使专业设计人员和制造商在生产一线开发、调试新产品等。这大大缩短了产品的开发周期。 以32位嵌入式微控制器为基本技术特征的新一代电控单元(Electronic Control Unit,ECU)已成为汽车电子发展应用的主流。汽车工业是使用微控制器最多的工业,一辆现代汽车最多可使用达上百个微控制器(如图1所示)。汽车电子系统占整车成本的比例在90年代末已超过了30%,现在还在继续上升。 汽车电子行业的发展依赖于汽车工业的蓬勃发展,以及后者在整个工业领域所处的重要地位。汽车电子的技术基础来源于半导体行业、软件开发、执行器和传感器等电子技术的发展。汽车电子产品能够在高速移动、苛刻和剧烈变化的环境下运行,并且具有高可靠性、安全性、较强的机电结合性、适于大指和低成本的生产等特点。 国际汽车电子技术正处于全面快速发展的阶段,其特征主要体现在四化一功能,即多样的功能(从最初的发动机电子点火与喷油发展到如今的各种控制功能,如自动巡航、自动启停、自动避撞等)、技术一体化(从最初的机电部件松散组合到如今的机液电磁一体化,如直喷式发动机电控共轨燃料喷射系统)、系统集成化(从最初的单一控制发展到如今睥多变量多目标结合协调控制,如动力总成综合控制、集成安全控制系统等)、通信网络化(从初期的多子系统分别工作到如今的分布式模块化控制器局部网络,如以CAN总线为基础的整车信息共享的车载分布式控制系统,以及D2B无线通信为基础的远程高频网络通信系统)、技术标准化(如OSEK技术规范,将成为未来汽车电子行业嵌入式操作系统的技术标准,广泛被采用)。国外的汽车电子产业形成了从半导体到软件到部件开发再到系统集成应用的一整套的开发和生产体系。而国内的汽车电子科研和产业还处于分散、分割、重复、重叠的低水平阶段,现状不容乐观。 MPC555微控制器在汽车电子领域的应用范例: *BMW的Valwetronic电子阀门系统为目前国际最先进的动力控制系统技术(其三种车型已在道路上运行); *Ford的Taurus动力控制系统; *由BMW联合Motorola等开发的Byteflight数据传送系统(用于安全气囊); *Siemens VDO汽车动力管理一体化系统; *Ford采用MPC500系列为Lincoln LS Luxury Sedans开发的动力控制系统; *Ford采用MPC500系列为Jaguar S-TypeSedans车型的点火、喷油、排气控制; *韩国现代公司最新燃料电池轿车SNATA FE FCEV(EVS19展出的)的总成控制; *MoBIES项目OEP汽车动力控制开放式试验平台硬件控制单元(ECU)。 汽车动力系统、底盘系统、车体以及安全系统等逐渐从传统的机械、液压结构向电子结构以及智能化控制演变。在制动、驾驶、悬挂、助力、车身等控制方面都借助电子化的手段提高性能。GPA全球卫星定位导航、稳定管理、电制动、自动驾驶以及防撞车、语音识别、网络化、夜间辨别加强等系统都在积极的开发应用当中。另外,通过内部网络将各个独立功能的子系统连接形成实时的资源共享,使系统集成化、智能化。例如,底盘稳定控制系统;通过对制动、驾驶和悬挂系统信息的获得而得以优化。4 MPC555应用发展前景 汽车电子技术的发展为提高整车性能起到了关键性的作用。随着汽车电子化发展的深入,32位微控制器将逐渐取代8位、16位微控制器而成为主流应用产品。未来的发展趋势应重视以下领域技术的开发。 (1)软件 标准的I/O驱动模块、实时多任务操作系统、高级语言控制编程、基于模型的算法设计、自动代码生成及虚拟仿真测试。 (2)硬件 提供完整的与软件系统一体化的硬件开发平台。灵活、多功能的快速原型,硬件在环仿真HIL(Hardware-in-the-Loop)Simulation,Bypass方法的应用等。 (3)快速原型建立软硬件一体化应用系统 采用快速原型建立目标系统:基于模型设计建立控制算法;模拟系统动态测试验证控制算法;模型实时检验;系统联机测试、检验、调试、修改;自动生成源代码、在线调试标定。 (4)标准化 汽车电子正处于全面发展时期,相关技术的标准也处于建立、完善的阶段。关通信、网络规范、实时操作系统规范等技术规范日趋成熟。这类规范与针对性硬件系统到相渗透、互相依赖,成为一体。各大汽车公司联盟争先开发、建立不同的标准体系,以便在汽车电子竞争中抢得先机。 汽车工业的发展围绕安全、节能、环保、舒适、方便的主题,为消费者提供高质量、安全可靠、多功能低价位的创新产品。开发商面临的挑战是如何在最短的时间内将新产品推向市场。为了适应这一特点,汽车行业以及IT行业的企业越来越认同联合开发的方式,并着重在制定标准、统一开发模式方面加大力度。 MPC555嵌入式系统在汽车行业有着广阔的应用前景。随着我国国民经济的飞速发展,人民生活水平的提高,汽车有望成为居民新的消费热点以及国民经济新的增长点。随着中国加入WTO,竞争也越来越激烈。正像BMW总裁Helmut Panke所说的,未来的发展趋势将是“from the sheet metal to software”。传统汽车制造业必然要与信息、计算、电子技术相结合,汽车生产企业与IT行业的合作关系将越来越紧密。先进的方法和手段将不断应用到产品的开发与生产当中。MPC555在汽车电子领域的应用将不断得到提升。我们有必要加大开发MPC555嵌入式计算机控制系统的应用,推进我国汽车电子行业的发展。

    时间:2004-12-08 关键词: Linux mpc555 车电子

  • MPC555微控制器与汽车电子

    摘要:介绍32位微控制器MPC555及其应用开发系统的技术特点,并分析比较国内外软硬件集成开发平台的应用现状。同时,对MPC555嵌入式系统在汽车电子领域的应用进行了总结和预测。     关键词:MPC555 集成开发环境(IDE) 实时操作系统(RTOS) 汽车电子 引言 随着汽车工业的飞速发展,汽车在控制、通信和网络方面的要求越来越复杂。以32位微控制器及嵌入式实时操作系统为基本技术特征的新一代电控单元ECU(Electronic Control Unit)成为汽车电子应用的主流。32位微控制器MPC555以其强大的性能在汽车电子等领域得到了广泛的应用。 1 MPC555微控制器简介 MPC555微控制器是Motorola PowerPC 555系列的代表产品,是专为汽车电子、航空航天、智能系统等高端嵌入式控制系统所设计。该产品可在高速移动及苛刻的环境下工作(工作温度:-40~125℃),性能优良,并具有高度的灵活性和可靠性,适合大批量低成本生产。 MPC555主要有以下功能模块: *主频40MHz的精简指令集CPU(RCPU); *四级存储器控制器; *U-Bus系统接口单元(USIU); *灵活的指令和数据存储保护单元; *448KB Flash EEPROM; *26KB SRAM; *双时间处理单元(TPU3); *18通道模块I/O系统(MIOS1); *双队列模数转换模块(QADC); *双CAN2.0B控制器模块(TouCANs); *队列串行多通道模块(QSMCM)。 在设计及开发应用MPC555微控制器过程中,厂商采取合作、联合推广等方式积极引导开发应用产品市场。MPC555微控制器采用了IBM微控制器的芯片结构技术、AMD闪存存储器技术。专业化嵌入式软硬件开发公司:ETAS、Pi-Technology、Axiom、ADI、Opti-NumSolution、dSPACE等开发出MPC555应用板、I/O模块、实时操作系统、集成开发工具、应用软件等嵌入式软硬件系统与集成开发环境。汽车电子产品开发商:BOSCH、德尔福等开发出相应的汽车电子应用产品。从而形成了对MPC555专业化分工、联合开发的产品链方式。这种产业/产品链的开发机制已成为高科技领域成功的发展模式。 2 MPC555应用软硬件平台及系统集成开发环境 针对目标系统,首先要选定与应用产品所处环境和功能参数相匹配的微控制器作为核心控制系统。另外,完备、强大的开发环境技术支持也至关重要。伴随着市场竞争越来越激烈,要求快速、灵活地开发应用产品,尽量减少和缩短从决策、设计、研发、测试、修正到最终批量生产的各个环节和周期。开发新产品的快慢往往与一个企业的生存紧密相连。为了适应这一要求。近几年,集成开发环境(Integrated Development Environment,IDE)技术得到了越来越广泛的重视。基于模型设计(Model-Based Design)、简化软件编程、软硬件一体化、快速原型(Rapid Prototyping)建立目标系统、应用程序模块化等先进的开发手段被广泛应用。另外,嵌入式实时操作系统(RTOS)对系统的安全运行、管理应用系统程序、系统的兼容通用性也至关重要。 一套完备的MPC555开发应用系统主要由软硬件平台和集成开发环境组成。集成开发环境的功能包括:提供控制操作界面;通过BDM接口浏览MPC555硬件平台状态和信息;建立控制模型;模拟仿真应用系统控制算法;与编译器连接将控制模型或C语言程序生成MPC555机器源代码;通过BDM接口将源代码传送到MPC555硬件平台;实时调试运行应用程序等。这种开发模式方便快捷,采用友好界面连接形象化模型框图、输入计算公式、经验公式等方式编制开发程序,由系统自动将其编译成目标代码。在应用程序经过反复模拟仿真,并实时调试运行成功后被装入MPC555硬件平台。MPC555系统配有各类应用I/O模块与通信接口,并装有一套实时操作系统(RTOS)。在操作系统的管理下,开发的应用程序在上位机监控下和脱离上位机两种环境下运行验证。一些特定、重复任务的应用程序被生成模块化的库文件已备调用。为了提高开发系统的实时性,系统具有HIL(Hardware-in-the-loop)、Bypass等硬件在环开发、实时嵌入加载等功能。模块化的应用程序可以实时在线导入导出而丝毫不影响系统的正常运行。 在硬件方面,MPC555微控制器是理想的汽车电子产品嵌入式硬件系统平台。表1列出了国内外专业公司开发的MPC555开发板情况比较。 在集成开发环境方面,各开发系统普遍采用MathWorks公司的MATLAB系列软件产品Simulink、Stateflow等,用于模拟仿真、建立模型,再配上相应的交叉编译器、控制界面连接程序与硬件平台相连,构成一完整的开发系统。在MPC555应用领域中,比较有代表的产品有ETAS公司的开发工具ASCET-SD;符合OSEK标准的实时操作系统OSEKWorks;调试工具LabCar和相应MPC555的硬件开发板;ADI公司的嵌入式系统的快速原型SIMsystem;开发平台BEACON,以及Axiom、Pi-technology的MPC555硬件开发系列产品等。 为了适应嵌入式计算机控制软件开发日益庞大的特点;实现软件开发的模块化和可移植性;确保各分布式控制子系统之间的通信畅通;尽可能地实现不同厂商的控制模块间的互换性和兼容性,应用系统的标准化成为迫切需要解决的课题。在汽车电子领域,CAN总线通信标准在物理层、数据链层定义了有关通信技术规范OSEK(Open Systems and the Corresponding Interfaces For Automotive Electronics)技术规范是针对符合汽车电子开放式系统及其接口的软件规范所研发的嵌入式实时操作系统。OSEK规范从实时操作系统和软件的开发平台两方面作了全面的定义与规定。该规范最先由德、法两国汽车行业所倡导并日趋完善。它所提出的一整套解决方案代表了未来汽车电子软件行业的发展方向,在国际车电子领域的影响力日益增强。 在国家高技术研究发展计算(863计划)电动汽车重大专项课题“燃料电池客车多能源动力总成控制器软硬件平台”中,北京西曼自动化技术有限公司配合课题承担方——清华大学计算机系智能技术与系统国家重点实验室,积极开发基于MPC500系列新一代汽车电子ECU软硬件平台以及集成开发环境,包括:MPC555评估板MPC565单板系统、OSEKLinux实时操作系统等。这些为MPC565单板系统、OSEKLinux实时操作系统等。这些为发展我国自主知识产权汽车电子关键核心技术,积极开发嵌入式软硬件及集成开发环境。 表1 国内外MPC555应用开发板情况比较      公司产品 项目 ETAS公司EVB555 Axiom公司CME0555 EST公司SBC555 ADI公司CE555 北京西曼公司BWM555 3 MPC555微控制器在汽车电子领域的应用 MPC555推出不久,便于1999年获得汽车行业国际PACE汽车创新产品优秀奖,并在嵌入式计算机控制领域,特别是汽车电子应用领域得到迅速发展。由于其优良的性能和强大的市场推广力度,MPC555在各个层次,从高科技研发项目、终端用户(汽车制造厂家)到各专业软硬件开发商都予以高度的重视,并积极开发应用MPC555产品。例如,美国MoBIES(Model-Based Integration of Embedded System)基于模型一体化嵌入式系统科研项目。MoBIES是由美国国防部DOD(Department of Defense)国防高技术研究项目局DARPA(Defense Advanced Research Projects Agency)信息处理技术办公室IPTO(Information Processing Technology Office)资助的项目。此项目旨在为嵌入式系统开发基于模型的软件组件集成技术。MoBIES项目日期从2000年6月开始到2003年11月结束。该项目的汽车OEP(Automobile Open Experimental Platform,汽车动力控制系统开放式试验平台)由Vehicle Dynamic Laboratory承担,采用MPC555为系统硬件控制单元。MPC555被重视的程度日益加强。 MPC555微控制器在汽车电子领域得到了广泛的应用,是目前被国际汽车电子系统广泛采用的新一代芯片。MPC555系列产品在2000年汽车行业的年销售额达10亿美元之多(据Motorola报道)。国外的汽车电子工业已形成了从半导体硬件到软件到部件开发,再到系统集成应用的一整套开发和生产体系。围绕着汽车制造商,形成了专业化、可提供全套应用系统的各类供应商:从硬件设计到软件开发,以及各种专用控制原型的提供,再配用先进的开发工具,使专业设计人员和制造商在生产一线开发、调试新产品等。这大大缩短了产品的开发周期。 以32位嵌入式微控制器为基本技术特征的新一代电控单元(Electronic Control Unit,ECU)已成为汽车电子发展应用的主流。汽车工业是使用微控制器最多的工业,一辆现代汽车最多可使用达上百个微控制器(如图1所示)。汽车电子系统占整车成本的比例在90年代末已超过了30%,现在还在继续上升。 汽车电子行业的发展依赖于汽车工业的蓬勃发展,以及后者在整个工业领域所处的重要地位。汽车电子的技术基础来源于半导体行业、软件开发、执行器和传感器等电子技术的发展。汽车电子产品能够在高速移动、苛刻和剧烈变化的环境下运行,并且具有高可靠性、安全性、较强的机电结合性、适于大指和低成本的生产等特点。 国际汽车电子技术正处于全面快速发展的阶段,其特征主要体现在四化一功能,即多样的功能(从最初的发动机电子点火与喷油发展到如今的各种控制功能,如自动巡航、自动启停、自动避撞等)、技术一体化(从最初的机电部件松散组合到如今的机液电磁一体化,如直喷式发动机电控共轨燃料喷射系统)、系统集成化(从最初的单一控制发展到如今睥多变量多目标结合协调控制,如动力总成综合控制、集成安全控制系统等)、通信网络化(从初期的多子系统分别工作到如今的分布式模块化控制器局部网络,如以CAN总线为基础的整车信息共享的车载分布式控制系统,以及D2B无线通信为基础的远程高频网络通信系统)、技术标准化(如OSEK技术规范,将成为未来汽车电子行业嵌入式操作系统的技术标准,广泛被采用)。国外的汽车电子产业形成了从半导体到软件到部件开发再到系统集成应用的一整套的开发和生产体系。而国内的汽车电子科研和产业还处于分散、分割、重复、重叠的低水平阶段,现状不容乐观。 MPC555微控制器在汽车电子领域的应用范例: *BMW的Valwetronic电子阀门系统为目前国际最先进的动力控制系统技术(其三种车型已在道路上运行); *Ford的Taurus动力控制系统; *由BMW联合Motorola等开发的Byteflight数据传送系统(用于安全气囊); *Siemens VDO汽车动力管理一体化系统; *Ford采用MPC500系列为Lincoln LS Luxury Sedans开发的动力控制系统; *Ford采用MPC500系列为Jaguar S-TypeSedans车型的点火、喷油、排气控制; *韩国现代公司最新燃料电池轿车SNATA FE FCEV(EVS19展出的)的总成控制; *MoBIES项目OEP汽车动力控制开放式试验平台硬件控制单元(ECU)。 汽车动力系统、底盘系统、车体以及安全系统等逐渐从传统的机械、液压结构向电子结构以及智能化控制演变。在制动、驾驶、悬挂、助力、车身等控制方面都借助电子化的手段提高性能。GPA全球卫星定位导航、稳定管理、电制动、自动驾驶以及防撞车、语音识别、网络化、夜间辨别加强等系统都在积极的开发应用当中。另外,通过内部网络将各个独立功能的子系统连接形成实时的资源共享,使系统集成化、智能化。例如,底盘稳定控制系统;通过对制动、驾驶和悬挂系统信息的获得而得以优化。 4 MPC555应用发展前景 汽车电子技术的发展为提高整车性能起到了关键性的作用。随着汽车电子化发展的深入,32位微控制器将逐渐取代8位、16位微控制器而成为主流应用产品。未来的发展趋势应重视以下领域技术的开发。 (1)软件 标准的I/O驱动模块、实时多任务操作系统、高级语言控制编程、基于模型的算法设计、自动代码生成及虚拟仿真测试。 (2)硬件 提供完整的与软件系统一体化的硬件开发平台。灵活、多功能的快速原型,硬件在环仿真HIL(Hardware-in-the-Loop)Simulation,Bypass方法的应用等。 (3)快速原型建立软硬件一体化应用系统 采用快速原型建立目标系统:基于模型设计建立控制算法;模拟系统动态测试验证控制算法;模型实时检验;系统联机测试、检验、调试、修改;自动生成源代码、在线调试标定。 (4)标准化 汽车电子正处于全面发展时期,相关技术的标准也处于建立、完善的阶段。关通信、网络规范、实时操作系统规范等技术规范日趋成熟。这类规范与针对性硬件系统到相渗透、互相依赖,成为一体。各大汽车公司联盟争先开发、建立不同的标准体系,以便在汽车电子竞争中抢得先机。 汽车工业的发展围绕安全、节能、环保、舒适、方便的主题,为消费者提供高质量、安全可靠、多功能低价位的创新产品。开发商面临的挑战是如何在最短的时间内将新产品推向市场。为了适应这一特点,汽车行业以及IT行业的企业越来越认同联合开发的方式,并着重在制定标准、统一开发模式方面加大力度。 MPC555嵌入式系统在汽车行业有着广阔的应用前景。随着我国国民经济的飞速发展,人民生活水平的提高,汽车有望成为居民新的消费热点以及国民经济新的增长点。随着中国加入WTO,竞争也越来越激烈。正像BMW总裁Helmut Panke所说的,未来的发展趋势将是“from the sheet metal to software”。传统汽车制造业必然要与信息、计算、电子技术相结合,汽车生产企业与IT行业的合作关系将越来越紧密。先进的方法和手段将不断应用到产品的开发与生产当中。MPC555在汽车电子领域的应用将不断得到提升。我们有必要加大开发MPC555嵌入式计算机控制系统的应用,推进我国汽车电子行业的发展。 RAM 1MB 512KB(可扩展到1MB) 2MB 8MB 2MB ROM 512KB 512KB(可扩展到2.5MB) 1MB 4MB 2MB 逻辑分析接口 有 无 无 有 无 调试接口 BDM接口 BDM、JTAG接口 无 BDM、JTAG接口 BDM接口 仿真器支持 ETKP-1仿真器(Lauterbach 公司) 仿真端口总线 VisionICE仿真 系统 无 仿真端口总线 I/O接口 MPC555微控制 配备 MPC555微控制器 配备 MPC555微控制 配备 MPC555微控制 配备 MPC555微控制器配备 RS232接口 1 2 2 1 2 CAN总线 2 2 2 2 2 操作系统(OS)支持 OSEKworks(WindRiver公司)、ERCOSEK(ETAS公司) OSEKworks(WindRiver公司)、OSEK turbo(Metrowerks公司) OSEKworks(WindRiver 公司) Rtexec(ADI公司),proOSEK(3SOFT公司) PowerOSEK (西曼) 模拟接口 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 其它 备选:以太网ETKP 420LCD液晶屏、44键盘 - VME总线、I/O信号调理 -

    时间:2004-12-08 关键词: 微控制器 iOS mpc555 车电子

  • MPC555微控制器与汽车电子

    摘要:介绍32位微控制器MPC555及其应用开发系统的技术特点,并分析比较国内外软硬件集成开发平台的应用现状。同时,对MPC555嵌入式系统在汽车电子领域的应用进行了总结和预测。     关键词:MPC555 集成开发环境(IDE) 实时操作系统(RTOS) 汽车电子 引言 随着汽车工业的飞速发展,汽车在控制、通信和网络方面的要求越来越复杂。以32位微控制器及嵌入式实时操作系统为基本技术特征的新一代电控单元ECU(Electronic Control Unit)成为汽车电子应用的主流。32位微控制器MPC555以其强大的性能在汽车电子等领域得到了广泛的应用。 1 MPC555微控制器简介 MPC555微控制器是Motorola PowerPC 555系列的代表产品,是专为汽车电子、航空航天、智能系统等高端嵌入式控制系统所设计。该产品可在高速移动及苛刻的环境下工作(工作温度:-40~125℃),性能优良,并具有高度的灵活性和可靠性,适合大批量低成本生产。 MPC555主要有以下功能模块: *主频40MHz的精简指令集CPU(RCPU); *四级存储器控制器; *U-Bus系统接口单元(USIU); *灵活的指令和数据存储保护单元; *448KB Flash EEPROM; *26KB SRAM; *双时间处理单元(TPU3); *18通道模块I/O系统(MIOS1); *双队列模数转换模块(QADC); *双CAN2.0B控制器模块(TouCANs); *队列串行多通道模块(QSMCM)。 在设计及开发应用MPC555微控制器过程中,厂商采取合作、联合推广等方式积极引导开发应用产品市场。MPC555微控制器采用了IBM微控制器的芯片结构技术、AMD闪存存储器技术。专业化嵌入式软硬件开发公司:ETAS、Pi-Technology、Axiom、ADI、Opti-NumSolution、dSPACE等开发出MPC555应用板、I/O模块、实时操作系统、集成开发工具、应用软件等嵌入式软硬件系统与集成开发环境。汽车电子产品开发商:BOSCH、德尔福等开发出相应的汽车电子应用产品。从而形成了对MPC555专业化分工、联合开发的产品链方式。这种产业/产品链的开发机制已成为高科技领域成功的发展模式。 2 MPC555应用软硬件平台及系统集成开发环境 针对目标系统,首先要选定与应用产品所处环境和功能参数相匹配的微控制器作为核心控制系统。另外,完备、强大的开发环境技术支持也至关重要。伴随着市场竞争越来越激烈,要求快速、灵活地开发应用产品,尽量减少和缩短从决策、设计、研发、测试、修正到最终批量生产的各个环节和周期。开发新产品的快慢往往与一个企业的生存紧密相连。为了适应这一要求。近几年,集成开发环境(Integrated Development Environment,IDE)技术得到了越来越广泛的重视。基于模型设计(Model-Based Design)、简化软件编程、软硬件一体化、快速原型(Rapid Prototyping)建立目标系统、应用程序模块化等先进的开发手段被广泛应用。另外,嵌入式实时操作系统(RTOS)对系统的安全运行、管理应用系统程序、系统的兼容通用性也至关重要。 一套完备的MPC555开发应用系统主要由软硬件平台和集成开发环境组成。集成开发环境的功能包括:提供控制操作界面;通过BDM接口浏览MPC555硬件平台状态和信息;建立控制模型;模拟仿真应用系统控制算法;与编译器连接将控制模型或C语言程序生成MPC555机器源代码;通过BDM接口将源代码传送到MPC555硬件平台;实时调试运行应用程序等。这种开发模式方便快捷,采用友好界面连接形象化模型框图、输入计算公式、经验公式等方式编制开发程序,由系统自动将其编译成目标代码。在应用程序经过反复模拟仿真,并实时调试运行成功后被装入MPC555硬件平台。MPC555系统配有各类应用I/O模块与通信接口,并装有一套实时操作系统(RTOS)。在操作系统的管理下,开发的应用程序在上位机监控下和脱离上位机两种环境下运行验证。一些特定、重复任务的应用程序被生成模块化的库文件已备调用。为了提高开发系统的实时性,系统具有HIL(Hardware-in-the-loop)、Bypass等硬件在环开发、实时嵌入加载等功能。模块化的应用程序可以实时在线导入导出而丝毫不影响系统的正常运行。 在硬件方面,MPC555微控制器是理想的汽车电子产品嵌入式硬件系统平台。表1列出了国内外专业公司开发的MPC555开发板情况比较。 在集成开发环境方面,各开发系统普遍采用MathWorks公司的MATLAB系列软件产品Simulink、Stateflow等,用于模拟仿真、建立模型,再配上相应的交叉编译器、控制界面连接程序与硬件平台相连,构成一完整的开发系统。在MPC555应用领域中,比较有代表的产品有ETAS公司的开发工具ASCET-SD;符合OSEK标准的实时操作系统OSEKWorks;调试工具LabCar和相应MPC555的硬件开发板;ADI公司的嵌入式系统的快速原型SIMsystem;开发平台BEACON,以及Axiom、Pi-technology的MPC555硬件开发系列产品等。 为了适应嵌入式计算机控制软件开发日益庞大的特点;实现软件开发的模块化和可移植性;确保各分布式控制子系统之间的通信畅通;尽可能地实现不同厂商的控制模块间的互换性和兼容性,应用系统的标准化成为迫切需要解决的课题。在汽车电子领域,CAN总线通信标准在物理层、数据链层定义了有关通信技术规范OSEK(Open Systems and the Corresponding Interfaces For Automotive Electronics)技术规范是针对符合汽车电子开放式系统及其接口的软件规范所研发的嵌入式实时操作系统。OSEK规范从实时操作系统和软件的开发平台两方面作了全面的定义与规定。该规范最先由德、法两国汽车行业所倡导并日趋完善。它所提出的一整套解决方案代表了未来汽车电子软件行业的发展方向,在国际车电子领域的影响力日益增强。 在国家高技术研究发展计算(863计划)电动汽车重大专项课题“燃料电池客车多能源动力总成控制器软硬件平台”中,北京西曼自动化技术有限公司配合课题承担方——清华大学计算机系智能技术与系统国家重点实验室,积极开发基于MPC500系列新一代汽车电子ECU软硬件平台以及集成开发环境,包括:MPC555评估板MPC565单板系统、OSEKLinux实时操作系统等。这些为MPC565单板系统、OSEKLinux实时操作系统等。这些为发展我国自主知识产权汽车电子关键核心技术,积极开发嵌入式软硬件及集成开发环境。表1 国内外MPC555应用开发板情况比较      公司产品项目 ETAS公司EVB555 Axiom公司CME0555 EST公司SBC555 ADI公司CE555 北京西曼公司BWM555 RAM 1MB 512KB(可扩展到1MB) 2MB 8MB 2MB ROM 512KB 512KB(可扩展到2.5MB) 1MB 4MB 2MB 逻辑分析接口 有 无 无 有 无 调试接口 BDM接口 BDM、JTAG接口 无 BDM、JTAG接口 BDM接口 仿真器支持 ETKP-1仿真器(Lauterbach公司) 仿真端口总线 VisionICE仿真系统 无 仿真端口总线 I/O接口 MPC555微控制配备 MPC555微控制器配备 MPC555微控制配备 MPC555微控制配备 MPC555微控制器配备 RS232接口 1 2 2 1 2 CAN总线 2 2 2 2 2 操作系统(OS)支持 OSEKworks(WindRiver公司)、ERCOSEK(ETAS公司) OSEKworks(WindRiver公司)、OSEK turbo(Metrowerks公司) OSEKworks(WindRiver公司) Rtexec(ADI公司),proOSEK(3SOFT公司) PowerOSEK(西曼) 模拟接口 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 MPC555微控制器配备 其它 备选:以太网ETKP 420LCD液晶屏、44键盘 - VME总线、I/O信号调理 - 3 MPC555微控制器在汽车电子领域的应用 MPC555推出不久,便于1999年获得汽车行业国际PACE汽车创新产品优秀奖,并在嵌入式计算机控制领域,特别是汽车电子应用领域得到迅速发展。由于其优良的性能和强大的市场推广力度,MPC555在各个层次,从高科技研发项目、终端用户(汽车制造厂家)到各专业软硬件开发商都予以高度的重视,并积极开发应用MPC555产品。例如,美国MoBIES(Model-Based Integration of Embedded System)基于模型一体化嵌入式系统科研项目。MoBIES是由美国国防部DOD(Department of Defense)国防高技术研究项目局DARPA(Defense Advanced Research Projects Agency)信息处理技术办公室IPTO(Information Processing Technology Office)资助的项目。此项目旨在为嵌入式系统开发基于模型的软件组件集成技术。MoBIES项目日期从2000年6月开始到2003年11月结束。该项目的汽车OEP(Automobile Open Experimental Platform,汽车动力控制系统开放式试验平台)由Vehicle Dynamic Laboratory承担,采用MPC555为系统硬件控制单元。MPC555被重视的程度日益加强。 MPC555微控制器在汽车电子领域得到了广泛的应用,是目前被国际汽车电子系统广泛采用的新一代芯片。MPC555系列产品在2000年汽车行业的年销售额达10亿美元之多(据Motorola报道)。国外的汽车电子工业已形成了从半导体硬件到软件到部件开发,再到系统集成应用的一整套开发和生产体系。围绕着汽车制造商,形成了专业化、可提供全套应用系统的各类供应商:从硬件设计到软件开发,以及各种专用控制原型的提供,再配用先进的开发工具,使专业设计人员和制造商在生产一线开发、调试新产品等。这大大缩短了产品的开发周期。 以32位嵌入式微控制器为基本技术特征的新一代电控单元(Electronic Control Unit,ECU)已成为汽车电子发展应用的主流。汽车工业是使用微控制器最多的工业,一辆现代汽车最多可使用达上百个微控制器(如图1所示)。汽车电子系统占整车成本的比例在90年代末已超过了30%,现在还在继续上升。 汽车电子行业的发展依赖于汽车工业的蓬勃发展,以及后者在整个工业领域所处的重要地位。汽车电子的技术基础来源于半导体行业、软件开发、执行器和传感器等电子技术的发展。汽车电子产品能够在高速移动、苛刻和剧烈变化的环境下运行,并且具有高可靠性、安全性、较强的机电结合性、适于大指和低成本的生产等特点。 国际汽车电子技术正处于全面快速发展的阶段,其特征主要体现在四化一功能,即多样的功能(从最初的发动机电子点火与喷油发展到如今的各种控制功能,如自动巡航、自动启停、自动避撞等)、技术一体化(从最初的机电部件松散组合到如今的机液电磁一体化,如直喷式发动机电控共轨燃料喷射系统)、系统集成化(从最初的单一控制发展到如今睥多变量多目标结合协调控制,如动力总成综合控制、集成安全控制系统等)、通信网络化(从初期的多子系统分别工作到如今的分布式模块化控制器局部网络,如以CAN总线为基础的整车信息共享的车载分布式控制系统,以及D2B无线通信为基础的远程高频网络通信系统)、技术标准化(如OSEK技术规范,将成为未来汽车电子行业嵌入式操作系统的技术标准,广泛被采用)。国外的汽车电子产业形成了从半导体到软件到部件开发再到系统集成应用的一整套的开发和生产体系。而国内的汽车电子科研和产业还处于分散、分割、重复、重叠的低水平阶段,现状不容乐观。 MPC555微控制器在汽车电子领域的应用范例: *BMW的Valwetronic电子阀门系统为目前国际最先进的动力控制系统技术(其三种车型已在道路上运行); *Ford的Taurus动力控制系统; *由BMW联合Motorola等开发的Byteflight数据传送系统(用于安全气囊); *Siemens VDO汽车动力管理一体化系统; *Ford采用MPC500系列为Lincoln LS Luxury Sedans开发的动力控制系统; *Ford采用MPC500系列为Jaguar S-TypeSedans车型的点火、喷油、排气控制; *韩国现代公司最新燃料电池轿车SNATA FE FCEV(EVS19展出的)的总成控制; *MoBIES项目OEP汽车动力控制开放式试验平台硬件控制单元(ECU)。 汽车动力系统、底盘系统、车体以及安全系统等逐渐从传统的机械、液压结构向电子结构以及智能化控制演变。在制动、驾驶、悬挂、助力、车身等控制方面都借助电子化的手段提高性能。GPA全球卫星定位导航、稳定管理、电制动、自动驾驶以及防撞车、语音识别、网络化、夜间辨别加强等系统都在积极的开发应用当中。另外,通过内部网络将各个独立功能的子系统连接形成实时的资源共享,使系统集成化、智能化。例如,底盘稳定控制系统;通过对制动、驾驶和悬挂系统信息的获得而得以优化。4 MPC555应用发展前景 汽车电子技术的发展为提高整车性能起到了关键性的作用。随着汽车电子化发展的深入,32位微控制器将逐渐取代8位、16位微控制器而成为主流应用产品。未来的发展趋势应重视以下领域技术的开发。 (1)软件 标准的I/O驱动模块、实时多任务操作系统、高级语言控制编程、基于模型的算法设计、自动代码生成及虚拟仿真测试。 (2)硬件 提供完整的与软件系统一体化的硬件开发平台。灵活、多功能的快速原型,硬件在环仿真HIL(Hardware-in-the-Loop)Simulation,Bypass方法的应用等。 (3)快速原型建立软硬件一体化应用系统 采用快速原型建立目标系统:基于模型设计建立控制算法;模拟系统动态测试验证控制算法;模型实时检验;系统联机测试、检验、调试、修改;自动生成源代码、在线调试标定。 (4)标准化 汽车电子正处于全面发展时期,相关技术的标准也处于建立、完善的阶段。关通信、网络规范、实时操作系统规范等技术规范日趋成熟。这类规范与针对性硬件系统到相渗透、互相依赖,成为一体。各大汽车公司联盟争先开发、建立不同的标准体系,以便在汽车电子竞争中抢得先机。 汽车工业的发展围绕安全、节能、环保、舒适、方便的主题,为消费者提供高质量、安全可靠、多功能低价位的创新产品。开发商面临的挑战是如何在最短的时间内将新产品推向市场。为了适应这一特点,汽车行业以及IT行业的企业越来越认同联合开发的方式,并着重在制定标准、统一开发模式方面加大力度。 MPC555嵌入式系统在汽车行业有着广阔的应用前景。随着我国国民经济的飞速发展,人民生活水平的提高,汽车有望成为居民新的消费热点以及国民经济新的增长点。随着中国加入WTO,竞争也越来越激烈。正像BMW总裁Helmut Panke所说的,未来的发展趋势将是“from the sheet metal to software”。传统汽车制造业必然要与信息、计算、电子技术相结合,汽车生产企业与IT行业的合作关系将越来越紧密。先进的方法和手段将不断应用到产品的开发与生产当中。MPC555在汽车电子领域的应用将不断得到提升。我们有必要加大开发MPC555嵌入式计算机控制系统的应用,推进我国汽车电子行业的发展。

    时间:2004-12-08 关键词: mpc555 车电子 设计教程

发布文章