[Tinyos-devel] GenericComm

Joe Polastre polastre at cs.berkeley.edu
Wed Jun 30 15:56:50 PDT 2004


On the msp430, the UART configurations abstractions allow you to circumvent
the legacy "HPLUART" module.  There's a lot of back fill (as david says)
that should be done to make the Atmel have equally expressive interfaces,
but I know that few of us at UCB have the interest to do so.

-Joe

-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Michael
Newman
Sent: Tuesday, June 29, 2004 9:39 PM
To: 'tinyos-devel'
Subject: RE: [Tinyos-devel] GenericComm

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. 

-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Philip
Levis
Sent: Tuesday, June 29, 2004 7:17 PM
To: tinyos-devel
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 
> addressing.

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.

Phil

-------

"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
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel

_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel



More information about the Tinyos-devel mailing list