OV7670 with both arduino uno and now mega

Saren:
I think there has been a misunderstanding. My camera is without fifo...

So is mine so will need the same connections as I use and the external sram. Also the reason d0-d7 not need shifting is the arduino will never drive those pins so it is up to you to make sure that those pins are always set to input on the arduino.

Hi, i have the ov7670 camera, an arduino uno rev 3 and ST M27C512-12F1 Eprom. Is it possible to take pictures with these components? and if so, how do i connect them together. i have seen that you used the spi ram, can i replace that with the eprom??
Please assist me on how to connect the arduino, camera and the eprom together to give me a picture.

This is the old school eprom with UV erase. There are several reason why this would not work. First of all how are you going to erase it in a reasonable time. Even if you had a UV led driven by the arduino it would still take awhile to erase and UV is bad for your eyes so you would need to cover it with something. Also you would not have enough pins are the eprom is parallel. Also how fast are the write speed will it even accept data fast enough. Another problem is that you would wear it out fast. Eproms only have a certain amount of writes (They do have unlimited reads though). Also this Eprom has only 64kb of memory you would have to break the frame up even more which would reduce performance even more. In short the Eprom would not work for this purpose save it for repairing a bios or make your own NES cartridge or do something fun with it but not in a camera. Just buy or sample the 23LC1024 it is kinda cheap at $2.59 if you only order one at digi-key and you will not regret it. It is even in dip package. The dip package one is called 23LC1024-I/P by the way

Clearly getting the eprom was a wrong move. My other option(or idea, but might not be a very good one) is to connect the camera to a SIM5216E 3g shield. the datasheet indicates that its possible to connect the camera pins on the shield but the pins are marked 'NC'.
this is the shield i have ftp://imall.iteadstudio.com/Shield/IM121026002/DS_IM121026002_3G_Shield.pdf
this is its schematic ftp://imall.iteadstudio.com/Shield/IM121026002/SCH_IM121026002_3G_Shield.pdf
Could i connect the camera to the shield instead of using the arduino directly?

Hello Mr_arduino
I have planed to use the OV7670 camera module to capture picture with arduino mega 2560 R3. I m using it to drive à robot and get few data from robot.
I m using arduino programming IDE to write code.
The code you gave is compiled with another compiler and as I do not have deep kwnowledge on this it is à liltle bit hard for me.
Is it possible to give us(I guess I m not alone in that case) a hello world example to capture picture and store it in an array( in order to save it in SD card or send it other serial) written with arduino IDE.
Thanks à lot in advance.

hye...i wanna ask if this camera is same with JPEG TTL CMOS camera???

@hlankoande
I made some code for the arduino mega awhile ago check it out it uses the arduino ide

@isaiful
It is no were near the jpeg TTL camera. The Jpeg TTL CMOS camera is way easier to use but cost more money.

Hello

I have the same problem with OV7670 v2 + Mega R3, a lack of experience stops me to get those things work together..
Mr_arduino it would be really great if could share the code and wiring with us?

Thank you.

Mr_arduino:
I think the 74HC245 would work just fine also a unidirectional one would work too. Pretty much any buffer that is fast enough to handle a 16mhz signal and can accept 3.3v as a supply voltage which the 74HC245 can. ... Only the clock signal needs to go though the buffer as that is an input and the sd card if you are using it. From twi just disable internal pullup resistors and have them to 3.3v instead of 5v...

Hello, I'm trying too to get the ov7670 communicate with Arduino UNO.

I read this post a week ago, I bought some 74HC245 but I realized they are not fully bidirectional, you have to choose the direction using a pin. So they can't be used with SIO_D and SIO_C, as far as I know. As I'm reading this post again, I guess A5 and A4 pins, using the code supplied, will output 3.3V instead of 5V (assuming internal pullup is OFF). Am I right?

It said in the post it does not matter if they are bidirectional or not. Also you do not need a buffer for i2c if you disable the internal pull-up and make sure that you have the pull-up resistor to 3.3v.

Mr_Arduino, thank you for your response.
I managed to connect SIO_C and SIO_D, I also changed atmega fuses to get the CLKOUT at pin 8. Yet, I don't have extra RAM chip and right now the only thing I want to do is checking if the ov7670 is responding.

  • What's the simplest way to know? Let's say using and oscilloscope.
  • Is it possible to capture an image from the sensor right into the SD (without a RAM)?

Thank you again!

First verify that CLKOUT is correct connected to the buffer and the output from the buffer does not exceed 3.3v and is correctly connected to XCLK then verify that with an osciloscope (you should see a square wave) after that see if SIO_C and SIO_D work it may just be a quick burst but that is normal. Then see if you get a most square wave from PCLK there should be a very brief burst where PCLK stops every so often. This is because by default the ov7670 outputs unwanted dummy pixels that serve no good we don't want those dummy pixels. If PCLK never stops it may not be communicating properly but the part where it stops may be too fast to see I can not remember off the top of my head.

Thank you!

I'm doing better now. Yet it isn't working. I had a communication problem between Arduino and the sensor. Now that's working and I'm able to configure the sensor. I'm having a somewhat coherent reading. I read 512 bytes blocks from the sensor, but I get blocks of zeroes every two or three blocks.

I'm configuring a 3MHz PCLK but I guess it's too fast for arduino. What do you think?

I set the divider to 4 see this code wrReg(0x11,4);//using pre-scaler for divider Also what you can do to verify communication is increment the divider and wait awhile and increment again in a loop and see if the OUTPUT PCLK changes on an oscilopsoce. Also you MUST have this register

	wrReg(0x15,32);//pclk does not toggle on HBLANK COM10 vsync falling

That may another reason why you are getting invalid data. If you don't have it just use all registers from my sample code would be best.

Ok, I have been working and I see some advances now. Yet I'm not done.

I've incremented the prescaler and I realized there is a point (as I incremente PCLK frequency) where I start missing bytes. So I'm using the slower PCLK possible now. I have got a 23LC1024 chip and removed the SD card. My test program reads 50 lines of 640 from the sensor and puts the in the chip. Then dumps it in base64 to the PC through the USB. I'm setting the sensor to output a color bar pattern.

Here is my YUV output for that image's portion. And what I see when I convert it using ffmpeg

$ ./ffmpeg -f rawvideo -s 640*50 -pix_fmt yuvj422p -i frame0.yuv -f image2 -vcodec png img.png

I think I may be getting valid data from the sensor, and my problem could be in the ffmpeg conversion. But I'm not sure how to check that.

img.png

FRAME0.YUV (62.5 KB)

Good job the only thing is that you have the sensor configured for raw bayer data. I attached the image I got.
Here is the source code to the program that converts the image it does both yuv422 and raw bayer data and saves it to a png file. RawCamera-data-converter/main.c at master · ComputerNerd/RawCamera-data-converter · GitHub
To compile it simply type

gcc -Wall -Wextra -lm -lpng -o yuv main.c

As you may have noticed you need libpng installed.
The only thing is that the file name must be called F(x).YUV replace (x) with a number this was because I made it for time lapses originally and need to may pictures at once. If you don't specify which number x is when running the program it will start from 0 and count up until a file is not found note that if you have F0.YUV and F2.YUV it will stop at F0.YUV as F1.YUV does not exist so in this case if you wanted to convert F2.YUV you would need to use the -n x argument so in this case do ./yuv -n 2 to convert it. Also speaking of missing a byte glitch I found out that sometimes at the beginning of capture a byte would be missed I fixed this by waiting for PCLK to go low read the pixel then wait for it to go high and then loop. I previously had it backwards.

frame 6.png

Wow... thank you.

I thought I was configuring the sensor for YUV output. After reading your reply I went to check that. I think I'm misreading the documentation or the document is wrong. Because I can't manage to change the output.

What I'm doing now:

  // Max prescaler divider
  ovcam.toggle(REG_CLKRC, NONE, CLKRC_PRESCALER_MASK & 31);
  ovcam.toggle(REG_DBLV, NONE, DBLV_PLL_BYPASS);

  // No PCLK during HBLANK
  ovcam.toggle(REG_COM10, NONE, COM10_PCLK_NO_TOGGLE);

  // Set up camera
  ovcam.write(REG_COM7, 0x00);  // YUV
  ovcam.write(REG_COM15, 0xC0);  // Set normal rgb with Full range
  
  ovcam.toggle(REG_ABLC1, NONE, ABLC_ENABLE); // Auto black level

  ovcam.write(REG_COM13, 0x88);
  ovcam.write(REG_TSLB, 0x05);

The problem is no matter what I put in COM7, COM13 and TSLB. I can't manage to change to YUV. I have a PDF dated "Version 1.3, April 5, 2006" but I see some registers do not act according to the configuration. Do you know where is the last document for this sensor?

Anyway, I guess I can live with RAW Bayer data by now.

What is the clock frequency you are sending to the module?
What is the max PCLK frequency you are able to read from Ardunino UNO or Mega?
Is you conversion program discarding color information? Or is it me doing something wrong?

By the way: I just noticed I had a byte in zero at the start. I fixed it waiting for the high state of the HREF signal, before starting to read the line. But then, as I change from bar pattern to the image, I start getting zeroes again. :confused:

Thank you very much!

Here is a picture taken in three stages of 640x100 pixels:

frame 0.png

Ok I think you were configuring the output for yuv however here is what I use for yuv also I am having the same problem with raw bayer data it lacks color. Yuv is much more colorful Here is what I use for yuv422. Also the documentation for the ov7670 is very bad don't blame yourself. Although here is a newer version 1.4 that may help abit http://www.haoyuelectronics.com/Attachment/OV7670%20+%20AL422B(FIFO)%20Camera%20Module(V2.0)/OV7670%20datasheet(V1.4).pdf
If you noticed in the changelog of the 1.4 from 1.3 they changed the TSLB and COM13 documentation.

	wrReg(0xb0,0x84);//Undocumented but writing this fixes colors I do not know why
	wrReg(REG_COM7, 0x00);           // YUV
	wrReg(REG_COM15, 0xC0);          //Full range
	wrReg(REG_TSLB,0x04);                // 0D = UYVY  04 = YUYV     
 	wrReg(REG_COM13,0xC8);               // connect to REG_TSLB

I keep getting the RAW data. I will keep trying tomorrow morning (it's 11:40PM here). Thank you again.

frame 0.png