DAVINCI DM3730開發攻略——應用程序例程分析

過完2015年春節回來了，利用上班前的幾天時間，先把這篇文章寫完，原本是先寫《DAVINCI DM3730開發攻略——linux-2.6.32移植》，可是那篇文章涉及內核的東西太多，不太好寫，而本人已經很長時間沒寫新文章了，先發布這篇文章。後來想了想，從應用程序使用的角度分析，再一步一步深刻內核裏邊去，也許更好。

前面幾篇DM3730開發攻略講到：一個DAVINCI  DM3730板子程序由xload，uboot, linux-2.6.32或者(linux-2.6.37)，文件系統rootfs和存放在文件系統裏邊的不少應用程序組成，這個順序是從CPU運行的順序排列的，或者從燒到NAND FLASH的角度講：咱們桐燁科技的命名是：dm3730_xload.bin，dm3730_uboot.bin，dm3730_kernel.bin，dm3730_ubifs.bin（裏邊包含不少應用程序，咱們使用ubifs而不是jffs2），有些客戶還加上本身的應用程序app等BIN文件。

 

1、文件系統移植：

在DVSDK4_03安裝包裏邊（不清楚的網友能夠先看看本人在51CTO博客一篇《DAVINCI DM3730開發攻略——DVSDK4_03和雙核CODEC機制介紹》），本人開發目錄dvsdk4_03\filesystem，人家TI（包括合做第3方）已經提供arago-base-tisdk-p_w_picpath-dm37x-evm.tar.gz和dvsdk-dm37x-evm-rootfs.tar.gz，其中arago-base-tisdk-p_w_picpath-dm37x-evm.tar.gz是通過第3方裁剪的文件系統，很是適合燒寫NAND FLASH裏邊，也能夠直接解壓作爲NFS文件系統（NFS環境設置見本人51CTO博客一篇《DAVINCI DM3730開發攻略——開發環境篇》）；而dvsdk-dm37x-evm-rootfs.tar.gz是不通過裁剪的文件系統，裏邊的衆多應用程序、頗有價值的LIB文件、測試程序，包括測試DMAI例程的應用程序、encode應用程序、decode應用程序、wifi應用程序等等，特別關注usr/share/ti裏邊的例子，總之很是豐富，具體有什麼價值，還須要有興趣在這方面開發的網友本身打開文件夾看看。

圖-1 dvsdk-dm37x-evm-rootfs有關TI測試應用程序

 

這個dvsdk-dm37x-evm-rootfs.tar.gz超級大，不適合燒寫到NAND FLASH裏邊去。咱們也是在arago-base-tisdk-p_w_picpath-dm37x-evm.tar.gz基礎上面，把dvsdk-dm37x-evm-rootfs.tar.gz有用的東西COPY過來，而後加上本身開發的應用程序和修改的腳本，同時也對arago-base-tisdk-p_w_picpath-dm37x-evm.tar.gz進行裁剪，才獲得本身產品的文件系統rootfs。這個rootfs能夠作爲NFS測試，也可使用mkfs.ubifs，mkfs.jffs2或者mksquashfs等工具製做燒寫到板子NAND FLASH的產品文件系統(xxx.bin或者xxx.img之類文件)，至於這些文件系統如何製做，這裏再也不累贅，由於衆多網友都寫有不少博客文章進行介紹，特別是omap3530，dm3730的ubifs，本人就不必多說了（題外話，咱們碰到一些客戶對NFS文件系統和燒寫到NAND的文件系統都不知道怎麼回事，就敢作DAVINCI嵌入式產品，只能說他們老總有錢養人和項目燒錢啊，這種客戶咱們如今不敢賣開發板了。如今網絡這麼發達，技術文章很是多，還有其餘幾百塊錢的linux嵌入式開發板多如牛毛，在大學隨便買回來學習學習，一點難事都沒有。從各大門戶網站論壇來看，各路大神都下了論斷，從2015年開始國內企業倒閉潮模式開啓，找工做更難了，若是家境很差的學生還和其餘人醉生夢死去玩，苦果等出到社會慢慢品嚐吧。之前在DM368開發攻略說過，危機有「危」也有「機」，技術過硬的人才仍是很搶手的，畢竟如今是地球村模式，科技仍是一直向前發展的，淘汰的都是些低效低技術門檻的企業）。

 

2、DVSDK視頻應用程序介紹

介紹完文件系統的移植，如今能夠介紹應用程序了，之前寫DM6446開發攻略的時候，沒有單獨介紹，這裏咱們爲了完善DAVINCI開發攻略，補充一下。咱們拿TI DAVINCI最經典的音視頻encode例子來講吧，這個encode 涉及到原始圖像採集和dsp調用，多線程如何配合運行，很是有價值。TI DAVINCI雙核芯片DM6446,DM6467T,DM3730這幾個經典的芯片都是一樣的應用架構。在dvsdk4_03\dvsdk-demos_4_02_00_01\omap3530目錄裏邊，有encode，decode，edge_detection三個例子，其中edge_detection（邊緣檢測）用到c6accel的LIB，側重DSP算法移植，不是很經典，咱們不介紹，decode也比較簡單，就是如何調用h264解碼，mpeg4解碼，jpeg解碼，音頻g711的解碼。咱們仍是選擇encode介紹，看看encode如何錄製h264視頻文件和g711音頻文件（同時修改一下能夠支持mpeg4或者jpeg壓縮）。結合本人的《DAVINCI DM3730開發攻略——DVSDK4_03和雙核CODEC機制介紹》，經過這個encode具體的例子，更加深刻了解雙核的是如何工做的。

要正確編譯encode例子，必須編譯內核linux-2.6.32和其餘相關的元素，最後才能編譯encode的例子，見本人那篇51CTO博客《DAVINCI DM3730開發攻略——DVSDK4_03和雙核CODEC機制介紹》，這篇文章很是重要，順便提一下，其餘元素編譯完後，都產生對應的臨時文件和輸出文件，這些都是下一級要編譯元素的所依賴的文件，你對其中一個make clean等清除命令，後面的元素模塊確定編譯不過去。Encode例子直接調用的是DMAI元素（dvsdk4_03\dmai_2_20_00_15\packages\ti\sdo\dmai），而不是直接去和內核打交道，也不是直接去跟DSP打交道。DMAI就是一個封裝好的中間件，DMAI能夠直接經過open設備節點和內核驅動打交道，可是它也不能直接去調用DSP SERVER，而是去調用codec-engine裏邊的VISA接口，只有codec-engine配合dsplink等元素才能調用DSP SERVER。這裏提到DSP SERVER就是C64+ DSP程序了，一個DSP核只有一個DSP SERVER（就是編譯出來的cs.x64P），而一個SERVER能夠有N個DSP 算法CODECS，就是那一大堆的h264,jpeg,mpeg4編碼解碼，g7十一、aac音頻編碼解碼，以及客戶本身的算法（例如咱們桐燁科技的ty_video_copy算法）。

咱們打開dvsdk4_03\dvsdk-demos_4_02_00_01\omap3530\encode文件夾，先打開Makefile，修改第79行，

#SOURCES = $(wildcard *.c) $(wildcard ../*.c)註釋掉

#HEADERS = $(wildcard *.h) $(wildcard ../*.h)註釋掉

改爲：

SOURCES = $(wildcard *.c)

HEADERS = $(wildcard *.h)

而後把dvsdk4_03\dvsdk-demos_4_02_00_01\omap3530\ctrl.c，ctrl.h，demo.h，ui.c，ui.h  5個文件COPY進encode文件夾，咱們這樣作是由於這幾個文件和decode文件夾共享文件，若是對5個文件修改，會同時影響encode和decode，爲了保持工程的獨立性，咱們仍是COPY到每一個文件裏邊，這時就須要對encode裏邊的差很少每一個源碼文件，凡是使用demo.h等頭文件include的路徑改一下代碼（#include "../demo.h"改爲#include "demo.h"）。之後參考encode創建本身的工程，好比咱們的tvp5158_d1，徹底參考encode例子，幾乎如出一轍，encode裏邊的是encode.cfg，不須要修改，下面就拿這裏邊的文件介紹。

圖-2 encode例子裏邊的源碼

 

Capture.c就是專門負責視頻採集的源碼了，這個會去調用到DMAI目錄下的dvsdk4_03\dmai_2_20_00_15\packages\ti\sdo\dmai\linux源碼函數和dvsdk4_03\dmai_2_20_00_15\packages\ti\sdo\dmai\linux\omap3530源碼函數，裏邊也有對應的Capture.c，只不過這個DMAI裏邊的Captue.c是和li nux內核裏邊V4L2驅動對接，把這源碼打開，好好看看，分析Capture_create()等等函數，一切都明白了，之前寫過的V4L2的文章，均可以對接獲得，DM644六、DM6467T、DM3730一個樣，固然DM814八、DM816八、DM8127就不是這種軟件架構了。一樣encode目錄下的標清視頻CVBS輸出display.c也和Capture.c同樣，跟DMAI目錄下的對應display.c和display_v4l2.c對接。Video.c就是如何調用DSP H264等算法去壓縮採集線程放過來的數據，特別看看Venc1_create()函數和Venc1_process()的調用，經過這兩個函數，能夠在ARM應用程序去訪問DSP算法，而咱們客戶的算法能夠參數這個Venc1的東西，可使用Venc_create()函數和Venc_process()去實現，對應的DMAI接口源碼在dvsdk4_03\dmai_2_20_00_15\packages\ti\sdo\dmai\ce目錄下。至於如何實現，須要你們回去本身慢慢摸索，我這裏點到爲止。去分析DMAI和codec-engine裏邊的VISA接口不是一天兩天就搞明白的。Write.c是專門把video.c壓縮好的H264 BUFFER數據進行文件方式保存（錄製結束後能夠從開發服務器把xxx.264 COPY出來，使用VLC或者暴風影院播放錄製的文件）。Ctrl.c裏邊的線程就是處理相似按鍵和IR這些應用。每一個線程裏邊都是一個while的大循環， 線程間圖像數據BUFFER的管理使用FIFO。TI 提供的這幾個線程間的BUFFER管理比較亂，特別是加上display線程後，錄製的圖像不是很連續，拿來學習是沒問題的，作產品就不行了。

 

3、編譯和運行encode的例子

咱們在《DAVINCI DM3730開發攻略——DVSDK4_03和雙核CODEC機制介紹》介紹如何編譯cmem，sdma，dsplink，lpm，codecs等模塊，特別是總的dvsdk4_03\Makefile和總的路徑環境參數Rules.make，根據總Makefile編譯方法，編譯出來的模塊所有自動COPY到NFS文件系統：

/home/davinci/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk/dsp目錄下，

本人那篇文章特別寫了個腳本，如何編譯這些元素，好比在總的Makefile有個cmem的編譯和install：

cmem_install:

    install -d $(EXEC_DIR)/dsp

    install $(CMEM_INSTALL_DIR)/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko $(EXEC_DIR)/dsp

咱們在總Rules.make最後面一句定義EXEC_DIR，

# Where to copy the resulting executables

EXEC_DIR=/home/davinci/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk

 

編譯完相關的模塊，最後纔去編譯demos，也就是咱們的encode或者本人的tvp5158_d1，直接進到dvsdk4_03\dvsdk-demos_4_02_00_01\omap3530\encode目錄下使用make clean和make，就會獲得encode這個可執行的linux應用程序，你能夠把這個應用程序COPY到NFS文件系統指定的目錄/home/davinci/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk。

 

好了，編譯若是一切OK，並且板子模擬視頻接好，或者麥克風接好，能夠給板子上電，進到NFS模式就行調試，執行如下命令：

在當前目錄下（filesystem/dm3730rootfs/opt/dvsdk）錄製H264視頻文件：

./loadmodule.sh

./encode –v xxxxx.264

錄製G711音頻文件

./loadmodule.sh

./encode –s xxxxx.g711

 

錄製視頻的使用-v參數，錄製音頻使用-s參數，這些都在main.c裏邊有，能夠去分析源碼。

運行10秒~10分鐘，使用Ctrl+C終止運行，那麼在linux服務器對應的NFS文件系統/home/davinci/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk下面獲得剛纔錄製xxx.264文件。

 

這個loadmodule.sh基本內容見下面（桐燁科技DM3730開發板使用的）：

 

# TONGYE Tech. Memory Map for DM3730 EVM without Android

# Start Addr    Size    Description

# -------------------------------------------

# 0x80000000     120 MB  Linux

# 0x87800000     32 MB  CMEM for ARM and DSP

# 0x89800000     104 MB  CODEC SERVER for DSP (20M for DDR2)

insmod /opt/dvsdk/dsp/cmemk.ko phys_start=0x87800000 phys_end=0x89800000 allowOverlap=1 useHeapIfPoolUnavailable=1

insmod /opt/dvsdk/dsp/dsplinkk.ko

insmod /opt/dvsdk/dsp/lpm_omap3530.ko

insmod /opt/dvsdk/dsp/sdmak.ko

 

在另一篇51CTO博文《DAVINCI DM3730開發攻略-U-BOOT-2010.06的移植》提到UBOOT參數bootargs，裏邊有個mem=120M@0x80000000的參數：

這個參數和loadmodule.sh、dvsdk4_03\codecs-omap3530_4_02_00_00\packages\ti\sdo\server\cs目錄下的memmap.tci分配的地址一一對應，mem=120M@0x80000000的意思是從0x80000000這段內存分配給linux，後面緊跟的從0x87800000開始分配的32M專門給CMEM（全部雙核DAVINCI芯片）重要的共享內存段，最後面104M是分配給DSP使用的，ARM和DSP均可以對32M的共享內存進行訪問，上面提到的Capture.c和Video.c使用BufTab_create()函數產生的BUFFER都是指向這個內存，因此客戶本身的算法能夠對從ARM採集到原始的YUV4:2:2數據在DSP端進行圖像分析。上面那些insmod 動態加載幾個重要元素驅動，是必須的，不然沒法去運行DSP SERVER。

 

以上是從encode應用程序角度進一步分析DVSDK軟件架構，對開發DM3730的網友應該有點幫助。這個2014年公司過得比較艱難，公司運營成本愈來愈高，而賣給客戶的產品利潤愈來愈薄（本人認爲中國大部分公司也碰到一樣的問題，企業負擔愈來愈重，大環境愈來愈差），同時也碰到一些合做不愉快的公司，發覺作TI DAVINCI方案，越是高級的CPU開發週期越長，因此大半年沒怎麼寫文章了。作產品和作樣機不是一回事，和大客戶作好一個大批量生產的產品很是耗本人精力，可是爲了公司的生存，也沒辦法。也因爲太累了，公司也調整業務，不太想作開發板了。咱們在DAVINCI方案可以堅持作下去，是因爲TI 的帶DSP的CPU生命週期長，以及幾個合做愉快的老客戶支持。DM3730採集1/4寸COMS 200萬仍是能夠的，功耗低是擺在那裏，一個高清720P智能視頻分析相機功耗居然不到4瓦。很是適合低成本人臉識別，低成本高清IVS產品設計，4CIF雙目分析產品等。固然，要作1080P  60幀高清產品只能使用DM81XX了，不過這個DM81XX方案成本至關貴，功耗通常超過10瓦。

寫了這麼多，但願對在這方面開發的網友有幫助，有錯誤的地方能夠指出更正，謝謝。