On Wed, Sep 15, 2010 at 3:46 AM, Roger Larsson <[email protected]> wrote:
> I have been fighting this as well (see my mail Multichannel Oscilloscope try 
> to compile with SENSOR_ARRAY
> http://www.mail-archive.com/[email protected]/msg34868.html 
> )
>
> Lets take this question to tinyos-devel
>
> My guess is that the compilers does not support this - it could, since code 
> could be generated statically.

There's no compiler/language problem. See below for a description of
the fix (and the related misunderstanding).

> Från: [email protected] 
> [[email protected]] f&#246;r Anna Förster 
> [[email protected]]
> Skickat: den 15 september 2010 11:23
> Till: [email protected]
> Ämne: [Tinyos-help] parametrized interfaces : an array of timers
>
> Dear all,
>
> I have some troubles implementing a parametrized interface of Timers. I have 
> used the code snippets from "Software design Patterns for Tinyos" from Gay et 
> al. and some hints online and from this mailing list. I am attaching the 
> complete code (it is basically the Blink application with an array of 3 
> timers). When compiling, the error is:
>
> In component `BlinkC':
> BlinkC.nc: In function `Boot.booted':
> BlinkC.nc:51: Timers.startPeriodic not connected
> BlinkC.nc:52: Timers.startPeriodic not connected
> BlinkC.nc:53: Timers.startPeriodic not connected
> make: *** [exe0] Error 1
>
> I found a hint on this mailing list from Phil Lewis that I need a default 
> implementation for the event, but this hint leads to yet another compilation 
> error, saying:
>
> In file included from BlinkAppC.nc:45:
> In component `BlinkC':
> BlinkC.nc:61: `fired' is defined, not used, in this component
> BlinkC.nc:61: (default implementations are only for used commands or events)
> BlinkC.nc:61: conflicting types for `Timers.fired'
> BlinkC.nc:56: previous declaration of `Timers.fired'
> make: *** [exe0] Error 1
>
> I would be very thankful for any ideas of how to get this wokrking. And, yes, 
> I am sure I need such a parametrized interface (not for the Blink 
> application, of course.. ) :-)
>
> Anna
>
> CODE
> ____
>
> ##############################
> BlinkAppC.nc:
> ##############################
>
> configuration BlinkAppC
> {
> }
> implementation
> {
>  components MainC, BlinkC, LedsC;
>  components new TimerMilliC() as Timer0;
>  components new TimerMilliC() as Timer1;
>  components new TimerMilliC() as Timer2;
>
>
>  BlinkC -> MainC.Boot;
>
>  BlinkC.Timers[0] -> Timer0;
>  BlinkC.Timers[1] -> Timer1;
>  BlinkC.Timers[2] -> Timer2;
>  BlinkC.Leds -> LedsC;
> }

All good...

>
> ##############################
> BlinkC.nc
> ##############################
>
> #include "Timer.h"
>
> module BlinkC @safe()
> {
>  uses interface Timer<TMilli> as Timers[int id];
> //  uses interface Timer<TMilli> as Timer1;
> //  uses interface Timer<TMilli> as Timer2;
>  uses interface Leds;
>  uses interface Boot;
> }
> implementation
> {
>  event void Boot.booted()
>  {
>   call Timers.startPeriodic[0]( 250 );
>   call Timers.startPeriodic[1]( 500 );
>   call Timers.startPeriodic[2]( 1000 );
>  }
>
>  event void Timers.fired[int id1]()
>  {
>    int id = 0;
>  }
>
> /*default event void Timers.fired() { } */

The thing that needs a 'default' implementation is startPeriodic.
Think of what happens in the code:

1. You're calling the startPeriodic command on some interface in the
Timers "parameterized interface", passing in an expression 'e' to
specify which interface you want (in this code, e is respecticely 0,
1, and 2 but in general could be any expression).
2. The implementation must evaluate e (at runtime) and dispatch to the
interface you wired to (so, in general, the compiler has no idea what
values e might take).
3. What should it do if e happens to evaluate to some value for which
there's no corresponding interface wired in BlinkAppC? The answer is
call a "default" implementation that you specified (this can do some
default handling, report an error, etc).

So the fix is to add:

  default command Timers.startPeriodic[int id](int interval) {
    ... complain/handle/ignore unexpected call ...
  }

Note that it would of course be possible to write an analysis that
detected that in this particular program there's no need for a
"default" startPeriodic command. However that would be a bad idea (in
general at least), as:
- it makes BlinkC less of a standalone component (the missing
startPeriodic command will be needed for some wiring patterns)
- it makes code's correctness quite dependent on exactly what analysis
is performed in the compiler to detect when default commands/events
are not required (should 'for (i = 0; i < 2; i++) call
Timers.startPeriodic[i](...);' work too?)

David Gay

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to