第一篇:嵌入式主控软件设计心得[精选]
嵌入式主控软件设计模式初探
1.软件框架简述
根据本人近三年的嵌入式主控软件经验,基于VxWorks的嵌入式的主控软件大概有以下几个模块
图2 大功率通信控制器主控软件架构
各模块简述如下:
1)初始化模块
用于系统必备资源的初始化工作,设备通信前需要将各通信接口如CAN控制器、RS-232、RS-485控制器初始化至适当的状态,申请发送/接收数据缓冲区;显示程序图形库一般采用VxWorks自带的windML实现,因此需要初始化windML相关参数以便能在屏幕上正确显示。如果采用其他图形库,则需要考虑其它图形库的初始化工作。上述相关参数初始化完毕后系统进入按键检测、按键处理、控制处理模块。
2)按键检测和按键响应模块
对于用户的按键输入为什么需要设置两个模块来完成呢?只使用一个按键模块实现能否可行呢?实践表明,采用一个按键模块有一定的风险。假设用户在某时刻按键,系统立即对该按键进行处理(可能该处理需要较长时间),在按键处理进行的过程中用户又按下一个键。由于系统正在进行按键处理工作,无法对再一次按键进行响应,该按键响应会被忽略,无法完成用户的预期任务。因此,把按键处理划分为按键检测模块和按键响应模块的好处在于检测模块将按键检测值缓存,等按键响应模块完成响应后再从该缓存中读取下一个键值,保证用户的每一次按键都能被正确记录。
—1—
研发中心设计案例集2007年9月
3)控制模块
控制模块和各应用层相关,无法一概而论,只能视情况而定。
5)显示模块
显示同控制分离是主控软件设计的主要特点之一。显示模块作为系统软件中的一个任务来实现,与按键响应模块、业务模块、控制模块采用自定义协议通信,根据这些模块发送的遥控协议进行界面显示。将显示单独作为一个模块有以下两点原因:
1)一旦用户似于遥控盒的设备需求,该设备能实现对控制器的遥控显示功能,在遥
控盒软件设计时显示模块就可以直接移植到遥控盒的主控软件设计中,减少工作量。
2)显示模块涉及到屏幕刷新操作时会占用一定的时间,显示模块如果直接在相关控
制模块中实现则会影响到控制模块的实时性能。
3.优先级上的考虑
主控软件设计中需要考虑多个任务之间的优先级问题,从目前的设计经验上来看业务单元、信道机调度需要最高优先级,因为中长波、短波通信系统过程中业务单元对信道机的实时性要求最高,按键检测和按键响应优先级次之,显示模块优先级最低。显示任务放在系统比较空闲的时候显示不至于影响到整个系统的实时性能。对于同等优先级的任务最好加上taskDelay(0)语句,因为同等优先级的任务采用分时隙调度的方式,taskDelay(0)能该任务在运行时隙结束时被其它同等优先级的任务抢占到CPU资源。
除端口查询外,采用while(1)或者FOREVER类似结构的无限循环的任务必须拥有信号量、消息等挂起本身的能力。否则,系统运行时从windView中观察:该任务即使优先级最低为255时,也会无休止的占用大量的系统资源,影响系统实时性。
4.总结
本文试图根据经历的几个嵌入式主控软件项目中提取一些设计经验和心得体会,有些经验只是在项目实际开展过程中的观察总结,抛砖引玉,希望对各位有所帮助。
第二篇:初探一种构件化嵌入式软件设计模型验证工具
1.引言
嵌入式计算系统已经广泛的应用于生活中的各个领域,如:交通、能源、医疗、控制、通信、军事等。近年来随着计算机硬件性能的不断提高,嵌入式系统中软件的规模和复杂性不断增加,使软件对整个系统的影响逐渐占据了统治地位。关键系统中的嵌入式软件失效将会导致生命与财产的重大损失。因此,嵌入式软件通常具有极高的功能可靠性、严格的实时性等要求,如何保证系统同时满足给定的功能和非功能需求已成为当前高可信嵌入式计算领域中的研究热点。目前,工业界已有一些比较有效的嵌入式软件测试和调试方法(如:在处理器中嵌入ICE 功能,调试代理软件,JTAG 模拟等)。但从软件工程的角度来看,这些方法都是在系统的开发中后期阶段所使用,而在嵌入式软件设计与分析的前期阶段还缺乏有效的方法和工具对系统设计进行分析与验证。
本文基于接口自动机模型对构件化嵌入式软件设计(CBESD: Component-BasedEmbedded Software Designs)的分析与验证方法展开进一步研究,在Eclipse 开放平台上实现了一个CBESD的模型分析与验证原型工具T-CBESD(a Tool for Component-based EmbeddedSoftware Designs)。该工具的目的是应用于构件化嵌入式软件开发的设计建模阶段,对设计者所关心的系统重要功能性质以及与时间相关的实时行为性质进行严格形式化分析和验证,提高系统可靠性的可信度。
本文内容安排如下:第2 节中给出了非实时功能行为验证以及实时功能行为验证的理论基础,包括:描述系统动态行为的多种接口自动机模型,基于场景的系统规约描述模型,以及形式化分析与验证的抽象算法等。在第3 节中给出了原型工具T-CBESD 的基本设计思想,非实时功能行为验证模块以及实时功能行为验证模块的设计与实现,包括:工具输入输出接口设计、状态空间数据结构设计、基于场景的系统规约模型的输入预处理、具体验证算法的设计与实现等。第4 节中给出了应用实例研究;最后是相关工作比较和结束语,对本文中原型工具的特点、意义以及进一步的工作进行简要讨论。
2.工具的理论基础
软件工程中的构件化设计方法学通过复用和组合软件模块来构造系统,从而提高系统开发效率和可靠性。通常,一个复杂的嵌入式系统由多个计算子系统构成,其软件系统也具有较高的构件化特征,因此,构件化的设计已成为解决嵌入式软件设计复杂性问题的一种手段。与此同时,构件接口之间的交互场景也成为体现系统行为复杂性的一个重要方面。
本文中所讨论的原型工具就是使用形式化的接口自动机模型来对系统构件接口动态行为进行设计建模,并使用UML 交互概观图模型来描述多种基于场景的构件交互行为规约,然后应用形式化分析算法对设计模型是否满足系统规约进行分析和验证。
2.1 建模系统构件以及组合行为
接口自动机(interface automata,简称IA)是用来刻画软件构件接口交互行为时序特征的一种形式化语言。它描述了一个构件被使用的时候其对外界环境的输入假设和输出保证,即构件内方法被调用的先后次序以及构件对外环境输出调用信息或结果的次序。
输入动作可以用来建模:1)构件内可以被调用的方法或过程;2)通信信道的接收端;3)调用外部过程的返回等。输出动作可以用来建模:1)对其他构件中的方法或过程的调用;2)通信信道的发送消息端;3)构件中方法或过程的调用结束时的返回;4)构件中方法或过程执行中出现的异常返回,等。内部动作则表达了两个构件在组合过程中的同步交互行为。
考虑到嵌入式软件的实时性建模需求,需要对IA 进行实时语义的扩展,以增强接口自动机对实时系统的描述能力。直观上,对接口自动机每一个转换添加时间区间约束,以表示此转换发生的最小、最大时限;扩展后的模型称为实时接口自动机。
我们使用接口自动机的组合状态空间来表达多构件系统的组合行为;自动机组合状态空间中每一条可能的状态转换序列用来表达多构件系统的一个组合行为轨迹。基本IA 和扩展的RTIA 组合状态空间的定义略有不同,以下只给出了RTIA 组合空间(实时接口自动机网络)的定义;不带时间语义的基本接口自动机的组合定义参见文献。
2.2 基于场景的交互行为规约
在基于场景的系统规约中,通常将一个系统相对独立的功能模块建模为一个场景描述。这个场景表达了参与其中的各构件之间如何进行交互。进一步的,在系统设计阶段,还会关心有多个简单场景组合起来的复杂场景需求,即需要考虑多个简单场景之间的逻辑关系。
交互概观图(Interaction Overview Diagrams)是在UML2 规范中引入的一种用以描述系统中复杂交互场景的动态行为模型。交互概观图本质上是将活动图模型与顺序图模型结合在一起,图中的每一个节点都可以视为一个用顺序图表达的简单交互场景,然后利用活动图所提供的顺序、迭代、并发、选择等操作将多个不同的顺序图场景联系在一起;这样就可以用来表达语义更为丰富的系统交互行为。在本文中所关心的以下几种场景组合一致性问题都可以用交互概观图来有效的描述:
1.存在一致性: 某个特定的场景D 是否在系统所有行为中至少出现一次,或者某个指定的场景D 是否在系统的所有行为中一定不会出现。
2.前向强制一致性:当某个条件场景D1 出现时,则场景D2 一定会随之在系统后续行为中发生。
3.逆向强制一致性: 当某个条件场景D1 出现时,则场景D2 一定在D1 之前就在系统的行为中发生。
4.双向强制一致性: 当两个条件场景D1、D2 在系统一个行为中先后出现时,则在这两个场景之间一定有D3 发生。
2.3 模型分析与验证算法
基于以上给出的接口自动机系统组合行为模型以及交互场景系统规约模型,可以对2.2节中提出的多个基于功能的一致性验证问题进行分析与验证;同时,考虑嵌入式软件设计中的实时需求,以上每个基于功能的一致性验证问题都存在一个相应的带时间约束的版本;即在完成功能性验证的同时,也必须同时满足交互场景中给定的时间约束。在相关研究工作中,对上述几类模型验证问题进行了形式化定义和分析,并分别设计了相应的验证算法。算法的基本思想是对带有不同语义信息的系统组合行为的状态空间进行搜索,将每一个可能的系统行为与基于场景的交互规约进行比较,来判断设计模型是否满足各种系统规约。例如:对于存在一致性验证问题,如果在组合状态空间中顺序图D 所描述场景中的消息事件序列至少出现一次,则判定系统行为满足D,其相应的抽象算法框架参见文献中的算法;其中所提到的投影路径是为了处理状态空间中环路的出现导致所检验的系统行为路径可能是无穷长度的问题。对于系统实时行为的验证算法,则需要进一步考虑由于时间的引入所带来的如何将连续时间进行整型化处理,以及带时间约束的投影路径的建立;RTIA-Network 的一致性验证抽象算法框架参见文献。中国代写论文网与您分享论文范文
3.T-CBESD 的设计与实现
基于以上的理论分析与验证框架,本文设计了一个原型工具T-CBESD(a Tool forComponent-Based Embedded Software Designs)。T-CBESD 的目的是应用于构件化嵌入式软件开发的设计建模阶段,对设计者所关心的一些系统重要功能性质以及与时间相关的实时行为性质进行严格形式化分析和验证,以提高系统可靠性的可信度。工具的基本设计原则主要包括以下两个方面:
T-CBESD 应当具备跨平台运行、易扩展特征:即工具应该可以尽可能在多种不同运行平台上运行,并且考虑到在未来工作中,我们将在目前的工作基础上对接口自动机模型进行资源以及能耗等语义描述方面的进一步扩展;因此,选择了面向对象程序设计语言Java作为工具的实现语言。Java 具有良好的跨平台运行特征以及丰富的类库资源,并可以使用面向对象程序设计思想中的类继承等方法对工具进行方便可靠的扩展。
T-CBESD 应当具备易使用、易维护特征:用户可以比较方便的使用工具,或进行调整;因此,选择了工业界广泛使用的开放集成开发环境Eclipse 作为工具的运行平台,即使用Eclipse 的插件(plug-in)技术来设计和开发T-CBESD。用户可以很容易在Eclipse 环境中通过插件技术来安装、配置和使用工具;同时,在T-CBESD 的输入输出接口中所使用的XML语言在Java 和Eclipse 环境中也是得到完全的支持。
主要的逻辑处理框架包括:
输入输出接口; UML 顺序图模型的预处理;自动机组合模型的建立;非实时功能验证算法的实现;实时功能验证算法的实现等。以下分别给出详细说明。
3.1 输入输出接口设计
T-CBESD 的输入输出均是以XML 文件形式来描述的系统设计模型、系统需求规约以及验证结果信息等。其中,工具的输入包括:描述系统设计的接口自动机模型的XML 文件和描述系统规约的消息交互序列的XML 文件;输出则包括:描述系统组合行为的接口自动机组合模型的XML 文件和包含验证结果信息的XML 文件。这里,最核心部分是接口自动机模型的XML 文件格式的设计。在图3 中给出了一个非实时构件基本接口自动机模型的XML 文件示例说明;通过XML 的树形标签格式,分别定义了自动机名、自动机个数(如果这是一个组合自动机)、状态个数、状态名、后继状态名、转换个数、转换名、转换的出发和到达状态名、动作个数、动作名、动作类型等数据信息,用来完整准确的保存接口自动机模型的语义信息。此外,对于扩展的实时接口自动机模型,其相应的XML 文件格式定义中还包含与动作相关联的时间区间约束标记。
在上述定义的XML 文件基础上,就可以使用Java 类库中的DOM(文档对象模型)方法很方便的对自动机模型进行解析及生成。例如:在T-CBESD 中设计了parseXmlDocument()和parseRtXmlDocument()两个类方法来分别对基本接口自动机模型XML 文件和实时接口自动机模型XML 文件进行解析,并根据Automata,Transition 以及State 等类定义在内存空间创建相应的自动机对象。
3.2 UML 顺序图模型的输入预处理
虽然 T-CBESD 的输入输出定义为标准XML 文档格式,但在工具中加入了从UML 建模环境Rational Rose 的顺序图模型到T-CBESD 的XML 输入文件(描述消息交互序列集)的自动化转换处理。其原因有二:
其一,现在工业界已存在较为成熟的图形化建模工具,可以快速方便的绘制UML 模型图,可以利用这些工具作为T-CBESD 的前端,而不用在T-CBESD 中重新设计复杂的用户接口来支持图形化建模设计。
其二,在2.2 节中提到,一个顺序图场景可能会包含多个不同的消息事件序列;显然,如果让系统设计与分析人员从每一个顺序图中手动的生成所有可能的消息事件序列,这并不是件容易的事情。因此,需要提供一种从顺序图模型自动化生成所有可能的消息事件集合的方法。
在Rational Rose 中所生成的顺序图模型文件是MDL 格式,需要先转换成XML 格式文件,然后进行相应消息序列的抽取。其处理过程如图5 中所示,首先通过在Rational Rose中加载XMI 插件将MDL 格式的文件转换为XML 格式;然后对XML 文件进行解析,建立文档解析树,提取消息事件节点,并根据顺序图中的事件发生先后顺序构造一个相应的有向无环图(在此,定义了顺序图的参加者类(Element Class)、消息类(Message Class)以及结点类(Node Class)用于图的构造);最后设计了一个拓扑排序算法,对该有向图中的消息事件节点进行拓扑排序,从而得到一个顺序图中所有可能的消息事件序列的集合。
3.3 自动机组合模型的建立
接口自动机的组合过程与一般自动机组合的语义存在不同之处。在两个接口自动机组合的状态空间中,有可能存在两个构件接口之间交互不同步的所谓“非法状态”,在应用验证算法之前必须将这些非法状态找出来并从状态空间中去除掉。文献中给出了一个识别非法状态集合的基于不动点(Fixpoint)的抽象算法框架,基本思想是先构造出所有可能的组合状态的空间图,然后逆向搜索非法状态集。在T-CBESD 的实现中我们则采用正向的合法状态集合构造方法,其好处是避免了需要首先生成所有的状态空间。给出了工具中基本自动机模型的组合算法流程图。此外,在实时接口自动机组合的过程中还需要进一步考虑时间约束;如在2.1 节中形式化定义表示一样,所得到的每一个组合状态都会有一个相应的时间标记值。
3.4 非实时功能性质验证算法的实现
在3.3 节中建立的自动机组合状态空间的基础上,就可以应用文献中的一致性验证算法等对3.2 节中所给出系统需求中的消息交互序列进行分析验证。T-CBESD 中实现了包括存在一致性、前向一致性、逆向一致性以及双向一致性在内的多种形式的非实时功能行为验证算法。给出了工具中非实时功能性质验证模块的类图框架。主要包括两大部分:一部分是自动机模型核心类,包括Automata Class,Transition Class,State Class 以及组合模型的 Composition Class ; 另一部分则是与验证算法相关的类,包括:ExistConsistencyChecking Class,ActionString Class,AdjacentMatrix Class 和辅助类TransitionNode Class。其中,存在一致性验证类(ExistConsistencyChecking Class)作为功能验证算法类的基类,其他形式的一致性验证算法类(如:BackwardConsistencyCheckingClass,ForwardConsistencyChecking Class 和 BiConsistencyChecking Class 等)都依赖存在一致性验证类,调用其方法实现所需的功能。
在基类ExistConsistencyChecking 的实现过程中,一个关键的问题是:当在系统组合状态空间图中搜索与UML 顺序图交互序列所对应的投影路径时,有可能出现一个满足条件的投影路径一部分出现在某个环路内部,而另一部分却出现在此环路的外部路径上的情形[11,12]。如果只是采用经典的深度优先遍历或广度优先遍历方法对组合状态空间图进行搜索判定,将会遗漏掉这种情况。为此,在T-CBESD 中设计了动作名表(ActionString Class)和邻接矩阵(AdjacentMatrix Class)。其中,动作名表是以接口自动机的动作名作为表头向量,并以执行该动作名的转换作为表结点的一张哈希表,其定义见图8 所示(注:未包含类方法说明)。
基本思想为:对于所给出的一个消息交互序列,先根据消息名从动作名表中依次取出与消息名所对应的表头结点以及表结点,构成一张与消息序列中消息次序对应的消息名表。
然后遍历这张消息名表来搜索投影路径,搜索过程中需要根据邻接矩阵来判断两个结点之间是否可达。
3.5 实时功能性质验证算法的实现
在实时功能性质验证算法的实现中,考虑到实时一致性验证抽象算法框架实际上包含了两次对组合系统状态空间图的搜索过程;也就是说在非实时功能一致性验证中只需找到一条满足条件的投影路径,而在实时功能一致性验证中,是需要先根据消息序列找出所有可能的投影路径,然后进行检验。因此,T-CBESD 中依据动作名表以及邻接矩阵对图进行穷举搜索,搜索到一条投影路径之后并不立即结束,而是继续找下一条投影路径,找出所有与给定路径相符合的投影路径。在此基础上根据所给出的时间布尔表达式对这些投影路径进行筛选,如果找到符合时间布尔表达的投影路径验证则验证成功,否则,验证失败。
4.实例应用
目前,T-CBESD 的设计开发和运行环境是:Windows Xp 操作系统平台,Eclipse SDK3.4.0,Java SDK 1.6,所引用的MDL 文件是由Rational Rose 2003 生成。本节中分别给出T-CBESD 的非实时功能性质验证和实时功能验证两方面的实例应用说明。
在T-CBESD 中所构造的构件Communication 和User 的合法组合状态空间(去除了非法状态集)包括6 个组合状态:(s0|s0),(s1|s1),(s2|s1),(s3|s1),(s4|s1),(s5|s1)。对于存在一致性验证,不妨设顺序图中抽取的一个消息交互序列send*nack*send*ack 作为验证规约,显然,直观上就能判断Communication 和User 的组合系统应该是满足这个规约的。
运行T-CBESD 进行验证的结果,显示组合系统确实满足存在一致性,其相应的系统执行路径为:s0|s0??s1|s1??s2|s1??s3|s1??s4|s1??s5|s1。对于前向一致性验证,就本例而言,不妨设D1 消息序列为send*nack,D2 消息序列为send*ack,然后将其作为工具的系统规约来输入,其验证结果应该仍然是满足。运行T-CBESD 的验证结果,显示的确存在一条系统执行路径满足前向一致性。事实上,所找到这条路径与存在一致性的路径是相同的。
对于逆向存在一致性,若设D1 消息序列是send,D2 消息序列是ack,T-CBESD 给出的结果是不存在这样的一条组合系统路径满足它。这也符合对本例的直观判断,即在接受到ack之后又执行send 动作是不合法的,因此这个存在一致性是不满足的。对于双向一致性,若给出的D1 消息序列是send,D2 消息序列是send,D3 消息序列是nack,验证的结果是搜索成功,得到的可满足的组合系统执行路径为:s0|s0??s1|s1??s2|s1??s3|s1??s4|s1。图13 所示为T-CBESD 的非实时功能验证模块插件的界面。界面左边部分为操作区,主要提供组合、查看、工具输入、验证类型等功能选择,界面右边部分为分析与验证过程中工具所反馈的数据信息。
5.相关研究工作
SpIN是一个经典的分布式系统模型检验工具。系统每一个构件的自动机模型使用SpIN 中promela 语言所构造的进程(process)来表达,组合系统的状态空间通过计算所有自动机异步积来得到,系统规约使用LTL 时序公式描述;系统是否满足规约性质则通过组合系统和时序公式相对应的Buchi 自动机进行同步积,然后检验其结果是否为空。目前SpIN在工业界硬件设计以及通信协议规约的验证领域得到了较广泛的应用,但对同时具有功能和非功能需求的嵌入式软件验证领域,SpIN 并未提供相应的支持。UppAAL是一个基于时间自动机理论的实时系统仿真和验证工具。其基本思想为将实时系统的行为建模为一个实时自动机网络,并进行了数据类型的扩展,采用时间μ-算子作为系统的规约语言,主要对系统进行安全性和活性等性质的检验。UppAAL 具有良好的图形化编辑和模拟功能。
目前,已有一些工具以UppAAL 为核心作进一步扩展,如:TIMES是以时间自动机模型验证为基础的一个工具集环境,可以进行建模、可调度分析、系统合成以及特定平台上的代码生成;Save-IDE则是基于构件模型SaveCCM[20]所建立的一个支持构件化嵌入式系统开发的工具集,等等。此外,与接口自动机相关的工具包括:Chic是第一个基于接口自动机理论的原型工具。它是作为Jbuilder 集成环境下的一个插件模块来设计开发的,其目的只是用于对相关理论工作的一个初步验证,现在已经被另一个工具Ticc所替代。
Ticc 的理论基础是接口自动机的一个扩展版本:Sociable Interface,其基本思想仍然是检验构件接口组合中是否兼容。ptolemy II中也实现了基本接口自动机模型的组合兼容性分析工作,不过ptolemy II 是一个包含了多种不同工具集的混成系统建模、分析、合成和代码生成的开发环境。此外,以法国INRIA 为中心的欧洲多个研究机构正在构建的OpenEmbeDD是一个以Eclipse 为开放平台的模型驱动嵌入式系统开发工具集。这是一个庞大的开源工具组合环境,提供嵌入式系统设计(包括软件和硬件)、模拟、验证、合成以及测试等各个阶段的开发支持。
与上述相关工具相比,T-CBESD 的特点在于:首先,可以直接使用UML 的顺序图模型作为系统规约输入进行验证,而不需要系统设计人员去重新学习时序逻辑语言来构造规约说明;避免了在大多数相关工作中需要在不同的形式模型之间进行复杂转换,通常这些转换是需要相当的空间和时间消耗。其次,相比较上述基于接口自动机模型的研究,本文的工作在接口自动机组合兼容性的基础上对构件式嵌入式软件系统设计模型与场景式规约模型之间的一致性问题给出了一个更为完整的验证框架;可以进一步进行各类一致性问题的分析和验证;第三,通过扩展时间区间所得到的实时接口自动机的描述能力本质上与时间自动机的描述能力是等价的,并且通过在顺序图模型中使用时间不等式约束,使得所定义的实时接口自动机网络与带时间约束的顺序图之间的一致性问题更具有一般性。最后,Eclipse 开放平台给工具提供了良好的开发、维护和使用环境。
6.结束语及未来工作
本文在 Eclipse 开放平台上设计并实现了一个基于接口自动机模型的构件化嵌入式软件设计分析与验证的原型工具T-CBESD。该工具的目的是应用于构件化嵌入式软件开发的设计建模阶段,对系统重要功能性质以及与时间相关的实时行为性质进行严格形式化分析和验证,使得设计者可以尽早在系统开发前期发现错误并予以修改,以降低成本并提高系统可靠性的可信度。论文主要内容包括:非实时功能验证以及实时功能验证的理论基础;T-CBESD 的基本设计思想;工具的输入输出接口、状态空间数据结构、验证算法等的设计与实现;以及应用实例分析。
进一步的工作包括以下几个方面:
扩展工具的输入和输出接口形式。输入方面,目前T-CBESD 中自动机模型的XML 文件是需要用户手动生成,我们希望也可以使用Rational Rose 等图形化建模环境作为前端工具来方便用户进行系统接口自动机模型的设计。但是接口自动机与UML 状态机的语法和语义都存在不同之处,需要重新设计一个中间转换过程来处理。同时,考虑在顺序图形式化定义的基础上进一步对UML 交互概观图进行形式化描述,并将其作为工具的另一种扩展形式的输入模型。输出方面,将设计更为完整的验证结果信息XML 文件格式,并考虑与软件测试技术相结合,利用验证结果给出的系统出错(验证失败)行为轨迹来指导生成相应的测试用例。
在工具的核心算法部分,将进一步设计并实现包括资源接口自动机和能耗接口自动机在内的分析与验证算法,以扩展T-CBESD 的功能。同时,考虑到在实时接口自动机组合过程中可能出现的状态空间爆炸问题,将对实时验证算法作进一步改进,设计新的On-the-Fly 验证算法实现,即:在构造一个新状态的时候就对当前路径进行即时验证。
应用复杂的多构件系统设计实例,来对工具的性能进行检验和提高。目前所运行的实例相对比较简单,主要目的是为了检查实现算法的正确性,还需要在复杂多构件系统模型情形下对算法性能作进一步检验和改进。现在我们正在对某无人机飞行控制软件系统进行模型分析和抽取工作,准备将其作为T-CBESD 的一个复杂实例验证。
进一步完善原型工具的操作界面;目前本文的工作主要关注于基本的输入输出处理和核心算法的设计与实现,还需要考虑工具用户界面接口设计的实用性和有效性。
第三篇:嵌入式图像处理系统的软件设计论文
摘要:随着我国智能化、信息化的不断发展,嵌入式系统在多媒体通信、交通控制以及个人数据处理中得到了广泛的应用,计算机视觉技术的应用范围也逐渐增强。嵌入式图像处理系统嵌入式系统和计算机视觉技术的有效融合,可用于网络摄像机、视频监控等领域,采用的是网络化嵌入式硬件系统对图像进行处理,具有重大的运用价值。
关键词:嵌入式;图像处理系统;软件设计
中图分类号:TP3文献标识码:A文章编号:1674-6708(2016)156-0080-02
DOI:10.16607/j.cnki.1674-6708.2016.03.049
在很多领域中,由于科学技术的不断发展,不可避免的需要使用大量的数据,面对这些算法复杂的数据,传统的图像处理系统已经不能满足要求。嵌入式图像处理系统在通讯、医药等方面都发挥着非常重要的作用,正是因为各个领域获得的图像数据越来越多,如何对图像数据快速准确的进行处理显得格外重要。所以需要设计出更优化的图像处理。
1嵌入式系统概述
1.1嵌入式系统的概念
嵌入式系统是建立在计算机技术基础上的应用型专用计算机系统,其软件和硬件都可以剪裁,系统对成本、功耗、功能都提出了更高的要求,具有可靠性强、体积小等优点,可以实现对其他设备的监视、控制和管理。随着嵌入式系统的不断发展,嵌入式系统已经渗透到人们的生活中,无论是在工业、服务业还是消费电子等领域都得到了广泛的应用。
1.2嵌入式系统的特点
与普通的计算机系统相比,嵌入式系统的专用性更强,一般是面向特定运用的,嵌入式处理器一般应用在用户设计的特定系统中,集成性高、体积小、功耗低,不仅具有方便携带的优点,操作系统更是实时操作的,可以满足实时性较强的场合要求。将嵌入式系统运用到应用程序中,在芯片上直接运行而不需要操作系统,未来可以充分利用更多的系统资源,用户需要选择RTOS开发平台,保障软件的质量。嵌入式系统主要包括硬件系统和软件系统,其中硬件系统是基础,软件系统是灵魂,复杂程度非常高。
2系统软件设计
基于RF5软件系统总体设计:嵌入式图像处理系统和传统处理系统一样,主要包括硬件和软件两个方面,硬件包括系统的硬件平台,软件包括嵌入式操作系统和图像处理算法两个方面。其中硬件平台又包括图像储存模块、通信模块和显示模块等,主要是为系统的软件系统提供支持。在图像处理过程中,硬件系统可以为其提供计算、显示、存储等条件[1]。RF5是以DSP和XDAIS为基础的代码参考框架,在DSP软件的设计和开发中具有重要的作用,参考框架在整个程序中具有非常重要的作用,是整个运用应用程序的蓝本。RF5的数据处理元素包括通道、单元、任务和XDAIS算法,这4个元素之间具有紧密的联系,独立又联系。嵌入式操作系统是整个系统的核心系统,提供了包括图形处理任务管理在内的各项管理,经过硬件的初始化、图像信息存储、图像信息显示等过程实现图像处理和存储。
3软件模块化程序实现
3.1初始化模块
软件系统的初始化模块主要包括处理器、RF5模块化初始化、图像处理算法、视频捕获、视频显示通道等。处理器和系统板初始化是指设备重启之后,通过软件配置的方式对外围设备进行配置和选择。系统在进行工作的时候,初始化模块是其执行的第一个任务,执行完初始化模块之后,程序的控制权将会转变到调度程序中,由调度程序来调度接下来的任务。
3.2视频捕获和显示模块
3.2.1视频捕获的实现
视频捕获主要负责将外部的视频解码器解码生成的数字视频信号采集收集起来,并且这个采集的过程非常方便,可以实现实时采集,最终形成的图形处理也是可以实时处理的,可以随时随地对大数据的图像进行处理,这也是其最大的优点和特点。采集到的数字视频信号进入到系统外扩的存储器中,从而实现视频的捕获。视频采集可以自动采集,当单元进入自动采集状态,完成了图像的采集之后,视频端口都会向系统自动发出中断请求,中断服务程序便开始发挥自身的功能,对图像的存储区进行连续更新,图像存储区一旦更新之后,图像采集系统就会采集下一个图像数据,最终进入一个循环。当视频端口的FIFO装满了采集的数据之后,会发生中断信息,进入EDMAISR中断服务程序将视频数据送入到SDRAM中[2]。
3.2.2视频显示的实现
视频显示的实现是通过视频图像显示模块来实现的,视频图像处理模块处理后的图像经过显示模块处理,处理之后将图像编码成数字视频流,标准数字视频流经过系统编码转化为虚拟视频信号,经过解码器之后视频流就变成了标准的模拟视频信号,分别经过EDMA控制器和EDMAISR之后最终进入到视频端口的缓冲区中,经过缓冲器之后,信号会使EDMA中断,送入新的图像信号,并在显示器上显示出来,视频显示的流程。输出作用在外部编辑器中。
3.3图像处理模块
图像处理模块比较灵活,是指在嵌入式的环境下实现对图像的处理。在图像处理系统中,又包括系统功能模块和图像增强模块。系统功能中包含图像增强功能,除了图像功能之外,还包括图像的几何变换、形态运输和图像分析。在图像增强模块中又包括图像的预处理和边缘检测、直方图修正、中值滤波、灰度变换调整,而图像预处理又包括图像平滑和图像锐化。图像平滑就是消除噪声对图像造成的影响,图像平滑的处理是通过高斯低通滤波法来实现,这样做虽然可以消除图像受到噪声的影响,但同时也存在着一定的弊端,图像经过处理之后会变得模糊。图像锐化的目的就是让模糊的图像重新变得清晰。图像模糊是由于图像受到平均或积分运算而造成的,图像锐化就是对其进行逆运算,重新使图像变得清晰[3]。
4结论
嵌入式图像处理系统的软件系统主要包括初始化模块、视频捕获模块、视频显示模块和图像处理模块,在确定了整个软件系统的程序流程之后,就可以分别设计纷纷模块的程序,最终完成整个软件系统的设计。
参考文献
[1]吴锡强.探析嵌入式图像处理系统的设计与实现[J].计算机光盘与软件,2015,12(3):307-309.[2]蒋立丰.嵌入式图像处理系统的设计与研究[D].东华大学,2013,22(21):11-13.[3]宋琦,牟晓光.嵌入式图像处理系统设计[J].信息技术与信息化,2015,22(31):116-117
第四篇:嵌入式心得
11计科4班
115031303
4鲁敏杰
嵌入式实习报告
实习内容:学习并自己动手在Ubuntu系统下制作电子相框
实验目的:Ubuntu操作系统的使用,利用C语言编写程序制作电子相框第一周学习:学习Ubuntu操作系统的简单使用
使用VMware 虚拟机搭建Ubuntu操作系统环境;作为主要由自由软件构建的操作系统,Ubuntu具有庞大的社区力量,用户可以方便地从社区获得帮助。Ubuntu的一些基本命令操作如下所示:
Ls查看系统目录下的文件
Cd进入目录 后接地址cd..返回上级
Gedit进行编译操作 后接需要编译的文件
Cat查看文件 在编译器中查看与vi 相似
Make进行编译make clean 清理编译
Ctrl+Alt+F2 进入Ubuntu系统的控制台
Ctrl+Alt +F7退出控制台操作
ctrl + C控制台操作时终止程序运行
第二周学习:在Ubuntu中利用C语言实现图片的特效运转
电子相册的主体结构在编译器中实现编译,主要学习C语言程序的编写实现图片的特效显示。图片特效的实现学习完毕,就开始制作电子相册,实现图片的添加。
图片的添加:图片加入文件中。在showpic.c文件中实现特效 在main.c文件中实现显示。用C语言编写的特效有上到下、左到右、中间分屏、上下分屏、圆的扩展与缩小、四分屏等。
部分特效关键代码如下:
画点实现在屏幕中设定坐标、参数中添加了颜色
void pixel_point(struct fb_var_screeninfo fb_var,char *mem, int x, int
y, int color)//画点函数
{int *buf =(int *)((fb_var.xres*y+x)*fb_var.bits_per_pixel/8 + mem);
*buf = color;
}
利用C语言实现画圆的特效
void pixel_circle(struct fb_var_screeninfo fb_var, char *mem, int x, int
y,int len,int color)//画圆
{int i,j;
for(i=0;i for(j=0;j if(((j-x)*(j-x)+(i-y)*(i-y))>(len*len))continue; else pixel_point(fb_var,mem,j,i,color); } 满屏打印输出函数 voidpixel_full_screen(struct fb_var_screeninfo fb_var, char *mem,int color)//满屏 {int i,j; for(i=0;i for(j=0;j pixel_point(fb_var,mem,j,i,color); usleep(1000); } 第三周学习:制作一个完整可运行的相册程序 编程在showpic.c函数中实现图片的特效输出;修改showpic.c添加已有特效; 编程main.c实现图片及特效的可控定向显示;完成实际操作并成功运行通过验收 学习心得: Ubuntu操作系统与Linux操作系统相似学习起来不难,超级终端的使用就是命令行的操作,这点在以前学习的Linux操作系统中有一定的基础。最重要的感受就是特效算法的实现。这是一个学习C语言与linux的很好机会。出现问题: 1.自下到上或者自右到左实现特效时候无法正常运行,只能出现两张图片的一半效果。 2.分屏输出出现很多重合的图片,不能按照一定的速率打印。 解决问题: 多次刷屏,当读出一半图片时候,重新读取另一半图片以及新的另一半图片。不能安装预定的方式打印图片 心得: 在为期三周的实习过程中,首先了解在VMware虚拟机上搭建的Ubuntu操作系统,加深了对Linux系统的理解和认识。其次就是学会一些基本的图片特效的实现,由于时间紧迫的缘故,不能熟练的掌握。但是实现一些基本特效还是比较容易的,对C程序又有了新的理解。总是犯一些很浅显的错误,说明还是学的不够扎实。这次实习也给了重新认识自己的机会,知道了以前学到的跟实践起来还是有很大的差别,面临工作的压力,我们这点能力是不够看的。要想找到理想的工作,同志仍需努力! 专题课学习至今,学到了很多东西。而找工作时,各种笔试面试中,深刻地体会到“嵌入式系统”的重要性。这让我更坚定了学好嵌入式系统的想法。 嵌入式系统这门课和C语言颇有关联,这也重新夯实了我的C语言基础。而良好的C语言能力,也是学习嵌入式的必备基础。我决定在学好基础后,在对嵌入式进行扩展学习。 据了解嵌入式学习主要有两方面:软件和硬件。嵌入式软件的比较多,而做硬件不多,但多是高手。嵌入式的软件又有好多种,主要是针对不同CPU的,但是基本都是用C语言的,还有极少的汇编,主要在BOOT启动、初始代码中。目前来说,嵌入式Linux比较流行,安卓就是基于linux内核的。wince、Vxworks什么的貌似不多,特别是vxworks。 我也对嵌入式系统的应用方面进行了了解。现在在市场还是蛮吃香的,可从事的就业方向还是蛮多的比如:消费类电子(手机、PDA、游戏机)、数字 多媒体(网络点播、机顶盒)、汽车电子(导航仪)、医疗电子、工业控制等行业。 嵌入式系统是二十一世纪科技领域的重大创新,必将推进全球经济社会高速发展,实现人类发展史上的重大突破。科学在发展,人类在进步,随着一代又一代IT精英们的不断努力,未来的嵌入式系统一定会是更加方便人们的工作、学习、生活的好伴侣。 据了解,嵌入式市场有非常大的机会,预计到2012年将有30亿台嵌入式设备交货。这样一个“爆炸性”的增长主要是由于终端用户越来越基于连接性的用户体验及应用程序来购买具有智能、连接性、服务导向的设备。 附 嵌入式系统是“控制、监视或者辅助装置、机器和设备运行的装置(”devices used to control, monitor, or assist the operation of equipment, machinery or plants)。从中可以看出嵌入式系统是软件和硬件的综合体,还可以涵盖机械等附属装置。目前国内一个普遍被认同的定义是:以应用为中心、以计算机技术为基础、软件硬件可裁剪、适应应用系统对功能、可靠性、成本、体积、功耗严格要求的专业计算机系统。 本文从嵌入式系统的 等方面来概要性地介绍嵌入式系统。 1.嵌入式系统的概念 1.1嵌入式系统的定义 根据IEEE(电气和电子工程师协会)的定义,嵌入式系统是“控制、监视或者辅助装置、机器和设备运行的装置”(devices used to control, monitor, or assist the operation of equipment, machinery or plants)。从中可以看出嵌入式系统是软件和硬件的综合体,还可以涵盖机械等附属装置。目前国内一个普遍被认同的定义是:以应用为中心、以计算机技术为基础、软件硬件可裁剪、适应应用系统对功能、可靠性、成本、体积、功耗严格要求的专业计算机系统。 1.2 嵌入式系统的特点 1.系统内核小。由于嵌入式系统一般是应用于小型电子装置的,系统的资源相对有限,所以内核较之传统的操作系统要小得多。 2.专用性强。嵌入式系统的个性化很强,其中的软件系统和硬件的结合非常紧密,一般要针对硬件进行系统的移植,即使在同一品牌、同一系列的产品中也需要根据系统硬件的变化和增减不断进行修改。同时针对不同的任务,往往需要对系统进行较大更改,程序的编译下载要和系统相结合,这种修改和通用软件的“升级”是完全两个概念。 3.系统精简。嵌入式系统一般没有系统软件和应用软件的明显区分,不要求其功能设计及实现上过于复杂,这样一方面利于控制系统成本,同时也利于实现系统安全。 4.高实时性的系统软件(OS)是嵌入式软件的基本要求。而且软件要求固态存储,以提高速度;软件代码要求高质量和高可靠性。 5.嵌入式软件开发要想走向标准化,就必须使用多任务的操作系统。嵌入式系统的应用程序可以没有操作系统直接在芯片上运行;但是为了合理地调度多任务、利用系统资源、系统函数以及和专家库函数接口,用户必须自行选配RTOS(Real-Time Operating System)开发平台,这样才能保证程序执行的实时性、可靠性,并减少开发时间,保障软件质量。 6.嵌入式系统开发需要开发工具和环境。由于其本身不具备自举开发能力,即使设计完成以后用户通常也是不能对其中的程序功能进行修改的,必须有一套开发工具和环境才能进行开发,这些工具和环境一般是基于通用计算机上的软硬件设备以及各种逻辑分析仪、混合信号示波器等。开发时往往有主机和目标机的概念,主机用于程序的开发,目标机作为最后的执行机,开发时需要交替结合进行。 1.3几个关键概念的解释 1、嵌入式处理器 嵌入式系统的核心,是控制、辅助系统运行的硬件单元。范围极其广阔,从最初的4位处理器,目前仍在大规模应用的8位单片机,到最新的受到广泛青睐的32位,64位嵌入式CPU。 2、实时操作系统 实时操作系统(RTOS-Real Time Operating System): 嵌入式系统目前最主要的组成部分。根据操作系统的工作特性,实时是指物理进程的真实时间。实时操作系统具有实时性,能从硬件方面支持实时控制系统工作的操作系统。其中实时性是第一要求,需要调度一切可利用的资源完成实时控制任务,其次才着眼于提高计算机系统的使用效率,重要特点是要满足对时间的限制和要求。 3、分时操作系统 对于分时操作系统,软件的执行在时间上的要求,并不严格,时间上的错误,一般不会造成灾难性的后果。目前分时系统的强项在于多任务的管理,而实时操作系统的重要特点是具有系统的可确定性,即系统能对运行情况的最好和最坏等的情况能做出精确的估计。 4、多任务操作系统 系统支持多任务管理和任务间的同步和通信,传统的单片机系统和DOS系统等对多任务支持的功能很弱,而目前的Windows是典型的多任务操作系统。在嵌入式应用领域中,多任务是一个普遍的要求。 5、实时操作系统中的重要概念 系统响应时间(System response time):系统发出处理要求到系统给出应答信号的时间。 任务换道时间(Context-switching time):任务之间切换而使用的时间。 中断延迟(Interrupt latency):机器接收到中断信号到操作系统作出响应,并完成换道转入中断程序的时间。 6、实时操作系统的工作状态 实时系统中的任务有四种状态:运行(Executing),就绪(Ready),挂起(Suspended),冬眠(Dormant)。 运行:获得CPU控制权。 就绪:进入任务等待队列,通过调度转为运行状态。 挂起:任务发生阻塞,移出任务等待队列,等待系统实时事件的发生而唤醒,从而转为就绪或运行。 冬眠:任务完成或错误等原因被清除的任务,也可以认为是系统中不存在的任务。 任何时刻系统中只能有一个任务在运行状态,各任务按级别通过时间片分别获得对CPU的访问权。 2.嵌入式系统的组成 有关嵌入式系统的组成非常多,限于篇幅,本文只介绍其中机电最关键概念。嵌入式系统的组成 1)嵌入式系统硬件层。一般包括有:嵌入式处理器、存储器、I/O系统和外设 2)嵌入式系统的软件系统。包括:操作系统、应用软件 嵌入式系统的开发工具(1)硬件开发工具包括:仿真器等;其它(示波器等)(2)软件开发工具包括:编译、连接、定位软件,通常使用C语言;调试软件。 3)中间层。它将系统软件与底层硬件部分隔离,使得系统的底层设备驱动程序与硬件无关。4)应用层 一个嵌入式系统装置一般都由嵌入式计算机系统和执行装置组成,如图1-1所示,嵌入式计算机系统是整个嵌入式系统的核心,由硬件层、中间层、系统软件层和应用软件层组成。执行装置也称为被控对象,它可以接受嵌入式计算机系统发出的控制命令,执行所规定的操作或任务。 2.1硬件层 硬件层中包含嵌入式微处理器、存储器(SDRAM、ROM、Flash等)、通用设备接口和I/O接口(A/D、D/A、I/O等)。在一片嵌入式处理器基础上添加电源电路、时钟电路和存储器电路,就构成了一个嵌入式核心控制模块。其中操作系统和应用程序都可以固化在ROM中。 2.1.1、嵌入式微处理器 嵌入式系统硬件层的核心是嵌入式微处理器,嵌入式微处理器与通用CPU最大的不同在于嵌入式微处理器大多工作在为特定用户群所专用设计的系统中,它将通用CPU许多由板卡完成的任务集成在芯片内部,从而有利于嵌入式系统在设计时趋于小型化,同时还具有很高的效率和可靠性。 嵌入式微处理器的体系结构可以采用冯诺依曼体系或哈佛体系结构;指令系统可以选用精简指令系统(Reduced Instruction Set Computer,RISC)和复杂指令系统CISC(Complex Instruction Set Computer,CISC)。RISC计算机在通道中只包含最有用的指令,确保数据通道快速执行每一条指令,从而提高了执行效率并使CPU硬件结构设计变得更为简单。 嵌入式微处理器有各种不同的体系,即使在同一体系中也可能具有不同的时钟频率和数据总线狂度,或集成了不同的外设和接口。据不完全统计,目前全世界嵌入式微处理器已经超过1000多种,体系结构有30多个系列,其中主流的体系有ARM、MIPS、PowerPC、X86和SH等。但与全球PC市场不同的是,没有一种嵌入式微处理器可以主导市场,仅以32位的产品而言,就有100种以上的嵌入式微处理器。嵌入式微处理器的选择是根据具体的应用而决定的。 2.1.2、存储器 嵌入式系统需要存储器来存放和执行代码。嵌入式系统的存储器包含Cache、主存和辅助存储器。 1.Cache Cache是一种容量小、速度快的存储器阵列它位于主存和嵌入式微处理器内核之间,存放的是最近一段时间微处理器使用最多的程序代码和数据。 在嵌入式系统中Cache全部集成在嵌入式微处理器内,可分为数据Cache、指令Cache或混合Cache,Cache的大小依不同处理器而定。一般中高档的嵌入式微处理器才会把Cache集成进去。 2.主存 主存是嵌入式微处理器能直接访问的寄存器,用来存放系统和用户的程序及数据。它可以位于微处理器的内部或外部,其容量为256KB~1GB,根据具体的应用而定,一般片内存储器容量小,速度快,片外存储器容量大。 常用作主存的存储器有: ROM类 NOR Flash、EPROM和PROM等。 RAM类 SRAM、DRAM和SDRAM等。 其中NOR Flash 凭借其可擦写次数多、存储速度快、存储容量大、价格便宜等优点,在嵌入式领域内得到了广泛应用。 3.辅助存储器 辅助存储器用来存放大数据量的程序代码或信息,它的容量大、但读取速度与主存相比就慢的很多,用来长期保存用户的信息。 2.1.3、通用设备接口和I/O接口 嵌入式系统和外界交互需要一定形式的通用设备接口,如A/D、D/A、I/O等,外设通过和片外其他设备的或传感器的连接来实现微处理器的输入/输出功能。 2.2软件系统 系统软件层由实施多任务操作系统(Real-time Operation System,RTOS)、文件系统、图形用户接口(Graphic User Interface,GUI)、网络系统及通用组件模块组成。RTOS是嵌入式应用软件的基础和开发平台。 嵌入式实时操作系统: 实时多任务操作系统(RTOS)是嵌入式应用软件的基础和开发平台。RTOS是一段嵌入在目标代码中的程序,系统复位后首先执行,相当于用户的主程序,其他程序都建立在RTOS之上。 2.3中间层 硬件层与软件层之间为中间层,也称为硬件抽象层(Hardware Abstract Layer,HAL)或板级支持包(Board Support Package,BSP),它将系统上层软件与底层硬件分离开来,使系统的底层驱动程序与硬件无关,上层软件开发人员无需关心底层硬件的具体情况,根据BSP 层提供的接口即可进行开发。该层一般包含相关底层硬件的初始化、数据的输入/输出操作和硬件设备的配置功能。 BSP具有以下两个特点: 硬件相关性:因为嵌入式实时系统的硬件环境具有应用相关性,而作为上层软 件与硬件平台之间的接口,BSP需要为操作系统提供操作和控制具体硬件的方法。 操作系统相关性:不同的操作系统具有各自的软件层次结构,因此,不同的操作系统具有特定的硬件接口形式。 3.嵌入式系统的开发 3.1嵌入式两种开发 硬件,主要使用语言是C语言和汇编,例如做dsp开发,做驱动开发,这类的开发对硬件要求比较高,短期内比较难掌握,除非是专业人士,另外,这类开发的就业机会比较少,因为国内的硬件设计力量很弱,稍复杂的硬件都交给国外公司设计,所以大学生找这样的工作很难,这也是为什么很多这类的毕业生都转行去做应用层的软件开发或者做网络维护之类的工作了。 软件,主要基于嵌入式操作系统,例如Symbian、Linux、Windows mobile、Android等等,开发人员主要从事嵌入式操作系统和应用软件的开发。特点是:比较容易上手学习,就业机会多,因为嵌入式设备的增值很大程度上取决于嵌入式软件,这占了嵌入式系统的最主要工作。越是智能设备越是复杂系统,软件越起关键作用,而且这是目前的趋势,所以需要大量的研发人员,而且就业前景也非常的看好。 3.2嵌入式系统开发生命周期 硬件与软件将同时进行开发。理解硬件与软件功能相互之间的关系及界限有助于确保设计要求得到完整正确的理解和实现。 早在设计要求的定义与分析阶段,就必须分配系统仿真、原型设计和行为建模结果、一旦分配结束,就可以立即着手具体的设计和实现。实时系统开发中软硬件的并行设计会使用到各种分析技术,包括: 1.硬件与软件仿真; 2.硬件/软件协同仿真; 3.可调度的建模技术,如速率恒定分析; 4.原型设计和渐进式开发。 低层仿真可以用来为总线宽度和数据流程建模,这对性能评估是非常有用的。高层仿真可以满足功能的交互,并促成硬件/软件权衡研究及有效性设计。 4.嵌入式系统的现状与发展 发展现状: 随着信息化,智能化,网络化的发展,嵌入式系统技术也将获得广阔的发展空间。 硬件方面,不仅有各大公司的微处理器芯片,还有用于学习和研发的各种配套开发包。目前低层系统和硬件平台经过若干年的研究,已经相对比较成熟,实现各种功能的芯片应有尽有。而且巨大的市场需求给我们提供了学习研发的资金和技术力量。 从软件方面讲,也有相当部分的成熟软件系统。国外商品化的嵌入式实时操作系统,已进入我国市场的有WindRiver、Microsoft、QNX和Nuclear等产品。 发展趋势: 信息时代,数字时代使得嵌入式产品获得了巨大的发展契机,为嵌入式市场展现了美好的前景,同时也对嵌入式生产厂商提出了新的挑战,从中我们可以看出未来嵌入式系统的几大发展趋势:。 1.嵌入式开发是一项系统工程,因此要求嵌入式系统厂商不仅要提供嵌入式软硬件系统本身,同时还需要提供强大的硬件开发工具和数据库支持。 目前很多厂商已经充分考虑到这一点,在主推系统的同时,将开发环境也作为重点推广。2.网络互联成为必然趋势。 未来的嵌入式设备为了适应网络发展的要求,必然要求硬件上提供各种通信接口。传统的单片机对于网络支持不足,而新一代的嵌入式处理器已经开始内嵌网络接口,支持更多协议。 3.精简系统内核、算法,降低功耗和软硬件成本。 未来的嵌入式产品是软硬件紧密结合的设备,为了减低功耗和成本,需要设计者尽量精简系统内核,只保留和系统功能紧密相关的软硬件。第五篇:报告嵌入式心得