OV5640 hack - Page 1
Forum section: electronics / general

author: Unknown
author_rank: Unknown
timestamp: April 28, 2014, 12:59:33 am
content: POST REMOVED AT USERS REQUEST

author: hamster_nz
author_rank: Super Contributor
timestamp: April 28, 2014, 02:52:59 am
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: April 28, 2014, 11:22:45 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: April 28, 2014, 01:01:21 pm
content: A low end FPGA could do this. Look at mikeselectricstuff's series of videos on reversing iPod lcd - it's very similar interface.

author: nctnico
author_rank: Super Contributor
timestamp: April 28, 2014, 11:01:01 pm
content: If the module uses MIPI then you are out of luck. Those specs are closed and the datastreams are very high speed LVDS signals.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 28, 2014, 11:50:10 pm
content: THis might give you some ideas on an FPGA implementation....http://hamsterworks.co.nz/mediawiki/index.php/Zedboard_OV7670

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2014, 08:57:20 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: April 29, 2014, 09:01:04 pm
content: Quote from: nctnico on April 29, 2014, 08:57:20 pmMike 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 sothere's no shortage of that.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 29, 2014, 09:03:16 pm
content: Quote from: nctnico on April 29, 2014, 08:57:20 pmIME 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.

author: Dielectric
author_rank: Regular Contributor
timestamp: May 02, 2014, 01:25:37 pm
content: You can probably get a good start downloading the docs for this reference design:http://www.e-consystems.com/CX3-Reference-Design-Kit.aspRegistration required of course.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 12, 2014, 08:15:08 am
content: pereczes, the PCLK rate (48MHz typ, 96MHz max) is too high for Cypress FX2 used on that board

author: amyk
author_rank: Super Contributor
timestamp: May 12, 2014, 01:54:53 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: May 13, 2014, 01:27:04 pm
content: You can compare as well as I can, figure out what you need.You should also probably read more about MIPI first.

author: nctnico
author_rank: Super Contributor
timestamp: May 13, 2014, 11:02:22 pm
content: As I mentioned before: start with Mipi and you'll see you most probably hit a dead end right away.

author: miguelvp
author_rank: Super Contributor
timestamp: May 14, 2014, 12:22:26 am
content: 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 schematicSource for STM32 and schematics for the 2Megapixel cousin here:http://www.wvshare.com/product/OV2640-Camera-Board.htmSource for STM32 and schematics for the 1.3Megapixel cousin here:http://www.wvshare.com/product/OV9655-Camera-Board.htmI 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 barsBTW the input clock on the datasheet for the one the OP mentions is: 6 to 27 MHz

author: nctnico
author_rank: Super Contributor
timestamp: May 14, 2014, 01:46:37 am
content: 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.

author: miguelvp
author_rank: Super Contributor
timestamp: May 14, 2014, 01:59:11 am
content: What about SCCB? they all seem to support that?http://www.ovt.com/download_document.php?type=document&DID=63which 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 14, 2014, 09:57:09 am
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: May 14, 2014, 12:32:52 pm
content: Check outMike's iPod LCD reverse-engineering video seriesif 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.htmlA slightly different model with a parallel bus, interfaced to a Arduino:http://forum.arduino.cc/index.php?topic=159557.0Another Omnivision camera being used with a pixel clock of69.25KHz!:http://www.robozes.com/inaki/dproject/report.pdf

author: miguelvp
author_rank: Super Contributor
timestamp: May 14, 2014, 03:50:12 pm
content: Quote from: nctnico on May 14, 2014, 09:57:09 amLike 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 onehttp://www.wvshare.com/product/OV7670-Camera-Board.htmIn the downloads package it has sample code for anATmega32This 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.

author: miguelvp
author_rank: Super Contributor
timestamp: May 15, 2014, 08:52:23 am
content: 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 480I guess I can change register 0x12 to get RGB instead of YUV. leaving 0x0c as default & 0x40 to select between RGB 565 or RGB 555http://dev.xdevs.com/projects/c3se/repository/revisions/3ae89d5fc3c9/show/ARML0/lib/components/omnivisionWill play with other values and figure out what in there is set that is undocumented on the datasheet.

author: amyk
author_rank: Super Contributor
timestamp: May 15, 2014, 01:09:52 pm
content: QuoteYou'll need to refer to the datasheet for the details of the output formats in each mode.

author: hamster_nz
author_rank: Super Contributor
timestamp: May 16, 2014, 02:38:35 am
content: Quote from: miguelvp on May 15, 2014, 08:52:23 amBe 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.

author: miguelvp
author_rank: Super Contributor
timestamp: May 16, 2014, 03:49:04 am
content: Quote from: hamster_nz on May 16, 2014, 02:38:35 amThanks,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 peekI'm getting a 3 channel DAC 330Msps from China:http://www.wayengineer.com/digiasic-fpga-adv7125adv7123-vga-board-p-160.htmlUnsure 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.

author: miguelvp
author_rank: Super Contributor
timestamp: May 17, 2014, 04:32:16 pm
content: 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

author: miguelvp
author_rank: Super Contributor
timestamp: May 19, 2014, 01:46:35 am
content: I got distracted with the 3 channel DAC so I pushed it to 330MHz pixel clock to see how it responds (of course not hooking it to the monitor but to the scope). It does alright although very noisy!If you notice 1.289MHz times 256 steps is 330MHz per pixel.Then I did try 1920x1200@60Hz with a 193.16 MHz clock (well it was rounding it down to 193.111111 MHz) but the video controller didn't like it.So I settled for 1600x1200@60Hz and looks good with a 162.0 MHz pixel clock, gotta love the PLL to escape the built in 50MHz clockSorry for the terrible phone camera picture.Now back to the camera code.

author: hamster_nz
author_rank: Super Contributor
timestamp: May 19, 2014, 02:39:08 am
content: That is a nice DAC. I now want one!

author: miguelvp
author_rank: Super Contributor
timestamp: May 19, 2014, 03:38:04 am
content: Quote from: hamster_nz on May 19, 2014, 02:39:08 amI ordered it May 6th for $42 got it on May 17th with just $7 shipping total $49.I did specify on the comments that I wanted the ADV7123 but I guess it depends if you get lucky or not.PDF for the ADV125:http://www.analog.com/static/imported-files/data_sheets/ADV7125.pdfThe schematics and pinout (Altera 40 pin GPIO compatible) are at:http://www.wayengineer.com/digiasic-fpga-adv7125adv7123-vga-board-p-160.htmlThe packaging was alright but they sure put a lot of smelly tape around the box. Inside the box it was bubble wrapped and inside an antistatic sealed bag.Declared value for customs $7. Not that it matters in the US.I'm very happy with it, sure beats the 3 bit R2R 512 colors total DAC: