文獻(xiàn)標(biāo)識(shí)碼: B
文章編號(hào): 0258-7998(2013)11-0017-03
OMAP3530是TI公司提出的基于ARM和DSP的雙核應(yīng)用處理器[1],,在單個(gè)芯片上集成了ARM Cortex-A8內(nèi)核、TMS320C64X+DSP內(nèi)核,、圖像引擎,、視頻加速器以及豐富的多媒體外設(shè)。用ARM作為應(yīng)用處理器進(jìn)行多樣化的應(yīng)用開發(fā),,實(shí)現(xiàn)用戶界面接口,,能夠保證實(shí)時(shí)性和編碼效率,降低開發(fā)成本,;利用DSP進(jìn)行算法加速,,既能夠保持算法的靈活性,又能提供強(qiáng)大的處理能力,。
船用導(dǎo)航雷達(dá)作為重要的無線電輔助導(dǎo)航設(shè)備,,在船舶近海定位、引導(dǎo)船舶進(jìn)出港口,、惡劣天氣航行及避碰導(dǎo)航等領(lǐng)域發(fā)揮重大作用。國內(nèi)導(dǎo)航雷達(dá)顯控終端大多采用基于PC的PCI雷達(dá)圖像卡或基于X86的計(jì)算機(jī)模塊,。隨著現(xiàn)代電子技術(shù)的飛速發(fā)展,,越來越多的嵌入式處理器被應(yīng)用于雷達(dá)設(shè)備中。本文介紹的導(dǎo)航雷達(dá)終端以O(shè)MAP3530嵌入式處理器為硬件平臺(tái),,采用了Codec Engine框架下的軟件設(shè)計(jì)方案,。該終端具有體積小、實(shí)時(shí)性高,、穩(wěn)定性好,、成本低、功耗小的優(yōu)點(diǎn),。
1 軟件架構(gòu)設(shè)計(jì)
如圖1所示,,根據(jù)處理器的工作分配,終端從縱向劃分為ARM子系統(tǒng)與DSP子系統(tǒng)。ARM子系統(tǒng)采用Linux操作系統(tǒng),,DSP子系統(tǒng)采用DSP/BIOS操作系統(tǒng),。ARM核是精簡指令集處理器,運(yùn)算能力相對(duì)較弱,,主要負(fù)責(zé)終端整體控制功能,。而DSP核是超長指令集的處理器,適合處理大批量的數(shù)據(jù)傳輸和數(shù)據(jù)處理工作,。
1.1 軟件框架
如圖1所示,,終端軟件分為顯控處理軟件、錄取跟蹤軟件,、GPMC總線驅(qū)動(dòng)程序,、Codec Engine。其中,,顯控處理軟件在ARM核[2]上運(yùn)行,,它基于QT界面框架[3],使用自定義繪圖和QT控件提供可視化的導(dǎo)航界面,,負(fù)責(zé)終端整體控制功能,;錄取跟蹤軟件在DSP核上運(yùn)行,負(fù)責(zé)處理運(yùn)算需求高的各種濾波,、關(guān)聯(lián)算法,,使導(dǎo)航雷達(dá)同時(shí)對(duì)多批目標(biāo)進(jìn)行實(shí)時(shí)錄取、ARPA跟蹤[4],,并自動(dòng)計(jì)算出目標(biāo)的動(dòng)態(tài)信息,,以發(fā)揮避碰導(dǎo)航的作用;GPMC總線驅(qū)動(dòng)程序?yàn)镕PGA與OMAP提供通信通道,;FrameBuf顯示驅(qū)動(dòng)為QT與OMAP顯示模塊提供圖形數(shù)據(jù)寫入通道,;Codec Engine為顯控處理軟件(ARM側(cè))與錄取跟蹤軟件(DSP側(cè))提供交互通道。
1.2 各軟件間數(shù)據(jù)通信流
如圖1所示,,各軟件間數(shù)據(jù)通信流包括雷達(dá)控制信息,、雷達(dá)狀態(tài)信息、波門信息,、航跡信息,、界面圖形信息。顯控處理軟件通過GPMC總線驅(qū)動(dòng)經(jīng)FPGA讀取雷達(dá)狀態(tài)信息,,寫入雷達(dá)操控信息,;同時(shí)讀取波門和扇區(qū)信息,通過Codec Engine送至錄取跟蹤軟件,。錄取跟蹤軟件通過Codec Engine將航跡信息送至顯控處理軟件,。顯控處理軟件通過FrameBuf顯示驅(qū)動(dòng)將界面繪圖送入OMAP顯示緩沖,。
2 在Codec Engine框架下的軟件開發(fā)
雙核系統(tǒng)雖然擁有強(qiáng)大的處理能力,但由于ARM和DSP分別對(duì)應(yīng)不同的指令集和編譯器,,要使雙核系統(tǒng)配合工作,,分擔(dān)不同的任務(wù),雙核之間的協(xié)調(diào)通信是一個(gè)關(guān)鍵的因素,。TI的數(shù)字視頻軟件開發(fā)包(DVSDK)提供了Codec Engine來實(shí)現(xiàn)ARM與DSP的協(xié)同工作[5],。Codec Engine引入了遠(yuǎn)程過程調(diào)用(RPC)的概念[6],它是指在另外一個(gè)處理器上遠(yuǎn)程執(zhí)行的一個(gè)命令或者過程,。在該終端中,,錄取跟蹤軟件為Server端,顯控處理軟件為Client端,,Client端應(yīng)用程序調(diào)用Codec Engine向Server端發(fā)送一個(gè)命令,,Server端執(zhí)行命令并通過相應(yīng)的通信方式將結(jié)果返回給客戶端,進(jìn)而實(shí)現(xiàn)雙核的無縫連接與協(xié)調(diào)工作,。
在使用Codec Engine時(shí),,一般會(huì)做以下操作:搭建開發(fā)環(huán)境、創(chuàng)立算法(Codec),、服務(wù)的集成(Server)以及Engine的集成和應(yīng)用(App),。
2.1 軟件開發(fā)環(huán)境搭建
要構(gòu)建定制的Codec Engine配置,需要在TI公司提供的數(shù)字視頻開發(fā)套件DVSDK中修改相關(guān)軟件包的環(huán)境變量,,搭建軟件開發(fā)環(huán)境,。該套件中集成了多種軟件模塊,其核心是Codec Engine,。要根據(jù)實(shí)際安裝情況分別修改以下文件的環(huán)境變量,。
(1)在DSPLINK軟件包中的Rules.mk、c64xxp_5.xx_linux.mk,、omap3530_2.6.mk文件中分別修改內(nèi)核源碼路徑,、ARM編譯器路徑、XDC工具路徑,、DSP系統(tǒng)路徑等,,完成后編譯生成dsplinkk.ko(ARM與DSP連接模塊)。,;
(2)在CMEM軟件包中的Rules.make文件中分別修改內(nèi)核源碼路徑、ARM編譯器路徑,,完成后編譯生成cmemk.ko(內(nèi)存管理模塊),。
(3)在電源管理軟件包中的Makefile文件中修改內(nèi)核源碼路徑、ARM編譯器路徑,、DSPLINK安裝路徑,,完成后編譯生成lpm_omap3530.ko(電源管理模塊),。
2.2 算法的創(chuàng)立
按照xDAIS-DM標(biāo)準(zhǔn),目標(biāo)跟蹤算法模塊需要提供標(biāo)準(zhǔn)中所定義的一些接口的實(shí)現(xiàn)函數(shù),,并且需要對(duì)算法模塊中用到的一些結(jié)構(gòu)作出定義,。擴(kuò)展xDM規(guī)范中已有的標(biāo)準(zhǔn)接口是產(chǎn)生自定義算法模塊的一種最常見的方式。本文的目標(biāo)跟蹤算法模塊利用VISA中的SCALE接口進(jìn)行xDM標(biāo)準(zhǔn)算法庫的開發(fā),。圖2是SCALE接口中各個(gè)package的關(guān)系,。
codecs:在該文件夾下定義相關(guān)算法的.c和.h文件。為了使編譯器能識(shí)別自定義的.c文件,,需要修改package.bld配置文件,,將自定義的.c文件名添加到SRCS數(shù)組中,這個(gè)SRCS數(shù)組中包括了package中的所有.c文件,。最后修改相應(yīng)的服務(wù)配置文件生成算法并將其打包,,經(jīng)編譯生成scale_ti.a64P的lib庫文件,這就是所需要的codec,。
extensions:包括GPP端的stub庫和DSP端的skeleton庫(通過.c和.h文件配置stub和skeleton函數(shù)表),,經(jīng)編譯生成scale.a64P的lib庫文件。
2.3 服務(wù)的集成
servers:算法服務(wù)集成,。修改配置文件,,分配內(nèi)存生成一個(gè)DSP端的可執(zhí)行程序all.x64P文件,這就是所需要的DSP Server算法服務(wù)器,,可被應(yīng)用程序直接調(diào)用,。
(1)修改all.tcf文件。對(duì)128 MB的外部RAM空間即DDR存儲(chǔ)區(qū)進(jìn)行分配,,這塊空間是ARM和DSP可以共享的,,ARM通過MMU(Memory Management Unit)看到的是內(nèi)存的虛擬地址,但DSP直接使用物理地址,。內(nèi)存分配具體如表1所示,。
(2)修改all.cfg文件。主要對(duì)線程屬性進(jìn)行設(shè)置,。線程屬性主要包括棧大小,、內(nèi)存段的ID以及優(yōu)先級(jí)等。堆棧大小要大于所需要的容量,,這樣比較安全,。
2.4 Engine集成和應(yīng)用
apps:apps中定義了Engine的配置,對(duì)于應(yīng)用程序是在本地(ARM)執(zhí)行還是在遠(yuǎn)端(DSP)執(zhí)行,,通過配置腳本文件local.cfg和remote.cfg即可實(shí)現(xiàn),,在腳本文件中指明Engine名稱和Server名稱。經(jīng)編譯生成app_remote.av5T可執(zhí)行程序,。
App通過調(diào)用各種VISA(Video,,Image,,Speech,Audio)APIs實(shí)現(xiàn)具體算法實(shí)例[7-8],,VISA APIs通常分為四個(gè)部分:MOD_create(用于創(chuàng)建算法實(shí)例),、MOD_control(用于動(dòng)態(tài)地修改算法實(shí)例的屬性)、MOD_process(用于對(duì)算法傳遞輸入數(shù)據(jù)流做處理并返回一個(gè)輸出數(shù)據(jù)流),、MOD_delete(用于刪除編碼器實(shí)例,,釋放創(chuàng)建編碼器實(shí)例時(shí)占用的系統(tǒng)資源)。以應(yīng)用程序調(diào)用MOD_process為例,,GPP端和DSP端的交互過程大致如圖3所示,。
(1)應(yīng)用程序(GPP端)調(diào)用MOD_process()函數(shù);
(2)Codec Engine將調(diào)用信息和調(diào)用所需參數(shù)傳遞給GPP端的stub,;
(3)stub將參數(shù)打包封裝成消息,,并且將GPP端的虛擬地址映射到DSP端的物理地址;
(4)Codec Engine將消息傳遞到DSP端的skeleton,;
(5)skeleton將參數(shù)解析出來,,并且調(diào)用xDAIS算法的process函數(shù);
(6)skeleton再將參數(shù)打包返回,,以消息隊(duì)列形式返回給應(yīng)用程序,,然后stub再對(duì)參數(shù)進(jìn)行解析。
最后將編譯生成的all.x64P算法服務(wù)器,、app_remote.av5T可執(zhí)行程序,、dsplinkk.ko、cmemk.ko,、lpm_omap3530.ko驅(qū)動(dòng)以及驅(qū)動(dòng)加載/卸載配置腳本loadmodules.sh,、unloadmodules.sh一同拷入目標(biāo)板的同一文件夾執(zhí)行,即可實(shí)現(xiàn)目標(biāo)跟蹤,。
現(xiàn)代雷達(dá)終端價(jià)格高,、體積大、功耗大,,本文基于OMAP3530實(shí)現(xiàn)的船用導(dǎo)航雷達(dá)終端的軟件設(shè)計(jì),,充分發(fā)揮了OMAP3530芯片的雙核特性,滿足高速處理和穩(wěn)定性的需求,,使船載雷達(dá)終端的體積大大減小,,成本大幅降低,為在中小船只上普及裝備導(dǎo)航雷達(dá)終端提供了一種新的解決方案,,值得在現(xiàn)代船舶導(dǎo)航雷達(dá)中進(jìn)一步研究推廣,。
參考文獻(xiàn)
[1] Texas Instruments.OMAP35x applications processor Texas Instruments OMAPTM family of products technical reference manual[Z].2008.
[2] 李忠民,楊剛,顧亦然,,等.ARM嵌入式VxWorks實(shí)踐教程[M].北京:北京航空航天大學(xué)出版社,2006.
[3] 袁鵬飛.24小時(shí)學(xué)通qt編程[M].北京:人民郵電出版社,,2000.
[4] 王德生,,彭勇.ARPA系統(tǒng)與艦船導(dǎo)航雷達(dá)顯示[J].中國雷達(dá),1998(02):40-42.
[5] 溫君安.基于Davinci處理器的語音算法設(shè)計(jì)和優(yōu)化實(shí)現(xiàn)[D].杭州:浙江大學(xué),,2007.
[6] 劉永春.基于DSP和ARM的車牌識(shí)別系統(tǒng)設(shè)計(jì)[J].微型機(jī)與應(yīng)用,,2012,31(22):80-82.
[7] 林上升.基于OMAP3530硬件平臺(tái)的ARM和DSP協(xié)同開發(fā)方法[J].電子技術(shù)應(yīng)用,,2013,,39(2):6-8.
[8] 孫連三.基于OMAP的手持設(shè)備嵌入式系統(tǒng)研究[J].計(jì)算機(jī)工程與設(shè)計(jì),2008(9):2242-2245.