【转载】驱动调试常见问题_Camera
转载自：http://blog.csdn.net/chi001/article/details/7360206
在嵌入式系统，如手机等平台上使用的Camera sensor通常是由类似I2C这样的总线进行寄存器控制，由CPU端的Controller提供所需的驱动时序，通常支持YUV和RGB等数据格式。有 的Sensor需要由CPU进行图像处理工作，有的Sensor自己会集成图像处理芯片，完成一些基础的图像处理工作，还有些高像素的Sensor甚至自 己完成JPEG的编码工作。因为硬件的多样性，我所遇到的问题可能和你的原因现象都不尽相同，分析内容仅供参考。
Sensor端I2C总线没有响应
-
症状
所有输入电压和时钟信号都正常，往I2C总线上写入读取寄存器 数据的命令后，sensor没有响应，没有数据从I2C总线上输出。
-
分析
因为测量发现一切输出信号都正常，所以往往都会怀疑Sensor硬件存在问题，不过99% 的情况，实际的原因总是因为I2C总线的ID值没有设置对，导致设备不响应命令。据我的观察，每次一个新的工程师在调试Sensor的时候几乎都会遇上这 个问题。
之所以这么容易设置错误的原因，是因为通常Camera Sensor的Spec上所写的I2C ID号，还包含了最后一位读写方向位。而这一位在I2C总线的定义中，严格来说，不属于ID的一部分，所以Linux I2C的驱动API中的调用参数里的ID号，通常是不考虑这一位的，读写方向位会在具体的读写操作中，在寄存器中进行设置。
- 解决
例如Spec上会写 读写寄存器操作 I2C ID 分别为 0x64和0x65，实际调用API时应该使用0x32作为该设备的I2C ID
图像中有不断变化的细密的水平条纹
-
症状与荧光灯的频闪造成的大面积的滚动水平条纹不同，表现出来 的是一个像素高的水平条纹状躁点，位置不固定，数量比较多，而且随光线强弱有一定的变化
-
分析
因为设置某些sensor寄存器的时候，会影响到这些 水平条纹的颜色，所以基本上排除是在数据传输过程中板子对数据造成的干扰，也排除接触不良的可能性，应该是数据在sensor内部已经存在这些水平条纹。
此外相同的初始化序列，相同的sensor，在厂商的 demo版上也没有发生这种情况，所以也基本排除软件的问题。
最后，发现原先为了节省硬件成本，将sensor的两 个电压相同的模拟电和数字电由同一芯片输出供给，导致两者之间互相干扰，影响了sensor的正常工作
-
解决
将模拟电和数字电分离单独供电
图像上有固定的锯齿状垂直条纹
-
症状
图像上有明显的垂直条纹，全屏分布，非常细密，好像百 叶窗一样。
-
分析
仔细看可以发觉该垂直条纹实际上是由于图像上相邻的 两两像素互相错位造成的锯齿状条纹
仔细分析spec可以看到，由于sensor是按字节送 出图像数据，在RGB565模式下，两个字节表示一个像素。而在我所使用的CPU的Camera控制器中，数据是按4个字节也就是一个字为单位处理的，由 于CPU这端是按LSB方式处理数据的，所以在一个字内部，未经调整的话，两个像素的顺序是颠倒过来的。也就是最终由DMA将数据送到内存的连续 buffer中时，像素的顺序是：像素2，像素1，像素4，像素3。。。
-
解决
用程序调整像素顺序，为了减少附加计算对CPU的负 担，可以将这一步操作合并在其它类似颜色转换或PACK模式转Planer模式等操作中。
大尺寸时容易出现图像错位
-
症状
-
分析
-
解决
某些情况下，改变DMA传输的启动阙值可以解决该问 题，但是有些情况是无效的
考虑到最高分辨率仅在拍照的时候使用，预览的时候并不使 用该分辨率，所以，在不影响预览桢数的情况下，可以在拍照的一瞬间改变分辨率的同时，修改sensor的时钟频率，降低到一个不会导致FIFO溢出的频率
另外，在截获最高分辨率的图像的同时，尽量不执行其它的 内存相关操作。截获完图像马上切换回预览用的分辨率。通过这些办法，减少发生FIFO溢出的可能性。
读取到的数据显示出来的时候是花屏
-
症状
-
分析
显示的数据是完全的花屏，或者可以看出物体大致轮廓， 但颜色完全不对，例如一片绿色。这种情况往往是因为图像数据格式不匹配，例如没有处理YUV2RGB，YUV的各个分量采样顺序与软件计算的取值顺序不匹 配等。
如果花屏的具体表现是图像不断变换，没有规律，通常 有可能是数据接收的触发边沿有误，导致没有正确的接收数据。
另外有一次，花屏的时候，仔细观察花屏的图案，发现有部 分错位重复的图案的迹象。因此分析可能是Sensor的物理layout，其长宽比例与LCD刚好相反，仔细查看Spec得到确认。
-
解决
