高通CAMIF和OV sensor调试经验分享

要借用某高通平台的camera接口，联合OV(OmniVision)公司的sensor，实现手机摄像头的拍照及录像功能，需要处理两芯片、显示屏和需求配合的问题，在这个过程中遇到并解决了许多问题。
【关键词】
拍照  预览  CAMIF
一、问题的提出
新手上路，第一次见到ov sensor，第一次认识Qualcomm的 CAMIF，没有任何经验，调试中遇到诸多劫难，如没有预览不到任何象素点、图像色彩不对、拍照无效区域、dispsize设置不合适预览全屏问题、黑白模式上层设不成、预览和拍照范围不一致的问题、软件转90度压扁问题等等。
二、解决思路
先做基础理论的储备。
VGA ：640x480；
QVGA ：320x240；
YUV格式：4：2：2
曝光控制/伽玛增益/白平衡等都是效果方面的调整。
对于象素数较大的sensor，如1280x1024，由于数据量较大，通常预览分辨率640x512拍照分辨率是1280x1024，且拍照时的PCLK是预览时的2倍，这样可以对VFE（video front end）来说是同样的帧速率。
Ov7670的寄存器0x15的bit6可以切换sensor输出HREF或HSYNC，我们用HREF。
Camera_process_config_vfe初始化VFE寄存器；
Qcamraw_set_header设置sensor帧头；
代码分层：
层        Drivers        services        Oem层        App层
代码位置        camsensor        camera        Oemcamera.c        Qcamera.c/Qcamcorder.c



Trace32命令:data.image addr. 640. 480. /GS8，可方便的看某buffer地址中的图片，判断取到的预览图片内容和最终显示的屏上的差异。
camera_qdsp_cb是收到帧等事件的回调，根据预览和拍照的不同需要，QDSP会送来不同的格式，本例中拍照格式是YUV422PS，预览格式是RGB565LE。
要得到需要的帧率，需要给sensor寄存器设置时加入空白象素和空白行。对于ov7670，0x92/0x93加入空白行个数。
帧率的计算按照以下公式：
fps*(640+144)*(510+x)*2 = 12M(Pclk)
其中x是空行数，{0x92, 0x00},{0x93, 0x00}时，x为0，fps为15；{0x92, 0x19},{0x93, 0x01}时，x为281（0x119），fps为9.67。
如下图1是x为0时的时序图：



图 1   VGA Frame Timing
三、实践情况
3.1预览
首先关注寄存器设置是否成功，测试发现写完寄存器，再读出的值和写的部分不同，因为某些寄存器是在自动刷新的。
对于sensor，只要供电正常，且有MCLK，就应该有行场同步及PCLK信号。开始没有测到信号，后查出来同步信号在传输过程中由于某管脚对地短路，衰减了。
要保证代码中主芯片和sensor侧象素数（宽、高）、同步信号极性（高低电平）和采样频率（PCLK）设置一致，才能预览。主芯片通过CAMIF接口的寄存器设置。在camera_process_config_vfe中写入。
软件设置如下：

测出9.679fps时的波形如下图：




















15fps的时序如下：
VSYNC High:66ms（约510=17+480+10 lines）Low 394us   周期约66ms 即15fps;
HSYNC High:106us (约1280 clks) low 24.4us 周期约130us;
VSYNC上升沿到HSYNC上升沿的time :1.98ms，约17 lines;
HSYNC下降沿到VSYNC下降沿的time :1.57ms，约10 lines;
PCLK是12MHz.
HREF、VSYNC都用做同步信号，高通新近平台上通过采样同步信号得到数据，有效行前边的无效行不需精确设置，只要同步信号电平给定即可。检测计数到够一帧才会产生中断数据。
查完一切状态正常，但从log文件可以看看主芯片还是是未接到sensor的帧；
后再测信号，发现HREF信号实际板子上没传到CPU子板上。
总结经验：硬件调试时注意，信号测试要逐级测试，从输出一直到输入点上，考虑硬件通路可能存在的传输问题。硬件电路容易有对地短路的点，如遇到信号传输异常的。可以断电侧对地电阻，确认是否对地短路。
3.2拍照无效区域的问题
           
Dispsize设为216x160可以在128*160的屏上全屏预览，但拍出的照片有一条杂色区域，如图所示，这个问题在默认Dispsize设置128x96时也有。
30万像素，数据量比较小，预览和拍照可以用同一分辨率，所以snapshot不用重设寄存器，驱动中重设寄存器引起了拍照无效区域的问题，去掉解决。
3.4预览和拍照范围不一致的问题
CAMIF输出的是一个横长的图像，在竖长的屏上预览需要裁减，因此造成了用户看到的和拍到的明显不一致，为解决这个问题，需要把sensor从横着放置改为竖直放置，但是所用高通平台没有一个MDP，即图像旋转的硬件加速器，软件上的旋转可能会增加负担，对此，做了必要的验证工作。
从原理上看，不旋转和旋转90度的处理算法没有明显差异。
现象上看，软件令camera_default_rotation =90，camera预览和拍照及camcorder预览及录下的视频都顺时针转了90度。
用task profiling跟踪，不旋转和旋转90度占用CPU时间一样。详如下图：
旋转：0度；  display size: 216x160； Image size :160*120

     九宫格   QCAMERA预览 拍照      拍照      QCAMERA预览
旋转：90度；  display size: 216x160； Image size :160*120

     九宫格   QCAMERA预览 拍照      拍照      QCAMERA预览

3.5拍小尺寸照片压扁问题
软件和硬件都转过90度之后，拍出来的大尺寸照片和预览只有了微小差异，但小照片却被压扁了，从理论上分析，宽高比等和屏同样很协调，怎么也想不出道理。
最终用仿真器仔细跟踪拍照过程中各参数的设置，找到了原因：预览的CAMIF window根据 display_aspect_ratio不同分别基于宽或高来计算，拍照的CAMIF window也需要这么处理，否则看到的和拍到的会不同。
因此在代码上加了类似的处理。