[Tinyos-devel] TEP116 HIL/HAL discussion

[Vlado Handziski]

On Fri, May 16, 2008 at 5:20 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On May 16, 2008, at 1:39 AM, Vlado Handziski wrote:
>
>  HIL is a layer, take a look at the HAA paper, the TEP, etc. There can be
>> components in this layer with platform specific interfaces. And nothing
>> prevents users to tap both at the HIL interfaces exported from a
>> ActiveMessageC component and to the HAL hardware specific interfaces
>> exported by another component.
>>
>
>
> Vlado, I don't think the TEP or paper say what you think they do:
>
> TEP 2 and EWSN 2005:
>
> "The final tier in the architecture is formed by the *HIL* components
> that take the platform-specific abstractions provided by the *HAL* and
> convert them to hardware-independent interfaces used by cross-platform
> applications."
>
> "When the capabilities of the hardware
> exceed the current API contract, the *HIL* "downgrades" the
> platform-specific abstractions provided by the *HAL* until they are
> leveled-off with the chosen standard interface. "
>

Well, they say what I think now and what I though when I wrote them, modulo
the fact that English is not my native language.


> From a programming standpoint, there is a reason why you should not tap
> both the HIL of ActiveMessageC and the HAL of an underlying chip: you have
> no assurance that the HIL refers to that chip. In practice today,
> implementations definitely ignore this point (e.g., mlqi), but mostly
> because the AM services are in system/ and not wrappers around chip-specific
> services. E.g., this case:
>
>  ActiveMessageC is a wrapper around CC1000ActiveMessageC;
>  You call HAL functionality on CC2500ActiveMessageC;
>  You send a packet with ActiveMessageC.
>

It is up to the platform code to sort such hypothetical two radio chips
problem. Anyhow, there is explicit section in the paper saying how sometimes
it might be beneficial to use both the HIL and the HAL of a given
abstraction. This will make the overall application non-portable, but limit
the non-portability only in the code interfacing the HAL. But this is not
the root of our misunderstanding.


>
> The purpose of this section in TEP116 had been to specify the naming and
> signature of active message communication in a radio-chip specific way. This
> enables applications which are willing to bind to a specific radio chip to
> use the advanced features of that radio which the HIL does not include. The
> most trivial case of this for the CC2420 is the LQI field.
>


That is all fine under the assumptions that AM is a proper radio HIL, that a
radio HAL should have AM interfaces plus some other chip specific ones. As I
said at the beginning of the thread, I did not want to open the can of worms
called radio HAL here, but Jan and Miklos already did. My position on this
is clear, I don't plan to repeat it now (anyone interested can do a search
in the archives of the tinyos-2wg on radio HIL -- the interesting bits are
in January 2005). HAA is for hardware drivers, and misusing its terminology
beyond its original intention is what brings all this confusion.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080516/f8f8f75d/attachment.htm