基于视频处理的DSP系统通用设计模式及其实现

元和算法接口。OS层由不同的多个任务组成，每个任务可以包含一系列的通道，而每个通道又可以包含一系列的外包单元，其中一个外包单元对应一个算法接口的封装；每个算法代码都可以重复使用，通过调用不同的对象来实现一个算法的多个例程在不同通道中的使用。

　　2) 数据传递方面：

　　A. 任务级的数据传递，是基于旗语同步的。在任务与驱动之间通常采用DSP/BIOS中的SIO对象(针对音频系统)或GIO对象(针对视频系统)指明数据的位置来进行交互，而在多个任务之间则采用RF5提供的SCOM消息队列机制通过识别不同的队列名和指明相应的数据位置来互传信息。

　　B. 外包单元级的数据传递。每个外包单元都有其输入列表和输出列表，这些列表里存放了由RF5提供的ICC对象用于指明数据的位置，通过各列表中包含相同的ICC对象来实现各外包单元间的交互。此外，通过ICC对象可以完成任务级数据和外包单元级数据之间的交互。

　　3) 消息控制。对于信息少的控制消息可以采用DSP/BIOS中的邮箱机制通过搬移指令的内容单向的在任务间传递指令，而对于信息多的控制消息则可以使用SCOM消息队列机制通过识别不同的队列名和指明相应的数据位置在任务间传递指令。

　　图7中示出了基于视频处理与RF5的一般OS层构架示意图，可以通过增加任务来扩充其它如网络传输、音频处理等功能(需要相应的硬件和底层驱动支持)。从图中可以看到，以双通道及每通道内两外包单元的情况为例，图像数据从ADC出来后经过输入设备驱动存放在GIO对象所指的数据位置，任务tskCapture通过调用GIO对象对其所指的数据进行格式及大小等的简单变换，再将结果数据存入SCOM消息指定的位置并通过SCOM队列向任务tskProcess发送该消息；当任务tskProcess接收到该消息后，对其所指的数据按具体要求的算法进行处理，其中一个外包单元实现一个算法例程，一个通道则实现一路功能上已独立且算法间先后关联的算法组；当任务tskProcess处理数据完成后，将结果再次存入SCOM消息指定的位置并向任务tskDisplay发送消息；任务tskDisplay收到消息后会对所指数据做格式及大小等的简单变换，以便通过GIO对象发送给输出设备驱动从而在DAC后端显示；任务tskControl通过接收主机端的控制消息来对任务tskProcess的处理过程进行控制。

基于本文上述讨论的系统框架模型可通过图7定制适合其硬件结构的如图8中所示的简化的OS层构架。与图7中相比，图8中只有算法的处理和控制两个任务从而提高了DSP在算法处理上的效率，而ADC和DAC的配置则在系统上电后的初始化中完成，此后ADC和DAC不需要DSP的介入而通过CPLD/FPGA中的逻辑实现了图像数据按要求的格式和大小在存储器子模块中的存放从而在某种程度上减轻了DSP的负担。

设计思路的具体应用

　　依照以上的思路实现整个系统的设计主要通过下列四步的完成：

　　1) 根据实际需要选择适当的器件，完成整个系统硬件层次上的连接；

　　2) 针对具体情况定制系统中使用的可编程逻辑器件的内部逻辑；

　　3) 编写适合具体电路的程序代码，实现整个系统软件层次上的构架；

　　4) 将指定的视频处理算法嵌入在该构架中。

　　按上述四步，选用TVP5150A(ADC)、SAA7105(DAC)、XC95288XL(CPLD)各一片和三片IS61LV2568L(SRAM)为主要器件，在数字信号处理仿真/教学实验系统DES3200的二次开发接口上完成了基于可通用模式的DES3200图像处理子卡II的设计，如图9中左所示；并配合TMS320C6713B(DSP)子卡得到了CIF格式的视频预处理的显示结果，如图9中右所示。进而，证明该通用设计模式是可行的。