一般的视频应用系统中，Davinci的ARM负责操作系统应用，DSP负责运行音视频codec算法处理，ARM通过TI的Codec Engine机制调用DSP侧的codec。那么怎样把不同的codec算法集成到一个DSP可执行程序(称为DSP Server)中，又保证它们占用的资源不冲突？本文从Davinci软件结构入手，介绍如何构建DSP Server，及如何通过DSP Server的配置文件配置FC(Framework Component)，以便通过FC管理DSP的资源。

达芬奇DMSoC软件概述

一般来讲，软件系统分为应用层、信号处理层和I/O层三部分，TI提供的达芬奇参考软件框架就是基于这样的结构，如图1所示。Davinci的应用工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色。信号处理层通常都运行在DSP一侧负责信号处理，包括音视频编解码算法、Codec Engine、DSP的实时操作系统DSP/BIOS及和ARM通信的模块。I/O层就是我们通常所说的驱动，是针对Davinci外设模块的驱动程序。

其中应用层通过Codec Engine的VISA(Video, Image, Speech, Audio)API来调用DSP侧的算法，通过EPSI(Easy Peripheral Software Interface)API来访问和操作Davinci的外设。这三个部分通常对应三个Davinci软件开发小组。当然还需要一个系统集成工程师把这三个部分集成起来，不过VISA API和EPSI API的存在已经大大简化了集成工作的复杂程度。

如图2所示，DaVinci的软件开发通常需要四个步骤(本文以codec运行在DSP为例)：

图2：软件系统分为应用层、信号处理层和I/O层三部分，达芬奇软件开发通常需要以上四个步骤。

第一步，工程师需要基于DSP利用CCS开发自己的音视频编解码算法，编译生成一个编解码算法的库文件*.lib(等同于Linux环境下的*.a64P，直接在Linux环境下修改文件后缀名即可)。如果要通过Codec Engine调用这个库文件中的算法函数，那么这些算法实现需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)标准；Codec Engine机制下不符合xDM标准的算法实现需要创建算法自己的Stub和Skeleton(具体请参考spraae7.pdf)。

第二步，生成一个在DSP上运行的可执行程序*.x64P(即.out文件)，也就是DSP Server。本文将详细介绍这一步。

第三步，根据DSP Server的名字及其中包含的具体的音视频编解码算法创建Codec Engine的配置文件*.cfg。这个文件定义Engine的不同配置，包括Engine的名字、每个Engine里包括的codecs及每个codec运行在ARM还是DSP侧等等(具体说明，请参考sprue67.pdf的第5章Integrating an Engine)。

最后，应用工程师收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的应用程序通过编译、链接，最终生成ARM侧可执行文件。

Codec Engine概述

前面我们提到，应用工程师通过调用Codec Engine的API来调用和运行符合xDAIS的算法(关于API的具体信息，请参考sprue67.pdf第4章)。在Davinci软件中，符合xDAIS的音视频编解码算法(即xDM算法)的调用是通过Codec Engine的VISA API完成的。Codec Engine通过这套API为算法的执行提供了一个标准的软件架构和接口，体现在以下几个方面：

1. 通过Codec Engine API调用的算法可以运行在本地(ARM侧)或者远端(DSP侧)；

2. Codec Engine可以基于ARM＋DSP、DSP或ARM上运行；

3. 无论Codec Engine运行在ARM还是DSP上，对应的Codec Engine API都是完全一致的；

4. Codec Engine的API与操作系统无关。比如Linux、VxWorks和WinCE环境下的Codec Engine API都是完全一致的。

[1] [2] [3]  下一页