驱动调试常见问题_Camera

admin

        手机等平台上使用的Camera sensor通常是由类似I2C这样的总线进行寄存器控制，由CPU端的Controller提供所需的驱动时序，通常支持YUV和RGB等数据格式。有的Sensor需要由CPU进行图像处理工作，有的Sensor自己会集成图像处理芯片，完成一些基础的图像处理工作，还有些高像素的Sensor甚至自己完成JPEG的编码工作。因为硬件的多样性，我所遇到的问题可能和你的原因现象都不尽相同，分析内容仅供参考。

Sensor端I2C总线没有响应

• 症状
  
  ) B8 C- e/ @! e$ Y' [5 U% A+ @& [

   

    所有输入电压和时钟信号都正常，往I2C总线上写入读取寄存器数据的命令后，sensor没有响应，没有数据从I2C总线上输出。

# ~9 W6 F, [! p, J: U! J$ ~$ a
) S, t2 l3 v1 @0 k/ C3 q  s- @( I+ d

• 分析
  4 [( \  D$ ~7 N4 k5 {
  $ i9 n' n) k: g5 U$ ~

    因为测量发现一切输出信号都正常，所以往往都会怀疑Sensor硬件存在问题，不过99%的情况，实际的原因总是因为I2C总线的ID值没有设置对，导致设备不响应命令。据我的观察，每次一个新的工程师在调试Sensor的时候几乎都会遇上这个问题。

    之所以这么容易设置错误的原因，是因为通常Camera Sensor的Spec上所写的I2C ID号，还包含了最后一位读写方向位。而这一位在I2C总线的定义中，严格来说，不属于ID的一部分，所以Linux I2C的驱动API中的调用参数里的ID号，通常是不考虑这一位的，读写方向位会在具体的读写操作中，在寄存器中进行设置。
* [0 k  }  Z* E/ L% x6 r* m/ v- m
& j. H2 l* z; Q. K3 s" M

• 解决
  % G1 w7 O" D/ S. J# W- P

    例如Spec上会写 读写寄存器操作 I2C ID 分别为 0x64和0x65，实际调用API时应该使用0x32作为该设备的I2C ID
' _2 F8 m# }/ N$ A. W+ S" C& i图像中有不断变化的细密的水平条纹

• 症状
  0 a# ~( ~, |+ N
  * v) m& C0 B7 b' R+ f% B  N

   
    与荧光灯的频闪造成的大面积的滚动水平条纹不同，表现出来的是一个像素高的水平条纹状躁点，位置不固定，数量比较多，而且随光线强弱有一定的变化

6 h; B8 ?1 ?0 q* F- t- I2 m

• 分析
  % h* E5 {% K# t5 M0 H/ B0 p
  

   
    因为设置某些sensor寄存器的时候，会影响到这些水平条纹的颜色，所以基本上排除是在数据传输过程中板子对数据造成的干扰，也排除接触不良的可能性，应该是数据在sensor内部已经存在这些水平条纹。
    此外相同的初始化序列，相同的sensor，在厂商的demo版上也没有发生这种情况，所以也基本排除软件的问题。
    最后，发现原先为了节省硬件成本，将sensor的两个电压相同的模拟电和数字电由同一芯片输出供给，导致两者之间互相干扰，影响了sensor的正常工作
" W* f& q1 M; f4 p

• 解决
  ' ], o+ i7 q, D2 ~2 L8 J/ O: O; W
  ; n+ Y$ Q3 ?, X. m, S9 r

    将模拟电和数字电分离单独供电
% e  o' k$ R- ]2 x% H3 g
图像上有固定的锯齿状垂直条纹

• 症状
  
  

   
. Y5 A$ V( e4 }4 o& y" O  B/ w8 E    图像上有明显的垂直条纹，全屏分布，非常细密，好像百叶窗一样。
& z! p0 c& ?$ U2 N# n1 [$ N
% ^& O) _6 M% n! z% v5 P* n5 L

• 分析
  6 P0 n* {, S- z. r  Q. |( V$ f
  

   
: m2 s0 j, q3 C  x9 w3 F    仔细看可以发觉该垂直条纹实际上是由于图像上相邻的两两像素互相错位造成的锯齿状条纹

# e4 L! ?1 }2 `4 M3 Z* H& i  Q    仔细分析spec可以看到，由于sensor是按字节送出图像数据，在RGB565模式下，两个字节表示一个像素。而在我所使用的CPU的Camera控制器中，数据是按4个字节也就是一个字为单位处理的，由于CPU这端是按LSB方式处理数据的，所以在一个字内部，未经调整的话，两个像素的顺序是颠倒过来的。也就是最终由DMA将数据送到内存的连续buffer中时，像素的顺序是：像素2，像素1，像素4，像素3。。。
) d- ^% O. C9 v! ?" r: a# T3 i  |) |; y8 P

• 解决
  8 d% b1 y$ E5 T; i# {
  

& q: d8 D+ ^' d* y. U( a    用程序调整像素顺序，为了减少附加计算对CPU的负担，可以将这一步操作合并在其它类似颜色转换或PACK模式转Planer模式等操作中。
, i* Y/ ~; p# d9 k' C1 N$ d
. s! K1 b4 ?: r/ z8 [大尺寸时容易出现图像错位

• 症状
  - a7 |7 z. m: i
  2 K( m& x9 Q# P$ @) q

   
6 J7 d$ \8 p/ m+ A% Q    当sensor工作在最大分辨率的情况下时，图像容易出现上下错位的现象。
: H: {( T; U# ^( j

• 分析
  
  ! m( d8 K2 ^6 n4 c

   
! x( O) e2 y; S) r    跟踪程序可以看到这时候CPU的Camera控制器的FIFO缓存发生了溢出现象，也就是说DMA来不及将FIFO中的数据传送到内存中，该例中sensor在最大分辨率的情况下，输出数据的时钟工作在24MHZ，理论上说，DMA应该是来得急传送数据的，但是可能因为内存带宽还会被其它设备如CPU占用，导致来不及写入内存，使得DMA没有最大负荷的工作，所以来不及将FIFO中的数据读出，导致部分数据丢失，图像错位。
" h# A4 b! D: Q) @+ r
6 E0 T% N3 j) ]* K. R

• 解决
  * R& |. a& P. `0 r2 t9 g
  

    某些情况下，改变DMA传输的启动阙值可以解决该问题，但是有些情况是无效的

2 c4 T) s& r$ u8 L' a; V5 J9 P    考虑到最高分辨率仅在拍照的时候使用，预览的时候并不使用该分辨率，所以，在不影响预览桢数的情况下，可以在拍照的一瞬间改变分辨率的同时，修改sensor的时钟频率，降低到一个不会导致FIFO溢出的频率

    另外，在截获最高分辨率的图像的同时，尽量不执行其它的内存相关操作。截获完图像马上切换回预览用的分辨率。通过这些办法，减少发生FIFO溢出的可能性。
0 A  H7 }  e+ B' Q4 n/ y$ m
0 {9 n2 y! {( P7 \; R读取到的数据显示出来的时候是花屏

• 症状
  
  9 T9 B' }% I# W# O

   
! ^* k4 @& c( I+ Q6 }6 y    读取到的数据显示出来的时候是花屏，但是明显是随着所拍摄的对象的变化而变化的。

; S2 ?  o$ w% W. f, c  u% M, H

• 分析
  9 E& a  m+ t. a* X
  

   
7 g, a4 C) s7 b7 R. I# j    具体来说，常见的情况包括：
1 R- y- D' ^- k+ P% Z8 X( J: {    显示的数据是完全的花屏，或者可以看出物体大致轮廓，但颜色完全不对，例如一片绿色。这种情况往往是因为图像数据格式不匹配，例如没有处理YUV2RGB，YUV的各个分量采样顺序与软件计算的取值顺序不匹配等。

    如果花屏的具体表现是图像不断变换，没有规律，通常有可能是数据接收的触发边沿有误，导致没有正确的接收数据。
8 N% N; A& v9 E( {( M: n   
, x. i+ {. m6 V& Y- D. n! M0 `5 `    另外有一次，花屏的时候，仔细观察花屏的图案，发现有部分错位重复的图案的迹象。因此分析可能是Sensor的物理layout，其长宽比例与LCD刚好相反，仔细查看Spec得到确认。

3 S# V8 T5 h6 s. h6 o6 v

• 解决
  5 c3 t0 \4 H* I8 d0 `
  * |) M1 h* o" @+ ?9 z. s" W- `

    具体情况具体处理了。


7 w% G, y. \- V# i1 h4 X6 D( P) F) {

; H" N, F* b6 ]* \
& o8 c3 Q+ q( v6 R2 a

玉州

分析很到位，希望对自己有帮助
. `9 N/ s5 n8 R, P& q' T0 t" k

大尺寸时容易出现图像错位 这种是什么现象呢？

大尺寸时容易出现图像错位
这种问题是一种什么现象呢？能发张图看下吗？