get at EECS.Berkeley.EDU
get at EECS.Berkeley.EDU
Tue Jun 29 10:46:32 PDT 2004
----- Original Message -----
From: Philip Levis <pal at eecs.berkeley.edu>
Date: Tuesday, June 29, 2004 1:22 pm
Subject: Re: [Tinyos-devel] GenericComm
> On Tuesday, June 29, 2004, at 12:36 AM, polastre at eecs.berkeley.edu
> > There's pluses and minuses to this...
> > If you force the user to wire up GenericComm as they see fit,
> its is
> > more complicated and takes away then "Generic" meaning of
> > On the other hand, it solves the problem that we can have an
> > application force GenericComm to not use the UART/FramerM code.
> > I should probably give some background--originally this issue
> came up
> > because I couldn't get the Telos motes to consume under 120uA
> > the radio was turned on. The problem was in how the UART stack
> > started() and stopped() the UART module and so I changed the
> > underlying UART msp430 components. Additionally, I created a
> > GenericCommNoUART after I was surprised that it no longer
> existed in
> > the repository (I had much the same reaction after I looked and
> > that Chirp was no longer an application--can anyone explain
> > Creating the NoUART application allowed me to debug that the
> UART was
> > the culprit; but it also made me realize that there are things
> > GenericComm that people won't actually want if they're not
> > (in other words, people deploying applications or products).
> Having a
> > configurable, small set of TinyOS primitives to support the
> > ideals (small size, componentized, etc) would allow for such
> > applications. It would also increase the predicabi
> > lity of the application if you knew what was compiled in (Cory's
> > deps make target helps with this (its basically a hack to figure
> > what's in the app after the fact) but more support is necessary
> I think part of the problem here is that the UART used to be a
> small component in terms of RAM, but has grown into a reasonably
> one. A lot of components grew in the TREMENDOUS ROOMINESS of 4K.
> GenericCommNoUART/Chirp/etc. were removed from the main repository
> clear up some of the clutter. I think they've been gone for ~2
> now (tinyos-1.0). I'd argue that, since a need for them hasn't
> until now, due to a new platform that none of us really could have
> anticipated, that was probably a good idea. We can always put them
> in. *shrug*
> There are pros and cons to having a UARTSend over a
> Send(TOS_UART_ADDRESS). The former allows you to more easily
> remove the
> UART component as well as have communication parallelism (e.g., AM
> currently locks on either path, you can't do both at once).
> However, it
> also means that a component which could receive packets from
> source as to wire two receives, and make the compile-time decision
> which path to send a packet along. It's like having a loopback
> (127.0.0.1). But, it also abstracts away some important details,
> the fact that it's not a shared channel with the radio, which can
> be an
> issue with snooping protocols. I think it could go either way, but
> intuition is that UART/Radio mux/demux should occur *above* AM, as
> UARTs behave very differently in terms of group, etc.
Do you mean to say, by "above AM" that AM's dispatch filters should only be applied _after_ the selection of an interface? If so, then I agree. The only dispatch AM does on send is to divert UART-addressed messages to the UART, and it actually hides information on receive by disguising the interface over which the message arrived. Positioning AM after interface selection would remove both the special case on send and the information-hiding on receive, as well as solving the parallelism issues you mentioned.
I agree that having to wire two interfaces could be a burden on the programmer. But, creating a separate component whose only purpose is to unify receptions on multiple interfaces would give the programmer the option of only wiring one component, at the cost of losing interface information.
What's really needed here, in my opinion, is some more thought about the addressing system, especially at the border between mote patches and PCs. Internet-scale applications provide both transparent bridging, which is effectively name-free, and switching performed by associating an address with each interface, and selecting interfaces by matching prefixes of the destination name. Our system is in a slightly uncomfortable middle ground, with single-destination scoped addresses for one interface and address-obliteration for the other. From the bridging perspective, TOSBase acts as a dedicated bridging application that paradoxically assigns the bridge an address at compile-time, making link-layer acknowledgements impossible if the destination address of the message being bridged is not that of the bridge itself. Additionally, there is no reason that our address system couldn't support limiting message reception by prefix, and if the group ID is considered to be a statically as
signed prefix of a mote's address, we already do this in a limited way.
The IP method of assigning an address to each interface, allowing applications to reconstruct the incoming path from the destination address of the incoming message, selecting an outbound interface by prefix matching, and selecting a receiver set by additional prefixing may offer some insight into an alternate model for Sensor-Net Protocol addressing.
More information about the Tinyos-devel