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

nullnull 达芬奇(DaVinci)软件开发 李 亮 rock.li@serialsystem.com 13581737214null一、达芬奇软件架构 及开发流程 二、 Codec创建DSP Server 三、 Codec Engine概述null达芬奇(DaVinci)软件开发 --------------------------------------------------------------------------------------------------------------- 什么是达芬奇技术？ TI 的 DaVinci™ 技术是一组专门为高效和引人注目的数字视频而 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 的基于 DSP 的系统解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 -----------------适用于数码摄像机、视频安全设备、高级医疗成像设备、便携式视频播放器或任何其它您能想象得到的视频应用。 成功实现数字视频需要四大要素的最新进步，即：处理器、开发工具、软件以及系统专业技术。由于能够在集成这四种要素的平台中实现数字视频、音频、语音与话音技术，因此达芬奇技术可以为数字视频的当前变革打下基础。 达芬奇技术充分利用了 TI 25 年的数字信号处理与集成电路专业技术来提供系统级芯片(SoC)，这种系统针对灵活的数字视频实施而进行了精心优化，拥有业界领先的性能并集成了可编程数字信号处理器(DSP)内核、ARM处理器以及视频加速协处理器。凭借高效的处理能力、存储器、I/O带宽、平衡的内部互连以及专用外设组合，基于达芬奇技术的SoC能够以最低的成本为视频应用提供理想的核心动力。 处理器自身只能用作数字视频解决方案的基础。管理数字视频系统的所有组件是极其复杂的 工程 路基工程安全技术交底工程项目施工成本控制工程量增项单年度零星工程技术标正投影法基本原理 难题。对于许多应用来说，数字视频只是更为庞杂的系统的众多组件之一。工程师随意地在自视为基础技术方面投入大把时间和资金的好日子已经一去不复返了。null达芬奇(DaVinci)软件开发 --------------------------------------------------------------------------------------------------------------- 为了真正意义上地让开发人员克服最初的障碍并且加快产品上市进程，仅仅开发实施数字视频的基础芯片和软件已经远远不够。开发人员不仅需要处理器，他们还需要 能够直接投入生产的理想代码。换句话说，为了满足其应用的特定需求，开发人员还需要已经集成到可配置或轻松编程的数字视频子系统的硬件和软件。  正像汇编语言向 C 语言的过渡使开发人员能够全力开发更高级功能性那样，达芬奇技术使开发人员能够摆脱数字视频的具体技术细节。现在，开发人员不再需要了 解其视频应用中实施具体 CODEC 引擎(如：MPEG-2、H.263、WMA9)的细节。利用允许开发人员无需修改上层应用代码即可以使用理 想 CODEC 的 API，我们可以显著简化视频 CODEC 处理的具体低层次细节。 摆 脱 CODEC 的困扰是数字视频广泛普及的重要一步。当开发人员可以立足于以前开发的功能性，创新就已经来到他们眼前。例如，在过去开发电子器件时，即使是最基本的功能，工程师们也需要进行栅极布局。许多年来，TI 等公司始终致力于在硅芯片中集成功能，为超越自身功能期望的器件打下了基础，同时也降低了实现预期目标所需要的工程量。例如，由于提供了显著加快信号处理任务的计算引擎，DSP 的问世已经推动了数十载的技术创新。 利用达芬奇技术，TI 可以再度实现全新的创新水平。正是 DSP 的问世带来了计算加速，因此达芬奇技术会以 TI 的 DSP 为基础来提供应用加速。开发人员不再需要了解各种音频、视频、影像以及语音 CODEC 背后的机制。 null 一、达芬奇软件架构 及开发流程nullDavinci 软件平台概述用户软件 用户程序，框架，GUI设备 驱动Codec APIsARM/DSP 通信Linux操作系统ARM RISCVideoImageSpeechAudioSocket NodesDSPLinkDSP/BIOSDSP 外设OMAP-L137 Software ArchitectureOMAP-L137 Software ArchitectureCodec Engine 2.30EngineAlgorithm APIA-NodeTaskS-NodeTaskxDM APICodec/ 算法xDM APICodec/ 算法ARM 子系统DSP 子系统Linux 用户空间Linux 内核空间TransportI/OI/OI/OUSB 2.0 DriverCMEM DriverMcASP DriverEMAC DriverMMC/SD DriverSPI DriverLink DriverUART DriverDSP/BIOS Link v1.6xDSP/BIOS 5.3x应用程序OSALServerCCS 3.3/CGTMontaVista Pro 5.0 ToolchainLCD DriverI2C DriverGPIO DriverPSLC6747 Software ArchitectureC6747 Software ArchitectureCodec Engine 2.30EngineAlgorithm APIDMAN3Framework Components 2.30DSP 系统USB 2.0 DriverMcASPI2C DriverCMEM DriverEDMA DriverGPIO DriverEMAC DriverMMC/SD DriverSPI DriverUART Driver应用程序ACPY3DSK2DMANDSP/BIOS 5.32LCD DriverNAND DriverERTFS DriverCCS 3.3/CGTxDM APICodec/ 算法xDM APICodec/ 算法功耗管理 Power Manager (PWRM)PSLnull达芬奇DMSoC软件概述 --------------------------------------------------------------------------------------------------------------- 达芬奇DMSoC软件概述        一般来讲，软件系统分为应用层、信号处理层和I/O层三部分，TI提供的达芬奇参考软件框架就是基于这样的结构，如下图所示。图1null达芬奇DMSoC软件概述 ---------------------------------------------------------------------------------------------------------------应用层：工程师可以在系统的用户空间在系统功能性上添加和发挥自己的特色。 信号处理层：通常都运行在DSP一侧负责信号处理，包括Video/Audio编解码算法、 Codec Engine、DSP的实时操作系统DSP/BIOS及和ARM通信的模块。 信号处 理层(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的存在已经大大简化了集成工作的复杂程度。 nullCodec Engine概述 --------------------------------------------------------------------------------------------------------------- 下图给出了这种框架的结构示意图。 共享DDR2存储器----ARM与DSP之间共享内存，进行物理数据交换。 DSPLink---------------双核通信的基础软件，为开发人员提供通用的API，用于描述ARM 与DSP之间通信的物理链路的特征。 引擎功能层------------用于管理算法对象的实例，例如创建一个对象的具体过程等。 VISA层-----------------面向引擎功能层的一个接口，用于定义创建、删除和使用一个特定符合XDM 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 的算法的进程。由于Codec Engine的主要任务是为从ARM发起的VISA命令控制远程的XDM算法起到一个管道的作用，因此VISA层实际上就代表了XDM接口层。null达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 下面就是一个完整的应用程序开发步骤：xDMNon-xDM可发布使用的Codec包VISAStubDSP算法工程师运行在DSP上的可执行程序：.cfg, .tcf, main()Codec Server集成工程师可执行应用程序ARM应用工程师各种引擎配置Codec Engine集成工程师*.cfgDSP/BIOS,FrameWork Component, DSPLink, xDCServer 名称，Codec列表各种不同的Codec包： *.x64P , *.cfg*.a64P 即*.lib*.x64P 即*.outnull达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： xDMNon-xDM可发布使用的Codec包VISAStubDSP算法工程师*.a64P第一步： 需要基于DSP利用CCS开发自己的音视频编解码算法，编译生成一个编解码算法的库文件*.lib(等同于Linux环境下的*.a64P，直接在Linux环 境下修改文件后缀名即可)。由于需要确保算法可被Codec Engine使用和配置，所以要确保这些算法 实现需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)标准。 Codec主要完成音视频的核心算法，应用程序运行时被调用，并不参与其他功能。 如果算法与XDM标准兼容，则可不经修改而直接被Codec Engine的VISA API远程执行；如不兼容， 则需为其提供Codec Engine的框架和终端接口(具体请参考spraae7.pdf) 。null达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： 第二步： 将Codec集成到CodecEngine中。将第一步开发完成的Codec或已有的符合xDM的Codec集成到CodecEngine中， 这一步需要配置两个JavaScript的脚本文件： *.cfg----表明Codec的使用和配置信息， *.tcf-----描述Codec在达芬奇上的内存分配的配置. 配置好这两个文件后，使用make命令即可生成CodecEngine，其文件名一般为*.X64P (即.out文件) . *.x64P(即.out文件) DSP端可执行程序，即DSP Server,可被ARM端的应用程序直接调用。 对达芬奇的软件来说，DSP Server也叫Codec Server 运行在DSP上的可执行程序：.cfg, .tcf, main()Codec Server集成工程师*.x64PDSP/BIOS,FrameWork Component, DSPLink, xDCnull达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： 由于在双核环境中，Codec Engine是在DSP上执行，而操作系统是由ARM通过VISA API控制Codec Engine，所以必须先在远程的DSP生成一个Codec Server。 Codec Server是后缀为.x64P的文件，是一个集成了编解码器、框架元件和系统代码的二进制库。 Codec Server包含了一个为相应客户端(ARM)生成编解码器、提供系统运行信息(包括指令和内存使用情况)的DSP／BIOS任务线程； 客户端(ARM)的应用程序通过使用VISA API与在远程DSP上的编解码器联系。 运行在DSP上的可执行程序：.cfg, .tcf, main()Codec Server集成工程师*.x64PDSP/BIOS,FrameWork Component, DSPLink, xDCnull达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： 第三步： 开发音视频应用程序(ARM)，并在其中调用Codec Engine 在Linux下开发音视频应用程序，包括用户界面，音视频的采集、播放、同步等，其中完成对CodecEngine的调用， 应用程序也要完成一个扩展名为.cfg的脚本配置文件，以表明对CodecEngine的使用状况. 引擎配置(通过配置工具)，写入到.cfg文件 引擎配置的工作，包括引擎的名字、每个引擎中包含什么编解码器、编解码器是本地执行还是远程执行等， 如果这些编解码器在远程执行的，则还需配置相应的Codec Server。 一般将所有的配置写到一个.cfg文件里面(具体说明，请参考sprue67.pdf的第5章Integrating an Engine) . 各种引擎配置Codec Engine集成工程师Server 名称，Codec列表*.cfgnull达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： 第四步： ARM应用工程师利用Coedc Engine的应用编程接口create／delete配置好的引擎实例，进而create／delete和控制编解码器。 ARM应用工程师收到不同的codec包、DSP Server和Engine配置文件*.cfg，把自己的应用程序通过编译、链接，最终生成ARM端可执行代码。 ARM应用工程师可使用以下资源： a. 从算法开发工程师得到的大量的编解码器软件包(*.lib)； b. 从服务集成工程师得到一个可以在DSP上运行的Codec Server二进制文件，一般为.x64P文件； c. 从引擎集成工程师得到一个引擎配置文件，一般为.cfg文件。 可执行应用程序ARM应用工程师*.cfg*.lib, *.x64P , *.cfgnull达芬奇软件架构 及开发流程 --------------------------------------------------------------------------------------------------------------- 一个完整的应用程序开发步骤： 由于Codec Engine不参与任何的I/O操作，只是纯粹的视频编解码算法处理，因此应用工程师需要管理I/O，包括文件操作(文件的打开、读写与存储等)和外设操作(外设 的打开、关闭与控制等)。 至此，即可加载DSPLINK和CMEM模块，运行应用程序. 可执行应用程序ARM应用工程师*.cfg各种不同的Codec包： *.x64P , *.cfg 至此一个完整的达芬奇音视频应用程序就完成了，其中许多过程是通过脚本文件配置完成的，过程非常 简单易懂， 下面我们需要在达芬奇上运行它，首先要加载DSPLINK和CMEM两个驱动程序模块，其中DSPLINK主要实现了ARM和DSP的底层通信，而CMEM则主要是完成在物理段上分配连续内存的功能，加载完这两个模块，这样便可直接运行已完成的应用程序。null达芬奇(DaVinci)软件开发 ---------------------------------------------------------------------------------------------------------------       一般的视频应用系统中， Davinci的ARM负责操作系统应用， DSP负责运行音视频codec算法处理， ARM通过TI的Codec Engine机制调用DSP侧的codec.null 三、 Codec Engine概述nullCodec 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通过这套API为算法的执行提供了一个标准的软件架构和接口，体现在 以下几个方面： 通过Codec Engine API调用的算法可以运行在本地(ARM侧)或者远端(DSP侧)； 2. Codec Engine可以基于ARM＋DSP、DSP或ARM上运行, GPP通过Codec Engine对其实行控制 ； 3. 无论Codec Engine运行在ARM还是DSP上，对应的Codec Engine API都是完全一致的； 4. 对于所有支持的不同处理器、运行方式及操作系统，Codec Engine都有相同的API. Codec Engine定义了4类编解码器算法接口标准，分别是Video、Image、Speech、Audio，简称VISA. nullCodec 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的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)的操作。nullCodec Engine入门第一步 --------------------------------------------------------------------------------------------------------------- Codec Engine入门第一步 Codec Engine 1.20 根目录下的release_notes_codec_engine_1_20.html。 这个文档就是你了解Codec Engine的开始，里面有关于该版本Codec Engine的介绍、相关文档资料的链接、新的功能、支持哪些芯片、已知的bug、修正了哪些bug及例子等等的具体说明。具体如图2蓝色字体所示。浏览 该文档后，初学者至少可以知道哪里可以找到自己想要的文档或例子。举例来说，如果想找相关的文档，点击 Documentation就可以看到这个Codec Engine文件包里的文档的链接。图2 Codec Engine 1.20 Release Notes截图 nullCodec Engine入门第二步 --------------------------------------------------------------------------------------------------------------- Codec Engine入门第二步 点击Codec Engine的发布说明文档 （如图2）的Validation Info，我们可以知道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文件包下面检查上面提到的软件模块和工具是否安装，版本是否正确。否则，可能会编译不过 Codec Engine的例子。 那么，什么是 Framework Components，什么是xDAIS，什么又是XDC Tools呢？你可以分别到它们的根目录下浏览它们各自的发布说明文档，做一个总体的了解。 这里我们简单介绍一下，可以帮助大家尽快找到和自己相关的重点及资源。nullCodec Engine入门第二步 --------------------------------------------------------------------------------------------------------------- 1）Framework Components 是TI提供的一个软件模块，负责DSP侧的memory 和DMA资源管理。 因此，DSP算法工程师需要了解这个软件模块。 http://tiexpressdsp.com/wiki/index.php?title=Framework_Components_FAQ 2）xDAIS 是一个标准，它定义了TI DSP算法接口的标准。这样大大提高了DSP算法软件的 通用性。 DSP算法工程师要写出能被ARM通过Codec Engine调用的算法，必须保证自己的 算法接口符合这个标准。 因此，DSP算法工程师也必须了解这个软件模块。 http://tiexpressdsp.com/wiki/index.php?title=Category:XDAISnullCodec Engine入门第二步 --------------------------------------------------------------------------------------------------------------- 3）XDC Tools 和gmake类似，是一个工具。 XDC根据用户定义的一套build指令，通过调用用户指定的ARM 工具链（Tool Chain）和DSP编译器（C6x Code Generation Tools ）build出ARM侧和DSP侧的可 执行文件。 可以先不必细究这个工具，只需通过编Codec Engine的例子，知道如何设置build指令就可以了。 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://tiexpressdsp.com/wiki /index.php?title=DSPLink_Overview http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_mapnullCodec Engine入门第二步 --------------------------------------------------------------------------------------------------------------- 5）C6x Code Generation Tools 是Linux环境下C6000系列DSP的编译器. 我们用CCS开发DSP时都是用的Windows环境下的DSP编译器。 6）DSP/BIOS 是TI 免费提供的DSP实时操作系统。 和上面C6x Code Generation Tools一样，这里的DSP/BIOS也是Linux环境下的版本。 DSP系统工程师需要了解这个操作系统。 http://tiexpressdsp.com/wiki/index.php?title=Category:DSPBIOS nullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- Codec Engine入门第三步 开发ARM＋DSP平台需要三类工程师：ARM应用程序工程 师、DSP算法工程师和DSP系统工程师。而开发ARM＋协处理器平台只需要ARM应用程序工程师。 下面就让我们针对这三类工程师做分别介绍。 如果您使用 的是TI或TI第三方的编解码算法，就不需要关注DSP算法工程师的部分。如果使用ARM＋协处理器平台，就只需关心ARM应用工程师的部分。 nullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- DSP算法工程师应该如何着手？ 这里我们不讨论如何开发DSP算法，只讨论DSP算法工程师怎样让自己的算法可以被ARM通过Codec Engine调用。 （参考http://www.ti.com/litv/pdf/sprued6c，这个文档会讲到codec package及相关的.xs和.xdc文件，Codec Engine1.20及以上版本的用户可以先不细究这些内容，后面会介绍工具帮您自动生成这些文件。） 1）熟悉xDAIS和xDM标准 xDM只是xDAIS的扩展，因此，需要先了解xDAIS。 在xDAIS 软件包根目录下的发布说明文档里，可以很快找到关于xDAIS和xDM的文档链接。http://focus.ti.com/lit/ug/spruec8b/spruec8b.pdf 在 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）。 具体请参 考： http://tiexpressdsp.com/wiki /index.php?title=QualiTI_XDAIS_Compliance_Tool nullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- DSP算法工程师应该如何着手？ 2）熟悉Framework Components Framework Components主要包括两个模块DSKT2和DMAN3，它们分别负责DSP侧的memory 和EDMA资源管理。 DSP算法使用的memory必须是先向DSKT2提出申请并由DSKT2分配得到的。同样DSP算法使用的EDMA通道也是向 DMAN3申请并由DMAN3分配得到的。而关于QDMA的操作，是通过ACPY3这个模块实现的。这样的好处是很容易对DSP侧不同的算法做整合，不同算法之间不用担心资源（Memory和EDMA）的冲突问题。 在Framework Components 软件包根目录下的发布说明文档里，可以很快找到相关文档的链接。在Framework Components安装路径下packages\ti\sdo\fc\dman3\examples有一个Fast Copy的例子，可以帮您理解如何基于Framework Components的ACPY3模块实现QDMA的操作。 另外，有些用户DSP侧的算法比较简单，在确保不和ARM侧EDMA资源冲突的前提下在算法里直接操作EDMA不使用DMAN3也是可以的。这样做的弊端是和其它算法做整合时会遇到资源使用冲突的问题。nullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- DSP系统工程师应该如何着手？ 通常DSP算法工程师都会把自己的符合xDM标准的算法编成一个.lib文件（或 .a64P），供DSP系统工程师调用。 DSP系统工程师最终build出一个DSP Server（也就是DSP的可执行程序.x64P，和CCS下编译生成的.out类似）。 （参考http://focus.ti.com/lit/ug /sprued5b/sprued5b.pdf，这个文档会讲到.xdc和.bld等文件，Codec Engine1.20及以上版本的用户可以先不细究，后面介绍工具帮您自动生成这些文件。） nullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- DSP系统工程师应该如何着手？ 1）如果现在有一个.lib文件（或 .a64P）（算法必须符合xDM标准），如何生成自己的DSP Server呢？ 下面URL有详细的关于RTSC Codec and Server Package Wizard工具介绍，教您如何把一个.lib文件封装成RTSC Codec 包和RTSC DSP Server包，并最终build出DSP的可执行程序.x64P。 http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package_Wizards http://wiki.davincidsp.com/index.php?title=I_just_want_my_video_codec_to_work_with_the_DVSDK 2） 如果您使用的是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包之后，就是如何build出.x64P的问题了。点击图2所示的Examples，就可以找到build Codec Engine例子的说明文档的链接。按照这个文档做一遍后，就可以对如何build Codec Server有一个清楚的了解。其中关键是修改user.bld和xdcpaths.mak文件，设置Codec Engine依赖的其它软件模块和工具的正确路径。 [A] 4）如果自己的硬件DDR2大小和例子中的256Mbytes不一致，需 要修改DSP的.tcf文件和其他配置。还有些工程师不清楚如何分配memory及如何决定具体段，如：DDRALGHEAP和DDR的大小，以及如何配 置./loadmodules里的参数都请参考: http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_mapnullCodec Engine入门第三步 --------------------------------------------------------------------------------------------------------------- ARM应用程序工程师应该如何着手？ ARM应用工程师需要调用Codec Engine的VISA API，最终编出ARM侧的可执行程序，因此，必须根据自己的应用学习相关的VISA API、如何创建ARM侧Codec Engine的package及配置文件。 参考http://focus.ti.com/lit/ug/sprue67d/sprue67d.pdf， 这个文档也涉及到如何调试Codec Engine的内容）。 1）了解ARM应用程序调用Codec Engine的流程、VISA API和其他Codec Engine API. 参考Codec Engine安装路径下examples/apps/video_copy的例子（较简单）或者DVSDK安装路 径下demos里的encode /decode/encodedecode例子（较复杂）. http://wiki.davincidsp.com/index.php?title=Configuring_Codec_Engine_in_Arm_apps_with_createFromServer 2）了解ceapp.cfg文件. sprue67d.pdf有相关介绍，可以先读懂examples/apps/video_copy/ceapp.cfg. 3）用[A]中提到的方法学习如何build ARM侧的可执行程序 4）如何在多线程中调用codec engine，参考：http://wiki.davincidsp.com/index.php?title=Multiple_Threads_using_Codec_Engine_HandlenullCodec 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 DVEVM/DVSDK 1.2 (Rev. A) (spraag9a.htm, 8 KB) 27 Jun 2007 Abstractnull使用中常碰到的问题 --------------------------------------------------------------------------------------------------------------- 1）如果遇到问题可以先访问http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ 2） 有些工程师没有DSP开发经验，或者暂时没有仿真器通过JTAG调试DSP. 可以参考下面网页的内容，先做一个“Hello World”的例程对ARM和DSP如何协同工作有个感性认识。 http://wiki.davincidsp.com/index.php?title=How_to_build_an_ARM/DSP_Hello_World_program_on_the_DaVinci_EVM 3） 很多工程师都是参考video_copy的例子，在它的基础上把自己的算法加进去。 因为有源代码，这样比较容易。但肯定要根据自己算法的需要修改ARM和 DSP之间传递的buffer和参数，重要的是先保证ARM侧的应用程序可以把buffer和参数正确传递到DSP，DSP可以把处理之后的buffer 正确的传到ARM侧的应用程序。把这个通路打通之后，就比较容易定位问题是出在ARM应用程序还是DSP侧的算法。 另外，参考video_copy例子时注意代码的注释，以便清楚哪一句代码可以删掉哪一句必须要修改或保留。如果要扩展xDM的数据结构请参 考： http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM 4）Codec Engine DSP侧会涉及到Cache一致性的问题。请参考：http://wiki.davincidsp.com/index.php?title=Cache_Managementnull使用中常碰到的问题 --------------------------------------------------------------------------------------------------------------- 5）关于Codec Engine系统调试，有以下几种方法： A.打开Codec Engine trace，通过打印信息看问题出在什么地方。比如engine_open失败，DSP侧不能创建codec 等等。 a)Codec Engine 2.0及以上版本，请参考：http://wiki.davincidsp.com/index.php?title=Easy_CE_Debugging_Feature_in_CE_2.0 b)Codec Engine 1.x版本，请参考：http://wiki.davincidsp.com/index.php?title=TraceUtil B.ARM 应用程序跑起来后，用仿真器连上CCS调试DSP侧程序，参考： http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS C.用Soc Analyzer可以做系统调试之外，还可以统计具体函数运行（ARM和DSP侧）时间（benchmark）。请参考：http://tiexpressdsp.com/wiki/index.php?title=SoC_Analyzer null使用中常碰到的问题 --------------------------------------------------------------------------------------------------------------- 6） 因为Codec Engine是介于ARM 应用程序和编解码算法中间的软件模块，很多工程师非常想知道它的开销(overhead)， 请参考：http://wiki.davincidsp.com/index.php?title=Codec_Engine_Overhead 7）如何在Linux环境下编DSP的汇编或线性汇编程序？ 在Codec Engine安装路径下/packages/config.bld文件里 var C6?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” } null使用中常碰到的问题 --------------------------------------------------------------------------------------------------------------- 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 == %d\n”, (t2-t1)); } 6．结语 以上针对如何上手TI的Codec Engine做了简单的归纳，还有很多具体细节的问题没有涉及到。还请各位工程师从自己要用的软件模块发布说明文档开始找到相关的文档并研究。经常访问 TI的网页，http://wiki.davincidsp.com和http://tiexpressdsp.com/wiki找到最新的信息和资料。 也非常欢迎您在wiki上提问。nullCodec Engine概述 --------------------------------------------------------------------------------------------------------------- Codec Engine 框架分析 Codec Engine在解决达芬奇双处理器架构问题时首先引入了远程过程控制(RPC)的概念。RPC是指在另一个处理器上远程执行一个命令或过程。RPC有客户端和服务端，客户端通过某种通信 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 并最终通过物理链路向服务端发送一个命令，服务端执行命令并通过相应的通信方式将结果返回给客户端。 达芬奇芯片将ARM作为客户端、DSP作为服务端，两者之间的物理链路就是两个处理器之间共享的DDR2存储器，而将物理链路上的通信协议称为DSPLink。nullCodec Engine概述 --------------------------------------------------------------------------------------------------------------- Codec Engine 组件 CE里面有几个组件，或者我们叫做package, DSPLink是用来做应用软件和算法之间进行信令通信用的，DSPLink的 package里也有很多小模块，可以运行一个简单的脚本进行配置，然后再重新make出需要的dsplinkk.ko做为Linux模块加载