logo资料库

XDAIS标准,TI-DSP算法标准-中文版.pdf

第1页 / 共21页
第2页 / 共21页
第3页 / 共21页
第4页 / 共21页
第5页 / 共21页
第6页 / 共21页
第7页 / 共21页
第8页 / 共21页
资料共21页,剩余部分请下载后查看
现代软件开发,已从上世纪的面向过程编程发展到当前的面向框架编程。软件开发经验已证明: 框架话、模块化的开发方式可以极大的提高软件开发效率,提高代码质量及代码重用率。然而, 在嵌入式编程中,由于长期缺乏完善的开发框架和可用的 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 为例):
分享到:
收藏