CMOS Camera still shots - SD storage - Design recommendations

Hi there, 

I am looking into doing a new design which requires taking periodic still
shot  pictures from a CMOS camera and storing them into SD memory. I am
looking into the feasiblity of this using a Microcontroller to do this. I
have used mainly PIC 16 bit products in the past. There may be a better
option available out there. I would like to get some feedback from some you
experienced designers to see if I can use a Micro for this job, if so which
one may be best suited. 

Some general design specs that I am trying to follow: 
- would like to use a 1meg pixel, or larger camera - may start with vga for
testing purposes 
- Small form factor! - I need to keep the processing interface as small as
possible. Therefore, I want to stay away from FPGAs
     - use of qfn-44/64 would be optimal - micro sd card. possible external
sram to hold the image data depending on the size of image? 

- low power.  I would like to use low power devices if possible pic24f 
     - I may need to use pic24h, dspic33 or pic32 or other for faster
processing. 

- Still frame  is all that is required at this point, but would like to
keep max FPS processing open for future capability 


My initial thinking of the main flow of processing is:  1. collect and
buffer pixel data is SRAM (speed of processing must keep up with the
camera) 2. format the pixel data to be stored on sd card(possible jpeg
compression - some cmos chips have built in compression) 3. interface the
sd card to export the picture data to computer (rs232/usb) 

I have found some general purpose cameras that I may begin doing some
testing on. 

http://www.sparkfun.com/commerce/product_info.php?products_id=637 

http://www.sparkfun.com/commerce/product_info.php?products_id=8668 

At this point I don't have plans to do any signal processing of the pixel
data, but this could be a later add-on to the project.  This being the case
a dspic33 may be optimal?  

So, any recommendations would be greatly appreciated. 

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Sep 14, 8:16=A0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
wrote:

> - would like to use a 1meg pixel, or larger camera - may start with vga f=
or
> testing purposes

Take a look at the camera interfaces before you get too deep down a
difficult path. CMOS sensor interfaces aren't exactly easy to use,
they have tight realtime requirements. Unfortunately they do NOT work
the way an embedded person would like them to work (i.e. no onboard
RAM buffer in the camera; you need to read the sensor data out in
realtime).

For this reason most designs use a dedicated special-purpose chip, or
an FPGA, or a very large micro with an on-chip DMA camera interface. I
believe the parallel port interface on some PIC micros can be used as
a camera interface without too much difficulty (it has DMA
capability).

> - Still frame =A0is all that is required at this point, but would like to
> keep max FPS processing open for future capability

You won't be doing motion video with anything less than a high-end 32-
bit processor with hardware CMOS sensor interface.

larwe expounded in
news:339321f6-6b25-4005-863c-0eeb1ce11864@q26g2000vbn.googlegroups.com: 

> On Sep 14, 8:16&#4294967295;am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
> wrote:
> 
>> - would like to use a 1meg pixel, or larger camera - may start with
>> vga f 
> or
>> testing purposes
> 
> Take a look at the camera interfaces before you get too deep down a
> difficult path. CMOS sensor interfaces aren't exactly easy to use,
> they have tight realtime requirements. Unfortunately they do NOT work
> the way an embedded person would like them to work (i.e. no onboard
> RAM buffer in the camera; you need to read the sensor data out in
> realtime).

RAM is definitely going to push you into larger MCUs, unless you]
plan ahead very frugally. Combine the buffering of image data with 
the accessing of an SD memory card, and you'll definitely want 
to have some extra RAM to use for buffers.

If using a small MCU, you might need the use of SPI added
SRAM. But timing of the image transfer may make this impractical
(as noted above).

On the SD memory front, consider that any access to it is going to
require a minimum of one sector's worth of buffer (512 bytes).

To just store a "file" on the SD card, will require
file system software (I'll assume FAT16/32).  I know there is
a C version library on the net, but I have no experience with 
it (I wrote my own in Ada). You'll need to find out how many 
simultaneous instances of a sector buffer is used to create 
a new file and to write to it.

When a new file is created, the FS must minimally read and scan
the root directory, and allocate a new file directory
entry (if FAT32, this may mean adding a cluster to extend the
directory). Any time you must allocate a cluster, you must 
read/write the FAT table(s) (there can be multiple FATs, 
though this is user defined at format time).

Once the file is created and open, it has no clusters assigned.
So once you go to write to the file, you have one sector's
data worth sitting in a buffer. But the FS software must now
again read/update the FAT(s) to allocate a cluster to write
your data to. So this will need another sector buffer to
perform this. On a 1K SRAM MCU, you're pooched (you need 2 
sector buffers + extra SRAM for call stack and variables). 

Using a buffer shell game you can get around this however,
but this takes planning. I don't know if the C library
version goes to this level- You solve the issue by
having a free cluster on standby (keep track of the free
cluster number in a variable). Then your FS software
has some place to write your buffer to. It then can 
preallocate for the next file extension, should it be
needed.

As you can see, memory management is critical in the small.

Alternatively, you could just write the image data to
the SD card without a file system, since the images are 
fixed in size. Write them in groups of sectors.  But then 
you'll need custom software on the desktop side to extract
them out and put them into normal desktop "files". The 
custom software will have to read the device as raw
sectors (don't expect the desktop to know about the format).

Warren

>On Sep 14, 8:16=A0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
>wrote:
>
>> - would like to use a 1meg pixel, or larger camera - may start with vga
f=
>or
>> testing purposes
>
>Take a look at the camera interfaces before you get too deep down a
>difficult path. CMOS sensor interfaces aren't exactly easy to use,
>they have tight realtime requirements. Unfortunately they do NOT work
>the way an embedded person would like them to work (i.e. no onboard
>RAM buffer in the camera; you need to read the sensor data out in
>realtime).
>
>For this reason most designs use a dedicated special-purpose chip, or
>an FPGA, or a very large micro with an on-chip DMA camera interface. I
>believe the parallel port interface on some PIC micros can be used as
>a camera interface without too much difficulty (it has DMA
>capability).
>
>> - Still frame =A0is all that is required at this point, but would like
to
>> keep max FPS processing open for future capability
>
>You won't be doing motion video with anything less than a high-end 32-
>bit processor with hardware CMOS sensor interface.
>

*********************

Thank you for the  helpful information.  I see that there quite a bit of
data coming out of these things.  

Do of any ICs that handle this type of video/picture data that can buffer
the data for the Micro.  

I had thought that fpga would be out of the question due to power/size
constraints until I looked over the actel igloo series.  It looks like this
may be a good option to maintain low power and small form factor.  

I have a lot of code already written to handle a lot of my functionality,
so I would like to stay in the micro realm, but I think I will be forced
into the fpga realm at some point, so now might be a good starter for our
fpga needs.  

So, does anyone know of any external IC i might use with a Micro.  Or would
recommend going down the fpga route.  Any comments on the igloo series by
Actel?

**************

In regard to the SD file system functionality.  In the past I have used a
raw format with the SD.  I do have file system code available, but will
have to take a look the nuances that you mention.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Sep 14, 11:25=A0pm, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
wrote:
> >On Sep 14, 8:16=3DA0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com=
>
> >wrote:
>
> >> - would like to use a 1meg pixel, or larger camera - may start with vg=
a
> f=3D
> >or
> >> testing purposes
>
> >Take a look at the camera interfaces before you get too deep down a
> >difficult path. CMOS sensor interfaces aren't exactly easy to use,
> >they have tight realtime requirements. Unfortunately they do NOT work
> >the way an embedded person would like them to work (i.e. no onboard
> >RAM buffer in the camera; you need to read the sensor data out in
> >realtime).
>
> >For this reason most designs use a dedicated special-purpose chip, or
> >an FPGA, or a very large micro with an on-chip DMA camera interface. I
> >believe the parallel port interface on some PIC micros can be used as
> >a camera interface without too much difficulty (it has DMA
> >capability).
>
> >> - Still frame =3DA0is all that is required at this point, but would li=
ke
> to
> >> keep max FPS processing open for future capability
>
> >You won't be doing motion video with anything less than a high-end 32-
> >bit processor with hardware CMOS sensor interface.
>
> *********************
>
> Thank you for the =A0helpful information. =A0I see that there quite a bit=
 of
> data coming out of these things. =A0
>
> Do of any ICs that handle this type of video/picture data that can buffer
> the data for the Micro. =A0
>
> I had thought that fpga would be out of the question due to power/size
> constraints until I looked over the actel igloo series. =A0It looks like =
this
> may be a good option to maintain low power and small form factor. =A0
>
> I have a lot of code already written to handle a lot of my functionality,
> so I would like to stay in the micro realm, but I think I will be forced
> into the fpga realm at some point, so now might be a good starter for our
> fpga needs. =A0
>
> So, does anyone know of any external IC i might use with a Micro. =A0Or w=
ould
> recommend going down the fpga route. =A0Any comments on the igloo series =
by
> Actel?

Well something like the mpc5200b can certainly handle the stream
into ddram and copy it elsewhere, with plenty of power left for other
things.
(Mentioning it because this is what I do at the moment, of course
there are other options).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

>On Sep 14, 8:16=A0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
>wrote:
>
>> - would like to use a 1meg pixel, or larger camera - may start with vga
f=
>or
>> testing purposes
>
>Take a look at the camera interfaces before you get too deep down a
>difficult path. CMOS sensor interfaces aren't exactly easy to use,
>they have tight realtime requirements. Unfortunately they do NOT work
>the way an embedded person would like them to work (i.e. no onboard
>RAM buffer in the camera; you need to read the sensor data out in
>realtime).
>
>For this reason most designs use a dedicated special-purpose chip, or
>an FPGA, or a very large micro with an on-chip DMA camera interface. I
>believe the parallel port interface on some PIC micros can be used as
>a camera interface without too much difficulty (it has DMA
>capability).
>
>> - Still frame =A0is all that is required at this point, but would like
to
>> keep max FPS processing open for future capability
>
>You won't be doing motion video with anything less than a high-end 32-
>bit processor with hardware CMOS sensor interface.
>

*********************

Thank you for the  helpful information.  I see that there quite a bit of
data coming out of these things.  

Do of any ICs that handle this type of video/picture data that can buffer
the data for the Micro.  

I had thought that fpga would be out of the question due to power/size
constraints until I looked over the actel igloo series.  It looks like this
may be a good option to maintain low power and small form factor.  

I have a lot of code already written to handle a lot of my functionality,
so I would like to stay in the micro realm, but I think I will be forced
into the fpga realm at some point, so now might be a good starter for our
fpga needs.  

So, does anyone know of any external IC i might use with a Micro.  Or would
recommend going down the fpga route.  Any comments on the igloo series by
Actel?

**************

In regard to the SD file system functionality.  In the past I have used a
raw format with the SD.  I do have file system code available, but will
have to take a look the nuances that you mention.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

>Well something like the mpc5200b can certainly handle the stream
>into ddram and copy it elsewhere, with plenty of power left for other
>things.
>(Mentioning it because this is what I do at the moment, of course
>there are other options).
>
>Dimiter
>

Thanks Dimiter -

Looks like a screaming machine.  Unfortunately, it also looks like a power
hungry machine.  I am dealing with battery operated devices with ~ 1500
mA/hr @ 3 V.  This think would run me dry in no time.  I am hoping for
something more in the range of max current of 30-100mA. The igloos tout
some pretty serious low power prospects.  I have found some pretty high
performing 32 bit MCUs well that perform well under 100 mA active.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Sep 15, 12:48=A0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
wrote:
> >Well something like the mpc5200b can certainly handle the stream
> >into ddram and copy it elsewhere, with plenty of power left for other
> >things.
> >(Mentioning it because this is what I do at the moment, of course
> >there are other options).
>
> >Dimiter
>
> Thanks Dimiter -
>
> Looks like a screaming machine. =A0Unfortunately, it also looks like a po=
wer
> hungry machine. =A0I am dealing with battery operated devices with ~ 1500
> mA/hr @ 3 V. =A0This think would run me dry in no time. =A0I am hoping fo=
r
> something more in the range of max current of 30-100mA. The igloos tout
> some pretty serious low power prospects. =A0I have found some pretty high
> performing 32 bit MCUs well that perform well under 100 mA active. =A0 =
=A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.EmbeddedRelated.com

Ah, yes, this will eat at least a watt (that's what the mpc5200b
will eat alone at full power but there is also the DDR to take
into account).
Had missed the battery requirement, this will take something closer
to laptop style batteries to be practical in that context :-) .

You may be lucky with some TI 54xx (or 55xx which however I have
never used) DSP; they have plenty of DMA etc. stuff, and if you
locate a part with enough RAM (not sure there is any) I am pretty
sure the rest will be OK. Worth a look - although I don't know
Actel FPGA you are considering so I can't compare to it).

Dimiter

On Sep 14, 2:33=A0pm, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
wrote:
> >On Sep 14, 8:16=3DA0am, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com=
>
> >wrote:
>
> >> - would like to use a 1meg pixel, or larger camera - may start with vg=
a
> f=3D
> >or
> >> testing purposes
>
> >Take a look at the camera interfaces before you get too deep down a
> >difficult path. CMOS sensor interfaces aren't exactly easy to use,
> >they have tight realtime requirements. Unfortunately they do NOT work
> >the way an embedded person would like them to work (i.e. no onboard
> >RAM buffer in the camera; you need to read the sensor data out in
> >realtime).

If you have enough SRAM somewhere, it's going to kill your battery.
You have to use Mobile DDR SDRAM.

> ...

> I had thought that fpga would be out of the question due to power/size
> constraints until I looked over the actel igloo series. =A0It looks like =
this
> may be a good option to maintain low power and small form factor. =A0

Yes, Igloo is compatible with ProASIC3, just more expensive.

>
> I have a lot of code already written to handle a lot of my functionality,
> so I would like to stay in the micro realm, but I think I will be forced
> into the fpga realm at some point, so now might be a good starter for our
> fpga needs. =A0

You can embedded a Cortex M1 into the FPGA.

A FPGA/SDRAM pair can be build in a 2"x1.5" module with 4 layers
PCB.   You can build the rest in 2 layers.

See http://linnix.com/bga

You can download the "Design Tool" (A Window App) to review the
layout.  Make sure all the *.txt chip/wire files are in the same
directory as the program (for example: download to c:\temp\bga and
click on bga.exe).  Use "x2" or "x4" to zoom in and mouse press and
drag to pan.

Thank you for the very helpful info.  This should give me a good start! 
Let me know if anyone has any further comments - ideas.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com