cmos image sensor master and slave mode

Hi everyone, I want to buy c3038 camera module that uses omnivision's ov6630 image sensor. I'm trying to make an interface for this camera in fpga to grab the frame. To have the complete control over the incoming data, I thought of using camera in slave mode. But there seems to be two problem with that:

i) The ov6630 datasheet says that 'hsync' signal from master should be connected to chsync/bw (pin 42) pin in sensor. But seeing datasheet of c3038 it does not seem to have made this pin available to be used.

ii) the timing diagram for ZV port standard shows that href signal is asserted for new line only when hsync signal goes low after being high for sometime indicating start of the frame. However, hsync signal we need to provide in slave mode is supposed to be high when vsync signal is still high (as shown in slave mode operation timing diagram.) I'm confused about the hsync and href signal for slave mode.

I'm trying to design at least for now for master mode but then this will require my interface to wait for the new frame to start when it needs a frame. I don't know as for now how this can affect the system which consists of detecting some object based on the data from the camera.

so guys who have worked with cmos cameras, I think I'll have enough help to solve this issue soon. thanks.

Reply to
Loading thread data ...

So they have made a master device only.

If you cannot drive the module in slave mode, don't bother with slave mode timings.

Just remember that in slave mode you will have to generate timing patterns to send to the camera device based on counters for pixels, lines, fields and memory addressing.

Whilst in master mdoe you trigger these counters from start of field/frame to acquire the data.

So you wait for VSYNC and HREF combination for odd or even field to denote start of frame acquire frame, via FPGA. Alternatively you could just acquire one field. Depending on how you have configured the camera device.

If your processing is really simple process the data as you are acquiring the data. In reality, you are more likely to acquire the data and store it in local memory for processing.

This way you can acquire one image, whilst processing the previous image. Alternatively you only acquire frames when the processing is finished or nearly finished.

Last time I worked with Omnivision cameras it was with the actual devices on our own board.

Paul Carpenter          |
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

In master mode I haven't yet figured out if I can tell camera just when to send new frame and when to stop. I don't know if I overlooked the datasheet but I didn't see it there!!

I'll be using the progressive scan mode. I don't know if I am understanding right but for this mode I think I need to simply wait for the href signal to go high after the falling edge of vsync signal. I just completed the interface in FPGA. This module will start its operation when start_capture (which is its input) is asserted. After start_capture it will wait for new valid frame to start assuming camera has been sending pixel data continuosly (this of course would require some setting of registers through I2c which will be done by another module in fpga). After the vsync pulse it will get data for this frame. So if the camera had just started to send new frame when start_capture is asserted then this module has to wait for almost complete frame before next frame starts.

Is my analysis correct? I haven't just yet bought the camera, so haven't got chance to actually check with hardware.

If the processing will take too long time to catch up with the frames coming then of course I'm thinking of using external ram which is plenty (128MB) in my board. Well FIFO within the fpga with size of some fraction of total frame size could be a help for simple processing tasks. But I haven't reached there yet.

Reply to



In master mode the camera is master, you cannot tell it when to start you wait for frame start point.

Look at the data sheet for that mode. Their datasheets are not great but they are better than most, and assume some understanding about digital vidoe streams.

In a very general sense yes that is right. Specifics depend on a=20 lot more than that.

--=20 Paul Carpenter | PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

Reply to
Paul Carpenter










I have just checked my module with the testbench I designed to generate the video signals just like the camera would. And it worked perfectly in modelsim during simulation. This has not yet included setting of the registers in the camera but I don't think that will be a problem. So I'll get the hardware and then check it out. Thanks for the replies Paul and once again sorry for the accidental postage of this same question in another thread which I've clarified in that thread.

t -

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.