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.
EMBER • www.ember.com
FREESCALE • www.freescale.com
MICROCHIP • www.microchip.com
SENTILLA • www.sentilla.com
TEXAS INSTRUMENTS • www.ti.com