找回密码
 注册
搜索
查看: 19815|回复: 71

[讨论] 讨论:Camera调试

[复制链接]
发表于 2007-8-14 21:10:38 | 显示全部楼层 |阅读模式
各位调试Camera的时候肯定碰到过不少问题,我想大家对这些问题进行一下总结,对以后的调试也有一个参考和指导的作用,希望大家能分享自己的经验,抛砖引玉了:

问题1. 无法读取SensorID
现象:读取Sensor ID一直是0xFFFF
分析:如果排除Camera模组本身问题的话,那么问题的根源在于IIC通信不正常。考虑电平供给、复位信号以及时序问题。
解决方法:
从以下这三个方面着手:
(1)确定提供的电平是否正常;
(2)确定硬件复位信号;
(3)尝试拉长IIC读写等待时间:SENSOR_I2C_DELAY这个值可以调整大一点。

问题2. 预览花屏
现象:能正确读取Sensor ID,预览时屏幕上出现闪烁条纹,条纹颜色根据拍摄物体改变而改变,拍照能拍摄正常画面。
分析:说明IIC通讯已经正常,而且Sensor已经开始工作,测量MCLK、PCLK、HSYNC、VSYNC信号,分析信号,一般是后端显示配置时抓取的图象大小或者位置不正确导致。
解决方法:
调整抓取图象的起始位置(image_window->grab_start_x、image_window->grab_start_y)大小,尽量设置小一点(可设置为0,1进行尝试)。

PS:导致同一现象的原因肯定有多种,如果有不同的原因或方法,请大家补充。[br]<p align=right><font color=red>+5 RD币</font></p>
发表于 2007-8-16 10:03:05 | 显示全部楼层
UP[em08]
点评回复

使用道具 举报

发表于 2007-8-16 11:43:23 | 显示全部楼层
顶,下次也许用得上
点评回复

使用道具 举报

发表于 2007-8-22 17:50:06 | 显示全部楼层
总结得不错,顶以下![/COLOR][em08]
点评回复

使用道具 举报

发表于 2007-8-22 18:39:24 | 显示全部楼层
难能可贵。[em05]
点评回复

使用道具 举报

发表于 2007-8-27 15:30:07 | 显示全部楼层
SENSOR_I2C_DELAY是个什么值呀,能详细讲讲吗
点评回复

使用道具 举报

 楼主| 发表于 2007-8-29 15:21:01 | 显示全部楼层
个人理解:
比如在SCCB_send_byte函数里
                for(j=0;j<SENSOR_I2C_DELAY;j++);
                SET_SCCB_CLK_HIGH;
                for(j=0;j<SENSOR_I2C_DELAY;j++);
                SET_SCCB_CLK_LOW;
                for(j=0;j<SENSOR_I2C_DELAY;j++);
SENSOR_I2C_DELAY决定循环的次数,也就是决定等待的时间。
其他地方的作用也是一样的,等待电平的稳定,调整时序的。
点评回复

使用道具 举报

发表于 2007-8-31 13:20:28 | 显示全部楼层
还有个问题想问问,复位信号怎么设置?
不复位的时候,一直拉高即可还是有个时序?
我的复位信号是低激活
点评回复

使用道具 举报

 楼主| 发表于 2007-8-31 14:40:01 | 显示全部楼层

复位信号

<DIV class=quote><B>以下是引用<I>shrewl</I>在2007-8-31 13:20:28的发言:</B>
还有个问题想问问,复位信号怎么设置?
不复位的时候,一直拉高即可还是有个时序?
我的复位信号是低激活</DIV>


复位信号有两种模式,低电平复位和高电平复位:
低电平复位需要一个“高低高--__--”(或者“低高___---”)的电平变化;
高电平复位需要一个“低高低__--__”(或者“高低---___”)的电平变化。
因此,不复位的时候是维持在非复位电平的。
在MTK平台中,RESET_CMOS_SENSOR_MODE1是高复位,RESET_CMOS_SENSOR_MODE2是低复位。
如果你用的MTK平台,那么可以采用RESET_CMOS_SENSOR_MODE2来进行复位。
如果不是那么需要将RESET引脚的电平拉高,然后拉低,高电平维持的时间根据Datasheet来确定。
点评回复

使用道具 举报

发表于 2007-8-31 15:07:58 | 显示全部楼层
多谢楼上的:)
我是用gpio控制camera的RESET#,RESET#低复位
我现在碰到的问题是我能够用IIC读写camera寄存器一次,但第二次就报错.
还有我的RESET置为高(不复位)状态时,如果中间延时500us以上再去用IIC控制camera时也报错.
所以我现在怀疑我的RESET,但我的RESET能够由GPIO控制高和低.
点评回复

使用道具 举报

发表于 2007-8-31 16:04:51 | 显示全部楼层
楼主碰到过这种情况吗?
希望接受你的指导.
点评回复

使用道具 举报

发表于 2007-9-1 02:16:32 | 显示全部楼层
关注!
[em01][em08]
点评回复

使用道具 举报

 楼主| 发表于 2007-9-1 15:28:27 | 显示全部楼层
<DIV class=quote><B>以下是引用<I>shrewl</I>在2007-8-31 15:07:58的发言:</B>
多谢楼上的:)
我是用gpio控制camera的RESET#,RESET#低复位
我现在碰到的问题是我能够用IIC读写camera寄存器一次,但第二次就报错.
还有我的RESET置为高(不复位)状态时,如果中间延时500us以上再去用IIC控制camera时也报错.
所以我现在怀疑我的RESET,但我的RESET能够由GPIO控制高和低.</DIV>



不要这么客气,大家多交流交流,开这个帖就是想大家能多多交流:)
1、我现在碰到的问题是我能够用IIC读写camera寄存器一次,但第二次就报错.
你是怎么判断读写正确的?你是在读SensorID么?我以前也碰到过类似的问题,我觉得这个问题应该是跟时序有关的(个人意见)。
你可以这样尝试一下,IIC传送数据的时候,拉高拉低后都多等待一段时间,包括START和STOP。尽量让它稳定一点。
2、还有我的RESET置为高(不复位)状态时,如果中间延时500us以上再去用IIC控制camera时也报错.
这个不是很明白。
最狠的就是拿示波器直接去量你读写的信号,呵呵!
点评回复

使用道具 举报

发表于 2007-9-4 16:39:15 | 显示全部楼层
关于分屏造成的原因,自己的经验有以下几点。[52RD.com]
1. 前后PCLK有改变,使得帧同步(VYSNC)出错。[52RD.com]
2. 图象尺寸设置有误。[52RD.com]
3. 帧同步(VYSNC)不稳定-> 这个一直都没有搞懂,这个应该是sensor内部出错了?[52RD.com]
4.[52RD.com]
现在我遇到一个问题,对于PCLK前后都没有改变,尺寸设置正确的情况,几率性的出现分屏现象,大家有什么建议和看法啊?(连续拍照,9张,其中一张会有分屏现象)或者你之前遇到分屏现象是什么原因造成的啊?[52RD.com]

最后我除去原有的拍照延时解决了问题。
点评回复

使用道具 举报

发表于 2007-9-8 15:56:30 | 显示全部楼层
收藏!
点评回复

使用道具 举报

发表于 2007-9-8 16:18:12 | 显示全部楼层
To KING11:
   4.[52RD.com]
现在我遇到一个问题,对于PCLK前后都没有改变,尺寸设置正确的情况,几率性的出现分屏现象,大家有什么建议和看法啊?
-----》几率性的问题。可能是pclk太快,MTK BB端处理不过来导致的,需要降低clock,或者加dummy line,dummy pixel。确实是否是这个原因,可以试验对着亮处,是否更容易出现分频。
点评回复

使用道具 举报

发表于 2007-9-11 17:15:56 | 显示全部楼层
预览要等很过一段时间才有问题是什么原因呢
点评回复

使用道具 举报

发表于 2007-9-14 06:56:45 | 显示全部楼层
[em06]
点评回复

使用道具 举报

发表于 2007-11-12 20:38:41 | 显示全部楼层
我想请教一下,我调试ov9650的时候,屏幕出现的图象颜色不对头,有点像红外线热成像的那种感觉,郁闷的要死,敢问各位牛人,是啥原因哦?ov9650的datasheet上对寄存器的说明说得很简单,有的干脆就reserved,真不知道该怎么调哦?
点评回复

使用道具 举报

发表于 2007-11-13 11:37:18 | 显示全部楼层
你看看是不是你的YUV输出顺序颠倒了?
最好看图说话:)
点评回复

使用道具 举报

高级模式
B Color Image Link Quote Code Smilies

本版积分规则

Archiver|手机版|小黑屋|52RD我爱研发网 ( 沪ICP备2022007804号-2 )

GMT+8, 2024-11-14 14:50 , Processed in 0.067874 second(s), 18 queries , Gzip On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表