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
Reply by linnix●September 15, 20102010-09-15
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.
Reply by Didi●September 14, 20102010-09-14
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 =
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
Reply by fvnktion●September 14, 20102010-09-14
>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
Reply by fvnktion●September 14, 20102010-09-14
>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
Reply by Didi●September 14, 20102010-09-14
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/
Reply by fvnktion●September 14, 20102010-09-14
>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
Reply by Warren●September 14, 20102010-09-14
larwe expounded in
news:339321f6-6b25-4005-863c-0eeb1ce11864@q26g2000vbn.googlegroups.com:
> On Sep 14, 8:16�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