Forums

CMOS camera interfacing

Started by ampd October 18, 2011
Hi,

I've been wanting to start a project to build a small camera. I'm looking
to take a cmos camera (most likely 1.3mp such as omnivision 9655) and take
a still image and store on a sd card. Speed isn't really a concern, but I
wasn't sure what the best way to deal with the amount of data being sent
out by the cmos camera. 

I'd like to keep the cost and complexity as low as possible.

Would something like the xilinx spartan 3e be overkill? I've never worked
with a fpga before and would like to avoid it for this if possible. 

Would something like a S1D13774, with a camera interface be a better
choice?

Or would something like a PIC32 be able to deal with everything, given that
speed isn't really a priority. Would I need to use some external sd ram?

Thanks for your help.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com
On Tue, 18 Oct 2011 07:08:47 -0500, "ampd"
<handsonceheld@n_o_s_p_a_m.gmail.com> wrote:

>Hi, > >I've been wanting to start a project to build a small camera. I'm looking >to take a cmos camera (most likely 1.3mp such as omnivision 9655) and take >a still image and store on a sd card. Speed isn't really a concern, but I >wasn't sure what the best way to deal with the amount of data being sent >out by the cmos camera. > >I'd like to keep the cost and complexity as low as possible. > >Would something like the xilinx spartan 3e be overkill? I've never worked >with a fpga before and would like to avoid it for this if possible. > >Would something like a S1D13774, with a camera interface be a better >choice? > >Or would something like a PIC32 be able to deal with everything, given that >speed isn't really a priority. Would I need to use some external sd ram?
Much depends on just how low-level you want to go with this. A popular option is the C329 module from Electronics123. The CMOS sensor is mounted with interface and support electronics, including a JPEG engine, so all you need to do is command the picture and then pull the resulting jpg image. http://www.electronics123.com/s.nl/it.A/id.3010/.f Another possibility, same folks, the Y201-TTL module, also JPEG: http://www.electronics123.com/s.nl/it.A/id.3247/.f -- Rich Webb Norfolk, VA
In article <9aCdnd6Fw__S8QDTnZ2dnUVZ_u2dnZ2d@giganews.com>, 
handsonceheld@n_o_s_p_a_m.gmail.com says...
> > Hi, > > I've been wanting to start a project to build a small camera. I'm looking
It must be university project start time or late starters.
> to take a cmos camera (most likely 1.3mp such as omnivision 9655) and
take
> a still image and store on a sd card. Speed isn't really a concern, but I > wasn't sure what the best way to deal with the amount of data being sent > out by the cmos camera. > > I'd like to keep the cost and complexity as low as possible. > > Would something like the xilinx spartan 3e be overkill? I've never worked > with a fpga before and would like to avoid it for this if possible. > > Would something like a S1D13774, with a camera interface be a better > choice? > > Or would something like a PIC32 be able to deal with everything, given that > speed isn't really a priority. Would I need to use some external sd ram? > > Thanks for your help.
Go ask you lecturer/prof/mentor about data flows and work out what data you have and how quickly you are to have to deal with it. Classic case of cart before the horse. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
In article <9aCdnd6Fw__S8QDTnZ2dnUVZ_u2dnZ2d@giganews.com>, 
handsonceheld@n_o_s_p_a_m.gmail.com says...
> > Hi, > > I've been wanting to start a project to build a small camera. I'm looking > to take a cmos camera (most likely 1.3mp such as omnivision 9655) and take > a still image and store on a sd card. Speed isn't really a concern, but I > wasn't sure what the best way to deal with the amount of data being sent > out by the cmos camera. > > I'd like to keep the cost and complexity as low as possible. > > Would something like the xilinx spartan 3e be overkill? I've never worked > with a fpga before and would like to avoid it for this if possible. > > Would something like a S1D13774, with a camera interface be a better > choice? > > Or would something like a PIC32 be able to deal with everything, given that > speed isn't really a priority. Would I need to use some external sd ram? > > Thanks for your help. > >
I've worked with two different approaches to acquiring CMOS camera data: The first is to use a FIFO buffer (AL422B, I think) between the camera and the MPU. The FIFO accepts the data at the ~24MBytes/second rate of the camera and makes it available for the camera at a rate the MPU can handle. ST has some dev kits that use this approach and include the camera. The second method is to use a processor, such as the STM32F207, that has a built-in camera peripheral. The peripheral port accepts the camera data and puts it in system memory (Either the onboard 128K RAM or external SRAM) using DMA. A third method, that I've not used, is to read the pixels with a parallel port, skipping pixels as required by the CPU clock speed. This means that it takes several frames to accumulate a single image. This method is used by many hobby robotics imaging systems. The CMU cam is a good starting point for this approach: http://www.cs.cmu.edu/~cmucam/home.html You might also consider one of the small linux modules like the Gumstix. They have hardware camera interfaces and lots of CPU speed and RAM. You'd better be comfortable with embedded Linux, though. Which ever hardware you choose, you will eventually find that data on how to set up the camera is not easy to get. Omnivision requires NDAs and sometimes won't answer support emails even with an NDA. The publicly-available information is skimpy, confusing, and hard to find. It's probably easier to get support if your email ends in @apple.com! ;-) Mark Borgerson
On Oct 18, 5:08=A0am, "ampd" <handsonceheld@n_o_s_p_a_m.gmail.com>
wrote:
> Hi, > > I've been wanting to start a project to build a small camera. I'm looking > to take a cmos camera (most likely 1.3mp such as omnivision 9655)
You know that the chip is a 5 x 6 CSP (Chip Scale Packaging), right?
> and take > a still image and store on a sd card. Speed isn't really a concern, but I > wasn't sure what the best way to deal with the amount of data being sent > out by the cmos camera. > > ... > Or would something like a PIC32 be able to deal with everything,
Yes, if you run it at 200MHz and actively cool it. We got it to 96MHz and the chip is warm. You will need heat sink and fan beyond. Someone got it at 160MHz.
> given that speed isn't really a priority.
Why not? You have to clock one row at a time and jpeg compress it before the next row.
> Would I need to use some external sd ram?
That would help.
On 10/18/2011 8:08 AM, ampd wrote:
> I've been wanting to start a project to build a small camera. I'm looking > to take a cmos camera (most likely 1.3mp such as omnivision 9655) and take > a still image and store on a sd card. Speed isn't really a concern, but I > wasn't sure what the best way to deal with the amount of data being sent > out by the cmos camera. > > I'd like to keep the cost and complexity as low as possible. > > Would something like the xilinx spartan 3e be overkill? I've never worked > with a fpga before and would like to avoid it for this if possible. > > Would something like a S1D13774, with a camera interface be a better choice? > Or would something like a PIC32 be able to deal with everything, given that > speed isn't really a priority. Would I need to use some external sd ram? > Thanks for your help.
You might be interested in reviewing the CMUcam architecture http://www.cmucam.org/wiki/Hardware
I'm actually a mech. engineer a few years out of uni, So my actualy ee
classes stopped before ever having to deal with data flows. I've always
enjoyed electronics projects and hopefully with this one I'll learn how to
deal with them.

CMUcam looks interesting. I'll take a look at that and try to get a better
understanding of how it works. 

I'm also really interested in this FIFO buffer, but am not exactly sure of
the implementation. Would it go camera > fifo > jpeg encoder > sd card?
Then a mcu would control it? What provides the clock signals?

I've also never worked with external sdram or dma. Does the mcu need to
deal with the memory addressing?	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com
On Oct 18, 6:40=A0pm, Anony Mous <anony.mous...@yahoo.com> wrote:
> ..... > > You might be interested in reviewing the CMUcam architecture > http://www.cmucam.org/wiki/Hardware
Thanks for posting this - nice to have the info. It strikes me that those parts listed on the wiki page - where the datasheets of the two camera chips are to be found - have gone missing from all distributors. Probably after the datasheets leaked? Amazing what an effort the party members put nowadays into staying in the dark. For a good and obvious reason, the really amazing (and troubling...) part is that they are centrally organized enough to manage it. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
On Oct 18, 9:34=A0am, "ampd" <handsonceheld@n_o_s_p_a_m.gmail.com>
wrote:
> I'm actually a mech. engineer a few years out of uni, So my actualy ee > classes stopped before ever having to deal with data flows. I've always > enjoyed electronics projects and hopefully with this one I'll learn how t=
o
> deal with them. > > CMUcam looks interesting. I'll take a look at that and try to get a bette=
r
> understanding of how it works. > > I'm also really interested in this FIFO buffer, but am not exactly sure o=
f
> the implementation. Would it go camera > fifo > jpeg encoder > sd card? > Then a mcu would control it? What provides the clock signals?
The CMU sensor is around 300x300x8. They buffer 15 frames of 100,000 bytes each. OV9655 is 1000x800x10. You need 1M bytes per frame. The uC does jpeg encoding. OV9655 output the pixel clock at around 120M bits per second.
> > I've also never worked with external sdram or dma. Does the mcu need to > deal with the memory addressing? =A0 =A0 =A0 =A0 =A0
Yes.
>On Oct 18, 9:34=A0am, "ampd" <handsonceheld@n_o_s_p_a_m.gmail.com> >wrote: >> I'm actually a mech. engineer a few years out of uni, So my actualy ee >> classes stopped before ever having to deal with data flows. I've always >> enjoyed electronics projects and hopefully with this one I'll learn how
t=
>o >> deal with them. >> >> CMUcam looks interesting. I'll take a look at that and try to get a
bette=
>r >> understanding of how it works. >> >> I'm also really interested in this FIFO buffer, but am not exactly sure
o=
>f >> the implementation. Would it go camera > fifo > jpeg encoder > sd card? >> Then a mcu would control it? What provides the clock signals? > >The CMU sensor is around 300x300x8. They buffer 15 frames of 100,000 >bytes each. OV9655 is 1000x800x10. You need 1M bytes per frame. The >uC does jpeg encoding. OV9655 output the pixel clock at around 120M >bits per second. > >> >> I've also never worked with external sdram or dma. Does the mcu need to >> deal with the memory addressing? =A0 =A0 =A0 =A0 =A0 > >Yes. >
So if I were to use the OC9655, AL422B, and PIC24HJ32GP302, I'd have an external oscillator to clock the input from the camera, then use the mcu clock for the output. I'd take the ouput from the FIFO into the mcu, encode to jpeg, and write to sd however fast it wanted to? Or would I take the output of the FIFO and write it to sdram in the mcu? --------------------------------------- Posted through http://www.EmbeddedRelated.com