On 10/18/2011 02:08 PM, ampd 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.
> 

It's a late reply, but one quite powerful and cheap solution is the SRV1
cam from www.suveyor.com.
For the more advanced uClinux featured designs, you might want to check
www.section5.ch/vkit

Cheers,

- Strubi

On Oct 28, 1:41=A0pm, Steve B <sbatta...@gmail.com> wrote:
> On 10/28/2011 09:20 PM, linnix wrote:
>
> > I use a PIC24/26/32 (still upgrading) and a 3MP Android. =A0Android
> > compress it to jpeg for me, so I just have to move it to my own flash/
> > disk.
>
> I meant to ask what the OP's goal was.. if you have an Android device,
> what's the point of PIC anything anyway actually?

External I/Os and A2Ds.

On 10/28/2011 09:20 PM, linnix wrote:

> I use a PIC24/26/32 (still upgrading) and a 3MP Android.  Android
> compress it to jpeg for me, so I just have to move it to my own flash/
> disk.
>
I meant to ask what the OP's goal was.. if you have an Android device, 
what's the point of PIC anything anyway actually?

>>
>> Anyway, the cypress FX-2 combined with an Aptina MT9V032 sensor would
>> work like a charm. You get 720x480 pixels
>
> Why so small with 5MP camera?

Sorry, the MT9V032 is different from the 5MP sensor. I was just saying 
that I have managed to make it work on the 5MP sensor which transfers 
the data continuously on its own timing.
It would have been easier with the MT9V032 where you can throttle the 
data stream coming out of the sensor, to match your max storage rate as 
long as you can take one full line without data dropout. This is the 
case because that sensor has the global shutter feature, which is not 
common in CMOS cameras.

Steve

On Oct 28, 11:07=A0am, Steve B <sbatta...@gmail.com> wrote:
> Hello, all. This thread caught my eye, as I have been working quite a
> bit with camera interfaces.
>
> What is the final goal, do you simply want to get an image from the CMOS
> camera to PC? In that case, I have some nice tips for you.
>
> I have rigged up a Cypress FX-2 EZ-USB microcontroller to do exactly
> this, though with a much larger 5MP camera.http://computer-nerding.blogsp=
ot.com/2011/05/image-acquisition-with-c...
>

I use a PIC24/26/32 (still upgrading) and a 3MP Android.  Android
compress it to jpeg for me, so I just have to move it to my own flash/
disk.

>
> Anyway, the cypress FX-2 combined with an Aptina MT9V032 sensor would
> work like a charm. You get 720x480 pixels

Why so small with 5MP camera?

>  (wide VGA I guess?), a global
> shutter, and the sensor has a sort of "slave mode" which spits out the
> data one line at a time on your command.

Only if the sensor has a few hundred kilo byes of buffer.  Otherwise,
you will have problem with sharpness on motions.

Hello, all. This thread caught my eye, as I have been working quite a 
bit with camera interfaces.

What is the final goal, do you simply want to get an image from the CMOS 
camera to PC? In that case, I have some nice tips for you.

I have rigged up a Cypress FX-2 EZ-USB microcontroller to do exactly 
this, though with a much larger 5MP camera.
http://computer-nerding.blogspot.com/2011/05/image-acquisition-with-cypress-fx-2-usb.html

Unfortunately, I am now having some frame synchronization issues that I 
thought I had fixed before... but as long as the host PC side can keep 
up with the camera's data rate, it should basically work. The safest 
way, though, is to have enough memory and the right hardware (FPGA or 
CPU with camera interface) to fully buffer the image before processing 
or forwarding.

Anyway, the cypress FX-2 combined with an Aptina MT9V032 sensor would 
work like a charm. You get 720x480 pixels (wide VGA I guess?), a global 
shutter, and the sensor has a sort of "slave mode" which spits out the 
data one line at a time on your command.
It still comes out in sequence on the pixel clock, so if you want a CPU 
where you can process it on board and not just forward over USB, you 
would need a FIFO or some DMA or something to catch the data at that speed.
But, in theory, this chip would make it pretty easy to take a frame and 
process or relay the data to a PC at your leisure. With an FTDI Chip 
FT245RL chip, you can probably get better than 1 frame per second 
transfer rate (transfer only, no processing of course!). With high-speed 
USB you can probably achieve full frame rates if you write good 
receiving end software!

Hope that helps!

Steve

In article <MPG.2907953575f175f7989869@news.eternal-september.org>, 
mborgerson@comcast.net says...
> 
> 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
> 

I looked around a bit and found that the CMUCAM2 actually uses
an AL422B FIFO chip.   I must have confused that system
with some other hobby robotics system that used the 
pixel-skipping method.

Mark Borgerson

On Oct 18, 2:21=A0pm, "ampd" <handsonceheld@n_o_s_p_a_m.gmail.com>
wrote:
> >On Oct 18, 9:34=3DA0am, "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 alway=
s
> >> enjoyed electronics projects and hopefully with this one I'll learn ho=
w
> t=3D
> >o
> >> deal with them.
>
> >> CMUcam looks interesting. I'll take a look at that and try to get a
> bette=3D
> >r
> >> understanding of how it works.
>
> >> I'm also really interested in this FIFO buffer, but am not exactly sur=
e
> o=3D
> >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. =A0They buffer 15 frames of 100,000
> >bytes each. =A0OV9655 is 1000x800x10. =A0You need 1M bytes per frame. =
=A0The
> >uC does jpeg encoding. =A0OV9655 output the pixel clock at around 120M
> >bits per second.
>
> >> I've also never worked with external sdram or dma. Does the mcu need t=
o
> >> deal with the memory addressing? =3DA0 =3DA0 =3DA0 =3DA0 =3DA0
>
> >Yes.
>
> So if I were to use the OC9655, AL422B, and

This is not good enough,
PIC24HJ32GP302 - 16 bits, 40 mips, 32K flash, 4K sram

4K is not enough to do even one line of jpeg encoding.

I suggest
PIC32MX575F512H - 32 bits, 120 mips, 512K flash, 64K sram.

You will need some of the sram for program space, since running from
flash is slow.

You will need 32 bits for jpeg encoding.

> 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, enco=
de
> to jpeg, and write to sd however fast it wanted to?

Yes, if your FIFO buffer is big enough.

>Or would I take the output of the FIFO and write it to sdram in the mcu? =
=A0 =A0 =A0

There is no sdram in the mcu.

>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

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, 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/