[Tinyos-host-mote-wg] [Tinyos-2.0wg] Meeting 8/31
Philip Levis
pal at eecs.berkeley.edu
Tue Aug 30 09:22:19 PDT 2005
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
More information about the Tinyos-host-mote-wg
mailing list