[Tinyos-devel] GenericComm

polastre at EECS.Berkeley.EDU polastre at EECS.Berkeley.EDU
Tue Jun 29 00:36:03 PDT 2004

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)


----- Original Message -----
From: get at eecs.berkeley.edu
Date: Monday, June 28, 2004 8:49 pm
Subject: Re: [Tinyos-devel] GenericComm

> Does anybody remember why the decision was made to hide the UART 
> interface behind a "magic address"?
> Giving each interface its own separate communications component 
> seems to make more sense. Users could wire the UART component if 
> they needed it, and could later wire a stub component like NoLeds 
> to disable it. A higher-level layer could wire both, and then use 
> its own logic to decide where to send packets.
> This would have the added benefit of enabling the UART to actually 
> carry addresses of its own, for transparent forwarding of 
> messages, or for distinguishing between multiple listeners on the 
> PC side of a SerialForwarder. Granted, nobody does this now, but 
> isn't it time that our PCs stopped being nameless hangers-on in 
> mote-space?
> But as memory-saving short-term measures go, David's sounds great.
> Gil
> ----- Original Message -----
> From: Cory Sharp <cory.sharp at gmail.com>
> Date: Monday, June 28, 2004 6:30 pm
> Subject: Re: [Tinyos-devel] GenericComm
> > David's is the best yet. :)
> > 
> > On Mon, 28 Jun 2004 15:24:29 -0700, David Gay <dgay at intel-
> > research.net> wrote:
> > > 
> > > The slightly simpler approach is for the application to have 
> > it's own
> > > UARTFramedPacket which just drops the packets (or passes them 
> > onto the radio if
> > > you really want).
> > > 
> > > David
> > _______________________________________________
> > 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