Notes from AVR32 UC3 seminar

You must be joking... MP3 in software has been done for many years on

32-bit MCUs. MP3 needs just 7.5MHz on an ARM9E. Older iPod models use an ARM7tdmi with software decode. For the lowest power you need to do it in hardware, which is what many players do nowadays.

Wilco

I have not used ARM9E chips but they probably use a ton of current. I work almost exclusively with low-power battery applications.

I never saw an ARM7 implementation of MP3. I'd like to know if anyone has a reference to a libmad, or other, open source MP3 library for ARM7 chips.

Of the current ARM chips, it's my guess that only the STM32 (Cortex M3) could be considered a low-power chip that can decode MP3, if indeed it can. Maybe the SAM7S32 could also do it?

Eric

LPC3180 uses 6.3mW at 13MHz (enough to decode MP3). Does that count as low power?

But even if an ARM9E used a lot more power per MHz, it would actually need less power than an ARM7 for MP3 decoding. You need to compare the total energy to get a job done, not just the mW/MHz.

I'm sure a search will give lots of hits. I know you can get free MP3 libraries for LPC and SAM MCUs. Any well-written open source MP3 decoder could be compiled for ARM7, but you probably won't get the best performance.

Cortex-M3 is by no means the only MCU that can decode MP3. It's possible on any ARM as long as it has enough memory (that excludes SAM7S32). However it is likely going to use more power on ARM7 than either Cortex-M3 or ARM9E.

Wilco

You are right in principle, you can do MP3 on a flash based ARM7, or Cortex-M3 or ARM9E. I have seen people claim that you need to run an ARM7 core at top frequency to do MP3, and this means either copy to SRAM, (preferable on a SAM7) or the 100 mA LPC chips which are really out of the league here.

Since the orignal posting was referring to flash based microcontrollers, it is irreelevant to mention what you can do with non-flash microcontrollers. Show a flash based ARM9E with lower power!

Anyway the LPC3180 does not have enough internal memory, to do a real application, so you have to add the power consumption of the external memory to your figures.

The STM32 does not have enough RAM to do MP3 decoding, so where does that leave Cortex-M3 for this application? Luminary-Micro use more power than ARM7. Chips will come, but they are not here yet.

Neither have enough memory, The typical configuration is 256 kB code for a decent application, so a SAM7S256 will fit, if executing critical code

And less on the AVR32 due to its more efficient implementation of DSP features for this application, compared to Cortex-M3.

• single cycle SRAM access

• use of upper/lower half of register allowing 1/2 clock cycle per load.

• single cycle MAC (with one extra cycle for writeback at the end)

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

The original 'Zipit Wireless Messenger' is ARM7tdmi; mp3 is easily done in s/w (under Linux 2.4.27 variant). For a summary of some capabilities see

Regards,

Michael

That's a neat device but I was talking about single chip MCUs with internal flash and RAM. So far, there's no single chip of any kind that can run linux. I'm sure the day is coming, though. Maybe within 5 years.

Eric

Do you include single-package devices in that (stacked die) or do you want it monolithic ?

What about stacked die, without bonding wires ?

Stacked die is the preferred volume approach, as it allows eash vendor to opeimise what they do best, and increased finished yields, as each die is pre-tested.

I would have thought some of todays stacked-die devices could run Linux ?

-jg

there are least 2 TRUE-single IC package chips running linux

AXIS etrax

samsung

I think those are not only examples of single IC linux devices

Antti