[Tinyos-host-mote-wg] [Tinyos-2.0wg] 2005/09/28 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Fri Sep 30 14:01:30 PDT 2005
-------------- next part --------------
Notes from 09/28/2005 TinyOS 2.0 Working Group
Phil Buonnadonna (Arched Rock), David Culler (Arched Rock), Prabal
Dutta (UCB), David Gay (Intel Research, Berkeley), Ben Greenstein
(UCLA), Jan Hauer (TU-Berlin), Jonathan Hui (Arched Rock), Phil Levis
(Stanford), Gilbert Tolle (Arched Rock), Kristin Wright (UCB)
09/28/2005 Agenda
------------------
- status
- power management
10/05/2005 Tentative Agenda
------------------------------
- SPI
09/28/2005 Discussion Notes
----------------------------------------------------------
status
-------
- Phil: acks don't work well under high load; get bursts of
acks and bursts with no acks; 'high' defined as as fast as you
can go with csma
- ben: saw similar thing in telos stack; noticed the problem between
25 and 50 pps sending very large packets
- phil: a lot are being received but not getting acked; if
you tell the radio to do something while it's doing an ack the
ack gets dropped
- phil: still willing to put his stamp-of-approval on this stack for a
pre-release
- phil/ben: serial communication comments from 9/21 not folded in
- dgay will send a written version of the comments to to Phil to
accompany phil's notes
power management
-----------------
- culler: suggest we talk about SPI because it's very important
- agreed that the group would if time allowed
- phil: summary: override function, dirty bit, power-mgt
- dgay: McuSleep: what does it compute? the lowest power state based on?
- phil: examines the hardware state as mica and telos do today.
- dgay: it's conceivable that you may not be able to compute that
- phil introduced the notion of power override (McuPowerOverride)
- prabal: can we determine remaining power?
- dgay: that might be a higher-level (architecturally speaking) property;
answer may be no
- prabal: is there a notion of standardized low-power state? can I assume
a set of states? or is it simply platform-specific?
- culler: prabal's question restated: what are the assumptions this
solution makes about the power states? think this is the big question
for the imote2
which has a multitude of states; is there a linear sequence of states
or states that encapsulate the microcont/peripherals
- phil: there is an assumption that you can determine the low-power state
from the hardware state
- martin: bug in current state with uart; easy to know that you are sending
cpu will sleep even though the uart has just sent a byte; byte just gets
scrambled; only uart component sent the byte and only it knows; tx case:
what do you do?
- dgay: analagous problem as with radio
- start/stop interface would solve it; in 2.x send case dirty bit solves;
reality is that in 1.x this is an unaddressed problem; low-power node
cpu will go to sleep when there is a byte send
- phil: want to ensure that we fix that in the architecture for 2.x
- culler: in 3.2, we state what McuSleep is responsible to choose
lowest power state; better to put in intro to 3 rather than underneath;
dirty bit is an optimization to minimize the cost of calculating
appropriate power mode.
- not convinced that we've articulated all of our assumptions;
prescriptive approach rather than describing what code is supposed
to achieve
- phil: will put a note in
- martin: will do mica
- culler: other thing the tep is missing is the piece that says "these are
the actual facts in the platforms that have guided our decision"; can
take the position that they form a partial order
- phil: because we have no implementations
- culler: if we do more of the "facts that guided our decision" at the
TEP-writting stage, we may well end up with better implementations
- prabal: what can the os do to minimize power drop?
User perspective: what are the peripherals and how can I use them for
my app?
- dgay: at some point we do need a better system-wide view.
- prabal: could use a top-down perspective
- phil: maybe there should be some teps that are not so low-level
- culler: comes somewhat back to keeping our scope bounded; original
scope: support different platforms; may want to declare victory here
and move other things to different groups.
- ben: success largely determined by how much structure is in the teps;
example: if app developers can see a common pattern; say a table that
specifies the compatiblity states of all peripherals ; some function
would tell app
- culler: related exercise: what are the set of components that interact
with this interface? Can we make that list for each platform?
- culler: timer, adc, bottom or storage stack
- dgay: most of HPL for chip would interact with it; every subsystem which
doesn't work in the lowest power mode would have to interact with it
- martin: will write this list for the mica for next week
- culler: may leave off dirty bit entirely for first cut; to a first
order, agreement between idle loop and HPL
todo
-----
- recall list from email:
1) radio stacks for micaz/telos (which implies #2)
2) busses (I2C, SPI)
- jan: sate of eyes: same as when Kevin left; they do have someone
picking up the work that Kevin had done but will take a few weeks
until he's up to speed
3) Missing ADC/Timer bits
4) sensor boards (good way to test adc stack)
5) tep pass on completed subsystems
- teps should include platform-specific, design-driving features by
that point
6) nesdoc for 2.x
7) network protocols
8) surge-like demo app (with Java GUI)
9) TOSSIM
10) Tutorials
- culler: regarding #5) it was mentioned that HALs should be filled out
to express "everything the hw can do"; clarification: they
HALs are *permitted* to expose everything the hw can
do but not a MUST; in terms of bringing things to closure, may want
to restrict to what people most often use
- dgay: there are some things that are truly necessary but which aren't
implemented
- culler: example: it's possible on the msp to schedule a series of
different samples on different channels; if that code wasn't in
there it wouldn't be the end of the world
- dgay: missing storage in part of the core; needs to go in the boundary
- culler: boundary: primary issue is to deal with diversity of platforms,
and we improved robustness to scheduling as a side-effect
- dgay: would not like to lose functionality that was in 1.x, i.e.,
routing
- culler: perhaps we can do those things but outside of working group
- phil: collection routing; different for each radio platform due to
link estimation; maybe put a link-estimator in the core
- culler: want to get to the point where we have a set of things working
in the core so that we can build lots of things on top; don't have to
reach consensus on everything at the high-level
- dgay: so we could take a routing component from 1.x that is stable enough?
- culler: there will be a variety of things that weren't specified by the
wg that still rn on it
- dgay: could have a core working group + network protocol
working group + deluge working group; but if we go that route, we need
to get those groups going or they won't be there until too late.
- culler: i'd be all for that
- phil: do other working groups not deal with platform-specific issues?
- dgay: i think they have to
- culler: note that there will be working group overlap with respect
to boundaries and membership
- dgay: will break up things left to do and send out email
SPI
---
- will discuss SPI in email; try to wrap up next week; issue: phil has
made good progress that allows for split-phase ops;
there are cases for efficient larger xfers and some synchronous
operations
- phil b: (clarification on statement made in a previous meeting)
interface that doesn't allow you to do large split-phase is
a bit of a none-starter, but may still want to do small stuff;
so if interface doesn't allow you to do dma that's also a non-starter
Next week
----------
- spi (email first)
-------------- 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