At the 2006 Java One in San Francisco, Calif., in mid-May, Sun Microsystems revealed more details on a long-term wireless sensor effort it calls the Small Programmable Object Technology (SPOT) project.

The introduction was almost unnoticed amid the flurry of activity centered on the use of Java for providing multimedia services to cell phones and mobile platforms. However, Sun's innovative approach to designing virtual machines for wirelessly-connected controller devices and sensor networks is worthy of notice.

SPOT could have a profound influence on the way embedded systems developers build and deploy these VMs. It could also affect the nature of the underlying operating system, virtual machine and applications software used in resource-constrained environments.

On the hardware side, Sun Labs has come up with a prototype that consists of an approximately 3x5 inch board (see photo below) containing an ARM7 CPU, flash memory and SRAM, as well as an 802.15.4 Zigbee wireless radio chip. A variety of sensor plug-in cards can be inserted into this main board, including a sensor card incorporating a 3-axis accelerometer, a light sensor, a temperature sensor, two push buttons and three LEDs as well as nine general I/O lines.

This prototype of a Sun SPOT sensor can pick up light, motion, and temperature, and wirelessly transmit the information to another sensor or a computer.

On the software side, at the core of the SPOT wireless sensor platform is "Squawk", a small Java 2 Micro Edition (J2ME) virtual machine written almost entirely in Java. It has been designed to run wireless transducer applications "on the metal" - directly running on a 32-bit microcontroller without any underlying operating system. Theoretically, this should save memory overhead and improve performance, both important considerations in many resource-constrained embedded control designs.

Where most Java VMs run a single application, the Squawk VM is designed to run multiple applications, using an application isolation mechanism such that each application " called an isolate " maintains its own copy of its mutable, or modifiable, system state. Synchronization on shared immutable resources is tracked on a per-isolated-application basis so that the threads in one isolated app are managed as a group without affecting threads in another.

The Squawk VM reduces memory footprint by verifying class files in advance, eliminating the need for a class verifier within the VM. These pre-verified classes are bundled into what Sun calls "suites" for deployment. Each suite is optimized for the classes contained in each isolate, further reducing memory.

Each application isolate is represented by a Java object, which can be used to query the status of each application. Tools are available which allow the program to determine which isolates are running and their status, allowing the developer to manage an application: interrupting it, resuming it, or simply quitting the application.

One way of looking at the Squawk architecture is to think of it as a VM with a split personality. One personality is the execution engine and the other is a classfile preprocessor, called the translator. This second personality produces a more compact version of the input Java byte codes in which symbolic references have been resolved and local variables have been pre-allocated. A useful feature of this personality is that its operand stack is guaranteed to be empty for certain instructions whose execution may result in a memory allocation.

The effect of this is to greatly simplify garbage collection—each method requires just a single pointer map and eliminates the need to scan the operand stack.

The platform has features not available in remote sensor/controller applications written in C or C++, to wit:

For example, because the capabilities are built into the Java specification, using a purely Java approach means that developer of a wireless sensor application can write a program in Java, load it on a wireless sensor and remotely run diagnostics, instrument the code, debug and modify it. By accessing low-level mechanisms with standard Java IDEs such as NetBeans or Eclipse, wirelessly connected sensor devices can not only be monitored, but managed and upgraded in the field after deployment.

Also, the fact that the VM needs no operating system as an intermediary will be a big plus for many developers. In many constrained applications, an RTOS, particularly the commercial ones, are a hindrance rather than a help. They jack up the amount of memory and CPU resources that many distributed sensor designs can't handle.

Finally, if the work-around using "isolates" to avoid giving up garbage collection is workable in highly deterministic embedded applications, developers may not have to stray too far from the standard Java profiles with their many productivity enhancing features.

However, although this is an elegant way to create a VM that is sufficiently deterministic for embedded sensor and control apps without giving up Java's automatic garbage collection, I have some unresolved questions about SPOT.

First, unlike most other VMs the Squawk virtual machine is written in Java, rather than in C or C++. While this makes it much more platform independent, it would require more memory, although the Sun researchers who developed the prototype claim the VM and associated libraries require only 350 kBytes of RAM and flash, combined.

Second, Squawk is based on the J2ME virtual platform, which is neither real time nor deterministic and more appropriate for cell phones, unlike other VMs such as Aonix's PERC Ultra and PICO, aicas GmbH's Jamaica and IBM's OVM, which take their coding cues from the Real Time Specification for Java (RTSJ). This makes me doubt it has what it takes as far as applications that require deterministic interrupt response times.

My third reservation is Squawk's performance, which is roughly that of the J2ME-derived Java KVM introduced a few years ago, an interpreted JVM that is written in C. From everything I have learned about it, the developers are assuming that most applications for the SPOT platform will include processors of sufficient power and that large amounts of memory will be available for garbage collection, pointer safety, exception handling and a mature thread library for thread sleep, yield and synchronization. That is not true in many cases, and if SPOT is limited to only sensor applications that are not performance-constrained, the platform is interesting but not all that important in the long run.

Finally, there is the SPOT platform's approach to supporting interrupts and doing garbage collection, which while making programming easier and less error prone in Java, but play havoc with the ability to perform deterministic control operations, the bread and butter of many resource constrained embedded applications. Specifically, the Squawk VM supports interrupts written in Java, which results in an unpredictable latency due to the non-preemptible garbage collector borrowed from KVM and J2ME.

Soon to be available from Sun is a development and evaluation kit priced at $499. The kit includes three Sun SPOT hardware platforms: two standalone and one base station. Each platform is about the size of a 3x5 card with a 32-bit ARM9 CPU, 512 KB RAM and 4 MB of flash memory, a 2.4 GHz radio and a USB interface. The kit will also include a Java ME VM and the NetBeans 5.0 Integrated Development Environment.

The availability of such a platform could jumpstart further development in a wide range of distributed embedded sensor and controller applications and configurations, including medical monitoring, package tracking, swarm intelligence, and mesh networks.

I will be keeping an eye on potential applications of Java in memory- and CPU-constrained environments such as wireless remote sensor platforms. If you start developing applications using this platform or other similar ones, I would like to hear from you.

Embedded.com Site Editor Bernard Cole is also site leader on iApplianceweb and an independent editorial services consultant. He welcomes your feedback. Call him at 602-288-7257 or send an email to bccole@acm.org.