【正文】 還是 DSP側(cè)的算法。如果要擴展 xDM的數(shù)據(jù)結(jié)構(gòu)請參 考： 4） Codec Engine DSP側(cè)會涉及到 Cache一致性的問題。比如 engine_open失敗， DSP側(cè)不能創(chuàng)建 codec 等等。請參考： 使用中常碰到的問題 6） 因為 Codec Engine是介于 ARM 應(yīng)用程序和編解碼算法中間的軟件模塊，很多工程師非常想知道它的開銷 (overhead)， 請參考： 7）如何在 Linux環(huán)境下編 DSP的匯編或線性匯編程序？ 在 Codec Engine安裝路徑下 /packages/ var C6?P = (??P?)。最簡單的辦法是使用 TSC的低 32位 TSCL。 include void main (){ … TSCL=0。 my_code_to_benchmark()。 printf(“ cycles == %d\n”, (t2t1))。還請各位工程師從自己要用的軟件模塊發(fā)布說明文檔開始找到相關(guān)的文檔并研究。 Codec Engine概述 Codec Engine 框架分析 Codec Engine在解決達芬奇雙處理器架構(gòu)問題時首先引入了遠程過程控制 (RPC)的概念。 RPC有客戶端和服務(wù)端，客戶端通過某種通信協(xié)議并最終通過物理鏈路向服務(wù)端發(fā)送一個命令，服務(wù)端執(zhí)行命令并通過相應(yīng)的通信方式將結(jié)果返回給客戶端。 Codec Engine概述 Codec Engine 組件 CE里面有幾個組件，或者我們叫做 package, DSPLink是用來做應(yīng)用軟件和算法之間進行信令通信用的， DSPLink的 package里也有很多小模塊，可以運行一個簡單的腳本進行配置，然后再重新 make出需要的 Linux模塊加載的驅(qū)動； CMEM是用來做共享內(nèi)存分配的，因為 應(yīng)用程序 是運行在 MVista Linux上的，在應(yīng)用程序里 malloc到的 buffer都是 虛擬地址 ，實際的物理空間不一定連續(xù)，當把這個指針傳遞給算法的時候，問題就出現(xiàn)了，因為 算法是運行在 DSP/BIOS上 的， 這是一個只有實地址的世界 ，為了解決這個問題，在共享緩存動態(tài)申請空間的時候，就要調(diào)用CMEM提供的 API； XDCtTools是一個 TI提供的工具組件，也是一個最核心的組件，任何的編譯行為都是通過 xdctools來 解釋 腳本內(nèi)容 調(diào)用各種編譯器 來完成的， CCS下和 Linux下的工具鏈是一樣 的，可以看到安裝后 CCS路徑下的東西，一個是 DSPBios，一個是 CC，這里面是交叉編譯器，還有一個就是 XDCTools，在 Linux下的 CE也是如此，只不過還多了點料，譬如 DSPLink和 Cmem，所以， 所有的組件 package都可以在 CCS下用 ， CGTools，這個就是 DSP的交叉編譯器 DSP/BIOS使用 CE一定要用 DSP/BIOS， 客戶也可拋棄 BIOS和 CE，自己做雙核通信。因此， Codec Engine的工作是通過完成 VISA API的任務(wù)來體現(xiàn)的。 Codec Engine概述 Codec Engine 的工作原理 在調(diào)用 VISA API之前需要在應(yīng)用程序中通過 Engine_open()這個 Engine API把 DSP的可執(zhí)行程序加載到 DSP的 memory，同時把 DSP從復(fù)位狀態(tài)釋放，這時 DSP開始運行DSP Server的初始化程序在 DSP側(cè)創(chuàng)建一個優(yōu)先級最低的任務(wù) RMS(Remote Management Server)， RMS負責管理和維護對應(yīng)到具體 codec算法的 Instances。 接著 Engine SPI通過 OSAL(Operating System Abstraction Layer)、 DSPLink把 VISA create的命令傳到 DSP側(cè)的 RMS。 VISA create會返回一個 Instance的 Handle，以便于給這個 Instance做后續(xù)的 VISA control/process/delete提供信息。 Codec Engine概述 Codec Engine 的工作原理 概括來說， VISA control用來動態(tài)的修改 codec instance的屬性， VISA process用來對算法的輸入數(shù)據(jù)流做處理并返回一個輸出數(shù)據(jù)流。 Stub把這些參數(shù)和相關(guān)的命令通過 Engine SPI、 OSAL和 DSP Link傳遞到 DSP側(cè)Instance。 四、 Codec創(chuàng)建 DSP Server(DSP端可執(zhí)行程序 ) Codec創(chuàng)建 DSP Server 對達芬奇的軟件來說， DSP Server也叫 Codec Server。從圖 3和 4可以看到，除算法之外， DSP Server還集成了其他的軟件模塊 (如 DSP/BIOS、DSP Link、 Codec Engine等 )。 和 gmake類似， xDC根據(jù)一套 build指令 build生成可執(zhí)行文件 。 xDC的 源文件 可以是 C程序、 C++程序、匯編程序和庫文件等。 這個過程可以分為三部分： 創(chuàng)建 DSP Server的源文件； 設(shè)置 xDC的配置文件； 執(zhí)行“ make”生成可執(zhí)行文件 。圖 5中的 packages是指圖 3和圖 4中的 codecs、 RMS、 Engine SPI和 OSAL。 OMAP_L137的目錄為： Codec Engine_2_22/examples/ti/sdo/ce/examples/servers/video_copy/evmOMAPL137/ 要構(gòu)建 DSP Server首先就需要創(chuàng)建 server的 DSP/BIOS配置文件 .tcf及。這個初始化就是 DSP Server (見圖 7)中的 CERuntime_init()。 圖 6 Codec創(chuàng)建 DSP Server DSP BIOS的配置文件 .tcf中定義 DSP的memory map、設(shè)置 DSP的復(fù)位 /中斷向量表并且創(chuàng)建和初始化 BIOS程序需要的各種數(shù)據(jù)對象 (如圖 8的 .tcf)。但是，我們可以在sections(如圖 8 中 .tables和 .csl_vect等 )。 在 .tcf中我們只能定義編譯器默認的sections(如 .text和 .bss等 )。 Codec創(chuàng)建 DSP Server 3. xDC文件 在 Linux中我們用 make命令根據(jù) makefile來生成可執(zhí)行文件， xDC也有類似的 生成腳本文件(我們統(tǒng)稱為 xDC文件 )。 在 DSP Server的名字、它的路徑及 Server的依賴文件 . Linux中的 makefile，它會告訴 xDC怎么樣 build DSP Server的源文件。 Codec創(chuàng)建 DSP Server xDC的強大之處還在于它提供給系統(tǒng)集成工程師一個強大的工具，這個工具可以用來把各種各樣的代碼模塊組合成自己的最終產(chǎn)品。 請注意這里的 .cfg文件不同于第一章提到的 Codec Engine的 .cfg文件 (例如CE_INSTALL_DIR/examples/apps/video_copy/dualcpu/)，下文中提到的 .cfg都是指 DSP Server的 .cfg文件。 我們可以打開查看 ，但不能修改。 Codec創(chuàng)建 DSP Server 4. 設(shè)置 xDC的配置文件 既然 .cfg文件負責系統(tǒng)級的管理，我們需要先了解什么需要管理？當然是 DSP的資源，無非就是 CPU cycles、 memory及 DMA。 xDM和 xDAIS算法的 Instance都向 FC提出自己的資源請求，比如請求 1KByte的 memory或一個 DMA通道。舉例來說，有了 DSKT2負責不同算法開發(fā)的工程師就不必擔心自己要用的某一段 memory是否已經(jīng)被別的算法占用等一系列問題，因為每一個算法的 memory都是由 DSKT2分配的。系統(tǒng)集成工程師需要用所有可以利用的 memory初始化DSKT2模塊。當一個算法被創(chuàng)建的時候，永久性 memory才會被 DSKT2分配給這個算法，在算法被刪除的時候，這段 memory被返回到 heap。pool39。也就是說，共享 scratch memory的算法屬于同一個優(yōu)先級，不能中斷對方。 (1) Codec配置：每一個 codec都被包含在各自的線程中； 配置每一個 codec線程的屬性 (線程優(yōu)先級、堆棧大小和堆棧的 memory資源 )。 (2) DSKT2配置： 把所有的 IALG memory類型結(jié)合到可用的 DSP memory；定義缺省的 scratch組的 memory大小。 以 ，對應(yīng)到圖 4所示的 DSP Server部分， .cfg文件中對 OSAL和codecs模塊做了聲明和定義。 Codec創(chuàng)建 DSP Server 接著對 server進行配置，包括各個線程的屬性配置。 Codec創(chuàng)建 DSP Server 對 DSKT2的配置，參看下面的例子。 Codec創(chuàng)建 DSP Server 以下是 DMAN3的配置例子。 DMAN3的 PARAM是通過它自己的 base index和數(shù)量分配的，本例分配給 DMAN3 48個 PARAM。 Codec創(chuàng)建 DSP Server 5. xDC的 build 過程 xDC的調(diào)用是通過執(zhí)行命令 XDC完成的。 執(zhí)行 XDC后先產(chǎn)生 ， XDC再運行 pac