[Tinyos-host-mote-wg] [Tinyos-2.0wg] 10/05/2005 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Wed Oct 5 13:35:57 PDT 2005
-------------- next part --------------
Notes from 10/05/2005 TinyOS 2.0 Working Group
Phil Buonnadonna (Arched Rock), Prabal Dutta (UCB), David Gay (Intel
Research, Berkeley), Vlado Handziski (TU-Berlin), Jan Hauer
(TU-Berlin), Jonathan Hui (Arched Rock), Phil Levis (Stanford),
Gilbert Tolle (Arched Rock), Kristin Wright (UCB)
10/05/2005 Agenda
------------------
- core/network/tools/etc division of working group tasks (see my earlier
email)
- non-cpu (storage, radio, etc) power management
10/05/2005 Action Items
-------------------------
- Vlado: send out summary of Non-CPU Power Management
10/12/2005 Agenda
------------------
- not discussed
10/05/2005 Discussion Notes
----------------------------------------------------------
2.0 Task Division
---------------------
- see dgay's proposed list of task divisions/working groups:
http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-October/001163.html
- network services
- should start fairly soon
- jonathan and/or gil : potential chairs
- perhaps david c. should choose.
- phil would be happy to be the wg chair if jwhui or gil aren't
interested
- dgay: membership discussion should be on 2.0 list :
who wants to be in and who wants to chair
- prabal: seems like it's intersecting with ucb work,
particularly david chu's work
- tools:
- dgay: historically kwright and dgay; basically done
- would cory be interested?
- don't need to set up a working group at this point
- tutorials/documentation:
- phil: not sure what documentation means; broad category
- management tasks: nesdoc stuff there and accurate
- phil: role of the teps as a form of documentation
- vlado: what happened to user manual
- thought it was in beta/
- kwright: interested in chairing, but need to ask David C.
- would like phil levis to participate in working group since he
has expressed interested / opinions on tutorial & docs
- phil: what are the core responsibilities of a wg chair?
- dgay: make sure that work progresses not necessarily; likely
will vary from group to group
- phil/david c/dgay: nesc
- don't see a need to form a working group at this point
SPI bus summary
---------------
- SPI bus resolved in email
- decided that existing interfaces sufficient
- dgay: is there going to be an SPI tep?
- phil: don't see one because it gets down to Resource interface
- phil: depending on your platform, sometimes the SPI bus could be
shared ; cc2420 stack does this (flash & radio share spi)
- have Resource interface already keeping track of who is using what
and if there are pending requests, so it precludes needs for
specific component
Non-CPU Power Management
---------------------------
- vlado:
- RefVolt in msp430: multiple components are using it; reference
counting of resource usage with a timer expiring the usage
- phil; similar to what moteiv has been saying should be pushed up
to higher levels; question: how does something register that it's using the
ref voltage?
- vlado: very similar to Resource interface
- jan: it's a semaphore
- phil: StdControl::start/stop(): have deep semantics that are broken;
example: when you turn off radio it turns off the SPI bus so flash
can't talk
- oski takes an approach by keeping a bitmask for keeping track of
usage; keeps a byte of space or more depending on no of users; but
seems too expensive
- dgay: 10 subsystems per platform: cheap; every component: possibly
expensive
- dgay: different peripherals have different ways to manage power and
may have different schemes
- phil: at the bottom there's a notion of on/off and you can put policy
on top
- vlado: suggest that we keep start/stop as explicit hard commands;
not connected to any policy; so when you call stop, presumably the
calling app has some knowledge and "owns" the component;
in parallel you can turn on some kind of automatic component if you
wish
- phil: one option is that the Resource interface encapsulates power
interface, but could also arrange things such that that
you operate completely in parallel (try to gain access but
if not on call fails)
- dgay: would we want to lower RefVolt-style policies on top of something
that provides a Resource interface?
- suggested schemes clarified:
- vlado: if someone has requested resource and someone frees it it
goes straight to next request
- jan: if queue empty and person who has it frees it and then resource
can go off
- phil: since Resource if pretty prevalent, wary of adding another event
- dgay: that's why you put it in another component
- phil: still it's another event
- dgay: one line of code that will only be in if it's wired
- phil: nevertheless, we're adding soemthing to support
something speculative;
- like vlado's idea but have a question: are
the stdcontrol start/stop semantics deep?
- phil: under my perspective shouldn't be deep because that's broken
- dgay: agreed
- phil: 3 things using SPI, 2 turn off and one stays on; how do you
know to stay on?
- dgay: reference counting and the other is your bitmask idea
- dgay: if you want encapsulation you have to have deep semantics; with
a timer, don't know what it's using
- phil: when rob did power mgt, ref counts were problematic; weird code
happened where you call Start() again, then nothing turned off because
the ref count never again dipped to 0.
- believes a bitmask is the right way: if components aleady
have mechanisms to do this you don't have to waste additional space/code
- dgay: could provide both StdControl interface and also
resource mgt; sounds as if in some cases you need to separate and some
cases you don't
- 2=level: StdControl and Resource
- vlado: we still have problem with nested component interactions
- dgay: things which use StdControl need to keep current bitmasks
- phil: comes down to software figuring out (1) whether resource is
currently being used or (2) (due to startup/shutdown costs) going to
be used in future;
- dgay: note that flash can turn on/off on per-request basis
- phil: when do you need stdontrol?
- dgay: radio/uart: radio doesn't know when it's going to receive messages
and you might have an external interrupt pin; second example: slow turn-off
turn-on and you don't know when requests will come in
- gil: likes the device driver method: each compoennt
decide; general purpose interface should do something reasonable in
default case
- dgay: at point where we're specifying platform-independent interfaces,
must do something general
- gil: even a platform-dependent interface may still have a general
interface below;
- may have been a little quick to rule out oski interface
- phil: threw it out because he was hard-pressed to find when you would
have that but not Resource interface; already have that bit of state
from client ; found it redundant
- vlado: RefVolt is a model where you don't use explicit power mgt but
want underlying system to do power mgt; you interract with normal
commands (flash: read/write); but does not solve problem fully; still
need StdControl sometimes; if you want automatic power management,
you use something based on Resource ; if not, use StdControl
- typically, internally driven rely on resource interface or other
info regarding outstanding requests
- things which have to react to external events need to do start/stop
- dgay: radio is more complicated due to scheduling policies ; think it
has to be start/stop
- phil: internal (flash) stdcontrol may not be necessary;
slow startup? that might change
- for things which are reading in data, you do want stdcontrol/splitcontrol
- conclusion seems to be that there are many places where we can
replace stdcontrol with Resource
- phil: raise question: what happens if you have slow startup?
do you have both and, if so, how do they interact?
- vlado: could add parameter to power control to specify a latency limit;
limit will influence timer / final decision to turn off; could also
use a header file to specify a limit which you're willing to tolerate
- phil: very leary of approach ; timeouts/windows always have
edge cases that become problematic; if system has fixed period than
that implies that something that knows the fixed period starts pinging
keeping track of when it will turn off; possible that some higher-level
component above triggers events solely for the purpose of getting
around the lower-level policy
- dgay: we are talking about a single application running so there's more
opportunity for the application/app writer to tune the period
- dgay: components might want to offer both but could provide a standard
component that turns resource off that apps can choose to use
- phil: there are times when a timeout works, but there are times when
higher-level components are trying to get around them.
- dgay: if trying to get around, then timeout is the wrong policy for that
application
- vlado: so app would be free to disable
- dgay: can take lower-level system and put a start/stop after idle (in
seconds) above it; what RefVolt does; app can choose to use it or not;
no automatic policy below
- phil: think we want a separate tep for this power management; still
have reservations about sleep timeout thing but should go with it given
group consensus
- vlado: would like a clarification: right now it's simple for RefVolt to
determine if shutting down is the right choice; doesn't make sense to
we separate the state that RefVolt is currently using and place it higher
up the component tree.
- dgay: leave logic in there but have it call an event rather than just
turn off
- vlado will send out an email summary of this conversation
-------------- 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