[Tinyos-devel] platforms with 4 leds

[Vlado Handziski]

That is a viable solution. As long as the semantics for each of the two LED
interfaces at HIL level is the same across platforms, the HAA principles are
not violated.

Vlado

On 6/23/07, Matt Welsh <mdw at eecs.harvard.edu> wrote:
>
> 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
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20070623/0d00a8ff/attachment-0001.htm