[Tinyos-devel] the MPS430 sleep model and start/stop behavior

Joe Polastre joe.polastre at gmail.com
Sun Feb 27 00:55:19 PST 2005


PS: The stop() mechanism in HPLCC2420M calls disableSPI() which
removes reliance on the high speed oscillator since the SPI bus is
shut down.

Also, I'm happy to remove the StdControl interface from CC2420RadioC
if you think that it would "solve" your problem.

> Neither does HumidityM which
> seems to take 80ms to warm up.

What does HumidityM have to do with anything?  It uses SplitControl
and the microcontroller (on MSP430 platforms) sleeps while the Humdity
sensor is warming up (the Humidity sensor only consumes a few
microamps while warming up, so I absolutely do not see the problem at
all).

> BTW, I notice that the high level CC2420 interface uses SplitControl
> while the lower level uses StdControl. Is the new standard a mixture? is
> it going to be SplitControl all the way? or is it going to stay
> StdControl with the existing SplitControl instances remaining as
> aberrations?

For things that are split phase, they will use SplitControl.  For
those that are not, they will use StdControl.  This has been
thoroughly discussed on the TinyOS 2.x mailing lists, and its clear
that any StdControl interface can easlily be wrapped to a SplitControl
interface using generic components.

-Joe


On Sat, 26 Feb 2005 23:07:07 -0800, Yuval Peduel
<yuvalpeduel at digitalsun.com> wrote:
> Joe Polastre wrote:
> 
> >Just as a side note--The MSP430 model is to go to sleep whenever the
> >node is not processing (task queue is empty) and the hardware module
> >flags indicate that the high speed oscillator is not in use.  There is
> >no HPLPowerManagement component for the MSP430 (just a dummy empty
> >component for compatability reasons).  Each module removes its use of
> >the high speed oscillator with its "stop" command.  This approach
> >seems to be very effective; however, it assumes that the transition
> >time from sleep to active is extremely low which is not the case for
> >many microcontrollers (ARM, Atmel, etc)
> >
> >
> 
> I'm missing something. My understanding was that the Telos platform is
> using both the MSP430 and the CC2420 radio. The latter does not
> transition quickly from sleep to active. Neither does HumidityM which
> seems to take 80ms to warm up. Also, I checked the HPLCC2420M code and
> did not see a mechanism by which the stop() method signals that it isn't
> using the the high speed oscillator. What am I missing here?
> 
> BTW, I notice that the high level CC2420 interface uses SplitControl
> while the lower level uses StdControl. Is the new standard a mixture? is
> it going to be SplitControl all the way? or is it going to stay
> StdControl with the existing SplitControl instances remaining as
> aberrations?
> 
> (I was shocked when an app that worked on the CC1000 stack failed to
> work on the CC2420 stack because the StdControl.start() interface left
> the CC2420 stack in the WARMUP_STATE (which caused the first send() to
> fail) rather than in the IDLE_STATE. I thought the whole point of
> interfaces was to avoid requiring the user to know what is going on
> underneath. So is the CC2420RadioM implementation of the StdControl
> interface to be considered compliant or a bug?)
> 
> TIA.
> 
> >-Joe
> >
> >
> >On Fri, 25 Feb 2005 09:43:23 -0800, David Gay <dgay42 at gmail.com> wrote:
> >
> >
> >>On Fri, 25 Feb 2005 00:13:49 -0800, Yuval Peduel
> >><yuvalpeduel at digitalsun.com> > 1. Do we really want the power control
> >>routine to know the details of
> >>
> >>
> >>>the ADC hardware implementation, completely ignoring the ADC driver
> >>>hierarchy, as the HPLPowerManagementM.nc code currently does? The idea
> >>>that the ADC registers are touched in multiple pieces of code scares me
> >>>and creates what can only be a maintenance nightmare.
> >>>
> >>>
> >>Clearly no. My general thought has been that the various components
> >>with power management needs should keep the power management component
> >>informed of the lowest power-level they currently allow. This is
> >>clearly a somewhat atmel-specific approach (it assumes an ordering of
> >>power levels), but then again, the code knowing this kind of thing,
> >>and the power management system itself would always be
> >>platform-specific anyway.
> >>
> >>David
> >>_______________________________________________
> >>Tinyos-devel mailing list
> >>Tinyos-devel at Millennium.Berkeley.EDU
> >>http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel
> >>
> >>
> >>
> >_______________________________________________
> >Tinyos-devel mailing list
> >Tinyos-devel at Millennium.Berkeley.EDU
> >http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel
> >
> >
> >
> 
>


More information about the Tinyos-devel mailing list