基于DSP／BIOS大空間網(wǎng)絡型火災探測系統(tǒng)設計

摘要 針對傳統(tǒng)圖像型火災探測系統(tǒng)以PC作為處理終端，且不能對CCD攝像機進行有效控制等缺點，提出了以TMS320DM642為平臺開發(fā)基于DSP／BIOS的大空間網(wǎng)絡型火災探測系統(tǒng)。該系統(tǒng)在DSP／BIOS與RF5參考框架的基礎上，利用TCP／IP協(xié)議棧設計了多任務線程的應用程序，實現(xiàn)了火災檢測算法的移植與網(wǎng)絡開發(fā)環(huán)境的構建。最終將視頻處理結果由以太網(wǎng)傳至控制中心，同時控制中心可以利用串口通信線程對CCD攝像機進行參數(shù)設置。
關鍵詞 火災探測；TMS320DM642；DSP／BIOS；TCP／IP；RF5

    目前，國內(nèi)主要采用基于PC的圖像型火災探測系統(tǒng)，但該系統(tǒng)視頻傳輸距離有限且采用輪詢的方式，對各通道視頻信號進行分時處理，這樣大大降低了系統(tǒng)的性能。隨著大空間建筑和視頻監(jiān)控系統(tǒng)的普及，使得大空間網(wǎng)絡型火災探測成為可能。所謂“大空間網(wǎng)絡型火災探測”，即采用嵌入式設備作為處理終端，完成數(shù)據(jù)采集和火災識別任務，通過以太網(wǎng)實時將識別結果傳送到遠程監(jiān)控設備，實現(xiàn)早期火災預警，為及時疏散人群提供寶貴的時間，最大程度地減少人員傷亡和經(jīng)濟損失。文中采用美國德州儀器公司的TMS320DM642作為硬件開發(fā)平臺，憑借其高速的數(shù)據(jù)處理能力、豐富的外圍接口、精煉的操作系統(tǒng)以及方便快捷的網(wǎng)絡開發(fā)包，能夠滿足火災探測系統(tǒng)實時性的要求。

1 火災探測系統(tǒng)整體架構
    DM642是TI公司推出的一款專門為數(shù)字媒體應用而設計開發(fā)的32位定點DSP芯片，該芯片采用基于C64x的DSP內(nèi)核，工作頻率最高達720 MHz，處理性能可達5760MI／s。
    火災探測系統(tǒng)主要由視頻采集、串口通信、網(wǎng)絡通信3個模塊組成。系統(tǒng)框架如圖1所示。

    首先，CCD攝像機采集的視頻信號經(jīng)過解碼器送至DM642的VP0口，然后利用DM642的EDMA通道將視頻數(shù)據(jù)儲存在外部SDRAM中，最后將視頻處理結果通過物理層收發(fā)器送入因特網(wǎng)。同時利用UART口對攝像機及云臺進行控制。

2 系統(tǒng)硬件設計
2．1 視頻采集與存儲器擴展
2．1．1 視頻采集
    系統(tǒng)的視頻解碼器采用Philips公司的SAA7113芯片，它支持多種視頻標準，由CPLD中的狀態(tài)／控制寄存器控制，并且由I2C總線對其寄存器進行配置，能將PAL制的模擬視頻信號轉(zhuǎn)換為8位的ITU-RBT．656格式，Y、Cb、C，這3個分量的采樣模式為4：2：2，采樣后將視頻數(shù)據(jù)流發(fā)送到DM642的VP0口。DM642有VP0、VP1、VP2的3個視頻接口，可以根據(jù)用戶需要自行配置輸入與輸出接口。每個視頻接口都分為A、B兩個通道，每個通道都配置有2 560 Byte的緩沖區(qū)，設計人員可以自由設置緩沖區(qū)的傳輸閾值去觸發(fā)相對應的EDMA傳輸通道，然后通過EDMA通道將視頻數(shù)據(jù)送入外掛的SDRAM。[!--empirenews.page--]
2．1．2 外部存儲器擴展
    采用4 M×64位的SDRAM存儲視頻數(shù)據(jù)，采用4M×8位的Flash固化系統(tǒng)的程序代碼。EMIF映射CE0、CE1、CE2、CE3這4個物理地址空間，DM642將CE0配置為64位的同步存儲器接口，將CE1配置為8位的異步靜態(tài)存儲器接口。該系統(tǒng)采集到的視頻為Y：Cb：Cr 4：2：2格式，Y、Cb、Cr這3個分量在SDRAM中的采集緩沖區(qū)與顯示緩沖區(qū)都是分開存儲的。圖像的分辨率為720×576，所以每行Y分量采720個點，Cb、Cr分量各采360個點。每幀圖像的每個分量按奇偶場分開存儲，奇場在前，偶場在后。DM642外部共有20根地址線，即CE1空間的最大尋址范圍為1 Mb×8，映射到CE1空間的除了Flash，還有在CPLD中實現(xiàn)的控制／狀態(tài)寄存器以及8位異步靜態(tài)UART口。所以，最大只能將1／2的CE1空間配置給Flash，即512 kh×8。但是所選用的Flash芯片AM29LV320DB的物理存儲空間為4 Mb×8，所以利用有限的地址線訪問大物理空間時，要采用分頁技術，即將整個4 Mb×8的Flash分成8個512 kb×8的頁，而頁地址PA20、PA19、PA18則有位于CPLD中的頁地址寄存器提供。
2．2 串口通信電路設計
    該設計將信號通過EMIF接口并行引出，經(jīng)過異步收發(fā)器TL16C752B的移位寄存器實現(xiàn)串行傳輸，然后由多協(xié)議收發(fā)器MAX3160將異步串口接口電平配置為RS232標準。TL16C752B采用8位異步并行存儲器接口，可以與DM642的外部存儲器接口無縫連接。TL16C752B具有兩個異步串行轉(zhuǎn)換通道，每個通道包含18個寄存器，通過地址線A0、A1、A2以及LCR寄存器的第7位對寄存器進行字節(jié)尋址。波特率是由晶振頻率、DLL及DLH寄存器共同決定的，該系統(tǒng)對TL16C752B芯片接入的晶振頻率為3．07 MHz。線路控制寄存器(LCR)控制數(shù)據(jù)傳輸?shù)母袷剑ㄗ珠L、停止位個數(shù)以及校驗類型的選擇，系統(tǒng)通過寫寄存器操作對其配置的結果為：8位字長、1個停止位、奇偶校驗。TL16C752B芯片的外圍電路如圖2所示。

2．3 以太網(wǎng)接口電路設計
    DM642的網(wǎng)絡接口主要由EMAC(Ethernet MAC)與MDIO(Management Data Input／Output)兩部分組成。DM642的網(wǎng)路接口屬于鏈路層，主要負責與支持物理層的網(wǎng)絡器件相連接，其中EMAC負責DSP與以太網(wǎng)之間數(shù)據(jù)包的交換，MDIO負責物理層收發(fā)器的配置以及狀態(tài)監(jiān)視。該網(wǎng)絡接口符合IEEE 802．3標準。物理層收發(fā)器(PHY)的外圍電路示意圖如圖3所示。

3 系統(tǒng)軟件實現(xiàn)
    系統(tǒng)的主要任務是實現(xiàn)視頻數(shù)據(jù)的采集、處理以及數(shù)據(jù)的網(wǎng)絡收發(fā)。系統(tǒng)軟件模型由兩部分組成：驅(qū)動程序與應用程序。驅(qū)動程序直接控制底層物理器件的行為，是由提供給DSP／BIOS的若干個API函數(shù)組成。應用程序是在DSP／BIOS實時操作系統(tǒng)上，依據(jù)TI的RF5框架進行編寫設計的。根據(jù)應用程序的各個功能模塊，創(chuàng)建不同的任務線程實現(xiàn)整個系統(tǒng)軟件的開發(fā)。RF5是德州儀器(TI)公司新近推出的DSP軟件開發(fā)參考框架，以DSP／BIOS為基礎，利用其中的數(shù)據(jù)處理單元和數(shù)據(jù)通信單元方便快捷的完成DSP系統(tǒng)軟件的設計與開發(fā)。在DSP／BIOS中，任務的調(diào)度是通過HWI、SWI和TSK這3個模塊實現(xiàn)，DSP／BIOS通過各模塊優(yōu)先級的不同完成對各任務線程的調(diào)度。[!--empirenews.page--]
    系統(tǒng)軟件設計流程如圖4所示。首先對DSP／BIOS模塊進行靜態(tài)配置，包括設置內(nèi)、外部存儲器的映射空間，創(chuàng)建多任務線程及所需堆棧，配置TI網(wǎng)絡開發(fā)包NDK的啟動環(huán)境，分配旗語、郵箱通信機制的存儲位置及大小等。其中創(chuàng)建的多任務線程包括系統(tǒng)控制任務、視頻輸入任務、算法處理任務、圖像JPEG壓縮任務、網(wǎng)絡初始化任務、串口通信任務。在應用程序進入DSE／BIOS線程調(diào)度器之前，處理器需要完成3個模塊的初始化：(1)芯片板級間的初始化，包括CSL、RAM、Cache及EDMA的設置。(2)RF5模塊的初始化，包括通道模塊，SCOM模塊及ICC模塊。一個任務可以創(chuàng)建多個通道，每個通道可以包含多個內(nèi)核，每個內(nèi)核只能包含一種標準算法。(3)視頻捕獲(FVID)通道的建立與啟動。

    應用程序的Main()函數(shù)在完成系統(tǒng)初始化任務后退出，程序控制權正式交給DSP／BIOS任務線程調(diào)度器，根據(jù)優(yōu)先級和RF5中的任務切換準則調(diào)度各任務線程。為保證網(wǎng)絡傳輸?shù)膶崟r性，應將網(wǎng)絡初始化任務的優(yōu)先級配置成高于其他任務的優(yōu)先級。處于同一優(yōu)先級的任務之間利用同步通信機制SCOM模塊進行信息傳遞，同時基于RF5的SCOM通信機制內(nèi)部，制定了任務調(diào)用及切換規(guī)則，這樣就避免了多個任務同時訪問一個隊列指針的情況。
3．1 視頻輸入任務
    系統(tǒng)主線程已經(jīng)創(chuàng)建且打開了視頻捕獲通道，并初始化了FVID對象。該任務首先啟動SCOM消息隊列，從捕獲通道的緩沖區(qū)獲取一幀圖片，然后利用SCOM隊列指針將視頻數(shù)據(jù)傳輸至算法處理任務。此時，該任務處于阻塞狀態(tài)，等待算法處理任務接收完成的返回消息，系統(tǒng)切換至算法處理任務，直到接收到返回消息，視頻輸入任務才處于等待狀態(tài)，等待下一個循環(huán)重新采集視頻。每一個任務都不斷地處于等待消息與處理數(shù)據(jù)的狀態(tài)中。
3．2 算法處理任務
    該任務分別創(chuàng)建了火焰檢測通道對象FIRE_CHAN_Obj與煙霧檢測通道對象SMOCK_CHAN_Obj。每一個核對像都要在被初始化以后再調(diào)用注冊函數(shù)CHAN_regCell()，通過這種方式可以將每一個核對象注冊到相應的任務通道中。最后，線程調(diào)用函數(shù)CHAN_open()為每個指定的通道(chanNum)傳遞核對像，這樣通道通過調(diào)用核對像來執(zhí)行檢測算法。煙霧檢測算法流程如圖5所示。

[!--empirenews.page--]
    當算法處理任務接收到SCOM隊列送來的視頻數(shù)據(jù)后，分別送入火焰與煙霧兩個檢測通道。如果發(fā)現(xiàn)火焰或者煙霧疑似區(qū)域，兩個通道會分別將區(qū)域坐標返回，利用返回的坐標對疑似區(qū)域進行定位跟蹤，然后將跟蹤結果送入JPEG圖像壓縮任務；如果兩個通道都沒有返回疑似區(qū)域坐標，則直接將原始視頻數(shù)據(jù)送至下一個任務。煙霧檢測算法分為圖像預處理模塊、圖像分割模塊、特征提取模塊、目標識別及坐標提取模塊，這4個算法模塊分別對應4個核對像。核與核以及核與通道之間采用ICC模塊進行通信，任務通道通過調(diào)用這些核對象來完成對整個煙霧檢測算法的執(zhí)行過程。煙霧一般分為白煙、黃煙和黑煙，難以從顏色或形狀上對其進行檢測，所以應該對煙霧的半透明性、整體移動性、邊界閃爍性、主方向性和擴散性等方面進行分析。
3．3 網(wǎng)絡傳輸任務
    TI公司結合其C6000系列芯片推出的NDK(Network Developer‘s Kit)網(wǎng)絡開發(fā)包采用緊湊的設計方法，實現(xiàn)了利用較少的資源消耗來支持TCP／IP協(xié)議棧，在實際應用中，NDK僅用約200 kB的程序空間和95 kB數(shù)據(jù)空間即可支持常規(guī)的TCP／IP服務，其中包括應用層的telnet、DHCP、HTTP等。同時NDK還集成了類似于網(wǎng)卡的物理層收發(fā)器的驅(qū)動程序。
    NDK開發(fā)包包括Network Tools、OS Adaptation Layer、TCP／IP Stack Library、Hardware Adaptation Layer、Network Control這5個模塊，要開發(fā)基于NDK的網(wǎng)絡應用程序，必須利用以上5個模塊構建一個完整的TCP／IP功能環(huán)境。首先靜態(tài)創(chuàng)建網(wǎng)絡初始化任務，在該任務中構建TCP／IP協(xié)議棧的過程是：(1)在調(diào)用協(xié)議棧其他API函數(shù)之前，必須先調(diào)用函數(shù)NC_SystemOpen()，用它來初始化協(xié)議棧及系統(tǒng)環(huán)境，它的兩個參數(shù)Priority和OpMode分別決定了調(diào)度任務的優(yōu)先級和調(diào)度器何時開始執(zhí)行。(2)調(diào)用函數(shù)CfgNew()創(chuàng)建新的協(xié)議棧配置，返回配置句柄hCfg，對該句柄添加網(wǎng)絡層與應用層的相關配置。(3)調(diào)用函數(shù)NC_NetStart()來啟動網(wǎng)絡事件調(diào)度器。真正的網(wǎng)絡收發(fā)任務是由NetworkRx和NetworkTx完成，這兩個任務就是在指針NetworkIPAddr所指的函數(shù)中通過TaskCreate動態(tài)創(chuàng)建的。在系統(tǒng)結束時還會調(diào)用函數(shù)CfgFree()與NC_SystemClose()分別用來釋放配置內(nèi)存及關閉TCP／IP協(xié)議棧。
    設計在NetworkRx、NetworkTx任務中開發(fā)的是基于Client／Server與Browser／Server兩種模式的應用程序。在Client／Server模式中，DM642作為服務器，PC作為客戶端，由于該系統(tǒng)對實時性的要求較高且允許在一定范圍內(nèi)的丟包及出錯現(xiàn)象發(fā)生，所以NetworkTx在傳輸層采用面向無連接的UDP協(xié)議。NetworkRx接收的是PC對DM642的控制命令，即服務器、客戶端雙方定義好的少數(shù)數(shù)據(jù)結構，所以NetworkRx在傳輸層采用了面向連接的TCP協(xié)議。該模式下的應用程序是采用Socket網(wǎng)絡編程的方式進行開發(fā)的，以太網(wǎng)在鏈路層的最大傳輸單元為1500Byte，所以必須對每幀視頻在IP層進行分片操作。同時需要在上位機上開發(fā)基于VC++6．0的客戶端程序，為實現(xiàn)視頻數(shù)據(jù)高質(zhì)量的顯示效果，系統(tǒng)采用微軟公司推出的流媒體處理開發(fā)包Directshow對視頻數(shù)據(jù)進行譯碼顯示。
    在Browser／Server模式中，利用DM642的嵌入式文件系統(tǒng)創(chuàng)建Web服務器，便于將火災現(xiàn)場的視頻信息以網(wǎng)頁的形式送入局域網(wǎng)，再經(jīng)過路由器的端口映射傳至因特網(wǎng)。例如，在局域網(wǎng)內(nèi)部設置Web服務器的IP地址為192．168．0．11，在地址欄輸入該地址，Web服務器訪問結果如圖6所示。

4 結束語
    通過實例介紹了基于DSP／BIOS的大空間網(wǎng)絡型火災探測系統(tǒng)的具體開發(fā)流程。利用對TMS320DM642外圍電路的分析和對接口驅(qū)動芯片的詳細闡述，開發(fā)了基于DSE／BIOS與RF5系統(tǒng)架構的應用程序。另外，系統(tǒng)把煙霧、火焰檢測算法集成于RF5架構的算法內(nèi)核，并且采用TI的NDK進行網(wǎng)絡開發(fā)，這樣將更加有利于系統(tǒng)的移植以及產(chǎn)品的升級與推廣。