DSP6446相关资料CMEM、DSPLINK(转)

CMEM是一个连续物理存储空间分配模块,使得ARM端Linux进程和DSP端算法之间能够共享缓冲区。当应用程序需要在共享缓存区动态申请一个连续的物理空间时,通过调用CMEM的API可以实现,申请得到的空间可以供DSP端访问,进行算法处理时数据的传递与处理。

在DVSDK中集成了CMEM模块,CMEM模块安装在Linux服务器下的路径为:/opt/dvevm_1_20/cmem_1_02;

在Linux服务器的控制台下,需进行如下操作实现编译:

Host # cd /opt/dvevm_1_20/cmem_1_02/packages/ti/sdo/linuxutils/cmem

Host # make all

Host #make install

运行后,即对cmem模块进行了编译,编译文件为在目录src/module下生成的cmem.ko模块,并将cmem.ko和测试文件安装到了目标板的/opt/nfs/opt/dvsdemos目录下。

DVSDK中的CMEM Demo提供了测试程序:apitest能够测试CMEM的API功能,translate能够测试虚拟地址与实物理地址之间的转换功能。

4.5.2DSPLink的配置与编译

为了适应嵌入式多媒体终端的内存尺寸,需要修改DSPLink的内存配置文件,使之使之支持64MB DDR的平台。

DSPLINK存储空间配置部分由一个TXT 文CFG_Davinci.TXT件定义实现,该文件在/opt/dvevm_1_20/dsplink_1_30_08_02/packages/dsplink/config/all目录下。

 

参考TI所推荐的64MB内存空间分配方案,如图4.3所示,配置CFG_Davinci.TXT文件如下:

1.找到[DSP0]标识下的RESUMEADDR将0x8FF00020修改为0x83F00020;将RESETVECTOR的0x8FF00000修改为0x83F00000;

2.找到MEMTABLE0标识,将其下的[0],[1],[2]所标识的段修改为如下内容:

[MEMTABLE0]

[0]

ENTRY |N| 0 #Entry number

ABBR |S | DSPLINKMEM #Abbreviation of the table name

ADDRDSPVIRTUAL |H| 0x83F00080 #DSP virtual address

ADDRPHYSICAL |H| 0x83F00080 #Physical address

SIZE |H| 0x000FFF80 #Size of the memory region

MAPINGPP |B| TRUE #Map in GPP address space

[/0]

[1]

ENTRY |N| 1 #Entry number

ABBR |S | RESETCTRL #Abbreviation of the table name

ADDRDSPVIRTUAL |H| 0x83F00000 #DSP virtual address

ADDRPHYSICAL |H| 0x83F00000 #Physical address

SIZE |H| 0x00000F80 #Size of the memory region

MAPINGPP |B| TRUE #Map in GPP address space

[/1]

[2]

ENTRY |N| 2 #Entry number

ABBR |S | DDR #Abbreviation of the table name

ADDRDSPVIRTUAL |H| 0x83C00000 #DSP virtual address

ADDRPHYSICAL |H| 0x83C00000 #Physical address

SIZE |H| 0x00300000 #Size of the memory region

MAPINGPP |B| TRUE #Map in GPP address space ?

[/2]

DSPLink的配置提供了一个交互的脚本,可以通过交互进行配置DSPLink的各个参数,如:平台选择,GPP OS的选择和DSPLink模块配置选择等,而配置完成产生配置文件保存。在完成DSPLink的配置后,就可以进行DSPLink和测试程序编译。

在DSPLink进行编译前,需要配置以下两个必须的环境变量:1.DSPLINK DSPLink的安装路径;2.PATH 添加编译脚本的路径至PATH中。然后通过在相应文件里执行make指令编译生成的DSPLink模块和示例程序的二进制文件,并可通过加载模块的方式加载DSPLink模块到Linux操作系统中。

DSPLink示例程序提供了LOOP、SCALE、READWRITE三个程序,可以用来测试DSPLink模块是否正确配置和加载。

第五章基于DaVinci平台的网络图像采集传输实现

5.1.1总体结构

在基于DM6446处理器的嵌入式多媒体终端上的网络图像采集传输总体结构如图5.1所示,共由4部分组成:

CCDC摄像机连接在嵌入式多媒体终端的视频输入口,DM6446处理器的ARM核负责图像信号的采集,通过在DSP核执行JPEG图像压缩的DSPServer即JPEG Codec combo以25f/s对图像数据进行压缩,并将输出的JPEG图像文件交给嵌入式多媒体终端的Linux文件系统。

利用DB9的串口线可以将嵌入式多媒体终端与PC相连,通过Windows的终端程序和DM6446处理器通信,就可以控制DM6446处理器、引导嵌入式多媒体终端和输入命令等。

路由器为嵌入式多媒体终端和客户端的提供基础的IP通信,客户端即可以嵌入式多媒体终端在同一局域网内,也可分别位于不同的网络,只要IP可达即可。客户端可以通过路由器访问嵌入式多媒体终端上的网关接口(CGI),并以Web方式显示已编码的JPEG图像文件。当客户端访问CGI程序时,嵌入式多媒体终端就将一些Java代码通过网络发送给客户端。在客户端利用接收到的Java代码编码JPEG图像文件,并在IE窗口显示。同时JPEG图像质量还可以通过在IE窗口中[0,100]之间的数字动态配置,1是最低和最高质量的压缩比,100是最高和最低质量的压缩比。

5.1.2软件结构

 

基于DM6446处理器的网络图像采集传输的软件结构如图5.2所示。运行在ARM上的HTTP服务器调用Linux网络堆栈,处理器HTTP的请求。网络堆栈调用EMAC驱动器,处理数据的发送和接收。

ARM上的应用程序通过系统调用访问视频采集模块的驱动,接收来自视频口的数据。视频模块采集的数据位于核空间,而应用程序位于用户空间,Linux应用程序不能直接看见核存储器的地址,所以应用程序需要使用mmap()的方式访问缓存里的数据。

视频口驱动将缓存器放入可以和DSP共享的物理地址空间。当ARM的应用程序通知DSP编码一个视频帧时,不需要将数据复制到DSP的地址空间。在CMEM的地址转换和共享内存管理下,可以很好的实现ARM处理器和DSP处理器的数据交互。

从ARM应用程序角度看,要求DSP编码一帧,或改变视频编码的质量,是调用VISA API,在API下还有如下三个任务要做:

1.使用VISA  API所指向的任何ARM及DSP共享缓存的指针,都必须转换为可以由DSP能够识别的。因为API的变量并不在ARM和DSP共享的存储器内,在复制到DSP存储器之前,需要进行配置。这些任务由ARM侧的Codec Engine来处理。

2.传递DSPLink驱动器处理ARM和DSP之间的消息。

3.API的变量和缓存器的指针一旦到达DSP,就要调用适当的Codec API,或激活一个DSP/BIOS任务。要求对一个新的帧编码,就要禁止Cache,迫使DSP核从片外存储器读入新的输入数据。这些任务由DSP侧的Codec Engine负责完成。

5.2图像采集与JPEG图像压缩

5.2.1图像采集

基于DM6446的嵌入式多媒体终端上的图像采集是通过ARM核Linux平台下调用Linux的第二代视频标准Video 4 Linux 2(V4L2)实现的。图像采集线程需要从图像采集驱动器开辟出一个帧缓存器,并用视频编码算法对其编码,并用一个写线程将已编码的帧写入Linux文件系统。使用专门的I/0线程,最大化ARM和DSP核的使用。图像采集程序主线程的流程如下:

1.检测视频标准:ioctl(FBIO_GETSTD);

2.解析命令行变量:parseArgs();

3.初始化Codec Engine:CERuntime_init();

4.建立写线程:pthread_create();

5.初始化采集设备:initCaptureDevice();

6.打开Codec Engine:Engine_open();

7.建立图像编码器:IMGENC_create();

8.编码数据写入缓存,允许写线程:Memory_contigAlloc();

9.进入主循环;

图像采集线程首先需要执行第1-4步必要的初始化任务,解析用户命令所提供的参数,根据命令行所提供的参数值,产生并设置图像线程的环境变量。

第5步用initCaptureDevice()这个V4L2的器件驱动初始化图像采集器件:首先用VIDIOC_S_INPUT设置用户所选择的输入连接器,设置图像为720x576的D1分辨率;然后由采集器件的驱动器,使用mmap()映射到用户空间的应用程序空间里。最后,使用VIDIOC_STREAMON开始采集器件驱动器里的图像采集。

第6步用Engine_open()建立一个Codec Engine实例,返回一个句柄供该Engine的JPEG算法的实例使用。使用同一个Engine的所有线程,需要各自不同的句柄,否则对Engine的访问不安全。

第7步使用IMGENC_create()调用静态参数,建立一个JPEG Codec实例,用于实时图像的压缩。

第8步写线程将已编码的帧写入Linux文件系统。之后可以通过开启HTTP服务实现基于Web的实时远程访问。

基于以上8步就完成了DaVinci平台上的图像采集的功能。

5.2.2JPEG图像压缩

DaVinci平台上的JPEG图像的压缩实现需要利用Codec Engine,通过VISA API调用DSP端运行的DSPServer实现。由于论文开发研制的嵌入式多媒体终端内存为64MB,而TI所提供的JPEG图像压缩的DSPServer即JPEG Codec combo是针对256MB内存平台配置编译的。所以需要研究DSPServer文件组成结构,利用XDC工具配置编译支持64MB内存的JPEG图像压缩的DSPServer。

JPEG图像压缩的DSP Server的构建,除了收集dmjpge_tigem.l64P和jpegdec_ti.l64P两个符合xDAIS和xDM标准的JPEG编解码的算法文件外,首先需要创建的是main.c和server的DSP BIOS配置文件.tcf文件和link.cmd。main.c函数最核心的代码是CERuntime_init(),即在DSP从复位状态释放后,初始化DSP Server的运行环境。此外在main.c函数中还可以打开Codec Engine的trace功能,读取过更改main.c函数的参数等。

DSP BIOS的配置文件.tcf中定义DSP的memory map、设置DSP的复位/中断向量表,并且创建和初始化BIOS程序需要的各种数据对象。为了使创建的DSP Server能够支持64MB内存的嵌入式多媒体终端,需要重新配置.tcf文件,并使其和DSPLink部分所分配的内存映射保持一致。其内存配置参数如下:

var mem_ext = [

{

    comment:    "DDRALGHEAP: off-chip memory for dynamic algmem allocation",

    name:       "DDRALGHEAP",

    base:       0x83800000,   // 56MB

    len:        0x00400000,   // 4MB

    space:      "code/data"

},

{

    comment:    "DDR: off-chip memory for application code and data",

    name:       "DDR",

    base:       0x83C00000,   // 60MB

    len:        0x00300000,   //   3MB

    space:      "code/data"

},

{

    comment:    "DSPLINK: off-chip memory reserved for DSPLINK code and data",

    name:       "DSPLINKMEM",

    base:       0x83F00080,   // 63MB+128B

    len:        0x000FFF80,   //   1MB-128B

    space:      "code/data"

},

{

    comment:    "RESET_VECTOR: off-chip memory for the reset vector table",

    name:       "RESET_VECTOR",

    base:       0x83F00000,  //63M

    len:        0x00000080,  //128B

    space:      "code/data"

},

];

此外在.tcf中我们只能定义编译器默认的sections(如.text和.bss等),但可以在link.cmd中定义自己的sections。

利用XDC工具构建DSPServer除了以上三个文件的创建和配置外,还需要package.bld、package.xdc和.cfg三个文件。在package.xdc中声明DSP Server的名字、它的路径及Server的依赖文件。package.bld文件的功能类似于Linux中的makefile,它告诉XDC如何build DSP Server的源文件;

DSPServer中的.cfg文件负责DSP的资源系统级的管理,包括CPU cycles、memory和DMA。针对Davinci上DSP的软件开发,TI提供了Framework Components来方便DSP软件工程师使用DSP的memory和DMA资源。xDM和xDAIS算法的Instance都向FC提出自己的资源请求,如请求1KByte的memory或一个DMA通道。FC中的DSKT2和DMAN3就通过标准的、可以配置的方法实现算法的instances资源分配。.cfg文件中可以做以下三个部分的配置:

1.Codec配置: JPEG图像的编码、解码器都被包含在各自的线程中,并 配置JPEG图像的编码、解码器线程的属性(线程优先级、堆栈大小和堆栈的memory资源)。

2. DSKT2配置:把所有的IALG memory类型结合到可用的DSP memory;定义缺省的scratch组的memory大小。

3. DMAN3配置:定义DMAN3可以管理的DMA通道号;定义DMAN3可以提供给算法的TCC号。

基于以上文件XDC即能够生成package.mak,并最终运行它来生成支持64M内存的JPEG图像DSPServer:JPEG Codec combo,以用于实现DaVinci平台双核处理器平台网络图像传输的JPEG图像压缩。

5.3网络图像传输

网络图像传输功能主要由嵌入式多媒体终端上的HTTP服务器和负责图像传输指令处理网关接口CGI两部分实现。运行于ARM核的HTTP服务器响应客户访问压缩图像的请求,由CGI负责处理,通过IP网络发送实时图像数据。

HTTP是客户端浏览器与Web服务器之间的应用层通信协议。HTTP包含命令和传输信息,可用于IP网络应用系统之间超文本信息的传输。基于DM6446处理器的嵌入式多媒体终端的HTTP服务器运行于ARM核的Linux操作系统上,且Linux Apache HTTP服务器已经和DM6446接口,并作为DVSDK的默认选项,所以只需对HTTP服务器进行配置,就可以支持网管接口CGI程序的运行。

网管接口CGI有simplearm­_pal.cgi和cfgquality_pal.cgi两个模块。其中simplearm­_pal.cgi负责处理客户端观看图像的请求,在当在客户端使用IE访问嵌入式多媒体终端时将HTML的内容输出到客户端,并通知IE下载和执行用于PAL格式JPEG图像解码的Java字节代码;cfgquality_pal.cgi负责处理客户端在当在客户端使用IE访问嵌入式多媒体终端时改变PAL格式的编码质量,它确认从用户端的输入,将有效的质量索引写给Qfile,并将HTML的内容输出给客户端。

在客户端,为了能正确解析和显示图像数据,需要安装Java运行环境JRE,以解码Java字节代码的PAL格式JPEG图像数据。

5.4图像网络实时传输系统构建

如图5.1图像采集与网络传输总体结构图所示,构建图像网络实时传输系统需要如下的硬件和软件:

1.嵌入式多媒体终端一台;

2.PC机一台或更多;

3.CCD摄像机一台;

4.路由器、交换机一台或更多;

5.网线若干、DB9串口线一根;

6.Java运行环境JRE;

7.PC机上的终端程序,如hyperterminal;

8.嵌入式多媒体终端Linux操作系统上运行的图像采集与网络传输应用程序。

嵌入式多媒体终端是整个系统的核心设备,是决定系统性能最关键的部分,负责实时图像的采集和压缩,通过HTTP服务使用户能够以Web方式访问实时的图像数据。

摄像头是视频采集系统的重要部件,直接影响采集到的视频质量。系统中使用的CCD摄像机,支持12倍自动变焦,采集到的画面干净、悦目,需要接在嵌入式多媒体终端的视频输入口上。

PC机在网络图像系统中的作用有两个:一是作为客户端以Web方式远程访问嵌入式多媒体终端所采集到的实时图像,需要安装Java运行环境JRE。物理上通过网线与嵌入式多媒体终端连接,要求IP可达即可。二是作为嵌入式多媒体终端的显示终端,通过DB9串口线与嵌入式多媒体终端相连接。物理上可以与系统客户端为同一台PC机,但要求与终端距离较近,因为RS232穿行通信协议不适于信号的远距离传输。

路由器和交换机组成了图像网络实时传输系统的基础通信网络,路由器、交换机的性能、数量、组网方式和网络QoS策略是决定系统性能的另一个重要因素。为了嵌入式多媒体终端上采集、传输软件的调试和优化,实时图像网络传输实现期间可将客户端与图像终端连在同一局域网,屏蔽网络传输质量对系统性能的影响。由于实际的网络是庞大而且复杂的,网络的服务质量将直接影响图像数据网络传输的质量。为了研究保证网络质量的QoS策略,搭建由三台路由器组成的实验网络,并将终端用于网络质量测试的工作,具体内容将在第六章详细介绍。

在完成软硬件的准备后,进行硬件连接:将CCD摄像机接到嵌入式多媒体终端的视频输入口;将PC机通过交换机接到嵌入式多媒体终端所在局域网;用DB9的串口线将PC机和嵌入式多媒体终端相连。

在PC机上启动超级终端,加电引导嵌入式多媒体终端Linux系统的启动。启动完成后,在超级终端中通过命令行的方式执行:开启HTTP服务器;运行RunTmp,允许应用程序将输入文件吸入RAM disk;向Linux内核导入DSPLink和CMEM模块;启动图像采集传输应用程序四步工作。

在安装了JRE的PC机上用IE访问URL:http://[嵌入式多媒体终端的IP地址]/jpegdemo/simplearm_pal.cgi,在PC机的IE窗口就可以观看到实时的网络图像了。在IE窗口中输入[1,100]范围内的书,可以实时的改变视频的质量。至此,便实现了基于DaVinci处理器TMS320DM6446的嵌入式多媒体终端上的图像网络实时传输系统的构建。

 

6.3.1实验背景

传统的IP网络对各种业务的报文采取了尽力而为BE(Best Effort)的传递方式,这种传递方式能够满足文件传输、浏览网页、电子邮件等对实时性要求不苛刻的业务。但对于要求低延迟、低延迟抖动等业务,例如实时的IP语音、电视会议、视频点播等,力而为的传递方式已不能满足人们的需求,人们无法忍受断断续续的语音和图像。为了在Internet上部署这些实时性的业务,就需要Internet的设备针对不同的业务提供同的服务质量QoS(Quality of Service)的能力。

为了在 IP 网络中提供QoS 保证,IETF 先后提出了两种体系结构:综合服务/资源预留(Intserv/RSVP)和区分服务。由于综合服务 要求为每一个单独的流在网络节点上预留资源,很容易导致路由器资源枯竭,扩展性差。而区分服务通过采用分组头DSCP标记的每一跳转发行为提供相对的QoS 保证,由于良好的扩展性和实现的简单性,区分服务已成为IP QoS 首选方式,可广泛应用于IP网络的网络质量的优化中。

6.3.4QoS策略部署方案

根据实验路由器所支持的QoS策略和实时视频数据的特点,在试验网络环境中根据区分服务模型设计部署了实时视频业务QoS策略。考虑实际网络中QoS策略部署的有效性和可行性,对三台路由器的QoS策略分别设计配置如下:

6.3.4.1核心路由器ZXR10简介及QoS策略部署方案

核心路由器两侧连接的都是汇聚路由器,因此QoS策略的功能主要是根据汇聚路由器标记的DSCP码点进行优先级队列的分配和区分转发,并对拥塞数据进行流量整形。

核心路由器QoS策略:

视频业务策略:

Classifier:基于DSCP码点的数据包分类

Behavior:将数据分配至优先级最高的队列优先转发

拥塞数据策略:

Classifier:基于DSCP码点的数据包分类

Behavior:将数据分配至优先级最低的队列尽力转发

6.3.4.2汇聚路由器S3610简介及QoS策略部署方案

汇聚路由器在网络中即与用户相连又和核心路由器相连,需要完成用户侧的数据分类标记、接入速率控制和核心路由器侧核心区分转发功能,具体配置如下

用户侧QoS策略:

视频数据策略:

Classifier:基于端口的数据包分类

Behavior: DSCP码点映射至EF

拥塞数据策略:

Classifier:基于端口的数据包分类

Behavior:car(接入速率控制)+DSCP码点映射至BE

核心路由器侧QoS策略:

视频数据策略:

Classifier:基于DSCP码点的数据包分类

Behavior:将数据分配至优先级最高的队列优先转发

拥塞数据策略:

Classifier:基于DSCP码点的数据包分类

Behavior:将数据分配至优先级最低的队列尽力转发+流量整形

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值