Greetings,
When an embedded wireless system has a an image sensor, what is
usually used to compress the image for transfer over a GSM network
similar to a cell phone unit?

- Do cell phones/devices have dedicated hardware (FPGA,DSP)?
- Is the compression done in software? I am guessing that would need
a powerful MCU that will consume a lot of power


I am a new at this so any info will be helpful.

Thank you for your time and help.

A

amerdsp wrote:

A cellphone already has a 32-bit MCU that can handle this easily in
software. But they have DCT/iDCT hardware, at least, to help with MPEG
compression and playback.

In comp.arch.embedded amerdsp <amerdsp@hotmail.com> wrote:

Whatever the individual cell phone hardware designer found to be the
best balance on cost vs. energy vs. space vs. processing speed
dilemma.

Typically yes. It may not exactly be dedicated to image processing,
though --- a mobile phone is basically a solid marriage of a CPU with
all kinds of signal processing hardware you can imagine: analog signal
conditioning, DSP, FPGA and everything in between.

Part of it.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Thank you for all your replies.. So what do you suggest one uses to
incorporate that in an embedded low power solution? I am considering a
PIC micro. Can any of these handle the image compression as well as
controlling a camera and a wireless modem? Or any other combination of
MCU/hardware.

The fastest frame rate is 1 frame a sec.

It is a dilema, especially for prototyping and proof of concept.

Thank you, all your replies were helpful..

A

amerdsp wrote:
dsPIC maybe (I haven't looked at it, don't know the capabilities).
Regular PICs can't handle JPEG by any stretch of the imagination. You
could use a proprietary algorithm.

I wouldn't use PIC on principle, but especially not for imaging
applications, too much hoop-jumping. A fast 8051 with external RAM
maybe?

Can you elaborate a little about the hoop-jumping comment? I was
meaning to use the PIC for control. Now that I am digging deeper,
perhaps a PIC in tandem with a DSP? or do you still prefer 8051. I am
not familiar with the 8051, but willing to catch up if needed.

Thank you,

A

amerdsp wrote:
The PIC architecture doesn't handle large RAM spaces nor lookup tables
very efficiently. Image compression involves large chunks of memory
and, often, lookup tables. You won't directly see the hoop-jumping if
you're writing in C, but you sure will feel the ill effects.

I suggested 8051 because it's cheap and easy to prototype. It's going
to be slow, of course, working on JPEGs. You can use a proprietary
compression method and get faster, but larger results.

Hi,
check how they did it.
http://www.roundsolutions.com/cmos-c...era-module.htm

Regards,
Viron.

"amerdsp" <amerdsp@hotmail.com> skrev i meddelandet
news:1145544428.235654.38640@i40g2000cwc.googlegro ups.com...
Look at hours...
An ARM7TDMI AT91M40800@33 Mhz used 40 seconds to compress a VGA picture to
JPEG
in one application I know of. It was executing out of external flash, so a
speedup of 5-6 x should be
possible when executing out of internal memory.
If you plan VGA, then you have 307200 pixels, and are best off with 32 bit
addressing.
If it is QVGA it is still 76800 and you need to still use > 16 bit
addressing.
If you are using a GSM modem, then you face pretty slow bandwidth, (I get 8
kbps or so)
so you are not going to see a framerate of 1 second.
If you assume a reduction ratio of 1:30, then you are still facing 2 - 8
seconds per frame.

If you are using WLAN, then of course there is no problem.

An AVR32 has an instruction set which will allow high speed compression.


--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB