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

[Kristin Wright]

-------------- next part --------------
Notes from 04/20/2005 TinyOS 2.0 Working Group Telecon

04/20/2005 Agenda
-------------------
- status 
- planning for TinyOS 1.9 (aka boot+adc+timer+radio+serial+leds)

04/20/2005 Action Items
------------------------
- Joe: send short status report
- Martin: send short status report
- Everyone: work toward getting pre2 code/tools ready by mid-May

04/27/2005 Tentative Agenda
----------------------------
- Vlado to report on any arbiter experience he may have gained
- Cory to report on fix to the timer 
- Status


04/20/2005 Discussion Notes
---------------------------------------------------------------------------
Miscellaneous
---------------
- gil (Gilman Tolle): should we talk about the AM layer?
  - dgay (David Gay): assumed we'd stick with AM standard; pal (Phil Levis) not around, not sure what he's thinking

pre2.0 Schedule
---------------
- dgay: recall that 1.9 includes boot, radio, serial, adc, timers
  - assumption: 1.9 release mid-May which means that we should have working 
  code 2 weeks from now; packaging will take a few days. 
  - is that deadline (mid-May)okay?
- polastre: sketchy on the radio; will be gone next week
  - note: 1.9 name is confusing
  - everyone agreed, will be something like pre2.0

Booting?
--------
- msp430: yes
- imote2: philb (Phil Buonnadonna): no (dgay noted that imote2 not 
  necessarily a pre2.0 platform)
- mica: martin (Martin Turon): yes

Timers/ADC
----------
- msp: cory: yes, but has a bug
- mica: cory says martin said that he has mica booting, timers integrated; 
  adc status unknown; joe (Joe Polastre) said he believed that hu was 
  writing it
- radio, serial (bus arbitration needed for everything)
  - msp: joe: had an initial implementation, need to rewrite for new res rsv.
    significantly different
    - dgay: berlin: are you implementing an arbiter? if so, perhaps
      joe can reuse
    - vlado: doing an arbiter for spi/uart/i2c combining arbiter
    - joe: radio blocks until its there
    - culler (David Culler): noted to be careful about cost of complexity 
      of the reservation scheme
    - culler: suggested should we bang out the cc2420 radio with the old 
      scheme
    - dgay: what does the cc2420 need? 
      - joe: spi bus (2 usarts /spi arbitrating)
      - joe: radio really wants it (resources) now or not at all; as
	     radio writer, may not know arbiter's algorithm
	     - dgay: sure you do, the radio can *require8 a certain arbiter
      - vlado: could add an intermediate component that gives a 
	certain component priority.     
      - discussion about what design level decides what components 
	get compiled in, and the fact that that can lead to unnecessary 
	additional code (size) and complexity
      - culler: suggested that we don't have the arbiter in until we figure 
	out costs, etc., and fix up radio code later; *could* go the other 
	way also
      - dgay: votes for fix up later
	- polastre: votes fix up later
      - conclusion:  radio will use version joe has now; joe will try to be 
	code complete in a few weeks
  - imote2: 
    - philb: behind but can work on it now
  - tu berlin radio stack:
    - going okay, waiting on res reservation like joe
    - dgay: might make sense for tu berlin to code to the TEP to get experience
      with resource arbitration scheme since they're farther ahead on their
      stack
  - cc1000 
    - dgay: joe found some bugs in practice and will talk later  with dgay 
      this week

Serial
------
- gil: 
  - existing framing protocol has been porting 
  - put together glue for msp430 serial pins 
  - no tep yet, but will do
  - waiting on radio stack to test further (just gives you raw buffers)
- dgay: serial status for mica?
  - gil: not sure what's going to mica; framer stuff is porteed, 
    hpl stuff modified
  - existing model: tunneled radio packets

Network types
-------------
- dgay: do we want network types?
- joe: all the tos msg stuff is based on them, 
- conclusion: yes, will have network types in pre2
- dgay: note that framer should switch to using them

Endian-ness
-----------
- dgay: do we want to switch to big endian now? mig will need hacking.
- culler: good news: by changing to network types we get any 
  endian-ness we like. 
- joe: radio bet/pre 2.0 and 2.0 may not even work together so shouldn't 
    worry about different endianness
- items changing between pre2 and 2: endianness, cc2420 radio stack , 
   all the other stuff we're not including into pre2
- culler: it's clear the nest demo written in 1.1
- martin: perhaps the goal should be sensor readings over the uart
  - culler: uart does supercede radio, but should have both

App/Sensor Sets for pre2
-----------------------
- dgay: suggests that at least one sensor works on each platform 
- appset:
  - team decided: blink, tosbase, countradio, some kind of sense/send
- culler: not having flash support means that we don't have volume mgt
  - dgay: we have nothing ready to use it anyway;no deluge
- martin: applications: directory support for having platform specific 
  support ; 
  - dgay: could go over directory structure post pre2
  - one solution: put in contrib; 
  - joe: don't want to spread app stuff around; 
  - dgay: we need someone to make a suggestion
  - martin: could we put all 'mica*' under 'mica'; 
    - culler: that brings up strange things like is micaz closer 
      to a telos or a mica.
  - dgay: how is the tools directory organization going?
    - phil: tools directory hierarchy is on list of things to do today

Next week
-----------
- joe: next wednesday: spots / martin, too. (note that joe probably won't get
  much coding done) 
- dgay: meet next week; joe & martin could send 2-line status before meeting.
- other agenda items? 
  - culler: would be good to get experience with arbiter report from vlado
  - culler: should also get a report on fix to the timer 

Other Miscellaneous
-----------------------
- martin: would gil be looking into uart for mica? 
  - gil's really busy, can't help too much but noted that, in theory, 
    shouldn't be too different.
- polastre: could we get some mib510s? 
  - martin: will deliver to 410.
-------------- next part --------------
_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-2.0wg