摘  要： 从系统设计入手,介绍了开放的多媒体应用" title="多媒体应用">多媒体应用平台OMAP^TM的硬件和软件结构,及OMAP^TM平台的实现——DSP/BIOS^TM桥技术的概念和实现。

　　关键词： OMAP  DSP/BIOS桥  XDAIS  RTOS

　　今天的系统设计者面对的是日益增长的应用需求,嵌入式系统设计显得保守,新的系统设计理念是在开放式系统平台上进行设计。开放式平台可以不断地更新和下载新的应用,使产品功能常新,从而使产品在市场竞争中立于不败之地。

　　选择好平台是关键。本文介绍TI公司的OMAPTM平台(Open Multimedia Applications Platform)。它是基于DSP的开放多媒体应用平台,已被NOKIA、ERICSSON、SONY、HANDSPRING等公司选用。

  OMAP^TM平台是双核结构,由ARM核及DSP核组成,DSP以低功耗高性能实现多媒体应用。目前在OMAP^TM平台上实现的多" title="的多">的多媒体应用有语音、音频、图像、视频等。

1 OMAPTM的开放性

　　OMAPTM的开放性表现在以下三个方面：

　　(1)对于用户来说,基于OMAP^TM平台的应用是开放的。针对产品的操作系统,用户不仅可以下载基于该操作系统的应用程序" title="应用程序">应用程序,还可以下载基于DSP的多媒体应用程序。也就是说OMAP^TM平台透过先进的操作系统平台不仅开放了ARM,而且开放了DSP。通过DSP/BIOS^TM桥,DSP的资源就如同ARM的外设一样 通过操作系统的API被调用。DSP/BIOS^TM桥在OMAP^TM平台上实现了双核的无缝连接。

　　(2)对于独立的软件制造商(ISV)来说,为OMAP^TM平台开发商业应用软件的标准是开放的。算法的兼容性及可评估性是关键。只有算法的性能、占用资源及接口方式是标准的,算法才能离架。TI公司的XDAIS(eXpressDSP^TM 算法标准)的出台解决了DSP算法的标准化问题,所有XDAIS兼容算法都必须得到TI公司的兼容性测试。而且DSP/BIOS^TM桥提供XDAIS兼容算法接口。ISV开发的XDAIS兼容算法可直接用于OMAP^TM平台。

　　(3)对于原始设备制造厂商(OEM)来说,可以开放先进的操作系统。OMAP^TM平台支持的操作系统很多,如Microsoft的WINDOWS CE、Synbian的EPOC、ATI的NUCLEUS、Windriver的VXWORKS和LINUX等,OEM厂商可以按照自己的需求和LICENCE情况去定制。同时,OEM厂商还可以根据自己的特点和产品的功能去开放地选购算法和软件。借助于第三方OS及TI的第三方网络等,OEM厂商仿佛置身于一个巨大软件超市,各种算法及软件商品性能价格一目了然,尽可以取其所需。

　　OMAP^TM平台分为软件和硬件平台" title="硬件平台">硬件平台。为满足多媒体应用的需求,硬件平台必须高性能、低功耗;同时为满足应用的发展需求,硬件平台要具有不断升级的能力。OMAP^TM软件平台的核心是DSP/BIOS^TM桥,OMAP^TM的软件平台独立于硬件平台。

2 OMAPTM的硬件平台

　　OMAP^TM的多媒体应用取决于它内部硬件结构的实现,DSP是实现多媒体应用的关键。当然其内部的硬件加速器、DMA及交通控制单元等也举足轻重。

　　OMAP^TM硬件平台主要由DSP核、ARM核及交通控制(TRAFFIC CONTROLLER)单元组成。这三个部分可以独立地进行时钟管理,有效地控制功耗。

　　OMAP^TM平台采用双核技术使操作系统的效率和多媒体代码的执行更加优化。实时性任务由DSP完成,非实时性任务和系统控制工作由ARM完成,从而使系统的功耗降至最低,成功地解决了性能与功耗的最佳组合问题。

　　OMAP^TM平台的硬件平台会逐步升级,以满足日益增长的应用需求。目前的ARM核选用ARM925TDMI,其上可以运行先进的操作系统如WINDOWS CE、EPOC等。DSP核采用TMS320C55X^TM DSP,其上运行的RTOS是DSP/BIOS^TM。TMS320C55X^TM DSP有高度并行能力,它的32位读写能力和功能强大的EMIF、双流水线的独立操作及双MAC的运算能力,以及它的变长指令、用户自定义的并行指令是优异的多媒体性能的保证。其采用模块化的IDLE模式,最大程度地降低了功耗。OMAPTM硬件平台的框图如图1所示。

3 OMAP^TM的软件结构

　　OMAPTM的软件结构在两个操作系统上,一是基于ARM的先进的OS如 EPOC、WINCE等;二是基于DSP的DSP/BIOS^TM。如何使两个操作系统无缝工作,是实现开放的软件平台的关键。这个核心技术就是首次正式应用在OMAP^TM平台上的DSP/BIOS^TM桥。

3.1 DSP/BIOS^TM桥

　　DSP/BIOS^TM桥用于连接DSP/BIOS和其他通用处理器(GPP)上的OS。GPP在 OMAP^TM里是ARM,还可以是MIPS(Microprocessor without Interlocked Pipe Stage)等。DSP/DIOSTM桥具有以下特点：

　　·高性能;

　　·有效利用GPP和DSP的资源;

　　·可移植到不同的GPP和DSP硬件平台上;

　　·可移植到不同的GPP和DSP操作系统上;

　　·支持多个DSP和一个GPP;

　　·从GPP应用程序中使用;

　　·对象为中心的设计;

　　·高可靠性;

　　·APIs与将来的版本向后兼容。

    DSP/BIOSTM桥用于非对称的,由一个通用的处理器(GPP)和一个或多个DSP组成的多处理器环境。DSP/BIOSTM桥作为GPP OS和DSP OS的软件组合,把两个操作系统连接在一起。这种连接能够使GPP端的客户与DSP上的任务交换信息和数据。连接分为两种类型的子连接,消息子连接和数据流子连接。每种子连接都按顺序传递消息,哪个消息先到消息链,哪个消息就先被传递;同样哪个数据流先到数据流链,哪个数据流就先被传递。每个子连接都独立地进行操作,例如：GPP先发送数据流,然后发送消息,如果消息有高优先级,那么消息比数据流先到DSP。

　　DSP任务通常用消息对象传送控制和状态信息,用数据流对象传送高效实时数据流。图2表示GPP客户端程序和DSP任务间的关系。

3.2 主机软件结构

　　对于GPP操作系统来说,DSP/BIOS^TM桥增加了API,它能使GPP应用和驱动程序同时利用DSP的资源。GPP客户端可以通过API完成以下工作：

　　·初始化DSP上的信号处理任务;

　　·与DSP任务交换信息;

　　·与DSP任务双向交换数据流;

　　·停止、激活、删除DSP任务;

　　·进行资源的状态查询。

　　一个GPP应用程序或设备驱动程序" title="设备驱动程序">设备驱动程序可以使用DSP/BIOS^TM桥API与DSP子系统上的DSP任务进行通信。例如：一个GPP WAVE设备驱动程序可以利用API发送信息给DSP任务来管理数据从ADC到DAC。

　　GPP端DSP/BIOSTM桥API以库的形式实现,它调用特定硬件的设备驱动程序,如果没有一个针对特定硬件的设备驱动程序,API是不能工作的。对于GPP API来说,这些专用于DSP子系统的设备驱动程序执行I/O操作和控制操作,就象其他GPP外设的设备驱动程序一样。每个DSP设备驱动程序支持特定的DSP子系统,如果存在同一个DSP硬件的多个实例,那么这个DSP设备驱动程序的多个实例都会在GPP OS上运行。

　　DSP设备驱动程序为GPP端的API完成很多功能,它负责DSP的自举工作,为DSP装入RTOS和应用程序代码,并启动DSP运行。一旦DSP已经初始化并且RTOS进入运行状态,DSP设备驱动程序就开始了GPP和DSP间的消息和数据流的传递工作。与它对等的是DSP上的DSP主机驱动程序。DSP设备驱动程序和DSP主机驱动程序对所传递的内容并不关心。

3.3 DSP软件结构

　　对于DSP RTOS,DSP/BIOSTM桥增加了目标独立的流式I/O界面(STRM)、消息界面(NODE)和资源管理(RM)服务器。RM服务器就象DSP RTOS的一个任务一样运行,并服务于GPP的命令和查询。一旦GPP端的程序通过GPP端的API发出请求,RM服务器响应,启动或停止DSP信号处理节点。

　　由RM服务器启动的任务采用STRM和NODE界面,作为对应的GPP客户程序的服务器,并根据GPP客户程序发出的信息进行信号处理工作。典型的,一个DSP 任务用设备独立的流式I/O把数据从源端传送到宿主端,并在数据传送过程中进行特定的处理和转换。例如：一个WAVE音频任务从GPP WAVE设备驱动程序接收到数据后,可能要执行音频解压缩(ADPCM,MPEG,CELP),然后把解压缩的线性采样送到DAC。

3.4 DSP/BIOS^TM桥的功能组件

　　DSP/BIOS^TM桥的功能组件如图3所示。

　　在典型配置中,GPP与一个或多个DSP相连,最终用户在GPP上的应用程序调用媒体服务模块或驱动程序,通过DSP/BIOS^TM桥来管理DSP资源。

　　资源管理器负责动态调度DSP资源,监控DSP资源,动态装入DSP代码,发生请求冲突时,负责实现DSP资源的管理策略。资源管理器在平台管理器之上。平台管理器负责静态装入DSP代码,启动或停止DSP实现数据流。平台管理器位于GPP OS适配器及负责与DSP通信的连接驱动器之上。

　　DSP上的RTOS是基础,它通过主机连接驱动器与GPP通信。在DSP RTOS的上面是资源管理(RM)服务器。RM服务器的主要职责是在资源管理器的控制下动态地创建、执行和删除DSP处理节点,其他职责包括改变任务的优先级并响应资源管理器的配置命令和状态查询。一个专门的流用来接收来自资源管理器的命令,另一个专门的流用来发响应信号给资源管理器。

　　DSP任务节点是DSP上单独执行的线程,它实现信号处理算法。任务节点通过固定长度的短消息和与设备无关的流式I/O互相通信或与GPP通信。

3.5 举例说明DSP/BIOS^TM桥的实现过程

　　在这个例子中用DSP进行滤波,GPP应用程序调用API控制DSP上的音频滤波任务。API用来控制DSP，但GPP和DSP之间没有数据流,如图4所示。

　　为初始化DSP上的滤波器任务，GPP应用程序要完成的工作如下：

　　·连接到DSP;

　　·分配滤波器任务节点及ADC和DAC设备节点;

　　·连接节点;

　　·创建DSP上的节点;

　　·启动滤波器节点。

　　为终止DSP上的滤波器应用,GPP应用程序要完成的工作如下：

　　·调DSP节点,终止API发消息到滤波器来终止处理;

　　·删除滤波器节点和ADC， DAC节点;

　　·与DSP分离。

　　作为双核的OMAP^TM平台,其最大的特点是开放性及其软件平台和硬件平台的独立性，同时基于C的ARM和基于XDAIS算法的DSP使OMAP^TM平台易于开发和维护,功能强大且可在线升级。软件平台的核心DSP/BIOS^TM桥并不依赖于固定的操作系统,具有可移植性,允许操作系统的更新。DSP/BIOS^TM桥技术是实现开放的多媒体应用的核心技术。XDAIS兼容算法具有可重入和可重定位特性,因此不仅为算法提供标准的界面,而且具有多通道特性,并能直接在OMAPTM平台上运行,是TI推荐的算法封装方式。目前已经有众多的第三方开发出大量XDAIS兼容算法。OMAP^TM的软件开发集成环境支持多核的CCS2.0 IDE、XDS510及XDS560 仿真器,同时TI还提供OMAP^TM EVM做为评估工具。

参考文献

1 TMS320C5000 DSP/BIOSTM USER GUIDE

2 TMS320C5000 CODE COMPOSER STUDIO

3 OMAPTM 3.1 SPECS

4 DSPBIOS^TM BRIDGE SDK