I fully agree, and the question is not philosophical. The TinyOS HAA
defines two well-defined taping points for the application into the driver
code: the HAL and the HIL level. Consequently, the public interfaces at both
the HAL and the HIL level have to be documented and accepted through the TEP
One of the interesting aspects of NesC is that it doesn't enforce any
specific kind of encapsulation of interfaces. That is, an application
component can poke through the various layers below it to get at an
interface provided by a deeper underlying component. In this case you
propose to
I think each documentary TEP refers to the release version number so
even if the interfaces get added to the head of the CVS, I don't see
that as a problem. In theory, such interface change will be discussed
when a new TEP is written to document a new release. This brings up
another point - when
Matt and Phil -
This is meant to serve only as a private interface within the CC2420 stack
right now, not an interface provided by the ActiveMessage façade. After
all, once the interface is provided by ActiveMessage, it is no longer a
private CC2420-specific interface.
This is absolutely not a
On Feb 7, 2008, at 6:00 AM, David Moss wrote:
Matt and Phil -
This is meant to serve only as a private interface within the
CC2420 stack
right now, not an interface provided by the ActiveMessage façade.
After
all, once the interface is provided by ActiveMessage, it is no
longer a
While I like this idea, are we going through a TEP vetting process
before adding new calls in the radio stack interface? I could think of
a lot of things that one might want to add to the CC2420 radio stack
but I thought the idea of the TEP process was to air these ideas
through feature
On Feb 6, 2008, at 2:10 PM, Matt Welsh wrote:
While I like this idea, are we going through a TEP vetting process
before adding new calls in the radio stack interface? I could think
of a lot of things that one might want to add to the CC2420 radio
stack but I thought the idea of the TEP
