DM6467 Codec Engine执行流程 .

1、达芬奇技术是ti提供的一套系统解决方案或者说是技术体系，再具体的请Google
2、达芬奇技术体系中引入了Codec Engine，并创建了一整套的应用开发平台。为通用处理器（GPP）上的开发者提供更为简单的开发环境。
3、Codec Engine是一系列用于表示和运行数字多媒体标准化DSP算法接口(XDAIS)及算法的API。XDAIS定义了一整套的多媒体算法编程接口，可单独在GPP或DSP上运行，也可在DSP上运行，而GPP通过Codec Engine对其实行控制。对于所有支持的运算器结构、运行方式及操作系统，Codec Engine都有相同的API。Codec Engine定义了4类编解码器算法接口标准，分别是视频、图像、语音、音频，简称VISA。
4、Codec Engine在解决达芬奇双处理器架构问题时首先引入了远程过程控制(RPC)的概念。RPC是指在另一个处理器上远程执行一个命令或过程。RPC有客户端和服务端，客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令，服务端执行命令并通过相应的通信方式将结果返回给客户端。
5、达芬奇DM6446（DM6467）芯片将ARM作为客户端、DSP作为服务端，两者之间的物理链路就是两个处理器之间共享的DDR2存储器，而将物理链路上的通信协议称为DSPLink。

 

Ti的DaVinci架构为嵌入式程序的开发提供了很好的框架，对于DM6467，一个项目的开发可以分为Codec Engine Application Developer、Codec Engine Server Integrator 、Codec Engine Algorithm Creator三个角色，但是不论是哪一个角色，都应该了解三者直接如何共同合作。
应用程序运行在GPP端，算法运行在DSP端，APP通过一些接口函数控制dsp端创建或者执行算法，并取得结果，交互过程如下（翻译加个人理解）：
1、CERuntime_init();初始化所有的框架环境
2、GPP端通过VISA create API（xxx_create）在DSP端创建算法实例（个人理解为一个线程）
   （1）GPP端创建通用的接口对象（包括句柄、必要的参数、指针等）
   （2）GPP端创建一个"node"对象，负责沟通DSP端"node"
   （3）GPP端形成一条create信号，DSP端接收后创建DSP端的"node"（此node是由DSP端负责功能调度的一个线程创建的）    ------貌似这样链路就通了
   （4）DSP端继续解析create信号，经过错误校验等，创建并初始化一个状态对象   -------这个对象估计就是记录了此解码器的状态与参数
   （5）此时会创建一个消息队列，负责GPP端命令接收   -------每一个解码器有自己的队列
   （6）DSP端特定的"create"函数会被调用，初始化node状态、内存资源等    -------此函数也是有DSP端负责功能调度的线程创建
   （7）到此一个单独专用的解码线程被创建，但此时他是挂起状态的
   （8）调度线程保存新创建线程的状态信息，并发送一个状态恢复信息到GPP
   （9）GPP端收到成功信息，更新相关结构体
   （10）GPP端会生成一条start命令，DSP端调度线程会使解码算法线程由挂起转至运行，此时算法线程会执行"execute"函数，但此函数为阻塞函数，在等待GPP命令
3、GPP端调用VISA process(xxx_procese)：
   （1）GPP端执行基本的参数校验
   （2）一条消息结构体被创建（DSP端需要的所有参数）
   （3）该消息发送到DSP端的消息队列
   （4）DSP端收到消息，调用算法框架
   （5）框架分析参数，同步cache和内存里面的数据，并激活
   （6）调用编解码函数
   （7）等待cache里面的数据进入非活跃
   （8）框架将数据写回外寸（其实就是内存）
   （9）回复执行状态消息，等待下一条命令
   （10）GPP端分析outArgs，取到执行结果
到此解码完成。
4、另外对于删除一个解码算法实例 VISA delete（xxx_delete）：
   （1）GPP发送消息通知exit
   （2）DSP收到exit回复应答
   （3）GPP发送"delete"消息
   （4）DSP调度线程删除编码算法线程
   （5）调用对应算法里面的delete函数   ------此函数调用也是由调度线程完成的
   （6）DSP端的"node"接口被删除，消息队列也被删除，回复GPP
   （7）GPP端"node"接口也被删除，消息队列关闭，更新相关参数