CMOS Camera still shots - SD storage - Design recommendations

or

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).

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: snipped-for-privacy@q26g2000vbn.googlegroups.com:

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

f=

to

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

ke

of

this

ould

by

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

------------------------------------------------------

f=

to

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

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

wer

=A0 =A0 =A0

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

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

this

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

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

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

Stay away from FPGA if you can.

There is an MCU that boots from Serial Data Flash and runs on internal RAM with camera inputs and SD card support:

--Vinnie

--------------------------------------- Posted through

check controllers from epson,

dedicated camera interface ARM7TDMI controller MJPEG compression. SD card interface

trying to interface camera on controller PORTS is a time consuming task, i personally have done it before but i think it is not advised unless there is no other way

and after capturing you won't have compression also. need lot of ram.

--------------------------------------- Posted through