[Tinyos Core WG] Meeting: 6/17

Wed Jun 17 09:24:58 PDT 2009

Some links:

Current version of the VCS poll form:
http://spreadsheets.google.com/viewform?hl=en&formkey=cnUwTWJKMHNZeFJ3UTlOV2FLdFU5NlE6MA

Instructions for installing the latest CVS mspgcc version with the MSP430X
support:
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Linux_installation_(MSP430X)

The TEP112 aggregated comments by Prabal:

--------- Janos Sallai ---------

Just one issue I stumbled upon recently: Currently, it is not possible
to write a piece of code in a platform-independent manner that assures
that the mote never goes to sleep (unless I keep posting tasks). The
"every subsystem is on" power state is common to all MCUs, so it would
be nice if this power state could be requested by
McuPowerOverride.lowestState() without using the platform-specific
enums. This could be done, for instance, by requiring that all platforms
provide a POWER_IDLE enum, which corresponds to the "every subsystem is
on" power state.

--------- David Moss ---------

"For example, the MSP430 defaults to low power mode 3 (LPM3) unless it
detects that Timer A, the USARTs, or the ADC is active, in which case it
uses low power mode 1 (LPM1)."

There's a problem with this wording and implementation. If all timers are
inactive, the MSP430 implementation should default to LPM4. This saves you
~5-10x more energy than LPM3.

Two reasons:  1. TinyOS is a generic operating system that doesn't require
Timers to operate.  2. Wake-on Radio.

Here are a few applications that use LPM4:

http://focus.ti.com/lit/an/slla175/slla175.pdf
http://focus.tij.co.jp/jp/lit/an/slaa384/slaa384.pdf
http://www.gaw.ru/pdf/TI/app/msp430/slaa119.pdf

Yes, it takes the microcontroller longer to wake up that crystal in LPM4.
Whether you care or not depends on the end application.  For wake-on radio
type applications, I don't care. For a TV IR remote or interrupt-driven
system, I don't care. I just want the microcontroller in the lowest power
state possible, which is LPM4.  For other applications that need a faster
response time for an external interrupt while no timers are running anywhere
in the application, the McuPowerOverride interface is available and
documented.

--------- Neil Hancock ---------

The general discussion on Power Management is good to see, and the
discussion on how to manage the general power state of the CPU is relatively
straightforward.

TEP112 really deals with a narrow aspect of CPU power mode, it doesn't
consider the wider issues in both a "System" -CPU and peripherals, both
onchip  and off-chip.

The following areas I think could do with a mention, and I don't know how
you collect information on this.

Power is drawn by hardware, and every subsystem is now going to be able to
be powered down when it is not used - or never powered up to begin with.
This is fundamental aspect of hardware.

I would have thought a generic subsystem interface that controls this be
defined.
Within in that subsystem there could be pre-allocated entrees for a specific
hardware.
So there could be 'X' entries for standard subsystems eg eg UART, TIMER
PwrMngUART_1, _2 ... _4 and hence extensible to say _8
PwrMngTWI_1, ..
PwrMngSPI_1
PwrMngTIMER_1,  _2 ..
For example of one hardware see "Minimizing Power Consumption" ATmega256
manual, but the fundamentals are the same whether its implemented on a PC or
any other uP.

Power, especially in motes is likely to be a finite resource, so there could
be a reference to when a low power state needs to be forced. That is
available power is low (batteries down) and some sort of reduced activity
needs to be mandated on the system.

--------- Vlado Handziski ---------

Traditionally the 32khz timer (timerB) on the msp430 platforms has been kept

always running, hence this long standing convention to default to LPM3. We
can definitely remove this sentence from the TEP. The removal of the actual
default LPM3 in the getPowerState() implementation will be done once the
timer arbitration refactoring is completed, i.e. after the 2.1 release.

--------- Prabal Dutta ---------

Rodrigo Fonseca and I worked on an energy profiler that traced the
power states of individual hardware components.  This sort of thing
was done in PowerTOSSIM and Adam Dunkel's recent work on software
energy profiling.  In our approach, we defined the "PowerState"
interface and provided a generic component that implements it.
A device driver merely declares that it uses this interface and
signals hardware power state changes through its simple calls.
Multiple calls to the "PowerState" interface signaling the same
state are idempotent: such calls do not result in multiple
notifications to the OS.  This approach eliminates state tracking in
many device drivers.  Our version of the "PowerState" interface looks
like:

interface PowerState {
  // Sets the powerstate to value.
  async command void set(powerstate_t value);

  // Sets the bits represented by mask to value.
  async command void setBits(powerstate_t mask,
    uint8_t offset, powerstate_t value);

  // Sets the bits corresponding to mask to 0.
  async command void unsetBits(powerstate_t mask);
}

Supporting this in a device driver could be as easy as the following
example illustrates for the LED (or much harder for the radio or flash).
The modified LED driver intercepts calls to turn the LED on and off and
signals this state change through the PowerState interface.

uses PowerState as Led0PowerState;
uses PowerState as Led1PowerState;

async command void Leds.led0On() {
  call Led0PowerState.set(1);
  call Led0.clr();
}

async command void Leds.led0Off() {
  call Led0PowerState.set(0);
  call Led0.set();
}

Each platform would define the set of the subsystems that exported their
power states.  This sort of support can allow some very interesting
energy profiling (both software-based and hardware-based).  E-mail me or
Rodrigo for more details.

--------- Prabal Dutta ---------

Some of the author addresses should be updated:
1. Moteiv -> Sentilla
2. Arched Rock -> Arch Rock

On Wed, Jun 17, 2009 at 06:19, Philip Levis <pal at cs.stanford.edu> wrote:

> Wednesday, June 17, 2009, 09:30 AM US Pacific Time
>
> Bridge: 4
> Passcode: 7117452
>
> US: 1-916-356-2663 or 1-888-875-9370 (non-Intel)
> UK: +44 1793 402663
> Denmark: +45 4527 5090
> Germany: +44 01793 402663 (Munich) +44 01793 402663 (Braunschweig)
>         +44 01793 402663 (Ulm)
>
> Agenda:
>
> Status
>   TOSSIM (Phil)
>   RCS poll (Vlado)
>   msp430-gcc (Vlado)
> TEP 112 discussion (Vlado, Phil, Prabal)
> 2.1.1 planning (all)
> Message use case (Miklos, Vlado)
>
> Phil
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20090617/4606167d/attachment.htm 