简介压缩包内提供HI253 CMOS图像传感器在MTK MT6236(11A)平台上的驱动实现源码面向嵌入式驱动开发、功能机或物联网摄像头调试人员可用于快速理解并移植传感器驱动。RAR压缩包共含3个文件以两个C源文件和一个H头文件组成整体仅16KB代码量精炼便于直接阅读关键逻辑由于文件少、依赖简单非常适合作为学习MTK平台摄像头驱动的入门参考。其中主驱动代码覆盖传感器初始化、寄存器配置、I2C/SPI接口交互逻辑与图像数据捕获USB视频属性处理模块负责摄像头帧率、分辨率等参数协商头文件则清晰定义了结构体、常量和函数接口方便上层调用。目前已有111人学习/浏览适合需要参考MTK平台传感器驱动框架、做驱动移植或排查HI253适配问题的开发者整体简洁实用。1. 功能机平台没有 Linux 那套HI253 驱动是裸写的Linux 上写摄像头驱动第一反应是摸 V4L2 的 kcontrol 和 subdev。但打开这份源码包你会发现MT6236(11A) 上让 HI253 出图靠的是三个文件image_sensor_HI253.c、usbvideo_attr_HI253.c、image_sensor_HI253.h编译时直接拼进 MTK 多媒体库没有 insmod也没有 platform_driver只有一张张寄存器表通过 SENSOR_Write_Reg 的 I2C 通路写进 CMOS。对刚接手功能机和 BSP 维护的人来说这股原始感才是门槛你不需要懂 PCIe 枚举但必须理解上电时序、MCLK 分频和寄存器序列的顺序。这个压缩包的价值在于一个可编译的 HI253 驱动原型以及一套可以移植到其他 CMOS 的驱动组织方法。2. image_sensor_HI253.c从寄存器表到出图状态机2.1 驱动在 MTK 多媒体框架中的位置MT6236 的 camera 通路不经过标准内核框架它由 MTK 多媒体服务直接调用底层函数。sensor 驱动要做的事很集中初始化传感器、启动出图流、在 preview 和 capture 两种模式间切换。打开 image_sensor_HI253.c 你会发现它没有 file_operations 那套东西暴露出去的是SENSOR_Init、SENSOR_Preview_Setting、SENSOR_Capture_Setting这类固定函数。MTK 的 camera service 在启动时遍历 sensor 列表通过 chip ID 匹配到 HI253然后把函数指针注册进多媒体服务。之后上层要切到预览只是调用HI253_preview_setting由驱动改 sensor 内部寄存器。所以这个文件的代码组织本质上是一个状态机每个状态对应一组寄存器写入而不是 Linux 驱动里常见的异步事件模型。2.2 初始化序列的写法HI253 这类老式 CMOS 初始化基本靠一个静态寄存器表。驱动启动时逐条写入写完软复位再写 PLL 和输出窗口。下面是压缩包中 image_sensor_HI253.c 最常见的初始化代码形态/* image_sensor_HI253.c 中的初始化寄存器表节选 */ static const kal_uint16 HI253_Sensor_Init_Table[][2] { {0x0003, 0x0000}, /* 软复位: 让 sensor 回到默认状态 */ {0x0001, 0x0008}, /* 全局时钟分频为 8, 得到 MCLK/8 */ {0x0002, 0x0070}, /* PLL 倍频, 与分频共同决定像素时钟 */ {0x0020, 0x0040}, /* 曝光行数初值, 亮环境可改小 */ {0x0104, 0x0002}, /* 窗口水平偏移, 对准感光区中心 */ {0x0105, 0x0002}, /* 窗口垂直偏移 */ {0xFFFF, 0xFFFF}, /* 表结束标记 */ }; void HI253_Sensor_Init(void) { kal_uint16 idx 0; while (HI253_Sensor_Init_Table[idx][0] ! 0xFFFF) { SENSOR_Write_Reg(HI253_Sensor_Init_Table[idx][0], HI253_Sensor_Init_Table[idx][1]); idx; } }这段代码的逻辑很直接循环写入初始化表遇到 0xFFFF 结束。这里有两个关键参数要理解。0x0001是全局时钟分频系数0x0002是 PLL 倍频两者共同决定 sensor 内部的像素时钟0x0020是曝光行数直接决定预览初始亮度。寄存器地址和数据宽度都受 MTK 平台的 I2C 配置约束HI253 一般按 8 位地址和 8 位数据处理。初始化表的顺序有讲究。软复位寄存器必须放在最前面因为复位会把所有寄存器打回默认值如果把分频和曝光写在软复位之前这些配置会被复位动作清除。调试时如果发现 sensor 的输出 时钟不对先看是不是把软复位放在了表中间。2.3 preview/capture 模式切换模式切换不是调分辨率那么复杂本质还是改寄存器。HI253 的预览模式会降低分频、缩小曝光行数并设置输出窗口为 640x480抓拍模式则恢复全尺寸输出。可以参考下面的实现static void HI253_set_preview_mode(void) { SENSOR_Write_Reg(0x0001, 0x0006); /* 预览模式: 降低分频, 降低功耗 */ SENSOR_Write_Reg(0x0020, 0x0018); /* 预览曝光: 减少曝光行数 */ SENSOR_Write_Reg(0x0301, 0x0001); /* 输出窗口缩放系数 */ SENSOR_Write_Reg(0x0305, 0x0002); /* 输出尺寸: VGA */ } static void HI253_set_capture_mode(void) { SENSOR_Write_Reg(0x0001, 0x0009); /* 抓拍: 提高分频, 保证全分辨率 */ SENSOR_Write_Reg(0x0020, 0x0060); /* 抓拍曝光 */ SENSOR_Write_Reg(0x0301, 0x0001); /* 关闭缩放 */ SENSOR_Write_Reg(0x0305, 0x0001); /* 输出尺寸: 全尺寸 */ }注意上面寄存器地址在同类 CMOS 中常见实际开发时以 HI253 数据手册为准。写模式切换时最容易出问题的是曝光参数没有在 stream off 状态下写入导致抓拍首帧过曝或者全黑。预览到抓拍的切换过程在 MTK 上层看来只是调用了两个函数。驱动要做的是在新的曝光配置生效前等待 sensor 完成一帧输出。缺少等待会直接导致第一帧花屏。场景分频系数曝光行数输出尺寸preview60x18VGAcapture90x60全尺寸3. usbvideo_attr_HI253.c属性控制与 V4L2 kcontrol 的实现3.1 为什么传感器驱动里会出现 usbvideo_attrMT6236 支持 USB camera 模式上层通过 USB 视频类接口访问摄像头。usbvideo_attr_HI253.c 做的事情是把 sensor 的状态暴露成一组属性让 USB 协议栈可以读取或修改亮度、对比度、镜像翻转、图像翻转等参数。它不直接操作寄存器而是把上层请求翻译成对 sensor 寄存器的写操作。这个文件的数据结构很像 Linux V4L2 的v4l2_ctrl_ops但内部实现是 MTK 私有的属性机制。看到usbvideo_attr_前缀第一反应就是去找属性 ID 和回调函数而不是找设备节点。/* usbvideo_attr_HI253.c 中的属性设置回调 */ static int HI253_set_attr(unsigned int attr_id, unsigned int value) { switch (attr_id) { case ATTR_BRIGHTNESS: HI253_set_brightness(value 0xff); return 0; case ATTR_CONTRAST: HI253_set_contrast(value 0xff); return 0; case ATTR_HFLIP: HI253_set_mirror(value 0x01); return 0; case ATTR_VFLIP: HI253_set_flip((value 1) 0x01); return 0; default: return -1; } }这里attr_id是 USB 协议中的状态页编号value是上层传进来的原始值。开关类属性只取低 1 位亮度、对比度这类连续变量取整个字节。返回值 -1 表示不支持的属性 ID调用方会直接放弃这次调节。3.2 亮度、对比度如何映射到寄存器属性值到寄存器值不是简单复制通常要做一次映射压缩。HI253 的亮度寄存器只有 4 位有效位而 USB 协议传过来的是 8 位驱动要做一次右移static void HI253_set_brightness(unsigned int level) { kal_uint16 reg 0; /* level 0..255 压缩到 0..0x0f, 共 16 档 */ reg (level 4) 0x0f; SENSOR_Write_Reg(0x0044, reg); }线性压缩是常见做法但不是所有 sensor 的亮度寄存器都是线性响应。有些 CMOS 亮度和人眼感知是对数关系直接线性映射会出现低端跳变、高端饱和。我一般会先看数据手册里的响应曲线再用查表方式修正。如果调试时发现亮度调到中间档位突然过曝基本就是映射曲线不对。3.3 USB 属性与预览参数的联动在 USB camera 模式下分辨率切换时要同步更新 usbvideo 属性页里的格式字段。只改 sensor 寄存器不改属性页主机端拿到的时间和帧尺寸会对不上播放器会卡顿或花屏。这个问题在 3G 视频通话里尤其明显对方看到的画面分辨率不对但本地预览是正常的。所以改这类驱动时要养成的习惯是任何影响输出尺寸或帧率的寄存器修改都要回到 usbvideo_attr_HI253.c 里确认属性字段是否同步更新。这份源码包把属性控制单独抽成文件比把属性回调散落在 Sensor_Init 前面清晰得多也方便只做 USB camera 时裁剪。4. image_sensor_HI253.h驱动接口契约与数据结构的组织4.1 头文件里定义的驱动信息结构头文件的价值在于定义 MTK 多媒体层和驱动之间的契约。image_sensor_HI253.h 中一般会定义一个结构体把初始化、预览设置、抓拍设置这些函数指针集中在一起。上层只需要拿到这个结构体就能驱动传感器。/* image_sensor_HI253.h 中的驱动结构体定义 */ #define HI253_SENSOR_ID 0x2530 /* I2C 读到的 chip id */ typedef struct { kal_uint32 sensor_id; kal_uint8 i2c_addr; void (*init)(void); void (*preview_setting)(void); void (*capture_setting)(void); void (*night_mode)(void); } HI253_SENSOR_INFO; extern HI253_SENSOR_INFO HI253_sensor_info;sensor_id是驱动与上层匹配的关键读取失败时 MTK 会认为该 sensor 不存在。i2c_addr来自传感器数据手册一般不允许用户修改。换模组时如果读取不到 ID先检查 I2C 地址再检查上电时序。4.2 关键宏曝光与增益上限头文件里还会定义曝光和增益的上限这些宏直接决定驱动能否正常工作#define HI253_PAGE_SIZE 0x100 /* 分页寄存器窗口大小 */ #define HI253_SHUTTER_MAX 0x1F4 /* 曝光行数上限 */ #define HI253_GAIN_MAX 0x3F /* 模拟增益上限 */HI253_SHUTTER_MAX是根据 sensor 最大行数算出来的写太大 sensor 会丢帧写太小暗光下曝光不足。HI253_GAIN_MAX一般对应寄存器最大有效位宽6 位寄存器就是 0x3F。上层如果使用 10 位增益值需要在驱动里右移后再写寄存器。4.3 向 MTK 工程添加一颗新 sensor 的改法拿到这份代码最直接的应用是照葫芦画瓢增加一颗新 sensor。改动点集中在四个地方把新 sensor 的 .c 和 .h 文件放到custom\common\camera\目录下。在 image_sensor.c 的 sensor 列表中增加一个新枚举类型和匹配函数。在 Camera 模块的 makefile 中把新 .c 文件加进编译列表。检查 MTK GPO 配置确认 sensor 的 reset 和 power enable 引脚是否有冲突。常见错误是只改了驱动文件忘记更新 makefile。编译不报错但链接出来的库文件里不包含新 sensor运行时一直报 Unknown Sensor。检查方法是在编译日志里搜索 sensor 文件名确认被编进去。5. 编译、烧录与调试点让 HI253 真正出像5.1 在 11A 工程中落地的编译操作MT6236(11A) 的编译环境与后来 Linux 平台差异很大没有设备树也不需要在 kernel 里配置驱动。把三个文件放入 camera 模块目录后要修改模块的 makefile# camera 模块 makefile: 加入 HI253 驱动源文件 C_SOURCES image_sensor_HI253.c C_SOURCES usbvideo_attr_HI253.c然后编译整个工程生成 MCP 镜像再用 MTK 刷机工具烧录。刷机前宿主机要装好 VCOM USB 驱动否则刷机工具匹配不到设备。这一步卡住的人不少VCOM 驱动没装好时USB 设备枚举会失败刷机进度条跑了一点就报错。这个包里的源码编译顺序比较老如果编译器版本太新注意把编译选项对齐到工程默认的 C 标准。5.2 通过日志读取 sensor 状态功能机平台没有 Linux 的 dmesg但可以在串口控制台执行 vendor 命令或者读 log 文件。读取 sensor ID 是最常用的验证方式# 通过串口或者 adb(如果平台启用) 读取 sensor 寄存器 # 0x00 和 0x01 是 HI253 的 ID 寄存器 io_read 0x00 io_read 0x01io_read是 MTK 提供的调试命令实际名称以工程为准。返回值应该与HI253_SENSOR_ID匹配。如果读到 0xFFFF 或超时说明 I2C 或者上电时序有问题。这和 Linux 下用 i2ctransfer 读 eeprom 是一个思路只是工具名不一样。另一个常用工具是 modemeta。工程里保留这个工具时可以通过它读 NVRAM 中的 sensor 参数确认驱动运行时有没有写返回值回来。这与串号修改无关这里只是利用它看驱动日志。倒是有不少同事把它和串号工具混淆实际是两个独立的调试通道。5.3 常见问题排查现象排查点可能原因I2C 读不到 sensor idMCLK、reset 上电时序reset 拉低时间不够MCLK 未起振preview 花屏分频和 PLL 参数像素时钟超出 sensor 最大规格capture 黑屏曝光行数寄存器曝光值在 stream on 状态下写入被忽略亮度调节无效属性映射寄存器usbvideo_attr 里映射到了错误寄存器第一个问题最容易定位也最容易疏忽。HI253 需要先给 MCLK再等内部 PLL 稳定之后才能通过 I2C 读写。有的方案把 reset 和 power 绑在一起上电后立刻读 register结果全是 0xFF。加一个 5ms 延时通常能解决但最好是抓逻辑分析仪看时序。6. 曝光行数与帧率联动手动曝光配置的换算方法拿到这套驱动后最常用的进阶操作不是调亮度而是手动配置曝光行数来固定帧率。HI253 的曝光时间由三个参数决定曝光行数、行长、像素时钟。换算公式是曝光时间 曝光行数 × 行长 / 像素时钟反过来给定目标曝光时间和已知行长可以反推曝光行数/* 根据目标曝光时间(us)计算曝光行数 */ kal_uint16 HI253_exposure_lines_from_us(kal_uint32 us, kal_uint32 line_len, kal_uint32 pclk) { kal_uint32 lines (us * (pclk / 1000)) / line_len; /* 防止曝光行数超过寄存器上限 */ if (lines HI253_SHUTTER_MAX) lines HI253_SHUTTER_MAX; return (kal_uint16)lines; }参数说明us是目标曝光微秒数line_len是一行对应的像素时钟数pclk是传感器像素时钟。这个计算有两个注意点第一pclk 先除以 1000 是防止中间乘法溢出如果你用的是 32 位平台us 乘 pclk 很容易超过 65535第二最终曝光行数要受HI253_SHUTTER_MAX限制否则寄存器溢出后会自动回绕画面会突然过曝。验证方法很简单固定摄像头对准一个亮光源把曝光行数从最小逐步加大观察画面亮度变化是否线性。如果亮度跳变说明行长参数算错了。换一个暗环境同样行程下如果画面亮度不够优先检查HI253_GAIN_MAX对应的增益寄存器而不是继续加大曝光行数因为曝光时间过长会掉帧。本文还有配套的精品资源点击获取