OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you can throw a stick at!
In a recent column on Recreating Retro-Futuristic 21-Segment Victorian Displays, I noted that I’ve habitually got a number of hobby projects on the go. I also joked that, “one day, I hope to actually finish one or more of the little rascals.” Unfortunately, I’m laughing through my tears because some of my projects do appear to be never-ending.
For example, shortly after the internet first impinged on the popular consciousness with the launch of the Mosaic web browser in 1993, a number of humorous memes started to bounce around. It was one of these that sparked my Pedagogical and Phantasmagorical Inamorata Prognostication Engine project, which has been a “work in progress” for more than 20 years as I pen these words.
Feast your orbs on the Prognostication Engine (Click image to see a larger version — Image source: Max Maxfield)
As you can see in the image to the right, the Prognostication Engine has grown in the telling. The main body of the engine is housed in a wooden radio cabinet from 1929. My chum, Carpenter Bob, created the smaller section on the top, with great attention to detail like the matching hand-carved rosettes.
The purported purpose of this bodacious beauty is to forecast the disposition of my wife (Gina the Gorgeous) when I’m poised to leave the office and head for home at the end of the day (hence the “Prognostication” portion of the engine’s moniker). Paradoxically, should Gina ever discover the true nature of the engine, I won’t actually need it to predict her mood of the moment.
As we see, the control panels are festooned with antique knobs, toggle switches, pushbuttons, and analog meters. The knobs are mounted on motorized potentiometers, so if an unauthorized user attempts to modify their settings, they will automatically return to their original values under program control. The switches and pushbuttons are each accompanied by two LEDs, while each knob is equipped with a ring of 16 LEDs, resulting in 116 LEDs in all. Then there are 64 LEDs in the furnace and 140 LEDs in the rings surrounding the bases of the large vacuum tubes mounted on the top of the beast.
I was just reflecting on how much technology has changed over the past couple of decades. For example, today’s “smart LEDs” like WS2812Bs (a.k.a. NeoPixels) can be daisy-chained together, allowing multiple devices to be controlled using a single pin on the microcontroller. It probably goes without saying (but I’ll say it anyway) that all of the LEDs in the current incarnation of the engine are tricolor devices in the form of NeoPixels, but this was not always the case.
An early prototype of a shift register capable of driving only 13 tricolor LEDs (Click image to see a larger version — Image source: Max Maxfield)
The tricolor LEDs I was planning on using 20 years ago each required three pins to be controlled. The solution at that time would have been to implement a huge external shift register. The image to the left shows an early shift register prototype sufficient to drive only 13 “old school” devices.
And, of course, developments in computing have been even more staggering. When I commenced this project, I was using a PIC microcontroller that I programmed in BASIC. After the Arduino first hit the scene circa 2005, I migrated to using Arduino Unos, followed by Arduino Megas, that I programmed in C/C++.
One of the reasons I like the Arduino Mega is its high pin count, boasting 54 digital input/output (I/O) pins, of which 15 can be used as pulse-width modulated (PWM) outputs, 16 analog inputs, and 4 UARTS. On the other hand, the Mega is only an 8-bit machine running at 16 MHz, it offers only 256 KB of Flash (program) memory and 8 KB of SRAM, and it doesn’t have hardware support for floating-point operations.
The thing is that the Prognostication Engine has a lot of things going on. In addition to reading the states of all the switches and pushbuttons and potentiometers, it has to control the motors behind the knobs and drive the analog meters. Currently, the LEDs are being driven with simple test patterns, but these are going to be upgraded to support much more sophisticated animation and fading effects. The engine is also constantly performing calculations of an astronomical and astrological nature, determining things like the dates of forthcoming full moons and blue moons.
In the fullness of time, the engine is going to be connected to the internet so it can monitor things like the weather. It’s also going to have its own environmental sensors (temperature, humidity, barometric pressure) and proximity detection sensors. Furthermore, the engine will also boast a suite of sound effects such that flicking a simple switch, for example, may result in myriad sounds of mechanical mechanisms performing their magic. At some stage, I’m even hoping to add things like artificial intelligence (AI) and facial recognition.
The current state of computational play (Click image to see a larger version — Image source: Max Maxfield)
Sad to relate, my existing computing solution is not capable of handling all the tasks I wish the engine to perform. The image to the right shows the current state of computational play. As we see, there is one Arduino Mega in the lower cabinet controlling the 116 LEDs on the front panel. Meanwhile, there are two Megas in the upper cabinet, with one controlling the LEDs in the furnace and the other controlling the LEDs associated with the large vacuum tubes.
Up until a couple of years ago, I was vaguely planning on adding more and more Megas. I was also cogitating and ruminating as to how I was going to get these little rascals to talk to each other so that everyone knew (a) what we were trying to do and (b) what everyone else was actually doing.
Unfortunately, the whole computational architecture was becoming unwieldy, so I started to look for another solution. You can only imagine my surprise and delight when I was first introduced to the original ShieldBuddy TC275 from the folks at Hitex (see Everybody Needs a ShieldBuddy). This little beauty, which has an Arduino Mega footprint, features the Aurix TC275 processor from Infineon. The TC275 boasts three 32-bit cores, all running at 200 MHz, each with its own floating-point unit (FPU), and all sharing 4 Mbytes of Flash and 500 Kbytes of RAM (this is a bit of a simplification, but it will suffice for now).
Processors like the Aurix are typically to be found only in state-of-the-art embedded systems and they rarely make it into the maker world. To be honest, when I first saw the ShieldBuddy TC275, I thought to myself, “Life can’t get any better than this!” Well, I was wrong, because the guys and gals at Hitex have just announced the ShieldBuddy TC375, which features an Aurix TC375 processor!
O.M.G! I just took delivery of one of these bodacious beauties, and I’m so excited that I was moved to make this video.
I don’t know where to start. As before, we have three 32-bit cores, each with its own FPU. This time, however, the cores run at 300 MHz. Although each core runs independently, they can communicate and coordinate between themselves using techniques like shared memory and software interrupts. With regard to memory, the easiest way to summarize this is as follows: The TC375 processor has:
- 6MB Flash ROM
- 384 KB Data flash
And each of the three cores has:
- 240 KB Data Scratch-Pad RAM (DSPR)
- 64 KB Instruction Scratch-Pad RAM (PSPR)
- 32 KB Instruction Cache (ICACHE)
- 16 KB Data Cache (DCACHE)
- 64 KB DLMU RAM
Actually, there’s a lot more to this than meets the eye. For example, the main SRAMs (the DSPRs) associated with each of the cores appear at two locations in the memory map. In the case of Core 0, for example, the first location in its DSPR is located at address 0xD0000000 where it is considered to be local (i.e., it appears directly on Core 0’s local internal bus) and can be accessed quickly. However, this DSPR is also visible to Cores 1 and 2 at 0x70000000 via the main on-chip system bus, which allows them to read and write to this memory freely, but at a lower speed than Core 0. Similarly, Cores 1 and 2 access their own memories locally and each other’s memories globally.
Meet the ShieldBuddy TC375 (Click image to see a larger version — Image source: Hitex)
As for the original ShieldBuddy TC275, if you are a professional programmer, you’ll be delighted to hear that the main ShieldBuddy TC375 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.
By comparison, if you are a novice programmer like your humble narrator, you’ll be overjoyed to hear that the ShieldBuddy TC375 can be programmed via the Arduino’s integrated development environment (IDE). As far as I’m concerned, this programming model is where things start to get very clever indeed.
An Arduino sketch (program) always contains two functions: setup(), which runs only one time, and loop(), which runs over and over again (the system automatically inserts a main() function while your back is turned). If you take an existing sketch and compile it for the ShieldBuddy, then it will run on Core 0 by default. You can achieve the same effect by renaming your setup() and loop() functions to be setup0() and loop0(), respectively.
Similarly, you can 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 “homegrown” functions will be compiled in such a way as to run on whichever of the cores need to use them. I know that, like Pooh, I’m a bear of little brain, but even I can wrap my poor old noggin around this usage model.
There’s much, much more to this incredible board than I can cover here, but if you are interested in learning more, then may I recommend that you visit this portion of the Hitex site where you will find all sorts of goodies, including the ShieldBuddy Forum and the ShieldBuddy TC375 User Manual.
Now, if you will forgive me, I must away because I have to go and gloat over “my precious” (my ShieldBuddy TC375) and commence preparations to upgrade the Prognostication Engine by removing all of its existing processors and replacing them with a single ShieldBuddy TC375.
Actually, I just had a parting thought, which is that the Prognostication Engine’s role in life is to help me predict the future but — when I started out on this project — I would never have predicted that technology would develop so fast that I would one day have a triple-core 300 MHz processor driving “the beast.” How about you? What are your thoughts on all of this?
Originally posted here.
