http://www.usr.cc/forum.php/static/image/smiley/tiger/archiver/forum.php?mod=viewthread&action=printable&tid=51827

本文将达芬奇开发分为四个角色的工作，实则也就是达芬奇DSP开发的四个步骤，本文讲述这四个步骤都是什么，下面的链接则详细讲述四个角色的工作：
算法工程师，算法的移植或研发
服务器集成工程师，生成算法服务器
引擎集成工程师，配置引擎
应用程序作者，写应用程序
题外话：上面的四个步聊并非要次第进行，但层次关系却是递进的。

[i]正文：
codec engine:编解码引擎

从应用程序的开发者角度看来：
codec engine引擎就是一组API（应用程序编程接口），你可以用它来实例化并运行一个符合xDAIS标准的算法。
这个API对于以下的所有情况来说没有区别：

• 算法运行在通用处理器上（如ARM）还是运行在远端处理器（如DSP）上没有区别。
• 系统可以是GPP＋DSP（如ARM＋DSP），也可以是单核DSP，还可以是单核通用处理器(如ARM）,没有区别。
• 所有支持的GPP和DSP使用的API都是相同的。
• 所有支持的系统所用的API也是相同的，这些系统包括linux ,pros,vxworks,dsp/bios,wince.

对于xDAIS编程标准，还有一个与其伴生的标准，叫做xDM. xDAIS即eXpressDSP Algorithm Interface Standard,叫做快速DSP算法接口标准。xDM实际上是xDAIS for Digital Media. 意思是专用于数字媒体的xDAIS标准。全部的简称应该叫xDAIS-DM.它是对xDAIS的一个扩展，这个扩展定义了针对视频，图像，语音，音频的编解码器制定了“类”。

作者: chinablue    时间: 2011-8-21 13:57
上文最后一句话出现了“类“这个词，为什么会出现这个词呢？
因为xDM为数字媒体定义的API是以“类”的方式定义的。xDM接口将编解码算法分成四个类：视频、图像、语音、音频。这四个类的英文首字母分别为V,I,S,A所以这个扩展接口又称为VISA接口，VISA API。每一个类就对应一组API。在这种情况下，MP3与WMA两种音频的编解码进行替换时就不需要改变应用的源代码，只要改变一下配置就可以了。

codec engine引擎也提供了一组API，用来访问内存，CPU使用率统计数据，运行跟踪信息等。
codec engine引擎的运行时程序是以二进制的形式提供的，因此使用同一个codec engine创建的应用库通常都是互相兼容的。

作者: chinablue    时间: 2011-8-21 14:45
标题: 达芬奇:codec engine用法
本帖最后由 chinablue 于 2011-8-21 14:47 编辑 

codec engine怎么用呢？
codec engine是为了解决如下问题而设计的：

• 多处理器环境下的调试，这种情况下的调试是相当让人头疼的，要用到多个调试器，引导程序也很复杂。
• 处理同一算法的不同实现问题。如MP3，它有多个API，想改用另一个算法实现的话，要做大量的代码重写。
• 在有两个处理器的情况下，移植时，问题就混合在一起了。你不但要移植DSP代码，也要移植ARM代码。
• 多数应该都要求能支持多种解码器。
• 通用处理器的开发工程师开发时要再去弄明白DSP的内存管理和实时问题费时费力。

codec engine 引擎可以解决以上问题，它提供了一个标准的软件架构和算法执行接口。codec engine有如下优点：

• 简单易用。应用程序开发者不需要关心哪一个算法需要运行，也不用管他们怎么运行 ，在哪儿运行。
• 可扩展可配置。使用标准的工具和技术，新的算法可以随时加进去。
• 可移植。这套API不依赖于目标板、平台而有区别，甚至与编解码器也无关。

它怎么用呢？
应用程序的代码（或者它所使用的中间件代码）调用codec engine的API。在codec engine内部，VISA 各个API使用一些stub和一些skeleton来访问引擎核心及实际的编解码器，编解码器可以在当前的处理器上，也可以在另一个处理器上运行。

整个流程可以用一幅图来表示（http://qpic.cn/lCYibORh2），应用程序（或中间件）调用引擎核心的API们和VISA的API们。 VISA使用stub们来访问引擎核心的SPI们和Skeleton们，SPI即System Programming Interfaces, 系统编程接口。skeleton意为骨架。 VISA的SPI们则访问下层的算法。
有一个针对于双核处理器GPP＋DSP（GPP＝ARM等）的改过后的图（http://qpic.cn/0pB9vfgaT）其中黄色的部分代表代码在GPP上运行，灰色的部分代表代码在DSP上运行。在这幅图上，整体分为三部分。虚线框起来的是一部分，上下还各有一部分。上面的代码应用程序和中间件，中间的叫做codec engine runtime.下面的是编解码器算法。可以看到，应用程序和中间件是绝对跑在GPP上的，算法是绝对跑在DSP上的。而codec runtime则跑在两个处理器上都有。对于codec engine runtime而言，它由三部分组成：core engine runtime、 stub们和skeleton们。stub是codec engine runtime为应层留出的接口。skeleton是codec engine runtime为算法留出的接口。所以stubs都是跑在GPP上的,skeleton都是跑在DSP上的。而core engine runtime则是两者都有，属于居中策应的。

作者: chinablue    时间: 2011-8-21 15:35
codec engine的用户可能各自情况不同，导致看待问题的方式也不同，比如说一个比较了解工ARM而对DSP不是很了解的人与相反情况的人看待codec engine的方式就会不一样，为了便于理解，codec engine的文档将开发者分为不同的角色，这些角色并不一定是不定非要有那么几组人，有时候也可能所有的角色都有一个人来充当。
这几个角色是：

• algorithm creator,算法工程师；
• server intergrator,服务器集成工程师；
• engine integrator,引引擎集成工程师；
• application Author,应用开发工程师；

算法工程师：
算法工程师主要创建符合xDAIS标准的算法，并将其封状成包(package)，这样的算法支持远端执行时无需附加支持。而如果算法不符合标准，则支持远端执行时就要附加提供codec engine skeleton和stub们。
做为一个算法工程师，他要用到的工具是xDAIS和XDC工具，XDC工具包含配置组件。算法工程师使用这些工具创建一个编解码算法库（codec library),这个库要导出iAlg接口符号,也可以进一步导出iDMA3接口符号，前者必选，后者可选。他还要实现ti.sdo,ce,ICodec接口，并引用编解码算法库的导出符号。算法工程师将一个发行版的算法编解码器包交给服务器集成工程师，这个包通过包含多个库(libraries)以及XDC包标签数据（metadata)。
算法工程师手中应该有的资源如下：

• Codec Engine Algorithm Creator User‘s Guide(SPRUED6)
• xDAIS-DM(Digital Media) User Guide(SPRUEC8)
• xDM API Reference. XDAIS_INSTALL_DIR/docs/html/index.html
• TMS320 DSP Algorithm Standard Rules and Guidelines(SPRU352)
• TMS320 DSP Algorithm Standard API Reference(SPRU360)
• TMS320 DSP Algorithm Standard Developer‘s Guide(SPRU424)
• Example codecs(算法例程).

服务器集成工程师：
系统集成工程师为引擎提供远程算法支持，他要创建一个算法服务器。算法服务器包含各种组件，这些组件与算法一起打包。所需组件包括DSP/BIOS, Framework components, link drivers, codecs, codec engine等，并最终生成一个可执行文件。
算法集成有两处需要配置，一个是DSP/BIOS（通过Tconf脚本配置),另一个配置称为“其余”，即对其余组件如Framework Components,  Link,  Codec Engine等通过XDC配置。

服务器集成工程师从算法工程师那里得到各种算法，然后用codec engine和其依赖的DSP/BIOS,DSKT2等，通过XDC工具创建如下文件：

• 服务器配置文件(.cfg)
• DSP/BIOS 配置文件
• 一个简单的main()函数，只要做一些初始化就可以
• 执行配置文件会编译出一个输出文件，这是一个DSP可执行文件，也就是所谓的codec server,即算法服务器。

服务器集成工程师需要如下资源：

• 你当前看到这个帖子所用的手册（codec engine server integrator user‘s guide)
• 配置参考：CE_INSTALL_DIR/packages/xdoc/index.html
• codec server例程

对于单核系统，codec server不需要，也就不需要这个角色。

作者: chinablue    时间: 2011-8-21 16:20
引擎集成工程师：
他要定义各种引擎配置，包括引擎的名字，引擎中的算法及算法在引擎中的名字，一个算法是远程执行还是本地执行（即工作在另一个处理器上，还是与应用在同一处理器上），算法要集成在哪个包里（针对支持资源共享的环境），算法服务器的名字等，这些都是通过XDC配置脚本(.cfg)文件来做的。这个脚本在执行的时候，会生成代码和编译指令。
引擎集成工程师从算法集成工程师手里得到算法服务器的名字，和它所包含的算法。然后，他用这些东西创建 一个引擎配置脚本(.cfg文件),脚本可以引脚一个算法服务器。（这些对单核系统没有意义，因为单核系统不用算法服务器。)

引擎集成工程师将配置文件交给应用程序作者。

引擎集成工程师使用如下资源：

• Codec Engine Application Developer‘s Guide(SPRUE67)的第五章。
• 配置参考：CE_INSTALL_DIR/packages/xdoc/index.html
• 编译和执行指令示例：CE＿INSTALL＿DIR/examples/build_instructions.html
• 配置脚本示例

应用程序作者：
应用使用codec engine的API们（引擎API，VISA API，其他API）来创建/删除预配置的引擎实例，创建/删除算法，与算法交互，为算法申请合适的缓冲区。
由于codec engine不进行IO操作，应用要处理I/O操作，这包括文件的访问（open/read/write/seek/close)和与驱动的交互(open/close/ioctl及缓冲管理）。

应用程序作者负责创建代码，并将“合适的内容”链入可执行文件。

应用作者需要：

• 从算法工程师那里得到算法包
• 从服务器集成工程师那里获得算法服务器的DSP可执行文件（如果算法在DSP上跑的话）
• 从引擎集成工程师那里得到引擎配置文件.cfg

应用程序作者(1)写应用代码，(2)使用XDC工具从引擎配置文件生成.c和.xdl输出文件，(3)编译应用程序，生成文件，(4)把所有的文件（包括生成的链接命令文件.xdl)链接成最终的应用可执行文件。
生成应用可执行文件的过程高度依赖于应用运行的操作系统。比如说应用运行于DSP上的DSP/BIOS系统中，就需要一个.tcf文件来配置DSP/BIOS内核，如果应用跑在linux上面，则无需配置。

应用程序作者需要的资源有：

• Codec Engine Application Developer‘s Guide(SPRUE67)
• Codec Engine API Reference: CE_INSTALL_DIR/docs/html/index.html
• 例程编译运行指导:CE_INSTALL_DIR/examples/build_instructions.html

更多信息：
Codec Engine安装目录下的release_notes.html提供了一些总体的信息，关于最近版本的变化，支持和更新的设备，已知问题和在线文档的链接。在线文档如下：
Codec Engine API Reference:  CE_INSTALL_DIR/docs/html/index.html
Configuration Reference: CE_INSTALL_DIR/packages/xdoc/index.html
Example Build and Run Instructions: CE_INSTALL_DIR/examples/build_instructions.html
关于xDM的信息，请看：xDAIS-DM(Diguital Media) User Guide(SPRUEC8)

davinci入门必读