《达芬奇软件架构及开发流程重要.ppt》由会员分享，可在线阅读，更多相关《达芬奇软件架构及开发流程重要.ppt（58页珍藏版）》请在三一办公上搜索。
1、达芬奇(DaVinci)软件开发李 亮13581737214,一、达芬奇软件架构 及开发流程二、Codec创建DSP Server三、Codec Engine概述,达芬奇(DaVinci)软件开发-什么是达芬奇技术？TI的DaVinci技术是一组专门为高效和引人注目的数字视频而设计的基于DSP的系统解决方案-适用于数码摄像机、视频安全设备、高级医疗成像设备、便携式视频播放器或任何其它您能想象得到的视频应用。成功实现数字视频需要四大要素的最新进步，即：处理器、开发工具、软件以及系统专业技术。由于能够在集成这四种要素的平台中实现数字视频、音频、语音与话音技术，因此达芬奇技术可以为数字视频的当前变革
2、打下基础。达芬奇技术充分利用了TI25年的数字信号处理与集成电路专业技术来提供系统级芯片(SoC)，这种系统针对灵活的数字视频实施而进行了精心优化，拥有业界领先的性能并集成了可编程数字信号处理器(DSP)内核、ARM处理器以及视频加速协处理器。凭借高效的处理能力、存储器、I/O带宽、平衡的内部互连以及专用外设组合，基于达芬奇技术的SoC能够以最低的成本为视频应用提供理想的核心动力。处理器自身只能用作数字视频解决方案的基础。管理数字视频系统的所有组件是极其复杂的工程难题。对于许多应用来说，数字视频只是更为庞杂的系统的众多组件之一。工程师随意地在自视为基础技术方面投入大把时间和资金的好日子已经一去
3、不复返了。,达芬奇(DaVinci)软件开发-为了真正意义上地让开发人员克服最初的障碍并且加快产品上市进程，仅仅开发实施数字视频的基础芯片和软件已经远远不够。开发人员不仅需要处理器，他们还需要 能够直接投入生产的理想代码。换句话说，为了满足其应用的特定需求，开发人员还需要已经集成到可配置或轻松编程的数字视频子系统的硬件和软件。正像汇编语言向C语言的过渡使开发人员能够全力开发更高级功能性那样，达芬奇技术使开发人员能够摆脱数字视频的具体技术细节。现在，开发人员不再需要了 解其视频应用中实施具体CODEC引擎(如：MPEG-2、H.263、WMA9)的细节。利用允许开发人员无需修改上层应用代码即可以
4、使用理 想CODEC的API，我们可以显著简化视频CODEC处理的具体低层次细节。摆 脱CODEC的困扰是数字视频广泛普及的重要一步。当开发人员可以立足于以前开发的功能性，创新就已经来到他们眼前。例如，在过去开发电子器件时，即使是最基本的功能，工程师们也需要进行栅极布局。许多年来，TI等公司始终致力于在硅芯片中集成功能，为超越自身功能期望的器件打下了基础，同时也降低了实现预期目标所需要的工程量。例如，由于提供了显著加快信号处理任务的计算引擎，DSP的问世已经推动了数十载的技术创新。利用达芬奇技术，TI可以再度实现全新的创新水平。正是DSP的问世带来了计算加速，因此达芬奇技术会以TI的DSP为基
5、础来提供应用加速。开发人员不再需要了解各种音频、视频、影像以及语音CODEC背后的机制。,一、达芬奇软件架构 及开发流程,Davinci 软件平台概述,用户软件用户程序，框架，GUI,设备驱动,Codec APIs,ARM/DSP 通信,Linux操作系统,ARM RISC,Video,Image,Speech,Audio,Socket Nodes,DSPLink,DSP/BIOS,DSP,外设,Codec Engine 2.30,Engine,Algorithm API,A-Node,Task,S-Node,Task,xDM API,Codec/算法,xDM API,Codec/算法,OMA
6、P-L137 Software Architecture,ARM 子系统,DSP 子系统,Linux 用户空间,Linux 内核空间,Transport,I/O,I/O,I/O,USB 2.0 Driver,CMEM Driver,McASPDriver,EMAC Driver,MMC/SD Driver,SPI Driver,Link Driver,UART Driver,DSP/BIOS Link v1.6x,DSP/BIOS 5.3x,应用程序,OSAL,Server,CCS 3.3/CGT,MontaVista Pro 5.0 Toolchain,LCD Driver,I2C Driv
7、er,GPIO Driver,PSL,Codec Engine 2.30,Engine,Algorithm API,DMAN3,Framework Components 2.30,C6747 Software Architecture,DSP 系统,USB 2.0 Driver,McASP,I2C Driver,CMEM Driver,EDMADriver,GPIO Driver,EMAC Driver,MMC/SD Driver,SPI Driver,UART Driver,应用程序,ACPY3,DSK2,DMAN,DSP/BIOS 5.32,LCD Driver,NANDDriver,ER
8、TFS Driver,CCS 3.3/CGT,xDM API,Codec/算法,xDM API,Codec/算法,功耗管理Power Manager(PWRM),PSL,达芬奇DMSoC软件概述-达芬奇DMSoC软件概述 一般来讲，软件系统分为应用层、信号处理层和I/O层三部分，TI提供的达芬奇参考软件框架就是基于这样的结构，如下图所示。,图1,达芬奇DMSoC软件概述-,应用层：工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色。信号处理层：通常都运行在DSP一侧负责信号处理，包括Video/Audio编解码算法、Codec Engine、DSP的实时操作系统DSP/BIOS及和A
9、RM通信的模块。信号处 理层(SPL)一方面通过VISA API接口与应用层(APL)连接，另一方面则通过DSP/BIOS与底层内核沟通。I/O层:就是我们通常所说的驱动，是针对Davinci外设模块的驱动程序。其中应用层通过Codec Engine的VISA API来调用DSP侧的算法，通过EPSI(Easy Peripheral Software Interface)API来访问和操作Davinci的外设。这三个部分通常对应三个Davinci软件开发小组。当然还需要一个系统集成工程师把这三个部分集成起来，不过VISA API和EPSI API的存在已经大大简化了集成工作的复杂程度。,Cod
10、ec Engine概述-下图给出了这种框架的结构示意图。共享DDR2存储器-ARM与DSP之间共享内存，进行物理数据交换。DSPLink-双核通信的基础软件，为开发人员提供通用的API，用于描述ARM 与DSP之间通信的物理链路的特征。引擎功能层-用于管理算法对象的实例，例如创建一个对象的具体过程等。VISA层-面向引擎功能层的一个接口，用于定义创建、删除和使用一个特定符合XDM标准的算法的进程。由于Codec Engine的主要任务是为从ARM发起的VISA命令控制远程的XDM算法起到一个管道的作用，因此VISA层实际上就代表了XDM接口层。,达芬奇软件架构 及开发流程-下面就是一个完整的应
11、用程序开发步骤：,xDM,Non-xDM,可发布使用的Codec包,VISA,Stub,DSP算法工程师,运行在DSP上的可执行程序：.cfg,.tcf,main(),Codec Server集成工程师,可执行应用程序,ARM应用工程师,各种引擎配置,Codec Engine集成工程师,*.cfg,DSP/BIOS,FrameWork Component,DSPLink,xDC,Server 名称，Codec列表,各种不同的Codec包：*.x64P,*.cfg,*.a64P即*.lib,*.x64P即*.out,达芬奇软件架构 及开发流程-一个完整的应用程序开发步骤：,xDM,Non-xDM
12、,可发布使用的Codec包,VISA,Stub,DSP算法工程师,*.a64P,第一步：需要基于DSP利用CCS开发自己的音视频编解码算法，编译生成一个编解码算法的库文件*.lib(等同于Linux环境下的*.a64P，直接在Linux环境下修改文件后缀名即可)。由于需要确保算法可被Codec Engine使用和配置，所以要确保这些算法实现需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard)for Digital Media)标准。Codec主要完成音视频的核心算法，应用程序运行时被调用，并不参与其他功能。如果算法与XDM标准兼容，则可
13、不经修改而直接被Codec Engine的VISA API远程执行；如不兼容，则需为其提供Codec Engine的框架和终端接口(具体请参考spraae7.pdf)。,达芬奇软件架构 及开发流程-一个完整的应用程序开发步骤：,第二步：将Codec集成到CodecEngine中。将第一步开发完成的Codec或已有的符合xDM的Codec集成到CodecEngine中，这一步需要配置两个JavaScript的脚本文件：*.cfg-表明Codec的使用和配置信息，*.tcf-描述Codec在达芬奇上的内存分配的配置.配置好这两个文件后，使用make命令即可生成CodecEngine，其文件名一般为
14、*.X64P(即.out文件).*.x64P(即.out文件)DSP端可执行程序，即DSP Server,可被ARM端的应用程序直接调用。对达芬奇的软件来说，DSP Server也叫Codec Server,运行在DSP上的可执行程序：.cfg,.tcf,main(),Codec Server集成工程师,*.x64P,DSP/BIOS,FrameWork Component,DSPLink,xDC,达芬奇软件架构 及开发流程-一个完整的应用程序开发步骤：,由于在双核环境中，Codec Engine是在DSP上执行，而操作系统是由ARM通过VISA API控制Codec Engine，所以必须先
15、在远程的DSP生成一个Codec Server。Codec Server是后缀为.x64P的文件，是一个集成了编解码器、框架元件和系统代码的二进制库。Codec Server包含了一个为相应客户端(ARM)生成编解码器、提供系统运行信息(包括指令和内存使用情况)的DSPBIOS任务线程；客户端(ARM)的应用程序通过使用VISA API与在远程DSP上的编解码器联系。,运行在DSP上的可执行程序：.cfg,.tcf,main(),Codec Server集成工程师,*.x64P,DSP/BIOS,FrameWork Component,DSPLink,xDC,达芬奇软件架构 及开发流程-一个完
16、整的应用程序开发步骤：,第三步：开发音视频应用程序(ARM)，并在其中调用Codec Engine 在Linux下开发音视频应用程序，包括用户界面，音视频的采集、播放、同步等，其中完成对CodecEngine的调用，应用程序也要完成一个扩展名为.cfg的脚本配置文件，以表明对CodecEngine的使用状况.引擎配置(通过配置工具)，写入到.cfg文件 引擎配置的工作，包括引擎的名字、每个引擎中包含什么编解码器、编解码器是本地执行还是远程执行等，如果这些编解码器在远程执行的，则还需配置相应的Codec Server。一般将所有的配置写到一个.cfg文件里面(具体说明，请参考sprue67.pd
17、f的第5章Integrating an Engine).,各种引擎配置,Codec Engine集成工程师,Server 名称，Codec列表,*.cfg,达芬奇软件架构 及开发流程-一个完整的应用程序开发步骤：,第四步：ARM应用工程师利用Coedc Engine的应用编程接口createdelete配置好的引擎实例，进而createdelete和控制编解码器。ARM应用工程师收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的应用程序通过编译、链接，最终生成ARM端可执行代码。ARM应用工程师可使用以下资源：a.从算法开发工程师得到的大量的编解码器软件包(
18、*.lib)；b.从服务集成工程师得到一个可以在DSP上运行的Codec Server二进制文件，一般为.x64P文件；c.从引擎集成工程师得到一个引擎配置文件，一般为.cfg文件。,可执行应用程序,ARM应用工程师,*.cfg,*.lib,*.x64P,*.cfg,达芬奇软件架构 及开发流程-一个完整的应用程序开发步骤：,由于Codec Engine不参与任何的I/O操作，只是纯粹的视频编解码算法处理，因此应用工程师需要管理I/O，包括文件操作(文件的打开、读写与存储等)和外设操作(外设的打开、关闭与控制等)。至此，即可加载DSPLINK和CMEM模块，运行应用程序.,可执行应用程序,ARM
19、应用工程师,*.cfg,各种不同的Codec包：*.x64P,*.cfg,至此一个完整的达芬奇音视频应用程序就完成了，其中许多过程是通过脚本文件配置完成的，过程非常 简单易懂，下面我们需要在达芬奇上运行它，首先要加载DSPLINK和CMEM两个驱动程序模块，其中DSPLINK主要实现了ARM和DSP的底层通信，而CMEM则主要是完成在物理段上分配连续内存的功能，加载完这两个模块，这样便可直接运行已完成的应用程序。,达芬奇(DaVinci)软件开发-一般的视频应用系统中，Davinci的ARM负责操作系统应用，DSP负责运行音视频codec算法处理，ARM通过TI的Codec Engine机制调
20、用DSP侧的codec.,三、Codec Engine概述,Codec Engine概述-Codec Engine概述前面我们提到，应用工程师通过调用Codec Engine的API来调用和运行符合xDAIS的算法(关于API的具体信息，请参考sprue67.pdf第4章)。达芬奇技术体系中引入了Codec Engine，并创建了一整套的应用开发平台。Codec Engine为通用处理器(GPP)上的开发者提供更为简单的开发环境。在Davinci软件中，符合 xDAIS的音视频编解码算法(即xDM算法)的调用是通过Codec Engine的VISA API完成的。Codec Engine通过这
21、套API为算法的执行提供了一个标准的软件架构和接口，体现在以下几个方面：通过Codec Engine API调用的算法可以运行在本地(ARM侧)或者远端(DSP侧)；2.Codec Engine可以基于ARMDSP、DSP或ARM上运行,GPP通过Codec Engine对其实行控制；3.无论Codec Engine运行在ARM还是DSP上，对应的Codec Engine API都是完全一致的；4.对于所有支持的不同处理器、运行方式及操作系统，Codec Engine都有相同的API.Codec Engine定义了4类编解码器算法接口标准，分别是Video、Image、Speech、Audio
22、，简称VISA.,Codec Engine概述-Codec Engine 概述,图1 达芬奇软件结构框图,Codec Engine是连接ARM和DSP或协处理器的桥梁，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块。,ARM应用程序调用Codec Engine的VISA（Video,Image,Speech,Audio）API，如VIDENC_process(a,b,c)。Codec Engine的stub（ARM侧）会把参数a,b,c以及要调用DSP侧process这个信息打包，通过消息队列（message queue）传递到DSP。Codec Engine的
23、skeleton（DSP侧）会解开这个参数包，把参数a,b,c转换成DSP侧对应的参数x,y,z（比如ARM侧传递的是虚拟地址，而DSP只能认物理地址），DSP侧的DSP server（优先级较低，负责和ARM通信的任务）会根据process这一信息创建一个DSP侧的process(x,y,x)任务最终实现VIDENC_process(a,b,c)的操作。,Codec Engine入门第一步-Codec Engine入门第一步 Codec Engine 1.20 根目录下的release_notes_codec_engine_1_20.html。这个文档就是你了解Codec Engine的开始
24、，里面有关于该版本Codec Engine的介绍、相关文档资料的链接、新的功能、支持哪些芯片、已知的bug、修正了哪些bug及例子等等的具体说明。具体如图2蓝色字体所示。浏览 该文档后，初学者至少可以知道哪里可以找到自己想要的文档或例子。举例来说，如果想找相关的文档，点击 Documentation就可以看到这个Codec Engine文件包里的文档的链接。,图2 Codec Engine 1.20 Release Notes截图,Codec Engine入门第二步-Codec Engine入门第二步 点击Codec Engine的发布说明文档（如图2）的Validation Info，我们可
25、以知道Codec Engine 1.20需要和以下软件模块和工具配合使用：Framework Components 1.20.02 xDAIS 5.21 XDC Tools 2.93.01 DSP/BIOS Link 1.40.05,configured for the DM6446 EVM C6x Code Generation Tools version 6.0.8 DSP/BIOS 5.31.05 MontaVista Linux v4.0 Red Hat Enterprise Linux 3(SMP)因 此，我们需要在该Codec Engine安装的DVSDK文件包下面检查上面提到的软
26、件模块和工具是否安装，版本是否正确。否则，可能会编译不过 Codec Engine的例子。那么，什么是 Framework Components，什么是xDAIS，什么又是XDC Tools呢？你可以分别到它们的根目录下浏览它们各自的发布说明文档，做一个总体的了解。这里我们简单介绍一下，可以帮助大家尽快找到和自己相关的重点及资源。,Codec Engine入门第二步-1）Framework Components 是TI提供的一个软件模块，负责DSP侧的memory 和DMA资源管理。因此，DSP算法工程师需要了解这个软件模块。http:/是一个标准，它定义了TI DSP算法接口的标准。这样大大
27、提高了DSP算法软件的 通用性。DSP算法工程师要写出能被ARM通过Codec Engine调用的算法，必须保证自己的 算法接口符合这个标准。因此，DSP算法工程师也必须了解这个软件模块。http:/,Codec Engine入门第二步-3）XDC Tools 和gmake类似，是一个工具。XDC根据用户定义的一套build指令，通过调用用户指定的ARM 工具链（Tool Chain）和DSP编译器（C6x Code Generation Tools）build出ARM侧和DSP侧的可 执行文件。可以先不必细究这个工具，只需通过编Codec Engine的例子，知道如何设置build指令就可以
28、了。4）DSP/BIOS Link是 实现ARM和DSP之间通信的底层软件，Codec Engine就是建立在此底层软件之上。在修改系统内存分配（缺省是256MB的DDR2）时，DSP/BIOS Link 1.38版本的用户需要修改DSP/BIOS Link的配置文件，并重新build DSP/BIOS Link。而DSP/BIOS Link 1.40版本以后的用户就无需此操作。http:/index.php?title=DSPLink_Overview http:/,Codec Engine入门第二步-5）C6x Code Generation Tools 是Linux环境下C6000系列D
29、SP的编译器.我们用CCS开发DSP时都是用的Windows环境下的DSP编译器。6）DSP/BIOS 是TI 免费提供的DSP实时操作系统。和上面C6x Code Generation Tools一样，这里的DSP/BIOS也是Linux环境下的版本。DSP系统工程师需要了解这个操作系统。http:/,Codec Engine入门第三步-Codec Engine入门第三步 开发ARMDSP平台需要三类工程师：ARM应用程序工程 师、DSP算法工程师和DSP系统工程师。而开发ARM协处理器平台只需要ARM应用程序工程师。下面就让我们针对这三类工程师做分别介绍。如果您使用 的是TI或TI第三方的
30、编解码算法，就不需要关注DSP算法工程师的部分。如果使用ARM协处理器平台，就只需关心ARM应用工程师的部分。,Codec Engine入门第三步-DSP算法工程师应该如何着手？这里我们不讨论如何开发DSP算法，只讨论DSP算法工程师怎样让自己的算法可以被ARM通过Codec Engine调用。（参考http:/package及相关的.xs和.xdc文件，Codec Engine1.20及以上版本的用户可以先不细究这些内容，后面会介绍工具帮您自动生成这些文件。）1）熟悉xDAIS和xDM标准xDM只是xDAIS的扩展，因此，需要先了解xDAIS。在xDAIS 软件包根目录下的发布说明文档里，可
31、以很快找到关于xDAIS和xDM的文档链接。http:/xDAIS安装路径下的examples/ti/xdais/dm/examples/g711有一个g711_sun_internal.c，这个算法不符合xDAIS标准。在同一个路径下的g711dec_sun_ialg.c(decoder)和g711enc_sun_ialg.c(encoder)是封装成符合xDM标准之后的编解码算法。可以通过这个例子学习和了解如何把自己算法封装成符合xDM标准的算法。xDAIS 6.10及其以后的版本，包含了一个工具QualiTI，可以检查您的DSP算法是否满足xDAIS标准（但不会检查是否满足xDM）。具体
32、请参 考：http:/index.php?title=QualiTI_XDAIS_Compliance_Tool,Codec Engine入门第三步-DSP算法工程师应该如何着手？2）熟悉Framework ComponentsFramework Components主要包括两个模块DSKT2和DMAN3，它们分别负责DSP侧的memory 和EDMA资源管理。DSP算法使用的memory必须是先向DSKT2提出申请并由DSKT2分配得到的。同样DSP算法使用的EDMA通道也是向 DMAN3申请并由DMAN3分配得到的。而关于QDMA的操作，是通过ACPY3这个模块实现的。这样的好处是很容易对
33、DSP侧不同的算法做整合，不同算法之间不用担心资源（Memory和EDMA）的冲突问题。在Framework Components 软件包根目录下的发布说明文档里，可以很快找到相关文档的链接。在Framework Components安装路径下packagestisdofcdman3examples有一个Fast Copy的例子，可以帮您理解如何基于Framework Components的ACPY3模块实现QDMA的操作。另外，有些用户DSP侧的算法比较简单，在确保不和ARM侧EDMA资源冲突的前提下在算法里直接操作EDMA不使用DMAN3也是可以的。这样做的弊端是和其它算法做整合时会遇到资
34、源使用冲突的问题。,Codec Engine入门第三步-DSP系统工程师应该如何着手？通常DSP算法工程师都会把自己的符合xDM标准的算法编成一个.lib文件（或.a64P），供DSP系统工程师调用。DSP系统工程师最终build出一个DSP Server（也就是DSP的可执行程序.x64P，和CCS下编译生成的.out类似）。（参考http:/sprued5b/sprued5b.pdf，这个文档会讲到.xdc和.bld等文件，Codec Engine1.20及以上版本的用户可以先不细究，后面介绍工具帮您自动生成这些文件。）,Codec Engine入门第三步-DSP系统工程师应该如何着手？1
35、）如果现在有一个.lib文件（或.a64P）（算法必须符合xDM标准），如何生成自己的DSP Server呢？下面URL有详细的关于RTSC Codec and Server Package Wizard工具介绍，教您如何把一个.lib文件封装成RTSC Codec 包和RTSC DSP Server包，并最终build出DSP的可执行程序.x64P。http:/如果您使用的是Codec Engine 1.20以前的版本，请参考Codec Engine安装路径下examples/servers/video_copy这个例子。这时就需要搞清楚sprued6c.pdf和 sprued5b.pdf中
36、提到的.xdc和.xs等文件的功能，也可以在video_copy中的相关文件的基础上修改手动创建出自己的RTSC Codec包和RTSC DSP server包。3）创建好RTSC Codec 和RTSC DSP Server包之后，就是如何build出.x64P的问题了。点击图2所示的Examples，就可以找到build Codec Engine例子的说明文档的链接。按照这个文档做一遍后，就可以对如何build Codec Server有一个清楚的了解。其中关键是修改user.bld和xdcpaths.mak文件，设置Codec Engine依赖的其它软件模块和工具的正确路径。A4）如果自
37、己的硬件DDR2大小和例子中的256Mbytes不一致，需 要修改DSP的.tcf文件和其他配置。还有些工程师不清楚如何分配memory及如何决定具体段，如：DDRALGHEAP和DDR的大小，以及如何配 置./loadmodules里的参数都请参考:http:/,Codec Engine入门第三步-ARM应用程序工程师应该如何着手？ARM应用工程师需要调用Codec Engine的VISA API，最终编出ARM侧的可执行程序，因此，必须根据自己的应用学习相关的VISA API、如何创建ARM侧Codec Engine的package及配置文件。参考http:/这个文档也涉及到如何调试Cod
38、ec Engine的内容）。1）了解ARM应用程序调用Codec Engine的流程、VISA API和其他Codec Engine API.参考Codec Engine安装路径下examples/apps/video_copy的例子（较简单）或者DVSDK安装路 径下demos里的encode/decode/encodedecode例子（较复杂）.http:/sprue67d.pdf有相关介绍，可以先读懂examples/apps/video_copy/ceapp.cfg.3）用A中提到的方法学习如何build ARM侧的可执行程序4）如何在多线程中调用codec engine，参考：htt
39、p:/,Codec Engine入门第三步-ARM应用程序工程师应该如何着手？5）还可以参考以下三个文档了解更多TI demo的ARM应用程序的结构、线程调度等具体的问题。EncodeDecode Demo for the DaVinci DVEVM/DVSDK 1.2(Rev.A)(spraah0a.htm,8 KB)27 Jun 2007 Abstract Encode Demo for the DaVinci DVEVM/DVSDK 1.2(Rev.A)(spraa96a.htm,8 KB)27 Jun 2007 Abstract Decode Demo for the DaVinci
40、DVEVM/DVSDK 1.2(Rev.A)(spraag9a.htm,8 KB)27 Jun 2007 Abstract,使用中常碰到的问题-1）如果遇到问题可以先访问http:/有些工程师没有DSP开发经验，或者暂时没有仿真器通过JTAG调试DSP.可以参考下面网页的内容，先做一个“Hello World”的例程对ARM和DSP如何协同工作有个感性认识。http:/很多工程师都是参考video_copy的例子，在它的基础上把自己的算法加进去。因为有源代码，这样比较容易。但肯定要根据自己算法的需要修改ARM和 DSP之间传递的buffer和参数，重要的是先保证ARM侧的应用程序可以把buff
41、er和参数正确传递到DSP，DSP可以把处理之后的buffer 正确的传到ARM侧的应用程序。把这个通路打通之后，就比较容易定位问题是出在ARM应用程序还是DSP侧的算法。另外，参考video_copy例子时注意代码的注释，以便清楚哪一句代码可以删掉哪一句必须要修改或保留。如果要扩展xDM的数据结构请参 考：http:/Engine DSP侧会涉及到Cache一致性的问题。请参考：http:/,使用中常碰到的问题-5）关于Codec Engine系统调试，有以下几种方法：A.打开Codec Engine trace，通过打印信息看问题出在什么地方。比如engine_open失败，DSP侧不能创
42、建codec 等等。a)Codec Engine 2.0及以上版本，请参考：http:/Engine 1.x版本，请参考：http:/应用程序跑起来后，用仿真器连上CCS调试DSP侧程序，参考：http:/C.用Soc Analyzer可以做系统调试之外，还可以统计具体函数运行（ARM和DSP侧）时间（benchmark）。请参考：http:/,使用中常碰到的问题-6）因为Codec Engine是介于ARM 应用程序和编解码算法中间的软件模块，很多工程师非常想知道它的开销(overhead)，请参考：http:/Engine安装路径下/packages/config.bld文件里var C6
43、?P=xdc.useModule(ti.targets.C6?P);之后添加：C6?P.extensions“.sa”=suf:“.sa”,typ:“asm:-fl”或C6?P.extensions“.asm”=suf:“.asm”,typ:“asm:-fa”,使用中常碰到的问题-8）DSP侧如何统计具体函数运行时间？TI DSPC6?x+内核有一个6?位的硬件定时器（Time Stamp Counter），它的频率和CPU频率一致。最简单的办法是使用TSC的低32位TSCL。注意在DM6?4x中，TSCH用于ARM。#include void main()TSCL=0;t1=TSCL;my_
44、code_to_benchmark();t2=TSCL;printf(“#cycles=%dn”,(t2-t1);6结语以上针对如何上手TI的Codec Engine做了简单的归纳，还有很多具体细节的问题没有涉及到。还请各位工程师从自己要用的软件模块发布说明文档开始找到相关的文档并研究。经常访问 TI的网页，http:/和http:/也非常欢迎您在wiki上提问。,Codec Engine概述-Codec Engine 框架分析 Codec Engine在解决达芬奇双处理器架构问题时首先引入了远程过程控制(RPC)的概念。RPC是指在另一个处理器上远程执行一个命令或过程。RPC有客户端和服务端
45、，客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令，服务端执行命令并通过相应的通信方式将结果返回给客户端。达芬奇芯片将ARM作为客户端、DSP作为服务端，两者之间的物理链路就是两个处理器之间共享的DDR2存储器，而将物理链路上的通信协议称为DSPLink。,Codec Engine概述-Codec Engine 组件CE里面有几个组件，或者我们叫做package,DSPLink是用来做应用软件和算法之间进行信令通信用的，DSPLink的 package里也有很多小模块，可以运行一个简单的脚本进行配置，然后再重新make出需要的dsplinkk.ko做为Linux模块加载的驱动；CM
46、EM是用来做共享内存分配的，因为应用程序是运行在MVista Linux上的，在应用程序里malloc到的buffer都是虚拟地址，实际的物理空间不一定连续，当把这个指针传递给算法的时候，问题就出现了，因为 算法是运行在DSP/BIOS上的，这是一个只有实地址的世界，为了解决这个问题，在共享缓存动态申请空间的时候，就要调用CMEM提供的API；XDCtTools是一个TI提供的工具组件，也是一个最核心的组件，任何的编译行为都是通过xdctools来解释脚本内容调用各种编译器来完成的，CCS下和Linux下的工具链是一样的，可以看到安装后CCS路径下的东西，一个是DSPBios，一个是CC，这里
47、面是交叉编译器，还有一个就是 XDCTools，在Linux下的CE也是如此，只不过还多了点料，譬如DSPLink和Cmem，所以，所有的组件package都可以在CCS下用，CGTools，这个就是DSP的交叉编译器 DSP/BIOS-使用CE一定要用DSP/BIOS，客户也可抛弃BIOS和CE，自己做双核通信。,Codec Engine概述-Codec Engine 的工作原理Codec Engine是介于应用程序和具体算法之间的软件模块，其中的VISA API通过stub和skeleton访问Engine SPI最终调用具体的算法。因此，Codec Engine的工作是通过完成VISA
48、API的任务来体现的。VISA API分为四部分VISA create/control/process/delete，我们以codec算法运行在DSP为例，通过VISA API的执行过程了解Codec Engine的工作原理。,Codec Engine概述-Codec Engine 的工作原理 在调用VISA API之前需要在应用程序中通过Engine_open()这个Engine API把DSP的可执行程序加载到DSP的memory，同时把DSP从复位状态释放，这时DSP开始运行DSP Server的初始化程序在DSP侧创建一个优先级最低的任务RMS(Remote Management Se
49、rver)，RMS负责管理和维护对应到具体codec算法的Instances。应用程序调用VISA create API，相应的VISA create函数到Engine SPI中的Codec table中查到这个codec运行在远端DSP侧。接着Engine SPI通过OSAL(Operating System Abstraction Layer)、DSPLink把VISA create的命令传到DSP侧的RMS。RMS通过DSP侧Engine SPI的codec table找到要调用的codec算法后，就会在RMS中创建一个相应的Instance(即一个DSP/BIOS系统中的任务)。VIS
50、A create会返回一个Instance的Handle，以便于给这个Instance做后续的VISAcontrol/process/delete提供信息。VISA delete和VISA create原理类似，只是RMS删除掉相应的codec算法的Instance和执行codec算法的任务。,Codec Engine概述-Codec Engine 的工作原理 概括来说，VISA control用来动态的修改codec instance的属性，VISA process用来对算法的输入数据流做处理并返回一个输出数据流。如下图所示，应用程序在调用VISA process/control时会通过xD
