Ubiquitous Computing
Ubiquitous Computing The Sensor Network System
Sun SPOT: The Sun Small Programmable Object Technology Technology-Based Wireless Sensor Networks a Java Platform for Developing Applications for Wireless Networks of Small Devices
SUN Vision: RFID Tags and Sensors
Structure of Sun SPOT Devices Basic device has three layers Battery Processor Board with Radio Sensor Board (application specific) Processor Board alone acts as a base-station devices are programmed entirely in Java using standard Java tools "Sunroof" Sensor Board Processor Board Battery
Sun SPOT Hardware 180 Mhz 32-bit ARM920T core, 512K RAM/4M ROM ChipCon 2420 radio, 2.4 GHz IEEE 802.15.4 USB interface 3.7V rechargeable 750 mah prismatic lithium ion battery 40 µa deep sleep mode, 40 ma to 100+ ma 64 mm x 38 mm Double sided connector for stackable boards
Demo Sensor (Actuator) Board 8 tri-color LEDs 3D accelerometer 5 general purpose I/O pins 4 hi current output pins 1 A/D converter Temperature sensor Light sensor
The Sun SPOT SDK Libraries Squawk Java VM: desktop and Sun SPOT Libraries Java ME CLDC 1.1 libraries Hardware libraries - SPI, AIC, TC, PIO drivers all written in the Java programming language - Demo sensor board library Radio libraries Network libraries - 802.15.4 MAC layer written in the Java programming language, uses GCF Desktop libraries
Sensor Network System The Squawk Java VM A Java Virtual Machine for Small (and Larger) Devices
The Squawk Java VM Java VM mainly written in the Java programming language Interpreter written in C Garbage collector translated from the Java to the C programming language Java ME CLDC 1.1 Extra features Runs on the bare ARM without an underlying OS Interrupts and device drivers written in the Java programming language Supports isolate application model
Standard Java VM vs. Squawk Java VM Standard Java VM Java Class Library Loader Verifier Garbage Collector Interpreter Java Code Squawk Java VM Java Class Library Loader Verifier Transformer Garbage Collector Interpreter Thread Scheduler Thread Scheduler Exporter Compiler Compiler Device Driver Architecture I/O Library Native Code C Code I/O Library Native Code Squawk is fully Java compliant and CLDC 1.1-compatible (i.e., it's Java ME).
Squawk The Squawk Architecture The Squawk VM is (mostly) implemented in the language that it executes (Java). Its components include: The class loader/bytecode translator The ahead-of-time bytecode optimizer The threading system (green threads) The garbage collectors (selected at build time): - Simple two space Cheney collector - Mark/compact "Lisp2" collector - Generational mark/compact "Lisp2" collector Squawk's design includes a compiler that can be used to: compile the core VM components ahead-of-time compile an interpreter written in Java ahead-of-time compile other Java components ahead-of-time compile bytecodes just-in-time (JIT compilation) continued
Squawk Other features of the Squawk architecture include: A compact bytecode instruction set Smaller than standard bytecode (35% - 45% size of equivalent J2ME class files) Fixed up/pre linked Immutable execute in place Simplified garbage collection: - local variables are partitioned into pointers and primitives only one pointer map per method - there is nothing on evaluation stack at operations that may result in an invocation no need to statically interpret methods during GC Suites A suite is a collection of classes. Each class in a suite only refers to other classes in the suite or to a class in a parent suite. That is, a chain of suites is a transitive closure of classes as shown below:
Squawk Suites A suite is a collection of classes. Each class in a suite only refers to other classes in the suite or to a class in a parent suite. That is, a chain of suites is a transitive closure of classes as shown below: The representation of classes in a suite is very compact as they are all prelinked to each other. On average, suites are one third of the size of class files. Once a suite is closed (i.e. cannot have any more classes loaded into it), it is immutable. An immutable suite can be saved to and loaded from a file. This results in a significantly reduced start up time when running an application from a suite (as opposed to a dynamically loaded set of classes).
Squawk Isolates An isolate is a mechanism by which an application is represented as an object. In Squawk, one or more applications can run in the single JVM. Conceptually, each application is completely isolated from all other applications. Given the immutability of suites, the isolate implementation in Squawk shares common suites between applications. This can significantly reduce the memory footprint of each application, which is particularly important in the embedded device space. In addition to the standard semantics of isolates, the Squawk implementation has one extra feature: isolate migration. That is, an isolate running on one Squawk VM instance can be paused, serialized to a file or over a network connection and restarted in another Squawk VM instance. This feature is a direct result of certain architectural choices made in Squawk such as using a green threaded model, representing all VM structures (including thread stacks) as objects and not implementing a general native code interface such as the JNI.
Isolate Application Model JSR 121: Application Isolation API Specification Application state is an object Isolate start -exit moveto resume -pause Every isolate has its own state for all static variables Allows for running multiple applications in one VM Inter-isolate communication Provides lower-level asynchronous message delivery Can migrate from one device to another
Squawk Squawk Application Requirements Space Consumer embedded apps. Mobile Phones Sensors Java Card Speed Most Simple Squawk Maximum Performance