基於ARM+DSP進行應用開發

      針對當前應用的複雜性，SOC晶片更好能能滿足應用和媒體的需求，整合眾多介面，用ARM做為應用處理器進行多樣化的應用開發和使用者介面和介面，利用DSP進行演算法加速，特別是媒體的編解碼演算法加速，既能夠保持演算法的靈活性，又能提供強大的處理能力。德州儀器（TI）繼第一系列Davinci晶片DM644x之後，又陸續推出了DM643x，DM35x/36x，DM6467，OMAP35x，OMAPLx等一系列ARM＋DSP或ARM＋視頻副處理器的多媒體處理器平台。眾多有很強DSP開發經驗的工程師，以及應用處理開發經驗的工程師都轉到使用達芬奇或OMAP平台上開發視頻監控、視頻會議及攜帶型多媒體終端等產品。基於ARM+DSP的晶片架構，如何進行開發實現做期望的嵌入式應用呢？
      傳統的晶片，基本是一個處理器核心，或者是通用處理器如ARM，或者是DSP。對於控制和使用者介面，一般用通用處理器實現，演算法處理或者ApsaraVideo for Media Processing則依賴於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主要有兩部分：
      （1）ARM端應用適配層，提供了精簡的API和對應的庫給應用程式層使用。 
      （2）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常用的主要有如下幾部分的軟體模組：
      （1）PROC相關的，主要是用來做DSP晶片的控制，比如啟動，停止等，下載DSP的可執行代碼，以及直接讀寫DSP端的memory空間等；
      （2）MSGQ相關，ARM和DSP的通訊是基於MSGQ的，MSGQ有輪詢等待的方式或者中斷的方式，MSG是基於共用記憶體池的方式。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的介面就可以了。具體如何進行DSP的打包，如何產生DSP的可執行程式，在後續的文章繼續討論。

 

原文轉至http://www.linuxforum.net/forum/showflat.php?Cat=&Board=TI&Number=728820&page=0&view=collapsed&sb=5&o=0&fpart=