随着时代的发展，dsp技术在远程监控、可视电话、工业检测等视频处理领域得到了广泛的应用，对于不同的视频处理系统，会使用不同的视频设备，所以有必要为视频没备设计驱动程序，为高层应用程序提供统一的接口来操作底层硬件。只要是遵循此驱动程序接口标准开发的高层应用程序，都可以在具有相同接口的不同硬件平台上运行，具有很好的通用性和可移植性。同时高层应用程序设计人员只要会使用设备驱动程序提供的api接口，就不必了解底层硬件的具体实现，可以大大提高整个视频系统的开发效率。

　　对于视频设备，ti公司也提出了对应的视频设备驱动程序模型，但这些模型主要是针对6000系列高端dsp，甚至是dm64x这样的视频处理专用dsp设计的。而tms320f2812(简称f2812)dsp这样的低端处理器，内部存储空间较小，且没有dm64x那样专用的视频接口。本文针对这类问题，提出了对ti视频驱动模型进行简化和改造的方法，使视频设备驱动程序占用尽量少的系统资源，来完成对视频硬件设备的操作。这种视频驱动模型的裁减方法，对于使用低端处理器的视频处理系统具有借可鉴性。

　　1、基于dsp／bios的外设

　　ti公司为开发dsp的外设驱动程序，推出了dsp／bios device driver kit，定义了标准的设备驱动模型，并提供了一系列的api接口。如图1所示，外设驱动程序分为两层：

　　①类驱动(class driver)。类驱动程序用来为应用程序提供接口。这部分程序与设备无关，主要功能包括维护设备数据缓冲区，向上提供api接口供应用层程序调用，并协调应用程序对外设操作的同步和阻塞；向下提供适配层与迷你驱动层相连，实现api接口函数到迷你驱动层程序的映射。类驱动程序与硬件无关，只要外设驱动模型选定了，类驱动程序就定下来了，不需要做多少修改。

　　②迷你驱动(mini driver)。迷你驱动程序与设备相关，所以设计迷你驱动程序是外设驱动开发中的重点。迷你驱动程序与类驱动层的接口格式是统一的，但迷你驱动程序对底层硬件的操作是根据硬件平台的不同而变化的。迷你驱动接收类驱动层发出的iom_packet命令包，决定对底层硬件进行什么样的操作。

　　外设驱动程序模型又可以分为以下3类：

　　①pip/pi0模型。基于数据管道的i／o模型，每个管道都在维护自己的一个缓冲区。当数据写入缓冲区，或从缓冲区取出数据时，便会激发notifyreader和notifywriter函数实现数据的同步。

　　②sio／dio模型。基于数据流的i／o模型，一个数据流是单向的，要么是输入，要么是输出，而且sio／dio模璎使用异步方式来操作i／0，对于数据的读写、处理可以同时进行。

　　③gi0模型。通用的i／o模型，灵活性很强，且没有适配层，直接操作迷你驱动程序，主要用来设计新型的设备驱动模型。

　　2、视频处理系统硬件平台

　　硬件平台如图2所示。系统以ti公司的f2812 dsp作为中心处理器，以模拟摄像机进行视频信号采集，再使用saa7111视频解码芯片将其转换为bt601格式的数字视频信号。dsp将数字视频信号处理后，再写入输出帧缓存al422中，并控制视频编码芯片adv7177，将其转换为模拟电视信号输出。整个系统以l片cpld——ispmachlc4128来协调各个芯片之间的时序关系。

　　3、视频设备驱动程序开发

　　3．1 设备驱动程序模型的选择

　　如上文介绍，常用的驱动程序模型包括3类：pio、sio和gio。比较这3种模型可以知道：pio支持更底层的通信，适合设计比较简单的外设驱动程序。例如在ti公司的6x11dsk板上实现的音频采集和回放，一般都是基于pio模型的。而sio模型具有很好的缓冲器分配回收机制，比较适合描述视频设备，但是sio的很多功能在本系统中使用不到，而且gio模型设计的目的就是针对特殊硬件的新型设备，所以最终考虑使用gio设备驱动模型。

　　ti公司最初设计的gio模型其实是有缺陷的，主要在数据缓冲区管理的问题上，应用程序在取得缓冲区进行数据处理之后，却无法将缓冲区返回设备驱动程序。于是ti公司在推出dm6北这一款主要用于视频处理的dsp芯片的同时，对gio模型进行了改进，提出了专门针对视频设备的fvid模型。fvid模型是建立在gio模型之上的，以fvid_alloc、fvid_exchangc、fvid_free函数对gio模型中的gio_submit函数进行封装，解决了gio模型中驱动程序不能回收缓冲区的问题。