汽车音响系统软件设计与实现(3)

２．５．３系统平台—Ｊ。ＭＸ．ＯＳ”概述

计算机系统与其他硬件共同组成整套电子设备，该设备的功能并不是以计算机的软件功能为依据，计算机在其中所起的作用只是局部的控制或数据分析等。这样的计算机系统称为嵌入式系统（ＥｍｂｅｄｄｅｄＳｙｓｔｅｍ）。

在嵌入式软件运行的操作系统平台，称为嵌入式操作系统。它是运行在嵌入式芯片环境中，对整个芯片以及它所操作、控制的各种部件装置等等资源进行统一协调、调度、指挥和控制的系统软件【５】。由于嵌入式产品的多样化，针对自身的功能需求和单片机标准，各厂商定制或选择了自己的嵌入式操作系统，这导致嵌入式系统的硬件的依赖性比较大。

根据Ｉ＼Ｓ事业部的项目经营背景——面向Ａｌｐｉｎｅ公司的嵌入式ＣＡ软件开发，现主要选用的是ＭｏｄｕｌｅＥｘｅｃｕｔｉｖｅＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ——ＭＸ．ＯＳ的嵌入式操作系统。这是Ａｌｐｉｎｅ公司提出的面向汽车音响软件应用的“实时”多任务系统规范。

ＭＸ．ＯＳ系统的运行机制主要表现为以下几点：

基于“Ｔａｓｋ”的资源分配方式：

Ｔａｓｋ是ＭＸ—ＯＳ管理、实行和终了ＣＰＵ的资源分配的最小单位启动。在使用ＭＸ．ＯＳ系统的任务时，通过ＩＤ来索引注册在系统中的任务，Ｔａｓｋ之间无优先级的设定，采用

大连理工大学专业学位硕士学位论文

“ＦＣＦＳ”的调度方式，所以ＭＸ—ＯＳ并不是真正意义的ＲＴＯＳ（Ｒｅａｌ

Ｓｙｓｔｅｍ）。ＴｉｍｅＯｐｅｒａｔｉｏｎ

Ｔａｓｋ的本质是模块内部的一个处理流程，ＭＸ．ＯＳ中的Ｔａｓｋ列表（ｔａｓｋｔｂｌ．ｃ）中各Ｔａｓｋ为各个模块的入口函数，入口函数中会对“外界”的触发条件进行判断（Ｐｒｏｃｅｓｓ—Ｃｈｅｃｋ过程），然后进行相应的动作，即模块内各功能函数的调用。

周期管理：

ＭＸ．ＯＳ系统中提供了专门用于周期调用任务的接口，用户可以在指定的位置进行任务的添加注册，这是ＭＸ—ＯＳ系统维护的专有任务为所有功能模块共享的。系统中定义的周期是４ｍｓ，并同时预留了８ｍｓ，１６ｍｓ，６４ｍｓ定周期任务注册的接口。

中断管理：

ＭＸ—ＯＳ系统的中断处理采用了“硬件机制”，实现的过程主要是采用直接启动中断Ｈａｎｄｌｅｒ（处理程序）的方式来响应中断，这种中断Ｈａｎｄｌｅｒ不需要通过ＯＳ的管理参与，直接启动中断处理专用程序。

“Ｅｖｅｎｔ驱动”的程序设计思想：

软件系统中任何动作的执行都要以一定的条件为基础，通常称引起动作的时间为Ｔｒｉｇｇｅｒ（触发），类似于ＯＯＰ中“Ｍｅｓｓａｇｅ条件”为基础，通常称引起动作的时间为Ｔｒｉｇｇｅｒ（触发），类似于ＯＯＰ中“Ｍｅｓｓａｇｅ驱动”的程序实现机制，在ＭＸ－ＯＳ中引入了Ｅｖｅｎｔ（事件）的概念以其作为模块间的通信的载体。

Ｅｖｅｎｔ的本质是一个“条件触发”的信息，发送该信息的目的在于通知信息的接收者执行一个指定的Ｔａｓｋ，从信息接收者的角度看来，接收到这个Ｅｖｅｎｔ就是其决定执行下一个Ｔａｓｋ的判定条件。因此Ｅｖｅｎｔ的发送和接收就成为了决定整个系统Ｔａｓｋ执行的动力和原因。映射到具体的程序实现中，Ｅｖｅｎｔ可以以一个结构体的形式表示出来（ＭＸ．ＯＳ中以一个全局变量‘ＭＯＮ＿ｔｅｍｐ＿ＭｅｓｓａｇｅＳｔｒｕｃｔ’进行相关信息的取得）【９１。Ｅｖｅｎｔ结构定义为

ｓｔｒｕｃｔｍ＿ｅｎｔｒｙ｛

ＳｒｃＭｏｄｕｌｅｌＤ；／／ＳｒｃＭｏｄｕｌｅＩＤ：ＩＮＴ８Ｕ

ＩＮＴ８ＵＥｖｅｎｔ发送者——源ＭｏｄｕｌｅＩＤ；ＤｅｓｔＭｏｄｕｌｅｌＤ；／／ＤｅｓｔＭｏｄｕｌｅｌＤ：Ｅｖｅｎｔ接受者——目标ＭｏｄｕｌｅＩＤ；

Ｅｖｅｎｔ；ＩＮＴｌ６Ｕ

Ｏｐｔｉｏｎｔｕ／／Ｅｖｅｎｔ：Ｅｖｅｎｔ的ＩＤ号；ＥｖｅｎｔＯｐｔ；／／ＥｖｅｎｔＯｐｔ：传递的参数；

）；

Ｔａｓｋ与Ｅｖｅｎｔ之间的关系表现为：发送Ｅｖｅｎｔ的目的在于驱动Ｔａｓｋ的执行，而Ｅｖｅｎｔ的发送和接收本身就是一个Ｔａｓｋ。对于发送Ｅｖｅｎｔ的Ｔａｓｋ来说，其本质的目的就是对

汽车音响系统ＲＤＳ软件设计与实现

ＭＸ—ＯＳ中的全局变量进行改写更新。当ＭＸ．ＯＳ按照Ｔａｓｋ列表的顺序调用各个模块的Ｔａｓｋ时，相关模块会去进行该全局变量的数值读取，一旦经过判定动作后发现该信息是针对自己提出的请求时，便会进行相应Ｔａｓｋ的执行。

２．６本章小结

本章的主要内容是简述ＲＤＳ技术的基础知识，对目标软件系统的硬件平台——汽车音响制品和系统平台——－ⅣⅨ一ＯＳ进行介绍，侧重点在对ＭＸ．ＯＳ平台上的程序设计实现机制的阐述，这是目标软件结构设计的决定因素。目标软件的设计与实现均是以此为基础进行展开。

大连理工大学专业学位硕士学位论文

３需求分析

本章是目标软件系统的需求分析部分，从ＣａｒＡｕｄｉｏ制品的功能出发，针对ＲＤＳ系统中的“ＡＭＳＳ”（ＡｕｔｏＭＡＸＳｔａｔｉｏｎＳｅａｒｃｈ，自动追踪）部分进行逐步的分解和细化，最终转化为软件可实现的功能点，以此作为后续软件设计和实现的基准点。

３．１相关硬件平台

由于广播数据系统ＲＤＳ的广泛应用，使得可以利用ＲＤＳ方式数字化的传输经过编码，所有提供的信息都是基于事件的，它能够提供用户消息和系统消息两大类信息。系统消息是指仅供ＲＤＳ解码器用于解码、信息管理的消息，它们可通过８Ａ、４Ａ、３Ａ或１Ａ数据帧进行传输。其中用户消息是指要提供给用户相关通信信息，它只能由ＲＤＳ数据帧的８Ａ组传输。除了上述基本信息之外，为了详细地说明具体的事件或位置，用户消息还可能包括一些对基本信息中某些参数进行说明和解释的附加信息。附加信息的传输需要两个或更多个８Ａ数据帧。ＲＤＳ消息最多可由五个ＲＤＳ数据帧序列组成，第一帧ＲＤＳ数据是基本的用户信息，后续的数据帧是对第一帧数据的进一步解释。

消息包括以下五个基本方面：事件描述——信道的可用程度的细节描述；位置——汽车和信号源之间区域、路段或点位置；方向和范围信息——描述外界事件影响的相邻路段或位置点，以及受影响的车辆行驶方向；持续时间——此项信息预测的持续有效时间。用户信息可以通过各种服务和多种通信手段进行发布，包含车载设备、ＰＤＡ、手机等。对于所有的服务，为保证各个信息提供商和各种产品（接收终端）对发送、接收的数据的兼容性，需要对接口中的用来发布的数据和数据结构进行清晰的定义，并统一使用标准格式。

ＣＡ制品中的ＲＤＳ的功能实现同样需要硬件与软件的共同协作以最终实现。ＲＤＳ系统需要如下硬件的支持：

（１）ＭＡＩＮＣＰＵ：相关数据的接收，处理与发送，是整个系统实现的控制源【１１１。（２）ＴｕｎｅｒＣｈｉｐ：接收、解析广播信号，并把ＲＤＳ信号和广播声音信号分离。

（３）ＤＳＤｅｃｏｄｅｒ：接收ＴｕｎｅｒＣｈｉｐ发送的ＲＤＳ信号，将其数字化，对其进行解析分组，并通过ＩＩＣ．ＢＵＳ发送给ｔｘＣＯＭ，进行进一步的处理【ｌ引。

（４）Ｅ．Ｖｏｌｕｍｅ芯片：接收ＴｕｎｅｒＣｈｉｐ发送的广播信号，进行声音的播放处理ｌｌ引。ＣＡ制品中的ＲＤＳ系统的硬件平台结构如图３．１所示：

汽车音响系统ＲＤＳ软件设计与实现

图３ …… 此处隐藏：2323字，全部文档内容请下载后查看。喜欢就下载吧 ……