Sun's SPOT, Squawk VM and wireless embedded sensor devices - Embedded.com

Sun’s SPOT, Squawk VM and wireless embedded sensor devices

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

The introduction was almost unnoticed amid the flurry of activitycentered on the use of Java for providing multimedia services to cellphones and mobile platforms. However, Sun's innovative approach todesigning virtual machines for wirelessly-connected controller devicesand sensor networks is worthy of notice.

SPOT could have a profound influence on the way embedded systemsdevelopers build and deploy these VMs. It could also affect the natureof the underlying operating system, virtual machine and applicationssoftware used in resource-constrained environments.

On the hardware side, Sun Labs has come up with a prototype thatconsists of an approximately 3×5 inch board (see photo below ) containing an ARM7CPU, flash memory and SRAM, as well as an 802.15.4 Zigbee wirelessradio chip. A variety of sensor plug-in cards can be inserted into thismain board, including a sensor card incorporating a 3-axisaccelerometer, a light sensor, a temperature sensor, two push buttonsand three LEDs as well as nine general I/O lines.

Thisprototype of a Sun SPOT sensor can pick up light, motion, andtemperature, and wirelessly transmit the information to another sensoror a computer.

On the software side, at the core of the SPOT wireless sensor platformis “Squawk”, a small Java 2 Micro Edition (J2ME) virtual machinewritten almost entirely in Java. It has been designed to run wirelesstransducer applications “on the metal” – directly running on a 32-bitmicrocontroller without any underlying operating system. Theoretically,this should save memory overhead and improve performance, bothimportant considerations in many resource-constrained embedded controldesigns.

Where most Java VMs run a single application, the Squawk VM isdesigned to run multiple applications, using an application isolationmechanism such that each application ” called an isolate ” maintainsits own copy of its mutable, or modifiable, system state.Synchronization on shared immutable resources is tracked on aper-isolated-application basis so that the threads in one isolated appare managed as a group without affecting threads in another.

The Squawk VM reduces memory footprint by verifying class files inadvance, eliminating the need for a class verifier within the VM. Thesepre-verified classes are bundled into what Sun calls “suites” fordeployment. Each suite is optimized for the classes contained in eachisolate, further reducing memory.

Each application isolate is represented by a Java object, which canbe used to query the status of each application. Tools are availablewhich allow the program to determine which isolates are running andtheir 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 aVM with a split personality. One personality is the execution engineand the other is a classfile preprocessor, called the translator. Thissecond personality produces a more compact version of the input Javabyte codes in which symbolic references have been resolved and localvariables have been pre-allocated. A useful feature of this personalityis that its operand stack is guaranteed to be empty for certaininstructions whose execution may result in a memory allocation.

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

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

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

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

Finally, if the work-around using “isolates” to avoid giving upgarbage collection is workable in highly deterministic embeddedapplications, developers may not have to stray too far from thestandard Java profiles with their many productivity enhancing features.

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

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

Second, Squawk is based on the J2ME virtual platform, which isneither real time nor deterministic and more appropriate for cellphones, unlike other VMs such as Aonix's PERC Ultra and PICO, aicasGmbH's Jamaica and IBM's OVM, which take their coding cues from theReal Time Specification for Java (RTSJ). This makes me doubt it haswhat it takes as far as applications that require deterministicinterrupt response times.

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

Finally, there is the SPOT platform's approach to supportinginterrupts and doing garbage collection, which while making programmingeasier and less error prone in Java, but play havoc with the ability toperform deterministic control operations, the bread and butter of manyresource constrained embedded applications. Specifically, the Squawk VMsupports interrupts written in Java, which results in an unpredictablelatency due to the non-preemptible garbage collector borrowed from KVMand J2ME.

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

The availability of such a platform could jumpstart furtherdevelopment in a wide range of distributed embedded sensor andcontroller applications and configurations, including medicalmonitoring, package tracking, swarm intelligence, and mesh networks.

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

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.