CMOS camera interfacing

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