[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] TinyOS Telecon Notes 8/31/05

Wed Aug 31 14:24:51 PDT 2005

Skipped content of type multipart/alternative-------------- next part --------------
Present: Vlado Handziski (TU Berlin), Phil Levis (Stanford), Martin
Turon (XBow), Ben Greenstein (UCLA) 

Notes from 8/31/05 TinyOS Working Group

Agenda:

1) Power management discussion
2) Pre2 release cheer (hopefully)
3) Status: serial stack, CC2420/micaZ, etc.
4) Try to write a paper for NSDI?

--------------------

Power Management

Vlado: The sleeping patterns of the MCU and of peripheral components
are on different timescales from one another. We therefore need two
different power mgmt. drivers.

Phil: I agree. It should take something like 60-80 cycles to compute
the power state of the mcu. Let's consider the notion of a dirty
bit. If anything changes in the power state, the dirty bit isset. The
MCU goes into same state as the last time unless this bit is set. When
set it recomputes. ... Is this notion something that would be usesful
for eyes?

Vlado: We never talked about fine grained control of power mgmt. of
external flash.

Martin: i don't think we should notify above the HAL.

Phil: The scheduler is where the work would be done.

Martin: A component could ask the scheduler to give a HAL-level
notification. If I am a platform developer, then I would have to
develop my own scheduler; i might not. And even if I do, this is
dangerous

Phil: Developing a platform isn't simple. So it is reasonable to
expect a platform developer to write a new scheduler, perhaps mostly
by cut-and-paste.

Vlado: i agree with martin that this is a platform level decision

Martin: what if the platform designer decides to hook external flash
to the power down mechanism, what if i don't want it?

Phil: the platform is the only thing for which you have one and one
only and is where you make unilateral decisions.

Vlado: How large is this logic about what to turn on and off?

Phil: Small. It has to be signalled in an atomic section.

Vlado: How do we do it?

Phil: The scheduler signals an event saying 'going to sleep' or
'turning on'. The default implementations are nothing. something in
the platform can wire to the events and do what is needed and this
should be very short code. If someone puts bad code there, people will
notice.

Martin: Couldn't sleep code be put in the same hook?

Phil: everything concerning MCU state would be in this hook. ... We
shouldn't rush into interfaces on this. Maybe it would be best to take
another month on it. I'd like to guide this disussion towards
developing general principles. It is premature to start writing
specific interfaces.

Phil: There are a couple of language things you can do to prevent
people from wiring to the hook arbitrarily.

Ben: How complicated should the power mgmt logic be?

Phil: The computation should not outweigh the gains of performing that
computation.

Ben: how do we allow applications to override system power mgmt. behavior?

Vlado: Application overrides rrequire a complete power profile.

Phil: The application can indicate a maximum latency to scheduler. 

Vlado: We should allow the application to override

Martin: Would be nice to do this outside of atomic state.

Phil: can't have chips, platforms and applications all with power
mgmt policies.

Ben: It seems we have one variable that applications may use to guide
power management: maximum latency. And we may have a matrix of maximum
latencies for every software component and every peripheral under the
control of the power manager. Ideally we need to provide this level of
control, but clearly we need to simplify the mechanism.

--------------------

Other news:

Phil: Looks like pre2 went out. Three cheers!

Phil: Will send out serial TEP that Ben and I have written.

Phil: Got cc2420 stack working on micaz. Still have some work on that.

Vlado: we have a guy to replace Kevin to work on the radio stack to
get eyes 2.0 compliant.

Phil: Paper for NSDI? Abstract and title due 10/10. Paper (12-14pgs)
due 10/17.

Ben: Sounds good. Need to harden the power management story.

--------------------

Addendum to power management discussion (Martin):

My main focus was regarding the platform layer notification, with
specific focus on the flash as an example.

On the micaz, I would like to link the flash power pin to the MCU
sleep.  I want the flash to be on and available when the processor is
awake, and off when it is asleep.  I could see this being the case
with an on-board thermister and other peripherals as well that have
minimal (assume zero) latency issues (GPIO voltage over single
resistor to ground.)

While the timeout strategy we discussed as a good solution for sensors
and application-level management can work for the external flash, it
isn\u2019t ideal.  On my platform, the flash power pin could draw
~300uA; I want sleep to be ~20uA.

So the suggestion we are pondering is adding a hook to the scheduler
that only the platform and chip HAL is allowed to intercept:

[scheduler]

while (1) {

          do tasks

          atomic {

              signal HALPwrMgr.sleep();

              __nesc_atomic_sleep();

}

          signal HALPwrMgrHook.wake();

}

[flash]

async atomic HALPwrMgr.sleep() {

    // this must be fast, responsible code \u2013 just flip one pin!

    call HPLFlash.PwrPin.clr();

}

async HALPwrMgr.wake() {

    if (flash_started) call HPLFlash.PwrPin.set();

}

[MCU]

async atomic HALPwrMgr.sleep() {

          // all those crazy register checks of timer and adc.

          // but implemented using HPL calls

}
-------------- next part --------------
_______________________________________________
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