基于DSP／BIOS大空间网络型火灾探测系统设计

出处：imaway 发布于：2012-08-29 17:22:54

　　摘要：针对传统图像型火灾探测系统以PC作为处理终端，且不能对CCD摄像机进行有效控制等缺点，提出了以TMS320DM642为平台开发基于DSP／BIOS的大空间网络型火灾探测系统。该系统在DSP／BIOS与RF5参考框架的基础上，利用TCP／IP协议栈设计了多任务线程的应用程序，实现了火灾检测算法的移植与网络开发环境的构建。终将视频处理结果由以太网传至控制中心，同时控制中心可以利用串口通信线程对CCD摄像机进行参数设置。

　　目前，国内主要采用基于PC的图像型火灾探测系统，但该系统视频传输距离有限且采用轮询的方式，对各通道视频信号进行分时处理，这样大大降低了系统的性能。随着大空间建筑和视频监控系统的普及，使得大空间网络型火灾探测成为可能。所谓“大空间网络型火灾探测”，即采用嵌入式设备作为处理终端，完成数据采集和火灾识别任务，通过以太网实时将识别结果传送到远程监控设备，实现早期火灾预警，为及时疏散人群提供宝贵的时间，地减少人员伤亡和经济损失。文中采用美国德州仪器公司的TMS320DM642作为硬件开发平台，凭借其高速的数据处理能力、丰富的外围接口、精炼的操作系统以及方便快捷的网络开发包，能够满足火灾探测系统实时性的要求。

　　1 火灾探测系统整体架构

　　DM642是TI公司推出的一款专门为数字媒体应用而设计开发的32位定点DSP芯片，该芯片采用基于C64x的DSP内核，工作频率达720 MHz，处理性能可达5760MI／s。

　　火灾探测系统主要由视频采集、串口通信、网络通信3个模块组成。系统框架如图1所示。

系统框架如图1

　　首先，CCD摄像机采集的视频信号经过解码器送至DM642的VP0口，然后利用DM642的EDMA通道将视频数据储存在外部SDRAM中，将视频处理结果通过物理层收发器送入因特网。同时利用UART口对摄像机及云台进行控制。

　　2 系统硬件设计

　　2．1 视频采集与存储器扩展

　　2．1．1 视频采集

　　系统的视频解码器采用Philips公司的SAA7113芯片，它支持多种视频标准，由CPLD中的状态／控制寄存器控制，并且由I2C总线对其寄存器进行配置，能将PAL制的模拟视频信号转换为8位的ITU-RBT．656格式，Y、Cb、C，这3个分量的采样模式为4：2：2，采样后将视频数据流发送到DM642的VP0口。DM642有VP0、VP1、VP2的3个视频接口，可以根据用户需要自行配置输入与输出接口。每个视频接口都分为A、B两个通道，每个通道都配置有2 560 Byte的缓冲区，设计人员可以自由设置缓冲区的传输阈值去触发相对应的EDMA传输通道，然后通过EDMA通道将视频数据送入外挂的SDRAM。

　　2．1．2 外部存储器扩展

　　采用4 M×64位的SDRAM存储视频数据，采用4M×8位的Flash固化系统的程序代码。EMIF映射CE0、CE1、CE2、CE3这4个物理地址空间，DM642将CE0配置为64位的同步存储器接口，将CE1配置为8位的异步静态存储器接口。该系统采集到的视频为Y：Cb：Cr 4：2：2格式，Y、Cb、Cr这3个分量在SDRAM中的采集缓冲区与显示缓冲区都是分开存储的。图像的分辨率为720×576，所以每行Y分量采720个点，Cb、Cr分量各采360个点。每帧图像的每个分量按奇偶场分开存储，奇场在前，偶场在后。DM642外部共有20根地址线，即CE1空间的寻址范围为1 Mb×8，映射到CE1空间的除了Flash，还有在CPLD中实现的控制／状态寄存器以及8位异步静态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接口并行引出，经过异步收发器TL16C752B的移位寄存器实现串行传输，然后由多协议收发器MAX3160将异步串口接口电平配置为RS232标准。TL16C752B采用8位异步并行存储器接口，可以与DM642的外部存储器接口无缝连接。TL16C752B具有两个异步串行转换通道，每个通道包含18个寄存器，通过地址线A0、A1、A2以及LCR寄存器的第7位对寄存器进行字节寻址。波特率是由晶振频率、DLL及DLH寄存器共同决定的，该系统对TL16C752B芯片接入的晶振频率为3．07 MHz。线路控制寄存器(LCR)控制数据传输的格式，包括字长、停止位个数以及校验类型的选择，系统通过写寄存器操作对其配置的结果为：8位字长、1个停止位、奇偶校验。TL16C752B芯片的外围电路如图2所示。

TL16C752B芯片的外围电路如图2

　　2．3 以太网接口电路设计

　　DM642的网络接口主要由EMAC(Ethernet MAC)与MDIO(Management Data Input／Output)两部分组成。DM642的网路接口属于链路层，主要负责与支持物理层的网络器件相连接，其中EMAC负责DSP与以太网之间数据包的交换，MDIO负责物理层收发器的配置以及状态监视。该网络接口符合IEEE 802．3标准。物理层收发器(PHY)的外围电路示意图如图3所示。

物理层收发器(PHY)的外围电路示意图如图3

　　3 系统软件实现

　　系统的主要任务是实现视频数据的采集、处理以及数据的网络收发。系统软件模型由两部分组成：驱动程序与应用程序。驱动程序直接控制底层物理器件的行为，是由提供给DSP／BIOS的若干个API函数组成。应用程序是在DSP／BIOS实时操作系统上，依据TI的RF5框架进行编写设计的。根据应用程序的各个功能模块，创建不同的任务线程实现整个系统软件的开发。RF5是德州仪器(TI)公司新近推出的DSP软件开发参考框架，以DSP／BIOS为基础，利用其中的数据处理单元和数据通信单元方便快捷的完成DSP系统软件的设计与开发。在DSP／BIOS中，任务的调度是通过HWI、SWI和TSK这3个模块实现，DSP／BIOS通过各模块优先级的不同完成对各任务线程的调度。

　　系统软件设计流程如图4所示。首先对DSP／BIOS模块进行静态配置，包括设置内、外部存储器的映射空间，创建多任务线程及所需堆栈，配置TI网络开发包NDK的启动环境，分配旗语、邮箱通信机制的存储位置及大小等。其中创建的多任务线程包括系统控制任务、视频输入任务、算法处理任务、图像JPEG压缩任务、网络初始化任务、串口通信任务。在应用程序进入DSE／BIOS线程调度器之前，处理器需要完成3个模块的初始化：(1)芯片板级间的初始化，包括CSL、RAM、Cache及EDMA的设置。(2)RF5模块的初始化，包括通道模块，SCOM模块及ICC模块。一个任务可以创建多个通道，每个通道可以包含多个内核，每个内核只能包含一种标准算法。(3)视频捕获(FVID)通道的建立与启动。

系统软件设计流程如图4

　　应用程序的Main()函数在完成系统初始化任务后退出，程序控制权正式交给DSP／BIOS任务线程调度器，根据优先级和RF5中的任务切换准则调度各任务线程。为保证网络传输的实时性，应将网络初始化任务的优先级配置成高于其他任务的优先级。处于同一优先级的任务之间利用同步通信机制SCOM模块进行信息传递，同时基于RF5的SCOM通信机制内部，制定了任务调用及切换规则，这样就避免了多个任务同时访问一个队列指针的情况。

　　3．1 视频输入任务

　　系统主线程已经创建且打开了视频捕获通道，并初始化了FVID对象。该任务首先启动SCOM消息队列，从捕获通道的缓冲区获取一帧图片，然后利用SCOM队列指针将视频数据传输至算法处理任务。此时，该任务处于阻塞状态，等待算法处理任务接收完成的返回消息，系统切换至算法处理任务，直到接收到返回消息，视频输入任务才处于等待状态，等待下一个循环重新采集视频。每一个任务都不断地处于等待消息与处理数据的状态中。

　　3．2 算法处理任务

　　该任务分别创建了火焰检测通道对象FIRE_CHAN_Obj与烟雾检测通道对象SMOCK_CHAN_Obj。每一个核对像都要在被初始化以后再调用注册函数CHAN_regCell()，通过这种方式可以将每一个核对象注册到相应的任务通道中。，线程调用函数CHAN_open()为每个指定的通道(chanNum)传递核对像，这样通道通过调用核对像来执行检测算法。烟雾检测算法流程如图5所示。

烟雾检测算法流程如图5

　　当算法处理任务接收到SCOM队列送来的视频数据后，分别送入火焰与烟雾两个检测通道。如果发现火焰或者烟雾疑似区域，两个通道会分别将区域坐标返回，利用返回的坐标对疑似区域进行定位跟踪，然后将跟踪结果送入JPEG图像压缩任务；如果两个通道都没有返回疑似区域坐标，则直接将原始视频数据送至下一个任务。烟雾检测算法分为图像预处理模块、图像分割模块、特征提取模块、目标识别及坐标提取模块，这4个算法模块分别对应4个核对像。核与核以及核与通道之间采用ICC模块进行通信，任务通道通过调用这些核对象来完成对整个烟雾检测算法的执行过程。烟雾一般分为白烟、黄烟和黑烟，难以从颜色或形状上对其进行检测，所以应该对烟雾的半透明性、整体移动性、边界闪烁性、主方向性和扩散性等方面进行分析。

　　3．3 网络传输任务

　　TI公司结合其C6000系列芯片推出的NDK(Network Developer's Kit)网络开发包采用紧凑的设计方法，实现了利用较少的资源消耗来支持TCP／IP协议栈，在实际应用中，NDK仅用约200 kB的程序空间和95 kB数据空间即可支持常规的TCP／IP服务，其中包括应用层的telnet、DHCP、HTTP等。同时NDK还集成了类似于网卡的物理层收发器的驱动程序。

　　NDK开发包包括Network Tools、OS Adaptation Layer、TCP／IP Stack Library、Hardware Adaptation Layer、Network Control这5个模块，要开发基于NDK的网络应用程序，必须利用以上5个模块构建一个完整的TCP／IP功能环境。首先静态创建网络初始化任务，在该任务中构建TCP／IP协议栈的过程是：(1)在调用协议栈其他API函数之前，必须先调用函数NC_SystemOpen()，用它来初始化协议栈及系统环境，它的两个参数Priority和OpMode分别决定了调度任务的优先级和调度器何时开始执行。(2)调用函数CfgNew()创建新的协议栈配置，返回配置句柄hCfg，对该句柄添加网络层与应用层的相关配置。(3)调用函数NC_NetStart()来启动网络事件调度器。真正的网络收发任务是由NetworkRx和NetworkTx完成，这两个任务就是在指针NetworkIPAddr所指的函数中通过TaskCreate动态创建的。在系统结束时还会调用函数CfgFree()与NC_SystemClose()分别用来释放配置内存及关闭TCP／IP协议栈。

　　设计在NetworkRx、NetworkTx任务中开发的是基于Client／Server与Browser／Server两种模式的应用程序。在Client／Server模式中，DM642作为服务器，PC作为客户端，由于该系统对实时性的要求较高且允许在一定范围内的丢包及出错现象发生，所以NetworkTx在传输层采用面向无连接的UDP协议。NetworkRx接收的是PC对DM642的控制命令，即服务器、客户端双方定义好的少数数据结构，所以NetworkRx在传输层采用了面向连接的TCP协议。该模式下的应用程序是采用Socket网络编程的方式进行开发的，以太网在链路层的传输单元为1500Byte，所以必须对每帧视频在IP层进行分片操作。同时需要在上位机上开发基于VC++6．0的客户端程序，为实现视频数据高质量的显示效果，系统采用微软公司推出的流媒体处理开发包Directshow对视频数据进行译码显示。

　　在Browser／Server模式中，利用DM642的嵌入式文件系统创建Web服务器，便于将火灾现场的视频信息以网页的形式送入局域网，再经过路由器的端口映射传至因特网。例如，在局域网内部设置Web服务器的IP地址为192．168．0．11，在地址栏输入该地址，Web服务器访问结果如图6所示。

Web服务器访问结果如图6

　　4 结束语

　　通过实例介绍了基于DSP／BIOS的大空间网络型火灾探测系统的具体开发流程。利用对TMS320DM642外围电路的分析和对接口驱动芯片的详细阐述，开发了基于DSE／BIOS与RF5系统架构的应用程序。另外，系统把烟雾、火焰检测算法集成于RF5架构的算法内核，并且采用TI的NDK进行网络开发，这样将更加有利于系统的移植以及产品的升级与推广。