现在的位置: 首页 > 综合 > 正文

如何开发wince usb 摄像头的驱动-中星微摄像头驱动

2013年02月25日 ⁄ 综合 ⁄ 共 2776字 ⁄ 字号 评论关闭

这段时间成功的开发了中星微301H摄像头的wince驱动和视频采集程序。中星微摄像头出来的数据为JPEG格式,我们将其直接读出,交给应用程序来解码,就可以显示图像。中间的过程我们可以参考Linux GSPCA的驱动,将其移植到wince中就可以了。中间的关键是要理解Linux的驱动。幸好我以前开发过Linux USB的主和从设备,Wince USB的主和从设备的驱动,做这个也没花多少时间。下面是我参考的一些资料,非常有用。

USB摄像头的数据采集的一般流程为传感器接口――>图像信号处理-->图像压缩-->USB传输。一般USB摄像头对采集图像都作了压缩(内置JPEG硬件压缩),压缩是为了提高图像传输效率,也就是动态分配USB带宽技术,使DSP采集的图像可以在USB1.0上传输效率提高,现在能够使640*480帧率高达30/秒。至于传输协议,目前几乎所有的厂商使用自己的图像传输协议。将来USB摄像头会有统一的标准。要将USB摄像头和嵌入式系统相连时可能的,但是最好嵌入式系统使用Linux来做操作系统。这样可以找到开发源代码的驱动,然后再针对自己的要求作二次开发。

JPEG的文件格式

JPEG文件格式 JPEG文件大体上可以分成以下两个部分:标记码(Tag)加压缩数据。先介绍标记码部分。 标记码部分给出了JPEG图象的所有信息(有点类似于BMP中的头信息,但要复杂的多),如图象的宽、高、Huffman表、量化表等等。标记码有很多,但绝大多数的JPEG文件只包含几种。注意 JPEG/JFIF 文件格式使用 Motorola 格式,而不是Intel格式,就是说,如果是一个字的话, 高字节在前, 低字节在后.
JPG文件是由一个个段(segments)构成的.每个段长度<=65535.每个段从一个标记字开始.标记字都是0xff打头的,以非0字节和 0xFF 结束.例如"FFDA","FFC4","FFC0".每个标记有它特定意义,这是由第2字节指明的.例如,SOS(StartOf Scan= "FFDA")指明了你应该开始解码.另一个标记DQT(Define Quantization Table = 0xFFDB)就是说它后面有64字节的quantization表在处理JPG文件时,如果你碰到一个0xFF,而它后面的字节不是0,并且这个字节没有意义.那么你遇到的0xFF字节必须被忽略.(一些JPG ,常用用0xFF做某些填充用途)如果你在做huffman编码时碰巧产生了一个0xFF,那么就用0xFF 0x00代替.就是说在jpeg图形解码时碰到FF00就把它当作FF处理.另外在huffman编码区域结束时,碰到几个bit没有用的时候,应该用1去填充.然后后面跟 FF.

下面是必须处理的标记

SOF0 = Start Of Frame 0 = FFC0
SOS = Start Of Scan = FFDA
APP0 = it"s the marker used to identify a JPG file which uses the JFIF
specification = FFE0

COM = Comment = FFFE
DNL = Define Number of Lines = FFDC
DRI = Define Restart Interval = FFDD
DQT = Define Quantization Table = FFDB
DHT = Define Huffman Table = FFC4

段的类型:
SOF0: Start Of Frame 0:
~~~~~~~~~~~~~~~~~~~~~~~

- $ff, $c0 (SOF0)
- 长度 (高字节, 低字节), 8+components*3
- 数据精度 (1 byte) 每个样本位数, 通常是 8 (大多数软件不支持 12 和 16)
- 图片高度 (高字节, 低字节), 如果不支持 DNL 就必须 >0
- 图片宽度 (高字节, 低字节), 如果不支持 DNL 就必须 >0
- components 数量(1 byte), 灰度图是 1, YCbCr/YIQ 彩色图是 3, CMYK 彩色图
是 4
- 每个 component: 3 bytes
- component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q)
- 采样系数 (bit 0-3 vert., 4-7 hor.)
- quantization table 号

DRI: Define Restart Interval:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- $ff, $dd (DRI)
- 长度 (高字节, 低字节), 必须是 4
- MCU 块的单元中的重新开始间隔 (高字节, 低字节),
意思是说, 每 n 个 MCU 块就有一个 RSTn 标记.
第一个标记是 RST0, 然后是 RST1 等, RST7 后再从 RST0 重复

DQT: Define Quantization Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- $ff, $db (DQT)
- 长度 (高字节, 低字节)
- QT 信息 (1 byte):
bit 0..3: QT 号(0..3, 否则错误)
bit 4..7: QT 精度, 0 = 8 bit, 否则 16 bit
- n 字节的 QT, n = 64*(精度+1)

备注:
- 一个单独的 DQT 段可以包含多个 QT, 每个都有自己的信息字节
- 当精度=1 (16 bit), 每个字都是高位在前低位在后

DAC: Define Arithmetic Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
法律原因, 现在的软件不支持 arithmetic 编码.
不能生产使用 arithmetic 编码的 JPEG 文件

DHT: Define Huffman Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~

- $ff, $c4 (DHT)
- 长度 (高字节, 低字节)
- HT 信息 (1 byte):
bit 0..3: HT 号 (0..3, 否则错误)
bit 4 : HT 类型, 0 = DC table, 1 = AC table
bit 5..7: 必须是 0
- 16 bytes: 长度是 1..16 代码的符号数. 这 16 个数的和应该 <=256
- n bytes: 一个包含了按递增次序代码长度排列的符号表
(n = 代码总数)

备注:
- 一个单独的 DHT 段可以包含多个 HT, 每个都有自己的信息字节

COM: 注释:
~~~~~~~~~~

- $ff, $fe (COM)
-
注释长度 (高字节, 低字节
) = L+2
-
注释为长度为 L 的字符流

SOS: Start Of Scan:
~~~~~~~~~~~~~~~~~~~
- $ff, $da (SOS)
-
长度 (高字节, 低字节), 必须是 6+2*(扫描行内组件的数量)
-
扫描行内组件的数量 (1 byte), 必须 >= 1 , <=4 (否则是错的) 通常是
3
-
每个组件
: 2 bytes
- component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q),
SOF0
-
使用的 Huffman
:
- bit 0..3: AC table (0..3)
- bit 4..7: DC table (0..3)
-
忽略
3 bytes (???)

备注

抱歉!评论已关闭.