Working with a multi-core device can be a daunting concept for a small-MCU jockey, but the xCORE system does a good job of mitigating the intimidation factor.
I've been a stalwart 8-bit MCU user for more than a decade. If you consider raw CPUs, I've been living in the 8-bit world for quite a bit longer than that. Until recently, there's been good justification for staying there: cost, physical component size, and ease-of-use. For my purposes, 8-bits "did the job," and the advantages to moving up didn't outweigh the added complexity or cost.
Having said this, things have started to change over the last few years. Complex 32-bit ARM MCUs are now showing up at prices that were once exclusive to 8- or 16-bit devices. Also, most manufacturers have worked hard at making these devices easier to use. I'd say that the development tools could still use a bit more "friendly," but they're getting there.
The performance gap between 8-bit and 32-bit has grown quite a bit, as well. Along with increasing MCU capability, project requirements have tended to become more and more complex over the same time span.
So, you can only imagine my surprise and delight when EETimes editor Max Maxfield asked if I'd like to take a look at the xCORE-Analog sliceKIT from XMOS. Well, to be completely honest, it took a few moments for my delight to appear as I wasn't all that familiar with the product. However, a brief overview from the ever-enthusiastic Max, combined with a little of research of my own, brought my "delight" to the fore in short order.
The XMOS processor has a 32-bit multi-core architecture. The Analog sliceKIT development board, shown above along with two of my motor drivers, boasts a 16-core version of the processor. Here's part of the overview from the XMOS website:
...xCORE multicore microcontrollers execute multiple real-time tasks simultaneously. Devices consist of one or more xCORE tiles, each containing up to eight logical cores. Each core can execute computational code, advanced DSP code, control software (including logic decisions and executing a state machine) or software that handles I/O.
I'm not sure if the following is a great translation -- perhaps someone from XMOS could weigh in on this -- but it seems to me that, in their vernacular, "tile" = core and "logical core" = thread (I encourage you to go to the XMOS sliceKIT page for a more fulsome description).
Now I'm going to bring this thing up and see what I can do with it, as opposed to spending a lot of time regurgitating the specification and data sheets.
Step one is to download the "xTIMEcomposer" IDE. This is an Eclipse-based IDE with compiler, debugger, simulator, logic analyzer, and timing analyzer included. They've set it up to be compatible with MS Windows (XP - 8.1), OSX, Ubunto, and Centos Linux, so they havenít left any excuses for not getting it installed.
Eclipse requires Java, but I ran into a small problem with my Java installation. After installation, I received an error from xTIMEcomposer stating that it couldn't find a JRE. The helpful folks at XMOS asked about my Java installation and clued me in. As it turned out, I was missing a system path to Java.
I found it first disappointing, then intriguing, and -- finally -- welcome, that peripherals are all software defined. My initial concern came from what little I know about software (a.k.a. bit-banged) peripherals. Bit-banging in an 8-bit device is a decent quick hack, but is limited and difficult to maintain in real-time when loading up the MCU with other code.
However, because of the performance difference, combined with the fact that the xCORE is designed for this, software-defined peripherals can be a real advantage here. You don't need to buy a different variety of MCU to get a different set of peripherals. That's huge.
Even more interesting is the fact that the peripherals come in C source code; not pre-compiled libraries. This gives the advantages associated with both pre-made and bit-banged peripherals. With the source, it's easy to tweak a peripheral if you need something a little different, rather than recreate the whole thing from the ground up.
With the installation out of the way, it's time to see if a lightweight user (like me) can take advantage of a multi-core processor. The tutorial shows how to set up PWM (pulse width modulation), which I use for my robots. That's nice and handy, and I actually disciplined myself to start there with the appropriate xTIMEcomposer Studio tutorial.
The tutorial is pretty clear. My only complaint so far is probably an Eclipse-related issue. The tutorial instructions are displayed in an Eclipse window. This means that when asked to open a dialog as part of the tutorial, the focus goes to that dialog. In turn, this means you can't scroll in the tutorial window to see all of the steps required before closing the dialog. I worked around this issue by screen capturing everything from that section of the tutorial and pasting it into a Microsoft Word document.
To Page 2 >