Intel and other companies are forecasting a single chip with 1000 cores. Programming these chips will be a challenge, but there is another arena with similar challenges. Cores are proliferating in the wireless sensor and control arena, with 802.15.4 being the underlying protocol of choice.
Wireless chip vendors like Ember, Freescale, and Texas Instruments are churning out an array of options that often incorporate a compact 8-, 15-, or 32-bit core to handle communication with plenty of headroom left over for applications. Developers of single- chip multicore and distributed, wireless systems must reduce power consumption while considering issues like communication, programming syntax, and semantics.
Granted, the scope and approaches taken to address the problems for both arenas tend to be very different, but there are similarities as well. For example, the programming frameworks being developed are designed to minimize a programmer’s work while effectively using a large number of cores at the same time.
TINY CORES Most 802.15.4 nodes consist of one or two microcontrollers. In nodes with two microcontrollers, one microcontroller is dedicated to communications, while the other handles local processing chores. Typically, the communications chores address higher-level protocols such as ZigBee, alleviating much of the communication programming work.
There is a host of protocols built on 802.15.4, such as Microchip’s proprietary MiWi. They’re often simpler to use, and they may have more limited functionality than something like ZigBee though many provide mesh networking support. The processor cores tend to be tiny to reduce power consumption and extend battery life. But more often, the large savings comes from shutting down the system or at least going into a lower-power sleep mode.
This is where multicore chips differ significantly from our wireless network of cores. In multicore chips, the desire is to keep all the cores working. Most multicore chips used in servers and desktops are based on symmetric multiprocessing (SMP). Embedded applications take advantage of asymmetrical multiprocessing (AMP) architectures, but they tend to be designed for targeted applications versus generic platforms like the SMP systems.
Unfortunately, SMP systems do not always scale well. Many of the newer multicore systems employ architectures where communication control is a major aspect of the hardware and software design. This includes architectures such as IBM’s Cell processor (see “CELL Processor Gets Ready To Entertain The Masses” at www.electronicdesign.com, ED Online 9748) or the graphics processing unit (GPU) from AMD FireStorm or NVidia’s Tesla (see “What Will You Do With 1 TFLOPs Of Double-Precision Power?” ED Online 19324) where data management is critical.
Of course, there is always more than one way of doing things on these multicore marvels. That’s true with wireless nodes as well.
SMALL SOFTWARE SUPPORT ZigBee is has garnered the most mindshare to date, and its various profiles are being utilized in a variety of applications. One of its advantages is that nodes can support one of these profiles and other nodes can control or query it. That’s great, as long as the application can be properly addressed within the confines of the profiles. Taking communication past this point requires programming, and that’s where things can become more interesting.
A different approach is to use a programming framework, preferably one that is well supported. That’s what Sentilla has done with its Mini mote. It runs a Java virtual machine ( JVM) that fully complies with CLDC 1.1, including support for up to 64-bit double-precision floating point. Even running on the 16-bit TI MSP430, the JVM provides 6 kbytes of heap space and 64 kbytes of code space.
Coming up with a compact JVM is an impressive exercise. However, the primary benefit is the ability to run on the same Java application on the mote or on other platforms. Moving parts of an application between platforms becomes significantly easier, and having a consistent communication protocol enables developers to more easily handle the remote as well as management application. Likewise, the toolset can be the same. This includes the debugging and test support.
Using Java also gives developers access to standard class definitions, though the memory limitation doesn’t allow developers to pull in every tool they may have used on a PC platform. Extracting support for an existing class is often easier than starting from scratch. Still, the limited memory space will typically mean a custom application anyway.
A lot of developers will be comfortable with the Eclipse-based Sentilla Work integrated development environment (IDE). Eclipse, one of the better-known Java development platforms, can download applications over the air. These applications can run as Java Isolates that are sandboxed for better security. Also, 128-bit AES encryption and authentication is supported.
Java brings a host of communication protocols to the 802.15.4 table, so it will be interesting to see how the Mini makes out. One key difference between this approach and most others is Java’s ability to span platforms from these tiny platforms through enterprise servers.
Reprints
