| Philip Levis |
Note
This memo documents a part of TinyOS for the TinyOS Community, and @@ -310,13 +305,13 @@ requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
This memo documents the structure and implementation of the mote boot sequence in TinyOS 2.x.
TinyOS has a set of calling conventions and semantics in its boot sequence. Earlier versions of TinyOS used an interface named "StdControl" to take care of system initialization and starting @@ -330,8 +325,8 @@ initialization, one for starting and stopping components, and one for notification that the mote has booted. This memo describes the TinyOS boot sequence and reasons for its semantics.
The TinyOS 1.x boot sequence is uniform across most mote platforms (TOSSIM has a very different boot sequence, as it is a PC program). The module RealMain implements main(), and has the following @@ -351,11 +346,11 @@ int main() __attribute__ ((C, spontaneous)) { call hardwareInit(); call Pot.init(10); TOSH_sched_init(); - + call StdControl.init(); call StdControl.start(); __nesc_enable_interrupt(); - + while(1) { TOSH_run_task(); } @@ -386,8 +381,8 @@ start/stop model. In this case, some components can't operate properly until the radio starts, but main has no mechanism for waiting for the radio start completion event.
The TinyOS 2.x boot sequence uses three interfaces:
@@ -408,7 +403,7 @@ range of components need to be interleaved effectively, initialization is a sequential, synchronous operation: no component can be started until initialization is complete. If a particular component's initialization requires waiting for interrupts or other asynchronous -events, then it must explicitly wait for them (e.g., +events, then it must explicitly wait for them (e.g., with a spin loop), MUST NOT return until complete. Otherwise the system may start before initialization is complete.
The Scheduler interface is for initializing and controlling task @@ -421,8 +416,8 @@ interface Boot { }
The module RealMainP implements the standard TinyOS 2.x boot sequence. The configuration MainC wires some of RealMainP's interfaces to components that implement standard abstractions and exports the others @@ -457,8 +452,8 @@ implementation { default event void Boot.booted() { } } -
The first step in the boot sequence is initializing the system:
atomic {
@@ -475,11 +470,11 @@ places the system into an executable state. This function MUST NOT include
operations besides those which are absolutely necessary for further code,
such as scheduler initialization, to execute.
Examples of platform_bootstrap() operations are configuring the memory
-system and setting the processor mode. Generally, platform_bootstrap()
+system and setting the processor mode. Generally, platform_bootstrap()
is an empty function. TinyOS's top-level include file, tos.h, includes
a default implementation of this function which does nothing. If a platform
needs to replace the default, it SHOULD put it in a platform's
-platform.h file as a #define. The implementation of tos.h
+platform.h file as a #define. The implementation of tos.h
supports this:
/* This platform_bootstrap macro exists in accordance with TEP
@@ -499,7 +494,7 @@ configuration MainC {
uses interface Init as SoftwareInit;
}
implementation {
- components PlatformC, RealMainP, TinySchedulerC;
+ components PlatformC, RealMainP, TinySchedulerC;
RealMainP.Scheduler -> TinySchedulerC;
RealMainP.PlatformInit -> PlatformC;
@@ -531,7 +526,7 @@ through PlatformC meet some or all of the following criteria:
Three example operations that often belong in PlatformInit are I/O pin -configuration, clock calibration, and LED configuration. I/O pin +configuration, clock calibration, and LED configuration. I/O pin configuration meets the first two criteria. It should always be performed (regardless of what components the OS uses) for low-power reasons: incorrectly configured pins can draw current and prevent the MCU from @@ -540,13 +535,13 @@ all three criteria. LED configuration is a special case: while it nominally meets all three criteria, the most important one is the third: as LEDs are often needed during SoftwareInit initialization, they must be set up before it is invoked.
-Note that not all code which meets some of these criteria is wired through -PlatformC. In particular, criterion 1 is typically necessary but not +
Note that not all code which meets some of these criteria is wired through +PlatformC. In particular, criterion 1 is typically necessary but not sufficient to require PlatformC. For example, a timer system that configures overflow and capture settings or a UART stack that sets the baud rate and transmission options can often be wired to SoftwareInit. They are encapsulated abstractions which will not be invoked or -started until the boot event, and only need to be configured if the +started until the boot event, and only need to be configured if the system includes their functionality.
Components whose initialization does not directly depend on hardware resources SHOULD wire to MainC.SoftwareInit. If a component requires a @@ -569,7 +564,7 @@ configuration TimerMilliP { implementation { components HilTimerMilliC, MainC; MainC.SoftwareInit -> HilTimerMilliC; - TimerMilli = HilTimerMilliC; + TimerMilli = HilTimerMilliC; }
Rather than require an application to wire HilTimerMilliC to MainC, @@ -577,8 +572,8 @@ TimerMilliP does it automatically. When a component instantiates a TimerMilliC, that names TimerMilliP, which will automatically make sure that the timer system is initialized when TinyOS boots.
Interrupts are not enabled until all calls to Init.init have returned. If a component's initialization needs to handle interrupts, it can do one of three things:
@@ -605,7 +600,7 @@ flag) or to catch a brief edge transition. In these cases, a component can handle an interrupt in the boot sequence only if doing so will not cause any other component to handle an interrupt. As they have all been written assuming that interrupts are not enabled until after Init -completes, making one of them handle an interrupt could cause it to +completes, making one of them handle an interrupt could cause it to fail.Depending on what capabilities the hardware provides, there are several ways to meet these requirements. The simplest is to push these @@ -620,22 +615,22 @@ initialized unless it has initialized them, and MUST NOT call any functional interfaces on any components that might be shared or interact with shared resources. Components MAY call functions on other components that are completely internal to the subsystem. -For example, a networking layer can call queue operations to +For example, a networking layer can call queue operations to initialize its queue, but a link layer must not send commands over an SPI bus. An HAA component MAY make other calls to initialize hardware state. A component that is not part of an HAA SHOULD NOT call Init.init() on other components unless it needs to enforce a temporal ordering on initialization.
-If a component A depends on another component, B, -which needs to be initialized, then A SHOULD wire B's Init directly +
If a component A depends on another component, B, +which needs to be initialized, then A SHOULD wire B's Init directly to the boot sequence, unless there is a temporal ordering requirement to the initialization. The purpose of this convention is to simplify component initialization and the initialization sequence.
The following files in tinyos-2.x/tos/system contain the reference implementations of the TinyOS boot sequence:
@@ -646,8 +641,8 @@ PlatformC and TinySchedulerC