Atmel equivalent of ARM cortex products? Advice on getting into audio playback and processing on Atmel products.

Go To Last Post
75 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Until you know the answer to things like that how could you possibly pick ANY kind of CPU?

 

There we are, Now we're on the same page. As I said, Attiny85 and Atmega328 is all I've worked with. With my last projects I realized they are not powerful enough to pull off what I need. So I gotta get to know the ARM controllers now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
I realized they are not powerful enough
Quantify that and you will get close to your selection criteria ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
... or mp3 samples ...
Microchip has MP3 libraries for PIC32 using 27 MIPS, 46KB flash, and 29KB RAM.

Atmel also obtained a MP3 license for the AVR32 UC3 Audio Series but those UC3 are EOL.

I have forgotten the name of the zero price Linux MP3 software.

LAME : http://lame.sourceforge.net/

 

Microchip Technology

DS70688B

Microchip Compact MP3

Decoder Library

User’s Guide

http://ww1.microchip.com/downloads/en/devicedoc/70688b.pdf

(page 11)

2.2 RESOURCE USAGE

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=SW320014-5 

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=SW320012-2

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=SW320022-1HPM

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=SW320012-1

 

Edit : strikethru

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Aug 30, 2017 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
With my last projects I realized they are not powerful enough to pull off what I need. So I gotta get to know the ARM controllers now.

 

Well, 32 bit perhaps. Generally speaking, faster controllers tend to have more RAM, that is more of marketing thing. Personally I would go with Cortex M3-M4 for this sort of thing, although some other 32 bit cores are better/cheaper, the Cortex architecture is more widely supported.

 

I would have suggested trying Arduino Due, if you are already familiar with Arduino. It has Cortex M3 at 84 MHz with 96 KB RAM, so is a good step up from AVR, probably 5x - 10x faster depending on application. STM32F103 (red/blue pills) are a lot cheaper, slightly lower performance, and less well supported in Arduino.

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For now, I just want to play a couple of samples off an SD card at the same time.

Long Thread...

 

If, for starters at least, you don't wish to go the ARM route, then consider an Xmega, the high end of the Tiny, Mega, Xmega AVR line-up.

 

The Xmegas have built in DAC's to convert the digital data read from an SD card back to an analog voltage for output, (no PWM or R-2R resistor ladder needed).

 

The Xmegas run in spec at 32 MHz, giving you a bit more processing power than a 16 MHz or 20 MHz Mega.

 

There have been a couple of Threads where people mentioned porting the low level interface of Elm Chan's SD card routines to the Xmega, simplifying that part of the project.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I zoomed in on those iFixIt photos.  Looks like the OP-1 has an ADSP-BF524 as the main CPU:

 

The ADSP-BF524 offers up to 400 MHz performance and up to 800 MMACs. This processor core is supported by an advanced DMA controller supporting one-and two-dimensional DMA transfers between on-chip memory, off-chip memory, and system peripherals. The combination of the processor core speed and the DMA controller allows for efficient processing of audio, voice, video, and image data.

 That's much closer to RPi-class than any Cortex-M chip.  Plus "DSP Stuff", whatever that happens to be.

 

 

To me an ARM Cotex A is the same as ARM contex M

That's pretty much exactly like saying "A Pentium 2 is the same as a Pentium 4."

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Microchip has MP3 libraries for PIC32 using 27 MIPS, 46KB flash, and 29KB RAM.

 

Actually, regarding the MP3 licensing, if I were to create an up-loader software that would take mp3 files, re-format reformat them to .wav or other free / open source file format before uploading it to the device over USB, the device won't be using the MP3 codec but the software converting it technically still does? So acquiring the license is still required?

 

donotdespisethesnake wrote:
I would have suggested trying Arduino Due,

 

That was actually a great idea. It seems that Arduino has seized support and releases of the official Due a while back. Not sure what happened there.. You can still buy these boards and use them with the latest Arduino IDE when downloading the board config files from the boards manager. 

 

DocJC wrote:
If, for starters at least, you don't wish to go the ARM route, then consider an Xmega, the high end of the Tiny, Mega, Xmega AVR line-up.

 

To be honest, all the talk about above mentioned ARM controllers kind of made out the AVR processors seem under-powered for my task at hand. Some folks put an emphasis on just how resource generous the ARM lineup is over the AVR. So I'll look into that as well, thank you for the notice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright well I believe I've gotten all the information on the hardware side. For the sake of not encouraging the two threads being about the same subject I shall move on the discussion of software and learning resources on my other thread:

 

http://www.avrfreaks.net/forum/d...

Last Edited: Wed. Aug 30, 2017 - 07:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
Actually, regarding the MP3 licensing, if I were to create an up-loader software that would take mp3 files, re-format reformat them to .wav or other free / open source file format before uploading it to the device over USB, the device won't be using the MP3 codec but the software converting it technically still does?
Yes

M.Thatch wrote:
So acquiring the license is still required?
Indirectly yes other than for LAME.

Indirect because one purchases software that the software creator obtained the MP3 license for.

LAME Official Logo

The LAME Project

LAME is a high quality MPEG Audio Layer III (MP3) encoder licensed under the LGPL.

http://lame.sourceforge.net/

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
One of the things that makes ARM so popular is that there is so much documentation at arm.com - brilliant articles like this....   https://community.arm.com/proces...

 

Oh this is great. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,   

  I suggest that the general application that you are describing is out of the range of an embedded system CPU.

  I suggest that you look into PCs-on-a-chip.  These are very basic "IBM PC compatable" [MSDOS ver 6 or Windows 98 level] systems on small, inexpensive, module boards.

 With these micro-PCs you can use applications like open source audio editors to open, edit, and multi-track play audio files without having to actually write any code for an AVR or Raspberry PI level system.

 

How many of these devices are you making?  Less than 20?  Definitely go the PC-on-a-chip route.   10,000? consider an embedded CPU.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
These are very basic "IBM PC compatable" [MSDOS ver 6 or Windows 98 level] systems on small, inexpensive, module boards.
One instance of that is Intel Joule running Windows 10 IoT Core (zero price; the low price Pro version can update Universal Windows Platform (UWP) applications via Microsoft Store)

But, Intel Joule is EOL with the replacement being Intel Compute Card (ETA 2017 August)

IIRC, the Linux distributions for these is Ubuntu and Yocto.

 

Mouser Electronics  - Electronic Components Distributor

Mouser Electronics

All Products > Embedded Solutions > Computing > System-On-Modules - SOM

Joule Intel System-On-Modules - SOM

http://www.mouser.com/Embedded-Solutions/Computing/_/N-aez39?Keyword=Joule&FS=True

Microsoft

Microsoft

Windows IoT

Get Started

https://developer.microsoft.com/en-us/windows/iot/getstarted

...

Select your hardware

...

Intel Compute Card

https://www.intel.com/content/www/us/en/compute-card/intel-compute-card.html

Yocto Project

https://www.yoctoproject.org/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
 With these micro-PCs you can use applications like open source audio editors to open, edit, and multi-track play audio files without having to actually write any code for an AVR or Raspberry PI level system.

 

The whole point of the exercise is to actually learn how to write programs of these levels instead of using what other people made. Right now I need resources on basic IO with the ARM controllers. Folks here have referenced ARM hosting the best documentation on programming their controllers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ARM just design the processor core - the other stuff like i/o is left to the manufacturers. So whilst the ARM doc may be great, I rarely need to reference it unless I'm doing something very specific. The beauty of Arduino is it does most of the hard work for you, similarly with MBED.

With the embedded stuff I write - mostly on microcontrollers, over 90% of the code is portable to just about anything, the rest tends to be hardware specific. Do I use Arduino? Mainly for prototyping as any chip or device that is half useful has code written for it on Arduino. If you don't use Arduino, your other choices are the likes of ASF which doesn't have a good reputation. If you want to write your own low level code, then you'll spend a couple of days understanding, say the i2c hardware, writing some code then testing/debugging it. At least with Arduino, you can sort of assume the i2c library works as a zillion people use it. If it doesn't work the way I want it, then I'll change what is required. Recently I used the Arduino serial library for the Infineon XMC1100. I found a subtle defect so I fixed that and alerted the maintainers of that code. It's now in the latest release. You want to read a file of a SDcard. You could use a ready written library or you could write your own from scratch. What would you choose? Do you want to be an expert in SDcard and Fat file systems just to read a file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Do you want to be an expert in SDcard and Fat file systems just to read a file?

 

Well I need to be able to not just load the file, play it back, but to also be able to cut chunks of audio and put them into another file, be able to speed up and slow down sections of the same audio file, not just speed up the entire sample, I want to be able to copy a section of an audio file and create a new file with just that chunk. So does all that sound like any library can do? Most of the audio libraries don't even offer most of the what I just mentioned. This is why I need to get down and dirty with learning to load files and play them back myself Right now I need to find some resources on loading audio files and playing them back and by the looks of it, the only way I can do that is to look at the source code of any arduino audio library out there and try to make sense of the code. These libraries contained so much compatibility code, I'd imagine that it's the same code copied with adjustments for which board you're uploading it to which I wouldn't need as I'd write the code to a specific board I'm using.

 

Now then, any Resources you might know of specifically in audio sample works?

Last Edited: Thu. Aug 31, 2017 - 07:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'd get it working on a PC first then look at porting it down to an embedded system. Even then, what you're describing sounds more like raspi territory at a minimum rather than a single chip micro. I'd suggest you find out how many bytes are used to store your sound data per second then work that into what you want to do. This will give you an idea of how much ram you might need.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
So does all that sound like any library can do?
Google suggests things like:

 

https://ccrma.stanford.edu/softw...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I'd get it working on a PC

 

What do you mean by that? Like use emulation in an IDE? before uploading and testing on a board? Or you mean picking the same processor as raspberry pi? I'm looking at the wiki and it says that this is the processor it uses:

 

Processor[edit]

The Raspberry Pi 2 uses a 32-bit 900 MHz quad-core ARM Cortex-A7 processor.

The Broadcom BCM2835 SoC used in the first generation Raspberry Pi is somewhat equivalent to the chip used in first modern generation smartphones (its CPU is an older ARMv6 architecture),[19] which includes a 700 MHzARM1176JZF-S processor, VideoCore IV graphics processing unit (GPU),[20] and RAM. It has a level 1 (L1) cache of 16 KB and a level 2 (L2) cache of 128 KB. The level 2 cache is used primarily by the GPU. The SoC is stacked underneath the RAM chip, so only its edge is visible.

The Raspberry Pi 2 uses a Broadcom BCM2836 SoC with a 900 MHz 32-bit quad-core ARM Cortex-A7 processor, with 256 KB shared L2 cache.[21]

The Raspberry Pi 3 uses a Broadcom BCM2837 SoC with a 1.2 GHz 64-bit quad-core ARM Cortex-A53 processor, with 512 KB shared L2 cache

 

How come you guys reffer to the processor as raspi?

 

What's bugging me a bit is that I'm having all this hardware talk and getting new recommendations on which processors I should use and I"m still not getting anywhere closer to knowing what lines of code to write to actually do what I need to do. So I have the hardware figured out. Heck I can stick to the ARM controller on an Arduino DUE. The whole ram issue has been solved by loading files in sections. What I need now is to learn how to do that. Besides looking at source code of libraries, are you by any chance aware of any documentation or documented projects by other users who have done this? I still have heap of information to go over in the two threads I've made so excuse me for a moment.

 

clawson wrote:
M.Thatch wrote: So does all that sound like any library can do? Google suggests things like:   https://ccrma.stanford.edu/softw...
 

 

That looks interesting.

Last Edited: Thu. Aug 31, 2017 - 08:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.Thatch wrote:
I"m still not getting anywhere closer to knowing what lines of code to write to actually do what I need to do.
You do have access to Google right? When I type things like "audio processing library" I hit things like:

 

https://stackoverflow.com/questi...

https://processing.org/reference... (that's actually the predecessor to Arduino in fact!)

https://github.com/JorenSix/Tars...

https://github.com/filoe/cscore

https://www.surina.net/soundtouch/

https://ccrma.stanford.edu/softw...

 

Sure some of those may be the "wrong language" or for the "wrong platform" but you may be able to re-use the algorithms they implement anyway.

 

Now I guess you might say "but I want to write all this from scratch to learn" but you have to decide where you split things between the higher level stuff you write to actually "do" something and the library code you pull in and rely on for the lower level stuff. Think about "normal C" - you probably wouldn't consider needing to write your own printf() when you can just call on the one from the library.

 

But the fact is that "audio processing" is as old as the hills. People have been wanting to do it for years and there must be hundreds/thousands of existing (open!) solutions available on the internet to save you having to reinvent the wheel. My list above are just a few links from the first page of results. Google told me my search (which may not have been extensive) returned 38 million results. (but if Google is working right the "popular" ones should be on page 1.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your first challenge is to write code to manipulate the sound file. Get a C compiler for windows (i'd use Linux) and learn how to manipulate the audio data in C. Once you've mastered that, then moving that onto a smaller platform should be less troublesome. Debugging on a resource constrained platform has its challenges.
Reading/writing files is relatively easy regardless of the platform. Manipulating the audio data will have its challenges as will creating a user interface. Outputting the data to a DAC is relatively easy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Get a C compiler for windows (i'd use Linux) and learn how to manipulate the audio data in C.
I think you'll find that most "modern" work is probably C++ not C ;-)

 

Actually Russell's comment made me think that of course this is open source:

 

https://github.com/audacity/auda...

 

That is (possibly?) the most widely used audio editor in the world.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, my guess is Miles wants to do something like a mini sampler - you grab soundbites and loop them etc. So my suggestion is to do low level stuff in C/C++ to get a feel for what is involved eg move stuff around in 512byte buffers etc then write a file. You can then play it back or use tools like audacity to check it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

clawson wrote:
Sure some of those may be the "wrong language" or for the "wrong platform" but you may be able to re-use the algorithms they implement anyway.

Yep pretty much my concert. 

 

clawson wrote:
Now I guess you might say "but I want to write all this from scratch to learn" but you have to decide where you split things between the higher level stuff you write to actually "do" something and the library code you pull in and rely on for the lower level stuff. Think about "normal C" - you probably wouldn't consider needing to write your own printf() when you can just call on the one from the library.

 

Just about the reassurance I was looking for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Atmel also obtained a MP3 license

STM32 also has mp3 decoders. You can chose between a (buggy?) open source variant or a (more robust?) commercial library.

 

And all patents of mp3 are expired and I'm not sure why you would need to purchase a lisense for MP3.

Andyway, as far as I can remember the lisecne scheme for mp3 has been for encoding only and decoding has always been free of monetary exchange.

Or just use ogg. well established in the open soure world.

 

Personally I have never had much interest in lossy audio.

Ripped my complete CD collection to Flac and sold the CD's years ago

 

Did a quick search for mp3 in PlatformIO:

pio lib search mp3

Found 7 libs. Most are for controlling the VS1053 chip / board.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Pages