Hi drkblog, sorry if I'm too daring But I have seen that you also have great background with this project, maybe you could help me with my post above ?
Thank you !
aturcitu:
Hi drkblog, sorry if I'm too daring But I have seen that you also have great background with this project, maybe you could help me with my post above ?
No problem!
As far as I understand, you have successfully passed images from the sensor to RAM. You said you have enough RAM, which RAM are you talking about?
Then you tried to pass images to the PC (how?)
For storing the image to an SD card, you will have to start by having the entire frame in RAM because SD is slow (compared to the image sensor) and write speed in the card isn't constant. And you have to write blocks of 512 bytes, even if you don't use FAT file system. So, the best approach here is you start by creating a separated project for writing to the SD card. That's very easy, you have a lot of sample code out there. Once you have the SD module working, you can think of merging both projects: the one which passes images to RAM, and the one which writes to SD.
I've made two assumptions here so I will wait your answer before going further.
Tahnks!
Arduino DUE has 96 KBytes of SRAM.
Now I am working with QQVGA (160*120) that if I am not wrong would be more or les 40 Kbytes.
I tried with Processing through Serial port. But I fail.
And what about que image processing? SD libraries incloude the functions needed to convert this amount of bytes into a png/jpeg image?
Thanks Again! 
aturcitu:
Tahnks!Arduino DUE has 96 KBytes of SRAM.
Now I am working with QQVGA (160*120) that if I am not wrong would be more or les 40 Kbytes.
Yes, if you use two bytes per pixel.
I tried with Processing through Serial port. But I fail.
That can be tricky but it's possible if you are passing data from RAM to serial port. It won't work from OV7670 to serial port because it isn't fast enough.
And what about que image processing? SD libraries incloude the functions needed to convert this amount of bytes into a png/jpeg image?
I don't think SD library does JPEG encoding but you could find a proper library for that. Any way it would be better if you can delegate that task to another part of your project. Arduino processing power is limited.
Thanks Again!
No problem!
I don't think SD library does JPEG encoding but you could find a proper library for that. Any way it would be better if you can delegate that task to another part of your project. Arduino processing power is limited.
What do you mean? saving only the bytes as text and them process it on PC side? 
Great!
drkblog:
I don't think SD library does JPEG encoding but you could find a proper library for that. Any way it would be better if you can delegate that task to another part of your project. Arduino processing power is limited.
can you elaborate? I was using the SD library for another project(VC0706), but I've been thinking of trying the SdFat library, cuz as I understand it, you can save the time/date the file was written to the file, so it can be read by a computer. As soon as I get an RTC, I plan on trying to implement it.
By doing JPEG encoding, you mean taking it from the RAW Bayer and converting it to JPEG? Or am I missing something more on this?
aturcitu:
What do you mean? saving only the bytes as text and them process it on PC side?
No. Where do the text thing come from?
If you have a frame in RAM, all you have is a bunch of bytes (let say 160 x 120 x 2 bytes), a big block of 38,400 bytes. In whatever format the sensor can output (Bayer, bayer raw, RGB, etc). Then you can save this block on a SD card, as a file. It won't be a text file because you are not saving a block of text, but a block of bytes including values outside text range. Remember that the only thing that makes a file, a text file, is it contains ASCII printable character bytes. But this is only a conventional definition. Like the .TXT extension in Windows.
So, if you save that block to a file on the SD card, you get a binary file with the entire frame. Just like the file you posted before. You can then convert that file into JPEG or PNG or whatever format you need. But this new file is just another binary representation of the frame. Same thing, different format. Of course, a JPEG will use less space because it is usually compressed. But then you are loosing information at some point. And you have to spend some processing power for converting the raw binary frame from the sensor into a JPEG or PNG.
Now, having that in mind you can think if you really need to convert the frame into a JPEG file in the Arduino. Or you can do that afterwards over a PC:
Let's suppose you build an Arduino powered timelapse device which takes a picture every minute during all night (pointing to the sky). And save every picture to an SD card. There is no reason for converting the file into JPEG using the Arduino. You can do that on your PC the next day, running a batch process over the set of raw pictures you have.
xKoldFuzionx:
can you elaborate? I was using the SD library for another project(VC0706), but I've been thinking of trying the SdFat library, cuz as I understand it, you can save the time/date the file was written to the file, so it can be read by a computer. As soon as I get an RTC, I plan on trying to implement it.
I don't know the difference between them. SDFat library writes using FAT file system, obviously. Which is the format usually used for SD cards by a computer or digital camera. I guess both libraries allow for writing blocks on the SD card without following FAT specification. Which saves you some time, but then you have a non-standard SD format and you will have to build a special reader on the other end (where you put the SD card once it was written by the Arduino).
xKoldFuzionx:
By doing JPEG encoding, you mean taking it from the RAW Bayer and converting it to JPEG? Or am I missing something more on this?
Of course, JPEG encoding is exactly that.
Thank you, appreciate that info.
As for the two libraries, all I know is that SD was written(simplified) from SdFat. But one thing I've noticed is that it's over-simplified(great to learn with, but limits your options). I just wasn't sure if I was reading something into that about the library itself being able to convert the image to JPEG while being saved to the SdCard.
Total newb, just been watching this for some time. I have an OV7670(non-FIFO) I haven't even touched yet. I've mainly been fooling around with the VC0706 module, getting the hang of things, especially writing code. I purchased an OV5642 and am waiting for it to arrive. I haven't experimented much with the electronics side as of yet, so hooking everything up confuses me. But, I'm looking forward to playing around with one of them soon.
A properly written SD card library should do something like encoding JPEG. Of course, it is up to the guys who write the library. But for the sake of proper order, JPEG encoding should be in a JPEG library
Working with these sensors is hard even for someone with knowledge about electronics. It doesn't mean you won't make it, but it isn't going to be easy.
One good recommendation is to split the problem into parts which you can build and test by its own. Once you have parts working, you try to integrate them.
drkblog:
A properly written SD card library should do something like encoding JPEG. Of course, it is up to the guys who write the library. But for the sake of proper order, JPEG encoding should be in a JPEG library
That's good to know. So essentially, since the OV7670/OV5642 family mostly does RAW, YUV, etc, I should be able to find a library that will convert them to JPEG? Which brings me to my next question, compression. Less compression provides better quality JPEG images? So, like on the VC0706 I can set the compression ratio from 0-255(00 - FF, in HEX), so a setting of 0 would be no compression and a higher quality pic, where as FF would be a lower quality due to compression causing some loss in data?
Working with these sensors is hard even for someone with knowledge about electronics. It doesn't mean you won't make it, but it isn't going to be easy.
well, I've learned in 34 years of living that nothing worthwhile comes easy. I decided about 6 months ago I wanted to build my own Trail Cameras cuz I'm tired of the ones I've purchased. With the VC0706, I've got one working(minus a few components and a desperate need for some power saving routines). It hasn't been easy, but it's been an adventure.
One good recommendation is to split the problem into parts which you can build and test by its own. Once you have parts working, you try to integrate them.
Exactly what I've been doing with this other module. I started with the camera, sending data, receiving, etc. Then have been integrating other components once I'm happy tweaking the existing. For example, right now, I'm working on a menu system with a 16x2 LCD screen(small, challenging, but it's all I have at the moment). I fail, then get back on the horse and keep on trying, when that fails, I try something else.
xKoldFuzionx:
drkblog:
A properly written SD card library shouldn't do something like encoding JPEG.That's good to know. So essentially, since the OV7670/OV5642 family mostly does RAW, YUV, etc, I should be able to find a library that will convert them to JPEG? Which brings me to my next question, compression. Less compression provides better quality JPEG images? So, like on the VC0706 I can set the compression ratio from 0-255(00 - FF, in HEX), so a setting of 0 would be no compression and a higher quality pic, where as FF would be a lower quality due to compression causing some loss in data?
I fixed my previous answer: usually it's better to have one library for one purpose (like writing SD cards) and adding functionality outside it's main purpose is a bad idea. So I don't think SD libraries do JPEG encoding.
Less compression leads to better quality, but I'm not sure if you can have no-compression at all when encoding JPEG. There is a difference between compression (using less space/bandwidth at the cost of loosing some data) and data compaction (using less space/bandwidth without loosing data). If you don't want to loose any data, JPEG won't be of much help as you will end up with a bigger file than your RAW frame file. As JPEG has to introduce a header, and then represent all your data in the file. In the other hand, your RAW frame has no header information. You can interpret the file because you know beforehand it's a frame of a given resolution and format. If you send the file to someone else, you have to inform that too. The JPEG format (as every know image format) has a header for that.
xKoldFuzionx:
well, I've learned in 34 years of Exactly what I've been doing with this other module. I started with the camera, sending data, receiving, etc. Then have been integrating other components once I'm happy tweaking the existing. For example, right now, I'm working on a menu system with a 16x2 LCD screen(small, challenging, but it's all I have at the moment). I fail, then get back on the horse and keep on trying, when that fails, I try something else.
That's how electronics works, even for engineers when the project is challenging.
Lmao, glad you fixed that. I'd have been pissed when I couldn't figure out how to compress JPEG with SdFat. Lol.
As for compression, thanks for explaining that. For now, JPEG is just easier. That's why I ordered the OV5642 cuz it can do JPEG.
And good to know that everyone struggles with tough jobs, ensures I have my work cut out for me.
xKoldFuzionx:
Lmao, glad you fixed that. I'd have been pissed when I couldn't figure out how to compress JPEG with SdFat. Lol.
Big typo.
xKoldFuzionx:
As for compression, thanks for explaining that. For now, JPEG is just easier. That's why I ordered the OV5642 cuz it can do JPEG.
Well. Having a sensor which outputs JPEG saves you the cost of processing the encoding. But, as far as I know, you won't get a frame free of compression from such a sensor. And if you have to process the image in the Arduino, you have to decode JPEG first. Which is why OV7670 is better in such cases.
In the end, you have to use the right sensor according to your project. If you just want to save a JPEG image to SD for using over a computer later, using a JPEG-enabled sensor makes sense. Because you save space and time.
I didn't say this before: I don't think you will find a JPEG library for Arduino. As it isn't intended for such job. Encoding/decoding JPEG needs a lot of RAM. You have to keep in mind the Arduino isn't a computer. Of course, we take Arduino to its limits all the time. That's the idea. But you have to keep one foot on the earth. And think about the project as a whole.
Hello, I've been trying to get this to work the past few days. I have an Arduino Uno, the camera module (I'm thinking without fifo, it has 18 pins) and a bunch of cables. At this point I just want to send a single image from the camera over serial, nothing special with sd cards or such (I don't have the right stuff for it anyway). I've been reading trough this thread and other parts of the internet to get it to work but I haven't made any progress so far.
Specifically I'm asking for this:
-A schematic (or description of one) of which pins I need to connect with what. I've seen the one on the first page (reply 2), but I think it's outdated, since it doesn't use the PWM as clock.
-The basic code to communicate with the camera. So if I type something in the serial box of the arduino IDE, it sends it to the camera and then sends back the camera's reply.
-Some code to properly receive the data the camera sends back with the d0-7 pins.
I've seen the huge lists of registers, I don't think they're needed in the code itself if I use serial to operate the camera?
So far I'm thinking this:
The schematic, is this ok? http://i167.photobucket.com/albums/u157/cookiebal/OV7670ArduinoUno.jpg
As for the code, I've been looking at ov7670 arduino uno example code - Pastebin.com , I'm not very familiar with the language so I don't really understand everything. But so far I'm thinking that I'd need to add this (from page 4, reply 57) somewhere at the start to get the clock working.
DDRB|=(1<<3);//pin 11
ASSR &= ~(_BV(EXCLK) | _BV(AS2));
TCCR2A=(1<<COM2A0)|(1<<WGM21)|(1<<WGM20);//this also results in 67 but I wanted to clean up magic numbers
TCCR2B=(1<<WGM22)|(1<<CS20);
OCR2A=0;
Then there are a whole bunch of writes to registers or something in a bunch of if statements, I suppose that's the settings?
Then the loop, it's difficult to read because of the #if stuff, but I think I should just ignore everything between #else and #endif? And then edit out all the SD related stuff and write to serial instead of the SD card?
Another problem is that I can't see where it gets the data from the D7-0 pins. I'd guess somewhere in captureImg but I don't really understand what's going on there, except a bunch of looping. Does it write directly to the memory or something? Either way, I think I need to get the values of the pins connected to D7-0 and store it somewhere every time HREF changes? I've read it somewhere but the pin connection in the second post in this thread doesn't mention it.
I guess it's more efficient the way this is written, but it's not helping me much 
For the communication I'm trying to use Wire like in the wrReg function in ov7670 arduino uno example code - Pastebin.com but I'm not getting any responses, so I guess I did it wrong.
I'm using this to read:
Wire.requestFrom(0x42, 6);
while(Wire.available()) {
char c = Wire.read();
Serial.print(c);
}
Will this work for getting the image data from d0-7?
while (digitalRead(HREF) == 1){
while(digitalRead(PCLK) == 1){}
for (int i=0; i < = 7; i++){
//get stuff from each parallel data pin
}
My apologies if I've been asking stuff that's already answered. Because of all the different things (uno/mega, fifo, and such) it's been hard to figure out what is relevant.
First of all: If you want to make it work, you have to know whether you have a FIFO or non-FIFO module. Basically the FIFO module has a AL422B chip in the back of the module. In the other hand, no matter which module you have, there is no way of passing a frame from the module to the serial port without storing the entire frame in Arduino's RAM.
As you guessed the schematic and code needed for both cases is already posted here. So I think that a good reason for not reposting. The explanation about the impossibility of passing a frame without enough RAM is already posted too.
The schematic you posted is ok (as far as I can see) for a non-FIFO version. But the code you are referring uses a SPI RAM chip for storing 1/5 of a frame at a time while it's saved to the SD card. That means your scene has to be steady if you want good picture.
The code which starts with "DDRB|=(1<<3)" should be in the setup() function. That will output a clock at pin 11 (according to the comment) which you are connecting to XCLK (which is ok). You have to source a clock to this module to make it alive. Then you HAVE to pass ALL those registers if you want to get an image from the sensor.
If you can't get a response from the sensor (like reading the value of a register) don't try to go further. You have to be able to communicate with the sensor first. Most common reason for this to fail is a bad or non-existing XCLK. If you have a oscilloscope you can check Arduino pin 11 to see that you have there. If you don't have one, you are pretty much in trouble. You have to be sure the code you are merging doesn't conflict on that pin. I mean, if there is another configuration over pin 11 in the code, that could be a cause for the problem.
Hi everybody, today I have recived my fifo version. It has supposed to be an v2 but it's not.
I have the new v3 version but I can't find relevant information about this version, Does anybody know if it has any important different I would have to take into account?
Anyway, I also would like to ask if somebody could help me undesrtanding with three lines of explanation what is the fifo funcionality like. Only explaining the differences with the non-fifo version regarding the data capturing.
Thanks, I love your project
aturcitu:
I have the new v3 version but I can't find relevant information about this version, Does anybody know if it has any important different I would have to take into account?
Ask the seller for a datasheet. Do you have a link to the product on ebay or something?
aturcitu:
Anyway, I also would like to ask if somebody could help me undesrtanding with three lines of explanation what is the fifo funcionality like. Only explaining the differences with the non-fifo version regarding the data capturing.
FIFO First In First Out is a special kind of RAM memory. In this case you have a chip which can store up to one frame of 640x480x1 bytes. The chip has two interfaces input and output. Input is connected to the datalines of the OV7670 so all you have to do is to reset the FIFO write pointer and trigger write enable line when the signaling of the sensor tells you a new frame has started. And then disable FIFO's write line when the frame has ended. You do that by reading VSYNC signal.
At this point you have a frame saved into the FIFO memory as long as you don't enable write again and you don't turn the module off. You have to read the frame using FIFO's output interface which is exposed to you. You have to provide a reading clock of at least 1MHz and (at least for the modules I know) you have to read the entire frame at once. You can't do it at parts as I explained before in this thread.
Excellent explanation, this weekend I will work it out!
The camera module is
http://www.ebay.es/itm/180946265217?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
In the photos is the v2.. I will contact with the seller! I have feed the camera and checked vsync and href are working!
Thanks
EDIT: In the clk I have to use to read the data what it is the best way to generated?
With pwm and creating some interrups? Can I create interrupts with output signals? or I would have to reconected to an input?
Or maybe : (put pin up, read, put pin down... ) I suppose the first one..haha