[Tinyos-devel] platforms with 4 leds

Matt Welsh mdw at eecs.harvard.edu
Sat Jun 23 05:31:43 PDT 2007

Why not have two interfaces then- one that is "best effort" (fails
silently) and one that fails if a LED is not available on the target
platform? An app that *needs* the LEDs as part of its output would wire
to the appropriate interface, thereby indicating that it shouldn't even
compile on platforms without the LEDs that it requires. 

On Fri, 2007-06-22 at 19:06 -0700, Philip Levis wrote:
> On Jun 22, 2007, at 5:58 PM, Matt Welsh wrote:
> > I actually think that fail-silent on turning on/off LEDs that don't  
> > exist on your target platform is quite reasonable (maybe a #warn  
> > directive would be good though).
> The question here is whether LEDs should be a special case.
> In TinyOS, if you don't have a hardware resource, you don't have it;  
> the system won't let you compile. For example, if you don't have a  
> radio, you can't be able to compile RadioCountToLeds. Platforms don't  
> put in dummy radio stacks and then fail at runtime. At this level of  
> granularity, it might seem pedantic, but it's an important approach  
> to making debugging systems easier. For example, you're not supposed  
> to provide a TMicro granularity timer on top of a 32kHz clock; if the  
> system actually expects a TMicro timer, then losing 5 bits of  
> granularity is going to cause it to fail at runtime in impossible to  
> detect ways.
> Given how most people use LEDs, one could argue that it might make  
> sense to special case them. If they are solely a temporary debugging  
> tool (i.e., part of active development), I'd agree. But there are  
> applications out there whose output is LEDs; knowing that they cannot  
> work properly is important for their developers as much as platform  
> designers. A simple example of this would be all of the applications  
> in apps/test, whose testing output is usually LEDs. Your application  
> will not work as intended; in some cases, the test application will  
> be useless. If someone checked in a new generic test app that used  
> the 5 LEDs of the platform they actually tested it on, then its  
> output may not be useful on those that have 3 LEDs. How are you  
> supposed to find this out? Resorting to developers catching these  
> flaws is not a feasible long-term strategy, hence the recent  
> incorporation of regression tests from RinCon and checkin build tests  
> from ETH  Zurich.
> Phil
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

More information about the Tinyos-devel mailing list