針對(duì)當(dāng)前應(yīng)用的復(fù)雜性,SOC芯片更好能能滿足應(yīng)用和媒體的需求,集成眾多接口,用ARM做為應(yīng)用處理器進(jìn)行多樣化的應(yīng)用開(kāi)發(fā)和用戶界面和接口,利用DSP進(jìn)行算法加速,特別是媒體的編解碼算法加速,既能夠保持算法的靈活性,又能提供強(qiáng)大的處理能力。德州儀器(TI)繼第一系列Davinci芯片DM644x之后,又陸續(xù)推出了DM643x,DM35x/36x,DM6467,OMAP35x,OMAPLx等一系列ARM+DSP或ARM+視頻協(xié)處理器的多媒體處理器平臺(tái)。眾多有很強(qiáng)DSP開(kāi)發(fā)經(jīng)驗(yàn)的工程師,以及應(yīng)用處理開(kāi)發(fā)經(jīng)驗(yàn)的工程師都轉(zhuǎn)到使用達(dá)芬奇或OMAP平臺(tái)上開(kāi)發(fā)視頻監(jiān)控、視頻會(huì)議及便攜式多媒體終端等產(chǎn)品?;贏RM+DSP的芯片架構(gòu),如何進(jìn)行開(kāi)發(fā)實(shí)現(xiàn)做期望的嵌入式應(yīng)用呢?
傳統(tǒng)的芯片,基本是一個(gè)處理器內(nèi)核,或者是通用處理器如ARM,或者是DSP。對(duì)于控制和用戶接口,一般用通用處理器實(shí)現(xiàn),算法處理或者媒體處理則依賴于DSP或者硬件芯片,很多系統(tǒng)都是雙芯片的架構(gòu)。開(kāi)發(fā)模式也比較單純,比如ARM芯片,有ARM的的仿真工具,基于OS之上進(jìn)行應(yīng)用開(kāi)發(fā);DSP有DSP的開(kāi)發(fā)工具,如TI的CCS以及510、560的仿真器,可以進(jìn)行算法的移植、優(yōu)化、跟蹤、調(diào)試等。這時(shí),所需要的經(jīng)驗(yàn)也比較單一。
基于ARM+DSP的雙核架構(gòu),很多工程師不知道如何入手進(jìn)行開(kāi)發(fā),提出了很多的疑問(wèn),比如對(duì)ARM工程師,很困惑的是如何使用DSP的資源?如何進(jìn)行數(shù)據(jù)的交互?如何保持雙核之間的同步?對(duì)DSP工程師,則問(wèn)到如何進(jìn)行ARM調(diào)試?如何啟動(dòng)DSP?如果進(jìn)行媒體加速,如何操作外設(shè)獲取或發(fā)送數(shù)據(jù)等?;诓煌拈_(kāi)發(fā)經(jīng)驗(yàn)和基礎(chǔ),ARM工程師和DSP工程師會(huì)從完全不同的角度來(lái)看SOC的芯片,以至于拿到SOC的芯片根本不知道如何入手,這里就本人的經(jīng)驗(yàn)與大家分享一下。
本文引用地址:http://m.butianyuan.cn/article/201611/322348.htm首先ARM+DSP的芯片,他是一個(gè)雙核的,對(duì)應(yīng)ARM和DSP分別是不同的指令集和編譯器,可以把SOC的芯片看成是兩個(gè)單芯片的合成,需要兩套不同的開(kāi)發(fā)工具,CCS3.3可以進(jìn)行芯片級(jí)的調(diào)試和仿真,但是對(duì)應(yīng)ARM和DSP需要選擇不同的平臺(tái)。一般來(lái)說(shuō),ARM上面跑操作系統(tǒng),比如Linux,Wince等,在ARM上的開(kāi)發(fā),除了bootloader以外,基本都是基于OS的開(kāi)發(fā),比如驅(qū)動(dòng),內(nèi)核裁減,以及上層應(yīng)用等,需要的調(diào)試和仿真主要靠log或者OS提供的調(diào)試器,如KGDB,Platform Builder等?;贒SP核的開(kāi)發(fā)和傳統(tǒng)單核DSP一樣,需要用CCS+仿真器來(lái)進(jìn)行開(kāi)發(fā)調(diào)試。
其次,對(duì)于芯片的外設(shè)接口,ARM核和DSP核都可以訪問(wèn),典型的情況是ARM控制所有的外設(shè),通過(guò)OS上的驅(qū)動(dòng)去控制和管理,這部分和傳統(tǒng)的ARM芯片類似;DSP主要是進(jìn)行算法加速,只是和memory打交道,為了保持芯片的資源管理的一致性,盡量避免由DSP去訪問(wèn)外設(shè)。當(dāng)然,根據(jù)具體的應(yīng)用需求,DSP也是可以控制外設(shè)接口進(jìn)行數(shù)據(jù)的收發(fā),這時(shí),需要做好系統(tǒng)的管理,避免雙核操作的沖突。
對(duì)memory的使用,非易失的存儲(chǔ)空間,比如NAND、NOR Flash,基本也是由ARM訪問(wèn),DSP的算法代碼作為ARM端OS文件系統(tǒng)的一個(gè)文件存在,通過(guò)應(yīng)用程序進(jìn)行DSP程序的下載和DSP芯片的控制。外部RAM空間,即DDR存儲(chǔ)區(qū),是ARM和DSP共享存在的,但是在系統(tǒng)設(shè)計(jì)的時(shí)候,需要把ARM和DSP使用的內(nèi)存嚴(yán)格物理地址分開(kāi),以及預(yù)留出一部分用來(lái)交互的內(nèi)存空間。一般情況,ARM是用低端地址,DSP通過(guò)CMD文件分配高端地址,中間預(yù)留部分空間用來(lái)做數(shù)據(jù)交互,比如在OMAP3的Linux下的DVSDK中,128MB的DDR空間被分成三部分,低端地址從0x8000000到0x85800000-1的88MB空間給Linux內(nèi)核使用;從0x85800000到0x86800000-1的16MB給CMEM的驅(qū)動(dòng),用來(lái)做ARM和DSP的大塊數(shù)據(jù)交互,從0x86800000到0x88000000-1的24MB是DSP的代碼和數(shù)據(jù)空間。
芯片的啟動(dòng)也是需要重點(diǎn)考慮的問(wèn)題,一般情況下,是ARM啟動(dòng),和傳統(tǒng)的單核ARM一樣,支持不同的啟動(dòng)方式,比如可以支持NAND,NOR,UART,SPI,USB,PCI等接口啟動(dòng)。DSP默認(rèn)處于復(fù)位狀態(tài),只有通過(guò)ARM的應(yīng)用下載代碼并且解除復(fù)位以后,DSP才能跑起來(lái)。有些應(yīng)用場(chǎng)景,需要DSP直接從外部上電就自啟動(dòng),有些芯片也是支持這種模式的。
最后,關(guān)于芯片的通信和同步,這個(gè)是困擾很多工程師的問(wèn)題,為了便于客戶的開(kāi)發(fā)和使用,TI提供了DSPLINK,CODEC ENGINE的DVSDK開(kāi)發(fā)套件,基于DVSDK可以很方便的進(jìn)行ARM+DSP的應(yīng)用開(kāi)發(fā),下面對(duì)DVSDK的軟件架構(gòu),各個(gè)軟件模塊的功能等做簡(jiǎn)要介紹。
DVSDK是多個(gè)軟件模塊的集成,包括純DSP端的軟件模塊,ARM的軟件模塊和雙核交互的軟件模塊。DVSDK的軟件包都是基于實(shí)時(shí)軟件模塊(Real-Time-Software-Component:RTSC)的,還需要安裝RTSC的工具XDC,XDC是TI開(kāi)源的一個(gè)工具,可以支持跨平臺(tái)的開(kāi)發(fā),能夠最大程度的代碼重用;如果需要進(jìn)行純ARM的開(kāi)發(fā),還需要ARM的編譯工具以及Linux內(nèi)核或者Wince的BSP;如果需要進(jìn)行DSP的算法開(kāi)發(fā)或者DSP端開(kāi)執(zhí)行代碼生成,還需要安裝DSP的編譯器cgtools和DSP/BIOS;為了便于配置生成DSP端的可執(zhí)行代碼,通過(guò)向?qū)蒀odec的RTSC包和可執(zhí)行代碼,還可以選裝ceutils和cg_xml。
DVSDK的核心是Codec Engine,所有的其他軟件模塊基本都是圍繞Codec Engine的。Codec Engine是連接ARM和DSP的橋梁,是介于應(yīng)用層(ARM側(cè)的應(yīng)用程序)和信號(hào)處理層(DSP側(cè)的算法)之間的軟件模塊,在編譯DSP端可執(zhí)行代碼和ARM端應(yīng)用程序時(shí),都需要Codec Engine的支持。Codec Engine主要有兩部分:
? ARM端應(yīng)用適配層,提供了精簡(jiǎn)的API和對(duì)應(yīng)的庫(kù)給應(yīng)用層使用。
? DSP的算法調(diào)用層,提供了DSP算法的接口封裝規(guī)范,是的所有的算法通過(guò)簡(jiǎn)單的配置就可以編譯到DSP的可執(zhí)行程序中。
最終的應(yīng)用程序需要通過(guò)Codec Engine的API接口來(lái)下載DSP代碼,調(diào)用DSP端的封裝好的算法,以及進(jìn)行ARM和DSP的通信。
關(guān)于Codec Engine的介紹,可以參考《幫您快速入門Codec Engine》。
Codec Engine底層ARM和DSP的通信是建立在DSP/BIOS Link之上的,DSP/BIOS Link真正實(shí)現(xiàn)ARM和DSP交互的軟件模塊。由于DSP/BIOS Link是跨平臺(tái)的,也是有ARM部分和DSP部分組成,其中在ARM端,包括基于OS的驅(qū)動(dòng)和供應(yīng)用調(diào)用的庫(kù)文件,DSP端,必須要用DSP/BIOS,DSP的可執(zhí)行代碼需要包含DSP/BIOS Link的庫(kù)文件。DSP/BIOS
Link常用的主要有如下幾部分的軟件模塊:
? PROC相關(guān)的,主要是用來(lái)做DSP芯片的控制,比如啟動(dòng),停止等,下載DSP的可執(zhí)行代碼,以及直接讀寫DSP端的memory空間等
? MSGQ相關(guān),ARM和DSP的通信是基于MSGQ的,MSGQ有輪詢等待的方式或者中斷的方式,MSG是基于共享內(nèi)存池的方式。Codec Engine通過(guò)MSGQ交互一些關(guān)鍵數(shù)據(jù),比如控制,和一些大塊數(shù)據(jù)的地址指針等。大量的數(shù)據(jù)交互需要通過(guò)cmem實(shí)現(xiàn)。
在ARM端,配合Codec Engine使用的軟件模塊有LinuxUtils或者WinceUtils,包含cmem,SDMA等,cmem是用來(lái)在OS之外分配連續(xù)物理內(nèi)存空間,進(jìn)行物理地址到虛地址,以及虛地址到物理地址空間轉(zhuǎn)化的。為了避免數(shù)據(jù)的多次復(fù)制,需要開(kāi)辟一塊ARM和DSP共享的數(shù)據(jù)空間,ARM和DSP都可以直接訪問(wèn),這部分空間需要通過(guò)CMEM管理。對(duì)ARM來(lái)說(shuō),CMEM是OS上的一個(gè)驅(qū)動(dòng)程序,需要通過(guò)IOCTL來(lái)實(shí)現(xiàn)內(nèi)存分配或者地址空間轉(zhuǎn)化。由于DSP可以訪問(wèn)任何物理地址空間,通過(guò)ARM傳給DSP的指針必須是物理地址。
為了適配一些播放器的接口,DVSDK還提供了DMAI(Digital Media Application Interface),DMAI提供了更為精簡(jiǎn)的媒體接口和基于OS的音視頻捕捉、回放等接口,在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。并且DMAI也提供了最基本的測(cè)試應(yīng)用例子,可以很方便的進(jìn)行修改和測(cè)試。
如果只是調(diào)用現(xiàn)成的或者第三方的算法庫(kù),可以只了解ARM端的軟件模塊,Codec Engine或者DMAI已經(jīng)提供了豐富的應(yīng)用接口,DSP可以認(rèn)為是個(gè)單純的媒體加速器,把ARM+DSP的芯片當(dāng)作ASIC一樣使用。如果要充分發(fā)揮DSP的性能,就需要對(duì)DSP進(jìn)行開(kāi)發(fā)了。Codec Engine對(duì)DSP的算法只是規(guī)范了接口,以便于和Codec Engine一起生成DSP的可執(zhí)行程序。
評(píng)論