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
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.
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
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
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.
Regards, Viron.
"amerdsp" skrev i meddelandet news: snipped-for-privacy@i40g2000cwc.googlegroups.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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.