No subject

<br>
 &nbsp;ActiveMessageC is a wrapper around CC1000ActiveMessageC;<br>
 &nbsp;You call HAL functionality on CC2500ActiveMessageC;<br>
 &nbsp;You send a packet with ActiveMessageC.<br>
</blockquote><div><br>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.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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.<br>

</blockquote></div><br><br>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&#39;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.<br>
<br>Vlado<br>

------=_Part_11796_3744994.1210952746993--