[Tinyos-host-mote-wg] [Tinyos-2.0wg] 06/01/2005 Telecon Notes

[Kristin Wright]

-------------- next part --------------

Notes from 06/01/2005 TinyOS 2.0 Working Group 

06/01/2005 Agenda
------------------
- pre2 release reschedule
 there's a list of tasks at the beginning, with proposed dates...
- Radio / AM interaction 
- random issue of the day: cancelling tasks (continued)
- packages for nesC? (pre-discussion, not for pre2 release) 
  (continued)

06/01/2005 Action items
---------------------------
- dgay: email xbow to try out 2420 stack; put their backend in
  and debug
- pal: organize a Radio HIL subgroup
- everyone: various tasks to meet pre2 deadlines (see link
  to list of tasks under 'Status' below)

06/01/2005 Agenda
------------------
Not discussed


06/01/2005 Discussion Notes
----------------------------------------------------------

Status:
-------
For list of tasks message, see:
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-June/000914.html
Overall target: 6/30

- Is June 30 reachable??
- radio: Joe spending time on radio at most 1 day per week
  - Crossbow: get micaZ backend and test and debug
    - dgay to email
- tools: 
  - kwright: 
    - mspgcc geling on versions just this morning
      tu-berlin hasn't given input yet, though
    - haven't done anything on xscale
- dgay: 
  - cleaning up coding convnetions
    - might be adding Packages
  - cleaning up CC1000
- phil:
  - ADC tep mods: started but not done
  - oski: june 9 okay
  - count radio: done
- kevin's status in email:
  https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-June/000913.html
  - summary: much traveling in near future; not including infineon stack
    in pre2

Radio / AM interaction 
----------------------------------------------------
- Phil:
  - basic issue: what is the HIL for the radio? What is the lowest-level
  platform indepedence? Should we say that AM (Active Messages) 
  is the HIL? Then you can
  have platform-specific implementations -- addresses can be different
  or, no the AM is not in the HIL and the underlying layer is something else
- joe: what is AM other than service dispatch? 
- dgay: AM is also addresses, destination
- joe: no one uses anything but generic comm; no other implementations
- phil: could say am is just a one-byte type field; underlying layer has some address
- joe: 
   - 15.4 has group but we end up duplicating group because AM puts it
   in above 15.4 implementation; destination not unique to AM
    - argues AM only takes care of svc dispatch: groups at a 
      whole different level
- culler: we should discuss outbound -- do I have an address to send to? do
     I name a destination? in the am send is there a destination?
- culler: are addresses a parameter or part of the underlying implementation?
  - joe: *not* a parameter at sending phase?
  - phil: filling in pkt header structures is a pain, error-prone: 
    forgot to fill in len field (for example) or there are corner cases
- dculler: is the am interface a packet format? historically, we
     avoided that
- joe: are we actually using abstract types and sometimes we don't
  RadioPacket is an abstract type; we're 
- dgay: no difference between Get/Set and fields you can read and write
  some practical difference
- joe: remove the Sets() so it's not confusing; not multiple ways to
  set up the packet (as a parameter and by calling Set())
- dgay: 
  - What interface do we want to present to the programmer? 
  - with n params at the AM level? or one that has Set() and then call
    DoItNow()?
  - phil: analog in unix: sockets ; sockets interface well-known to 
    be not the greatest interface 
- culler:
   - 1) all of info conveyed through set of methods on packats; am does
     dispatch above
   - 2) interface has params; one is payload; dest/type/ 
   - 3) hybrid approach
- dgay: others could build hybrid 
- phil: going to pure get/set and bare Send
- culler: think we want to think through this in terms of the protocol 
  layers that are one above ; even for best-effort single-hop 
- joe: 
  - how does multihop algo work when they need to select parent? 
  - whole point is that people can provide their own intermediate layers
- phil: can you use a packet buffer as temp storage for params?
- culler: other question is: as I go up the stack, am I able to encapsulate the 
  inner payload? Do i get a zero copy as I go up the stack? 
- dgay: on the way down, may end up with extra read/write
- dgay: 
  - getting back to get/set: perhaps have that in 
  in lower layers where app programmers are less likely to 
  be reading/modifying code perhaps have Get/Set;
  - Upper-level API, want to at least provide the option maybe that level is 
  one level up from AM
- dgay: must store address in packet or it will cost them 2 bytes of RAM 
- joe: thinks there's no HIL for the radio/ there's no hw indep representation
  of sending a packet; analogous to ADC
  - talking about addressing; on every other computer, it's ipv4 addressing
  currently on sensor nets, there's no way to do this hw independently 
  because of the variation
- dgay: so packet is just the data payload
- dgay: if AM not available, what is the interface?
- How does AM deal with link address?

[to convey the spirit of the discussion, I'll add a note that 
here there were comments about something being silly, a second comment
that this was a contentious topic, and a third that they were 
'utterly confused' about what we were trying to solve]

- dgay: Can we standardize a link-layer w/non-standard addresses?
  - things w/addresses in args are in network-layer protocol
    on top of a get/set interface
- joe: 
  - addressing above the network layer, not the link-layer
  - not enforcing linking between network/link so no... 
- dgay: whole bunch of network layer things; some have addresses and
  some don't
- joe: if network layer wants addresses, it should do the mapping from
  link to network
- dgay: where do multiple physical layers merge? link-layer? 
- phil: no notion of sending an AM to the uart
- phil: what's the interface to the hw indepen. part? 
- joe: at least needs the notion to dynamically set addresses; not at
  compile time
- phil: am packet if that says, "what is my address?" could be a global,
but could be anything
- joe & phil & david: all the other stuff is in the noise compared to 
  that; going to get a sub-group 
- phil will check in something hacky for (AM C for HIL)pre2
- phil will send out email for getting people together ; tomorrow sounds
  good.  

nesC packages
---------------
See mail message here:
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-June/000915.html
- Continued due to length of time on Radio HIL

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