@alex_m1: Recently i've been researching about the arduino , and than recalled your project. i think the arduino teensy 3 might be a good fit for your project:
Good call -- in fact I've recently been chatting with Paul Stoffregen who is one of the creators of the Teensy -- he has some amazing libraries that address both the display side and the audio side of things.
I will be blogging about this today or tomorrow -- if you are at the Maker Faire in San Francisco thsi coming weekend, you shoudl look him up and say "Max says Hi"
Recently i've been researching about the arduino , and than recalled your project. i think the arduino teensy 3 might be a good fit for your project:
1. speedy Cortex-m4 - 64k ram - great for audio processing. And yes you can do fft in a 8 bitter, but you need to sample at around 5-8khz for that , while heavily optimizing code.
2. Audio library
3. The arduino has a simple scheduler , so you might not need the complexity of two mcu's , communication, etc
4. Not relevant to the project , but might interest your readers : the teensy 3 comes under a commercial friendly license, one of the major things that prevented usage of arduino in commercial projects.
Hey Max, you should check out a couple Arduino libraries I've written (one now in beta testing), and the hardware they run on. Full disclosure, my company makes this Arduino compatible board.
Display library is OctoWS2811. A quick google search will quickly turn it up. OctoWS2811 works with Adafruit NeoPixel LEDs and all other WS2811/2812-based addressible LEDs. OctoWS2811 drives 8 strips in parallel, so it can update 8X faster (these LEDs always use 800 kHz data rates). But the really important feature of OctoWS2811, for your project, it is accomplishes this feat using efficient DMA transfers that leave the CPU almost completely unused while the LEDs update.
All that free CPU could really help you communicate with another processor. With a traditional library, like Adafruit's NeoPixel code, interrupts are fully blocked while the LEDs update. On an AVR-based Arduino board, where the peripherals have only 1 byte of buffering, that means you can't receive data while transmitting to the LEDs.
However, another new library I've been developing for nearly the last year may completely change your 2-chip paradigm!
This new audio library allows processing CD quality audio with the ease and simplicity you'd expect from Arduino. That probably sounds too incredible to be true, but the catch is it only works on Teensy 3.1, running at 96 MHz with an ARM Cortex-M4 chip. That's a similar chip to the M3 on Arduino Due, but the M4 includes special DSP accellerating instructions, which of course my audio library uses to good effect.
The audio library already has a 256 point FFT object, and a larger FFT object is planned. The library can use the on-chip 12 bit ADC to receive audio, or an inexpensive shield provides 16 bit audio in & out. The library provides a toolkit of audio processing objects, and connection objects, so you can link them together for automatic CD quality data flow as your Arduino sketch runs. You never have to deal with moving fast data around (the library does it very efficiently). You can just use FFT.available() in your loop() function to detect when the library has completed another FFT calculation.
With these 2 libraries, rather than dealing with 2 chips and the complexity of communicating lots of data, you could write a very simple Arduino sketch that simply checks FFT.available() and then FFT.read() the spectral data and calls leds.setPixel() many times to compose your output, and then leds.show() to update all those NeoPixels. OctoWS2811 has double buffering, for awesome flicker-free animation, and the audio library automatically keeps processing incoming audio, to make this a very simple project.
I hope you'll take a look. These libraries are open source, so you can get all the code to inspect. Not only will they let you do this all on a single inexpensive board, but they'll make it far easier than any of the approaches you mentioned in this article.
If it works out well for you, I hope you'll help spread the word. :)
on Indiegogo. I've recommended they see if they can do a VAT-less version for us outside of the EU.
BTW, virtual peripherals have a long history: Scenix did it (Scenix did a 50MHz 8-bit PIC clone, then become Ubicom and created a 32-bit multi-threaded CPU with virtual peripherals, then went bankrupt and Qualcom bought the assets), the Parallax Propeller does it (and Parallax did a Scenix BASIC Stamp), and the XMOS chips do it.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.