如何构建达芬奇的DSP+Server

《如何构建达芬奇的DSP+Server》由会员分享，可在线阅读，更多相关《如何构建达芬奇的DSP+Server（14页珍藏版）》请在金锄头文库上搜索。

1、如何构建达芬奇的如何构建达芬奇的 DSP Server 德州仪器德州仪器(TI)的达芬奇的达芬奇(DaVinci)数字媒体技术平台包括四大部分：芯片数字媒体技术平台包括四大部分：芯片(处理器处理器)、开发工具或开、开发工具或开 发套件、软件及技术支持。其中软件开发涉及到操作系统、音视频编解码算法及发套件、软件及技术支持。其中软件开发涉及到操作系统、音视频编解码算法及 ARM 和和 DSP 之间的分之间的分 工协作，让很多工程师感到比较复杂。工协作，让很多工程师感到比较复杂。 为此 TI 推出了一系列软件模块和工具来建立 Davinci 软件开发的框架，方便工程师在此基础上快速 的开发自己的产品

2、。这些软件模块和工具包含在 TI 的基于达芬奇技术的数字视频评估板的软件开发包中。 一般的视频应用系统中，Davinci 的 ARM 负责操作系统应用，DSP 负责运行音视频 codec 算法处 理，ARM 通过 TI 的 Codec Engine 机制调用 DSP 侧的 codec。那么怎样把不同的 codec 算法集成到一 个 DSP 可执行程序(称为 DSP Server)中，又保证它们占用的资源不冲突？本文从 Davinci 软件结构入 手，介绍如何构建 DSP Server，及如何通过 DSP Server 的配置文件配置 FC(Framework Compone nt)，以便通过

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

4、(Video, Image, Speech, Audio)API 来调用 DSP 侧的 算法，通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设。这三个部 分通常对应三个 Davinci 软件开发小组。 当然还需要一个系统集成工程师把这三 个部分集成起来， 不过 V ISA API 和 EPSI API 的存在已经大大简化了集成工作的复杂程度。 如图 2 所示，DaVinci 的软件开发通常需要四个步骤(本文以 codec 运行在 DSP 为例)： 图 2：软件系统分为应用层、信号处理层和 I/O 层三部分，达芬奇

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

6、请参考 spraae7.pdf)。 第二步，生成一个在 DSP 上运行的可执行程序*.x64P(即.out 文件)，也就是 DSP Server。本文 将详细介绍这一步。 第三步， 根据 DSP Server 的名字及其中包含的具体的音视频编解码算法创建 Codec Engine 的配 置文件*.cfg。这个文件定义 Engine 的不同配置，包括 Engine 的名字、每个 Engine 里包括的 codecs 及每个 codec 运行在 ARM 还是 DSP 侧等等(具体说明，请参考 sprue67.pdf 的第 5 章 Integrating a n Engine)。 最后，应用工程师收

7、到不同的 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 为算法 的执行提供了一个

8、标准的软件架构和接口，体现在以下几个方面： 1. 通过 Codec Engine API 调用的算法可以运行在本地(ARM 侧)或者远端(DSP 侧)； 2. Codec Engine 可以基于 ARMDSP、DSP 或 ARM 上运行； 3. 无论 Codec Engine 运行在 ARM 还是 DSP 上，对应的 Codec Engine API 都是完全一致的； 4. Codec Engine 的 API 与操作系统无关。比如 Linux、VxWorks 和 WinCE 环境下的 Codec E ngine API 都是完全一致的。 Codec Engine 是介于应用程序和具体算法之间

9、的软件模块，其中的 VISA API 通过 stub 和 skel eton 访问 Engine SPI 最终调用具体的算法。因此，Codec Engine 的工作是通过完成 VISA API 的任 务来体现的。VISA API 分为四部分 VISA create/control/process/delete，我们以 codec 算法运行在 DSP 为例，通过 VISA API 的执行过程了解 Codec Engine 的工作原理。 在调用 VISA API 之前需要在应用程序中通过 Engine_open()这个 Engine API 把 DSP 的可执行 程序加载到 DSP 的 memor

10、y，同时把 DSP 从复位状态释放，这时 DSP 开始运行 DSP Server 的初始化 程序在 DSP 侧创建一个优先级最低的任务 RMS(Remote Management Server)，RMS 负责管理和维 护对应到具体 codec 算法的 Instances。如图 3 所示，应用程序调用 VISA create API，相应的 VISA create 函数到 Engine SPI 中的 Codec table 中查到这个 codec 运行在远端 DSP 侧。 接着 Engine SPI 通过 OSAL(Operating System Abstraction Layer)、DSP

11、Link 把 VISA cr eate 的命令传到 DSP 侧的 RMS。RMS 通过 DSP 侧 Engine SPI 的 codec table 找到要调用的 codec 算法后，就会在 RMS 中创建一个相应的 Instance(即一个 DSP/BIOS 系统中的任务)。VISA create 会 返回一个 Instance 的 Handle，以便于给这个 Instance 做后续的 VISA control/process/delete 提供 信息。VISA delete 和 VISA create 原理类似，只是 RMS 删除掉相应的 codec 算法的 Instance 和执 行

12、codec 算法的任务。 图 3：VISA create/delete 流程说明图。 概括来说，VISA control 用来动态的修改 codec instance 的属性，VISA process 用来对算法的 输入数据流做处理并返回一个输出数据流。如图 4 所示，应用程序在调用 VISA process/control 时会通 过 xDM Stub 把传递给 codec 算法的参数收集起来，并且转换成 DSP 可以识别的物理地址。Stub 把这 些参数和相关的命令通过 Engine SPI、 OSAL 和 DSP Link 传递到 DSP 侧的 Instance。 Instance 再通

13、 过 Skeleton 把传递过来的参数和命令解析出来，通过 DSP 侧 VISA control/process 对 codec 算法执 行 control/process。 对 Codec Engine 有了基本工作原理的了解之后， 我们就会更清楚的理解 DSP 的软件怎样配合应用 程序工作及 DSP Server 中除算法之外还应该包括哪些内容。 创建创建 DSP Server 对达芬奇的软件来说，DSP Server 也叫 Codec Server。其中“codec”是一组算法。从图 3 和 4 可以看到，除算法之外，DSP Server 还集成了其他的软件模块(如 DSP/BIOS、

14、DSP Link、Codec En gine 等)。 1. xDC 简介 达芬奇的软件开发环境中， 有一个 DSP 工程师比较陌生的工具 xDC(Express DSP Component)。 和 gmake 类似，xDC 根据一套 build 指令 build 生成可执行文件。xDC 同时也会 build 依赖文件，并且 可以一次 build 多个目标对象的可执行文件(如图 5 中的 hello.x64P 是 DSP 的可执行文件，hello.x470 MV 是 ARM 的可执行文件)。xDC 的 源文件可以是 C 程序、C+程序、汇编程序和库文件等。 如图 5 所示，xDC 按照 buil

15、d 指令，对 DSP Server 的源文件进行 build(类似于 make)生成 DSP Server .x64P 文件。这个过程可以分为三部分：创建 DSP Server 的源文件；设置 xDC 的配置文件； 执行“make”生成可执行文件。 图 5：xDC 按照构建指令，对 DSP Server 的源文件进行构建生成 DSP Server .x64P 文件。 图 5：xDC 按照构建指令，对 DSP Server 的源文件进行构建生成 DSP Server .x64P 文件。 2. DSP Server 的源文件 以 Codec Engine_1_02 中的 video_copy 为例

16、，如图 6 我们可以看到 video_copy 的 DSP Ser ver 中包括和图 5 对应的源文件 main.c、video_copy.tcf 和 link.cmd。图 5 中的 packages 是指图 3 和图 4 中的 codecs、RMS、Engine SPI 和 OSAL。接下来，我们可以通过 xDC 的配置文件看到如何把 packages 添加到 Server 中。 要构建 DSP Server 首先就需要创建 main.c 和 server 的 DSP BIOS 配置文件.tcf 及 link.cmd。 我们提到 engine_open 会把 DSP 从复位状态释放， DSP Server 程序开始运行初始化等等。 这个初始化 就是 DSP Server main.c(见图 7)中的 CERuntime_init()。除此之外在 main.c 中还可以打开 Codec Engine 的 trace 功能，读取或更改 main 函数的参数等。 DSP BIOS 的配置文件.tcf 中定义 DSP 的 memory map、 设置 DSP 的复位/中断向量表