简介：压缩包内提供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 完成一帧输出。缺少等待会直接导致第一帧花屏。
| 场景 | 分频系数 | 曝光行数 | 输出尺寸 |
|---|---|---|---|
| preview | 6 | 0x18 | VGA |
| capture | 9 | 0x60 | 全尺寸 |
3. usbvideo_attr_HI253.c：属性控制与 V4L2 kcontrol 的实现
3.1 为什么传感器驱动里会出现 usbvideo_attr
MT6236 支持 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 id | MCLK、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对应的增益寄存器，而不是继续加大曝光行数，因为曝光时间过长会掉帧。
本文还有配套的精品资源，点击获取
找出最大离群值)
