Filter
Top Products
24
Developing and debugging Sun SPOT
applications
Overview of an application
A Sun SPOT application is actually implemented as a MIDlet. This should not concern most
developers greatly: the simplest thing is to copy a template, as described above, and start editing the
copy. The most significant implications of this are covered in the section Manifest and resources.
The Sun SPOT application runs on top of a number of other software components within the Sun
SPOT. These include
• a bootloader (which handles the USB connection, upgrades to the SDK components,
launching applications, and much of the interaction with ant scripts).
• a Config page (containing parameters that condition the operation of the bootloader).
•
a Squawk Java VM (The Squawk VM is the Java virtual machine that runs on the Sun
SPOT. For more details, go to http://research.sun.com/projects/squawk/).
• a bootstrap suite (containing the standard JME Java classes).
• a library suite (containing the Sun SPOT-specific library classes).
The operation of these will generally be transparent to application developers.
Threads
Developers should also be aware that a number of background threads will be running as a result of
using the Sun SPOT libraries. These include various threads which manage sleeping (limiting
power use where possible), monitor the state of the USB connection, and threads within the radio
communication stack. All of these threads run as daemon threads.
One other thread to be aware of is the OTA command server thread: see section Remote operation.
This thread may or may not be running according to the configuration of the Sun SPOT, but if it is,
it will inhibit applications from exiting normally even after all user threads have stopped running.
Thread priorities
Through the standard contract of the Thread class, Squawk allows threads to be assigned priorities
in the range Thread.MIN_PRIORITY (1) to Thread.MAX_PRIORITY (10). Special interfaces
allow threads to be given higher priorities known as "system priorities", but these are not intended
for application use.
These rules should be adhered to by application developers to ensure correct operation of the
libraries:
1. Applications should not use system priorities. If they do, the library may not work.
2. Application threads that are compute-bound should run at a lower priority than
Thread.NORMAL. Otherwise they may interfere with the correct operation of the library.
3. Application threads at Thread.MAX_PRIORITY will not normally compete with any library
threads, which all run at lower priorities except as detailed below. Note that if library
threads are prevented from running then library operation may be affected. In particular, this
may either degrade radio performance or cause incoming broadcast traffic to be missed.