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.
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.
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.
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?
And you arrived at those number how, exactly?
Based on a 32 bits x86, unless the PIG (sorry, PIC) is faster than the x86.
No, even an ARM7TDMI with ~30 MHz and 50 kB ROM can decode MP3.
Seems that dsPIC based MP3 player was an entry in Microchip's 2004 dsPIC contest:
but cannot find anywhere any article describing it.
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.
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)
You could always have a look at
Alan
-- Sell your surplus electronic components at
Decoding MP3 with software floating point is impossible, you need an optimized fixed point decoder like Helix
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
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
I think you can probably write a 6502 emulator in much less than 32 kB...
-- Best Regards, 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
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
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
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
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.