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-image-dm37x-evm.tar.gz和dvsdk-dm37x-evm-rootfs.tar.gz，其中arago-base-tisdk-image-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裡邊的例子，總之非常豐富，具體有什麼價值，還需要有興趣在這方面開發的網友自己打開檔案夾看看。

<a href="http://s3.51cto.com/wyfs02/M02/59/D8/wKioL1TtPjXBTqeyAAGgU7vwlxc721.jpg" target="_blank"></a>

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

這個dvsdk-dm37x-evm-rootfs.tar.gz超級大，不适合燒寫到NAND FLASH裡邊去。我們也是在arago-base-tisdk-image-dm37x-evm.tar.gz基礎上面，把dvsdk-dm37x-evm-rootfs.tar.gz有用的東西COPY過來，然後加上自己開發的應用程式和修改的腳本，同時也對arago-base-tisdk-image-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編碼解碼，g711、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，不需要修改，下面就拿這裡邊的檔案介紹。

<a href="http://s3.51cto.com/wyfs02/M02/59/DC/wKiom1TtPUexTKpzAAGZlemaUJU370.jpg" target="_blank"></a>

圖-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的文章，都可以對接得到，DM6446、DM6467T、DM3730一個樣，當然DM8148、DM8168、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音頻檔案

./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瓦。

寫了這麼多，希望對在這方面開發的網友有幫助，有錯誤的地方可以指出更正，謝謝。

本文轉自 zjb_integrated 51CTO部落格，原文連結：http://blog.51cto.com/zjbintsystem/1615150，如需轉載請自行聯系原作者