[Tinyos-host-mote-wg] [Tinyos-2.0wg] 07/13/2005 Telecon Notes

[Kristin Wright]

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

Jonathan, Gil, Phil Levis, Kristin, David, Vlado, Ben, David Culler, Cory

Status:
- will release tools (1.x and 2.x) either next week or the week after
- kw: works
- once we decide exactly what the pre2 contains, will freeze and then
  Phil will clean up
- phil: will discuss java toolchain offline (regarding message_t) and then
  present to the group
- phil: has done sensetoradio
  - missing in teps: demosensorC
  - dgay: put in either the sensorboard tep or some platform-specific tep
  - vlado: think we can put in sensorboard
  - dgay: could have one that returns 23 (for example) if you're really 
  desparate
- pre2 platforms: mica2 - believe it's ready (minor problems and some 
  missing functionality)
- vlado: jan working through final layer of radio; problems with how to align
  resource reservation in radio; issue: radio uses uart for data, spi for 
  radio configuration - chief constraint: done on a single piece of hardware.
  config -> sending : have to go over release bus, acquire bus so someone
  else can grab bus when that's not what you want. Sometimes want 
  spi spec: uses different reservation strings than uart. dgay: reserve ahead
  of time, xfer ownership, note that they're the same user. dgay: do the easy
  thing for now and in long term should 
- phil: tep 108 not submitted to community, feel free to change
- dgay: useful feedback to work through the options
- platforms: pre2 will be mica2, 
- vlado will try to get SenseToRadio to compile; 

Timers: 
- David and Cory did not meet to discuss issues last week; Joe's concern: don't need all of it for what we're doing; can we simplify it? second issue: can you
understand the layering from the current tep context
- cory: first issue: not sure what isn't needed; 
- phil: TimerMilliC
- dgay: doesn't present story very clearly; 
- culler: might be useful to ; Counter  Alarm in HPL captures low-level hw;
- turon: 1.x timer0 dedicated to milli ; timer2 approximates a 32khz timer
- dgay: thought the issue was that the radio needed an input capture pin
- martin: needs 2 services from the timer component; needs jiffy timer & capture
- dgay: thought we agreed that 2.x would agree on a 32kgz timer
- dgay: can use timer0 to build 32kgz and timermilli & just divide
- martin: might be able to do that, but didn't know how to 
  implement
- timermilli trivial to implement on top of timerjiffy (?) by multiplying 
arguments
- cory: martin, sendemail and cory will describe
- culler: describe logival relationshiop between hw resources; dangerous
for martin to be exploring different ways to wire when in 2001 wmuch time
spent with these relationships 
- dgay: every hw timer exposed as an alarm at HAL; on mica use timer0 alarm
to build both timermilli & timer 32khz
  - micaz : dedicate timer1 to radio
- culler: want the reasoning to be put down somewhere and good place to put it 
is the tep; for each abstraction, there's thinking done before implementation 
and that reasoning is what we need to document
- vlado: understand, but there are differences in the preferences; ex: eyes
and telos make different decisions
- dgay: would describe it per platform: "on platform1 we do blah", etc.
- culler: example: discussion in the back of the radio tep; radio outputs clock
and they use that to drive one of the msps so they can synchronize w/clock
- culler: excellent thing to describe in eyes platform implementation section
at end of tep
- phil: sounds like martin should get together w/cory
- dgay: so we do need to revise tep to add these platform questions and perhaps
restructure the sections; sounds like a one-pass revision
- cory: don't have time this week, but think that sometime next week will work
- everyone: read and send comments to cory and list (to avoid redundant comments) 
- phil: did we resolve the acquireData thing? 
- dgay: should be in sensorboard or in the adc tep?
- vlado: wasn't in that meeting; opinion: more general than ADC and should be
in another TEP
- dgay: so we should include in sensorboard

- vlado: will look for some tool for processing teps into a readable form
- dgay: TOS/interfaces will only include interfaces specified in teps
- phil: can't be platform- or chip-specific, either
- vlado: reasonable because they have to be documented somewhere
- dgay: 1.x has some 100 or so that magically appeared there
- dgay: obvious rule: if there's a clear owner, can live with that owner. StdControl, AcquireData, etc seem to be more systemwide; might run into a question of
individual test
- cory: proposal: why not just lib/tos? why do we need a special interface?
- dgay: lib/tos grabs things w/no clear place 
- culler: feedback on ucla discussion from last week?
- dgay: will discuss next week; haven't gotten chance to read ben's notes





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