Hi, I'm struggling to get my Arduino Due set up on my machine. Atmel Start doesn't offer set-up functions for the ATSAM3XE8 SoC that is the root of the AD. Is their another SoC I can select to obtain the appropriate setup in Atmel Smart. I've watched videos, read papers and they all state that I should be able to simply select it! I have managed to download a few demos but compiled code from Studio 7 through GCC is proving to be a black box. Now, the thing I'm planning to do as step 1 is to have a .WAV file from MicroSD RAM playing i.e. 16-bit stereo stream. I mistakenly thought the Uno M0 had a 12-bit DAC (my bad) so I'm choosing the best PWM to Voltage board for a mono stream (paperback is envisaged as the cheapest and most reliable audiobook bar none. If kids in Africa, India or the Amazon play with them, they must always work. For anyone tracking what I'm doing with MP1/MP2/MP2.5/MP3, I've converted the IMDCT routines (they take around 50% of CPU time on all of the annotated implementations from DSPs through SH-2 to ARM7 to some high-end RISC cores. Bastian suggested that I unroll the first pass and it worked wonderfully. Now it's 800 assembly language instructions long BUT it almost achieves MIP/MHz (and on an M0+ I don't think it's possible to go faster. On the second loop, after some serious reogranization I was able to contain all of the variables in registers thus no stacking or storing to RAM and this ends up as 760 lines of assembly language. The 3rd pass is a long series of adds which MAY allow 2 ADDS at once (21-16:15-0) as long as their is no overloading. I decided to keep MP2 in it because DAB radio uses it and I have a long conversation with an editor at the BBC who explained that the MP2 butstream has quite a lot of unused bandwidth so in remote locations, books, news & texts can be recorded for future use. In fact, when they lowered the sampling frequency of Radio 3, they were left with 64 kbs doing nothing. They would happily broadcast lesson plans to schools and since the device is designed to be very low cost and rugged, even small children can have them. I should add that their is a way to get the thing to 'ping' in the 2G spectrum so lost kids can be fond using paperback. Of course, error-correction for DAB needs to operate seconds away from the error because of the way it breaks down. Differential Manchester Decoding paired with a Polar code separated by a matter of seconds. If I understood Verilog I might have been tempted to add extra instructions namely MULA R3,R2,R1,R0 (multiply R0 & R1 & accumulate in R3:R2). A MULL R3,R2,R1,R0 which doesn't accumulate can be emulated just by clearing the accumulator (although the hardware guys might not find if funny) & CLZ. The 64-bit shifts CLZs aren't really thick on the ground so I'm not sure how much faster an implementation would be but more importantly, it means the codec only works on a modified Cortex-M0. I have noted medical equipment with ARM cores in them ad blow me, they all seem to be Cortex M0+ or better. Quick question - why do people still use M0 when M0+ is so much better? I am relying on the extra grunt that the + has over the original. So you can see I have been investigating possible 'light infrastructures' to support paperback. Few people in Nigeria can afford a smartphone but presuming the material cost is <$5 then <$10 on the shelves looks possible. Ensuring every human being has an ARM processor in their possession. Other ideas occur to me such as pico-currency. Not some bitcoin scam but a value exchange mechanism limited to small items. It offers a little convenience and gets people used to the idea that this is the way forward. Last point. When the 32 kbs mono MP3 is complete, I'm hoping you, Bastian and others can spot some speedups. The reason being that MP4 (AAC) has a complexity of 150 MIPS compared to 120 MIPS for MP3. AAC files have an .AAX extension and the documentation states that it's not a fixed-rate system with 32kbs - 128kbs. Now earlier this year, the patents on ACELP & MP3 ran out but what is being kept very quiet is the fact that at least some of the AAC patents have already run out and several 3rd party decoders ignore small items of data so they do not infringe the patents. As far as I can tell, many of the AAC patents run out this year but I'm suspicious that some elements (not obvious even with the source code) such as comfort noise, DTX and other subtle improvements provided by the decoder that aren't recognized... and the Fraunhofer undoubtedly have a recording that will seek to highlight the presence of those elements. That being the case, it may prove better to work with the basic elements of AAC until those patents run out. I don't know if you have patent people at your place Joseph but I'm trying to sneak the Cortex M0+ into as many pockets as possible - Wifi would be possible, they could all 'come alive' as a predetermined time? More a media thing, I suspect.Regards,SeanPS I have reverse engineered the Audible ACELP data and just wondered if you had a bit of source so I understand what I am looking at. It's a very clever scheme, generating just the elements of a huge field that are likely to be needed. I intend to add LPC10e for ultra narrow-band communication (if the chip has this, emergency workers will want it) with the improved gain and a sparse ACELP. For non-realtime situations, new compression methods using truncated infinite trees becomes possible. But when all said and done, for this project I'm aiming for 24Kbytes of ROM & 8Kbytes of RAM.