[Tinyos-host-mote-wg] [Tinyos-2.0wg] 05/18/2005 2.0 Telecon Notes

[Kristin Wright]

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

Notes from 05/18/2005 TinyOS 2.0 Working Group 

Present:
Phil Buonnadonna (Intel Berkeley), David Gay (Intel Berkeley), Ben
Greenstein (UCLA), Vlado Handziski (TU-Berlin), Jan Hauer (TU-Berlin)
Jonathan Hui (UCB), Phil Levis (UCB), Gilman Tolle (UCB), Martin Turon
(Crossbow) Kristin Wright (UCB)

05/18/2005 Agenda
--------------------
- Status 
- pre2 release planning 

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

05/18/2005 Discussion Notes
----------------------------------------------------------
See: 
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000845.html

Status
--------
tools:
  - due next week
  - need cory's java xcomm
  - kwright: still have some xemacs packaging to do
    - dgay: can leave out of prerelease 1
  - mspgcc:
    - phil levis: what's the status of the msp430gcc bug? 
      non-repeatable; multiply by 1000 ended up being a 
      multiply 2000. 
    - phil is using 3.2.3 (what everyone is using)
    - vlado: plan for 2.0 is to have hardware multiply disabled; 
      there's a bug when it's enabled 
    - what libc version are we using?
      - dgay: package up what we packaged up before or what 
        we have today
     - vlado: standardized on a gcc version to 3.2.3 but using various
       libc version; script from cory makes a cvs snapshot so everyone
       has a different version. vlado/cory/kristin will take one and
       standardize on it. joe/cory/vlado --> different sizes of binaries
       due to libc version.

telos:
- dgay: cc2420 done in next few weeks? 
  - joe: 
    - probably; trying to make it completely hardware abstracted
    - debugging data buses, general i/o, other underlying components as
      implementation proceeds; arduous task; uses all of hte HIL
    - polastre: have a test component and going through fixing underlying
      components as bugs are hit
  - dgay: possible help:
    - joe: would be nice to test other parts of msp (timer captures) 
    - vlado: kevin using some while he's porting the eyes radio; can help
      with ironing out those bugs
    - joe: number of things radio uses that typical timer doesn't use; verifying
      that typical captures, etc., work 
    - dgay: kevin/joe/cory: can test those
    - dgay: send mail when you're close
 - joe: struggling with various nesc things; will send mail to dgay

eyes:
-  kevin: 
- timers don't compile
- cory:
  - updated premature; will fix up any platform code and should be
    fixed shortly
  - kevin: does that include timer32khz interface? or just timermilli?
    - kevin: wanted 2ms, 1ms granularity
    - cory: with 32khz, would ask but wouldn't necessarily get it
  - kevin: would be better with 32khz but can use 1ms
  - cory: can you use alarm? 
    - kevin: yes

micaz:
- martin: didn't check in spi or cc2420 wiring, but in progress and he
  can commit it this week
- joe: no point in checking in wiring because it changes every day

mica2:
- doing some mica2 cleanup
- will check in this week


prerelease
-------------
teps:
- for prerelease, teps should be reasonably up-to-date.
- coding conventions:
  dgay will go over coding conventions and phil levis 
- timer: 
  new tep checked in. 
- csma/radio: 
  complete
- task/boot: 
  complete
- reservation tep: 
  requestedNow/async rather than sync
  dgay will get out today or tomorrow

feedback from oski/higher levels:
- need a packet interface
- working through issues with multiplexing services
- phil: things okay
- dgay: ready by june 2?
  - phil: plausible for some, CountRadio app absolutely
- joe: should oski apps be under tos/oski/apps?
  - phil: agrees that they might belong elsewhere
- someone noted that the random number generator doesn't compile
  - phil will fix it

serial:
- done except for upper-layer stuff
- phil: raises a basic question
  - in tinyos-1x, does am have a uart address?
  - gil: other option: use the wiring
  - phil: yes
  - gil: vote for that option

java tools:
- just copy old serial forwarder
- tools/listen
- tools/send

network types:
- joe: are network types ready?
  - dgay: can do either endian-ness
  - joe needs big endian
  - 'nxle' -> little endian
  - 'nx' -> big endian 
- vlado: 
  - standard practice is to put 'eb' at end (foobe) -> (fooeb)
  - dgay: will change with next nesc release

vlado:
- tools in java; java 1.5 still getting enum error 
  - dgay: will fix

apps:
- dgay:prerelease apps will be CountRadio/TOSBase/Blink

summary:
- biggest uncertainty is the cc2420 radio; will have to see how that 
develops

adc
-----
(You might glean some info from these notes, but for a better understanding
of the issues see the following email and the entire thread that follows it, 
much of which was posted after this (5/18) meeting:)
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000822.html

- main issue: should there be a standard ADC component representing underlying
  ports
- jan: equivalent mechanism where he can choose something like DemoSensor
    and wire to it
- dgay: vision for adcc is not functionality which you would expect
  such a global enum; DemoSensor falls under sensorboard tep 
  - ADC HIL will be platform independent; ADCChannel component; 
  - where do I check-in my ADCChannel component? tos/lib/ADC
  - not strongly platform-independent -- *can* write *useful* app though
    we cannot guarantee complete paltform indep.
  - concepts like A-to-D are not platform independent, but still useful
    to expose; useful for several platforms; still a useful extraction
- jan (could have been vlado -- hard to guess on the phone): 
  HPL: platform-dependent
  HAL: platform-dependent (mps /atmel/so on)
     - fairly rich interface for msp (sampling,buffering)
  -wrappers that wrap around individual sensors that wrap the bytes;
   export AcquireDAta AcquireDAtaNow ; accompanied by reservation interface
   on top of the above, we need something comparable to current ADC imple. for mica 
 - architecturally, positioned above the platform-independent interface
- phil: how do I write a platform independent InternalChipTemperature what
if i don't have an InternalChipTemperature?
- vlado: same mech. that was used for 1.1; your platform-independent app would wire 
  to the platform 
- phil: might be co
nfusing interface and component names
- dgay: confusing 2 things:
      - 1) clearly a sensorboard which is a set of sensors
      - 2) signal strength/temp
      - something else: an atod chip with multi-channel where you want
        to do 
- maybe call them "services"
  - low platform-independent interface
  - buld services and put them into lib
  - having tos/libs that are for hals; all sorts of platform-independing
    things under, but common, useful abstractions
  - build services on top of HIL interface; once you go to round-robin, 
    lose any control over when you're going to hw.
  - platform-indep implies that there aren't any timing guarantees
- dgay: in some way you never write a platform-indep app becuase there are
  no platform-indep sensorboard
- vlado: want setrfpower analogy
- dgay: want setrfpower (specifies power in decibels)
- dgay: once we define a temp wrapper that always defines deg cent... 
don't want to go down that path; don't want to go down path of 
standardizing the sensors.
- dgay: sounds like the adc tep should say: here's a way 
  to structure tep; ends up w/a hil that says "each platform specifies
  HIL based on sensorboard interface"
- jan: parameterized or not? suggest another set of emails
- dgay: would like to expose parameterized beuase you can 
(rather than separate wrappers)
- jan: agree that HAL parameterized that way
- need a rich interface and a standard interface; 
  export 2 interfaces for cc1000; 
  cc1000 using acquiredata 
- dgay compromise: in last email
  - have adcc provide all acquire* interfaces but
    each platform can decide what port actually maps to/ what
    adc settings are
- dgay: 
  - one last issue
  - a platofrm doesn't know what their adc settings are supposed to be
  - different sensorboards may want different settings
- jan:
  - have events / callbacks just like initialization for timer system
- martin:
  - do we want to sense sensorboard changes dynamically?
  - dgay: don't think so
- tu-berlin: 
  - will send revised adc tep
-------------- 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