[Tinyos-host-mote-wg] [Tinyos-2.0wg] 06/29 Telecon Notes, 2nd half

[Kristin Wright]

I was only present for the last half of the meeting. I believe that
someone else was taking notes for the first half. If those get sent
along, I'll be sure and link both halves to the web site.

-kw
-------------- next part --------------

(Note: these notes only cover 2nd half of the meeting)

06/29/2005 Agenda
------------------
- status 
- more on message_t
- teps in general 

07/06 Agenda
-------------
- Sensorboard TEP

06/29/2005 Discussion Notes
----------------------------------------------------------

Status, cont'd
--------------
cc2420 implementation path
- new Timer spec : harder to follow path of code; documentation issue;
  nesdoc not updated for generic components 
- dgay: can still look at app.c
- culler: is this feeling that joe is raising about generic components, do other 
  people feel similarly?
- dgay: is joe using source debugging? joe: no. dgay: that's one issue 
  second: broken into lots of things so we have lots of small files
- culler: have we fallen into the 'second system' trap? 
- joe: philb says too many options to choose from from for implementation
- dgay: there is a tradeoff: breaking up makes it harder to understand
- philb: we're all writing them in completely different ways
- dgay: true we haven't done a good job on naming convention
- dgay: radio stack should not be using oski
- joe: how do you a test then?
- dgay: right-- for app, but not radio stack
- joe: it's just not clear; it's not an oski problem
- culler: seems like it's a level down 
- culler: 
  - issue: have gen comp created more structure than we have the
    ability to deal with?
  - second issue: concrete: fixing things at the bottom but people are all
    busy. 
  - options: 
    1) have joe fix appropriately 
    2) identify somebody that actually has time to fix appropriately  
    3) work-around and do top-level without using the right abstractions 
    and work around it.
- jan: will talk to kevin to see if he has time
- joe: note that Kevin took a completely different approach and wrote a 
  second byteRadio
- dgay/phil: orthogonal issue
- dgay: soemtime this week: kevin 

More status:
- ben: Host mote: will send email when they have a good implementation; 
  - summary:
    have a framer module; clients attach to the framer module; 
    attach by registering an interest in a particular datatype; at runtime; 
    interface parameterized on the client; TOSBase, for example, would be a client. 
    "piece of code running on mote"; could be a status client, config client, debug client, etc.. 
    Decision: who should be allocating buffers? Decided that clients should 
    be allocating the buffers and passing a pointer. 
  - Code is publically accessible, but in some flux. mstar/tos/contrib -> nix. 

message_t
- issues that arise when you have 2 radios and the data payloads have two offsets
  pt to union of all possible package formats that you have; 
- culler: classic approach pass ptr to head; used to cast to TOSMsg;
- dgay: still have different header sizes; data payload must be at max possible offset. 
- dgay: important to share buffers between modules? culler: shows up when you're 
  trying to build bridges (TOSBase); will build bridges that go between/ 2 radios. Today, 
  we have a uart between the two radios. 
- dgay: cost of copying a packet is not too many cycles
- ben: their implementation does a copy and they see no performance impact
- culler: important to optimize for radio to uart, not for radio to radio
- dgay: ignore radio to radio issue and concentrate on radio to uart
  encapsulate within uart implementation; no explicit uart packet type; 
- message_t: no further changes for pre2; revisit issue of uart early next week

tep feedback
- phil: would like to get feedback from community on teps 101, 106, 107, 109, 102 
  - sent out an email about teps 
  - culler: what does that mean? 
  - phil: Move it to front page and post to tinyos and tinyos-devel. 
- dgay: sent some changes to mica adc stuff
- ben: question they get: how is moving tinyos 2.0 going to change their 
  current code base. currently nothing is fully backwards compatible, but much 
  is similar so that porting is easy. 

next week:
- discussion on sensorboard tep 
- phil: people should read it and if discussion is needed then move on
- dgay: recommended that xbow read over it

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