Wouldn't it be nice to see the A/D's output all the time? A continuous graph might be even nicer. Or watch all of the stack pointers' high water marks? Here's a tool that does just that.
Spinning Multicore
Parallax (www.parallax.com) of BASIC Stamp fame released a very innovative--and very different--multicore processor a year or so ago called the Propeller, shown in Figure 2. It has eight 32-bit processors ("cogs") sporting 2 kbytes of RAM each. Other resources, including 64 kbytes of RAM and ROM, are shared by all of the cogs. Nothing terribly new there. But a "hub" controls access to these assets by sequentially opening a window of opportunity for each cog. Cog 0 gets a shot, then cog 1, and so on. Think of a V-8's distributor rotor. This hardware lockout means there are no bus contention problems or mutual exclusion issues. It hugely simplifies real-time programming.
View the full-size image
Unlike many multicore CPUs, this is a microcontroller. The bus doesn't connect to the part's pins so memory cannot be expanded. In fact, other than power and a couple of housekeeping pins, the device has just 32 I/O connections to the outside world. And herein lies another bit of clever quirkiness: each of those I/O lines goes to all of the cogs. If configured as outputs, the result is the logical OR of all of the cog's assertions. If cog 0 sets pin 23 to a zero, and cog 5 drives it high, the output will be high. Odd, huh? But this is a part meant for control applications. If a pin were tied to a warning light, any cog can easily, and without any complex interprocessor communications code, turn the light on.
In addition to the 2 kbytes of RAM, each cog has a pair of counters and, of all things, a video generator. But a lot of embedded applications feed small LCD displays; put the video on-chip and you can buy a cheaper display unit.
The cogs have no stack, and in fact have no need of a stack. Calls pass the return address very much like the SLJ instruction on the Univac 1100 series (for you old-timers). There are no registers, per se, either. Every instruction specifies both a destination and source for arguments in the cog's RAM. Cogs have instructions to start and stop other cogs and to control built in hardware semaphores.
There are no interrupts: just assign a cog to the activity. It makes you think about a very different paradigm when processors are abundant.
A cog can read and write to the shared memory (well, they can only write to the 32 bytes that's not ROM), but cannot execute from that space. So programs are limited to 2 kbytes/cog, although it's possible to reload that memory at any time from shared memory. Two kilobytes might not sound like much, but many apps just don't need big programs.
An on-chip interpreter called Spin makes bigger programs possible at the expense of execution time. A cog executing a Spin app is really running the Spin interpreter from its local memory while executing tokens stored in the larger shared area. Tokens, of course, are much more compact than compiled binary from traditional languages.
Here's a complete two-cog Spin program that blinks a pair of LEDs:
VAR
Long Stack[9]
Pub Main
cognew(Toggle(16, 3_000_000, 100), @Stack)
Toggle(17, 2_000_000, 200)
Pub Toggle (Pin, Delay, Count)
dira[Pin]~~
repeat Count
!outa[Pin]
waitcnt(Delay + cnt)
The cognew token starts routine Toggle running on another cog, while it continues to run Toggle on the initial cog. Note that the code for all of the cogs lives in a single source file. Multicore programming just can't get much simpler.
The 32 kbytes of shared ROM has the Spin interpreter in it, of course, but that is under 2 kbytes. The rest contains the video generator character set, plus log, antilog, and sine tables! Again, this defies our notion of what's found on a CPU, but makes some sense: logs make for faster multiplications and divisions, and trig calculations are common in many apps. Putting them in shared memory saves limited cog RAM.
The Propeller IDE looks like a simplified C development environment, but it, too, is full of novel thinking. Copy and paste work on arbitrary rectangles. There's a font for drawing schematics, which is TrueType, so any other Windows application can use it. Normal comments exist, of course, as do a sort of meta-comment. In "documentation" view all of the code disappears but the function definitions and meta-comments remain. Smart formatting automatically sets functions in alternating colors so the extent of a function is instantly clear. There's a lot more, but not room enough to describe it here.
At about $8 in quantity, these 160-MIPS parts are worth checking out.
Jack Ganssle (jack@ganssle.com) is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack click here .