[Tinyos-devel] Sharing interfaces below HIL

[Martin Leopold]

On Thu, 2006-10-12 at 14:20 +0200, Vlado Handziski wrote: 
> Having common interfaces does not however always mean having common
> semantics.  According to the HAA, up to the HAL level, the use of a
> HII should not be at the cost of losing functionality/performance on
> that particular hw chip/module. If the hardware is so similar that HII
> can be used without such costs, than there is no reason not to use
> them. 

I see - this was very much along the lines of what I was thinking. I
don't know the HAA by heart, so forgive me for asking - are there any
HII interfaces (other than timers) in the tos2.x tree at this time?

Btw. I couldn't fint the abbreviation HII in TEP2 - which I assume is
what you are referring to.

> I am not sure that I understand what you are aiming at. On almost all
> tinyos platforms, LEDs are connected directly to a MCU pin, so
> GeneralIO is a very natural way to _implement_ the Leds interface. But
> on some platforms the leds is active when a pin is high, on others
> when it is low, so the Leds interface implementation in the LedsP is
> different and can not be readily shared. So the issue is not only
> "agreeing on what a Led does".  Also, the current HIL assumes 3 leds,
> addressed using simple index number. But there are platforms with
> more/less leds , others might prefer a color based naming like in
> TinyOS 1.x, etc. This platform specific capability/style should be
> exported in the form of a HAL so that platform-specific applications
> can access the full capabilities of  the hardware.

I was not trying to gun down the use of LEDs, I was merely trying to
make an example. Trying to discuss the LEDs interface at the same time
was probably more confusing than anything else. What I want is
components sharing interfaces below the HIL - very much in the style
that everyone uses GeneralIO for LEDs.

About the LEDs, I can se what you are saying. At the HAL level the leds
might be named differently and what turns the leds on is different from
platform to platform (high/low).

What I was trying to say was that this could easily be made into an
interface that supports natural operations for Leds such as On/Off
instead of set/clr. The initialization could be put in "Init" instead of
makeOutput, etc. A disable method or a DummyLed component could be
created to disable the Led.

> In some cases, the chip name prefix is required in order to warn the
> user that although the interface signature is the same, the semantics
> might not be: number of states that a pin can be (is ~input=output?) ,
> whether an edge interrupt is triggered on falling/raising edge,
> required duration of pulse for level interrupts, etc. 

This makes a lot of sense, but there must be some cases in which the two
are truly identical both in terms of methods and semantics. 

-- 
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen
http://www.diku.dk/~leopold