[Tinyos-host-mote-wg] [Tinyos-2.0wg] 2005/05/25 Telecon Notes
Kristin Wright
l.kristin.wright at gmail.com
Tue May 31 18:09:48 PDT 2005
-------------- next part --------------
Notes from 05/25/2005 TinyOS 2.0 Working Group Telecon
05/25/2005 Agenda
-------------------
- ADC update (Jan Hauer)
- Other status items (All)
- AM layer issues (Phil Levis)
05/25/2005 Action Items
------------------------
- Phil Levis (with Jan): go over TEP 101 (ADC) and TEP 109
(Sensorboards)to ensure compatibility
- Phil Levis: will send out proposal for what address definitions
OSKI can assume
05/25/2005 Tentative Agenda
----------------------------
Not discussed.
05/25/2005 Discussion Notes
-----------------------------------------------------------------------------
ADC Update
----------
- dgay (David Gay): should put out that we've finalized the TEP; recommend that
people read and comment
-- kevin (Kevin Klues): brief summary:
- will not have an HIL by traditional sense due to the variety in the
underlying hardware; the HIL is taken over by the sensorboard TEP (109)
- instead will have 2 HALs;
- HAL1: traditional (provides all functionality)
- HAL2:
- has AcquireData parameterized interface
- still platform dependent; how you wire depends on
port (chip-independent but platform-dependent
- vlado (Vlado Handziski): opportunity to clear up confusion in TEP
sensor wrappers: very normal HIL interfaces
- dgay: need to ensure that tep 101 and tep 109 fit nicely together
- pal (Phil Levis): will do this by Sunday; will include Jan in the process
Status
-------
- kwright (Kristin Wright): sent in email
- https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000901.html
- https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000902.html
- vlado: to coordinate msp spec files with kwright
- vlado: has anyone tested TOSComm on linux?
- dgay: yes, he's been using it
- dgay: checked in packet stuff; removed dependencies on net.tinyos.message
- pal: oski: active messages, using services, next step is to
make sure services all work; basic model (instantiation
working pretty well)
- dgay: eyes radio code appearing?
- kevin: through HPL layer of radio
- done by next week
- imote2:
- tracking down a bug w/clock frequency
- not sure if hw or sw
- probably won't take much longer
- finally found the libc; gave info to kwright
Miscellaneous radio issues
------------------------------
- phil: basic question: what is the HIL to our radio? is it an AM?
with a particular address form (2 bytes) or something below
that?
- example: if my underlying mac layer has an address, is the AM address the
same, different?
- current approach: AM in HIL
- vlado: a lot of issues we have to find answers for
- start at HPL defines interaction of radio / busses
- HAL should be something that allows x-platform interfaces
- phil: how does that affect HIL decision?
- vlado: of the opinion that HPL/HAL close to hardware;
anything on top is protocol
- proposes ending with HIL way below active messages; all csma radios
have all the same HIL; another HIL for bluetooth radios
- on top of that (bluetooth/CSMA) are the protocols (AM)
- example: radioCRC and then on top we have AM
- philb (Phil Buonnadonna): include an event handler id, and packet
- dgay: and address?
- philb: no -- address can be provided by underlying layers; we've enjoyed
ordering that all the layers understand, but that ordering is
hard to maintain. If IP/zigbee become important in sensor network stacks,
this blurring could be a mistake; more strictly enforced layers
might allow greater flexibility to explore networking layers in the future
- phil: how the address is defined and at what levels the addresses are
seen not necessarily straightforward.
ex: in 15.4, only get ACK at hw level if you have the 15.4 addresses
in the chip; what's the relationship between those addresses and
AM addresses?
- it would be much cleaner if there was a separation, but blurring may
lead to greater efficiency/greater functionality
- dgay: what if the lower layers talked to AM they specify an address
as an opaque address_t type?
- should be decided and exposed at the CSMA level or we don't get ACK
- propose a strawman poll: which CSMA some size integer?
- vlado: some radios don't care
- CSMAC radio component will have to simulate them (address) to that component
- pal: with TDMA, must have address to know when to send
- philb:
- reason to balk at 2-byte thing is that we're reinventing a
network layer for tinyos;
- making the HIL as generic as possible allows the networking standard
to mature with experience
- could say it's 4 bytes address and a len, but avoid bleeding that
across the layers such that trying to put IP in wouldn't work
- dgay: even if we define an address size
- phil:
- understand concern about bleeding, but network stack is going
that way; pure layering seems untenable in the long term
- just because there's a certain HIL defined doesn't mean that it's
the *only* HIL; in fact, the platform doesn't have to provide it
ex: hamamatsu HIL, if you don't have it you don't implement the
interface
- HIL are high-level services
- can simplify declare the 'my platform is compliant with tep xyz';
if it isn't compliant with AM TEP, that's okay
- dgay:
- there could be alternative AM implementations; don't have to
commit now to a particular HIL for all radios for all time
- dgay: for this HIL that has an address, do we have a broadcast interface?
- phil: yes
- vlado: but it seems like the same case as uart; if we solve uart
with wiring, then broadcast seems analagous
- vlado: do we have an agreement on what's below the hil layer?
- dgay: up to radio
- vlado: do we want to support running different protocols
(TDMA/mac layer/physical layer)
- dgay: should answer the question: what can phil assume when
implementing oski?
- vlado: married with phy/mac/everything in one so you
have to use that; that's a problem
- phil: are you familiar with rfm radio? originally, the rfm used a similar
radio component (phy/mac/all-in-one)
- jhill decomposed stack as a result of ucla's desire to isolate and
experiment on the MAC layer; merged back in cc1000 for efficiency
- vlado: doesn't like that everything is in HIL up to app
- dgay: could have an HIL for all CSMA radios and also an AM HIL...
- phil: if you have hw support for queueing, that's going to be in your HIL;
if you don't, there's a hw-independent HIL that provides queueing
- dgay: can we just define a set of useful for more-than-one platform
abstractions and build them?
- vlado's abstraction: HIL for byte radios good but obviously not
available on all platforms
- dgay: need to define for phil what he can expect from underlying layers
- how about: oski will assume CSMA radio with address and length
- philb: does the packet include the src or dest?
- dgay: destination
- vlado: if you leave off source then acks are a problem
- phil: not sure we're going to resolve today because these decisions
will have far-reaching consequences
- will send out a proposal
- dgay: should we have a separate discussion about different kinds of radios?
- vlado: think we should std packet format just as it is now; we have
a tinyos message; everyone able to implement by defining it
- dgay: actually, msp430 and avr have different message structures
- phil: 15.4 address does not have a source
- vlado: how do they ack?
- phil: think jonathan hui said sequence numbering
- phil: will send out a proposal; proposal may take the form of
modifying TEP 05 (which has RadioPacket)
- all agree we need some ByteLevel, PacketLevel interfaces
- dgay: do we care enough about cc1000 to support in future? more a decision
in effort -- not worth doing for the cc1000.
- vlado: will get whole implementation for free from tu-berlin if we can
agree on a byte-radio HIL
- dgay: suggest we delay separate discussion about byte radio until
after pre2 release or we'll never get that done
-------------- 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-host-mote-wg
mailing list