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

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

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

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

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

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

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

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

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

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