[Tinyos-devel] platforms with 4 leds
mnewman at dragonnorth.com
Sun Jun 24 19:59:50 PDT 2007
I agree with Philip about the problems of failing silently and think that we
should eliminate those problems by producing warnings when an unimplemented
LED is used.
I think that two interfaces would not be the best implementation. The user
of the interface might be a middle tier service that does not, and should
not, know or care if the application permits a particular LED to be missing
or not. This knowledge belongs only to the highest level of the application.
The best implementation in my opinion would be a single interface and would
throw warnings if the application used an LED that did not exist. Then at
the highest level the application can declare which LEDs it is permitted to
have an empty implementation for, which turns off the warnings.
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Matt
Sent: Saturday, June 23, 2007 8:32 AM
To: Philip Levis
Cc: TinyOS Development; Cory Sharp
Subject: Re: [Tinyos-devel] platforms with 4 leds
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.
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
More information about the Tinyos-devel