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

Yuval Peduel yuvalpeduel at digitalsun.com
Sun Feb 27 19:39:09 PST 2005


Joe Polastre wrote:

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

>Also, I'm happy to remove the StdControl interface from CC2420RadioC
>if you think that it would "solve" your problem.
>  
>
I was asking about standards. Is the current implementation of the 
StdControl interface on CC2420RadioC considered compliant? If it is, 
then there is no reason to touch it. If it isn't, then it should either 
be fixed or removed.

As for my "problem" I've already had to modify my code to handle the 
split control so whatever you do is too late for me. On the other hand, 
there are lots of others who will be wanting to use your code so I hope 
you do something to make it clearer how it should be done, as well as 
easier to do.

>>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).
>  
>
No problem. Again, I thought you were referring to the sleeping and 
waking of the entire system rather than just the processor. Seeing that 
HumidityM doesn't wake up quickly confused me, which is why I included 
it in my question.

I don't use the MSP430; I know nothing about it; and responded to your 
message only because it seemed you were offering another model for 
handling system power reduction for sleep. Since you are only dealing 
with the processor, the MSP430 model seems much less interesting.

David Gay noted that power management is, of necessity, a 
platform-specific task. At the lowest level, he is clearly correct. 
However, I am hoping that there is some way to standardize how sleep 
readiness and sleep/wakeup constraints get communicated within each 
system so that we don't need to implement separate versions of every 
module for every platform.

Perhaps this is just a pipe dream, but as this group is supposed to be 
addressing a major cleanup of TinyOS for rev 2, this seemed a good place 
to ask.

>>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,
>
Good. But I'm a newbie to this list. Am I allowed access to the 
archives? The message I got from Kristin Wright said:

>After invoking the silence-infers-agreement rule regarding yesterday's
>mail (below), tinyos-devel at mail.millennium.berkeley.edu is now
>officially open and public. Anyone can join tinyos-devel and the
>archives are private.
>
so if they are private, it isn't clear that I do have access.

If I do, could you please point me to the archives and give me some idea 
of when this was discussed?

> and its clear
>that any StdControl interface can easlily be wrapped to a SplitControl
>interface using generic components.
>  
>
I agree that generic components should make the adaptation easy, but you 
write as if we already have generic components. I thought they were to 
be included in NesC 2.x but that they haven't been released yet; that 
NesC 1.1.3 is the latest. Am I missing something here?

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