[Tinyos-devel] platforms with 4 leds

[Michael Newman]

Why not implement LEDs as an array (or parameterized type) where the size of
the array is platform dependent. All of the services are generic and take an
array index. The HIL then handles an arbitrary number of LEDs.

Then the names for the particular colors are then just indexes to the array.
An index that is out of bounds for the array can be defined, can have
associated calls, and results in the appropriate 'do nothing' result.

You would get calls like:

	call Leds.toggle[RED_LED]();

Which could get bound at a higher level without the argument.

-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Philip
Levis
Sent: Friday, June 22, 2007 12:09 PM
To: Jan Beutel
Cc: TinyOS Development
Subject: Re: [Tinyos-devel] platforms with 4 leds

On Jun 21, 2007, at 2:59 PM, Jan Beutel wrote:

> while reviving the btnode3 platform support i created a patch to  
> support
> 4 leds (yes there are such paltforms) and added this to app/Blink.
>
> as i can't compile all platforms i am not checking it in yet... maybe
> some of the more exotic platform maintainers can check this out and  
> let
> me know if things work out. i have tried mica2 and mica2dot, telos and
> btnode3

There are also platforms that have more than 4 LEDs... the Dust Blue  
mote, for example, had 7. The mica2dot, on the other hand, only has 2  
(or am I mistaking it for the dot)?

We've run around in circles on the LEDs question a lot. The  
conclusion was as Vlado says; the HIL is three LEDs, and platforms  
that have more can have an HAL. It's better to have an HIL that is a  
least common divisor than one which covers all cases but is partially  
non-functional.

One direction the discussion went down was having an individual  
interface per LED. It seemed like three wirings just to blink three  
LEDs (or 4 for 4) was really overkill, though. This led to the  
discussion of whether there should be an interface hierarchy  
abstraction in nesC. E.g., you can have an interface which is made up  
of sub-interfaces:

interface Leds {
   interface Led as LedOne;
   interface Led as LedTwo;
   interface Led as LedThree;
}

but the consensus was that such a narrow case didn't quite motivate  
such a large language change.

Please don't patch the Leds interface.

Phil
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel