[Tinyos-devel] GenericComm

polastre at EECS.Berkeley.EDU polastre at EECS.Berkeley.EDU
Tue Jun 29 00:25:49 PDT 2004


Still an ugly solution.  The only one I like is Cory Wiring because it makes the user think that they're actually controlling the application.  it also is cleaner for documenation purposes.  Overriding UARTFramedPacket (as opposed to, say, UARTPacket in TinyOS 1.1.0) is extremely confusing.  It would be nice for a user to "configure" TinyOS like they do the Linux kernel--picking and choosing which parts should be in their application.

-Joe

----- Original Message -----
From: Philip Levis <pal at eecs.berkeley.edu>
Date: Monday, June 28, 2004 3:39 pm
Subject: Re: [Tinyos-devel] GenericComm

> On Monday, June 28, 2004, at 03:24 PM, David Gay wrote:
> 
> > Philip Levis wrote:
> >> On Monday, June 28, 2004, at 02:44 PM, Joe Polastre wrote:
> >>> At one point in time (TinyOS 0.6?) we had GenericCommNoUART.  
> >>> Although I
> >>> don't really like having 15 versions of GenericComm (normal, 
> >>> Promiscuous,
> >>> TinySec, NoUART, etc), I can see a real use for being able to 
> remove 
> >>> all of
> >>> the UART components when deploying an application (especially 
> now 
> >>> that
> >>> FramerM is a huge part of the application's RAM and ROM 
> usage).  The 
> >>> problem
> >>> with enabling/disabling through an interface is that it won't 
> be 
> >>> removed
> >>> from the code; on the other hand, having separate 
> configurations is 
> >>> really
> >>> ugly and causes problems when you try to have two types of 
> >>> GenericComms in
> >>> an application.
> >> I'd think that the answer is for an application to have its own 
> >> GenericComm, which is the same as the normal one, with the UART 
> cut 
> >> out. This would require AM to have defaults for sending to the 
> UART. 
> >> Putting this into the app directory should change everything 
> just 
> >> fine. Alternatively, the app GenericComm could also have an app 
> >> AMWhatever that doesn't test on address and sends UART packets 
> to the 
> >> radio. The only other solution is to put it in a separate 
> directory 
> >> and include that directory in your -I path.
> >
> > 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).
> 
> Agreed.
> 
> 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
> 



More information about the Tinyos-devel mailing list