[Tinyos-host-mote-wg] [Tinyos-2.0wg] 08/17/2005 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Wed Aug 17 14:38:40 PDT 2005
-------------- next part --------------
Notes from 08/17/2005 TinyOS 2.0 Working Group
Phil Buonnadonna (Arched Rock), David Gay (Intel Research, Berkeley),
Ben Greenstein (UCLA), Vlado Handziski (TU-Berlin), Phil Levis (Stanford),
Lama Nachman (Intel), Martin Turon (Crossbow), Kristin Wright (UCB)
08/17/2005 Agenda
-----------------
- Pre2 release1
- Next on Pre2
- Power management (Martin)
08/17/2005 Action Items
-------------------------
- kwright: post manual installation instructions
- phil: discuss phil writing the cc2420 stack w/David Culler
- lama: identify hw/app relationship where hw code cannot dicate
optimal power level
08/24/2005 Agenda
------------------
- Power management, cont'd
08/18/2005 Discussion Notes
----------------------------------------------------------
pre2 (release1)
---------------
- dgay: mica2 rpms are available; download set of tools, install and run;
we need How To Install -- can modify 1.x manual
and add classpath setting instructions and the like
- kwright: will write this afternoon
- dgay: Build a web page or write a document
- phil: critical part: give some information as to how to switch back
- dgay: in theory the tools work with 1.x
- vlado: can we add an option for allowing a different default platform
than avr? Having avr be the default requires that the avr tools
be installed because mig requires it; similar to the java jar
- dgay: make the default target 'null' so you don't have to install
unnecessary stuff; won't do it for pre-release1
but will for pre2.1 (or whatever it is)
- volunteers to test mica2:
ben: linux debian
martin: cygwin
phil: windows
dgay: kwright will do the writeup by tomorrow morning; everyone
then follow the writeup
What's next in pre2.1?
-----------------------
- dgay: need to add in the missing platforms (micaz, tmote, eyes)
main part: the two radio stacks
- vlado: unlikely to have a radio stack this month
(no person currently working on it);
hopefully somewhere in september);
- dgay: cc2420 in moteiv limbo
- martin: not familiar with status of code as is;
spi for micaz not thorougly tested, but based on 1.x code and
should work
- dgay: will have to find someone to work on it
- lama: imote team won't have anyone for next 2 months
possible that we can add to contract with arched rock
- dgay: cannot take anything new on until December
- phil: sense is that code mostly there but will take a week of work;
prabal has written a 2420 stack ; dgay has experience writing stacks;
phil going to try to do this.
- dgay: don't want to do it twice, talk to David Culler first
- phil: going to do it now. has two things on his plate: tossim 2.0
and cc2420 stack.
- dgay: talk to david culler when he gets back from vacation
- martin: phil, feel free to contact him; has various info that might
be useful
- tossim 2.0: phil
- dgay: sensorboards for pre2.1
- ucla sensorboard (dgay)
- micasb (crossbow)
- some sensor for eyes and each of other platforms.
- dgay: 2.x team not going to do all sensorboards.
- lama: is there a sensorboard interface defined?
- dgay: tep 109; linked from working group
- phil: separate because sensorboards are much more general than ADC;
some sensorboards don't even have ADCs.
- routing: phil
- storage:
- mica (dgay)
- jonathan (tmote)
- imote2 (lama)
- ADC updates
- mica
- eyes: jan is not working on adc now; believes it's done
power management
--------------------
- see martin's mail:
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-August/001042.html
- martin: summary: basic power mgt in 1.x: task queue empty and
then go to sleep; problem: mote adjustment done by the app; if app
didn't sweep sensors ahead of sleeping, the pins might not be right.
- vlado: on msp when task queue empty, check flag into special
registers to determine what is running and then select optimal
power mode; small number of registers; the operation is very quick;
don't need anything else
- martin: simplifying the programming for sb developer; vlado counting
on app to stop the sensor and use stdcontrol to turn on and off
- dgay: so problem is that app decides what goes on and off at
anytime; on wakeup, sb takes a second to come up but task queue is
empty of course you don't want to turn it off
- phil: whenever the task queue is empty, query all stuff in system
- vlado: number of flags you have to test (in msp at least) is low;
msp never shuts down 32khz clock
- martin: this proposal doesn't get in way of doing it currently;
you don't have to implement event handlers
- dgay: don't want to slow down msp's ability to go in and
out of sleep but in some cases you want the app developer to have
some control
- phil: trick is: how and when does the sb do that? It has to understand
when to shutdown; can use heuristics but there are places where they
fail; general observation is that heuristics are tricky when you hit
the edge case
- dgay: could build a component which when you call it it
calls 'start', sense, stop; use for simple apps.
- vlado: but power state can change in modern microcontrollers
with no delay/penalty; should be decoupled from power mgt of
additional hw (sb)
- need watchdog for a piece of hw that uses a lot of energy so you can
call stop; this state machine should be driven by time and not by
microcontr.; microcontr. changing state much faster than
what is necessary for external hw
- phil: analagous to determining when to spindown disk; the trick is
determining the correct time to spindown; in tinyos,
problematic to determine right time and mode but could probably have
general cases that are useful.
- dgay: have dataready, getdata, in getdata a small state machine --
if not on, fireup, set wd timer, send dataready when it comes in,
shutdown
- vlado: check RefVolt on msp; using most dumb interface possible;
it hides the complexity; uses timeout.
- vlado: could introduce a global 'tick' but should be decoupled by
microcontroller since time frames different
- dgay: we should start by describing lower level pwr mgt
interface (same as 1.x) start/stop; then maybe an
HAL-level component for microcontroller
- lama: is there any concept of making it visible to application?;
app could specify some general parameters: from app-level might be
helpful to expose a hint from app
- vlado: can disable or pass parameter in msp implementation
- martin: in imote2, could lose all of RAM; takes long time to powerup
- philb: clearly you cannot power off RAM in imote2 without taking
other measures to be certain sleeping is optimal
- phil: other side is that going to sleep is a very dicey operation if
you want to do it atomically
- vlado: have to be sure task queue is empty and a task doesn't slip
in while shutting down
- phil: there is an atomic sleep call in nesc
- dgay: propose that the bit of system which selects microcontroller's
sleep mode have a hook that various people can connect ot it; ex:
when radio on can say "don't go to sleep now"
- dgay: 2 ways to do hints: application-level or ;
"lowest power is x and I expect to do something at time t"
- phil: argue that the "hw knows" ; timer knows 5 seconds; should just
query the hardware
- vlado: how would you write formula inside module that depend
on all subsystems?
- dgay: asking each component LowestMode and WakeupTime; take
Max(LowestMode) and min(wakeuptime)
- lama: could be multiple power modes that still allow the wakeup
- dgay: yes, hopefully the sb component knows which is the right one
- vlado: cannot qualify everything in terms of absolute time;
should not introduce any policy that could violate any
agreement made with lower-layered modules
- dgay: will continue discussion next week:
- phil: lama: could you come up with a simple-use case where hw
component could not come up with correct statement as to what power
state it needs to be in; and app would have to dictate.
-------------- 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
More information about the Tinyos-host-mote-wg
mailing list