双核处理器ARM+DSP如何实现协同工作(2)

DVSDK的核心是CodecEngine,所有的其他软件模块基本都是围绕Codec Engine的。Codec Engine是连接ARM和DSP的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块,在编译DSP端可执行代码和ARM端应用程序时,都需要Codec Engine的支持。Codec Engine主要有两部分:

 ARM端应用适配层,提供了精简的API和对应的库给应用层使用。

 DSP的算法调用层,提供了DSP算法的接口封装规范,是的所有的算法通过简单的配置就可以编译到DSP的可执行程序中。

最终的应用程序需要通过Codec Engine的API接口来下载DSP代码,调用DSP端的封装好的算法,以及进行ARM和DSP的通信。

关于CodecEngine的介绍,可以参考《帮您快速入门Codec Engine》。

Codec Engine底层ARM和DSP的通信是建立在DSP/BIOSLink之上的,DSP/BIOSLink真正实现ARM和DSP交互的软件模块。由于DSP/BIOS Link是跨平台的,也是有ARM部分和DSP部分组成,其中在ARM端,包括基于OS的驱动和供应用调用的库文件,DSP端,必须要用DSP/BIOS,DSP的可执行代码需要包含DSP/BIOSLink的库文件。DSP/BIOSLink常用的主要有如下几部分的软件模块:

   PROC相关的,主要是用来做DSP芯片的控制,比如启动,停止等,下载DSP的可执行代码,以及直接读写DSP端的memory空间等

   MSGQ相关,ARM和DSP的通信是基于MSGQ的,MSGQ有轮询等待的方式或者中断的方式,MSG是基于共享内存池的方式。Codec Engine通过MSGQ交互一些关键数据,比如控制,和一些大块数据的地址指针等。大量的数据交互需要通过cmem实现。

在ARM端,配合CodecEngine使用的软件模块有LinuxUtils或者WinceUtils,包含cmem,SDMA等,cmem是用来在OS之外分配连续物理内存空间,进行物理地址到虚地址,以及虚地址到物理地址空间转化的。为了避免数据的多次复制,需要开辟一块ARM和DSP共享的数据空间,ARM和DSP都可以直接访问,这部分空间需要通过CMEM管理。对ARM来说,CMEM是OS上的一个驱动程序,需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间,通过ARM传给DSP的指针必须是物理地址。

为了适配一些播放器的接口,DVSDK还提供了DMAI(Digital Media Application Interface),DMAI提供了更为精简的媒体接口和基于OS的音视频捕捉、回放等接口,在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。并且DMAI也提供了最基本的测试应用例子,可以很方便的进行修改和测试。

如果只是调用现成的或者第三方的算法库,可以只了解ARM端的软件模块,Codec Engine或者DMAI已经提供了丰富的应用接口,DSP可以认为是个单纯的媒体加速器,把ARM+DSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能,就需要对DSP进行开发了。Codec Engine对DSP的算法只是规范了接口,以便于和Codec Engine一起生成DSP的可执行程序。

开发DSP算法的工程师,和传统的单核的DSP开发模式类似,只需要操作DSP核,基于CCS进行算法开发,最后封装成xDM的接口就可以了。具体如何进行DSP的打包,如何生成DSP的可执行程序,在后续的文章继续讨论。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wwwfwz.html