PIC MP3 Decoder

I'm looking for code for any of Microchip's dsPICs that will decode an MP3 file stream into PCM data. C is preferable, but asm will work fine, as well.

Does anyone have any leads on this? Thanks.

Reply to
bmearns
Loading thread data ...

Sure, just need a PIC with 500K program space, 50MHz for mono and 80MHz for stereo. Of course, float point multiplers are needed as well.

Reply to
linnix

But it's a dsPIC. Probably won't make much of a difference I guess. I think you can do MP3 decode in fixed point can't you?

Reply to
Isaac Bosompem

And you arrived at those number how, exactly?

Reply to
James Beck

Based on a 32 bits x86, unless the PIG (sorry, PIC) is faster than the x86.

Reply to
linnix

No, even an ARM7TDMI with ~30 MHz and 50 kB ROM can decode MP3.

Reply to
Andreas Schwarz

Seems that dsPIC based MP3 player was an entry in Microchip's 2004 dsPIC contest:

formatting link

but cannot find anywhere any article describing it.

Reply to
Roman Ziak

Yes, ARM7 or 9 would be a better choice. 30MHz would be tight and fitting a floating point C library in 50 K is impossible. Don't know about asm, and never want to try anyway. I would settle with 50MHz

128K flash.
Reply to
linnix

I may be an old fogey, but I remember when computers came with a 4k ROM for integer BASIC or 8k for floating-point BASIC (and we LIKED it!). An adequate, if stripped down, floating point library shouldn't require

50k.

On the other hand, I believe I've seen a design article for a PIC (or similar class) MP3 player. Decoding was done by a dedicated commercial MP3 ASIC.

--
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)
Reply to
David M. Palmer

You could always have a look at

formatting link

Alan

-- Sell your surplus electronic components at

formatting link
Search or browse for that IC, capacitor, crystal or other component you need.

Reply to
Alan

Decoding MP3 with software floating point is impossible, you need an optimized fixed point decoder like Helix

formatting link
30 MHz and 50 kB is enough for the decoder itself, to do something useful with it you need a bit more of course.

Reply to
Andreas Schwarz

David M. Palmer =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:

haha yeah the old times, 1Mhz 8-bit 6502 with 8K for Applisoft basic, but ARM is 32 bit architecture and 16/32 bit instructions on top of this is RISC i.e. what you do on 6502 with one assembly instruction will take few ARM RISC instruction to do this is why ARMs are much memory hungry and with the $2 worth 32K Flash memory ARM part you can't do what you can do on old 6502 with 4K ROM :)

Best regards Tsvetan

--
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
 Click to see the full signature
Reply to
tusunov

Indeed. It depends all on your performance requirements and what exactly you include. With all math.h functions in both single and double precision 50KB is about right. If you exclude the maths functions then you end up with about 10KB. A fast float-only lib containing add, mul, div, compare takes less than 4KB, a slow one can be done in 1KB.

You clearly haven't ever used ARM or 6502. A typical ARM instruction does the work of many 6502 instructions. Eg ADDEQ r0,r1,r2,LSL #2 does a branch, a shift, an add and a move.

Eh, where do you get the 8x codesize expansion from? The average instruction size of Thumb is around 20 bits. For 6502 it is slightly under 16 bits. Considering you need many 6502 instructions to do the same work, ARM wins big time on codesize. The same is true for other 8-bit CPUs.

Wilco

Reply to
Wilco Dijkstra

I think you can probably write a 6502 emulator in much less than 32 kB...

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

sure, I admit that I never wrote anything in ARM assembler, and I'm not familiar with ARM instructions, but I wrote a lot of assembly code for

6502 on the old Apple ][

if the difference is so small does this means that you can fit the Applesoft interpterer in 10K code for ARM? I doubt

Best regards Tsvetan

--
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
 Click to see the full signature
Reply to
tusunov

It would be better to comapre sizes of BBC basic. Versions coded in both 6502 and ARM exists. The ARM versions have quite a few extentions compared to the 6502 versions. AFAICR the actual interpreter fit inside the 16K cache of the ARM on the various Acorn machines. This allowed for quite fast execution of Basic programs.

Regards Anton Erasmus

Reply to
Anton Erasmus

I don't see why not, you can do a lot in 10KB of code, and AppleSoft wasn't that large compared to BBC BASIC. It would need to be done in assembler as the code was likely highly compressed. Performance was a dirty word at the time, anything was done to save a few bytes.

A perfect illustration of this is Steve Wozniac's floating point code

formatting link
(part of the Apple II ROM). At 114 instructions and 212 bytes for 32-bit float add/sub/mul/div it is amazingly small. However don't ask how many thousand cycles each operation could take, why it doesn't round at all, etc.

My point is that you can trade performance and functionality for codesize. On 32-bit CPUs people choose for more functionality (eg. IEEE 754) and much higher performance and only pay a modest cost in terms of codesize. The tradeoffs are simply different.

Wilco

Reply to
Wilco Dijkstra

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.