[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] TinyOS Telecon Notes 8/31/05

[Philip Levis]

On Sun, 2005-09-04 at 23:09 +0200, Joe Polastre wrote:
> Let me propose an alternative method:
> 
> Components automatically return to their lowest power state after a
> timeout.  If you want to keep the component running, you must "ping"
> it.  I've been experimenting with this method and it is much more
> robust and effective than anything we have in TinyOS 1.x today, and
> its simple to implement.

Cory and Rob have been mumbling a bit about this approach. I think it
sounds like a good idea, but also think that it's outside the core. That
doesn't mean it doesn't have a place in the WG (OSKI does, after all),
just that we need to make the distinction clear.

It's important to separate policy and mechanism. Timeouts are a
perfectly reasonably policy for power management, but first we need to
decide what the underlying mechanism is. The mechanism must be able to
support as wide a range of policies as possible (timeouts, explicit
control, implicit based on requests, etc.). 

I'd argue that the TinyOS core should neither require nor define a
specific policy. Instead, the power management policy should be the
province of a service distribution. The moteiv distribution could follow
a timeout policy, while OSKI follows an explicit-control-OR policy. The
presence of generic components makes policy layering really easy:

configuration MoteivAM {
  provides {
    interface MoteivWakeup; // For pinging
    interface AMSend[am_id_t id];
    interface Receive[am_id_t id];
    interface Packet;
    interface AMPacket;  
  }
}
implementation {
  components new MoteivPowerTimeout(<some constant?>), ActiveMessageC;
  components MainC;
  
  MainC.SoftwareInit -> ActiveMessageC;

  MoteivWakeup = MoteivPowerTimeout;
  MoteivPowerTimeout -> ActiveMessageC.StdControl;

  AMSend = ActiveMessageC;
  Receive = ActiveMessageC;
  Packet = ActiveMessageC;
  AMPacket = ActiveMessageC;
}

The discussion so far is really about the mechanism, specifically, the
mechanism for the MCU deciding what sleep state to enter. Some platforms
introduce complexities that something like a 128 or MSP430 don't have to
really deal with (e.g., wakeup latency).

> My worry with the "fan out" approach is: What happens if I forget to
> include a component?  This solution potentially gets very fragile.

If you do the wiring/configurations right, this shouldn't be an issue.
Including a subsystem would automatically wire it in.

Phil



_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg