pal at eecs.berkeley.edu
Tue Jun 29 10:22:44 PDT 2004
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 GenericComm.
> 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 after
> 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 saw
> that Chirp was no longer an application--can anyone explain why?).
> Creating the NoUART application allowed me to debug that the UART was
> the culprit; but it also made me realize that there are things in
> GenericComm that people won't actually want if they're not researchers
> (in other words, people deploying applications or products). Having a
> configurable, small set of TinyOS primitives to support the original
> 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 nesc
> deps make target helps with this (its basically a hack to figure out
> what's in the app after the fact) but more support is necessary imho)
I think part of the problem here is that the UART used to be a very
small component in terms of RAM, but has grown into a reasonably large
one. A lot of components grew in the TREMENDOUS ROOMINESS of 4K.
GenericCommNoUART/Chirp/etc. were removed from the main repository to
clear up some of the clutter. I think they've been gone for ~2 years
now (tinyos-1.0). I'd argue that, since a need for them hasn't emerged
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 back
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 either
source as to wire two receives, and make the compile-time decision of
which path to send a packet along. It's like having a loopback address
(127.0.0.1). But, it also abstracts away some important details, like
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 my
intuition is that UART/Radio mux/demux should occur *above* AM, as
UARTs behave very differently in terms of group, etc.
"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'
More information about the Tinyos-devel