Filter
Top Products
40
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.