[Tinyos Core WG] Binary components and TinyOS 2.0

[David Gay]

[Summary: building an external tool would make it easier to use binary
components with TinyOS 2.0. Is there enough interest to make this
worthwhile?]

nesC 1.2 and onwards support binary components, that allow a set of
nesC components to be compiled to a .o file that can then be linked
with a regular TinyOS application (or with C code, though that isn't
the issue here).

There is one significant drawback: unique and uniqueCount do NOT work
across binary component binaries, i.e., if A is an application and B a
binary component:

  A has X=unique("foo") and Y=uniqueCount("foo") somewhere in its source
  B has Z=unique("foo") somewhere in its source

then X=0, Y=1 and Z=0: the unique numbers are allocated independently
in A and B.

This is a significant problem with TinyOS 2.0 (and to a lesser extent
TinyOS 1.0), as many system components use unique to allocate
appropriately-sized resources: this happens in timers, the ADC, and
(under the hood) in the task scheduler. As is, using any of these
resources in a binary component will not work.

The fix is relatively straightforward, but somewhat painful: the
binary component B should just "use" an interface for each of the
system resources that it needs, and provide a wrapper for use in
applications that allocates and wires those resources.

For example, if B provides some interface X and needs two timers and a
task, it would look like (from the application's perspective):

  component B {
    provides interface X;
    uses {
      interface Timer as Timer1;
      interface Timer as Timer2;
      interface TaskBasic as Task1;
    }
  }

and the wrapper would be something like (this is what the application
would use):

  configuration Bwrapper {
    provides interface X;
  }
  implementation {
    components B, new TimerC() as Timer1, new TimerC() as Timer2,
      new TaskC() as Task1; /* TaskC doesn't exist, but that's easily fixed */

    B.Timer1 -> Timer1;
    B.Timer2 -> Timer2;
    B.Task1 -> Task1;
  }

However, this could rapidly become very tedious...

The suggestion is to build some dummy wrapper components for the
various system services (TimerC,  the scheduler, etc, etc), in a
readily extensible fashion so that Bwrapper can be automatically
generated.  Then binary component writers can "just" write as if the
usual TinyOS services were available.

I believe this is doable using the XML dump facilities in nesC, though
I haven't thought through all the details.

The question: is building such a tool useful enough to be worth the
effort? Who is using binary components today? Would you be interested
in helping write/test such a tool?

David Gay