[Tinyos-host-mote-wg] RE: [Tinyos-2.0wg] Meeting 9/7 - NOTES

[mturon at xbow.com]

Hi, I took some notes in the middle half of the meeting -- enclosed for
reference:


... spi discussion ending ...

Paper outline
three level hierarchy issues: chips/platforms (HAA ramifications)
boot/scheduler (task semantics)
communication (message_t, serial, zero copy)
resource management/virtualization
CC2420 as potential common example 

culler: key contributions -- lessons learned vs. principles
pal: not lessons learned
culler: makes writing easier
pal: lessons learned tough in blind conference
     building embedded systems beyond the tools of the 1970s
dculler: that could be a theme that carries through nicely
pal: so much technical depth, tons of examples of interesting points
dculler: challenge is that there is too much
pal: some evaluation, stuff like HAA, may seem like performance issues,
     but you are inlined in nesC.  flexibility of abstractions without costs
vlado: sound paper on principles
pal: organize outside of telecom, go to meat -- pwr mgmt
rob: glanced at notes.  read through martin's tep. not accounting for recent
     discussion. short snap shot
pal: how do you decide MCU state?  basic conclusion is that it should be
     slightly modified version of what is done today.  need to override
     sleep state when concerned of wakeup latency.  default thing you do,
     but there is some event to override this.  right?
rob: that sounds exactly right.  scheduler idle loops, and what not
pal: do you call this always, or have dirty bit?
rob: currently, msp, abbreviated check for MCU sleep mode.  something like
     that makes sense.  some minimal set of chacks is good.  simple things
     are simple to do.  tolerate initial latency. call start/stop, have it 
     work.  even if performance is not best.  minimize required protocol.
     so minimal set of checks is desirable.  on one hand, if you have dirty
     bit, then your component ends up being responsible.  dirty bit is
similar
     to adjustPower -- who calls that?  to what extent do you require
someone
     who is writing a simple component to implement that extra bit of
protocol.
     We then had to add start/stop powerManager.  Not sure who's fault it
was.
     Really like idea of abbreviated state and putting it in scheduler idle 
     loop.  
vlado: current tep allows msp to do what they want
rob: power state is not much longer on mica.  make that part as unified as 
     possible.  
vlado: wakeup latency problem
rob: not a big deal
vlado: does it make sense to do whole check everytime if wakeup latency 
       is long.
culler: hung up on detecting state -- easier part of problem
        what is more common? entry to scheduler, or event wakeup
pal: what % of interrupt handlers cause a task to be posted?

martin: tep need to be expanded -- pin management not handled in actual 
	wakeup interrupt handler.
?: msp never enters scheduler unless needed
rob: sleeping without going to scheduler.  needs to be spelled out what
these
     event handlers can and can't do.
vlado: msp does enter scheduler every wake up

pal: setting dirty bit could be encapsulated in HPL or HAL -- even in the
pin setting command

martin: current tep - 
  1) move power management to HAA model with .sleep hook to MCU in scheduler

  2) pin management using same hook plus .wake signalled to platform
  3) application level components

vlado: wakeup hook not required on msp platform.

rob: pin management is over-simplified in current tep.  
<group>: What if flash is writing and mcu goes to sleep -- extra
checks/state required

rob: back to latency discussion -- both: components register minimum, plus
another 
technique described by phil.
vlado: registering minimum may be overly complex -- this code must be
optimized
pal: we need to consider imote2 in this discussion.
<much discussion not noted...>

martin: is HAA abstraction of tep worthwhile?
vlado: as long as it is a very simple, platform only hook -- yes

martin: request for other ideas of application level components besides
AutoPowerBasic.

Martin 
__________________________________________________
Martin Turon  |  Crossbow Technology, Inc.

-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
[mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On Behalf Of Phil
Buonadonna
Sent: Wednesday, September 07, 2005 12:10 PM
To: Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
Subject: [Tinyos-2.0wg] Meeting 9/7 - NOTES


* Resolved issue with HPLCC2420 on ATmel. Will use multiple SPI write
operations and manually control the CS line (essentially similar to now)

* NSDI paper
  ** Focus on the 2nd generation approach of TinyOS 2.0
  ** If you want to participate in the NSDI paper, send e-mail to the list.
  ** Phil L will establish CVS server
  ** Think about what's different in 2.0 from 1.x that would be topics to
focus on
  
* Power Management
  ** Last discussion ended at looking on how to define events that can
overrid sleep state
  ** Much of recent e-mail discussion seemed to focus on scheduler idle
loops
  ** Two models of power management: simple start/stop or checking for dirty
bits in scheduler loop
  ** Checking dirty bits should not be expensive (if it's implemented right)
  ** What to do about latency projections?  Review notes from 2 weeks ago.
  ** Not a lot of visibility on all ideas about power managment


_______________________________________________
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
_______________________________________________
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