[Tinyos-8051wg] [Tinyos-2.0wg] 5/11/2005 2.0 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Fri May 13 14:36:36 PDT 2005
-------------- next part --------------
Notes from 05/11/2005 TinyOS 2.0 Working Group Telecon
Present:
Phil Buonnadonna (Intel Berkeley), David Culler (UCB) David Gay (Intel
Berkeley), Jonathan Hui (UCB), Ben Greenstein (UCLA), Joe Polastre
(UCB), Cory Sharp (UCB), Gilman Tolle (UCB), Martin Turon (Crossbow),
Kristin Wright (UCB)
05/11/2005 Agenda
-----------------
- Status
- A/D conversion (TEP 101), Sensor board (TEP109) revision
- Misc. issues rising from implementation experience
05/11/2005 Action Items
-----------------------
- Cory: update Timer TEP to reflect recent Timer changes
- Martin & Phil B: look at interfaces in SPIPacket, I2CPacket,
SPIPacketAdvanced
- Joe & Cory: send out an email on new uwait implementation
proposal/info, or Cory will possibly implement for telos
and send out pointer
- David Gay will discuss error conventions, initialization
with Phil Levis
05/18/2005 Tentative Agenda
----------------------------
05/11/2005 Discussion Notes
----------------------------------------------------------
Status
- telos:
ADC/Timer/Radio stack
- Stack unchanged since last week meeting; Joe busy w/end-of-
classes tasks which have now ended
- philb: *will* be using Joe's stack
- joe: biggest change to be made will be to adjust the bus
arbitration-related code, don't have it yet but changes
should be easy;
- philb: arbitration only necessary on those platforms
which share pins, yes?
- joe: yes; the stack code will have the arbitration code
in it; theoretically, the code will compile to nothing on
platforms which don't require arbitration
- Cory sent an update to the mailing list on timer changes;
will update the timer TEP today to reflect those changes
- mica:
- dgay: sort of working radio stack and sort-of working
ADC and Timer; missing the upper layers to test it
thoroughly
- joe recommends contrib/ucb/apps/CountRadio as higher-level
app
- dgay: will talk with Phil Levis about status of higher-level
apps
- martin: saw a lot of mica platform code being committed; what is
working and what's not
- dgay: all tested, though not strenuously; has an adctest (receives
a plausible value) radio test (sends a packet successfully
to tinyos-1.x tosbase and vice-versa)
- joe: have you built abstract radio types?
- dgay: not implemented; wanted to talk to joe & phil before implementation
- dgay: a-to-d status: still needs work
- other mica:
- martin: mica timers done; lower-levels basic, used cory's
tested 16-and 8-bit timer; didn't check in an extensive unit test for every
register pair. implemented 1st-pass hw i2c and have a spi module; looking
into wiring spi module to cc2420.
- dgay: does someone want to work on i2c bus tep?
- joe: has committed stuff that looks like i2c and spi, will work on it perhaps
later but all agreed that radio stack would be 1st priority
- joe: can look at SPIPacket, I2CPacket, SPIPacketAdvanced for what is
implemented now; checked into tos/interfaces
- dgay: martin & phil b: look into interfaces
- philb: is radio stack going to use request interface proposed by denmark?
- joe: my notion is that that will sit above radio stack.
- dgay: not going to get 5/15 target date, how about 5/30?
- will shoot for 5/30
A-to-D discussion
-------------------
- deferred since tu berlin couldn't be present today
Miscellaneous issues
--------------------
- see issues discussed below enumerated here:
https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000827.html
- TOSH_xxx functions: are we trying to get rid of all of these?
- general agreement: get rid of them
- joe: might want to take a look at tos/interfaces/GeneralIO.nc
and implementation in tos/chips/msp430 (converts msp pins to
hw-independent names)
- dgay: may want to have a tep on pins
- uwait: busy wait n microseconds?
- general consensus was that people would like the functionality,
but only if it's implemented right
- joe: yes do want, if wrapped in a timer interface
- uwait: joe and cory will send out an email on what the proposal
will take
- martin: will it be split-phase?
- cory: no , supposed to be a busy wait
- dgay: can we make it a function implemented by timer system?
- culler: functions must be just functions; shouldn't have tasks/commands
- dgay: should be self-contained
- culler: general notion: component abstracts functionality and state;
could argue a random number gen is much more that way
- joe: nice thing about a component rng is that you can
change which you use just by rewiring
- dgay: different because rng has state
- cory: cpu freq changes w/temperature drastically;
- dgay: any high freq timer clocked off cpu so would have same drift
- joe named a platform that is not clocked off cpu
- martin: implemented in some way that doesn't interfere w/anything in
hpl that hpl claims to own
- dgay: seem to agree makes sense that uwait offered by timer subsystem
- martin: utility functions shouldn't have hw state; shouldn't be
dependent on state of hw ina way that would change component control
- dgay: cory would you like to implement for telos?
- Post results have changed incompatibly (0 went from failure to success)
oops (note that the language specifies that post returns a boolean)
- dgay: error_t vs result_t
- joe: if we're going to stick to errors, need to stick to == SUCCESS
- dgay: so post just another example and we'll live with it
- dgay: will talk to Phil L. about clearing up some tep/convention about
error codes
- Initialisation, etc:
- Who is responsible for calling StdControl/SplitControl? (the app?)
- Who is responsible for wiring Init interfaces to Main.SoftwareInit?
- nesc1: warning: calls to SoftwareInit.init in RealMain are uncombined
- error_t doesn't have combination fucntion:
- both success: success / both same failure get that / different failure, get
some 3rd
- and who is supposed to be initing? generic components complicate situation;
- joe: init only called at boot
- dgay: won't components wire themselves to init?
- cory: that impl wires to init
- dgay: if you mention a timer, presumably it needs to be inited so it inits itself;
thought init was supposed to be self-contained (doesn't refer to other components);
stdcontrol does "start my timer"
- dgay: will talk to phil levis
- Minor A/D issues:
- should AcquireData be AcquireData<uint16_t> ? (and so on)
- should A/D readings be left-justified at the HAL level too? (the
ATmega128 has a h/w flag for this...)
- dgay: acquired: uint_16s; thought about acquiring data of any
particular type (do we expect to be acquiring 32-bit samples from
16-bit -- makes interfaces more generic
- joe: as long as it prevents you from wiring to wrong width, good
- dgay: which is more portable?
- martin: cast to width you expect and at higher-level ...
- phil b: duplicitous interfaces; default and sister -- thinks we should
go with one or the other -- is it a flexible type or not otherwise we
have interface bloat
- phil: make alarm also have in it a size type;
- phil: having flexibility to specify size types across the whole thing
seems useful
- cory: could be a barrier-to-entry
- phil b: found the duplicitous made the barrier-to-entry high
- dgay: but what about acquire data? will change it and if people hate it
we'll change it back
- CastTimerM.nc(TimerMilliC.CastTimer):55: warning: `Timer.fired'
called asynchronously from `TimerFrom.fired'
- cory: aware of it and addressing 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
More information about the Tinyos-8051wg
mailing list