基于OMAP3530硬件平台的ARM和DSP协同开发方法

摘  要： 以OMAP3530为硬件平台，以DVSDK为软件工具，介绍了协同开发环境的搭建方法。说明了OMAP3530中ARM和DSP协同开发的两种方法，并对两种方法的优缺点进行了比较。
关键词： OMAP3530；ARM；DSP；DVSDK；Codec Engine

目前市场上有良好控制功能的处理器很多，但是这些处理器大多在数据处理能力方面略显不足。因此，美国德州仪器(TI)公司于2009推出了一款多核处理器OMAP3530，它采用了600 MHz ARM Cortex-A8内核与420 MHz TMS320C64+TM DSP双核结构[1-2]。由于ARM在工业控制方面具有很大的优势以及DSP具有良好的数据处理能力，所以OMAP3530在嵌入式系统的应用开发方面有着广泛的应用前景和技术潜力。
    要使OMAP3530发挥ARM+DSP双核架构的优势，必须要使ARM和DSP协同工作。目前关于如何使ARM和DSP协同工作的参考资料不多，因此本文在研究实践的基础上，就如何搭建协同开发环境以及ARM和DSP协同开发方法进行了说明。
1 开发环境的搭建
1.1 PC端系统的搭建
    OMAP3530几乎支持所有嵌入式操作系统(例如WinCE、Symbian OS、EPOC、Linux等)，由于大部分嵌入式操作系统都要收费，所以这里采用Linux系统，它不仅应用广泛，而且免费和开源。
    为了能够开发OMAP3530，首先要搭建开发环境，在PC端，需要安装虚拟机VMware Workstation，配置超级终端；然后在虚拟机上安装Linux操作系统。除此之外，还需要在Linux系统上安装交叉编译器、NFS服务器、FTP服务器等一些必要的开发工具。
1.2 OMAP3530系统启动方式及分析
    OMAP3530上运行的Linux系统的组成结构如图1所示。其中，x-loader是一级引导程序，主要作用是初始化CPU和拷贝u-boot到内存中运行[3]，然后把控制权交给u-boot。u-boot为二级引导程序，主要用于与用户进行交互，以及提供镜像更新、引导内核等功能。kernel为Linux内核，是操作系统的核心，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。rootfs为根文件系统，在嵌入式Linux操作系统中，文件系统作为操作系统的重要组成部分，用于控制对数据文件及设备的存取，并提供对文件和目录的分层组织形式、数据缓冲以及对文件存取权限的控制。根文件系统是Linux系统不可或缺的组件，在嵌入式Linux中，内核在启动期间，必须调用根文件系统才能启动。Linux系统将自身划分为两部分，一部分为核心软件，即kernel(也称作内核空间)；另一部分为普通应用程序，这部分称为用户空间（user area）。

可以通过配置及编译x-loader、u-boot、kernel、busybox源码文件来获得OMAP3530所需的镜像文件，然后把镜像文件拷贝进SD卡，这样就可通过SD卡启动Linux系统。
    为了便于开发，通常使用交叉网线连接PC和OMAP3530开发板，然后通过由NFS挂载根文件系统的方法来启动Linux系统。该方法的好处是能直接在虚拟机中修改OMAP3530端Linux的文件系统，就可以直接在PC上开发OMAP3530端的程序。
2 搭建ARM与DSP之间的桥梁
2.1 DVSDK简介
    为了使ARM与DSP建立连接，TI公司推出了DVSDK(Digital Video Software Development Kit)软件开发包，它集成了多种软件工具，包括支持独立DSP处理器和ARM处理器组件以及双核系统交互组件，各个组件之间紧密联系，形成了完整的开发套件[4-5]。DVSDK部分软件模块介绍如下。
    (1)DSP/BIOS for Linux：是一个可扩缩的实时DSP核，可以理解为在DSP端独立运行的实时系统。
    (2)TI Codegen Tools for Linux：是Linux环境下DSP程序的编译器、连接器及相关工具，类似于Windows环境下的CCS软件(在Windows环境下的CCS软件用来编译和调试DSP程序)。
    (3)Framework Component：负责DSP端的Memory和DMA资源管理。
    (4)xDAIS：定义了DSP算法接口的标准。
    (5)DSP/BIOS Link：是实现ARM和DSP之间通信的底层软件。
    (6)Codec Engine：是DVSDK的核心，所有其他软件模块基本上都是围绕Codec Engine来设计的。
2.2 DVSDK的安装与编译
    首先要在虚拟机上的Linux系统中安装DVSDK软件包。DVSDK软件包可以从TI公司的官方网站上获取，软件包获取后执行如下命令即可实现其安装：
    ./ dvsdk_setuplinux_3_01_00_10.bin
    完成安装后会生成一个文件夹，里面包含了所有DVSDK软件模块。然后还需要对DVSDK内部的一些文件进行配置，主要的配置是指定各个模块编译所需要的编译工具以及相应目录的相对位置，配置好以后就可以对各个模块进行编译。
    编译成功后，在DVSDK相应的目录下会生成cmem.ko（内存管理模块）、dsplink.ko（ARM与DSP连接模块）、lpm_omap3530.ko（电源管理模块）等内核模块。为了使ARM与DSP建立连接，必须要有DSPLINK模块的支持，系统需要通过DSPLINK来完成ARM与DSP端之间底层的数据通信。DSPLINK提供了一套通用的API，从应用层抽象出ARM与DSP的物理连接特性，从而降低用户开发程序的难度。
2.3 内存的分配
    由于ARM端运行的是Linux操作系统，DSP端运行的是DSP/BIOS操作系统，为了使两个系统协同工作，两者之间需要开辟一块ARM端和DSP端共享的内存空间。这部分的工作由CMEM来完成，所以在加载cmem.ko时，需要对其进行内存分配设置。CMEM还能够将内存的物理地址转化为操作系统能够识别的虚拟地址，避免了操作系统对物理地址的直接访问。这样无论是Linux操作系统还是DSP/BIOS操作系统都是通过CMEM对内存进行管理。
    加载完上述各个功能模块后就可以开发可供ARM端调用的DSP程序。
3 供ARM端调用的DSP程序的开发
    为了开发可供ARM端调用的DSP程序，必须了解Codec Engine。Codec Engine是连接ARM和DSP协处理器的桥梁，是介于应用层（ARM端的应用程序）和信号处理层（DSP端的算法程序）之间的软件模块。在编译DSP端和ARM端程序时，都需要Codec Engine的支持。当ARM端应用程序调用Codec Engine的VISA（Video，Image，Speech，Audio）API，例如图2中VIDENC_process(a，b，c)时，Codec Engine的stub（ARM端）会把参数a、b、c以及要调用DSP端的process信息打包，通过消息队列(message queue)传递到DSP。Codec Engine的skeleton(DSP端)会解开这个参数包，把参数a、b、c转换成DSP端对应的参数x、y、z；DSP端的server会根据process这一信息创建一个DSP端的process(x，y，z)任务，最终实现VIDENC_process(a，b，c)的操作。

DSP端的算法程序开发一般有两种：
    (1)在Windows的CCS下直接开发DSP端运行的程序，然后打包成固定的格式，使其能够被Codec Engine调用。这种方法的优点是能够通过优化程序最大限度地提高DSP的运行效率。目前大多数DSP虽然都支持C语言编程，但是在实际工程应用中，具体的算法模块以及比较耗时的功能模块还是采用汇编语言来编写。这是因为C语言虽然具有易读性、可移植性等优点，但是它不便于对系统硬件资源的直接控制，无法发挥DSP自身的特点，无法充分利用DSP系统结构中有限的资源。特别是在硬实时性系统中，用汇编语言进行编程可利用DSP自身硬件结构的特点对汇编程序进行优化和精简，往往能够使一些复杂的算法及功能模块在实时性方面取得非常好的效果。但是这种方法也有其缺点，那就是算法程序的可移植性非常差，基本上针对每一个应用都要开发不同的DSP程序，这是比较致命的问题。
    (2)通过DVSDK开发套件在宿主机上直接开发算法程序，其开发方法遵照TI公司制订的基于eXpressDSP算法互用性标准。这种方法虽然会使DSP的运行效率受到一定影响，但为系统的整体性能和二次开发提供了可靠的保证。下面以示例程序来说明其开发方法。
    ①进入DVSDK安装后生成目录/dvsdk_3_01_00_10/codec_engine_2_25_02_11/examples/ti/sdo/ce/examples/codecs/imgdec_copy，如图3所示。该目录下的程序是DVSDK提供的示例程序，其中imgdec_copy.c是DSP端的程序，该程序实现了将ARM端读进的in.bmp图像拷贝成当前目录下的out.bmp图像的功能。
 

③编译ARM端的程序。进入ARM端应用程序目录/dvsdk_3_01_00_10/codec_engine_2_25_02_11/examples/ti/sdo/ce/examples/apps/image_copy，如图7所示。该目录下app.c是在ARM端运行的应用程序，该程序的主要功能就是从当前目录读取in.bmp文件，然后调用DSP端的程序，让DSP去实现图像拷贝。对该程序进行编译(执行make命令)，编译完成后会在该目录的bin子目录下生成ARM端的应用程序app_remote.xv5T，如图8所示。

本文阐述了OMAP3530中两种ARM和DSP协同开发方法，并对其进行了比较。一种方法是在CCS下直接开发DSP端的算法程序，其优点是能够通过优化算法程序最大限度地提高DSP端数字信号处理的效率，缺点是算法程序的可移植性差。另一种方法是利用DVSDK开发套件开发算法程序，其优点是算法的可移植性好，能够有效缩短开发周期，但是无法对DSP端运行的算法程序进行实时在线调试，而且DSP多流水线处理方式的优势难以得到充分发挥，所以算法程序也并不是最优化的。在实际开发中，可以根据具体的情况选择一种开发方法。
参考文献
[1] 冼进，毕盛.基于OMAP3530双核的嵌入式系统实验平台设计[J].信息系统工程，2010(7)：72-73.
[2] 王伟，刘培德.OMAP3530平台移动多媒体的视频解码方案[J].单片机与嵌入式系统，2010(6)：31-34.
[3] 宋宝华.Linux设备驱动开发详解[M].北京：人民邮电出版社，2010.
[4] 张起贵，张胜，张刚.最新DSP技术[M].北京：国防工业出版社，2009.
[5] 纪震，曾启明.OMAP3原理及系统设计[M].北京：科学出版社，2011.