现代软件开发，已从上世纪的面向过程编程发展到当前的面向框架编程。软件开发经验已证明：框架话、模块化的开发方式可以极大的提高软件开发效率，提高代码质量及代码重用率。然而，在嵌入式编程中，由于长期缺乏完善的开发框架和可用的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个部分：
IALG接口
前面说了，xdais标准里含有39条标准，15个指南。这些标准、指南几乎涵盖了整个DSP开发的生命周期，例如使用TI的C语言啊，所有C6x算法必须支持低位优先啊。具体的规则可以参考《TMS320 DSP Algorithm Standard Rules and Guidelines User’s Guide》，本文不再讨论。
xdais作为一个DSP的开发框架，定义了一些接口：
IALG
IDMA2
IDMA3
《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的简称，想出这个名字的人太有才了），基本覆盖了数字信号处理的所有需求：
在Codec Engine的Algorithm Create过程中，开发一个算法程序往往是从实现这些接口开始，例如，我们要做一个H264的编码算法，需要从实现IVIDENCx开始。
这样的，我们在Codec Engine的开发领域里，DSP端开发流程如下：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
