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編碼解碼，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，不需要修改，下面就拿這里邊的文件介紹。
圖-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音頻文件
./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瓦。
寫了這么多，希望對在這方面開發的網友有幫助，有錯誤的地方可以指出更正，謝謝。
?
總結
以上是生活随笔為你收集整理的DAVINCI DM3730开发攻略——应用程序例程分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 问道图语言_GraphQL_v1.0.0
- 下一篇： 2n字符