CMOS camera issue
rjo__
Posts: 2,114
Howdy,
I have been working on a simple, general purpose camera driver. In the process, I have been working with the OV2640 and the OV7670 from Omnivision, photos and drivers attached(hopefully:)
Because of bandwidth limitations, I am currently limited to about 1M pixels per second. While both sensors work about the same, because of resolution differences, the net result is that I can acquire 20 images (9600 pixels) per second from the OV7670 and 1 (48x500) image per second from the OV2640.
The bandwidth limitation has to do with the cog limits of 20Mhz and instructions that take multiple clock cycles to execute.
A better solution seems to me to use the pixel clock, which comes from the camera to strobe parallel SRAM chips, which accept the data in sequential mode, so that the data is continuously fed to the SRAM chips.
The problem I am having is that I would like the pixel clock to strobe the SRAM during sequential data input but not during the programming phase for the SRAM chips. I have tried using a combination of PNP and NPN transistors(and just a NPN transistor), with output from a Propeller pin to select when the clock gets transmitted, but with no luck. When I count the clocks, I get more than I know is actually present so noise seems to be the issue. I have tied the lines to ground with a range of resistors which does decrease the problem, but not eliminate it.
Any ideas?
Rich
I have been working on a simple, general purpose camera driver. In the process, I have been working with the OV2640 and the OV7670 from Omnivision, photos and drivers attached(hopefully:)
Because of bandwidth limitations, I am currently limited to about 1M pixels per second. While both sensors work about the same, because of resolution differences, the net result is that I can acquire 20 images (9600 pixels) per second from the OV7670 and 1 (48x500) image per second from the OV2640.
The bandwidth limitation has to do with the cog limits of 20Mhz and instructions that take multiple clock cycles to execute.
A better solution seems to me to use the pixel clock, which comes from the camera to strobe parallel SRAM chips, which accept the data in sequential mode, so that the data is continuously fed to the SRAM chips.
The problem I am having is that I would like the pixel clock to strobe the SRAM during sequential data input but not during the programming phase for the SRAM chips. I have tried using a combination of PNP and NPN transistors(and just a NPN transistor), with output from a Propeller pin to select when the clock gets transmitted, but with no luck. When I count the clocks, I get more than I know is actually present so noise seems to be the issue. I have tied the lines to ground with a range of resistors which does decrease the problem, but not eliminate it.
Any ideas?
Rich
Comments
Its for the OV9965 - but it should give you an idea of how to do 128x96 grey scale at 30 FPS. If you want to do 160x120 full color image segmentation and stuff take a look at the full CMUcam4 source code which will be easier to understand if you have read the link I posted. The CMUcam4 full source code is here: http://cmucam.org/attachments/download/668/!CMUcam4_Firmware_Code_102.zip
Each cog can handle about 120x60 pixels in my code for the CMUcam4. Stripping out functionality might boost that to 320x80 or 320x120. But, I'd say 120x60 is the best you'll get per cog. Then you can interleave multiple cogs to get up to 320x120 or 640x60 with 4 cogs.
Note I use a 6 MHz crystal. You should do this too.
---
If you want a really easy solution buy a fifo buffer to save all the data from a camera in one frame. Fifo buffers for large resolutions don't really exist however. Most of the big fifo buffers are made for seriously high speed data rate telecommunications stuff and can cost like $500 for a single chip. See the CMUcam3 and CMUcam2 for examples of this.
You will notice that my i2c code was directly ripped from your code. When I eventually post this stuff formally, I will correctly attribute your code as well as that of others:)
I wanted something that was simple, in a single cog and with a 5MHz crystal so that people could add a camera to their projects for about the cost of the camera. The pictures were taken from an unmodified Propeller activity board, with the same breadboard configuration for both cameras. The OV7670 is a little flakey… I think because it needs 3V and not the 3.3V I am feeding it. The OV2640 is very happy with the setup.
Resolution is what it is. In this case, in this application, there is enough room in Hub Ram to double buffer the OV7670 images…So that one could easily compute changes and do more extensive image processing (such as edge detection/line following) in close to real time…all for about $8.
The OV7670 is available in a configuration with a small FIFO. What I am trying to do is to use available SRAM boards such as two of the Parallax Memory Cards http://www.parallax.com/product/40004as a general purpose "FIFO" that has random access, is large enough and fast enough to store images from an OV5642(5M). The last time I looked at this, I gothttp://www.rayslogic.com a couple of SRAM boards from Rayslogic. What I would like to do is to use the Propeller to put the parallel SRAM chips into sequential write mode and then use the camera's pixel clock(clock out) to clock the data directly into the SRAM at full speed (up to about 10Mhz)… with the camera's data out lines directly hooked to the SRAM's data in lines
My first problem is that the camera outputs the pixel clocks automatically… so, I need to add a piece of hardware that only let's the pixel clock signal reach the SRAM when I intend it to.
Any help would be appreciated.
Thanks
Rich
What makes physically interrupting the pixel clock reasonable is that the pixel clock can be configured in software to only output valid pixels… technically speaking, this means that the pixel clock can be made to output only when HREF is high. One can then monitor the VSync line and wait to start recording on the next HREF(or next pixel clock:).
It should work:) But what do I put between the pixel clock and the SRAM clock to give me control?
Rich
There should be enough time to clock the data into SRAM if you instead of putting the data into RAM. The driver will allow you to at least get a clean image.
You can't stop the camera from running too. If you need to stop the data coming out use an AND gate controlling the WR signal for the SRAM.
Thanks. Much of what you say is true, but I think we are talking passed each other. One way or another, if the Prop parses the various signals, gets the data and then writes data to the SRAM, Prop resources are going to be used and will eventually limit what can be done. What I am trying to do would at most tie up 14 pins, leaving pins and cogs open for other purposes. I see no reason why the full resolution of the sensors mentioned above cannot be obtained in the way I am describing.
I am not messing with the camera registers, they are all set according to the documentation and seem to work just fine. Admittedly, the 2MHz xclk signal from the Prop to the OV2460 is way below what is described in the Omnivision's documentation, but it does work.
The nice thing about the OV7670 is that there is plenty of hacker info available and it is cheap. Register settings for all of the cameras I have mentioned are available through the Arducam http://www.arducam.comproject.
What I am describing would be simpler and more functional than the Arducam and would be fully open:), which the Arducam is not.
Rich
Then I suggest a FIFO chip which you can get at digikey. The FIFO will allow you to save an image at 30 FPS with a 24 MHz clock in one go. However, only small affordable FIFOs exist. All the big ones are made for networking stuff and cost way too much... Actually, in general FIFOs cost way too much.... so scratch this. The CMUcam2 and CMUcam3 had terrible problems because of the FIFOs... the FIFOs fail when touched, cost like $20, and were too small. Yes, some FIFOs are very statically sensitive...
But... you can build a FIFO from a RAM chip and some other digital logic components. Get a counter, some logic gates, etc.
I was looking into doing this for someone else recently and I determined it would be a PITA, but, possible. If you have the time and money to spend on board revs then go for it.
Work out a digital logic design and I'll look over it to see if it might work. You'll want to spec all the parts to be able to run at 24 MHz to 48 MHz.
purposes. Wonder how fast a FIFO a Prop would make?
Hi Kye, do you think I could use OV7670 with the ActivityBot? I mean, it's C just like Arduino and can use all the C libraries (I thought about OpenCV). I would like to send images to my PC using the XBee module in it. The robot and the Xbee are working fine, but I'm still searching about the camera. I don't mind low frame rates as long I can see small objects and move them with the gripper. Do you know something that could give a hand on that? Thank you!