Linux 系统下 USB 摄像头驱动开发(2008-07-05 11:37:47) 标签：it 分类：linux 设备驱动 摘要：介绍了在 Iinux 系统下开发符合 Video for Linux 标准的 USB 摄像头驱动的方法， 并对该标准提出“不间断采集”的改进思路，配合双 URB、双帧缓冲等方法，提高采集速 度。 关键词：Linux 设备驱动 USB 摄像头 Video for Linux 不间断采集 USB 摄像头以其良好的性能和低廉的价格得到广泛应用。同时因其灵活、方便的特性，易 于集成到嵌入式系统中。但是如果使用现有的符合 Video for Linux 标准的驱动程序配 合通用应用程序，难以充分利用 USB 带宽，帧速不高，不易满足实时监控等要求。本文 首先介绍在 Linux 系统下 USB 摄像头驱动编制的一般方法，然后说明在此基础上如何提 高帧速。 1 Linux 系统中的 USB 摄像头驱动程序 USB 设备驱动程序完全符合通用设备驱动的准则，不同的是内核提供了一些特别的 API 函数，方便驱动注册、销毁自己，例如 usb_reSister()和 usb_dereSister()；2．4 版的 内核还提供了对于 hotplug 的支持。 1．1 USB 摄像头驱动的一般编写方法 摄像头属于视频类设备。在目前的 Linux 核心中，视频部分的标准是 Video for Linux(简 称 V4L)。这个标准其实定义了一套接口，内核、驱动、应用程序以这个接口为标准进行 交流。目前的 V4L 涵盖了视、音频流捕捉及处理等内容，USB 摄像头也属于它支持的范畴。 因此，USB 摄像头的驱动应当与内核提供的视频驱动挂钩。即首先在驱动中声明一个 video_device 结构，并为其指定文件操作函数指针数组．fops，向系统注册。在应用程 序发出文件操作的相关命令时，核心根据这些指针调用相应函数，并将该结构作为参数 传递给它们。这样，就完成了驱动和核心之间的通信。例如： static struct video_device vdev_template＝{……}； ／／声明 video_device，指出挂接驱动 static struct file_operations ov511_fops＝{……}； ／／声明本驱动的文件操作函数指针 struct video_device*vdev＝video_devdata(file)； 

／／从文件指针中提取出 video_device 结构 在 video_device 结构中，有一个私有指针 priv，可以将它指向一块保留内存。在这块内 存中，保存着本驱动、本设备的相关初始化信息。这块内存的申请、初始化、指针指向 等工作都是在 USB 驱动的枚举函数.probe 中完成。这样，在枚举函数将控制权返还给系 统后，因为内核不销毁保留内存，所以驱动仍然保留着自己的信息。这点与 Windows 系 统中 WDM 驱动有异曲同工之处。当然，在驱动卸载函数中，应当将申请的各块内存全部 释放。 1．2 使用双 URB 轮流通信 众所周知，USBl．1 总线标准定义了控制、中断、批量、等时等四种管道。对于时间性极 强但是准确度要求不高的视频捕捉应用来说，摄像头应当使用等时传输方式。为了尽可 能快地得到图像数据，应当在 URB 中指定 USB_ISO_ASAP 标志。 urb->transfer_flags＝USB_ISO_ASAP；／／尽可能快地发出本 URB Linux 系统中任何 USB 传输都通过 URB 实现。为提高速度，可以考虑扩大 URB 的缓冲，这 样可以降低每个 USB 事务中握手信息所占比例，提高有效数据的传输速度。但是受限于 总线带宽和具体的 USB 设备芯片，单纯扩大 URB 的缓冲不能无限制地解决问题。具体分 析一下 USB 传输在操作系统中的实现：每次传输都要包括 URB 的建立、发出、回收、数 据整理等阶段，这些时间不产生有效数据。因此可以建立两个 URB，在等待一个 URB 被回 收时，也就是图像正在被传感器采集时，处理、初始化另一个 URB，并在回收后立刻将其 发出。两个 URB 交替使用，大大减少了额外时间。工作流程如图 1 所示。 这个过程是在 URB 的完成例程中实现的，有两点需要注意：首先处理再次初始化的代码 时间不能长，否则会造成完成例程的重人，如果确实来不及，可以在完成例程中设定标 志，例如“数据采集好”旗语，由应用程序使用阻塞 ioctl()来查询该旗语并做处理；其 次由于 CPU 可能会在完成例程中停留较长时间，系统负担较大，可以在．open 函数中初 始化两个 URB 并将其发出，有限度地减轻系统负担。 1．3 使用双帧缓冲提高效率 Linux 系统中，文件操作通常是由 read、write 等系统调用来完成。这些系统调用在驱动 中的解决方法就是用 copy_to_user()、copy_from_user()等函数在核态、户态内存空间 中互相拷贝。但是对于大批量的图像数据，采用拷贝的方法显然会增加时间开销，因此 用内存映射的方法解决。首先使用 vmalloc()申请足够大的核态内存，将其作为图像数据 缓冲空间，两个 URB 带回的图像数据在这里暂存；然后使用 remap_page_range()函数将 其逐页映射到用户空间中。户态的图像处理程序使用 mmap()函数，直接读写核态图像缓 冲内存，大大减少额外开销。 

图 2 图像数据的处理可能要花费比较长的时间，不同的算法对于数据保留时间的要求 也不一样。因此可以申请两帧图像缓冲，在处理一帧图像的同时，将两个 URB 带回的数 据全部填充到另一帧缓冲中，这样可以免去时间冲突上的麻烦。 值得注意的是：这种方法要求时刻持有当前帧的序号、每一帧的起始地址等信息，不能 将两帧图像混淆。这些信息可以保存在保留内存中，当前帧的数据整理、序号改变在 URB 完成例程中实现。 2 V4L 标准的改进 V4L 标准目前已经发展到第二版 V4L2，其基本思路与 V4L 相同。 2．1 标准分析 根据 V4L 标准，户态程序在需要一帧图像时，CPU 的走向如图 2。CPU 按照 123456 的顺序 完成一个循环。在这里，有一个细节被忽略：在完成例程中，也就是图 2 中步骤 6，该 URB 被立刻发出，但是由于这时用户程序正在阻塞等待，没办法再次提出获得图像的申请， 因此在判断有无新请求时，判断的结果必然是当前无请求，导致下一个 URB 带回的数据 被驱动丢弃；由于核态、户态的切换需要一定的时间，加上户态多进程同步等开销，等 到应用程序能够再次发出获得一副图像的申请时，已经有不止一个 URB 带回的数据被丢 弃掉，这些 URB 包含的数据正好是新一帧图像的开始部分。因此驱动必须等到再下一帧 图像才能保存数据、缓冲。这样凭白损失了一帧图像，帧速最少下降一半。 2．2 改进思路：不间断采集 为了解决这个问题，可以改进 V4L 标准作，使其增加新的功能：通过新的参数，让 ioetl() 函数通知驱动不间断采集、缓冲图像数据，轮流保存在两帧缓冲区中，并在一帧图像采 集好后，设定“图像采集好”旗语。户态程序只需要发出一次“获得图像”请求，就可 以通过阻塞等待该旗语，不断获得图像。在采集结束后，再次通过新的参数，让驱动停 止缓冲即可。CPU 工作流程图如图 3。 图 3 注意到图 2、图 3，两种“判断有无新请求”的不同，即可发现新方法假定一直 有请求，因此不丢弃每个 URB 带回的数据，轮流保存在两个帧缓冲内。 

V4L 已经作为约定俗成的标准被内核支持，因此如果使用全新的参数，工作量将相当巨大， 并且不能和现有的应用程序兼容。考虑到现有的图像采集应用程序使用 VIDIOCMCAPTURE 作为参数，并提供帧序号，要求驱动将图像保存到指定序号的帧缓冲内。由于驱动通常 仅仅提供几帧缓冲，因此该序号不会大于某个数字，如 10。因此可以继续使用 VIDIOCMCAPTURE 参数，搭配较大的序号来表示新增的功能，例如用 10000 和 10001 来分 别表示开始和停止缓冲图像数据的要求。驱动在收到 VIDIOCMCAPTURE 要求后，检查这个 序号。如果小于 10000，则按照正常的方法处理，否则按照改进方法。这种思路可以有效 解决兼容性问题。 2．3 实验结果 在赛扬 366、USBl．1 接口的计算机平台上，采用上述不间断采集改进 V4L 标准，配合双 URB、双帧缓冲等方法后，帧速提高两倍有余，有效数据传输速度达 960KB／s，接近等时 传输方式下 USB 总线的带宽极限。