来源:
http://www.usr.cc/thread-52031-1-3.html
http://www.usr.cc/thread-52036-1-3.html
1.codec engine example各文件夹解析
codec endine中给的例子codec中有很多个文件夹，初学者并不了解这些文件夹之间的关系，这里说明一下。给的例子中有三个版本的xDM，和non-xDM，分别包含的文件夹如下：
? xDM 0.9:
? apps (all kinds -- Arm client-only, Arm local, DSP local):
? audio_copy, image_copy, speech_copy, video_copy
? DSP servers:
? video_copy, all_codecs (includes xDM 0.9, xDM 1.0, and xDM 1.2 codecs)
?xDM1.0 apps:
? audio1_copy, audio1_ires, image1_copy, speech1_copy, video1_copy
? DSP servers:
? all_codecs (includes xDM 0.9, xDM 1.0, and xDM 1.2 codecs)
? xDM 1.2:
? apps:
? video2_copy (uses xDM 1.0 VIDENC1 and xDM 1.2 VIDDEC2), video2split_copy
? DSP servers:
? all_codecs (includes xDM 0.9, xDM 1.0, and xDM 1.2 codecs)
? non-XDM:
? apps/scale - The test app
? servers/all_codecs - A server with the scale alg built into it
? extensions/scale - The API, stub and skeleton support
? codecs/scale - The proprietary alg and interface spec
这些example运用makefile文件来控制编译，只有在运行“configuration”这步的时候采用XDC tools（“Configuro” XDC tool 生存.obj文件和linker file）
? ARM client apps:
? video_copy/configuro/*
这些example编译成一个DLL（动态链接库），它封装了codec engine，用户终端程序不需要运行XDC tool就可以调用该DLL。
? ARM client apps:
? video_copy/dualcpu_separateconfig
? video_copy/dualcpu_separateconfig_dll
异步VISA调用
那些只有arm客户端的example运用一对异步 _processStart()/_processWait()来保持运行，在远端的DSP 编码运行他们的要求时。
? ARM client apps
? audio1_copy/async
server_api_example显示了怎么运用Servers APIs 去重新定义DSP上的栈大小。
ti.sdo.ce.osal:是codec engine 的OS抽象层，它使codec engine在运行时与OS隔离开，只留下一些模块供用户使用。
2.codec engine example包中各文件解析
config.bld:
用于定义该example XDC将要编译的targets和环境变量。它设置的是默认的targets和platform，然后通过user.bld进行修改。
注意：该文件一般不需要改动，但要和user.bld保持一致。
该文件在XDC进行编译时控制编译器的选择（ARM或DSP），它只作用于由package.bld XDC 编译出来的二进制文件。XDC 通过该文件找到package的路径，然后找到有更多选项的user.bld文件。
该脚本文件比其他文件最先受到编译。它为目标文件和平台设置了独立的主机系统参数，然后它试图找到设置rootDir的user.bld。
主要内容：DSP target Linux host target Arm target 等的设置 load user.bld。
user.bld:
必须修改该文件以设置编译工具的路径
该文件列出了为了哪个目标去编译二进制和程序，每个目标所需要的编译器的位置，和为了哪个平台而编译的程序。你必须详细设置编译工具，并将不需要编译的平台注释掉。
例如：如果你只是对编译evmDm6446上Montavista Arm Linux 下Arm侧的程序，只要将第一个arm下的doBuild设为true，其他设为false。然后详细设置Montavista Arm tools的路径，并注释掉除dm6446之外的平台。
下面列出的是codec中的文件夹，以viddec_copy为例：
package.bld:
当包制造者编译该包的时候，执行package.bld文件。生成的tar文件包含包（包含识别该包的RTSC tools所要求的文件）生成的二进制文件。它还包含一些附加的文件。
在包编译时所需要的源文件和头文件都不包含在发行包中，除非你特别用Pkg.otherFiles加上它们。
例如：Pkg.otherFiles = [
'src', /* the whole src subdirectory */
'include', /* the whole include subdirectory */
'readme.txt',
];
这样这些文件会被发行。
如果你想包含库文件，该库文件是编译外面的包所需要的legacy 编译系统，你可以将库文件加在Pkg.otherFiles中。
Pkg.otherFiles = [
'legacy.lib',
'readme.txt',
];
如果你想改变你的cedec中的源文件：var SRCS = ["viddec_copy.c", "other source file", ...];
你也需要改变下面这行来引用你的codec库文件：Pkg.addLibrary("lib/viddec_copy", targ).addObjects(SRCS);
该文件中的target（x86 linux，c64P，arm9）来自config.bld。你可以通过修改user.bld来增加你的target.
package.xdc
该codec说明了Codec Engine最简单的融合。只要求三个文件：
package.xdc：该文件要求声明该包的名字和列出所有可用的接口。
MODULE.xdc:该文件具体说明了该包所提供的codec
MODULE.XS:该文件实现了由ICodec接口要求的函数，这些函数允许codec描述它的非功能性的请求，比如堆大小。
这个包中的其他文件仅仅实现了xDM具体要求的codec。因此将他们整合到codec engine中不需要改变codecs sources。
该文件定义了包的静态变量如它的名字和一些依赖关系。
比如viddec_copy中的package.xdc提到了它所依赖的xDM的VISA API接口：
requires ti.sdo.ce.video;
然后用下面的声明详细说了这个包所名字是ti.sdo.ce.examples.codecs.viddec_copy 和这个包所包含的单个模块叫VIDDEC_COPY
package ti.sdo.ce.examples.codecs.viddec_copy {
module VIDDEC_COPY;
}
package.xs:
该文件详细说明的包的性质，可以通过平台和配置来改变。如默认的VIDDEC_COPY的package.xs中设置的库名字是这样的：
function getLibs(prog)
{
/* "mangle" program build attrs to directory name */
var name = "lib/viddec_copy.a" + prog.build.target.suffix;
if (prog.build.target.isa == "64P") {
/* return the library name: name.a<arch> */
print(" will link with " + this.$name + ":" + name);
}
else {
name = "";
}
return (name);
}
该函数返回一个package导入的库文件名字。当XDC应用程序用到这个包时，XDC编译系统就调用这个特殊的函数以链接程序配置的包文件系统。导入的库文件不是用housing pakage的编译脚本编译。
上面的函数只有在为DSP server 或只是DSP编译时才返回库文件的名字，如果你编译ARM应用程序不会返回库文件。这就是用这句的所在。
if (prog.build.target.isa == "64P")
如果example codecs包含的库文件是为DSP和ARM一起使用的话，则不需要if语句。dm6446上的例子就是这样的，没有if语句。
VIDDEC_COPY.xdc:
你可以重新命名VIDDEC_COPY.xdc以匹配在package.xdc中用的模块。该文件声明了这个模块是一个可以嵌入codec engine server的codec。因此它详细说明了codec的名字，类型和一些你想定义的额外参数。
该文件详细说明了和codec engine整合所必须的信息。通过继承ti.sdo.ce.video.IVIDDEC,VIDDEC_COPY声明它只是一个video 解码算法。这允许codec engine 自动的为GPP透明的运行DSP提供简单的stubs 和skeletons。
metaonly module VIDDEC_COPY inherits ti.sdo.ce.video.IVIDDEC
除了声明了VIDDEC_COPY算法的类型外，还声明了由xDAIS要求的标志算法实现功能的额外的符号。
/*!
* ======== ialgFxns ========
* name of this algorithm's xDAIS alg fxn table
*/
override readonly config String ialgFxns =
"VIDDECCOPY_TI_VIDDECCOPY";
如果codec需要使用DMA，你应该在该文件中详细说明idma3Fxns vtable symbol的名字。
VIDDEC_COPY.xs:
你可以重新命名VIDDEC_COPY.xdc以匹配在package.xdc中用的模块。该文件应该包含在VIDDEC_COPY.xdc中声明的任何方法的实现。这样分析看来，.xs文件对应.xdc文件就像.c文件对应.h文件一样。
该文件实现了ti.sdo.ce.ICodec接口.这些函数允许配置工具验证用户提供的配置参数。（例如：运行该codec的进程所需要的stack大小）
function getStackSize(prog)
{
if (verbose) {
print("getting stack size for " + this.$name
+ " built for the target " + prog.build.target.$name
+ ", running on platform " + prog.platformName);
}
return (1024);
}
包含：getStackSize ，getDaramScratchSize， getSaramScratchSize