OV5640 hack

[pereczes]

POST REMOVED AT USERS REQUEST

[hamster_nz]

Not possible directly - the camera has a 10 parallel bus to transfer pixel data, that runs at pixel clock rate. However, in some cases something like an AL422 FIFO can be put in front of a camera to buffer data.

[amyk]

Here's the datasheet, if you haven't got it already. The pixel clock is going to be far too high for an Arduino to read every pixel as it comes, but if you really want to make this a "hack", maybe you could do some sort of "equivalent time sampling" with a few SIPO shift registers to interface the MIPI... if you want full functionality you're going to have to use an FPGA or a devboard with a MIPI CSI interface - probably ARM-based.

[poorchava]

A low end FPGA could do this. Look at mikeselectricstuff's series of videos on reversing iPod lcd - it's very similar interface.

[nctnico]

If the module uses MIPI then you are out of luck. Those specs are closed and the datastreams are very high speed LVDS signals.

[hamster_nz]

THis might give you some ideas on an FPGA implementation....

http://hamsterworks.co.nz/mediawiki/index.php/Zedboard_OV7670

[nctnico]

Note the remark about the 'undocumented register settings'. Even with support from Omnivision it can take a lot of time to get their cameras going. The documentation is far from complete.

[amyk]

Note the remark about the 'undocumented register settings'. Even with support from Omnivision it can take a lot of time to get their cameras going. The documentation is far from complete.

Mike has given some great advice about taking the register settings from some existing open-source code that uses this model. This is a common tablet/smartphone camera so there's no shortage of that.

[mikeselectricstuff]

Note the remark about the 'undocumented register settings'. Even with support from Omnivision it can take a lot of time to get their cameras going. The documentation is far from complete.

IME you pretty much need an initial set of known-working register values to start from, then spend time tweaking to see what effects various bits have- the factory defaults are rarely useful, and the values in the datasheet, though generally correct as far as they go,  are rarely the full story.
My guess is when they design a new chip, they leave a lot of things in "reserved" registers that  are used to tweak & optimise stuff after they get first silicon back, but the datasheets that are readily available (without NDA) aren't updated to reflect the tweaked values.
   

[Dielectric]

You can probably get a good start downloading the docs for this reference design:

http://www.e-consystems.com/CX3-Reference-Design-Kit.asp

Registration required of course.

[abyrvalg]

pereczes, the PCLK rate (48MHz typ, 96MHz max) is too high for Cypress FX2 used on that board

[amyk]

Those FX2-based logic analysers can only do maximum 24Msps sample rate.

That said, from a quick scan of the camera datasheet I think you may be able to turn down the framerate so that the pixel clock is slow enough for it. You would still need a level translator to capture the signals, however, as the MIPI interface voltages are lower than 3.3V.

[amyk]

You can compare as well as I can, figure out what you need.

You should also probably read more about MIPI first.

[nctnico]

As I mentioned before: start with Mipi and you'll see you most probably hit a dead end right away.

[miguelvp]

Raspberry Pi uses the same or similar camera FWIW. You might be able to get some resources on that community, or google rapsberry pi camera schematic

Source for STM32 and schematics for the 2Megapixel cousin here:
http://www.wvshare.com/product/OV2640-Camera-Board.htm


Source for STM32 and schematics for the 1.3Megapixel cousin here:
http://www.wvshare.com/product/OV9655-Camera-Board.htm

I bought the later, didn't start playing with it yet but I'm going to use an FPGA, just got the video out done, now working on the PS/2 mouse input maybe I tackle the camera after that so I have something better to display than just some color bars


BTW the input clock on the datasheet for the one the OP mentions is: 6 to 27 MHz

[nctnico]

The camera chip supports both parallel and MIPI. The problem is that although all camera modules look the same some modules have parallel pins for the image data (which are easy to interface) while other camera modules only have the MIPI pins which are very hard to interface with generic logic. You'd need an FPGA with at least SERDES I/O and a MIPI IP core. I doubt you'll find the latter or even the specs to make one for free. MIPI is primarily used as an image data bus in mobile devices to safe space and emit less radiation.

[miguelvp]

What about SCCB? they all seem to support that?

http://www.ovt.com/download_document.php?type=document&DID=63

which seems to be I2C or some close flavor of it. Edit: actually it uses 400KHz for the configuration part like I2C2 but same thing.

The sources on those modules linked above use that and have SCCB code as well as the camera configuration code, with the datasheets at hand it shouldn't be too hard to figure it out right?

Edit: Although they do the actual capture via DMA but that is solvable.

[nctnico]

SCCB is Omnivision's name for I2C to avoid having to pay royalties. Expect to spend a lot of time to get an Omnivision camera working. I used one in a project WITH support and NDA from Omnivision but even then it took a lot of trial & error to get it going.

[amyk]

Check out Mike's iPod LCD reverse-engineering video series if you haven't watched it already, he got MIPI DSI displays working with an FPGA without needing to do anything special. MIPI CSI doesn't look that much more difficult, you just need to watch the voltages and timing.

Although it does say 6 ~ 27MHz you might be able to get away with a lower frequency; the main issue is dynamic logic and internal PLLs, but it appears from the datasheet that you can disable the PLL and use the input clock directly so that gets rid of the second issue.

Here's someone who has successfully used an 8MHz clock on a module spec'd for 10MHz minimum: http://embeddedprogrammer.blogspot.ca/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

A slightly different model with a parallel bus, interfaced to a Arduino:
http://forum.arduino.cc/index.php?topic=159557.0

Another Omnivision camera being used with a pixel clock of 69.25KHz!:
http://www.robozes.com/inaki/dproject/report.pdf

[miguelvp]

SCCB is Omnivision's name for I2C to avoid having to pay royalties. Expect to spend a lot of time to get an Omnivision camera working. I used one in a project WITH support and NDA from Omnivision but even then it took a lot of trial & error to get it going.

Like I said before, full source and schematics of two different Omnivision camera modules intended for an SMT32 in the links I put before, separate source for sccb and for the actual camera modules, including configuration intitialization.

But here is one that has a lot more information even if the camera is the lowest 0.3 megapixel one

http://www.wvshare.com/product/OV7670-Camera-Board.htm

In the downloads package it has sample code for an ATmega32

This one has way more information that the other two, separate SCCB and ov7670 source and header. diagrams for how it's all setup and datasheets, some in Chinese, schematics, board layout as well but in pdf.

This is their board configuration:


But since I'm going to port it to VHDL for my DE-0 Nano, it might take a bit. The good thing is that my scope can do I2C decoding, that might speed up things a bit.

[miguelvp]

So two things,

1st) My board (ov9655) doesn't support raw data (well it does but D1 and D0 are disconnected so I can't get 10bit raw) and I'm not about to solder the two pins to the 2 unconnected pins just yet.

2nd) I found settings for the yuv SXGA for my camera 1280 x 1024 @ 15 fps @ 48MHz input clock.
(7.5fps @ 24MHz input clock)
among as 30fps yuv formats:
QQCIF 88 x 72, QQVGA 160 x 120, QCIF 176 x 144, QVGA 320 x 240, CIF 352 x 288 & VGA 640 x 480

I guess I can change register 0x12 to get RGB instead of YUV. leaving 0x0c as default & 0x40 to select between RGB 565 or RGB 555

http://dev.xdevs.com/projects/c3se/repository/revisions/3ae89d5fc3c9/show/ARML0/lib/components/omnivision

Will play with other values and figure out what in there is set that is undocumented on the datasheet.

[amyk]

Output format: 8-/10-bit RGB RAW, RGB565/555/444, CCIR656, YUV422/420 and compression

You'll need to refer to the datasheet for the details of the output formats in each mode.

[hamster_nz]

I guess I can change register 0x12 to get RGB instead of YUV. leaving 0x0c as default & 0x40 to select between RGB 565 or RGB 555

Be careful that your interperation of what RGB is matches the camera designer's. RGB RAW is not what you are expecting - it is the pixel values from behind each colour filter, only one colour per pixel. You then need to post-filter with a Bayer filter (http://en.wikipedia.org/wiki/Bayer_filter) to give you a RGB triplet per pixel.

Also, it is far better to get the pain over with and learn how YUV 4:2:2 works, if only because you end up with three more bits of data per channel and can avoid ugly posterisation effect that 555 or 565 gives you.

[miguelvp]

I guess I can change register 0x12 to get RGB instead of YUV. leaving 0x0c as default & 0x40 to select between RGB 565 or RGB 555

Be careful that your interperation of what RGB is matches the camera designer's. RGB RAW is not what you are expecting - it is the pixel values from behind each colour filter, only one colour per pixel. You then need to post-filter with a Bayer filter (http://en.wikipedia.org/wiki/Bayer_filter) to give you a RGB triplet per pixel.

Also, it is far better to get the pain over with and learn how YUV 4:2:2 works, if only because you end up with three more bits of data per channel and can avoid ugly posterisation effect that 555 or 565 gives you.

Thanks,

Yeah, I can't even get the RAW data (well I could but not D0 and D1 since they are not connected) but I what actually thinking at the end to leave it as YUV because it's easier to do DSP by using the frequency of the UV data and then applying the luminance to it.

The reason I wanted to do RBG at the beginning is just to implement an easy frame buffer that I could display directly. But I guess I could just use the YUV since the conversion is pretty simple. I've done it before by software.

BTW thanks for your link on the first page and your work on your FPGA implementation. I was planning on doing mine from scratch to maximize my learning, but it's so tempting to peek

I'm getting a 3 channel DAC 330Msps from China:
http://www.wayengineer.com/digiasic-fpga-adv7125adv7123-vga-board-p-160.html

Unsure if it's 8 or 10 bit but it doesn't matter since the 10 bit one has the lower two grounded but that will reduce noise anyways. So, it's already in NJ so should get it next week. At the moment I'm using a 3bit DAC R2R that works great but I coded it and wired it so it will work with the one coming. And the connector is Altera GPIO compatible so pretty much plug and play and I already have the pins configured for the board.

Hmm, I did look up the Bayer filter you linked and now I want to implement it as well, Curse you! (in a good way). My camera has D9 to D0 for raw, for the rest is two bytes D9 to D2. But it has two pins not connected that I could wire to D1 and D0.

Here is a picture of the connector, D3 and DGND are connected by vias on the other side, D0 and D1 are totally unconnected and I have two spare N/C pins on the header, so maybe I'll wire them up.

[miguelvp]

Love Saturday deliveries, got the 3 channel video DAC and since I already had the code done I just plugged it in and viola.

Still 640x480 @60 Hz will push it more later. I also have the camera wired up but haven't finished the code yet.

The picture doesn't really show the colors right.

The DAC populated was the ADV7125 8bit, was hopping for the ADV7123 10 bits but oh well, it's still a 330MSPS DAC I wonder if I can push it to the max resolution that LCD can do 1920x1200@60Hz.

Seems to be pretty clean compared to the R2R 3bit DAC I was using before.


Now to work on the camera code to display something nicer.

Edit: added the transition from the last red line to the first green line. Don't mind the voltage of the green line, I only have one terminator and it's 50 ohm, I guess it's time to buy some T's and 75 Ohm terminators