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

Joe Polastre joe.polastre at gmail.com
Sun Feb 27 00:49:46 PST 2005

You're missing some very major points:

1) I'm talking about the MSP430, not the CC2420.  My comments were
about the MSP430 going to sleep when no processing occurs (unlike the

2) The code in CC2420RadioM clearly states that StdControl.start() is
DEPRECATED and SplitControl is the only supported interface for the


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