2.Of all threads executing a Thread.sleep() it determines which will resume soonest. If the sleep interval is less than the minimum deep sleep time it shallow sleeps.
3.If the sleep interval is at least the minimum deep sleep time and deep sleeping is enabled, it sends a request to the SleepManager thread.
4.The SleepManager checks whether the Sun SPOT is connected to USB. If it is, a shallow sleep is performed.
5.The SleepManager requests each driver to “tear down”, saving any state that must be preserved into RAM and releasing any resources such as interrupt lines and PIO pins it has acquired from other drivers. Finally, each driver returns a status indicating whether it was able to do this successfully. If any driver failed, all drivers are reinitialized and a shallow sleep is performed.
6.If all drivers succeed, a deep sleep is performed. The low level firmware is programmed to wake the Sun SPOT up at the requested time and main power is turned off.
When the firmware restores main power to the Sun SPOT it resumes execution of the Java VM. The SleepManager then requests each driver to reinitialize its hardware using the state it stored before deep sleeping. Finally, the SleepManager does a brief shallow sleep until the end of the allotted driver wake up time allowance and resumes execution of the user program. The deep sleep appears to be transparent, except that external events such as radio packets arriving may have been missed during the deep sleep.
Writing a device driver
In deep sleep mode the CPU will not be able to receive interrupts from peripherals. Furthermore, the peripherals themselves are switched off, so they cannot detect external events or trigger interrupts. Only the low level firmware's real time clock continues to operate, allowing the Sun SPOT to wake up after a predetermined interval. Therefore, if the Sun SPOT deep sleeps it could miss external events unless drivers are written appropriately.
If you write your own device driver and you want to support deep sleep your driver must implement the IDriver interface. This has two methods “tearDown” and “setUp” which will be called indirectly by the SleepManager when the Sun SPOT deep sleeps and wakes, respectively. The tearDown method should only return true if the driver approves the request to deep sleep. A driver also has a method “name” that is used to identify the driver in messages to the user. The Sun SPOT has a DriverRegistry with which the driver should register itself with in order to participate in the tear down/set up sequence. A simple example of a confirming driver can be found in the class com.sun.spot.peripheral.Led. Note that this class is not public and hence in not described in the javadoc but its source can be found in <sdk>/src/spotlib_source.jar.
One constraint on device driver authors is that device drivers may receive interrupts while processing tearDown and setUp. The radio driver handles this by vetoing deep sleep unless an application has previously disabled the radio and consequently its interrupts. An alternative strategy is to turn off interrupts at the beginning of tearDown, and reenable them at the end of setUp.
It can prove difficult to debug tearDown() and setup() methods as these are only normally invoked when the USB port is not connected to a host computer, which means that diagnostic messages cannot be seen. To overcome this method, you can execute code like this:
Spot.getInstance().getSleepManager().enableDiagnosticMode();
The effect of this will be that the SleepManager will go through the full process of tearing down even though USB is enumerated. It will then enter a shallow sleep for the requisite period, and then set up the drivers as though returning from deep sleep.
40