简介这是一份针对联发科MTK_MT6236(11A)功能机平台的HI253 CMOS图像传感器驱动源代码面向嵌入式驱动开发工程师、摄像头底层调试人员及功能机方案研究者可解决Sensor驱动移植与图像采集通路搭建问题。资源为RAR压缩包共3个文件包含2个C源文件与1个头文件image_sensor_HI253.c实现传感器初始化、寄存器读写与图像采集等核心逻辑usbvideo_attr_HI253.c负责USB视频类设备属性配置与数据传输image_sensor_HI253.h则提供驱动所需的结构体、枚举常量及函数原型便于其他模块调用。包体仅16KB结构精炼适合对照学习MTK平台Camera驱动框架、I²C/SPI接口交互及UVC输出链路也适合初学者快速建立Sensor驱动代码的阅读路径。已有112人学习下载对于正在调试HI253或同类CMOS器件的开发者具有直接参考价值可用于梳理驱动挂载流程、定位图像异常问题亦可作为后续平台移植与功能裁剪的基础模板。1. 拿到这份 MT6236 平台 HI253 sensor 驱动源码先别急着烧板子如果你在搜索引擎里敲下“MTK MT6236 HI253 sensor driver 源码”八成是刚从某个老项目目录或者同事的移动硬盘里翻出一个叫20110915_MTK_MT6236(11A)HI253_Jerry_V1[1].2_hi253sensordriver_源的压缩包。这个文件名长得像物流单但里面装的是联发科功能机平台上让 HI253 这颗 CMOS 摄像头传感器在预览、拍照时正常出图的驱动源文件。它解决的问题是平台自带的 sensor 适配库里没有 HI253或者预置的驱动的上电时序和寄存器配置和你的硬件板子对不上导致摄像头顶多显示黑屏或花屏甚至一进相机就死机。适合读这篇文章的是做功能机 BSP、摄像头驱动移植、或者还在维护古董嵌入式方案的工程师新手可以照着把驱动跑起来熟手可以跟着我一起把几个容易翻车的寄存器边界捋清楚。2. 先把硬件和代码框架对上MT6236(11A) 与 HI253 的通信关系2.1 为什么 MT6236 上要单独写 sensor driver平台 sensor 库的边界MT6236 是联发科功能机时代一颗很典型的基带 应用处理器单芯片方案跑的是 Nucleus OS 那套轻量级实时操作系统摄像头通路从 sensor 出来通过并行 DVP 或者串行接口接到平台的 ISP 模块。平台出厂时自带了一批常见的 sensor 驱动适配比如当时大量出货的 OV 系列、GC 系列厂商要自己做差异化往往换一颗成本更低的国产 sensor而平台库没有对应适配就需要 BSP 工程师从零写一个 driver 挂进去。与其在网上到处找 MTK 完整驱动不如把手头这份 HI253 的源工程读透它包含了 sensor 的上电、下电、初始化寄存器表、分辨率切换、增益和曝光控制正好覆盖平台 sensor 驱动框架需要的全部回调。HI253 的实际型号我并不确定它具体出自哪家代工厂但按当时功能机市场的常见命名习惯以 HI 开头的 CMOS sensor 多半是国产厂商的出货量很大的型号感光面积和功耗都比较克制主要用在 130 万到 200 万像素的拍照手机上。MT6236 能支持的最大分辨率也就是两百万像素上下所以 HI253 和这块平台在规格上是般配的。平台方面11A 是 MTK 软件版本分支的一种标识同一个硬件平台配合不同维护基线sensor 驱动的接口structs可能有细微差别这也是为什么你手里的源工程如果是从别的项目拷贝来的不能直接编过就完事必须先确认接口结构是否匹配。2.2 读懂文件名20110915_MTK_MT6236(11A)HI253_Jerry_V1[1].2_hi253sensordriver_源这个文件名把几乎所有背景信息都写清楚了20110915 是打包日期说明这份驱动是 2011 年 9 月 15 日那批工程导出的MTK_MT6236(11A) 是目标平台和软件基线HI253 是 sensor 型号Jerry 多半是写这份驱动的工程师名字V1[1].2 是 patch 版本号注意那个[1]是 Windows 系统下下载文件自动附加的很多人解压前会疑惑文件名里的方括号哪来的其实不影响内容最后的“源”表明这是完整源码包不是预编译的 lib。对于长期维护的人这个命名本身就是一份档案你回看项目历史时可以根据日期和版本号快速找到哪份驱动配哪版主板比如 V1.2 比 V1.1 改了什么往往就藏在代码注释或改动记录里。2.3 驱动在系统里的位置从上电到出图的调用链在 MT6236 平台里一个 sensor driver 不是孤立存在的。如果你打开工程目录会看到 sensor 驱动被放在 camera 相关的 hal 和驱动层之间。常见调用链是这样的用户打开相机应用应用层通过 media server 调用 camera halhal 再调用 sensor driver 注册的接口。sensor driver 拿到命令后第一步是平台先拉高 sensor 的电源 GPIO有的板子还有 AVDD、DOVDD 模拟电源同时给 MCLK 提供 24MHz 或者 12MHz 的时钟源第二步是把复位脚从低拉高释放 sensor 内部状态第三步是等待一小段时间让 sensor 内部模拟电路稳定然后通过 I2C 总线往寄存器里写初始化序列最后才是配置预览分辨率、设置曝光和增益让 sensor 开始输出 YUV 或者 RGB 数据给 ISP。这里面每一环节的先后顺序和延迟都是硬约束。比如有些 sensor 在电源起来之后需要 10 毫秒左右才开始响应 I2C如果你刚拉完电源就立刻去写寄存器写操作会直接无应答。平台框架通常提供了默认的Poweron函数模板但里面的延迟值是按平台自己的参考 sensor 调的换用 HI253 时必须重新验证。这也是为什么写一份新的 sensor driver 会有这么多玄学问题不是代码逻辑难度大而是硬件时序的微小差异很难一次调出来血泪经验都是拿示波器一下一下量出来的。3. 拆解 hi253sensordriver 源一个驱动文件里的六块拼图3.1 驱动注册与 sensor id让平台认得出这颗 sensor打开这份源码最先要看的不是细节而是驱动文件的整体结构。以 MTK 当时常见的 camera sensor 驱动模板为准一个源文件会从顶部定义一个全局的sensor_ldvt结构体它相当于一个身份证告诉平台这颗 sensor 的名字、设备地址、能够支持的分辨率以及各个操作的回调函数指针。HI253 的驱动注册代码块大致长这样static sensor_ldvt hi253_sensor_ldvt { .sensor_id HI253_SENSOR_ID, .name hi253, .slave_addr 0x40, .port CAM_PORT_DVP, .max_width 1600, .max_height 1200, .power_on hi253_power_on, .power_off hi253_power_off, .init hi253_init, /* 一次性初始化 */ .preview_setting hi253_preview_regs, .capture_setting hi253_capture_regs, .set_gain hi253_set_gain, .set_exposure hi253_set_exposure, };这段代码说明sensor_id是用来匹配平台某张 sensor ID 表的如果平台在编译时把 ID 定义为别的数字你需要先改一个地方否则平台会认为没有这颗 sensor。slave_addr是 I2C 从设备地址HI253 的 7 位地址一般是 0x40但不同批次或不同 AVDD 电压配置会有差分必须看 sensor 数据手册确认算上读写位的 8 位地址就是 0x80/0x81。我拿到一个陌生工程的第一件事就是核对slave_addr和硬件上拉电阻因为这是最容易隐藏问题的黑匣子。3.2 上下电时序模拟电源与 GPIO 的先后坑电源函数看着简单但 80% 的硬件适配问题都出在这里。sensor 一般需要三路电数字电源 DOVDD、模拟电源 AVDD、IO 电源 DVDD平台方案往往不单独给 sensor 做三路 LDO而是共用主板上已经存在的电源轨然后靠 GPIO 控制一个 MOS 管来做电源开关。实际代码里我们只需要关心几个 GPIO 的高低电平顺序下面是一段极简的power_on示例static void hi253_power_on(void) { /* 先开 IO 电源让 I2C 引脚有正确的电平参考 */ mtk_gpio_set(GPIO_SENSOR_DVDD_EN, 1); mtk_delay_ms(5); /* AVDD 稳定后再给模拟部分供电 */ mtk_gpio_set(GPIO_SENSOR_AVDD_EN, 1); mtk_delay_ms(10); /* 复位脚默认低等电源全部稳定后拉高 */ mtk_gpio_set(GPIO_SENSOR_RESET, 0); mtk_delay_ms(5); mtk_gpio_set(GPIO_SENSOR_RESET, 1); /* MCLK 由平台 PLL 输出电源起来后必须等 sensor 内主时钟锁定 */ mtk_delay_ms(20); }这里有个容易被忽略的参数mtk_delay_ms在未优化编译下是真实毫秒级但如果你跑的是 release 编译循环被优化掉实际延迟会远小于声明值调试时会导致 sensor 还没准备好就被写寄存器。我一般会在调试版里用平台提供的mtk_sleep_us多写几个不同档位配合逻辑分析仪实测每段到底消耗了多少毫秒。这个延迟参数不是越大越好上电总时间太长会影响相机启动速度用户按快门到画面出来超过一两秒就会被吐槽。3.3 寄存器配置表预览与拍摄的两套“长相”HI253 驱动源码里最占篇幅的是那张十六进制寄存器表。初始化序列一般包括 sensor 软复位、输出格式选择YUV422 还是 RGB565、窗口裁剪、增益上限、自动曝光相关的参数、镜像翻转开关、测试图案等。预览和拍照共用时钟分频表但输出的分辨率不同因此preview_setting和capture_setting是两个不同的表。static const struct hi253_reg hi253_preview_regs[] { {0x12, 0x80}, /* 软复位之后要延时 */ {0x0E, 0x05}, /* MCLK 分频设置24MHz/5 约等于 4.8MHz PCLK */ {0xFE, 0x00}, /* page0 */ {0x01, 0x13}, /* 输出格式 YUV */ {0x1A, 0x02}, /* 行时序调整 */ {0x1B, 0x00}, /* 垂直起始 */ /* 省略几十行 */ {0xFF, 0xFF}, /* 表结束标志 */ };在改动这张表时最重要的原则是不要凭感觉把别人驱动里的整表直接照搬。老驱动和新驱动的差异往往就在一两个寄存器上比如 HI253 在预览 640x480 下要求{0x16, 0x44}而在做 1280x960 拍照时要求{0x16, 0x74}这两者差别只是水平采样窗口边界。调花屏时我会用二分法先屏蔽掉一半的寄存器看画面变化趋势把可疑范围缩小到 4 个寄存器之内再逐个改。这个工作很枯燥但比盲目试要省很多时间。3.4 I2C 读写封装读写时序是驱动的心脏sensor driver 对外的所有操作最终都会落成 I2C 读写。MT6236 平台的 I2C 控制器支持普通模式100kHz和快速模式400kHz多数 sensor 的标准是 400kHz。问题往往出现在长寄存器表写入时平台上如果有其他外设如 eeprom、陀螺仪共用同一条 I2C 总线总线的负载电容可能过大导致上冲沿变缓本来能 400kHz 的采样现在会偶发 NACK。驱动里看到的读写函数通常长这样static int hi253_i2c_write(u8 reg, u8 val) { struct i2c_msg msg {0}; u8 buf[2] { reg, val }; msg.slave_addr HI253_SLAVE_ADDR; msg.data buf; msg.len 2; msg.flags 0; /* 写标志 */ if (mtk_i2c_transfer(msg, 1) ! 0) { return -1; } return 0; }参数方面mtk_i2c_transfer的第一个参数是消息指针第二个是消息条数。有个很容易踩的坑平台 I2C 驱动在每次 transfer 之间如果间隔过短部分 sensor 会丢失起始位正确做法是每笔写完后加一个 1~2 毫秒的间隔尤其是连续写上百个寄存器时要格外注意。我见过不少“预览偶尔黑屏”的问题最后定位不是寄存器配置错而是连续写太快中间丢了一两笔sensor 状态没对上就黑屏了。4. 把 HI253 驱动移植进你手中的 MT6236 工程落地步骤与参数4.1 准备阶段从旧工程捞驱动确认平台版本和编译环境如果你不是拿到了带完整工程的源码包而是手里有一个只有hi253sensordriver源文件的碎片第一步不是编译而是对照目标工程的驱动框架。MT6236 的 BSP 目录里通常会有一个camera/sensor/文件夹里面放着平台自带的所有 sensor 驱动每个文件里都定义了注册结构体你需要在工程的SensorList.c或类似文件里把 HI253 加入枚举列表。常见做法是打开工程的 camera sensor 目录找UVP_sensor.c这类参考文件比对它的sensor_ldvt结构成员名和顺序。比如有的工程把slave_addr写作i2c_addr把preview_setting写作preview_reg差一个字符编译都会报错。另外确认编译器版本老 MTK 工程常用 ADS、RVCT 2.2 或 GCC不同工具的 struct 对齐规则不完全一样但通常不会影响寄存器表本身。4.2 修改 sensor 相关宏定义与文件配置让平台认出一颗新 sensor一般要做三处修改。第一处是 sensor ID 枚举在头文件里加一个HI253_SENSOR_ID编号要和平台预留位置对应第二处是 sensor list 数组把 HI253 的注册结构体加进去第三处是编译脚本或 prj 文件把驱动 C 文件加入编译目标。这里以伪代码形式给出一个典型的枚举typedef enum { SENSOR_OV5642 0, SENSOR_GC0308, SENSOR_HI253, /* 新增加的 */ SENSOR_NONE, } CAMERA_SENSOR_ID_T;改动参数时需要特别留意SENSOR_NONE的位置不能变因为平台内部会拿sensor_id按顺序做映射有些老驱动里写死了MAX_SENSOR_NUM你插入新 sensor 时必须把MAX_SENSOR_NUM加一否则数组越界会把后面的数据结构覆盖掉典型表现是拍照后重启手机或死机。这个错误在编译期完全看不出来只有跑到那条初始化路径才爆雷。4.3 上电/下电函数里调整延迟参数在作好配置后编译之前先把上电延迟参数按你的硬件设计过一遍。如果你的板子给 AVDD 用的 LDO 是纯硬件使能软件只需要拉 GPIO那么从拉高到稳定可能只要 1 毫秒如果电源是由 PMIC 的 LDO 输出而且你在代码里通过 I2C 去配置 PMIC 的寄存器那么延迟要按 PMIC 手册重算。HI253 这类 sensor 的 datasheet 通常会标出 t1~t8 的时序要求比如 t1 是 AVDD 到 reset 拉起的间隔不能小于 2mst2 是 reset 拉起后到 I2C 可访问的间隔通常是 10ms 以上。最好的做法是在power_on函数里按这段参数用宏定义方便后续调板子时快速改#define HI253_POWER_STABLE_MS 2 #define HI253_RESET_HIGH_MS 5 #define HI253_POST_RESET_MS 10调试时如果 sensor 的 ID 寄存器读不到第一件事就是把这几个宏改大一个量级测试。比如HI253_POST_RESET_MS改成 100做一次长延时实验如果 ID 能读了说明时序余量不足如果改了也没用则要去查电压是不是真的到 2.8V 了。4.4 编译与烧录用 MTK 工具链把驱动编进 binMT6236 工程的编译一般是通过批处理或 Makefile 驱动的编完之后会生成一个分散加载的 bin 文件里面包含 phone ROM、用户分区、媒体数据等多个区域。摄像头驱动属于代码段编在 AP 侧镜像里。常见做法是在工程根目录运行make脚本并传入目标型号配置make clean make PRODUCTMT6236_S02 new这个过程会把 sensor driver 的 C 文件编译成目标文件再链接进ext_objs之类的镜像里。如果代码文件里有编译错误会有明确的Error提示但如果只有警告比如未用变量、结构体未初始化还是能编过而运行时可能因为结构体sensor_ldvt里没实际赋值的回调指针是零地址导致平台调用时跳飞。所以我编译时会加一条规则把 warnings 当作错误。在 Makefile 顶部追加CFLAGS -Werror这不算一个稳妥的最终方案但在移植初期能帮你少踩很多坑。烧录阶段网上随手能搜到各种 MTK 刷机工具和教程但对驱动调试真正有用的其实是平台自带的FlashTool配CCTCamera Calibration Tool。先把工程编出的 bin 用 Flashtool 烧进手机再通过 CCT 连接目标机读 sensor 寄存器确认当前实际生效的配置到底是不是你写的那一张表。5. 避坑指南HI253 驱动在 MT6236 上最常见的五个翻车现场5.1 I2C 一直 ACK 超时地址对不上还是上电没完成现象是打开相机预览画面全黑log 里不断刷i2c write fail或hi253 read id fail。原因有两类一是 I2C 从机地址写错比如用了 8 位地址 0x81 但平台内部还要再左移导致实际匹配不上二是上电时序里某个电压尚未稳定就发起了 I2C 通信。解决步骤是先只拉高电源然后用示波器测 sensor 供电脚看电压是否达到 datasheet 标注的 2.8V 并且纹波低于 50mV。如果电压正常再单步执行 I2C 读固定 ID 寄存器用逻辑分析仪抓波形看 sensor 是否响应了 ACK。如果响应了但读回来的 ID 和预期不符那就要怀疑是不是点错了 sensor而不是驱动问题。5.2 预览花屏但拍照正常分辨率时序表和 sensor 实际输出不匹配现象是预览画面有带状条纹或马赛克拍照却清晰正常。原因是预览状态下 sensor 输出的行场同步信号和 MT6236 ISP 配置的时序没有同步常见于你在初始化和预览表里写了两套不同的 HOD、VOD 值。解决方法是打开 sensor datasheet 的 timing diagram找到预览分辨率对应的window参数并和驱动里preview_setting表中{0x17, 0x26}这类寄存器比对。最容易翻车的是把拍照表的行窗口值沿用到了预览表导致输出的行长度多了几个像素ISP 按错误长度解包画面自然撕裂。5.3 画面偏紫/偏绿曝光步进与 gain 的表不配套现象是预览画面整体颜色不对或者说暗场景下偏紫、亮场景偏绿并且手动调白平衡无效。原因往往是 HI253 驱动在设置增益时和平台 AE 算法的步进不匹配比如 platform 把 gain 从 1.0 到 16.0 映射成 0 到 1023 的数值而 sensor 的寄存器只支持 0 到 127 且是非线性。解决方法是确认set_gain函数里有没有做对数映射,如果没有需要照着数据手册的 gain 表重写一段查表逻辑。这种事情当年在实验室里属于基础操作但在网上看不到一套可以直接抄的适配公式只能自己拿着数据手册对着色卡一遍遍调试。5.4 一进相机就死机中断与 DMA 的问题现象是点击相机图标后屏幕卡死或者黑屏后整机重启。原因多半不是 sensor 本身而是驱动里某个回调函数没有做空指针保护平台在 sensor 尚未注册完成时就启动了 DMA导致 DMA 访问了个非法地址。解决方法是先用平台提供的最小 sensor 概念把出图路径旁路掉。我一般会在init函数末尾加一个读 sensor ID 的校验如果校验失败主动返回 error而不是继续往下执行。这样死机就变成出错码便于在 log 里追问题。另一个常被忽视的原因是中断服务函数里调用了带延时的函数Nucleus OS 的 ISR 不应该消耗大量时间否则整个系统会被打断表现也是死机。5.5 温度一高就丢帧寄存器表和欠压的边缘情况现象是整机预热后相机开始一卡一卡偶发黑帧。原因可能是用于 sensor 的 LDO 电流不够或者时钟源布局不良导致 MCLK 在高频时边沿劣化。解决方法是先量 PCLK 和 MCLK 的上升沿看是否超过 sensor 最大 slew rate如果边沿过缓应当串接 33Ω 电阻并尽量缩短排线长度。寄存器层面则可以降低 PCLK 频率比如把输出时钟从 24MHz 降到 12MHz代价是帧率下降但换来稳定性。这种边缘问题最耗时间环境温度上升会让驱动里所有“看起来没问题”的参数都露出真面目所以正式量产前必须在温箱里跑一轮。6. 验证驱动的最后一里路用逻辑分析仪和示波器收尾6.1 I2C 波形抓取与寄存器配置核对驱动跑通预览只是第一步真正交付给生产前我会把逻辑分析仪挂到 I2C 的 SDA 和 SCL 上以 500kHz 采样率抓一段上电初始化过程。目的有两个一是确认所有写的寄存器都落到了 sensor 上没有写失败或跳过二是核对写寄存器的总时间是否在平台允许的 timeout 范围内。如果发现连续写入间隔太短导致时钟低电平周期不足就在驱动里补一个mtk_delay_us(200)让时序更难看懂但更可靠。6.2 MCLK/PCLK 测量与稳定性判断MCLK 由平台输出通常就是 24MHz 或 13MHzPCLK 是 sensor 输出像素时钟取决于你设置的分频寄存器。用示波器看波形时重点看占空比和上升沿毛刺。如果 PCLK 抖动超过 5%sensor 内部的 PLL 可能失锁常见原因是在初始化表里写入了互相矛盾的分频参数。把预览和拍照两组的 PCLK 频率都记录下来和 sensor 数据手册标称值对比偏差超过 5% 就要回查寄存器设置。6.3 收尾习惯把驱动参数和硬件版本写进注释我做完一块新板子上的 sensor 移植后习惯在hi253_sensor_ldvt结构体旁加一段注释记录三样东西板子电源方案是哪一路 LDO 供电的、上电延迟参数是根据哪个版本文档定的、调试中最后验证通过的 MCLK 和 PCLK 频率。这样半年以后再有同事接手看到的是工程日志式的驱动而不是一堆神秘的数字。写注释这件事也算是把“玄学”变成工程的一部分哪怕只是多写一行/* PCLK 12MHz on EVT2 board */都能帮你少走几次弯路。希望这篇笔记能帮你在旧的 MTK 工程里少翻点车把 HI253 驱动的每一个时序都调到能睡得着觉的程度。本文还有配套的精品资源点击获取