基于ARM+DSP进行应用开发

　　针对当前应用的复杂性，SOC芯片更好能能满足应用和媒体的需求，集成众多接口，用ARM做为应用处理器进行多样化的应用开发和用户界面和接口，利用DSP进行算法加速，特别是媒体的编解码算法加速，既能够保持算法的灵活性，又能提供强大的处理能力。德州仪器（TI）继第一系列Davinci芯片DM644x之后，又陆续推出了DM643x，DM35x/36x，DM6467，OMAP35x，OMAPLx等一系列ARM＋DSP或ARM＋视频协处理器的多媒体处理器平台。众多有很强DSP开发经验的工程师，以及应用处理开发经验的工程师都转到使用达芬奇或OMAP平台上开发视频监控、视频会议及便携式多媒体终端等产品。基于ARM+DSP的芯片架构，如何进行开发实现做期望的嵌入式应用呢？

　　传统的芯片，基本是一个处理器内核，或者是通用处理器如ARM，或者是DSP。对于控制和用户接口，一般用通用处理器实现，算法处理或者媒体处理则依赖于DSP或者硬件芯片，很多系统都是双芯片的架构。开发模式也比较单纯，比如ARM芯片，有ARM的的仿真工具，基于OS之上进行应用开发；DSP有DSP的开发工具，如TI的CCS以及510、560的仿真器，可以进行算法的移植、优化、跟踪、调试等。这时，所需要的经验也比较单一。

　　基于ARM+DSP的双核架构，很多工程师不知道如何入手进行开发，提出了很多的疑问，比如对ARM工程师，很困惑的是如何使用DSP的资源？如何进行数据的交互？如何保持双核之间的同步？对DSP工程师，则问到如何进行ARM调试？如何启动DSP？如果进行媒体加速，如何操作外设获取或发送数据等。基于不同的开发经验和基础，ARM工程师和DSP工程师会从完全不同的角度来看SOC的芯片，以至于拿到SOC的芯片根本不知道如何入手，这里就本人的经验与大家分享一下。

　　首先ARM+DSP的芯片，他是一个双核的，对应ARM和DSP分别是不同的指令集和编译器，可以把SOC的芯片看成是两个单芯片的合成，需要两套不同的开发工具，CCS3.3可以进行芯片级的调试和仿真，但是对应ARM和DSP需要选择不同的平台。一般来说，ARM上面跑操作系统，比如Linux，Wince等，在ARM上的开发，除了bootloader以外，基本都是基于OS的开发，比如驱动，内核裁减，以及上层应用等，需要的调试和仿真主要靠log或者OS提供的调试器，如KGDB，Platform Builder等。基于DSP核的开发和传统单核DSP一样，需要用CCS+仿真器来进行开发调试。

　　其次，对于芯片的外设接口，ARM核和DSP核都可以访问，典型的情况是ARM控制所有的外设，通过OS上的驱动去控制和管理，这部分和传统的ARM芯片类似；DSP主要是进行算法加速，只是和memory打交道，为了保持芯片的资源管理的一致性，尽量避免由DSP去访问外设。当然，根据具体的应用需求，DSP也是可以控制外设接口进行数据的收发，这时，需要做好系统的管理，避免双核操作的冲突。 

　　对memory的使用，非易失的存储空间，比如NAND、NOR Flash，基本也是由ARM访问，DSP的算法代码作为ARM端OS文件系统的一个文件存在，通过应用程序进行DSP程序的下载和DSP芯片的控制。外部RAM空间，即DDR存储区，是ARM和DSP共享存在的，但是在系统设计的时候，需要把ARM和DSP使用的内存严格物理地址分开，以及预留出一部分用来交互的内存空间。一般情况，ARM是用低端地址，DSP通过CMD文件分配高端地址，中间预留部分空间用来做数据交互，比如在OMAP3的Linux下的DVSDK中，128MB的DDR空间被分成三部分，低端地址从0x8000000到0x85800000-1的88MB空间给Linux内核使用；从0x85800000到0x86800000-1的16MB给CMEM的驱动，用来做ARM和DSP的大块数据交互，从0x86800000到0x88000000-1的24MB是DSP的代码和数据空间。

　　芯片的启动也是需要重点考虑的问题，一般情况下，是ARM启动，和传统的单核ARM一样，支持不同的启动方式，比如可以支持NAND，NOR，UART，SPI，USB，PCI等接口启动。DSP默认处于复位状态，只有通过ARM的应用下载代码并且解除复位以后，DSP才能跑起来。有些应用场景，需要DSP直接从外部上电就自启动，有些芯片也是支持这种模式的。 
最后，关于芯片的通信和同步，这个是困扰很多工程师的问题，为了便于客户的开发和使用，TI提供了DSPLINK，CODEC ENGINE的DVSDK开发套件，基于DVSDK可以很方便的进行ARM+DSP的应用开发，下面对DVSDK的软件架构，各个软件模块的功能等做简要介绍。

　　DVSDK是多个软件模块的集成，包括纯DSP端的软件模块，ARM的软件模块和双核交互的软件模块。DVSDK的软件包都是基于实时软件模块（Real-Time-Software-Component：RTSC）的，还需要安装RTSC的工具XDC，XDC是TI开源的一个工具，可以支持跨平台的开发，能够最大程度的代码重用；如果需要进行纯ARM的开发，还需要ARM的编译工具以及Linux内核或者Wince的BSP；如果需要进行DSP的算法开发或者DSP端开执行代码生成，还需要安装DSP的编译器cgtools和DSP/BIOS；为了便于配置生成DSP端的可执行代码，通过向导生成Codec的RTSC包和可执行代码，还可以选装ceutils和cg_xml。

　　DVSDK的核心是Codec Engine，所有的其他软件模块基本都是围绕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的通信。关于Codec Engine的介绍，可以参考《帮您快速入门Codec Engine》。 

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

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

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

　　在ARM端，配合Codec Engine使用的软件模块有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的接口就可以了。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

1. DVSDK的安装与配置
>安装：linux下的操作，比较简单，只是要注意DVSDK的版本必须与DVEVM版本号一致。且最好把相关的DVSDK安装在dvevm_#_#_#下。
>配置：在dvevm_#_#_#目录下的Rules.make文件控制了大部分的编译行为，该文件被dvevm_#_#_#目录及其一些子目录下的Makefile文件所包含，对DSP端应用程序的编译需要修改相应的文件，具体根据你实际DVSDK软件包的安装路径。里面要求指定DVEVM、CE、XDAIS、DSP LINK、CMEM、codec server、RTSC、FC、DSP/BIOS、linux kernel等等包的路径。

2. DVTB的安装和使用
数字视频测试平台(DVTB)是不用C代码而直接利用一些脚本语言来测试DSP端算法的工具。在DVSDK安装后，会在dvevm_#_#_#目录下有个dvtb的目录，就在此执行安装，然后到DSP的可执行目录下去运行(DSP的可执行目录下必须要有cmemk.ko, dsplink.ko等文件)，如/nfshost/mydemos.
DVTB的命令语法如下：  
通过DVTB命令，可以控制audio/vpbe/bpfe等外设或各音视频编解码器，来完成一些测试工作。具体安装过程和命令使用方法可以参考：optdvevm_#_#_#dvtb_#_#目录下文档。暂时还没有用到。

3. XDC(Express DSP Component)的配置
XDC是用来编译和打包的工具，能够创建实时软件组件包RTSC(Real Time Software Component).与其他编译工具一样，它能根据源文件和库文件编译生成可执行文件。不同的是它能够自动的进行性能优化和版本控制。XDC还能够根据所提供的配置脚本语言产生代码，这一特性在编译如编解码器、服务器和引擎等可执行程序时尤为重要。
>XDC的调用语法格式： XDC
target files: 指编译产生的目标文件。可以通过命令脚本来指定要产生哪些目标文件;
XDCPTH:       编译时所要查找的目录;
XDCBUILDCFG: 由"config.bld"文件指定，包含了与平台有关的编译指令。后面细说。
以上命令模式可能在参数过多是很复杂，通常把它写成shell脚本来运行。

>与XDC相关的三个配置文件：
package.xdc: 主要包含与包package有关的信息：依赖信息、模块信息、版本信息。由自己提供。
package.bld: 主要作用是定义一个包应该如何被编译。文件内容用Javascript来描述。其中包含目标平台集的定义[MVArm9,Linux86]、编译版本的定义[release]、确定源文件集、生成的可执行文件信息等等。 这两个文件都是在server目录下，可见每个codec都有自己的package信息描述文件，然后XDC根据再依之生成一个package包。
config.bld: 这个文件处在codec_engine_##目录下，为各个codec所共有，它主要定义了与平台有关的特性，包含如下几部分：DSP Target、Arm Target、Linux Host Target、Build Targets、Pkg.attrs.Profile、Pkg.lib等具体信息。通常都是基于TI提供的模板对这三个配置文件做修改。

-----------------------------------------------------------------------------------------------------------------------------------

.xdc:
这个文件完成的工作很简单，就是定义servers包名，即servers目录下文件夹名称，这里用的video_copy,如果改成h264_dec,则只要相应的在这个文件中做修改，这是整个servers骨架包的名称。但是这个包名更改后，.bld文件下所有关于serverName的值及.tcf文件名都要做相应修改，否则会找不到编译对象。同时，ceapp.cfg文件中的myEngine.server的值也应修改成 ./h264_dec.x64P.

.bld:
这个文件里面定义编译对象时，如果对象的操作系统为'Linux',则什么都不做，这是因为Linux OS在这里不能做为host来进行远程codecs调用(我觉得就是因为这个原因才需要安装特定的montavista做OS). 另外，这里只限定了.tcf文件名必须是serverName，并没有限定.cfg文件的名称。这里平台和对象是在主目录的./user.bld中定义的。

.cfg:
这里指定使能某个codec可以使用dma。然后在codecs目录下的package.bld文件中不仅添加编译对象.c文件，而且可添加dma库(做法还有点疑问).