达芬奇软件架构及开发流程(For_)

1、达芬奇达芬奇(DaVinci)软件开发软件开发一、达芬奇软件架构一、达芬奇软件架构 及开发流程及开发流程二、二、 Codec创建创建DSP Server三、三、 Codec Engine概述概述达芬奇达芬奇(DaVinci)软件开发软件开发-什么是达芬奇技术？什么是达芬奇技术？ TI 的 DaVinci技术技术是一组专门为高效和引人注目的数字视频而设计的基于 DSP 的系统解决方案-适用于数码摄像机、视频安全设备、高级医疗成像设备、便携式视频播放器或任何其它您能想象得到的视频应用。 成功实现数字视频需要四大要素的最新进步，即：处理器、开发工具、软件以及系统专业技术。由于能够在集成这四种要素的平

2、台中实现数字视频、音频、语音与话音技术，因此达芬奇技术可以为数字视频的当前变革打下基础。 达芬奇技术充分利用了 TI 25 年的数字信号处理与集成电路专业技术来提供系统级芯片(SoC)，这种系统针对灵活的数字视频实施而进行了精心优化，拥有业界领先的性能并集成了可编程数字信号处理器(DSP)内核、ARM处理器以及视频加速协处理器。凭借高效的处理能力、存储器、I/O带宽、平衡的内部互连以及专用外设组合，基于达芬奇技术的SoC能够以最低的成本为视频应用提供理想的核心动力。 处理器自身只能用作数字视频解决方案的基础。管理数字视频系统的所有组件是极其复杂的工程难题。对于许多应用来说，数字视频只是更为庞杂

3、的系统的众多组件之一。工程师随意地在自视为基础技术方面投入大把时间和资金的好日子已经一去不复返了。达芬奇达芬奇(DaVinci)软件开发软件开发- 为了真正意义上地让开发人员克服最初的障碍并且加快产品上市进程，仅仅开发实施数字视频的基础芯片和软件已经远远不够。开发人员不仅需要处理器，他们还需要 能够直接投入生产的理想代码。换句话说，为了满足其应用的特定需求，开发人员还需要已经集成到可配置或轻松编程的数字视频子系统的硬件和软件。 正像汇编语言向 C 语言的过渡使开发人员能够全力开发更高级功能性那样，达芬奇技术使开发人员能够摆脱数字视频的具体技术细节摆脱数字视频的具体技术细节。现在，开发人员不再需

4、要了 解其视频应用中实施具体 CODEC 引擎(如：MPEG-2、H.263、WMA9)的细节。利用允许开发人员无需修改上层应用代码即可以使用理 想 CODEC 的 API，我们可以显著简化视频 CODEC 处理的具体低层次细节。 摆 脱 CODEC 的困扰是数字视频广泛普及的重要一步。当开发人员可以立足于以前开发的功能性，创新就已经来到他们眼前。例如，在过去开发电子器件时，即使是最基本的功能，工程师们也需要进行栅极布局。许多年来，TI 等公司始终致力于在硅芯片中集成功能，为超越自身功能期望的器件打下了基础，同时也降低了实现预期目标所需要的工程量。例如，由于提供了显著加快信号处理任务的计算引擎

5、，DSP 的问世已经推动了数十载的技术创新。 利用达芬奇技术，TI 可以再度实现全新的创新水平。正是 DSP 的问世带来了计算加速，因此达芬奇技术会以 TI 的 DSP 为基础来提供应用加速。开发人员不再需要了解各种音频、视频、影像以及语音 CODEC 背后的机制。 一、达芬奇软件架构一、达芬奇软件架构 及开发流程及开发流程Davinci软件平台概述软件平台概述用户软件用户软件用户程序，框架，GUI设备驱动CodecAPIsARM/DSP通信通信Linux操作系统操作系统ARMRISCVideoImageSpeechAudioSocketNodesDSPLinkDSP/BIOSDSP外设Cod

6、ec Engine 2.30EngineAlgorithm APIAlgorithm APIA-NodeTaskS-NodeTaskDSKT2DMAN3 ACPY3RMANCodec Engine RemoteServerFramework Components 2.30 xDMAPICodec/算法算法xDMAPICodec/算法算法OMAP-L137SoftwareArchitectureARM 子系统DSP 子系统Linux用户空间用户空间Linux内核空间内核空间TransportI/OI/OI/OUSB 2.0 DriverCMEM DriverMcASPDriverEMAC Dri

7、verMMC/SD DriverSPI DriverLinux APIsLink DriverUART DriverDSP/BIOS Link v1.6xDSP/BIOS 5.3x应用程序OSALServerCCS 3.3/CGTMontaVista Pro 5.0 ToolchainLCD DriverI2C DriverGPIO DriverPSLCodec Engine 2.30EngineAlgorithm APIDMAN3Framework Components 2.30C6747SoftwareArchitectureDSP 系统USB 2.0 DriverMcASPI2C Dri

8、verCMEM DriverEDMADriverGPIO DriverEMAC DriverMMC/SD DriverSPI DriverUART Driver应用程序ACPY3DSK2DMANDSP/BIOS 5.32LCD DriverNANDDriverERTFS DriverCCS 3.3/CGTxDMAPICodec/算法算法xDMAPICodec/算法算法功耗管理Power Manager (PWRM)PSL达芬奇达芬奇DMSoC软件概述软件概述- 达芬奇达芬奇DMSoC软件概述软件概述 一般来讲，软件系统分为应用层应用层、信号处理层信号处理层和I/O层层三部分，TI提供的达芬奇参

9、考软件框架就是基于这样的结构，如下图所示。图图1达芬奇达芬奇DMSoC软件概述软件概述-应用层：应用层：工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色。信号处理层：信号处理层：通常都运行在DSP一侧负责信号处理，包括Video/Audio编解码算法、 Codec Engine、DSP的实时操作系统DSP/BIOS及和ARM通信的模块。信号处 理层(SPL)一方面通过VISA API接口与应用层(APL)连接，另一方面则通过DSP/BIOS与底层内核沟通。I/O层层:就是我们通常所说的驱动驱动，是针对Davinci外设模块的驱动程序。其中应用层通过Codec Engine的VISA

10、 API来调用DSP侧的算法，通过EPSI(Easy Peripheral Software Interface)API来访问和操作Davinci的外设。这三个部分通常对应三个Davinci软件开发小组。当然还需要一个系统集成工程师把这三个部分集成起来，不过VISA API和EPSI API的存在已经大大简化了集成工作的复杂程度。 Codec Engine概述概述-下图给出了这种框架的结构示意图。共享共享DDR2存储器存储器-ARM与DSP之间共享内存，进行物理数据交换。DSPLink-双核通信的基础软件，为开发人员提供通用的API，用于描述ARM 与DSP之间通信的物理链路的特征。引擎功能层

11、引擎功能层-用于管理算法对象的实例，例如创建一个对象的具体过程等。VISA层层-面向引擎功能层的一个接口，用于定义创建、删除和使用一个特定符合XDM标准的算法的进程进程。由于Codec Engine的主要任务是为从ARM发起的VISA命令控制远程的XDM算法起到一个管道的作用，因此VISA层实际上就代表了XDM接口层。达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-下面就是一个完整的应用程序开发步骤：xDMNon-xDM可发布使用的可发布使用的Codec包包VISAStubDSP算法工程师算法工程师运行在运行在DSP上的可执行程上的可执行程序：序：.cfg,.tcf,main()Codec

12、Server集成工程师集成工程师可执行应用程序可执行应用程序ARM应用工程师应用工程师各种引擎配置各种引擎配置CodecEngine集成工程师集成工程师*.cfgDSP/BIOS,FrameWorkComponent,DSPLink,xDCServer名称，名称，Codec列表列表各种不同的各种不同的Codec包：包：*.x64P,*.cfg*.a64P即即*.lib*.x64P即即*.out达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤：xDMNon-xDM可发布使用的可发布使用的Codec包包VISAStubDSP算法工程师算法工

13、程师*.a64P第一步：第一步：需要基于DSP利用CCS开发自己的音视频编解码算法，编译生成一个编解码算法的库库文件*.lib(等同于Linux环境下的*.a64P，直接在Linux环境下修改文件后缀名即可)。由于需要确保算法可被Codec Engine使用和配置，所以要确保这些算法实现需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)标准。Codec主要完成音视频的核心算法，应用程序运行时被调用被调用，并不参与其他功能。如果算法与XDM标准兼容，则可不经修改而直接被Codec Engine的VI

14、SA API远程执行；如不兼容，则需为其提供Codec Engine的框架和终端接口(具体请参考spraae7.pdf) 。达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤：第二步：第二步：将Codec集成到集成到CodecEngine中。将第一步开发完成的Codec或已有的符合xDM的Codec集成到CodecEngine中， 这一步需要配置两个JavaScript的脚本文件： *.cfg-表明Codec的使用和配置信息， *.tcf-描述Codec在达芬奇上的内存分配的配置.配置好这两个文件后，使用make命令即可生成CodecEn

15、gine，其文件名一般为*.X64P (即.out文件) . *.x64P(即.out文件) DSP端可执行程序端可执行程序，即DSP Server,可被ARM端的应用程序直接调用。对达芬奇的软件来说，DSP Server也叫Codec Server 运行在运行在DSP上的可执行程上的可执行程序：序：.cfg,.tcf,main()CodecServer集成工程师集成工程师*.x64PDSP/BIOS,FrameWorkComponent,DSPLink,xDC达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤：由于在双核环境中，Code

16、cEngine是在是在DSP上执行上执行，而操作系统是由ARM通过VISA API控制Codec Engine，所以必须先在远程的DSP生成一个CodecServer。 Codec Server是后缀为.x64P的文件，是一个集成了编解码器、框架元件和系统代码的二进制库。 Codec Server包含了一个为相应客户端(ARM)生成编解码器、提供系统运行信息(包括指令和内存使用情况)的DSPBIOS任务线程； 客户端(ARM)的应用程序通过使用VISA API与在远程DSP上的编解码器联系。运行在运行在DSP上的可执行程上的可执行程序：序：.cfg,.tcf,main()CodecServer

17、集成工程师集成工程师*.x64PDSP/BIOS,FrameWorkComponent,DSPLink,xDC达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤：第三步：第三步：开发音视频应用程序应用程序(ARM)，并在其中调用调用Codec Engine 在Linux下开发音视频应用程序，包括用户界面，音视频的采集、播放、同步等，其中完成对CodecEngine的调用， 应用程序也要完成一个扩展名为.cfg的脚本配置文件，以表明对CodecEngine的使用状况.引擎配置引擎配置(通过配置工具配置工具)，写入到.cfg文件 引擎配置的工

18、作，包括引擎的名字、每个引擎中包含什么编解码器、编解码器是本地执行还是远程执行等，如果这些编解码器在远程执行的，则还需配置相应的Codec Server。 一般将所有的配置写到一个.cfg文件里面(具体说明，请参考sprue67.pdf的第5章Integrating an Engine) .各种引擎配置各种引擎配置CodecEngine集成工程师集成工程师Server名称，名称，Codec列表列表*.cfg达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤：第四步：第四步： ARM应用工程师利用Coedc Engine的应用编程接口cre

19、atedelete配置好的引擎实例，进而createdelete和控制编解码器。ARM应用工程师收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的应用程序通过编译、链接，最终生成ARM端可执行代码端可执行代码。ARM应用工程师可使用以下资源： a. 从算法开发工程师得到的大量的编解码器软件包(*.lib)； b. 从服务集成工程师得到一个可以在DSP上运行的Codec Server二进制文件，一般为.x64P文件； c. 从引擎集成工程师得到一个引擎配置文件，一般为.cfg文件。 可执行应用程序可执行应用程序ARM应用工程师应用工程师*.cfg*.lib,*

20、.x64P,*.cfg达芬奇软件架构达芬奇软件架构 及开发流程及开发流程-一个完整的应用程序开发步骤：一个完整的应用程序开发步骤： 由于Codec Engine不参与任何的I/O操作，只是纯粹的视频编解码算法处理，因此应用工程师需要管理I/O，包括文件操作(文件的打开、读写与存储等)和外设操作(外设的打开、关闭与控制等)。至此，即可加载加载DSPLINK和和CMEM模块，运行应用程序模块，运行应用程序.可执行应用程序可执行应用程序ARM应用工程师应用工程师*.cfg各种不同的各种不同的Codec包：包：*.x64P,*.cfg 至此一个完整的达芬奇音视频应用程序就完成了，其中许多过程是通过脚本

21、文件配置完成的，过程非常 简单易懂， 下面我们需要在达芬奇上运行它，首先要加载DSPLINK和CMEM两个驱动程序模块，其中DSPLINK主要实现了ARM和DSP的底层通信底层通信，而CMEM则主要是完成在在物理段上分配连续内存的功能物理段上分配连续内存的功能，加载完这两个模块，这样便可直接运行已完成的应用程序。达芬奇达芬奇(DaVinci)软件开发软件开发- 一般的视频应用系统中，Davinci的ARM负责操作系统应用操作系统应用，DSP负责运行音视频音视频codec算法处理算法处理，ARM通过TI的CodecEngine机制机制调用调用DSP侧的codec. 三、三、 Codec Engi

22、ne概述概述Codec Engine概述概述-CodecEngine概述概述前面我们提到，应用工程师通过调用Codec Engine的API来调用调用和运行符合xDAIS的算法(关于API的具体信息，请参考sprue67.pdf第4章)。达芬奇技术体系中引入了Codec Engine，并创建了一整套的应用开发平台。Codec Engine为通用处理器(GPP)上的开发者提供更为简单的开发环境。在Davinci软件中，符合 xDAIS的音视频编解码算法(即xDM算法)的调用是通过Codec Engine的VISA API完成的。Codec Engine通过这套API为算法的执行提供了一个标准的软

23、件架构和接口，体现在以下几个方面：1.通过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，简称VIS

24、A. Codec Engine概述概述-CodecEngine概述概述图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 En

25、gine的skeleton（DSP侧）侧）会解开这个参数包，把参数a, b, c转换成DSP侧对应的参数x, y, z（比如ARM侧传递的是虚拟地址，而DSP只能认物理地址），DSP侧的DSPserver（优先级较低，负责和ARM通信的任务）会根据process这一信息创建一个DSP侧的process(x, y, x)任务最终实现VIDENC_process(a, b, c)的操作。Codec Engine入门第一步入门第一步 -CodecEngine入门第一步入门第一步Codec Engine 1.20 根目录下的release_notes_codec_engine_1_20.html。这个

26、文档就是你了解Codec Engine的开始，里面有关于该版本Codec Engine的介绍、相关文档资料的链接、新的功能、支持哪些芯片、已知的bug、修正了哪些bug及例子等等的具体说明。具体如图2蓝色字体所示。浏览 该文档后，初学者至少可以知道哪里可以找到自己想要的文档或例子。举例来说，如果想找相关的文档，点击 Documentation就可以看到这个Codec Engine文件包里的文档的链接。图2 Codec Engine 1.20 Release Notes截图 Codec Engine入门第二步入门第二步 -CodecEngine入门第二步入门第二步 点击Codec Engine的

27、发布说明文档 （如图2）的Validation Info，我们可以知道Codec Engine 1.20需要和以下软件模块和工具配合使用配合使用：FrameworkComponents1.20.02xDAIS5.21XDCTools2.93.01DSP/BIOSLink1.40.05,configuredfortheDM6446EVMC6xCodeGenerationToolsversion6.0.8DSP/BIOS5.31.05MontaVistaLinuxv4.0RedHatEnterpriseLinux3(SMP)因 此，我们需要在该Codec Engine安装的DVSDK文件包下面检查

28、上面提到的软件模块和工具是否安装，版本是否正确。否则，可能会编译不过 Codec Engine的例子。那么，什么是 Framework Components，什么是xDAIS，什么又是XDC Tools呢？你可以分别到它们的根目录下浏览它们各自的发布说明文档，做一个总体的了解。这里我们简单介绍一下，可以帮助大家尽快找到和自己相关的重点及资源。Codec Engine入门第二步入门第二步-1）FrameworkComponents是TI提供的一个软件模块，负责负责DSP侧的侧的memory和和DMA资源管理资源管理。 因此，DSP算法工程师需要了解这个软件模块。 http:/ 是一个标准，它定义

29、了TI DSP算法接口的标准算法接口的标准。这样大大提高了DSP算法软件的 通用性。 DSP算法工程师要写出能被ARM通过Codec Engine调用的算法，必须保证自己的 算法接口符合这个标准。 因此，DSP算法工程师也必须了解这个软件模块。 http:/ Engine入门第二步入门第二步-3）XDCTools和gmake类似，是一个工具。 XDC根据用户定义用户定义的一套build指令指令，通过调用调用用户指定的ARM工具链工具链（Tool Chain）和DSP编译器编译器（C6x Code Generation Tools ）build出ARM侧和DSP侧的可可执行文件执行文件。 可以先

30、不必细究这个工具，只需通过编Codec Engine的例子，知道如何设置build指令就可以了。4）DSP/BIOSLink是 实现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:/ Engine

31、入门第二步入门第二步-5）C6xCodeGenerationTools 是是Linux环境下环境下C6000系列系列DSP的编译器的编译器. 我们用CCS开发DSP时都是用的Windows环境下的环境下的DSP编译器编译器。6）DSP/BIOS 是TI 免费提供的DSP实时操作系统。 和上面C6x Code Generation Tools一样，这里的DSP/BIOS也是Linux环境下的版本。 DSP系统工程师需要了解这个操作系统。 http:/ Codec Engine入门第三步入门第三步-CodecEngine入门第三步入门第三步 开发ARMDSP平台需要三类工程师：ARM应用程序工程

32、师、DSP算法工程师和DSP系统工程师。而开发ARM协处理器平台只需要ARM应用程序工程师。 下面就让我们针对这三类工程师做分别介绍。如果您使用 的是TI或TI第三方的编解码算法，就不需要关注DSP算法工程师的部分。如果使用ARM协处理器平台，就只需关心ARM应用工程师的部分。Codec Engine入门第三步入门第三步 -DSP算法工程师应该如何着手？算法工程师应该如何着手？这里我们不讨论如何开发DSP算法，只讨论DSP算法工程师怎样让自己的算法可以被ARM通过Codec Engine调用。（参考http:/ package及相关的.xs和.xdc文件，Codec Engine1.20及以上

33、版本的用户可以先不细究这些内容，后面会介绍工具帮您自动生成这些文件。） 1）熟悉）熟悉xDAIS和和xDM标准标准xDM只是xDAIS的扩展，因此，需要先了解xDAIS。在xDAIS 软件包根目录下的发布说明文档里，可以很快找到关于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标准之后的

34、编解码算法。可以通过这个例子学习和了解如何把自己算法封装成符合xDM标准的算法。xDAIS 6.10及其以后的版本，包含了一个工具QualiTI，可以检查您的DSP算法是否满足xDAIS标准（但不会检查是否满足xDM）。具体请参 考：http:/ /index.php?title=QualiTI_XDAIS_Compliance_ToolCodec Engine入门第三步入门第三步 -DSP算法工程师应该如何着手？算法工程师应该如何着手？2）熟悉）熟悉FrameworkComponentsFramework Components主要包括两个模块DSKT2和DMAN3，它们分别负责负责DSP侧的

35、侧的memory和和EDMA资源管理资源管理。DSP算法使用的memory必须是先向DSKT2提出申请并由DSKT2分配得到的。同样DSP算法使用的EDMA通道也是向 DMAN3申请并由DMAN3分配得到的。而关于QDMA的操作，是通过ACPY3这个模块实现的。这样的好处是很容易对DSP侧不同的算法做整合，不同算法之间不用担心资源（Memory和EDMA）的冲突问题。在Framework Components 软件包根目录下的发布说明文档里，可以很快找到相关文档的链接。在Framework Components安装路径下packagestisdofcdman3examples有一个Fast C

36、opy的例子，可以帮您理解如何基于Framework Components的ACPY3模块实现QDMA的操作。另外，有些用户DSP侧的算法比较简单，在确保不和ARM侧EDMA资源冲突的前提下在算法里直接操作EDMA不使用DMAN3也是可以的。这样做的弊端是和其它算法做整合时会遇到资源使用冲突的问题。Codec Engine入门第三步入门第三步 -DSP系统工程师应该如何着手？系统工程师应该如何着手？通常DSP算法工程师都会把自己的符合xDM标准的算法编成一个.lib文件（或 .a64P），供DSP系统工程师调用。DSP系统工程师最终build出一个DSPServer（也就是DSP的可执行程序.

37、x64P，和CCS下编译生成的.out类似）。（参考http:/ /sprued5b/sprued5b.pdf，这个文档会讲到.xdc和.bld等文件，Codec Engine1.20及以上版本的用户可以先不细究，后面介绍工具帮您自动生成这些文件。） Codec Engine入门第三步入门第三步 -DSP系统工程师应该如何着手？系统工程师应该如何着手？1）如果现在有一个.lib文件（或 .a64P）（算法必须符合xDM标准），如何生成自己的DSP Server呢？ 下面URL有详细的关于RTSC Codec and Server Package Wizard工具介绍，教您如何把一个.lib文件

38、封装成RTSC Codec 包和RTSC DSP Server包，并最终build出DSP的可执行程序.x64P。http:/ 如果您使用的是Codec Engine 1.20以前的版本，请参考Codec Engine安装路径下examples/servers/video_copy这个例子。这时就需要搞清楚sprued6c.pdf和 sprued5b.pdf中提到的.xdc和.xs等文件的功能，也可以在video_copy中的相关文件的基础上修改手动创建出自己的RTSC Codec包和RTSC DSP server包。3）创建好RTSC Codec 和RTSC DSP Server包之后，就是

39、如何build出.x64P的问题了。点击图2所示的Examples，就可以找到build Codec Engine例子的说明文档的链接。按照这个文档做一遍后，就可以对如何build Codec Server有一个清楚的了解。其中关键是修改user.bld和xdcpaths.mak文件，设置Codec Engine依赖的其它软件模块和工具的正确路径。 A4）如果自己的硬件DDR2大小和例子中的256Mbytes不一致，需 要修改DSP的.tcf文件和其他配置。还有些工程师不清楚如何分配memory及如何决定具体段，如：DDRALGHEAP和DDR的大小，以及如何配 置./loadmodules里

40、的参数都请参考: http:/ Engine入门第三步入门第三步 -ARM应用程序工程师应该如何着手？应用程序工程师应该如何着手？ARM应用工程师需要调用Codec Engine的VISA API，最终编出ARM侧的可执行程序，因此，必须根据自己的应用学习相关的VISAAPI、如何创建创建ARM侧侧CodecEngine的的package及配置文件配置文件。参考http:/ 这个文档也涉及到如何调试Codec Engine的内容）。1）了解ARM应用程序调用Codec Engine的流程、VISA API和其他Codec Engine API. 参考Codec Engine安装路径下examp

41、les/apps/video_copy的例子（较简单）或者DVSDK安装路 径下demos里的encode /decode/encodedecode例子（较复杂）.http:/ sprue67d.pdf有相关介绍，可以先读懂examples/apps/video_copy/ceapp.cfg.3）用A中提到的方法学习如何build ARM侧的可执行程序4）如何在多线程中调用codec engine，参考：http:/ Engine入门第三步入门第三步 -ARM应用程序工程师应该如何着手？应用程序工程师应该如何着手？5）还可以参考以下三个文档了解更多TI demo的ARM应用程序的结构、线程调度

42、等具体的问题。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 DVEVM/DVSDK 1.2 (Rev. A) (spraag9a.htm, 8 KB) 27 Jun 2007 Abstract使用中

43、常碰到的问题使用中常碰到的问题-1）如果遇到问题可以先访问http:/ 有些工程师没有DSP开发经验，或者暂时没有仿真器通过JTAG调试DSP.可以参考下面网页的内容，先做一个“Hello World”的例程对ARM和DSP如何协同工作有个感性认识。http:/ 很多工程师都是参考video_copy的例子，在它的基础上把自己的算法加进去。因为有源代码，这样比较容易。但肯定要根据自己算法的需要修改ARM和 DSP之间传递的buffer和参数，重要的是先保证ARM侧的应用程序可以把buffer和参数正确传递到DSP，DSP可以把处理之后的buffer 正确的传到ARM侧的应用程序。把这个通路打通

44、之后，就比较容易定位问题是出在ARM应用程序还是DSP侧的算法。另外，参考video_copy例子时注意代码的注释，以便清楚哪一句代码可以删掉哪一句必须要修改或保留。如果要扩展xDM的数据结构请参 考：http:/ Engine DSP侧会涉及到Cache一致性的问题。请参考：http:/ Engine系统调试，有以下几种方法：A.打开Codec Engine trace，通过打印信息看问题出在什么地方。比如engine_open失败，DSP侧不能创建codec 等等。a)Codec Engine 2.0及以上版本，请参考：http:/ Engine 1.x版本，请参考：http:/ 应用程序

45、跑起来后，用仿真器连上CCS调试DSP侧程序，参考：http:/ C.用Soc Analyzer可以做系统调试之外，还可以统计具体函数运行（ARM和DSP侧）时间（benchmark）。请参考：http:/ 因为Codec Engine是介于ARM 应用程序和编解码算法中间的软件模块，很多工程师非常想知道它的开销(overhead)，请参考：http:/ Engine安装路径下/packages/config.bld文件里var C6?P = xdc.useModule(ti.targets.C6?P);之后添加： C6?P.extensions“.sa” = suf: “.sa”, typ:

46、 “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_code_to_benchmark();t2=TSCL;printf(“# cycles = %dn”, (t2-t1

47、);6结语以上针对如何上手TI的Codec Engine做了简单的归纳，还有很多具体细节的问题没有涉及到。还请各位工程师从自己要用的软件模块发布说明文档开始找到相关的文档并研究。经常访问 TI的网页，http:/和http:/ 也非常欢迎您在wiki上提问。Codec Engine概述概述-CodecEngine框架分析框架分析 Codec Engine在解决达芬奇双处理器架构问题时首先引入了远程过程控制(RPC)的概念。RPC是指在另一个处理器上远程执行一个命令或过程。RPC有客户端和服务端，客户端通过某种通信协议并最终通过物理链路向服务端发送一个命令，服务端执行命令并通过相应的通信方式将结

48、果返回给客户端。 达芬奇芯片将ARM作为客户端、DSP作为服务端，两者之间的物理链路就是两个处理器之间共享的DDR2存储器，而将物理链路上的通信协议称为DSPLink。Codec Engine概述概述-Codec Engine 组件组件CE里面有几个组件，或者我们叫做package,DSPLink是用来做应用软件和算法之间进行信令通信用的，DSPLink的 package里也有很多小模块，可以运行一个简单的脚本进行配置，然后再重新make出需要的dsplinkk.ko做为Linux模块加载的驱动；CMEM是用来做共享内存分配的，因为应用程序是运行在MVista Linux上的，在应用程序里ma

49、lloc到的buffer都是虚拟地址，实际的物理空间不一定连续，当把这个指针传递给算法的时候，问题就出现了，因为 算法是运行在DSP/BIOS上的，这是一个只有实地址的世界，为了解决这个问题，在共享缓存动态申请空间的时候，就要调用CMEM提供的API；XDCtTools是一个TI提供的工具组件，也是一个最核心的组件，任何的编译行为都是通过xdctools来解释脚本内容调用各种编译器来完成的，CCS下和Linux下的工具链是一样的，可以看到安装后CCS路径下的东西，一个是DSPBios，一个是CC，这里面是交叉编译器，还有一个就是 XDCTools，在Linux下的CE也是如此，只不过还多了点料

50、，譬如DSPLink和Cmem，所以，所有的组件package都可以在CCS下用，CGTools，这个就是DSP的交叉编译器 DSP/BIOS-使用CE一定要用DSP/BIOS， 客户也可抛弃BIOS和CE，自己做双核通信。Codec Engine概述概述-CodecEngine的工作原理的工作原理Codec Engine是介于应用程序和具体算法之间的软件模块，其中的VISA API通过stub和skeleton访问Engine SPI最终调用具体的算法。因此，Codec Engine的工作是通过完成VISA API的任务来体现的。VISA API分为四部分VISA create/contro

51、l/process/delete，我们以codec算法运行在DSP为例，通过VISA API的执行过程了解Codec Engine的工作原理。Codec Engine概述概述-CodecEngine的工作原理的工作原理 在调用VISA API之前需要在应用程序中通过Engine_open()这个Engine API把DSP的可执行程序加载到DSP的memory，同时把DSP从复位状态释放，这时DSP开始运行DSP Server的初始化程序在DSP侧创建一个优先级最低的任务RMS(Remote Management Server)，RMS负责管理和维护对应到具体codec算法的Instances

52、。 应用程序调用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系统中的任务)。VISA create会返回一个Instance的Handle，以便于给这个I

53、nstance做后续的VISAcontrol/process/delete提供信息。VISA delete和VISA create原理类似，只是RMS删除掉相应的codec算法的Instance和执行codec算法的任务。Codec Engine概述概述-CodecEngine的工作原理的工作原理 概括来说，VISA control用来动态的修改codec instance的属性，VISA process用来对算法的输入数据流做处理并返回一个输出数据流。如下图所示，应用程序在调用VISA process/control时会通过xDMStub把传递给codec算法的参数收集起来，并且转换成DSP

54、可以识别的物理地址。 Stub把这些参数和相关的命令通过Engine SPI、OSAL和DSP Link传递到DSP侧Instance。Instance再通过Skeleton把传递过来的参数和命令解析出来，通过DSP侧VISA control/process对codec算法执行。 四、四、 Codec创建创建DSP Server(DSP端可执行程序端可执行程序) Codec创建创建DSP Server -对达芬奇的软件来说，DSPServer也叫CodecServer。其中“codec”是一组算法。从图3和4可以看到，除算法之外，DSP Server还集成了其他的软件模块(如DSP/BIOS、

55、DSP Link、Codec Engine等)。图图4图图3Codec创建创建DSP Server -1. xDC简介简介 达芬奇的软件开发环境中，有一个DSP工程师比较陌生的工具xDC(Express DSP Component)。 和gmake类似，xDC根据一套build指令build生成可执行文件生成可执行文件。xDC同时也会build依赖文件，并且可以一次build多个目标对象的可执行文件(如图5中的hello.x64P是DSP的可执行文件，hello.x470MV是ARM的可执行文件)。 xDC的源文件源文件可以是C程序、C+程序、汇编程序和库文件等。 如下图所示，xDC按照bui

56、ld指令，对DSP Server的源文件进行build(类似于make)生成DSP Server .x64P(.out)文件。 这个过程可以分为三部分： 创建创建DSP Server的源文件；的源文件； 设置设置xDC的配置文件；的配置文件； 执行执行“make”生成可执行文件生成可执行文件。图图5Codec创建创建DSP Server - 2.DSPServer的源文件的源文件 以Codec Engine_1_02中的video_copy为例，如图6我们可以看到video_copy的DSP Server中包括和图5对应的源文件main.c、video_copy.tcf和link.cmd。图5

57、中的packages是指图3和图4中的codecs、RMS、Engine SPI和OSAL。接下来，我们可以通过xDC的配置文件看到如何把packages添加到Server中。OMAP_L137的目录为：的目录为： Codec Engine_2_22/examples/ti/sdo/ce/examples/servers/video_copy/evmOMAPL137/ 要构建DSP Server首先就需要创建main.c和server的DSP/BIOS配置文件.tcf及link.cmd。我们提到engine_open会把DSP从复位状态释放，DSP Server程序开始运行初始化等等。这个初始

58、化就是DSP Server main.c(见图7)中的CERuntime_init()。除此之外在main.c中还可以打开Codec Engine的trace功能，读取或更改main函数的参数等。图图6Codec创建创建DSP Server - DSP BIOS的配置文件.tcf中定义DSP的memory map、设置DSP的复位/中断向量表并且创建和初始化BIOS程序需要的各种数据对象(如图8的.tcf)。在.tcf中我们只能定义编译器默认的sections(如.text和.bss等)。但是，我们可以在link.cmd中定义自己的sections(如图8 link.cmd中.tables和.

59、csl_vect等)。Codec创建创建DSP Server - DSP BIOS的配置文件.tcf中定义DSP的memory map、设置DSP的复位/中断向量表并且创建和初始化BIOS程序需要的各种数据对象(如图8的.tcf)。在.tcf中我们只能定义编译器默认的sections(如.text和.bss等)。但是，我们可以在link.cmd中定义自己的sections(如图8 link.cmd中.tables和.csl_vect等)。Codec创建创建DSP Server -3.xDC文件文件 在Linux中我们用make命令根据makefile来生成可执行文件，xDC也有类似的生成脚本文

60、件生成脚本文件(我们统称为xDC文件文件)。如图6所示，其中package.bld、package.xdc和video_copy.cfg三个文件就是提供给xDC build DSP Server的xDC文件。在package.xdc中声明DSP Server的名字、它的路径及Server的依赖文件.Package.bld文件的功能类似于Linux中的makefile，它会告诉xDC怎么样build DSP Server的源文件。如图9所示在package.bld中定义target是C64P DSP.要生成针对target的可执行程序，其中配置脚本文件是video_copy.tcf(与图8中的.