[Tinyos-devel] TEP116 HIL/HAL discussion

[Jan Hauer]

my 2 cents: like for the other chips the radio stack should be
structured into HPL, HAL and HIL; traditionally (in my interpretation)
the HIL has been ActiveMessage, single-hop unreliable communication
through platform-independent AM interfaces. The problem that I have
encountered with our 15.4 MAC implementation is: where would be the
right level of abstraction for a platform-indepentent MAC
implementation? Obviously it cannot sit on top of ActiveMessage, but
wiring it to a radio HAL ("driver") makes it hardware dependent. My
interpretation of HAA is that ideally a radio HAL should expose *all*
capabilities of the hardware and a radio HIL should provide a set of
platform-independent interfaces so that *MAC protocols* can sit on top
of this HIL. MAC protocols would then provide their MAC-specific
interfaces and for every MAC there would be a MAC/LL HIL on top, which
is AM. I.e. two HILs, one for the radio chip and one for the
communication link.

One might argue that there cannot be a "radio chip HIL" with different
platform-independent MAC protocols on top, because MAC  performance is
crucial and we cannot accept the abstraction penalties here. This
would be too bad, but then -even more- a radio chip abstraction must
provide at least a proper HAL. This is currently, at least for the
CC2420 stack, not the case: e.g. how would you write a TDMA MAC on top
of CC2420TransmitC? CC2420Transmit.send() gives you no control over
when the packet is actually put on the channel... practically, for my
15.4 MAC implementation this meant, that I had to adapt the CC2420
"driver" before I could start with the actual MAC implementation
(which is ugly, because there will be code duplicatation). It's
definitely worth thinking about how we can decouple the radio chip
abstractions from the specific MAC protocols that have accumulated
under chips/ (and if we follow the first approach then MAC protocols
don't belong under chips/, but rather in something like tos/lib/mac).

Jan


On Fri, May 16, 2008 at 10:39 AM, Vlado Handziski
<handzisk at tkn.tu-berlin.de> wrote:
> On Fri, May 16, 2008 at 1:19 AM, Philip Levis <pal at cs.stanford.edu> wrote:
>>
>> On May 15, 2008, at 11:55 AM, Vlado Handziski wrote:
>>>
>>> It is a component belonging to the HIL layer. Again, there is a
>>> difference between the platform independent interface at the top of
>>> the HIL and the component composition forming the HIL layer  and by
>>> HIL layer component one understands all components used to transform a
>>> HAL into this final platform independent interface.
>>
>> I disagree; CC2420ActiveMessageC can't be an HIL, as it has
>> hardware-specific interfaces. The precise purpose of this section in 116 was
>> to allow programmers to use active messages while being able to use
>> chip-specific features (e.g., channel selection, transmit power, etc.).
>
> It is obvious that we are not coming to a consensus here, so this is my last
> mail on the topic. 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
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>