DM6437（精选四篇）
DM6437 篇1
DM6437是TI公司推出的、专门为高性能、低成本视频应用开发的、32位定点DSP达芬奇 (Davinci (TM) ) 技术的处理器系列。TMS320DM6437有着丰富的片上外设, 其中包括2个UART外设, 其中每个UART支持以下特性:16-tyte存储空间的传输和接收FIFOs、针对自动流控制和DMA的1, 4, 8或14byte可选的接收FIFO触发等级、中断优先、串口数据格式可编程等。除了DSP自带的硬件资源, 但想要有效利用DSP内部资源, 应用程序程序需要借助于BIOS。DSP/BIOS是一个多任务实时嵌入式操作系统 (RTOS) , 能大大方便用户编写多任务应用程序。DSP/BIOS实时操作系统的主要功能是:任务管理、存储管理等, 这里我们主要用到DSP/BIOS的任务管理。使用DSP/BIOS开发的DSP软件有两个重要特点:第一, 借助DSP/BIOS完成所有硬件相关操作。开发者不需要直接控制硬件资源, 而是通过CCS开发环境提供的图形化工具BIOS的配置文件;第二, 带有BIOS功能的程序在运行时与不带BIOS的程序是不同的。有BIOS控制DSP的程序, 应用程序是建立在以BIOS为基础上的, 程序根据BIOS调度下按照其安排的任务或者中断的优先级顺序进行执行。其中BIOS支持四种线程, 优先级顺序从低到高为:后台线程、普通任务, 软件中断, 硬件中断。其中这里需要用到硬件中断HWI。
2 串口通信
本文设计的UART通信部分软件程序设计未使用传统的芯片支持库, 而是直接对DM6437的UART外设寄存器进行初始化, 且利用DSP/BIOS实现UART硬件中断, 防止CPU轮询UART外设造成的计算开销浪费, 保证了数据传输的实时性和数据传输效率。
由于串口通信是异步的, 端口能够在一根线上发送数据同时在另一根线上接收数据。串口通信最重要的参数是波特率、数据位、停止位和奇偶校验。对于两个进行通信的端口, 这些参数必须匹配。其中:波特率:这是一个衡量通信速度的参数。它表示每秒钟传送的位的个数。这里我们使用波特率为:9600。数据位:这是衡量通信中实际数据位的参数。当计算机发送一个信息包, 实际的数据不会是8位的, 标准的值是6、7和8位。停止位:用于表示单个包的最后一位。典型的值为1, 1.5和2位。由于数据是在传输线上定时的, 并且每一个设备有其自己的时钟, 很可能在通信中两台设备间出现了小小的不同步。因此停止位不仅仅是表示传输的结束, 并且提供计算机校正时钟同步的机会。奇偶校验位:在串口通信中一种简单的检错方式。其中DM6437有2个UART外设, 这里使用的是RS-232串口接口。
3 DSP/BIOS中断
由于DM6437需要处理其他事务, 不能采用轮询等待串口数据, 所以必须采用中断方式来进行UART通信操作。如下流程图1所示。
而UART串口通信属于外部硬件中断, 需要在DSP/BIOS里任务管理进行硬件中断设置。C64+的中断系统与以往系列不同, 中断是基于事件的, 整个硬件CPU接收15个中断, 但中断源可以支持最多128个。C64+将中断源是为事件“Event”, 128个事件可以分别通过配置连接到15个CPU中断。而128个事件每连续32个可以合并到四个固定的事件中, 即Event0 (对应事件号0-31) 、Event1 (对应时间号32-63) 、Event2 (对应事件号64-95) , Event4 (对应时间号96-127) 。这样可以通过数量有限的CPU中断来管理超大量的中断源, 使用灵活。DSP/BIOS默认将Event0-3分别对应到HWI_INT7-10四个中断号。TI设备驱动通过注册Event0-3这四个事件, 进而对应到相应中断。在中断HWI_INT7-10中断服务程序再去判断具体是哪个事件触发的中断。而其他中断是系统硬件复位中断、NMI中断、预留中断及仿真通信中断。HWI_INT4-6、HWI_INT13、HWI_INT15这几个中断是未使用中断。我们可以通过将事件号对应到这5个中端, 并添加中断服务来实现中断控制。这里需要使用未使用中断完成UART中断方式通信。首先需要打开工程的TCF文档, 在任务调度部分中选择硬件中断HWI, 如图2所示。
选取HWI_INT4为我们需要中断, 并对其进行设置, 在中断事件栏中添加UART中断事件号85, 并接着添加中断服务函数名, 此中断服务程序即当中断产生时, CPU将停止当前正在执行的操作跳转到uart中断服务程序去执行。
4 UART中断
在使用UART中断之前需要初始化中断相关寄存器, 初始化CSR (Control and Status Register) 控制、状态寄存器, 开启全局中断开关, 此外还需设置DSP中的PINMUX0与PINMUX1。设置PINMUX是为了配置复用引脚工作模式, 并且通过IER (Interrupt Enable Register) 中断使能寄存器开启HWI_INT4的中断。接着需要初始化串口寄存器, 通过配置Divisor MSB Latch (DLH) 与Divisor LSB Latch (DLL) 将波特率设置为9600、配置FIFO Control Register (FCR) 清空接收数据FIFO与发送数据FIFO并使能接收与发送FIFO功能, 再配置Line Control Register (LCR) 寄存器设置数据位的长度。最后配置Power and Emulation Management Register (PWREMU_MGMT) 来使能串口接收与发送功能, 这些初始化部分在系统开启后进行。而在使用串口传输数据时, 需要解决中断嵌套导致程序跑飞的问题, 在这里需要在中断服务程序中开始时关闭中断HWI_INT4并在中断处理之后开启中断HWI_INT4。
5 结语
通过TMS320DM6437的UART模块并结合DSP/BIOS的中断管理部分实现了异步串口通信, 并通过软硬件调试, 该部分已经加入实际的实时监测系统中与外界上位机进行通信。采用中断的方式, 合理有效地使用了CPU资源, 取得了一定的效果, 具有一定的应用价值。
摘要：串口作为一种灵活、方便、可靠的通信方式, 广泛应用于计算机与其他嵌入式产品中以及工业控制系统中, 是计算机与外部设备进行数据通信时经常使用的方式之一。本文介绍在DM6437嵌入式DSP开发平台上, 串口通讯的一般步骤以及配置。主机通过发送命令可以实现调节或查询系统的功能或状态。结果表明, 在通讯速率要求不高的情况下, 利用串口命令可以有效的实现控制和查询DSP的功能和状态。
关键词：DM6437,UART,硬件中断
参考文献
[1]查萨英, 韩月秋.DSP原理及其C编程开发技术[M].北京:电子工业出版社, 2005.
[2]Taxas Instrument Incorporated.TMS320C6000 Programmer's Guide[Z].Taxas:Taxas Instrument Incorporated, 2002.
[3]Taxas Instrument Incorporated.TMS320C6000 CPU and Instruction Set[Z].Taxas:Taxas Instrument Incorporated, 2000.
[4]Taxas Instrument Incorporated.TMS320DM643x DMP Universal Asynchronous Receiver/Transmitter (UART) .Taxas:Taxas Instrument Incorporated, 2009.
[5]Taxas Instrument Incorporated.TMS320C6000 DSP/BIOS User’s Guide.Taxas:Taxas Instrument Incorporated, 2000.
[6]Taxas Instrument Incorporated.TMS320DM6437 Evaluation Module.Taxas:Taxas Instrument Incorporated, 2006.
DM6437 篇2
TI的达芬奇(Da Vinci)技术是一组专门为高效和引人注目的数字视频而设计的基于DSP的系统解决方案,适用于数码摄像机、视频安全设备、高级医疗成像设备、便携式视频播放器及其它视频应用。
Da Vinci技术包含:达芬奇软件、达芬奇开发工具/套件、达芬奇处理器、达芬奇支持。达芬奇(Da Vinci)技术与TI技术配合能使得开发数字视频应用变得更简单、更快速。Da Vinci技术提供了一个处理器、软件和开发工具完全集成的平台,该平台已针对数字视频应用进行优化,从而简化了设计,并能在更短时间内激发创新。现成的编解码器、集成的加速器、已发布的API和应用特定的框架使数字视频工程师能够专注于增值开发并借助新设计快速将产品投入市场。TMS320DM6437芯片就是达芬奇(Da Vinci)技术的杰出代表。
2 系统设计及工作原理
整个视频采集系统采用的是由达芬奇处理器(TMS320DM6437)、DDR2 SDRAM、FLASH、视频解码器TVP5146、电源管理芯片TPS54310,OPA361输出驱动芯片的方案。系统结构如图1所示。
视频解码器把CCD摄像头传过来的模拟视频信号进行模/数转换,变成符合ITU-BT.656标准的数字视频信号,然后将数字视频信号传到达芬奇处理器视频处理子系统的前端进行预处理,经过Codec Engine编解码后送到视频处理子系统的后端,经驱动后输出数字视频信号到显示终端上。
TMS320D6437内核构建在Veloci TI.2体系结构的基础上,是Veloci TI.2体系结构的进一步增强,以其DM6437内核的先进超长指令字(VLIW)结构,获得当前应用设备所需要的极高性能。在结构上其特点如下。
(1)DM6437片内有2个数据通道、8个功能单元和2个一般目的寄存器文件(A和B)。而8个功能单元和2个寄存器文件又分成了相同的两组,每组占用一个数据通道。两个数据通道之间包含有两个数据交叉通路。
(2)DM6437采用超长指令字(VLIW),即在每个时钟周期最高可提供8条32位指令,总字长为256位的指令包同时分配到8个并行处理单元。在600MHz的时钟频率下,当片内8个处理单元同时运行时,其最大处理能力可以达到4800MIPS。
(3)DM6437具有双16bit扩充功能,芯片能在一个周期内完成双16位的乘法、加减法、比较、移位等操作。DM6437通过把DSP运算压缩在较少的周期里,加速通信和图像应用。在增强并行性的扩展中,四组8位/两组16位指令允许每秒进行约90亿次8位乘法运算。
2.2 系统控制功能
TMS320DM6437微处理器的系统控制模块提供了看门狗(WT)、中断控制器、电源管理控制器、复位控制器及两个片上振荡器,DSP内核采用TI第3代超长指令集结构(Veloci TI.3),主频可达600MHz,支持8个8位或4个16位并行MAC运算,峰值处理能力高达4800MIPS,可实时处理8路CIF或3路D1格式的H.264编码算法。
2.3 视频处理子系统(VPSS)
TMS320DM6437中的视频处理子系统有两个接口,分别为用于视频输入的视频前端输入(VPFF)接口和用于图像输出的视频末端输出(VPBE)接口。
视频前端输入(VPFE)接口由1个CCD控制器(CCDC)、1个预处理器、柱状模块、自动曝光/白平衡/聚焦模块(H3A)和寄存器组成。CCD控制器可以与视频解码器、CMOS传感器或电荷耦合装置连接;预处理器是一个实时的图形处理器,它把CMOS或CCD得到的原始图形从RGB(三原色)转变为YUV4:2:0编码;柱状模块和H3A模块则提供原始图形信息。
视频末端输出(VPBE)接口由1个在线视频显示处理器(OSD)和1个视频编码器组成。在线视频显示处理器既能够显示两组独立的视频窗口或两组独立的OSD窗口,还可以以1个视频窗口、1个OSD窗口和1个属性窗口的形式显示。视频解码器以54MHz进行D/A转换,可以提供NTSC/PAL、S等格式的视频或音频输出。
2.4 电源管理
TMS320DM6437有三种电源管理模式:备用电源模式、低功耗运行模式和正常运行模式。备用电源模式下运行的功耗是最低的,DSP核和视频处理器子系统都不运行,除了通用I/O、UART和PWM运行以外,其他的外设都不运行,而且只有27MHz时钟工作。低功耗模式下,仅仅运行一些ARM的基本功能,DSP核和视频处理器子系统也都不运行,除了通用I/O、UART、PWM、SPI和定时器运行以外,其他的外设都不运行,而且也是只有27MHz时钟工作。正常运行模式下,除了所有的模块和外设都可以运行外,两个时钟也正常运行。
3 视频前端解码电路设计
TVP5146允许10路模拟视频输入,具有4路10bit 30MSPS A/D转换器;场同步信号VS、行同步信号HS、奇偶场信号FID、时钟输出信号DATACLK等都由引脚直接引出,省去同步时钟电路的设计[1,2]。视频前端解码电路图如图2所示。
4 视频后端驱动电路设计
OPA361是用于视频芯片的优秀高速放大器,它特别用于TI公司的嵌入式视频编码器OMAP2420处理器和达芬奇处理器或其他与0.5VPP视频输出应用处理器。它允许经过模数转换器的直流共模视频信号输入,从而驱动显示器等视频后端设备,其原理电路如图3所示。
5 电源设计
本设计采用的是最新的基于达芬奇技术的TMS320DM643x DSP的电源管理芯片TPS54310,在高达1.5A的最宽负载电流范围内可实现高性能的数控功能与效率最大化。在本设计中改变TPS54310外围电阻的阻值可输出1.8V、3.3V和1.2V电压。其中1.2V电压用于DM6437的内核供电;1.8V电压用于DM6437的存储器接口供电;3.3V电压用于DM6437的外设接口供电[3]。这样用3个电源管理芯片就能满足系统供电。输出为1.8V的电源管理芯片电路如图4所示。
6 总结
本文对达芬奇技术做了详细的介绍,并针对达芬奇技术的典型芯片进行介绍,以TMS320DM6437为核心设计了视频采集电路方案,对视频采集的前端数据采集和解码及视频后端驱动进行了设计,最后对电源的方案进行设计。本文的设计具有新颖实用和成本低的特点,相信会得到广泛的推广。
摘要：针对常规视频开发采用的ARM加DSP或双DSP复杂方案,采用一片DSP实现了视频采集系统的设计,具有开发简单,成本低的特点。
关键词：TMS320DM6437,TVP5416,视频采集
参考文献
[1]张琦,苏宛新.基于达芬奇技术的数字视频系统设计与实现[J].微计算机信息,2008(23):184-185.
[2]TI.TMS320DM642Video/imaging Fixed-Point Digital Signal Process[Z].2004.
DM6437 篇3
TI公司的TMS320DM6437(简称DM6437)是一款高性能的通用数字媒体处理器[1],属于TI公司的C64x+系列,主频可达400~700 MHz,峰值运算速率更是高达3 200~5 600 MI/s(兆指令/秒)。相对于TI公司的C64x系列DSP,在保持指令兼容性的同时,DM6437拥有自己独特的扩展指令集,而且拥有更大的cache配置容量和更为灵活的cache配置方式[2]。针对视频应用,DM6437还提供了强大的视频处理子系统(Video Processing Sub-System,VPSS)[3],其包括提供数字视频输入及预处理的视频处理前端(Video Processing Front End,VPFE)和提供数字视频输出及驱动显示设备的视频处理后端(Video Processing Back End,VPBE)。这一子系统提供的各种接口为视频的采集和显示处理提供了极大的便利。
DSP/BIOS是TI公司为了满足用户各种实时性应用的需求提供的一种尺寸可裁剪的实时操作系统内核[4],它为需要实时线程调度和同步、主机与DSP间通信或实时监测的应用而设计。DSP/BIOS提供了抢占式多线程、硬件抽象、实时分析和配置工具。通过使用DSP/BIOS提供的一系列丰富的内核服务,开发者能够快速创建满足实时要求的多任务应用程序。这些内核服务具有跨越C6000,C5000和C28x DSP平台的标准API接口,能被用户程序调用,易于移植。
H.264/AVC是视频编码专家组(ITU-T VCEG)和运动图像专家组(ISO/IEC MPEG)共同开发的新一代视频处理标准[5]。H.264标准具有如下特点:1)支持多尺寸块变换和多参考帧运动补偿,1/4像素精度运动搜索和基于上下文的算术编码和变长编码等高级特性,因此能够达到很好的压缩效率;2)把编码器框架分为VCL部分和NAL部分,VCL单元负责高效压缩视频,而NAL单元使压缩码流具有良好的网络适应性;3)支持冗余条带编码、数据分割,任意条带顺序等抗误码选项工具使得视频传输相对稳健。相对于以往的视频编码标准,H.264更加适合无线信道下高压缩率的应用场景。但它具有相当高的编码复杂度,实时编解码算法需要高性能专用集成电路(ASIC)或者DSP的支持。
2 系统结构
2.1 线程类型的选择
DSP/BIOS支持多种不同优先级的线程,包括硬件中断(HWI)、软件中断(SWI)、任务(TSK)、后台线程(IDL),每种线程类型都有不同的执行和抢占特性[4]。
根据系统需求,线程需要满足以下条件:
1)多个优先级,使初始化线程能够先于其他线程运行,完成系统初始化;
2)多种与其他线程共享数据的方式,根据需要共享数据的大小和类型,选择不同的方式在线程之间传递数据;
3)多种执行状态,需要任务具有阻塞状态以等待所需数据。
根据这些要求,本文选定任务(TSK)[4]实现系统的各个线程,通过多优先级的选择实现线程的依次执行,通过流、管道、邮箱实现多线程中各种不同性质数据的共享,通过信号灯和邮箱实现多线程的同步,TSK的这些特性完全可以满足系统对线程的各种需求。
2.2 系统的结构设计
视频系统的结构如图1所示。
根据系统需求,共设置了视频采集/显示(Video Capture/Display)、视频编码/解码(Video Encoder/Decoder)、网络初始化(Net Init)、服务质量(Qo S)、控制管理(Control&Management)等任务线程,每个线程完成其特定的功能,并根据系统的运行顺序设置不同的优先级,线程之间通过邮箱(MBX)、同步通信模块(SCOM)、共享存储空间等实现线程之间的同步、通信和数据传递。视频数据按以下顺序在系统中传递:
1)Video Capture TSK从视频采集设备(如CCD Camera)获取YUV 4∶2∶2的视频帧,对色度分量进行降采样后得到YUV 4∶2∶0数据;
2)YUV 4∶2∶0数据被送至H.264编码器,经过编码后得到编码后的比特流;
3)在Qo S TSK缓冲区不满的情况下,H.264比特流被送至Qo S TSK,进行组包;
4)Qo S TSK产生的固定长度的包送至CM TSK,在选定信道编码模式下进行信道编码,编码后数据送至网络,发送到接收端;
5)接收端收到足够的信道包后进行信道解码,得到固定长度的数据包;
6)数据包被送至Qo S TSK,拆包后形成H.264的比特流;
7)比特流送至H.264解码器后经过解码形成YUV4∶2∶0的视频数据帧;
8)Video Play TSK从解码器获得数据帧后对色度分量进行差值,得到YUV 4∶2∶2视频帧;
9)视频帧在输出显示设备上显示。
以上步骤实现了发送端采集编码视频、接收端解码显示视频的系统功能,并可以提供独立于信源采集编码的信道编码方式以满足不同网络条件的不同需求。
2.3 线程之间的通信和数据传输
2.3.1 邮箱(MBX)
MBX是DSP/BIOS提供的一种用于任务间传递消息的方式[4]。DSP/BIOS系统维护一个固定长度的共享邮箱来实现任务间的数据传递,可以保证信息流的输入不会超过系统处理这些信息的能力。
函数MBX_handle,MBX_create(msgsize,msglength,attris)[6]和Void MBX_delete(mbx)[6]分别用于动态地创建和删除邮箱,在创建邮箱时可以指定邮箱的长度和单个信息的大小。还可以在DSP/BIOS中静态的创建邮箱对象,并设置各种参数。函数Bool MBX_post(mbx,msg,timeout)[6]和Bool MBX_pend(mbx,msg,timeout)函数[6]则分别用于向邮箱中发布信息和从邮箱中读取信息。
但MBX存储的消息数量有限,而且每个消息的长度都较小(例如8 byte),所以MBX在系统中往往被用于信令的传递。在本文中,MBX用于在多个任务之间传递控制信令,信令的大小都不超过8 byte。
在本文中,共设置mbx_video_capture/player,mbx_videoencoder2Qo S,mbx_Qo S2videodecoder,mbx_Qo S2CM和mbx_CM2Qo S等MBX。其中,mbx_video_capture/player主要用于处理采集、显示端的缓冲区状态;mbx_video encoder2Qo S和mbx_Qo S2videodecoder主要用于协调Qo S任务与Video Encoder任务和Video Decoder任务执行顺序。在采集编码端,当Video Encoder任务产生H.264比特流后,通过邮箱mbx_videoencoder2Qo S通知Qo S任务对缓冲区中的数据进行处理。Qo S任务处理得到数据后,通过邮箱mbx_Qo S2CM通知CM任务,进行信道编码并通过网络发送数据。解码显示端的3个MBX起到的作用与采集编码端MBX的作用基本一致。
2.3.2 同步通信模块(SCOM)
SCOM是通过封装DSP/BIOS提供的信号灯(Semaphore)[4]和队列(Queue)[4]两种基本组件实现的,用于在多个线程之间通信的一种基本模块。一个任务通过调用SCOM_put Msg()函数将SCOM信息放置在一个SCOM队列中,发送给其他任务。目标任务通过SCOM_get Msg()函数从队列中获取消息。一般情况下,发送任务为需要传递的数据申请一定的空间,并将指向这一空间的指针封装在SCOM消息中,接收任务从SCOM消息中得到需要处理数据所在空间的地址,对数据进行处理。通过共享空间地址的模式,实现了数据在任务线程之间的高速传递,如图2所示。
本文中,在Video Capture和Video Encoder之间、Video Decoder和Video Display之间设置了2组SCOM信息。在采集编码端,Video Capture任务申请存储空间,将采集到的YUV数据放置在此存储空间内,然后将数据空间的指针通过SCOM信息发送至Video Encoder任务,Video Encoder任务通过指针直接访问YUV视频数据,进行H.264编码。这种指针的传递避免了较大量数据的复制,节省了任务线程之间数据传递的时间。
2.3.3 线程间的数据传递
通过SCOM模块,可以实现在2个任务线程之间快速传递大量数据的目的。但是为了适应不同的网络条件,有必要在Video Capture/Display和Qo S之间、Qo S和CM之间添加缓冲,使得下层网络条件的变化不会影响到编码器的正常运行,使任务之间尽量的独立。采用SCOM模块会增加任务线程之间的耦合度,所以在Video Capture/Display和Qo S之间、Qo S和CM之间传递大量数据时,需要考虑采用其他的方式。
任务线程之间最快的通信方式就是全局变量,因此在使用全局变量的基础上需要选择一种能够实现数据缓冲的数据结构,本文使用循环队列来实现线程间的大量数据传递,过程如图3所示。
在整个系统启动之初,为需要传输、缓冲数据的任务线程创建循环队列,并记录循环队列中的未使用队列和已使用队列的起始位置,每个队列元素中包括一个指向已申请好的空间的指针,如图3所示。队列的具体使用描述如下:在产生数据的任务线程产生数据前,获得未使用队列的第一个队列元素中的空间地址指针,将产生的数据放置在这一空间后,将这一队列元素标记为已使用,更新循环队列的未使用队列的起始位置;使用数据的任务线程执行时,根据已使用队列的第一个队列元素中的地址指针获得需要的数据,对数据进行处理后,将队列元素标记为未使用,更新循环队列中的未使用队列的起始位置。
通过循环队列和指针传递,直接使用地址对数据进行访问,既避免了大量数据在任务线程之间的复制,又可以使数据的传递独立于2个任务线程,提高各个模块的可移植性。此外,还可以在一定程度上缓解不同任务线程之间数据处理速度不同造成的匹配问题,对网络条件的变化也具有了更好的适用性。
2.4 线程的调度(图4)
采集显示端的运算复杂度很高,H.264编码器的编码速度严重限制了系统采集编码端的运行速度,因此在线程调度中应以H.264编码器为核心,合理调整其他线程与编码线程之间的速度关系,才能实现采集编码端的高效运行。
采集编码端的调度流程如图4a所示,描述如下:
1)具有高优先级的Net Init TSK[7]首先运行,完成网络的初始化;
2)Video Capture TSK开始循环运行,采集视频数据完成后,通过SCOM消息将视频数据地址传送至Video Encoder TSK,Video Capture TSK进入阻塞状态;
3)Video Encoder TSK在接收到Video Capture TSK的SCOM消息后,从阻塞态进入执行态,根据SCOM信息提供的地址访问视频数据,并完成H.264编码,将编码数据放入Video Encoder TSK和Qo S TSK之间的缓冲区(如果该缓冲区未满),并通过MBX消息向Qo S TSK传递信令,同时通过SCOM消息通知Video Capture线程编码完成;
4)Qo S TSK循环运行,在收到Video Encoder TSK的MBX消息后开始从缓冲区中取得数据进行组包,组包后数据放入Qo S TSK和C&M TSK之间的缓冲区(如果该缓冲区未满),通过MBX消息通知C&M TSK,并将Video Encoder TSK和Qo S TSK之间缓冲区状态返回至Video Capture TSK;
5)C&M TSK循环运行,在收到Qo S TSK的MBX消息后开始从缓冲区中取得数据进行信道编码,信道编码后数据通过网络接口进行发送,并将Qo S TSK与C&M TSK之间状态报告Video Capture TSK;
6)在2个缓冲区状态都未满的情况下,Video Capture TSK采集数据,重复2)~6)。
整个系统的速度不仅取决于每个模块的速度,更取决于模块之间能否合理地调度运行。因此,在设计线程调度时就应该合理设置线程之间的依赖关系,实现线程之间的协调工作。系统的解码显示端运算复杂度较低,而且运行逻辑相对简单,调度关系如图4b所示。
3 系统的改进和优化
经过以上的设计,整个系统可以在多种网络条件下运行,在一端对数据进行采集和编码,在另一端实现视频的解码和显示,实现了系统在设计之初提出的功能要求。但是仅仅实现功能是远远不够的,系统在实现之初的运行速度是很慢的,无法显示视频的流畅采集显示,所以要通过各种方式实现系统性能的优化,以实现较好的系统性能。
为了衡量系统的运行速度,笔者对系统进行部分修改,将采集端的采集部分修改为读取标准序列文件,系统自环运行(系统同时完成编码端和解码端的所有功能),选择典型测试序列foreman(352×288)的前25帧进行测试,码率为200 kbit/s。
主要在以下几个方面进行系统优化:
1)线程调度的调整。合理地匹配各个线程的运行速度对系统性能的提高是有很大帮助的。例如,在系统设计之初,采集编码端的线程也是依次顺序运行的,这样的调度结构虽然简洁清晰,但是在某一线程需要等待数据时(比如采集线程获取数据时)其他线程也需要等待,这就拖慢了系统的运行速度。将调度结构按照第2.4节进行调整后,在某一线程等待数据的过程中,其他线程运行,这一方式提高了整个系统的运行速度。
2)编译器优化。通过合理选择CCS编译器提供的编译选项提高系统的性能,性能如表1所示。MI·s-1表示兆指令/秒。
3)空间结构的调整。例如,DM6437提供了多种速度不同的存储空间[2],合理地设置空间的使用方式可以提高系统的运行速度。在所有线程中,H.264编/解码器占用了系统运算量的75%以上,因此在安排整个系统的空间时,着重考虑了编码器和解码器的空间需求。经过对编码器/解码器结构和数据大小的分析以及不断的时间分析,笔者选定如下的存储空间设置:L1P存储空间全部配置为cache,大小为32 kbyte;L1D存储空间48 kbyte配置成为内部数据存储空间,32 kbyte配置成为数据cache;L2存储空间32 kbyte配置成cache(程序cache或者数据cache),剩余96 kbyte设置为数据存储空间。在内部存储空间中主要放置编解码需要频繁使用的数据以及全局变量。经过以上的设置,编解码器相对于所有数据放置在片外的情况,速度提高了约20%,系统性能如表2所示。
4)汇编优化。在合理配置空间的基础上,还可以将编解码器中调用次数较多、运算量较大的函数用线性汇编实现。通过线性汇编的编写,在编解码器运行速度上还可以获得约10%的提高。
经过以上的各种优化方法,可以使系统运行在一个可以接受的速度上,实验结果如表3所示。
DM6437的主频按照600 MHz来计算,可得系统自环的运行速度为12.46 f/s(帧/秒),如果系统单独作为发送端或接收端运行,运行速度都可以基本达到25 f/s的实时性要求。
4 小结
笔者通过系统框架设计完成了系统的架构,通过线程的设计和实现完成了系统线程的设置和调度,通过各种优化方式实现了系统运行速度的优化,最终基本实现了基于DM6437视频系统的实时运行。根据对系统实际运行数据的分析,也找到了系统运行速度的主要瓶颈,为进一步的优化工作打下了基础。接下来的工作中将进一步优化系统运行速度,完善系统功能,以实现更高分辨力、更高码率的实时通信。
摘要：针对TI公司芯片TMS320DM6437硬件平台,在开源编码器X264基础上,基于TI公司提供的DSP/BIOS系统,实现了多线程,具有视频采集、编码、传输、解码和显示功能的视频系统。实验结果表明,通过DSP/BIOS的实时可伸缩性内核,合理设置各个任务线程之间的通信和调度机制,并利用实时分析和配置工具,合理配置代码和数据空间,可以实现整个系统的高速运行,并可以大大缩短系统的开发时间。
关键词：TMS320DM6437,DSP/BIOS,编码器,多线程
参考文献
[1]Texas Instruments.TMS320 DSP/BIOS V5.41 user's guide[EB/OL].[2010-01-20].http://focus.ti.com/lit/ug/spru423h/spru423h.pdf.
[2]Texas Instrument.TMS320C64x DSP two level internal memoryreference guide[EB/OL].[2010-01-20].http://focus.ti.com/lit/ug/spru610c/spru610c.pdf
[3]Texas Instruments.TMS320DM6437 digital media processor[EB/OL].[2010-01-20].http://focus.ti.com/lit/ds/sprs345d/sprs345d.pdf.
[4]Texas Instruments.TMS320 DSP/BIOS V5.41 user's guide[EB/OL].[2010-01-20].http://focus.ti.com/lit/ug/spru423h/spru423h.pdf.
[5]JVT of ISO/IEC and ITU-T.ITU-T recommendation H.264——ISO/IEC 14496-10 AVC.[EB/OL].[2010-01-20].http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52974.
[6]Texas Instrument.TMS320C6000 DSP/BIOS 4.90 application program-ming Interface(API)reference guide[EB/OL].[2010-01-20].http://focus.ti.com/lit/ug/spru403g/spru403g.pdf.
DM6437 篇4
除了数字视频编码标准外, 具备可以实时处理大量视频数据的硬件则是网络视频服务器必不可少的。作为可以编程的多媒体处理器, DSP (Digital Signal Processor, 数字信号处理器) 由于其灵活性高和处理能力强的特点, 很快就成为网络视频服务器的首选硬件。由此可见, 通过将高性能的DSP多媒体处理器和H.264/AVC编解码技术相结合, 以实现对视频的高效压缩, 将会是网络视频服务器应用中必不可少的软硬件支持[3]。
1 X264在DM6437上的移植
通常在C6000代码开发中有3个阶段:写线性汇编阶段、编写C/C++代码阶段和优化C/C++代码性能阶段[4]。在VS2010环境下对X264代码进行适当精简即可通过编译, 但要在CCS软件中顺利运行并完成DSP开发还需要经过如下步骤。
1.1 编译单个C文件
首先, 在CCS3.3软件中, 创建1个名为H264.pjt的DSP工程。把需要用到的C文件添加到该工程中, 即精简后的X264代码。通常都是在VC平台对X264源码进行编译的, 其库函数与头文件在Windows系统下是支持的, 但若要在DSP上运行, 与VC同名的头文件和函数在CCS环境中可能不存在, 继而会在代码编译时产生许多数据类型、函数无法被识别和找不到头文件的错误。所以必须对源码中的库函数进行修改, 详细步骤如下。
1) 如果没有找到可以代替的函数, 则需改写代码。
2) 若在头文件中存在CCS软件所不支持的库函数, 则删除掉。
3) 由于CCS软件仅与ANSIC代码兼容, 因此有必要修改部分非标准的C代码, 将其改写成可以兼容CCS软件的代码。
4) 首先, 尽量使用新加入的库函数去替换掉源码中的函数。其次, 进行改写和删减源代码。在X264源代码中可以对各条指令进行解析, 而在DSP上运行时H.264编码器无需与电脑进行通信, 即可在函数内对指令中涉及的参数直接进行配置。所以可删除源码中的函数static int Parse (x264_param_t*param, cli_opt_t*opt) , 并在主函数中加上下述代码:
在VC平台下编译的X264中还存在许多计算模块及信息显示程序。在单片机上运行时无需显示这些信息, 所以上述模块都是可以删除的。
1.2 分配存储空间
堆 (heap) 和栈 (Stack) 的合理分配是在移植时需要特别留意的问题。堆主要用于动态存储器分配, 栈则用来保存地址和局部变量。在VC平台中堆栈可以由操作系统自动分配管理, 而在单片机中则需要自己设置。
两级缓存构成了DM6437中的片上存储空间, 他们分别是大小为112 KB的一级片内存储器和128 KB的二级片内存储器。这两级缓存结构又与单片机采用的片外RAM共同组成了一个三级存储器结构, 见图1。
在DM6437对数据进行访问时首先要获取L1中的信息, 若其存在则从L1中直接取得信息, 否则访问二级缓存L2;如果此信息在L2中也没有, 就利用EMIF接口进入片外RAM, 并把信息从片外RAM依次复制到L2和L1中。
对DM6437的三级缓存机制进行合理的分配, 目的是为了提升单片机内核数据的读取效率。将需要持续使用的函数放置在连续的内存空间中, 对二级缓存L2以组合的形式进行配置, 最后把经常使用的数据和代码置于L2 SRAM中, 通常这些数据大多为原始宏块数据、离散余弦变换后以及量化后的系数等。
1.3 DSP/BIOS配置
通常情况下, 执行捕获、处理以及输出等这些任务是通过视频编码硬件进行处理的, 对于开发者来说, 实时维护如此巨大的系统是非常困难的。如同步视频、共享数据以及管理多通道, 这些都需要通过DSP/BIOS这样一个多任务管理操作系统来执行。软件开发人员只需将其固化于BIOS的相关配置中, BIOS就会帮你完成任务函数之间的调度[4,5]。
在CCS平台中DSP/BIOS是核心部分, 其主要包含配置DSP/BIOS的工具和基于DSP/BIOS内核的API函数两大模块。首先, 在CCS软件中需新建一个配置文件, 单击DSP/BIOS Configurtion选项后, 弹出一个窗口, 见图2。在这里, 选择其中的ti.platforms.evm DM6437作为配置模板。
然后, 为了正确编译整个工程, 需要添加一个.cmd文件。在配置界面中, 需要设置Cache分配、时钟配置文件的属性, 以及对任务模块和MEM模块的属性进行修改。在配置文件中, 主要是配置MEM模块, 在程序中依据需求建立大小适中的Heap, 并确定在Heap中放置数据还是代码。根据需要把Memory Section Manager中的各个段放在片外或者片内, 先将数据和程序都放在片外DDR2中, 然后把一些使用频繁的数据和程序陆续放置在片内SRAM中。保存设置并命名为DM6437.tcf。接着把该文件加入到项目中, 则DM6437cfq_c.c和DM6437cfg.s62就会被Generated Files陆续添加到其中, 在项目中添加CCS软件所生成的DM6437cfg.cmd文件。接下来就可以编译工程文件, 并生成.out文件。
2 在DM6437S平台下对X264的优化
2.1 编译器选项优化
CCS3.3软件中的C编译器拥有十分好的优化性能, 而编译选项则决定着编译器的优化过程和优化级别, 通过使用恰当的编译选项能够产生效率更高、尺寸更小的汇编代码[6,7]。
在CCS软件中, 大量的优化工具给用户提供了界面优化编译选项, 而且大多数是在改进音视频编解码算法, 使用者能够依据所需自行组合出合适的配置方案。文中使用的优化选项见表1。
通过采用这些配置可提升2~3倍的效率。相关设置见图3。
2.2 C语言级优化
通常是把利用部分源码的设计技巧以提升编码效率作为进行C语言级优化的主要方法, 相关步骤如下。
1) 通过移位取代乘除, 位运行取代求余, 能够减少运行指令的时间。
2) 采用尽可能小的数据类型以便于单指令的多数据运行。如把程序中的长整型换为整型, 不但浪费了DSP的内部寄存器, 而且大大减少了内核的运行效率[8]。
3) 在switch语句中把使用概率高的列在前面, 可减少运行时的查找判断时间。
4) 为了避免浪费调用时参数入栈和出栈的时间, 要尽可能的采用全局变量以减少参数不必要的传递调用。
5) 优化C语言的循环运行, 尽量提升程序运行效率。
6) 在声明静态函数中利用关键字static, 进行inline改进。
2.3 汇编级优化
为了可以显著增加代码运行效率, 应用汇编语言对源码中耗时较大的算法进行修改, 然后对其进行优化。然而, 由于CPU寄存器采用并行汇编十分困难, 所以TI为了简化C6000汇编程序的开发流程而提供了一个专用的线性汇编语言。
线性汇编语言仍和汇编语言采用相同的格式, 通过助记符的形式以实现指令名, 是常用的伪指令描述, 见表2。
最后利用代码剖析工具Profiler找到在编码中时间耗费最多的函数代码, 并将其用线性汇编逐个替换修改。
3 实验结果
通过以上过程的优化调整, 在经过DM6437对CIF格式原始视频的编码后, 生成的视频文件传输到电脑中, 同时对输出码流进行验证以确保其正确。测试的对象为YUV视频序列akiyo.qcif和foreman.qcif, 视频大小均为11 138 KB, 帧数为300。下面是对两个视频序列分别进行编码测试的结果。表3对比了优化前后编码速度, 第54页图4截取部分视频显示了优化后的效果。
通过实验结果可以看出, 经过上述阶段的优化调整后, 其编码速率相比之前有了显著的提升, 同时编码结果也具有较好的视觉效果。
4 结束语
文中以X264源码为核心, 通过在电脑上的精简和改写将其运行在单片机DM6437上, 最终经过多阶段的优化调整, 顺利实现了H.264编码器在DM6437环境下的运行, 从各类评价指标可以看出视频编码结果具有较好的质量。
摘要：H.264视频压缩标准是在2003年由联合视频组 (JVT) 开发的新一代视频编码标准。通过对H.264编码算法的系统分析, 在DM6437开发环境中对H.264编码器进行了移植与优化, 获得了质量和效率较高的视频编码图像。
关键词：视频编码,H.264,DM6437
参考文献
[l]林福宗.多媒体技术基础[M].北京:清华大学出版社, 2002:14-15.
[2]王汇源.数字图像通信原理与技术[M].北京:国防工业出版社, 2000.
[3]卞红雨, 纪祥春, 乔钢.TMS320C6000系列DSP的CPU与外设[M].北京:清华大学出版社, 2007.
[4]罗了平.基于Tl达芬奇平台H.264编码器的研究与实现[D].成都:西华大学, 2010.
[5]宋磊.H.264视频编码算法在TI DM642平台上的实现与优化[D].上海:上海交通大学, 2007
[6]张晓明.基于TMS320DM642的H.264编码器优化[D].北京:北京邮电大学, 2010.
[7]延瑾瑜.基于TMS320DM6437的H.264视频编码器的研究与优化[D].北京:北京化工大学, 2009.