[Tinyos-host-mote-wg] [Tinyos-2.0wg] 4/27/2005 2.0 Telecon Notes

[Kristin Wright]

This second mailing, which I'll link from the wg page rather than the
first mailing, has all references to Vlado changed to Kevin. Otherwise 
the notes are identical. -kw
-------------- next part --------------

Notes from 04/27/2005 TinyOS 2.0 Working Group Telecon

Present:
David Culler (UCB), David Gay (Intel), 
Kevin Klues (TU-Berlin), Phil Levis (UCB), 
Cory Sharp (UCB), Karen Weeks (UCLA), 
Kristin Wright (UCB)

04/27/2005 Agenda
-----------------
- TEP 108: Resource Reservation
- Status

04/27/2005 Action Items
-----------------------
- dgay to send mail to Crossbow re: Mica Timer/ADC status

04/05/2005 Tentative Agenda
----------------------------
Not discussed. 

04/27/2005 Discussion Notes
----------------------------------------------------------

TEP 108: Resource Reservation
-----------------------------
- Background: Currently, there are 2 outcomes of the 
Request() command: SUCCESS means that you got the 
resource and EBUSY means that you didn't get the 
resource because someone else has it and you're 
enqueued. Joe Polastre suggested that the radio
implementation would benefit from a call with "grab the 
resource if it's available; otherwise, forget it and don't 
even put me in a queue". The following discusses whether to
add that to the Resource Reservation TEP 108 and, if so, how.
- possible solutions could be:
  - an additional parameter to the existing Request() command 
    that indicates that you don't want 
    to be queued if the resource is busy.
  - a different command altogether
  - do you still get the Granted() event? How is that handled? 
  - leave command semantics as they are now; programmer could add 
    in an intermediate component that prioritizes certain callers
- issue: some solutions lead to code duplication; memory is
already scarce
- Discussion:
- 3 possible responses: busy, but wait; granted immediately; busy but fail
- culler: what is if response is failed or granted, then event will not be fired 
- kevin: if you release in granted, will need a new state variable
- phil: what's the common case? if i don't get it now don't want it at all, or 
      the i-can-wait 
- culler: latter is the common case
- phil: than would suggest that you should get the event 
- dgay: another way is with a separate command; thinks it's cleaner
- dgay: does that (if we go with a separate command) mean that if we have 
    a request-it-NOW-> never split-phase, and Request() always split-phase? 
- culler: not sure about having so many variants
- phil: if we have Release(),  what does that mean if there's an EBUSY return on the
request. what does a subsequent call to Release() mean? 
- kevin: nothing happens. there's a check that caller owns resource.
- phil: release could mean to cancel pending request.
- culler: would be cautious about putting too much into the reneging; 
  rare case; needn't put a lot of energy into it
- kevin: agrees; just want to request 
- phil: issue is that where this happens is in the radio stack; if you can make radio simpler,
  everyone benefits
- culler: specifically, can't get to radio because flash is busy and they're sharing pins
- culler: adding complexity to interface makes it that much wider; argues 
  for one call w/parameter
- dgay: would argue that 2 calls actually simpler than passing a parameter
  - sematically, the two options are identical
- dgay: defer discussion about interface specifics; we agree that *do* we want 
  a non-queuing request
- kevin: do we want RequestNow to have a related released event?
- dgay: don't think we need release event
- phil: if that event is going to come in you might as well queue; if you want 
  a release you should have an enqueue. 
- culler: probably whatever we do here, we should probably have done w/send/sendDone
- dgay: haven't made that decision quite yet, don't know how OSKI is looking
- culler: once we clean up resource interface, transmit will look much the same
- dgay: discussion concluded via email; tep will be updated

TOSMsg
------
- kevin: would like to look into TOSmsg / their radio doesn't need any fields, 
  but platform needs it so it doesn't make sense to put in chips radio for 
  their platform; not a notion of where it works, but where to put it
- culler: is kind of rare that radio needs fields
- culler: might be that we're getting too worried about whether something 
  is determined by hw or software interface; rfm+framing format
  (logically the chip even though chip more primitive)
- dgay: obvious one is the crc (done in the software but really belongs 
  in lowest level implementation)
- culler: sounds like we may be hung-up on the word 'chip' 
- kevin: link field
- phil: discussion might be more complete w/joe (who's at a conference)
- culler: 'chips' really mean platform component; a component that appears 
  in potentially multiple platforms -- typically a chip but not always
- dgay: does that answer questions?
- kevin: except for families directory
- dgay: no strong opinion
- phil: prohibiting additional structure seems nonsensical
- dgay: vision of ncc -- should just be able to say 'ncc -foo' --
adding stuff to tools/make to support families is a mistake; .platform
file -> have all options to be able to compmile for that platform;
have family directories that have a .family file that ncc could look
in; could put all mica motes in a family
- dgay: any opionion from crossbow? 
  - no xbow rep present

status
-------
- mica: unknown
- telos (cssharp) 
  - running fine; may be remiss in detail of how 
  - adc/timer done; waiting for radio from joe  
  - cory: unsure of uart status from gil
  - phil: gil copied current stuff over; 
  - dgay: thinks gil actually did a new serial interface -- not sure
- eyes: same as telos: waiting for radio
- dgay: will send email to martin that we're starting to depend on
  mica timer/adc as dgay is doing the radio for the cc1000




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