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
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
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.
24