[Tinyos-devel] platforms with 4 leds

[Michael Newman]

Sounds like an excellent choice. 
 
Provides for up to 16 LEDs with a simple straightforward interface.
The platform interface for a LED defines the bit for the mask:  #define
RED_LED_BIT 0x00001
LEDs that are not implemented on a particular platform can be defined as 0.

  _____  

From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Cory
Sharp
Sent: Friday, June 22, 2007 6:20 PM
To: TinyOS Development
Subject: Re: [Tinyos-devel] platforms with 4 leds


Just my $0.02, but I've been using the "int as a bitvector" for working with
LEDs and I like it very much.  The interface looks something like this:

  // directly set the leds: off=false, true=on
  command void set( uint16_t value ); 
  
  // turn on leds where mask is true
  command void on( uint16_t mask );

  // turn off leds where mask is true
  command void off( uint16_t mask );

  // toggle leds where mask is true
  command void toggle( uint16_t mask ); 

Cory


On 6/22/07, Michael Newman <mnewman at dragonnorth.com> wrote: 

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
<mailto: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
<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/20070622/6cc632e4/attachment.html