[Tinyos Core WG] Boot Order

[Kevin Klues]

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.0wg
>



-- 
~Kevin