注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Aspirer's blog

停止维护,新博客地址:http://aspirer.wang/

 
 
 

日志

 
 

TI DaVinci(达芬奇)入门  

2009-09-15 16:22:24|  分类: 学习心得 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

TI DaVinci(达芬奇)入门 - aspirer - Aspirers blog

如果你想查看原始版本,请去TI中国的网站搜索文章的题目如帮您快速入门 TI Codec Engine”及TI百科:

http://wiki.davincidsp.com/index.php?title=Quickly_Getting_Started_on_TI_Codec_Engine

帮您快速入门 TI Codec Engine

 

德州仪器半导体技术(上海)有限公司 通用DSP 技术应用工程师 崔晶

德州仪器(TI)的第一颗达芬奇(DaVinci)芯片(处理器)DM6446已经问世快三年了。继DM644x之后,TI又陆续推出了DM643xDM35xDM6467OMAP353x等一系列ARMDSPARM+视频协处理器的多媒体处理器平台。很多有很强DSP开发经验或ARM开发经验的工程师都转到达芬奇或通用OMAPOMAP353x)平台上开发视频监控、视频会议及便携式多媒体终端等产品。大家都面临着同一个问题,那就是如何实现ARMDSP或协处理器的通信和协同工作?TI的数字视频软件开发包(DVSDK)提供了Codec Engine这样一个软件模块来实现ARMDSP或协处理器的协同工作。有很多工程师反馈这个软件模块非常好用,节省了很多开发时间,也有工程师认为TI提供的资料太多,不知如何快速上手。本文将从一个第一次接触Codec Engine的工程师角度出发,归纳TI提供的相关资源(文档,例程和网络资源)并介绍相关开发调试方法帮您快速入门Codec Engine

1Codec Engine概述

 

如图1所示,Codec Engine是连接ARMDSP或协处理器的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块。ARM应用程序调用Codec EngineVISA Video, Image, Speech, AudioAPI,如图1VIDENC_process(a, b, c )Codec Enginestub ARM侧)会把参数a, b, c以及要调用DSPprocess这个信息打包,通过消息队列(message queue)传递到DSPCodec EngineskeletonDSP侧)会解开这个参数包,把参数a, b, c转换成DSP侧对应的参数x, y, z(比如ARM侧传递的是虚拟地址,而DSP只能认物理地址),DSP侧的server(优先级较低,负责和ARM通信的任务)会根据process这一信息创建一个DSP侧的process(x, y, x)任务最终实现VIDENC_process(a, b, c)的操作。

1 达芬奇软件结构框图

2Codec Engine入门第一步,从Codec Engine发布说明文档(release notes)开始

 

2 Codec Engine 1.20 Release Notes截图

3Codec 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呢?你可以分别到它们的根目录下浏览它们各自的发布说明文档,做一个总体的了解。

这里我们简单介绍一下,可以帮助大家尽快找到和自己相关的重点及资源。

1 Framework ComponentsTI提供的一个软件模块,负责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:XDAIS

3 XDC Toolsgmake类似,是一个工具。XDC根据用户定义的一套build指令,通过调用用户指定的ARM 工具链(Tool Chain)和DSP编译器(C6x Code Generation Tools buildARM侧和DSP侧的可执行文件。可以先不必细究这个工具,只需通过编Codec Engine的例子,知道如何设置build指令就可以了。

4 DSP/BIOS Link是实现ARMDSP之间通信的底层软件,Codec Engine就是建立在这个底层软件之上。在修改系统内存分配(缺省是256MBDDR2)时,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_map

5 C6x Code Generation ToolsLinux环境下C6000系列DSP的编译器。我们用CCS开发DSP时都是用的Windows环境下的DSP编译器。

6 DSP/BIOSTI 免费提供的DSP实时操作系统。和上面C6x Code Generation Tools一样,这里的DSP/BIOS也是Linux环境下的版本。DSP系统工程师需要了解这个操作系统。

http://tiexpressdsp.com/wiki/index.php?title=Category:DSPBIOS

4Codec Engine入门第三步,根据自己的角色参考相关的文档和例子进行开发

 

开发ARMDSP平台需要三类工程师:ARM应用程序工程师、DSP算法工程师和DSP系统工程师。而开发ARM+协处理器平台只需要ARM应用程序工程师。下面就让我们针对这三类工程师做分别介绍。如果您使用的是TITI第三方的编解码算法,就不需要关注DSP算法工程师的部分。如果使用ARM+协处理器平台,就只需关心ARM应用工程师的部分。

41 DSP算法工程师应该如何着手?
这里我们不讨论如何开发DSP算法,只讨论DSP算法工程师怎样让自己的算法可以被ARM通过Codec Engine调用。(参考http://www.ti.com/litv/pdf/sprued6c,这个文档会讲到codec package及相关的.xs.xdc文件,Codec Engine1.20及以上版本的用户可以先不细究这些内容,后面会介绍工具帮您自动生成这些文件。)

1) 熟悉xDAISxDM标准。
xDM
只是xDAIS的扩展,因此,需要先了解xDAIS。在xDAIS 软件包根目录下的发布说明文档里,可以很快找到关于xDAISxDM的文档链接。
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

2 熟悉Framework Components Framework Components主要包括两个模块DSKT2DMAN3,它们分别负责DSP侧的memory EDMA资源管理。DSP算法使用的memory必须是先向DSKT2提出申请并由DSKT2分配得到的。同样DSP算法使用的EDMA通道也是向DMAN3申请并由DMAN3分配得到的。而关于QDMA的操作,是通过ACPY3这个模块实现的。这样的好处是很容易对DSP侧不同的算法做整合,不同的算法之间不用担心资源(MemoryEDMA)的冲突问题。
Framework Components 软件包根目录下的发布说明文档里,可以很快找到相关文档的链接。在Framework Components安装路径下packages\ti\sdo\fc\dman3\examples有一个Fast Copy的例子,可以帮您理解如何基于Framework ComponentsACPY3模块实现QDMA的操作。
另外,有些用户DSP侧的算法比较简单,在确保不和ARMEDMA资源冲突的前提下在算法里直接操作EDMA不使用DMAN3也是可以的。这样做的弊端是和其它算法做整合时会遇到资源使用冲突的问题。

42 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及以上版本的用户可以先不细究,后面介绍工具帮您自动生成这些文件。)

1) 如果现在有一个.lib文件(或 .a64P)(算法必须符合xDM标准),如何生成自己的DSP Server呢?下面URL有详细的关于RTSC Codec and Server Package Wizard工具介绍,教您如何把一个.lib文件封装成RTSC Codec 包和RTSC DSP Server包,并最终buildDSP的可执行程序.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.pdfsprued5b.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.bldxdcpaths.mak文件,设置Codec Engine依赖的其它软件模块和工具的正确路径。

4 如果自己的硬件DDR2大小和例子中的256Mbytes不一致,需要修改DSP.tcf文件和其他配置。还有些工程师不清楚如何分配memory及如何决定具体段,如:DDRALGHEAPDDR的大小,以及如何配置./loadmodules里的参数都请参考: http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map

43 ARM应用程序工程师应该如何着手?
ARM
应用工程师需要调用Codec EngineVISA API,最终编出ARM侧的可执行程序,因此,必须根据自己的应用学习相关的VISA API、如何创建应用侧Codec Enginepackage及配置文件。(参考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 4.2 3)中提到的方法学习如何build ARM侧的可执行程序。

4 如何在多线程中调用codec engine,参考:
http://wiki.davincidsp.com/index.php?title=Multiple_Threads_using_Codec_Engine_Handle

5)还可以参考以下三个文档了解更多TI demoARM应用程序的结构、线程调度等具体的问题。

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

5.使用中常碰到的问题

 

1)如果遇到问题可以先访问 http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ

2)有些工程师没有DSP开发经验,或者暂时没有仿真器通过JTAG调试DSP。可以参考下面网页的内容,先做一个“Hello World”的例程对ARMDSP如何协同工作有个感性认识。

http://wiki.davincidsp.com/index.php?title=How_to_build_an_ARM/DSP_Hello_World_program_on_the_DaVinci_EVM

3 很多工程师都是参考video_copy的例子,在它的基础上把自己的算法加进去。因为有源代码,这样比较容易。但肯定要根据自己算法的需要修改ARMDSP之间传递的buffer和参数,重要的是先保证ARM侧的应用程序可以把buffer和参数正确传递到DSPDSP可以把处理之后的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_Management

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可以做系统调试之外,还可以统计具体函数运行(ARMDSP侧)时间(benchmark)。请参考: http://tiexpressdsp.com/wiki/index.php?title=SoC_Analyzer

6 因为Codec Engine是介于ARM 应用程序和编解码算法中间的软件模块,很多工程师非常想知道它的开销(overhead),请参考:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_Overhead

7)如何在Linux环境下编DSP的汇编或线性汇编程序?
Codec Engine安装路径下/packages/config.bld文件里
var C64P = xdc.useModule(‘ti.targets.C64P’);
之后添加:
C64P.extensions[“.sa”] = {
suf: “.sa”, typ: “asm:-fl”
}

C64P.extensions[“.asm”] = {
suf: “.asm”, typ: “asm:-fa”

8DSP侧如何统计具体函数运行时间?
TI DSPC64x+
内核有一个64位的硬件定时器(Time Stamp Counter),它的频率和CPU频率一致。
最简单的办法是使用TSC的低32TSCL。注意在DM644x中,TSCH用于ARM
#include void main (){

TSCL=0;

t1=TSCL;
my_code_to_benchmark();
t2=TSCL;
printf(“# cycles == %d\n”, (t2-t1));
}

6.结语

 

以上针对如何上手TICodec Engine做了简单的归纳,还有很多具体细节的问题没有涉及到。还请各位工程师从自己要用的软件模块发布说明文档开始找到相关的文档并研究。经常访问TI的网页,http://wiki.davincidsp.comhttp://tiexpressdsp.com/wiki找到最新的信息和资料。也非常欢迎您在wiki上提问。

 

 

 

 

 

 

 

 

 

 

 

 

达芬奇数字媒体片上系统的架构和 Linux 启动过程

德州仪器半导体技术(上海)有限公司 崔晶

达芬奇(DaVinci)数字媒体技术平台TMS320DM6446/3采用了ARM+DSP双核的架构,本文从芯片的硬件结构入手介绍达芬奇DMSoC硬件部分及Linux OS的启动过程。

达芬奇 DMSoC 硬件概述

如图1所示,达芬奇数字媒体片上系统(DMSoC)提供:两个内核(ARM+DSP);视频处理子系统(VPSS);多种Boot模式(NOR Flash/NAND Flash/UART0 Boot Mode);两个电源域;多个时钟树;多个引脚独立或复用的外设。

1  DM6446功能结构框图

ARM-DSP集成

对于双核的达芬奇架构,大家最关心的就是两个核之间的资源分配、通信方式及如何高效地实现资源共享各尽其能。ARM独享(DSP不可用)的外设有:UART0/1/2I2C,看门狗定时器,PWM0/1/2ARM中断控制器,USB2.0ATA/CFSPIGPIOVPSSEMAC/MDIOEMIFA CONTROLVLYNQMMC/SDDSP独享(ARM不可用)的外设有:DSP中断控制器,VICPARMDSP共享的外设有:EDMATimer0/1Power & Sleep ControllerASPEMIFA Data

2  ARM-DSP集成结构

如图2所示,可以很清楚地看到ARM可以访问DSP片内存储器(L2RAML1P/D)DSP可以访问ARM片内存储器;ARMDSP共享DDR2AEMIF。因此,通常情况下ARM只需传递需要处理的数据地址指针给DSP,而无须大块的数据搬移。ARMDSP之间的通信可以通过相互中断实现。ARM可以中断DSP(通过4个通用中断和1个不可屏蔽中断)DSP可以通过2个通用中断来中断ARMARM控制DSP的电源、时钟、复位和引导。

DMSoC存储器映射

达芬奇DMSoC多个片上存储器和两个处理器及不同的子系统相关。为了简化软件开发,DMSoC中所有的存储器统一编址,如表1所示。

DMSoC交换中心资源

以上大家看到DMSoC有非常丰富的外设和视频处理硬件资源,而且ARMDSP又共享DDR2等存储器资源,那么DMSoC又是如何确保ARMDSPVPSS同时访问外设或存储器资源时不会引起冲突呢?DMSoC中的交换中心资源(SCRSwitched Central Resource)会做出管理。如图3所示,把任何一个发起数据传输的源称为Master(每一个Master有一个专用的ID),这个Master要访问的目的地称为Slave,这样在MasterSlave之间就构成一条数据传输的通路。从图3中可以看到,在SCR中可以有很多并行的MasterSlave的数据通路。如果是不同的Master、相同的Slave,那么可以通过设置每一个Master的优先级来得到特殊应用系统的最佳性能。对于大多数的Master,可以通过寄存器MSTPRI0MSTPRI1来设置它们的优先级。如果MasterC64x+VPSSEDMA,可以通过它们自己的相关寄存器控制它们自己的优先级,这样可以更加灵活、快速的实现高的视频数据吞吐带宽。详细信息可以参考DM6446的数据手册。

3  DMSoC交换中心资源的结构框图

电源域及复位

达芬奇DMSoC有两个电源域,分别是Always On域和DSP域。Always On域由CVDD ARM核电源供电,给ARM、总线、SCR和除VICP之外的所有外设提供电源;DSP电源域由CVDDDSP DSP核电源供电,给DSPVICP提供电源。

双核架构的达芬奇DMSoC的功耗也非常有竞争力,这一方面取决于芯片本身的工艺,另一方面也取决于芯片内部时钟和电源的结构。如图4所示,达芬奇DMSoC有电源休眠控制器(Power & Sleep Controller)管理芯片电源的开关及复位。可以用软件控制DSP电源域,控制DSP及其模块时钟的开关和复位。PSC不支持ARM及其模块的断电控制、ARM的本地复位和ARM的时钟关断控制。同时PSC可以中断ARMDSP,支持IcePick仿真(emulation)特性。

4  DM6446的电源休眠控制器

关于达芬奇DMSoC的复位类型、触发源及对应的复位对象请参考表2

达芬奇DMSoC初始化流程

达芬奇DMSoC复位状态

DM644x上电复位后,芯片的绝大部分模块都处于不工作状态。锁相环PLL处于旁路(Bypass)模式;DSP子系统的状态取决于DSP_BT引脚;UART1UART2也处于不工作状态,UART0的状态取决于BTSEL引脚(如果BTSEL=11UART0工作)EMIFA处于工作状态,其数据总线宽度由EM_WIDTH决定,地址总线宽度由AEAW决定;芯片的大部分引脚都被配置为GPIO引脚。引脚复用通过寄存器PINMUX0PINMUX1控制。

达芬奇DMSoC初始化顺序

1.  DMSoC复位。芯片的配置由PSC决定,取决于BTSEL[0-3]EM_WIDTHAEWADSP_BT的状态。

2.       ROM boot loader(如果被选)NAND或者UART0的初始化。

3.       引导加载(Boot-loading)。以U-boot为例,

o    使能电源域:DDR2DSP

o    设置时钟频率(ARMDSPDDR2时钟的乘除系数)

o    设置引脚复用控制器;

o    设置ARM引导启动操作系统。

4.       操作系统启动。以Linux为例,

o    初始化ARM

o    初始化硬件系统;

o    初始化Linux环境。

U-boot初始化顺序

通常情况下,ARM Linux要求boot loader中有少许的初始化。目前TIDVEVM使用的是U-boot-1.1.3U-boot代码中首先运行的是u-boot/cpu/arm926ejs/start.S,芯片和一些DVEVM板的硬件配置主要在u-boot/board/davinci/platform.Sdavinci.c中完成。其中u-boot/board/davinci/platform.S设置最基本的系统硬件环境,包括系统PLLDDR2的初始化、PSC的配置及使能UART0AEMIF等硬件模块。有些工程师设计的达芬奇板可能用到了和DVEVM不同的Flash,那么就要根据用到的Flash参数修改u-boot/board/davinci/flash.c。另外,关于DM644x支持的NAND Flash ID,请参考TMS320DM644x DMSoC的相关文档。

NOR Flash boot为例,DVEVM u-boot初始化下列的达芬奇DMSoC内容:

1.       关中断和MMU

2.       使能DSP电源域(PTCMD),把DSP置为复位状态。

3.       初始化PLL,使能DDR2,软复位DDR2并且重新使能DDR2,使其脱离复位状态。

4.       初始化系统PLL

5.       配置AEMIF引脚为NOR Flash接口。

6.       VTP校准。

完成以上步骤之后,U-boot准备引导ARM Linux

1.       配置系统的内存(通过ATAG_ MEM块和mem=)NAND FlashDDR2

2.       通过TFTP加载等加载方式,加载内核到指定的存储地址。

3.       如果定义过,加载RAM Disk

4.       初始化传递到内核的引导参数(EMAC地址,串口,控制台,视频格式等)

5.       获得ARM Linux机类型值(DVEVM为#901)

6.       设置kernel tagged list

7.       用初始值设置ARM的寄存器。

8.       调用内核。

Linux 初始化步骤

1.  Linux内核需要从引导加载程序(U-boot)中得到以下参数。

*
已经初始化的memory系统。
* R0
0R1ARM Linux机类型值。
* R2
指向ATAG结构体的内容:物理memory区;是否使用RAM DISK及其压缩版的地址;视频驱动程序具体的初始化参数;内核命令行;其他参数(串口和版本号)

更多关于Linux内核引导参数的信息可以参考Linux/Documentation/kernel-parameters.txt。如果要想传递给内核更多的参数,再u-boot中的bootargs中设置就可以了。
 

2.       对于压缩的内核(aka uImage)Linux 最初启动Linux/arch/kernel/head.s

3.       start_kernel()运行。位于Linux/init/main.c

4.       Linux的第一个进程init()运行。

总结

经过上面介绍,很多DSP工程师可能会对达芬奇DMSoCLinux启动流程有一个感性的认识,双核架构的达芬奇DMSoC带给我们的是一加一大于二的性价比,要想了解更多的细节,请参考数据手册和应用文档。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

数字视频系统设计中的集成新概念(下)

闻亭数字系统(北京)有限公司
德州仪器半导体技术(上海)有限公司

数字视频配置工具

将数字视频嵌入应用中的首要难题在于实施视频的复杂性要远远超过简单的图像与音频压缩和解压缩。数字视频可以采用形形色色的形式与格式,开发人员需要支持繁杂的配置和各种不同的方面,其中包括不同的分辨率/显示器尺寸、不同的比特率、实时问题乃至视频源的可靠性等,例如来自硬盘驱动器的视频流与来自无线通信链路的视频流的区别和处理。即使是那些看似简单明了的任务——如高效管理音频/视频同步以及在IP 网络上实现可靠的视频传输,仍然会让开发人员伤透脑筋。

如何使这些技术难题迎刃而解就成为采用达芬奇技术成功实现数字视频系统设计的关键。达芬奇技术所包含的四大要素,即处理器、开发工具、软件以及系统专业技术对于数字视频设计的集成具有重要的作用,其中一个极为有效的工具就是包含在TI为配合达芬奇开发所提供的数字视频开发包(DVSDK)中的数字视频配置工具(eXpressDSP Configuration Kit)。

由于在达芬奇技术软件结构中引入了编解码引擎(Codec Engine)结构,Codec Engine就提供了对DSP标准化算法(XDAIS)的完全包装,使得应用程序与DSP程序的开发分离,更为方便简捷,Codec Engine使得DSP开发人员不必关心应用程序端,只需按照相应的标准开发出Codec Server,即可被应用程序正确调用。有了eXpressDSP配置工具的支持,开发人员模块之间的接口,eXpressDSP配置工具会自动绑定编解码器(CODEC)以及符合xDM标准的软件模块,不需要任何其它的操作,几乎可以将开发时间从数月降到几周之内,使软件的重使用率大大增加。eXpressDSP配置工具汇集了Linux和达芬奇技术的CODEC ENGINE以及DSP/BIOSDSP/BIOS LINK。下图为系统集成图:

数字视频配置工具使得配置一个CODEC的过程极其简单,只需进行简单的脚本配置,无需DSP编程便可以完成,首先得到在DSP上的符合xDM标准Codec库,通过脚本配置语言进行简单的配置,将此Codec库至于Codec Engine中,进行再次编译链接。至此已经完成了Codec上的全部工作。下面将逐步描述一个基于达芬奇开发板的应用程序的生成过程:

第一步,开发并完成Codec。就是要开发音视频编解码的核心算法,按照xDM标准封装成为Codec库,Codec主要完成音视频的核心算法,应用程序运行时被调用,并不参与其他功能。

第二步,将Codec集成到Codec Engine中。将第一步开发完成的Codec或已有的符合xDMCodec集成到Codec Engine中,这一步需要配置两个JavaScript的脚本文件,其中一个脚本文件表明了,Codec的使用和配置信息,文件名一般为*.cfg,另一个描述了Codec在达芬奇上的内存分配的配置,文件名一般为*tcf,配置好这两个文件后,使用make命令即可生成Codec Engine,其文件名一般为*.X64P。可被应用程序直接调用。

第三步,开发音视频应用程序,并在其中调用Codec Engine。在Linux下开发音视频应用程序,包括用户界面,音视频的采集、播放、同步等,其中完成对Codec Engine的调用,应用程序也要完成一个扩展名为cfg的脚本配置文件,以表明对Codec Engine的使用状况。

第四步,加载DSPLINKCMEM模块,运行应用程序

至此一个完整的达芬奇音视频应用程序就完成了,其中许多过程是通过脚本文件配置完成的,过程非常简单易懂,下面我们需要在达芬奇上运行它,首先要加载DSPLINKCMEM两个驱动程序模块,其中DSPLINK主要实现了armdsp的底层通信,而CMEM则主要是完成了在物理段上分配连续内存的功能,加载完这两个模块,我们便可以直接运行已完成的应用程序。

图形系统可视化工具

将多个软件模块集成只是整个开发过程的第一步,DVDSK还包含一个图形系统可视化工具,可用于分析和显示整个系统的性能,从而帮助快速开发数字媒体软件。基于TMS320DM644x SoC分析器的可视化分析,以最小化的干预快速辨别和分离系统的各部分执行状况,并通过捕捉数据鉴定程序运行状况,以及显示系统交互,负载分布和其它类型的行为。在消除大量不必要的断点跟踪调试后,开发者便可判断出系统的瓶颈在哪里并加以解决。
TMS320DM644x SoC
分析器使用户花费时间解决问题而不仅仅是发现问题,作为一个完全的可视化分析工具,通过它用户可以得到诸如系统交互分析、各部分负荷分析、瓶颈分离、异常行为分析和应用的基准性能等功能。

当一个任务在DSPARM上同时运行时,分析器采集并显示数据,提供了对应用程序完全的系统可视化,消除了手工收集、对比数据的繁琐过程,如图一所示可视化分析流程。


图一 可视化分析流程

TI所实现的业界首创的图形系统可视化技术为数字视频系统设计带来了最大化的设计效率与性能,其多窗的图形界面极为友好,在同一图象上显示 ARM DSP 的任务运行情况,如图二所示。


图二,数据可视化工具界面

结语:实现集成新概念

现在用达芬奇技术搭建一个视频应用系统已经成为一件轻松愉快的事情,而集成的概念已经在小小的单片系统上展开。数字视频的开发人员首先需要搭建DSP的通用集成开发环境,然后利用业界首款优化的数字视频配置工具即可尽可能减小设计工作的复杂性,进而利用首款全面的图形系统可视化工具实现设计效率与性能的最大化。新技术和新手段的应用就可以这样一来全面简化数字视频系统的设计开发过程而获得更高层次的数字视频创新。

  评论这张
 
阅读(4166)| 评论(1)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018