[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Meeting 8/31

[Joe Polastre]

Rob and I are in Germany (with very bad phone and Internet access); I
believe Martin's email said he was in Asia.  Since that's half of the
power management group, seems like you should postpone to next week.

-Joe

On 8/30/05, Philip Levis <pal at eecs.berkeley.edu> wrote:
> Wednesday, August 31, 2005 11:00 AM US Pacific Time  Where: 8-356-2663,
> 916-356-2663, Bridge: 1, Passcode: 3967115
> 
> 1-888-875-9370 (US non-intel employees)
> 0-800-1000-104 (Germany)
> 
> Agenda:
> 
> 1) Pre2 release cheer (hopefully)
> 2) Try to write a paper for NSDI?
> 3) Status: serial stack, CC2420/micaZ, etc.
> 4) Power management discussion
> 
> Is there anything else people would like to discuss?
> 
> This is the message I sent out to the power management subgroup (did
> I miss someone? some part of me thinks Vlado might have been in the
> subgroup? I forget):
> 
> *****************
> 
> From:       pal at eecs.berkeley.edu
> Subject:     2.x power management
> Date:     August 28, 2005 5:13:59 PM PDT
> To:       rob at moteiv.com, mturon at xbow.com, lama.nachman at intel.com,
> culler at eecs.berkeley.edu
> 
> The current proposal on the table involves a hybrid solution, where
> the platform computes its best guess at a low power state based on
> hardware configuration, but components can override this with a
> 'latency' specification. I think that there's no reason we can't
> unify these two, where the latency specification is merely an input
> to the platform (another piece of state it considers).
> 
> This means that, the power state of the MCU is implicit, based on the
> power state of all of the peripherals and the specified maximum
> wakeup latency. So, you'd see something like this:
> 
> RadioControl.off();
> TempControl.off();
> StorageControl.off();
> LatencyControl.maxWakeup(1000); // I'm guessing us is the parameter,
> so 1 ms here
> 
> Then the platform does something like it does today:
> 
> inline void TOSH_sleep() {
>    // The LPM we can go down to depends on the clocks used. We never go
>    // below LPM3, so ACLK is always enabled, also TimerB clock source
>    // is assumed to be ACLK.
>    // We check MSP430's TimerA, USART0/1, ADC12 peripheral modules if
> they
>    // use MCLK or SMCLK and switch to the lowest LPM that keeps
>    // the required clock(s) running.
>    extern uint8_t TOSH_sched_full;
>    extern volatile uint8_t TOSH_sched_free;
>    __nesc_atomic_t fInterruptFlags;
>    uint16_t LPMode_bits = 0;
> 
>    fInterruptFlags = __nesc_atomic_start();
> 
>    if ((LPMode_disabled) || (TOSH_sched_full != TOSH_sched_free)) {
>      __nesc_atomic_end(fInterruptFlags);
>      return;
>    } else {
>      LPMode_bits = LPM3_bits;
>      // TimerA, USART0, USART1 check
>      if ( (((TACCTL0 & CCIE) || (TACCTL1 & CCIE) || (TACCTL2 & CCIE))
>           && ((TACTL & TASSEL_3) == TASSEL_2))
>        || ((ME1 & (UTXE0 | URXE0)) && (U0TCTL & SSEL1))
>        || ((ME2 & (UTXE1 | URXE1)) && (U1TCTL & SSEL1))
> #ifdef __msp430_have_usart0_with_i2c
>        // registers end in "nr" to prevent nesC race condition detection
>        || ((U0CTLnr & I2CEN) && (I2CTCTLnr & SSEL1) &&
>            (I2CDCTLnr & I2CBUSY) && (U0CTLnr & SYNC) && (U0CTLnr & I2C))
> #endif
>        )
>        LPMode_bits = LPM1_bits;
> #ifdef __msp430_have_adc12
>      // ADC12 check
>      if (ADC12CTL1 & ADC12BUSY){
>        if (!(ADC12CTL0 & MSC) && ((TACTL & TASSEL_3) == TASSEL_2))
>           LPMode_bits = LPM1_bits; // TimerA for ADC12
>        else
>          switch (ADC12CTL1 & ADC12SSEL_3){
>            case ADC12SSEL_2: LPMode_bits = 0; break;
>            case ADC12SSEL_3: LPMode_bits = LPM1_bits; break;
>          }
>      }
> #endif
>      LPMode_bits |= SR_GIE;
>      __asm__ __volatile__( "bis  %0, r2" : : "m" ((uint16_t)
> LPMode_bits) );
>    }
> }
> 
> with some additional conditions to make sure it doesn't go beyond the
> latency.
> 
> This is the HIL layer: there can certainly be HAL abstractions that
> provide more fine grained control, but they are understandably
> hardware-specific. With these mechanisms, one can create higher-level
> policies. E.g., a service distribution could have a component
> SensorPower, which with a single call to StdControl turns on/off ALL
> of the sensors in the system.
> 
> What are people's opinions on this approach?
> ******
> 
> Phil
> 
> -------
> 
> "We shall not cease from exploration
> And the end of all our exploring
> Will be to arrive where we started
> And know the place for the first time."
> 
> - T. S. Eliot,  'Little Gidding'
> 
> 
> 
> 
> Phil
> 
> -------
> 
> "We shall not cease from exploration
> And the end of all our exploring
> Will be to arrive where we started
> And know the place for the first time."
> 
> - T. S. Eliot,  'Little Gidding'
> 
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>


_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg