基於OMAP3530硬件平臺的ARM和DSP協同開發方法
2013/3/21 17:32:55
摘 要： 以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.
