[Tinyos-devel] Proposed interface for Nucleus attributes, events, and commands

Gilman Tolle gilman.tolle at gmail.com
Wed Feb 16 16:28:43 PST 2005

> Do you think that perhaps Nucleus events etc. should be a property of
> interfaces, rather than modules?  That seems to make a bit more sense in
> many cases, although it might require more language support.

I'm not sure what you mean. A Nucleus attribute must be made available
by some module containing actual code, just like a Nucleus event or
command only has meaning to a module.

> Typedef'ing a structure for arguments seems reasonable.   But, will
> there be any way of supplying variable-length blobs (i.e. a bunch of
> bytes and their length)?

That's an interesting point. I would suggest this: at compile time,
the sizes of all event parameter sets, command argument sets, and
attributes should be known. This makes calling commands and parsing
events much easier. For example, even in a single printf statement,
the total length of the argument values is still known at compile
time, as is their order, size, and type.

If you want to send something of variable length, perhaps you could
typedef a structure containing a char array large enough to contain
the largest data item you would send, set the type of the event to be
that type, and then manage the storage yourself. This approach
wouldn't save any bandwidth or flash space, though, because you have
no way of telling the other side that "this time, it's smaller."

> And finally, some comments about naming.  I would call the Attr
> interface AttrGet, just for consistency.  The Event and Command
> interfaces are clearly the Nucleus counterparts to the NesC constructs,
> but maybe the names should be different so that, for example, when
> you are explaining the code to someone, you wouldn't have to refer
> to them as "Nucleus events" and "Nucleus commands."  Maybe something
> like RemoteCall and Trigger could be used instead.

Hmm. It may be easier to learn if users can build an analogy between
TinyOS events from components to other components and Nucleus events
from a mote to a remote host. Think of it as an "RPC" approach -- the
application programmer isn't really supposed to be constantly reminded
of the fact that it's not a local function call.


More information about the Tinyos-devel mailing list