现代软件开发,已从上世纪的面向过程编程发展到当前的面向框架编程。软件开发经验已证明:
框架话、模块化的开发方式可以极大的提高软件开发效率,提高代码质量及代码重用率。然而,
在嵌入式编程中,由于长期缺乏完善的开发框架和可用的 API,开发人员依旧利用 C 或汇编语
言和底层硬件打交道,凡是亲力亲为,这必然会增加嵌入式开发的入门门槛,降低代码的重用
性,甚至增加代码易集时的复制度(不过这些缺点,对于程序员来说确是好事,入门门槛高、
开发复制意味着高付出高回报,不像现在桌面电脑端的开发,已经被人研究烂了,如果你不是
超超超超级大牛,根本找不到一份满意的薪水)。基于这点,TI 公司发布了一套 DSP 算法标
准——TMS320 DSP Algorithm Standard,规范了 DSP 算法软件的开发,并提供了类似 C++
语言类的封装方式的算法接口,使得算法集成变得简单统一。
XDAIS 标准
如果你对 TMS320 DSP Algorithm Standard 还陌生的话,那么如果提起另一个名字:xdais,
那么就顺眼地多了。没错,我们在 Codec Engine 文档中经常看到的 xdais,实际上就是 TMS320
DSP Algorithm Standard 的另一个名字。根据 TI 官方白皮书,xdais 标准一共提供了 39 条规
则,15 条指南。这些规则和指南一共分为 4 个部分:
只要你的算法满足 xdais 标准,你也可以像笔记本上打上的“Vista Capable”那样,在算法上面
打上 TI 的认证图标:
IALG 接口
前面说了,xdais 标准里含有 39 条标准,15 个指南。这些标准、指南几乎涵盖了整个 DSP 开
发的生命周期,例如使用 TI 的 C 语言啊,所有 C6x 算法必须支持低位优先啊。具体的规则可
以参考《TMS320 DSP Algorithm Standard Rules and Guidelines User’s Guide》,本文不再
讨论。
xdais 作为一个 DSP 的开发框架,定义了一些接口:
•
•
•
IALG – 为算法实例对象的创建定义了独立于框架的算法接口。
IDMA2 – 为 C64X 和 C5000 使用统一的 DMA 资源处理方式的定义的算法接口
IDMA3 – 为 C64+和 C5000 使用统一的 DMA 资源处理方式的定义的算法接口
《TMS320 DSP Algorithm Standard API Reference》指出,所有的算法都必须实现了 IALG 接
口,IALG 接口最主要的工作就是定义算法中需要使用的内存,提高片上系统内存使用效率,应
用程序和 xdais 间工作关系如下:
这又遇到了一个问题,xdais 的 API 是基于 C 的,我们知道,C 是面向过程的,因此不存在面
向对象里拥有的封装、继承、重构等特性,那么,我们的应用程序是如何实现接口的呢?对于
这点,xdais 的设计了一个名为 IALG_Fxns 的 v-table:
开发人员只要遵循以上 v-table 定义的函数指针格式,实现自己的函数,就可以了。这些函数的
作用大体上和函数名类似,框架的调用过程如下:
XDM 标准
看到这里,有人要问了,既然 TI 已经有适用于 DSP 开发全过程的 xdais 标准,怎么又弄了个
XDM 标准出来。这里解释一下:我们知道 xdais 几乎涵盖了 dsp 开发的整个生命周期,是一个
非常庞大的东西。如果里面的接口、准则、规定要开发人员一一实现的话,工作量还是很大的。
因此,TI 在 xdais 上又扩展了一个 XDM 标准,用来为数字信号处理提供一个轻量级的框架,
总体上说,就是在 XDAIS 的基础上扩展了一个名为 Digital Media 的接口(xDM),然后根据
数字图像处理的要求,提供了一个名为 VISA 的 API 集合,其底层远离,用的还是 xdais 的东
西。
这样下来,应用层需和 XDM 标准打交道就变成以下形式了:
xDM 接口实际上扩展了 IALG 接口,在其上增加了 process 和 control 方法,例如 VISA API 中
的 IVIDENC1 接口的 v-table 定义如下:
而 xDM 的调用过程就变为:
VISA API
TI 扩展 xDM 的目的,是为了为数字图像处理提供一个轻型的框架,为此,TI 根据数字图像处
理的分类,封装了一套名为 VISA 的 API 集合(这里的 VISA,不是信用卡 VISA,而是 Video、
Image、Speech 和 Audio 的简称,想出这个名字的人太有才了),基本覆盖了数字信号处理的
所有需求:
•
•
•
•
•
•
•
•
IVIDENCx :Generic interface for video encoders
IVIDDECx :Generic interface for video decoders
IAUDENCx :Generic interface for audio encoders
IAUDDECx :Generic interface for audio decoders
ISPHENCx :Generic interface for speech encoders
ISPHDECx :Generic interface for speech decoders
IIMGENCx :Generic interface for image encoders
IIMGENCx :Generic interface for image decoders
在 Codec Engine 的 Algorithm Create 过程中,开发一个算法程序往往是从实现这些接口开始,
例如,我们要做一个 H264 的编码算法,需要从实现 IVIDENCx 开始。
这样的,我们在 Codec Engine 的开发领域里,DSP 端开发流程如下:
•
http://gs5689.blogbus.com/logs/34197152.html
德州仪器(TI)的达芬奇(DaVinci)数字媒体技术平台包括四大部分:芯片(处理器)、开发工具或开
发套件、软件及技术支持。其中软件开发涉及到操作系统、音视频编解码算法及 ARM 和 DSP 之间的分
工协作,让很多工程师感到比较复杂。
为此 TI 推出了一系列软件模块和工具来建立 Davinci 软件开发的框架,方便工程师在此基础
上快速的开发自己的产品。这些软件模块和工具包含在 TI 的基于达芬奇技术的数字视频评估板的软件
开发包中。
一般的视频应用系统中,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 为例):