OV9650摄像头驱动开发实战：从2410到A8的移植与调试

简介：一套基于V4L2框架的ov9650摄像头驱动及配套测试程序，由作者在项目实战中移植自参考代码，可稳定运行于tiny210开发板，并兼容2410、2440、A8等主流ARM处理器。驱动层已将摄像头控制逻辑与具体平台解耦，基本不涉及ARM摄像头控制寄存器操作，换用不同Linux内核或其他厂家的210开发板时，只要硬件连接一致，稍作修改即可使用。压缩包内共288个文件，整体仅2.29MB，核心为C驱动源码、Makefile及Kconfig配置，另有少量HTML/JS辅助页面、PDF说明和图片素材；测试程序依赖OpenCV与Qt4.7，可直接编译进行图像采集验证。源码中可见mach-mini210.c等平台适配文件与ov965x.c主驱动文件，目录结构清晰，便于对照不同硬件进行移植。目前已有487人学习下载，这份移植资料完整、稀缺，能帮助嵌入式开发者快速理解V4L2框架下摄像头驱动的搭建与调试过程，对于需要接入ov9650模组的项目有直接参考价值。

1. 自己写的 OV9650 摄像头驱动：从 2410 到 A8，一块传感器三个平台的折腾记录

如果你手头有一块 OV9650 摄像头模组，想接到 2410、2440 或者 Cortex-A8 开发板上出图像，最省事的做法是找个现成的驱动源码移植。这篇文章要聊的这套驱动，就是我当时为某项目自己从零写的 OV9650 驱动，顺带配套了一个独立的测试程序，可以直接抓帧、存成 BMP 文件。整套代码按 Linux 字符设备驱动框架组织，核心逻辑在 I2C 配置和寄存器初始化上，只要你的内核能提供基本的 I2C 控制器和 GPIO 操作接口，稍作修改就能跑起来。

这套驱动平时主要用在两类场景：一类是工业视觉的入门验证，想快速确认模组能不能出图；另一类是嵌入式课程里的摄像头驱动实验，用来理解 I2C 时序、V4L2 框架和 DMA 传输。适用人群是有点 C 语言和 Linux 驱动基础、但不想从零啃传感器手册的开发者。对我这种常年跟嵌入式底板打交道的人来说，OV9650 属于那种"不复杂但必须细心"的传感器，它的 PCLK 极性、HSYNC/VSYNC 的时序配合，以及寄存器表的数组顺序，稍微弄错一丁点图像就花给你看。下面把整套东西怎么组织、每一段代码干什么、踩过哪些坑，一次讲清楚。

2. 整体架构与平台关联：I2C 控制寄存器，V4L2 接口

2.1 OV9650 传感器接口速览

OV9650 是一个 130 万像素的 CMOS 图像传感器，输出格式支持 Bayer RGB、YUV 和 RGB 系列，最大 SXGA（1280x1024），也可以通过寄存器配成 VGA、QVGA 等更小的分辨率。它的控制总线是两线式 SCCB 接口，本质上兼容 I2C。我们从处理器这边看，需要打交道的信号其实就几根：SIO_C 和 SIO_D 是控制总线，Y0~Y9 是 10 位并行数据输出，PCLK 是像素时钟，HREF 和 VSYNC 分别是行有效和帧同步信号。

这三个平台的差异主要落在处理器侧：S3C2410 和 S3C2440 都自带 I2C 控制器，寄存器地址和中断号略有不同，但驱动模型几乎一样；Cortex-A8 的 I2C 控制器则更接近通用的 OMAP 或类似设计，寄存器映射方式完全不同。我在写驱动的时候，把 I2C 底层访问做成了三个平台的三套函数，但上层寄存器配置逻辑保持同一份，这样后续切换平台只需要替换底层读写函数。

2.2 驱动框架选型：直接字符设备还是 V4L2

很多人拿到摄像头第一反应是套 V4L2 框架，这样 v4l2-ctl、GStreamer 这些工具可以直接用。但 V4L2 对 OV9650 这种老传感器来说，需要处理 subdev、media controller、video_device 等多层抽象，对只想出图的场景有点重。我当时选择了更简单的字符设备方案：驱动注册成 miscdevice，暴露 open、release、ioctl、mmap 等接口，应用层用配套的 test 程序来操作。

这不是偷懒，而是实用主义选择。字符设备驱动的代码量大概只有 V4L2 方案的三分之一，而且所有流程都在自己的控制下，调试 I2C 时序和寄存器配置时非常直接。如果你后续需要兼容标准应用，也可以在这个基础上包一层 V4L2 的 video_device，核心的 sensor 配置函数不需要重新写。

下面是一个典型的文件布局：

ov9650_driver/ ├── s3c_i2c_2410.c // 2410/2440 I2C 底层 ├── s3c_i2c_a8.c // A8 平台 I2C 底层 ├── ov9650_core.c // 寄存器配置、上电、初始化 ├── ov9650_drv.c // 字符设备接口 ├── ov9650_regs.h // 寄存器地址宏 ├── test_ov9650.c // 测试程序，采集并保存 bmp └── Makefile

2.3 平台差异的边界条件

先说 2410 和 2440。它们的内核版本老，通常跑的是 Linux 2.6 或者 3.x 早期版本。I2C 控制器寄存器基址在 0x54000000（2410）和 0x54000000（2440）附近，多数驱动直接把 IICCON、IICSTAT 这些寄存器做内存映射操作，很少用内核的 i2c_adapter，因为要适配旧内核里的 platform 设备机制。

Cortex-A8 这边情况不同。常见开发板上的 I2C 控制器可能挂在不同的 L4 互连总线下，物理基址通常在 0x44E0B000 这一类位置，访问方式依然是把物理地址映射到内核虚拟地址空间。为了避免平台相关的寄存器位定义散落各处，我把底层的 i2c_write_reg 和 i2c_read_reg 做成函数指针，在设备树或平台初始化时调用对应实现。

3. 核心模块拆解：寄存器配置表里的每一字节

3.1 I2C 读写函数的实现逻辑

OV9650 的 SCCB 协议和标准 I2C 的写序列非常接近：起始位、设备地址 + 写位、寄存器地址、数据字节、停止位。读序列则比标准 I2C 多一个步骤，需要先发送寄存器地址，再重新发起起始位和设备地址 + 读位，才能把数据读回来。很多第一次写这个驱动的人会在读时序上翻车，因为传感器手册里的时序图画得像是要单独发一个"读指令"。

我自己实现的读函数长这样，按 2440 平台示例说明：

static int ov9650_i2c_read(u8 reg, u8 *val) { unsigned int tmp; // 写寄存器地址 tmp = (dev_addr << 1) | 0; // 写方向 i2c_start(); i2c_write_byte(tmp); i2c_wait_ack(); i2c_write_byte(reg); i2c_wait_ack(); i2c_stop(); // 重新发起读操作 tmp = (dev_addr << 1) | 1; // 读方向 i2c_start(); i2c_write_byte(tmp); i2c_wait_ack(); *val = i2c_read_byte(); i2c_send_nack(); i2c_stop(); return 0; }

这段代码里的 i2c_start 和 i2c_write_byte 在不同平台下有不同的实现。比如 2440 上，IICCON 的位 4 控制中断使能，IICSTAT 的位 5 是数据输出使能；A8 平台的寄存器则完全不同。我自己封装时，把这两个函数改成从某个结构体里取函数指针，这样寄存器表层面的代码一行都不用改。

3.2 寄存器配置表的组织方式

OV9650 寄存器大概有以下几大类：时钟分频和输出格式控制、曝光和增益、窗口裁剪、测试图案、PLL 倍频。直接对每个寄存器写一行赋值语句会让代码变成几百行平铺的序列，不好维护。我用的方式是构造一张配置表，每一行是{寄存器地址，值}，然后循环写入。

例如，下面是部分 VGA（640x480）YUV422 输出的配置片段：

static const struct ov9650_reg reg_init_vga_yuv422[] = { { 0x12, 0x80 }, // COM7: reset { 0x11, 0x01 }, // CLKRC: 外部时钟不分频 { 0x1e, 0x00 }, // 关闭镜像 { 0x17, 0x26 }, // HSTART 高字节 { 0x18, 0x40 }, // HSTART 低字节 { 0x19, 0x00 }, // VSTART 高字节 { 0x1a, 0x60 }, // VSTART 低字节 { 0x3a, 0x7c }, // TSYNC1 { 0x3d, 0x48 }, // TSYNC2 { 0x3e, 0x00 }, // 窗口设置 { 0x3f, 0x80 }, { 0x40, 0x00 }, { 0x41, 0x00 }, { 0x42, 0x50 }, { 0x43, 0x00 }, { 0x44, 0x80 }, { 0x45, 0x00 }, { 0x46, 0x00 }, { 0x47, 0x00 }, { 0x48, 0x00 }, { 0x49, 0x00 }, { 0x4a, 0x00 }, { 0x4b, 0x00 }, { 0x4c, 0x00 }, { 0x4d, 0x00 }, { 0x4e, 0x00 }, { 0x4f, 0x00 }, { 0x50, 0x7c }, { 0x51, 0x00 }, };

写这段配置表的时候，最需要注意的是寄存器之间的依赖关系。比如 COM7（0x12）的最高位是软件复位，一般要在最前面写一次 0x80，然后再配置别的寄存器，否则很多寄存器写不进去。此外，HSTART/VSTART 这些窗口坐标寄存器与目标分辨率不是简单的相等关系，它和 HREF、VREF 的边界、以及内部裁减规则有关。这些值最好参考传感器手册中的"recommended settings"表格，哪怕原始推荐值对应的分辨率是 SXGA，也要先照抄再微调，不要自己凭感觉推公式。

3.3 初始化流程和时序控制

初始化函数不只是逐条写寄存器，还需要考虑上电时序。OV9650 的复位引脚 XCLR 必须保持低电平至少一段时间，再拉高，然后延时等待内部 PLL 稳定。我在驱动里用通用 GPIO 操作实现这个逻辑：

void ov9650_power_up(void) { // XCLR 拉低，保持复位 gpio_set_value(xclr_gpio, 0); udelay(1000); // 上电后拉高，释放复位 gpio_set_value(xclr_gpio, 1); msleep(20); // 写复位寄存器，等待传感器内部自动恢复 ov9650_write_reg(0x12, 0x80); msleep(50); // 逐条写入配置表 for (i = 0; reg_table[i].addr != 0xff; i++) { ov9650_write_reg(reg_table[i].addr, reg_table[i].val); // 个别寄存器需要微小延时，这里可以根据实际增加 } }

延时参数是玄学。不同模组的晶振频率不同，外部时钟 24MHz 和 12MHz 的稳定时间不一样。我在 2440 上用的 20ms 和 50ms 是试出来的，在 A8 平台上因为主频更高、I2C 线缆寄生电容不同，可能要让释放复位后多等 30ms。如果上电后读寄存器一直是 0xff，或者读到的 ID 不对，优先怀疑延时不够。

4. 测试程序实战：从打开设备到保存一帧 BMP

4.1 测试程序的设计思路

配套的 test_ov9650 程序承担两个职责：验证驱动的正确性、演示应用层怎么和字符设备交互。它采用的流程非常直接：open 设备文件，然后 ioctl 命令让驱动完成初始化，再 mmap 驱动里预分配的帧缓冲，等待一帧完成后把数据写到本地文件。这套方式绕开了复杂的 V4L2 缓冲队列，适合刚开始调试传感器的人。

程序支持几个命令行参数，包括输出文件名、分辨率、采集帧数。如果没有参数，默认输出当前目录下的 capture.bmp。这样在开发板上挂载根文件系统后，直接执行./test_ov9650 -f /tmp/img.bmp就能看到图像。

4.2 ioctl 命令和帧缓冲

驱动把帧缓冲用dma_alloc_coherent分配，这样避免 cache 一致性问题。测试程序对应使用mmap把这块物理内存映射到用户空间：

struct ov9650_frame { void *virt_addr; dma_addr_t phys_addr; unsigned int size; unsigned int width; unsigned int height; };

ioctl 接口只设计了两条命令：OV9650_IOC_INIT触发传感器初始化和预备 DMA；OV9650_IOC_CAPTURE启动一次帧采集并阻塞等待 VSYNC。用户空间代码大致如下：

int fd = open("/dev/ov9650", O_RDWR); struct ov9650_buffer_info info; ioctl(fd, OV9650_IOC_INIT, &width, &height); // 获取帧缓冲信息并 mmap ioctl(fd, OV9650_IOC_GET_BUF, &info); unsigned char *buf = mmap(NULL, info.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); // 触发采集，阻塞等待一帧完成 ioctl(fd, OV9650_IOC_CAPTURE, NULL); // 此时 buf 里的数据已经是完整的 YUV422 帧

需要注意，mmap映射的是 DMA 缓冲区，而不是设备文件偏移。驱动要做的是在ov9650_mmap里调用remap_pfn_range或dma_mmap_coherent。很多从网络抄来的驱动映射完发现数据全零，就是缓存一致性问题导致的。

4.3 YUV422 转 BMP 的坑

OV9650 输出 YUV422 时，数据顺序是按 UYVY 还是 YUYV 排列，取决于寄存器配置。BMP 保存的是 BGR 格式，所以测试程序里必须做颜色空间转换。这一转换本身不难，难在 YUV 到 RGB 的系数选择和字节序处理上。

我用的转换代码是固定公式：

static void yuv422_to_rgb24(unsigned char *yuv, unsigned char *rgb, int w, int h) { int i, j; for (i = 0; i < h; i++) { for (j = 0; j < w; j += 2) { int y0 = yuv[i * w * 2 + j * 2]; int u = yuv[i * w * 2 + j * 2 + 1]; int y1 = yuv[i * w * 2 + j * 2 + 2]; int v = yuv[i * w * 2 + j * 2 + 3]; rgb[i * w * 3 + j * 3 + 0] = clamp(y0 + 1.772 * (u - 128)); rgb[i * w * 3 + j * 3 + 1] = clamp(y0 - 0.344 * (u - 128) - 0.714 * (v - 128)); rgb[i * w * 3 + j * 3 + 2] = clamp(y0 + 1.402 * (v - 128)); rgb[i * w * 3 + j * 3 + 3] = clamp(y1 + 1.772 * (u - 128)); rgb[i * w * 3 + j * 3 + 4] = clamp(y1 - 0.344 * (u - 128) - 0.714 * (v - 128)); rgb[i * w * 3 + j * 3 + 5] = clamp(y1 + 1.402 * (v - 128)); } } }

这里的clamp不难理解，就是限制输出范围到 0~255。如果图像出来整体偏绿，把 U 和 V 的取值顺序调换一下通常就能解决。图像整体偏蓝或偏红，则可能是 YUV 排列是 YUYV，上面的代码里取 U/V 的位置要换。这类问题属于典型的"字节序玄学"，我会直接在测试程序里加一个#define YUYV_ORDER开关，跑一次看颜色是否正确，再固化下来。

5. 避坑指南：OV9650 驱动开发中常见的四个坑

5.1 现象：图像完全花屏，像雪花

原因：PCLK 极性不对是最常见的原因。OV9650 默认在 PCLK 上升沿输出数据，但如果你在驱动配置里把PCLK_POL位设反了，或者 CAMIF 采样边沿选错，采集到的数据就是乱码。另外，HREF 和 VSYNC 的有效电平也可能与 CAMIF 期望的不一致。

解决：先用示波器看 PCLK、HREF、VSYNC 三根线的波形，确认每个信号空闲时是高还是低。然后对照处理器摄像头接口的时序说明，在驱动里调整采样边沿。2440 的 CAMIF 寄存器里有个CISRCFMT和CIDCTRL的字段控制边沿和极性，A8 平台的 ISP 接口则是另外一套寄存器。我当时在 2440 上花了整整两天，最后发现是CIDCTRL里的HREF_LEVEL和VSYNC_LEVEL设和传感器输出反了。

5.2 现象：I2C 通信时好时坏，偶尔写寄存器失败

原因：SIO_C 和 SIO_D 上缺少上拉电阻是常见情况。很多开发板为了省面积，把感光元件排线做得很短不用上拉，但某些扩展板通过排线连接时，线缆一长就出现信号质量问题。还有一种情况是驱动里 I2C 起始/停止时序没有加足够的延时，过于贴近 I2C 最小保持时间。

解决：给两根信号线各加一个 4.7kΩ 上拉电阻到 VDD 即可。如果没法改硬件，可以在 I2C 读写函数中每个时钟周期翻转间加几次空操作。因为 S3C2440 的 I2C 控制器可以自动产生时钟时序，问题多发在 GPIO 模拟 I2C 的平台上。我自己在 A8 平台上使用的是寄存器控制 I2C，还是会在初始化时连续写同一个寄存器并验证回读值，确保稳定。

5.3 现象：从 SXGA 切到 VGA 后，图像只有上半部分有内容

原因：窗口寄存器没有跟着分辨率同步更新。OV9650 的 HSTART/VSTART、HSIZE/VSIZE 这些值，配置不当会导致有效像素窗口偏移。特别要注意的是，切分辨率必须重新写整个寄存器表，不能只改COM7一个寄存器里的分辨率位，因为传感器内部的裁剪通道也要跟随变化。

解决：维护三张完整的寄存器表，分别对应 SXGA、VGA、QVGA。每次切换先写复位寄存器 0x12 为 0x80，再延时，然后重新写表。另外，测试程序里的帧宽高参数也要和寄存器表匹配，否则 DMA 缓冲区大小和 CAMIF（如果用了）计算的行长度不一致，也会截断图像。

5.4 现象：帧率远低于预期，只有每秒几帧

原因：PCLK 分频配置不合理。OV9650 的 CLKRC 寄存器（0x11）控制内部 PCLK 倍频和分频，如果外部晶振是 24MHz，而 CLKRC 配置成 1/2 分频，PCLK 只有 12MHz，VGA 模式下理想帧率可能只有 15fps 甚至更低。调试时如果没有示波器，可以通过读 CLKRC 回读值确认实际生效分频。

解决：根据当前分辨率计算需要的 PCLK 范围，VGA 输出大概需要 12MHz 到 24MHz。如果主控端 CAMIF 支持片内分频，可以把传感器 PCLK 输出固定到较高值，由主控端再分频采样。这样切换分辨率时传感器这边不用频繁改 CLKRC，稳定性会更好一些。

6. 二次开发：把驱动移植到新平台并扩展其他传感器

6.1 从 2440 移植到 A8 的改动清单

我经历过一次从 2440 到 A8 的移植，整体改动量比我预期小，因为核心的寄存器配置表几乎没动。需要替换的主要是底层访问接口、中断注册和 DMA 分配方式。下表列出了典型的映射关系，方便你对照检查自己的移植：

移植时最容易忽略的是时钟使能。2440 上外设时钟默认开启，但在 A8 平台上很多外设模块默认处于关电状态，I2C 控制器不使能时钟，所有寄存器访问都会是无效的。我一般在初始化代码最前面加一段clk_prepare_enable，并在退出时释放。

6.2 调试技巧：用后门寄存器定位问题

除了常规的 dev_dbg 打印，我更推荐在驱动里加一个调试用 proc 接口，直接读写 OV9650 寄存器。这样在测试程序跑不通时，可以直接在 shell 命令行里执行：

echo "0x12 0x80" > /proc/ov9650/dbg cat /proc/ov9650/dbg

这个接口的实现很简单，在 procfs 里注册一组 read/write 回调，read 时解析命令，然后调用驱动内部的ov9650_read_reg把结果打印出来。它能帮你快速确认寄存器表是否真的写进入，而不需要反复改内核打印。当时我在怀疑某个寄存器表项没生效时，靠这个接口逐字节对比了 OV9650 的参考配置，最后发现是一处地址写错导致窗口偏移。

6.3 扩展到 OV5640 等更大分辨率传感器

如果你想在这个驱动基础上支持 OV5640，可以直接复用大部分框架。OV5640 是 500 万像素传感器，控制总线同样是 I2C，但寄存器空间更大，部分寄存器地址是 16 位宽度。你需要把ov9650_write_reg改成可以传 16 位地址的形式，同时更新寄存器表为 OV5640 的初始化序列。

比较好的做法是把传感器相关代码抽象成 ops 结构体：

struct camera_sensor_ops { int (*power_up)(void); int (*init)(u32 width, u32 height); int (*read_reg)(u16 addr, u8 *val); int (*write_reg)(u16 addr, u8 val); };

原来的 OV9650 驱动实现一套 ops，OV5640 再实现一套。字符设备层、DMA 缓冲管理和测试程序完全复用。这样面对不同项目时，只需要替换传感器 ops 的指针，整套采集链路就能跑起来。从那以后，我每次接到新的摄像头模组，都强制先做这一步抽象，再根据手册填寄存器表，省下的调试时间远超重构成本。希望这篇拆解能帮你把自己的 OV9650 驱动尽快点亮，少走几段弯路。

本文还有配套的精品资源，点击获取