mnewman at dragonnorth.com
Tue Jun 29 21:39:04 PDT 2004
There are other more important reasons to have a component that supports the
UART. The UART component will then allow a programmer to use the UART for a
different purpose. I remember having to write my own UART support when I
wanted to connect a GPS to the system. I also had to rewrite GenericComm to
get it to stop listening to the UART.
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Philip
Sent: Tuesday, June 29, 2004 7:17 PM
Subject: Re: [Tinyos-devel] GenericComm
On Tuesday, June 29, 2004, at 10:46 AM, get at eecs.berkeley.edu wrote:
> 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 guess what I was thinking is that GenericComm would have a module to
dispatch based on address. This module sits on top of two AM
components: one sits on top of the UART, the other on top of the radio.
The two behave a bit differently; the radio one filters based on
address and group, while the UART one does not (rewrites address/group
to match the mote).
I'm just generally arguing for more finely grained components. Our
direction right now seems to be towards small numbers of large
components, and that really makes adaptation difficult in the long run.
> 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.
I don't think there's a right answer to this question. In some
situations, dispatching based on address is preferrable; in others,
requiring explicit dispatch based on interface is better. If you factor
the components carefully, though, then you can do both. Following the
above example, if the components were written right, an app writer
could either wire to RadioComm and UARTComm both, only RadioComm, or
GenericComm. Of course, if a system expects to be able to use the UART
and wants addressing correspondingly, then you have to jump through
hoops to prevent it.
I think this just comes down to the basic tension between component
encapsulation and global system definition. A component should be able
to say it wants GenericComm without an app writer having to worry about
it. But if an app writer doesn't want the component to use the UART,
the situation becomes more complicated.
> 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.
Group ID is really sketchy these days, especially now that we have the
ability to change frequencies.
> 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
True. I think it's something that would be great to sit down and think
about when mapping out the next gen architecture. There are a lot of
options and possibilities, and it would be nice to work through a few
to get a better idea of pros and cons. Certainly, this could be more
fruitful with help from Scott and Ion.
"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."
- T. S. Eliot, 'Little Gidding'
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
More information about the Tinyos-devel