Image compression MCU/DSP

If not a PIC, then what do you suggest?  For personal and affordable
prototyping, how would one go about it?

amerdsp wrote:
> If not a PIC, then what do you suggest?  For personal and affordable
> prototyping, how would one go about it?

ARM, PPC or X86

On Thu, 11 May 2006 19:41:57 -0700, amerdsp wrote:

> Hello all,
>   What would you experts do if you want to perform image compression (I
> am thinking jpeg), on a low power board?  The data is captured from an
> image sensor and needs to be transmitted elsewhere.  Would you use a
> MCU bundled with a DSP or would you use two separate MCU and DSP chips?
>  I was thinking about using a PIC with nano watt technology along with
> a low power DSP from TI. Or should I use a dsPic? Or anything else?
> 
> Thank you for your time and help.
> 

How about MP3?

Good Luck!
Rich

Thank you for your helpful insight.  I am leaning towards an ARM
solution, do you have any preference about which one to choose from?
It is so confusing with all the choices available.

Thank you.

A

"amerdsp" <amerdsp@hotmail.com> wrote in message 
news:1147484742.253499.180240@j33g2000cwa.googlegroups.com...
> Thank you for your helpful insight.  I am leaning towards an ARM
> solution, do you have any preference about which one to choose from?
> It is so confusing with all the choices available.

Any ARM7tdmi MCU can easily deal with your resolution and
framerate using only a few MHz to do JPEG compression (a well
optimised JPEG is extremely fast on ARM). However it will be difficult
to do this just using on-chip SRAM, and using external SDRAM means
power consumption may become a problem. It may be good enough if
you can collect, process and transfer the image in small strips though,
so you'd want to look for an ARM7 MCU with a lot of on-chip SRAM.

If you want to do JPEG or similar compression and need SDRAM
then it might be better to go for an ARM9 with cache, for example
LPC3180, AT91RM9200 or AT91SAM9261. The caches and higher
performance of ARM9 will significantly lower power consumption.

Wilco

Rich Grise wrote:
> On Thu, 11 May 2006 19:41:57 -0700, amerdsp wrote:
>
> > Hello all,
> >   What would you experts do if you want to perform image compression (I
> > am thinking jpeg), on a low power board?  The data is captured from an
> > image sensor and needs to be transmitted elsewhere.  Would you use a
> > MCU bundled with a DSP or would you use two separate MCU and DSP chips?
> >  I was thinking about using a PIC with nano watt technology along with
> > a low power DSP from TI. Or should I use a dsPic? Or anything else?
> >
> > Thank you for your time and help.
> >
>
> How about MP3?

Yes, they all work the same, just differently.
MP3 works in single dimensional voice freqence.
JPEG works in two dimensional color spectrum.
MPEG works in three dimensional color and temporal spaces.
They can all be handle with the same Si + O compound.

> 
> Good Luck!
> Rich

Wilco Dijkstra wrote:
> "amerdsp" <amerdsp@hotmail.com> wrote in message
> news:1147484742.253499.180240@j33g2000cwa.googlegroups.com...
> > Thank you for your helpful insight.  I am leaning towards an ARM
> > solution, do you have any preference about which one to choose from?
> > It is so confusing with all the choices available.
>
> Any ARM7tdmi MCU can easily deal with your resolution and
> framerate using only a few MHz to do JPEG compression (a well
> optimised JPEG is extremely fast on ARM). However it will be difficult
> to do this just using on-chip SRAM, and using external SDRAM means
> power consumption may become a problem. It may be good enough if
> you can collect, process and transfer the image in small strips though,
> so you'd want to look for an ARM7 MCU with a lot of on-chip SRAM.
>
> If you want to do JPEG or similar compression and need SDRAM
> then it might be better to go for an ARM9 with cache, for example
> LPC3180, AT91RM9200 or AT91SAM9261. The caches and higher
> performance of ARM9 will significantly lower power consumption.

I would suggest at least 32MB SDRAM,
but depends on your sensor resolutions.

For a secured site, we are using a K6 for
capturing, compressing and wifi-ing
aproximately 4 frames per second
at 592x480 12 bits YUV to JPEG

You can plan your hardware by my example:

K6 233MHz
64MB IDE Compact Flash
48MB SDRAM
SAA7130 NTSC Composite
Linksys WUSB11

> Wilco

Thats would be great except that I am unable to sun power to the site,
it has to run of a battery.

I found an epson network camera controller that has ar ARM MCU built in
with a hardware jpeg encoder.  Has anyone used one of these before?  I
am waiting until after the weekend to check where I can get a couple
for prototyping.

Thank you,
A

amerdsp wrote:
> Thats would be great except that I am unable to sun power to the site,
> it has to run of a battery.

Yes, we can run it off battery, with a 50W solar panel charger.
Our setup takes about 20W, wuth the rest saved for overnight.

>
> I found an epson network camera controller that has ar ARM MCU built in
> with a hardware jpeg encoder.  Has anyone used one of these before?  I
> am waiting until after the weekend to check where I can get a couple
> for prototyping.

Did a quick check on the spec.  It can do 7 fps on VGA, with the
hardware JPEG encoder.  That part is good.  But...

    Epson/Arm7 vs.  Phillips/PC
1. 8 bits LUV vs. 12 bits LUV
2. 640x480 vs. 582x480
3. 50MHz vs. 200MHz to 4G

In fact, we might run it on a faster PC.  We are using the
200MHz PCs because they are useless for anything else.

> 
> Thank you,
> A

How large is your setup?

I have other restrictions inclduing size, the smaller the better.  In
fact all the restrictions are competing with each other.. power,
efficiancy, size, battery life.. etc..

  It is great that you can use obsolete equipment for something
beneficial.