[Tinyos Core WG] Boot Order

[Martin Turon]

Is the nesC call order guaranteed to be the order of the wiring lines in
the configuration?  I know this is how it works in practice, but I
thought it was not strictly defined behavior in the language
specification.

The other method is to have one .Init which does explicit calls to each
of the lower level components.  This certainly bloats the code however
because you have to:

1) Wire in the config (+2-3 lines per module)
2) Add using interface lines to the module (+1-2 line per module)
3) In the top-level module.Init, call them all in order: (+1 line per
module)

  call NonVolatileStore.Init()
  call RadioLow.Init()
  call Mac.Init()
  call AppDriver.Init()

  ...

Kind of defeats the purpose of just "wiring in" to Boot...

Martin 

__________________________________________________
Martin Turon  |  Crossbow Technology, Inc.


-----Original Message-----
From: tinyos-2.0wg-bounces at millennium.berkeley.edu
[mailto:tinyos-2.0wg-bounces at millennium.berkeley.edu] On Behalf Of Kevin
Klues
Sent: Wednesday, May 21, 2008 3:24 PM
To: David Moss
Cc: TinyOS Core WG
Subject: Re: [Tinyos Core WG] Boot Order

For my applications I usually include a custom SystemBootC component
that provides a Boot interface for my top level application.  I then
wire into this instead of to MainC.  depending on my application, my
SystemBootC looks different, but an example is:

configuration SystemBootC {
  provides interface Boot;
  uses interface Init as SoftwareInit;
}

implementation {
  components MainC;
  components Phase1C,
  components Phase2C;
  components Phase3C;
  SoftwareInit = MainC.SoftwareInit;

  //Daisy chain my Boots here...
  Phase1C.Boot -> MainC;
  Phase2C.Boot -> Phase1BootC;
  Phase3C.Boot -> Phase2BootC;
  Boot = Phase3BootC;
}

At the bottom of a *used* Boot I signal a provided Boot to allow the
daisy chaining to happen and then in my top level app I Just wire to
SystemBootC instead of MainC to bring everything up.

Kevin

On Wed, May 21, 2008 at 3:15 PM, David Moss <dmm at rincon.com> wrote:
> I've run into this problem several times now, so I wanted to bounce an
idea
> off you guys.
>
>
>
> The problem is I have an application that consists of many, many
sub-systems
> and components.  The sub-systems work fine when they are separated,
but
> integrating them together can cause problems with the order they are
> started.
>
>
>
> Specifically, the problem is with Boot.booted().  There's a single
event
> signaled out to fire up the entire system, but the fan-out here is
dependent
> upon the order in which I pull in components within a configuration.
If my
> main configuration lists all of the components that comprise the
system in a
> certain order, and those components all use Boot.booted() to startup,
the
> order that their booted() events get signaled is dependent upon the
order I
> listed them.  In fact, by changing the order in which components are
called
> out in a configuration file, the entire behavior of the system could
change
> because something started up before a sub-system it is dependent upon.
> Sometimes these types of integration issues are nearly impossible to
debug.
>
>
>
> A good example of this boot order behavior is loading variables from
> non-volatile memory. I have a component that reads from internal
> microcontroller memory to instantiate variables within other modules
in the
> system.  This component has to boot() before the rest of the system
tries to
> start and access those variables.  My solution in the past was to add
a
> custom init() command to MainC to start this non-volatile
configuration
> module before the rest of the system.
>
>
>
> I think that a single Boot.booted() interface is not enough for more
> advanced applications.  I'd like to see several Boot interfaces
provided,
> each specifying a different priority, like 1-5 (where 1 is the highest
> priority).   This would allow components to startup in a predictable
manner
> without bloating code.  We could keep the MainC signature the same for
> backwards compatible, and create a BootC configuration to provide Boot
> interfaces renamed to something like BootPriority1, BootPriority2,
etc. and
> the lowest priority could be the standard Boot.booted().
>
>
>
> The same argument could apply to the Init interface.  Right now we
have two
> priorities on that: the PlatformInit and SoftwareInit.  I'm not sure
that
> adding more Init priorities is as compelling as fixing the Boot
interface
> though.
>
>
>
>
>
> For me, I'd like my system to boot in this order:
>
>
>
> The highest priority component would be something like my non-volatile
> variable loading component and other non-volatile memory drivers
> (configurator). These need to instantiate variables from flash for the
rest
> of the system.
>
>
>
> Second, configure the radio settings (low power communications,
channel,
> output power, etc.), and other higher priority things like file
systems.
>
>
>
> Third, enable communications on radios or serial.
>
>
>
> Fourth are any application dependencies, drivers, custom stuff, etc.
>
>
>
> Finally, the application boots.
>
>
>
>
>
>
>
> All other operating systems I know have a defined order in which
elements
> boot up, and I think TinyOS would benefit from the same.  Getting rid
of the
> boot order based on the order of compilation is critical to handle
these
> more complex integration issues.
>
>
>
> Just a thought.
>
>
>
> -David
>
>
>
>
>
>
>
> configuration BootC {
>
>
>
>   provides {
>
>     interface Boot as BootPriority1;
>
>     interface Boot as BootPriority2;
>
>     interface Boot as BootPriority3;
>
>     interface Boot as BootPriority4;
>
>     interface Boot as BootPriority5;
>
>     interface Boot;
>
>   }
>
>
>
> }
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
>
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0w
g
>



-- 
~Kevin
_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0w
g