In order to write applications for Sun SPOTs it is first important to understand the SPOT system architecture.
Here is a traditional stack diagram for the software running on a free-range SPOT:
At the top is the user-written SPOT application, which extends the Java ME MIDlet class.
At the bottom is the Squawk JVM. There is no operating system; Squawk runs on the bare metal.
In between are the various SPOT libraries. Access to the SPOT device and basic I/O is provided by SPOTlib. This includes access to the low-level MAC radio protocol.
The multihoplib provides higher-level radio protocols, such as Radiogram and Radiostream, and also takes care of the routing of packets to SPOTs not in direct contact with this one.
The transducerlib provides a way to access the hardware on the SPOT eDemo sensor board, e.g. the accelerometer, LEDs, switches, digital I/O, analog inputs, etc.
Here is the stack diagram for a SPOT host application and how it connects to a SPOT basestation:
Again at the top is the user-written host SPOT application, which is just a regular Java SE program. It can do everything a regular Java application can do: file I/O, display Swing GUI's, etc. It can also send and receive radio messages with free-range SPOTs if a basestation is connected to the host computer.
At the bottom is the host operating system: Linux, Windows, Mac OS X or Solaris.
Just above the OS is a Java SE JVM along with all the regular Java class libraries.
In between are the various SPOT libraries. Access to the SPOT device and basic I/O is provided by the host version of SPOTlib. This includes access to the low-level MAC radio protocol, which either uses the USB connection to access the basestation's radio, or uses socket connections to communicate with other host applications.
The multihoplib again provides higher-level radio protocols, such as Radiogram and Radiostream, and also takes care of routing of packets.
The spotclientlib gives access to a number of OTA (over-the-air) commands that can be sent to a free-range SPOT. This includes the "Hello" command used to discover SPOTs within radio range.
The rxtx library is used to perform serial I/O over the USB connection to the basestation.
Note that Solarium and all of the SPOT SDK ant commands are SPOT host applications.
The basestation provides a way for host applications to communicate with free-range SPOTs by using the basestation's radio.
Note that the host application runs solely on the host computer; no user code runs on the basestation. Packets to send are sent via USB to the basestation, which then sends them out over its radio. Likewise when the basestation receives a radio packet it forwards it to the host application.
When using a shared basestation there is no user program deployed to the SPOT, instead the Basestation class in the SPOT library is run. "Radio" packets received from other host applications (via a socket connection) are relayed to free-range SPOTs using the basestation's radio.
When you create a new virtual SPOT in Solarium, a new process is started to run the emulator code in a Squawk VM. The emulator code communicates over a socket connection with the virtual SPOT GUI code in Solarium. For example when the SPOT application changes the RGB value of an LED that information is passed to the virtual SPOT GUI code that updates the display for that LED with the new RGB value. Likewise when the user clicks one of the virtual SPOT's switches using the mouse, Solarium sends a message to the emulator code that the switch has been clicked, which can then be noticed by the SPOT application.
Here's a stack diagram of the Emulator architecture:
Each virtual SPOT has its own Squawk VM running in a separate process on the host computer. Each Squawk VM contains a complete host-side radio stack as part of the SPOT library, which allows the SPOT application to communicate with other SPOT applications running on the host computer, such as other virtual SPOTs, using sockets or real SPOTs via radio if a shared basestation is running.