Forums

CMOS Camera still shots - SD storage - Design recommendations

Started by fvnktion September 14, 2010
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&#2013266080;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