Arduino Mega footprint; three 32-bit cores all running at 200 MHz; 4 Mbytes of Flash and 500 Kbytes of RAM; works with the Arduino IDE; what’s not to love?
I tend to have a lot of hobby projects on the go at any particular time. Occasionally, I even manage to finish one. More rarely, one actually works.
Awesome Audio Reactive Artifact (Click image to see a larger version — Image source: Max Maxfield)
I also have a soft spot for 8-bit microprocessors and microcontrollers. Thus, many of my hobby projects are based on the Arduino Nano, Uno, or Mega platforms.
Take my Awesome Audio Reactive Artifact, for example. This little rascal is currently powered using an Arduino Uno, which is driving 145 tricolor NeoPixels. In turn, these NeoPixels are mounted under 31 defunct vacuum tubes (see also Awesome Audio-Reactive Artifact meets BirmingHAMfest).
The Awesome Audio Reactive Artifact also includes an ADMP401-based MEMS Microphone breakout board (BOB), which costs $10.95 from the guys and gals at SparkFun. In turn, this feeds a cheap-and-cheerful MSGEQ7 audio spectrum analyzer chip, which relieves the Arduino of a lot of processing pain (see also Using MSGEQ7s In Audio-Reactive Projects).
Countdown Timer (Click image to see a larger version — Image source: Max Maxfield)
Sad to relate, 8-bit Arduinos sometimes run out of steam. Consider my Countdown Timer, for example, whose task it is to display the years (YY), months (MM), days (DD), hours (HH), minutes (MM), and seconds (SS) to my 100th birthday (see also Yes! My Countdown Timer is Alive!).
This little scamp employs 12 Lixie displays, each of which contains 20 NeoPixels, which gives us 240 NeoPixels in all. As the sophistication of the effects I was trying to implement increased, so did my processing requirements. Thus, I decided to use a Teensy 3.6, which features a 32-bit 180 MHz ARM Cortex-M4 processor with a floating-point unit. Furthermore, the Teensy 3.6 boasts 1 Mbyte of Flash memory for code, along with 256 Kbytes of RAM for dynamic data and variables.
Prognostication Engine (Click image to see a larger version — Image source: Max Maxfield)
All of which brings us to the pièce de résistance in the form of my Pedagogical and Phantasmagorical Prognostication Engine (see also The Color of Prognostication). This bodacious beauty sports two knife switches, eight toggle switches, ten pushbutton switches, five motorized potentiometers, six analog meters, and a variety of sensors (temperature, barometric pressure, humidity, proximity). All of this requires a bunch of analog and digital general-purpose input/output (GPIO) pins.
Furthermore, in addition to a wealth of weird, wonderful, and wide-ranging sound effects, the engine is equipped with 354 NeoPixels. These could potentially be daisy-chained from a single pin, although I ended up partitioning them into five strands. More importantly, the various effects require a lot of processing and memory.
When things finally started to come together on this project, I was initially thinking of using an Arduino Mega to power the beast, mainly because it has 54 digital pins and 16 analog inputs. On the downside, we have to remember that this is only an 8-bit processor gamely running at 16 MHz with a scant 256 Kbytes of Flash memory and 8 Kbytes of RAM. Furthermore, the Mega doesn’t have a floating-point unit (FPU), which means that if you need to use floating-point operations, this will really impact the performance of your programs.
The tri-core ShieldBuddy (Click image to see a larger version — Image source: Hitex)
But turn that frown upside down into a smile, because the boffins at Hitex (hitex.com) have taken the Arduino Mega form factor and slapped an awesome Infineon Aurix TC275 processor down on it.
These processors are typically found only in state-of-the-art embedded systems. they rarely make it into the maker world (like the somewhat disheveled scientist who is desperately in need of a haircut says in the movie Independence: “They don’t let us out very often”).
The result is called the ShieldBuddy. As you can see in this video, I just took delivery of my first ShieldBuddy, and I’m really rather excited (I say “first” because I have no doubt this is going to be one of many).
So, what makes the ShieldBuddy so special? Well, how about the fact that the TC275 boasts three independent 32-bit cores, all running at 200 MHz, each with its own FPU, and all sharing 4 Mbytes of Flash and 500 Kbytes of RAM (actually, this is a bit of a simplification, but it will suffice for now).
There’s no need for you to be embarrassed — I’m squealing in excitement alongside you. Now, if you are a professional programmer, you’ll be delighted to hear that the main ShieldBuddy toolchain is the Eclipse-based “FreeEntryToolchain” from HighTec/PLS/ Infineon. This is a full-on C/C++ development environment with source-level debugger and suchlike.
But how about if — like me — you aren’t used to awesomely powerful (and correspondingly complicated) Eclipse-based toolchains? Well, there’s no need to worry, because the guys and gals at Hitex also have a solution for the Arduino’s integrated development environment (IDE).
Sit up straight and pay attention, because this is where things start to get really clever. In addition to any functions you create yourself, an Arduino sketch (program) always contains two functions: setup(), which runs only one time, and loop(), which runs over and over again.
Now, remember that the ShieldBuddy has three processor cores, which we might call Core 0, Core 1, and Core 2. Well, you can take your existing sketches and compile/upload them for the ShieldBuddy, and — by default — they will run on Core 0.
You could achieve the same effect by renaming your setup() function to be setup0(), and renaming your loop() function to be loop0(), which explicitly tells the compiler to target these functions at Core 0.
The point is that you can also create setup1() and loop1() functions, which will automatically be compiled to run on Core 1, and you can create setup2() and loop2() functions, which will automatically be compiled to run on Core 2. Any of your remaining functions will be compiled in such a way as to run on whichever of the cores need to use them.
Although each core runs independently, they can communicate between themselves using techniques like shared memory. Also, you can use interrupts to coordinate and communicate between cores.
And things just keep on getting better and better, because it turns out that a NeoPixel library is already available for the ShieldBuddy.
I’m just about to start experimenting with this little beauty. All I can say is that everybody needs a ShieldBuddy and my ShieldBuddy is my new best friend (sorry Little Steve). How about you? Could any of your projects benefit from the awesome processing power provided by the ShieldBuddy?
Originally posted HERE.
