基于数字基带处理器的多媒体应用处理方法及装置
技术领域
本发明涉及通信技术领域,具体涉及一种基于数字基带处理器(DSP)的多媒体应用处理方法及装置。
背景技术
随着移动通讯技术的发展,已经进入了一个移动带宽初步承载多媒体业务的时代,激烈的市场竞争促使移动多媒体业务势在必行。多媒体业务对终端的要求比传统业务对终端的要求高。根据下一代多媒体应用的要求,3G移动设备应支持各种多媒体应用,因此,在许多移动设备中,都会将DSP和通用或基于RISC的CPU这两种处理器组合起来,获得强大的处理能力,以此满足多媒体应用对处理能力的要求。这样,手机或PDA才能够以最低的功耗达到必要的处理性能。DSP不但可以用在这种需求量极大的通信处理应用中,还可用于实现许多新的多媒体应用,例如流媒体、话音识别、交互式游戏以及其它一些对数据处理能力要求较高的应用。
在移动通信终端系统中,对DSP运算性能要求高的处理主要有两个:其一,物理层的数字基带处理,主要包括信道编/译码(如卷积编码与viterbi译码,turbo编/译码),扩频调制/解扩,交织/解交织,TX/RX RRC滤波等;其二,应用层的多媒体应用处理,主要包括AMR语音编解码,MPEG4或者H.264视频编解码等信源编解码。现有的解决方案主要有两种:
(1)采用两片处理器,如图1中的“基带处理器”以及“应用处理器”,分别完成物理层与应用层的处理任务,这样需要多使用一块芯片,系统集成度低,产品成本高。
(2)采用一片处理器完成基带信号与应用层的处理,但是数字基带处理软件构架比较复杂,需要实现上层协议的部分功能(如MAC:Medium AccessControl的部分功能),这部分功能主要是完成逻辑信道和传输信道的映射(参见3GPP25.321),在应用层与物理层之间起着桥梁的作用,如图2的“基带-应用映射模块”。通常,位于“协议处理器”UMTS/GSM/GPRS proces sor中的高层协议栈(Protocol Stack)包含这部分功能;但是,图2中示出的解决方案,须将这部分功能从Protocol Stack中剥离出来,而且需要重新设计,该变动导致两块处理器之间增加更多的信令与数据交互,并且大大增加了数字基带处理软件设计的复杂度。
在解决方案(2)中,由于数字基带处理涉及3GPP的所有物理层过程,数字基带处理模块内部调度本身就很复杂;如果再考虑协议栈的部分功能,即:在物理层实现部分协议栈(如:MAC)的功能,系统就会更复杂,不但实现困难,模块划分不清晰,而且不易于升级维护,甚至会影响系统的稳定性。同时,在该方案下,处理纯12.2K语音以及多媒体语音流程复杂,语音数据的加解密流程复杂,产品的扩展性与移植性差,较难应用于不同的平台等。
发明内容
鉴于此,本发明所要解决的技术问题是提供一种基于数字基带DSP的多媒体应用处理方法及装置。采用本发明的方法及装置,将多媒体应用处理模块相对独立地镶嵌于基带处理器内部,数字基带处理软件模块不直接参与多媒体应用模块的控制,但多媒体应用模块占用基带处理器的资源,如Memory,BUS,MCU资源,以及操作系统(BIOS)等。
本发明所提供的一种基于数字基带DSP实现多媒体应用的方法,包括步骤:
a.在基带处理器内设立专用的数据与程序空间,供多媒体应用模块使用;
b.定义独立的多媒体应用处理任务,该任务使用独立的堆栈;
c.协议处理器(UMTS/GSM/GPRS Processor)根据多媒体数据流的处理需求,触发多媒体应用处理任务;
d.在基带处理器的控制下,统一调度多媒体应用处理任务;
e.根据预定的优先级执行多媒体应用处理任务。
在进行多媒体应用处理过程中,多媒体应用模块占用数字基带处理器的资源,所述资源包括内存、总线、处理器以及操作系统。
在进行多媒体应用处理过程中,包括将多媒体处理task添加到任务队列(task queue)中,并根据系统当前执行任务的优先级以及多媒体处理任务的优先级,安排执行多媒体应用处理任务。
在进行多媒体应用处理过程中,在下一个任务调度周期到来之前,当前的多媒体处理任务已完成。
根据本发明还提供一种基于数字基带DSP实现多媒体应用的装置,包括:
基带处理器,为多媒体业务处理模块提供独立的数据与程序存储空间;
协议处理器(UMTS/GSM/GPRS processor):根据多媒体数据流的处理需求,启动多媒体业务处理任务,用于执行协议栈与应用层软件。
多媒体处理模块:设置在数字基带处理器中,专用于处理多媒体业务数据;
其中在所述基带处理器内设立专用的数据与程序空间,供多媒体应用模块使用;
并在基带处理器内定义独立的多媒体应用处理任务,该任务使用独立的堆栈。
在进行多媒体应用处理过程中,多媒体应用模块占用基带处理器的资源,所述资源包括内存、总线、处理器以及操作系统。
在基带处理器内将多媒体处理任务添加到任务队列中,并根据系统当前执行任务的优先级以及多媒体处理任务的优先级,安排执行多媒体应用处理任务。
本发明将多媒体应用处理器设计为一个相对独立的功能模块,镶嵌于基带处理器(通常为DSP)内部,数字基带处理软件模块不直接参与多媒体应用模块的控制,但是多媒体应用模块占用基带处理器的资源,如Memory,BUS,MCU资源,以及操作系统(BIOS)等。使模块划分更清晰,软件架构实现更简单,易于扩展与移植,系统的集成度更低,同时降低了产品的成本,可以应用于低,中,高等各个档次的终端设备中。
附图说明
图1为现有技术的多媒体应用处理装置架构示意图;
图2为现有技术的另一种多媒体应用处理装置架构示意图;
图3为根据本发明的多媒体应用处理装置架构示意图;
图4为本发明的具体实施例的处理装置示意图;
图5为根据本发明的实施例的实现数字基带以及AMR处理任务的流程图。
具体实施方式
本发明将多媒体应用处理任务模块化,相对独立地嵌入基带处理器内,具体地说是在基带处理器内划分独立的程序以及数据存储空间给多媒体应用处理模块,并且定义独立的任务(Task),用于完成多媒体应用处理任务,从而在基带处理器内既进行数字基带处理,又完成多媒体应用处理,共享同一块处理器的MCU,总线以及操作系统(BIOS)等资源。
多媒体应用处理模块相对独立地嵌入基带处理器中,可适用于多种应用平台;
当多媒体应用处理模块的位置变更时,L3/L2/L1的实现无需做改动。由于多媒体应用处理模块相对独立,几乎不影响数字基带处理的软件构架;
处理不同业务时(如:纯语音业务和多媒体业务),L3/L2/L1的模块做到处理的一致性;
支持新的功能(如:加解密),而不影响接口和处理流程。
a.在基带处理器内设立专用的数据与程序空间,供多媒体应用模块使用;
b.定义独立的多媒体应用处理任务,在基带处理器内定义独立的多媒体应用处理任务(Task),并为该任务设立独立的堆栈;
c.协议处理器(UMTS/GSM/GPRS Processor)根据多媒体数据流的处理需求,触发多媒体应用处理任务,如:12.2K的话音触发AMR语音编解码,64K的数据业务触发MPEG4视频编解码等;
d.在基带处理器的控制下,统一调度多媒体应用处理任务,多媒体应用处理任务根据预先定义好的任务优先级别,由基带处理器的多任务调度系统(BIOS)统一安排。
e.根据预定的优先级执行多媒体应用处理任务。
多媒体应用处理任务优先级别的设定原则是,保证下一个任务调度周期到来之前,当前的多媒体处理任务能及时完成,以AMR语音编解码为例,这个任务周期一般为20ms。
多媒体应用处理任务调度,协议处理器UMTS/GSM/GPRS Processor根据多媒体数据流的处理需求,触发多媒体处理任务,基带处理器的多任务管理系统把多媒体处理任务添加到任务队列(task queue)中,根据系统当前执行任务的优先级以及多媒体处理任务的优先级,安排是否马上执行多媒体应用处理任务。当多媒体应用处理任务优先级高于当前执行的任务时,多媒体应用处理Task抢占当前的任务;如果当前的任务优先级别高于多媒体应用处理Task,则多媒体应用处理Task等待直到比自己优先级别高的任务完成才开始执行。在多媒体应用处理Task执行的过程中,允许被更高优先级别的任务抢占。高优先级别的task完成之后,多媒体应用处理任务重新获得MCU以及BUS等的使用权,继续执行。
为了保证多媒体应用处理的实时性,整个系统的任务划分,各个任务的优先级别设定需要全局考虑,优先级别高于多媒体应用处理的任务,要求及时处理,避免高优先级别的任务长时间独占系统的资源,影响整个系统的实时性。
图5示出了实现的流程图。参照图5,基于OMAP1610实现数字基带以及AMR处理任务的步骤如下:
(1)AMR codec软件处理模块的定义:
任务定义:在C55DSP内定义独立的AMR语音编解码处理任务,任务名称为Void AMRCodecTask();
堆栈定义:在该任务中开辟独立的堆栈unsigned intAMR_Stack[4000];
数据与程序空间定义:在share memory中定义unsigned intAMR_OutData[160*2],unsigned int AMR_InData[160*2],unsigned intAMR_ProgramMemory[10000];
优先级别定义:任务优先级别10(优先级别0-15,0:最高,15:最低)
(2)触发:AMR语音编解码的触发由ARM926发起,当12.2K的语音链路建立起来之后,ARM926以20ms为周期向C55DSP发送AMR codec RequestMailbox中断,DSP完成一帧的语音编解码之后以类似的方式,发送AMRcodec Complete Response Mailbox中断给ARM926。
(3)执行:C55DSP收到ARM926发来AMR codec Request Mailbox中断之后,把任务Void AMRCodecTask()添加到任务队列。BIOS操作系统判断,当前是否有比Priority=10的任务还高的任务,如果有(如Priority=2的任务),就等待;如果没有,就打断当前正在执行的低优先级别任务(如Priority=12),开始运行Void AMRCodecTask()。
(4)void AMRCodecTask()任务执行完之后,DSP发送一个response mailbox给通知ARM926,当前语音帧编解码完成,ARM926可以到share memory中读取数据结果。
(5)之后,BIOS回收对系统的控制权。
(6)当下一语音帧的数据到来,从上述步骤(2)开始,反复执行,直到语音通话结束。
上述实施例是用于说明和解释本发明的原理的。可以理解,本发明的具体实施方式不限于此。对于本领域技术人员而言,在不脱离本发明的实质和范围的前提下有多种实现方式。