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：将数据分配至优先级最低的队列尽力转发+流量整形