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

Stanislav Rost stanrost at csail.mit.edu
Wed Feb 16 14:46:38 PST 2005


Hey Gil,

Looks very good, and I would like to pitch in a couple of cents.

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.

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)?

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.

Stan

On Wed, 2005-02-16 at 14:06 -0800, Gilman Tolle wrote:
> Think about, and let me know:
> - Would you use this interface?
> - Does it bother you that you have to name each of your events?
> - Does it bother you that you have to define an event in the "module"
> section before you can fire it in the "implementation" section?
> - Does it bother you that you have to typedef a structure for your
> command arguments and event parameters?
> 
> Gil
> 
> =======
> 
> configuration BoringC {
>   provides interface StdControl;
> } 
> implementation {
>   components 
>     BoringM,
>     TimerC;
> 
>   StdControl = BoringM;
>   BoringM.Timer -> TimerC.Timer[unique("Timer")];
> }
> 
> module BoringM {
>   provides {
>     interface StdControl;
> 
>     // the wiring between this stuff and the components that activate them
>     // will be auto-generated at compile-time.
>     interface Attr<uint16_t> as BoringAttr @nucleusAttr();
>     interface AttrSet<uint16_t> as BoringAttrSet @nucleusAttrSet();
>     interface Command<uint16_t> as BoringCmd @nucleusCommand();
>     interface Event<uint16_t> as BoringEvent @nucleusEvent();
>   }
>   uses {
>     interface Timer;
>   }
> }
> implementation {
>   uint16_t boring = 0;
> 
>   command result_t StdControl.init() { return SUCCESS; }
> 
>   command result_t StdControl.start() {
>     call Timer.start(TIMER_REPEAT, 4096);
>     return SUCCESS;
>   }
> 
>   command result_t StdControl.stop() {
>     call Timer.stop();
>     return SUCCESS;
>   }
> 
>   command result_t BoringAttr.get(uint16_t* buf) {
>     // compute the attribute and give it back
>     memcpy(buf, &boring, sizeof(uint16_t));
>     signal BoringAttr.getDone(buf);
>     return SUCCESS;
>   }
> 
>   command result_t BoringAttrSet.set(uint16_t* buf) { 
>     // save the new value of the attribute
>     memcpy(&boring, buf, sizeof(uint16_t)); 
>     signal BoringAttrSet.setDone(buf);
>     return SUCCESS;
>   }
> 
>   command result_t BoringCmd.run(uint16_t* arg) {
>     // use the argument and take some action
>     boring = boring / *arg;
>     signal BoringCmd.done();
>     return SUCCESS;
>   }
> 
>   event result_t Timer.fired() {
> 
>     boring++;
> 
>     // signal the event with an argument attached
> 
>     // I am unsure whether an @-tag can be attached to a statement like this
> 
>     // In my preferred interface, fire() would be a varargs function
> like printf.
>     // In the meantime, you would have to fill a structure and pass
> the structure
>     // as an argument.
> 
>     signal BoringEvent.fire(&boring)
>       @nucleusEventString("This event is boring event number %d");
> 
>     return SUCCESS;
>   }
> }
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel
-- 
Stanislav Rost <stanrost at csail.mit.edu>
Computer Science and Artificial Intelligence Laboratory, MIT



More information about the Tinyos-devel mailing list