Generating a clock signal
- Thread starter BrendanP
- Start date
Chavaquiah
Senior Member
Using i2c commands, the Picaxe will take care of the clock signal for you. 
What Picaxe model will you be using? If you can go with hardware i2c, it will be much easier.
What Picaxe model will you be using? If you can go with hardware i2c, it will be much easier.
The PICAXE will generate the I2C Bus clock signal but only while I2C communications are in progresss. The camera may require a continuous clock which would have to be generated separately.
@ BrendanP : Do you have a link to a datasheet so people can look to see what it says, understand what its requirements are ?
@ BrendanP : Do you have a link to a datasheet so people can look to see what it says, understand what its requirements are ?
Chavaquiah
Senior Member
See http://www.ovt.com/download_document.php?type=document&DID=63 for SCCB specification. It can operate in two wire mode (i2c compatible). The clock signal is supposed to remain high when no communication is in progress, but I assume that's how i2c normally goes.
...but the Clock Input on the Product Brief easily findable by Google (http://www.ovt.com/uploads/parts/OV7670_PB(2.2)_web.pdf) shows an external clock going into the video timing generator.
But without a real data sheet that indicates what the clock requirements are, we are in cystal ball land...
But without a real data sheet that indicates what the clock requirements are, we are in cystal ball land...
InvaderZim
Senior Member
Erm...what's your application? You can *command* the camera with I2C, but the video data is going to come out of an 8-bit port at MHz data rates (~27MHz?). I think it's 640x480 pixels times 3 bytes/pixel times 30 frames/second. It'd take almost a megabyte of ram to store a single raw image. What do you have going on?
I've heard of people interfacing with complete cameras before with success. It's more expensive, but it works. Some cameras even run a tiny OS that you can talk to and execute scripts on, so an AXE could control the taking and naming of pictures. But the image data itself is massive.
I've heard of people interfacing with complete cameras before with success. It's more expensive, but it works. Some cameras even run a tiny OS that you can talk to and execute scripts on, so an AXE could control the taking and naming of pictures. But the image data itself is massive.
Thanks guys. I looked around before posting for a link to a data sheet, which I usually provide when posting. I couldn't find one at the time. (I had to sign a NDA with OminiVision to get data sheets I got).
I'm only using picaxe to comm the camera, the signal processing is done with other hardware whose maker recommends the OV7670 for use with it.
"....Found a preliminary datasheet which indicates it's a 24MHz clock, would need to check the release datasheet. In this application the clock probably has to be stable so a crystal oscillator module is likely the best thing to use...."
Hippy, does the crystal oscillator module generate a signal for the camera only? If so how does that "fit in" with the camera receiving I2C comms from the picaxe at a different clock rate? (I2C fast for instance)
I'm only using picaxe to comm the camera, the signal processing is done with other hardware whose maker recommends the OV7670 for use with it.
"....Found a preliminary datasheet which indicates it's a 24MHz clock, would need to check the release datasheet. In this application the clock probably has to be stable so a crystal oscillator module is likely the best thing to use...."
Hippy, does the crystal oscillator module generate a signal for the camera only? If so how does that "fit in" with the camera receiving I2C comms from the picaxe at a different clock rate? (I2C fast for instance)
Well the I2C comms certainly will be at a different rate to the 24MHz clock, but whether the camera supports 100Khz (slow) or 400kHz (fast) SCCB/I2C is going to be defined in the proper datasheet.
Much as MartinM57 says - the 24Mhz ( or whatever ) clock is required for the IC to perform its internal processing and probably affects the rate it scans the image and puts out its video. It may have an affect on I2C comms but I2C bus rates are usually largely independent of the system clock speed.
This is the preliminary datasheet I found ...
www.semic.cn/admin/bookpic/OV7670_DS (1.3)1.pdf
If OmniVision only officially release datasheets on signing an NDA it's going to be difficult for others to give any real advice without potentially breaching such an NDA so you will likely have to seek support from OmniVision or just dive in, try to figure it out for yourself.
This is the preliminary datasheet I found ...
www.semic.cn/admin/bookpic/OV7670_DS (1.3)1.pdf
If OmniVision only officially release datasheets on signing an NDA it's going to be difficult for others to give any real advice without potentially breaching such an NDA so you will likely have to seek support from OmniVision or just dive in, try to figure it out for yourself.
As hippy says, it's a little tricky to answer your question if the data can not be provided.
I2C is a synchronous method of serial comms and the timing limits should be in your data sheet - usually presented as numerical info plus a timing diagram (lots of wiggley lines).
Whether your transfer is at 50kHz or 100kHz it is usually neither here nor there. It's not like Asynch serial where timing is crucial because there is clock synch.
Best you get the I2C document from Phillips/NXP to show you about I2C definitions -
http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf
It doesn't matter whether its 24MHz or WhateverMHz , the I2C limit and spec should be provided in the Data Sheet as said by Martin.
The data transfer is governed by the clock rate limits which will be an arithmetical function of the master clock (and hardware/firmware limitations).
This, again, should be defined in the Manufacturer's Data Sheet.
If you have signed an NDA then it really is the responsibility of the manufacturers to provide you with the information rather than us lot guessing. And they will probably expect you to have a reasonable working knowledge of Synch serial comms.
The Manufacturer should be providing timing limitations (which reflect the maximum I2C speed which is what "slow" and "fast" really refer to). They should also provide you with address info and details on any other protocols and logic levels.
Sounds like a fun project. Let us know what happens.
I2C is a synchronous method of serial comms and the timing limits should be in your data sheet - usually presented as numerical info plus a timing diagram (lots of wiggley lines).
Whether your transfer is at 50kHz or 100kHz it is usually neither here nor there. It's not like Asynch serial where timing is crucial because there is clock synch.
Best you get the I2C document from Phillips/NXP to show you about I2C definitions -
http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf
It doesn't matter whether its 24MHz or WhateverMHz , the I2C limit and spec should be provided in the Data Sheet as said by Martin.
The data transfer is governed by the clock rate limits which will be an arithmetical function of the master clock (and hardware/firmware limitations).
This, again, should be defined in the Manufacturer's Data Sheet.
If you have signed an NDA then it really is the responsibility of the manufacturers to provide you with the information rather than us lot guessing. And they will probably expect you to have a reasonable working knowledge of Synch serial comms.
The Manufacturer should be providing timing limitations (which reflect the maximum I2C speed which is what "slow" and "fast" really refer to). They should also provide you with address info and details on any other protocols and logic levels.
Sounds like a fun project. Let us know what happens.
Sorry for not being more helpful, I'm doing 10 hours days at work and working on this for a few hours each evening. I was little hazy last night.
The OV7670 is using I2C 400kHz (fast).
I'm familiar with the timing diagrams. I've used I2C with Winbonds audio recording IC's some time ago.
I have a good understanding of the register addresses and the commands used to effect the different functions of the camera.
Ive have emailed Omni to see what clock signal generator they recommend. I will also check with them re. the effect of the two different clock signals on the OV7670.
Some time ago at my last job I mentioned to the boss J.T., (a older civil engineer) I had thought of doing electronic engineering off campus. He said don't bother and pointing down the corridor at one of his staff bashing away on auto cad said "he costs me 60K year, as long as you know how to tell them what you want thats enough". On the current project I'm on the guys on the tools make twice what the graduate civil engineers make. (unionized labor versus no union).
I recently made contact with a couple in Nanjing, she's a ex GE info services SW engineer and her husband is a hardware engineer. A electronic engineer in Nanjing makes around $500 au (I did some research) a month. I make more than that in one day. They have sourced a lot of parts for me so far and are going to do the pcb design and get them manufactured .
So taking JT's advice I'm really only after a broad understanding the external clock signal is generated and the over all concept of how two sigs could work in conjunction with the same hardware so I can explain what I need to happen to engineers.
The OV7670 is using I2C 400kHz (fast).
I'm familiar with the timing diagrams. I've used I2C with Winbonds audio recording IC's some time ago.
I have a good understanding of the register addresses and the commands used to effect the different functions of the camera.
Ive have emailed Omni to see what clock signal generator they recommend. I will also check with them re. the effect of the two different clock signals on the OV7670.
Some time ago at my last job I mentioned to the boss J.T., (a older civil engineer) I had thought of doing electronic engineering off campus. He said don't bother and pointing down the corridor at one of his staff bashing away on auto cad said "he costs me 60K year, as long as you know how to tell them what you want thats enough". On the current project I'm on the guys on the tools make twice what the graduate civil engineers make. (unionized labor versus no union).
I recently made contact with a couple in Nanjing, she's a ex GE info services SW engineer and her husband is a hardware engineer. A electronic engineer in Nanjing makes around $500 au (I did some research) a month. I make more than that in one day. They have sourced a lot of parts for me so far and are going to do the pcb design and get them manufactured .
So taking JT's advice I'm really only after a broad understanding the external clock signal is generated and the over all concept of how two sigs could work in conjunction with the same hardware so I can explain what I need to happen to engineers.
Last edited:
I think you are seeing it as more complicated than it likely is - Throw the 24MHz ( or whatever ) into the chip, throw the I2C signals into it as well, job done.
There aren't really two different clock signals into the chip, only the 24MHz system clock. It's just convention / historical that the 'push a piece of data into the chip' pulse used for I2C is also called a clock. It doesn't drive the chip in any way other than to put data into it.
There aren't really two different clock signals into the chip, only the 24MHz system clock. It's just convention / historical that the 'push a piece of data into the chip' pulse used for I2C is also called a clock. It doesn't drive the chip in any way other than to put data into it.
Thanks Hippy, you're a great guy.
I queried Omni re. recommended parts, reply is below.
Hi Brendan,
We don’t have recommendation for oscillator. The oscillator just need to filful the timing specs in the sensor spec. We are using the signal generated from the MCU IO on our demo board.
Rgds,
Aun Kie
I queried Omni re. recommended parts, reply is below.
Hi Brendan,
We don’t have recommendation for oscillator. The oscillator just need to filful the timing specs in the sensor spec. We are using the signal generated from the MCU IO on our demo board.
Rgds,
Aun Kie