[Tinyos-devel] platforms with 4 leds

[Philip Levis]

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