[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep106.html, 1.1.2.4,
1.1.2.5 tep107.html, 1.1.2.5, 1.1.2.6
Phil Levis
scipio at users.sourceforge.net
Fri Jun 9 10:18:53 PDT 2006
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv15732/html
Modified Files:
Tag: tinyos-2_0_devel-BRANCH
tep106.html tep107.html
Log Message:
Reformatted and cleaned up.
Index: tep106.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep106.html,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -C2 -d -r1.1.2.4 -r1.1.2.5
*** tep106.html 18 May 2006 23:08:14 -0000 1.1.2.4
--- tep106.html 9 Jun 2006 17:18:49 -0000 1.1.2.5
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title>Schedulers and Tasks</title>
<meta name="author" content="Philip Levis and Cory Sharp" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>Schedulers and Tasks</title>
<meta name="author" content="Philip Levis and Cory Sharp" />
***************
*** 281,285 ****
</head>
<body>
- <div class="document" id="schedulers-and-tasks">
<h1 class="title">Schedulers and Tasks</h1>
<table class="docinfo" frame="void" rules="none">
--- 281,284 ----
***************
*** 301,307 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.4</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-05-03</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 300,306 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.6</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-09</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 309,312 ****
--- 308,312 ----
</tbody>
</table>
+ <div class="document" id="schedulers-and-tasks">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 324,328 ****
<h1><a name="introduction">1. Introduction</a></h1>
<p>TinyOS has two basic computational abstractions: asynchronous events
! and tasks. Prior versions of TinyOS provided a single type of task --
parameter free -- and only a FIFO scheduling policy. While changing
the latter was possible, the incorporation of tasks into the nesC
--- 324,328 ----
<h1><a name="introduction">1. Introduction</a></h1>
<p>TinyOS has two basic computational abstractions: asynchronous events
! and tasks. Early versions of TinyOS provided a single type of task --
parameter free -- and only a FIFO scheduling policy. While changing
the latter was possible, the incorporation of tasks into the nesC
***************
*** 331,335 ****
to be presented as an interface enables extending the classes of tasks
available. TinyOS 2.0 takes both approaches, and this memo documents
! the structure of how it does so.</p>
</div>
<div class="section" id="tasks-and-the-scheduler-in-tinyos-1-x">
--- 331,336 ----
to be presented as an interface enables extending the classes of tasks
available. TinyOS 2.0 takes both approaches, and this memo documents
! the structure of how it does so as well as a simple mechanism that
! greatly increases system dependability.</p>
</div>
<div class="section" id="tasks-and-the-scheduler-in-tinyos-1-x">
***************
*** 343,357 ****
<p>In TinyOS 1.x, the nesC language supports tasks through two
mechanisms, <tt class="docutils literal"><span class="pre">task</span></tt> declarations and <tt class="docutils literal"><span class="pre">post</span></tt> expressions:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">task</span> <span class="pre">void</span> <span class="pre">computeTask()</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">//</span> <span class="pre">Code</span> <span class="pre">here</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <p>and</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">result_t</span> <span class="pre">rval</span> <span class="pre">=</span> <span class="pre">post</span> <span class="pre">computeTask();</span></tt></div>
! </div>
<p>TinyOS 1.x provides a single kind of task, a parameter-free function,
and a single scheduling policy, FIFO. <tt class="docutils literal"><span class="pre">post</span></tt> expressions can return
--- 344,356 ----
<p>In TinyOS 1.x, the nesC language supports tasks through two
mechanisms, <tt class="docutils literal"><span class="pre">task</span></tt> declarations and <tt class="docutils literal"><span class="pre">post</span></tt> expressions:</p>
! <pre class="literal-block">
! task void computeTask() {
! // Code here
! }
! </pre>
! <p>and:</p>
! <pre class="literal-block">
! result_t rval = post computeTask();
! </pre>
<p>TinyOS 1.x provides a single kind of task, a parameter-free function,
and a single scheduling policy, FIFO. <tt class="docutils literal"><span class="pre">post</span></tt> expressions can return
***************
*** 373,377 ****
<blockquote>
<ol class="arabic simple">
! <li>Some components do not have a reasonable response to a failed <tt class="docutils literal"><span class="pre">post</span></tt></li>
<li>As a given task can be posted multiple times, it can consume more than one element in the buffer</li>
<li>All tasks from all components share a single resource: one misbehaving component can cause other's posts to fail</li>
--- 372,376 ----
<blockquote>
<ol class="arabic simple">
! <li>Some components do not have a reasonable response to a failed post</li>
<li>As a given task can be posted multiple times, it can consume more than one element in the buffer</li>
<li>All tasks from all components share a single resource: one misbehaving component can cause other's posts to fail</li>
***************
*** 403,407 ****
application component does not try to send another packet until it
knows the one it is sending completes (so it can re-use the
! buffer). As the <tt class="docutils literal"><span class="pre">sendDone()</span></tt> event was lost, this will never occur,
and the application stops sending network traffic.</p>
<p>The solution to this particular problem in TinyOS 1.x is to signal
--- 402,406 ----
application component does not try to send another packet until it
knows the one it is sending completes (so it can re-use the
! buffer). As the <tt class="docutils literal"><span class="pre">sendDone()</span></tt> event was lost, this does not occur,
and the application stops sending network traffic.</p>
<p>The solution to this particular problem in TinyOS 1.x is to signal
***************
*** 409,445 ****
this violates the sync/async boundary, but the justification is that
a <em>possible</em> rare race condition is better than <em>certain</em> failure.
The TinyOS 1.x model prevents it from doing any better.</p>
</div>
<div class="section" id="tasks-in-tinyos-2-x">
<h1><a name="tasks-in-tinyos-2-x">3. Tasks in TinyOS 2.x</a></h1>
- <p>TinyOS 2.x takes the position that the basic use case of tasks should
- remain simple and easy to use, but that it should be possible to
- introduce new kinds of tasks beyond the basic use case. TinyOS
- actualizes this by keeping <tt class="docutils literal"><span class="pre">post</span></tt> and <tt class="docutils literal"><span class="pre">task</span></tt> for the basic case,
- and introducing task interfaces for additional ones.</p>
<p>The semantics of tasks in TinyOS 2.x are different than those in 1.x.
This change is based on experiences with the limitations and run time
errors that the 1.x model introduces. <strong>In TinyOS 2.x, a basic post will
! only fail if the task has already been posted and has not started
! execution.</strong> A task can always run, but can only have one outstanding
! post at any time. If a component needs to post task several times,
! then the end of the task logic can repost itself as need be.</p>
<p>These semantics prevent several problems, such as the inability to
signal completion of split-phase events because the task queue is
full, task queue overflow at initialization, and unfair task
allocation by components that post a task many times.</p>
<p>Task interfaces allow users to extend the syntax and semantics of
! tasks. Generally, a task interface has an <tt class="docutils literal"><span class="pre">async</span></tt> command, <tt class="docutils literal"><span class="pre">post</span></tt>,
and an event, <tt class="docutils literal"><span class="pre">run</span></tt>. The exact signature of these functions are
up to the interface. For example, a task interface that allows a task
to take an integer parameter could look like this:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">TaskParameter</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">async</span> <span class="pre">error_t</span> <span class="pre">command</span> <span class="pre">postTask(uint16_t</span> <span class="pre">param);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">runTask(uint16_t</span> <span class="pre">param);</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>Using this task interface, a component could post a task with a
<tt class="docutils literal"><span class="pre">uint16_t</span></tt> parameter. When the scheduler runs the task, it will
--- 408,461 ----
this violates the sync/async boundary, but the justification is that
a <em>possible</em> rare race condition is better than <em>certain</em> failure.
+ Another solution would be to use an interrupt source to periodically
+ retry posting the task; while this does not break the sync/async
+ boundary, until the post succeeds the system cannot send packets.
The TinyOS 1.x model prevents it from doing any better.</p>
</div>
<div class="section" id="tasks-in-tinyos-2-x">
<h1><a name="tasks-in-tinyos-2-x">3. Tasks in TinyOS 2.x</a></h1>
<p>The semantics of tasks in TinyOS 2.x are different than those in 1.x.
This change is based on experiences with the limitations and run time
errors that the 1.x model introduces. <strong>In TinyOS 2.x, a basic post will
! only fail if and only if the task has already been posted and has not
! started execution.</strong> A task can always run, but can only have one
! outstanding post at any time.</p>
! <p>2.x achieves these semantics by allocating one
! byte of state per task (the assumption is that there will be fewer than 255
! tasks in the system). While a very large number of tasks could make
! this overhead noticable, it is not significant in practice.
! If a component needs to post a task several times, then the end of
! the task logic can repost itself as need be.</p>
! <p>For example, one can do this:</p>
! <pre class="literal-block">
! post processTask();
! ...
! task void processTask() {
! // do work
! if (moreToProcess) {
! post processTask();
! }
! }
! </pre>
<p>These semantics prevent several problems, such as the inability to
signal completion of split-phase events because the task queue is
full, task queue overflow at initialization, and unfair task
allocation by components that post a task many times.</p>
+ <p>TinyOS 2.x takes the position that the basic use case of tasks should
+ remain simple and easy to use, but that it should be possible to
+ introduce new kinds of tasks beyond the basic use case. TinyOS
+ achieves this by keeping <tt class="docutils literal"><span class="pre">post</span></tt> and <tt class="docutils literal"><span class="pre">task</span></tt> for the basic case,
+ and introducing task interfaces for additional ones.</p>
<p>Task interfaces allow users to extend the syntax and semantics of
! tasks. Generally, a task interface has an <tt class="docutils literal"><span class="pre">async</span></tt> command, post ,
and an event, <tt class="docutils literal"><span class="pre">run</span></tt>. The exact signature of these functions are
up to the interface. For example, a task interface that allows a task
to take an integer parameter could look like this:</p>
! <pre class="literal-block">
! interface TaskParameter {
! async error_t command postTask(uint16_t param);
! event void runTask(uint16_t param);
! }
! </pre>
<p>Using this task interface, a component could post a task with a
<tt class="docutils literal"><span class="pre">uint16_t</span></tt> parameter. When the scheduler runs the task, it will
***************
*** 454,478 ****
call TaskParameter.postTask(34);
...
! event void TaskParameter.runTask(uint15_t param) {
...
}
</pre>
! <p>The semantics of tasks in TinyOS 2.x are different than those in 1.x.
! This change is based on experiences with the limitations and run time
! errors that the 1.x model introduces. <strong>In TinyOS 2.x, a basic post will
! only fail if the task has already been posted and has not started
! execution.</strong> A task can always run, but can only have one outstanding
! post at any time. 2.x achieves these semantics by allocating a single
! byte of state per task. While a very large number of tasks could make
! this overhead noticable, it is not significant in practice.
! If a component needs to post a task several times, then the end of
! the task logic can repost itself as need be.</p>
! <p>For example, one can do this:</p>
<pre class="literal-block">
! param = 34;
! post parameterTask();
...
task void parameterTask() {
! // use param here
}
</pre>
--- 470,497 ----
call TaskParameter.postTask(34);
...
! event void TaskParameter.runTask(uint16_t param) {
...
}
</pre>
! <p>one can:</p>
<pre class="literal-block">
! uint16_t param;
! ...
! param = 34;
! post parameterTask();
...
task void parameterTask() {
! // use param
! }
! </pre>
! <p>The principal difference between the simplest code for these
! two models is that if the component posts the task twice, it
! will use the older parameter in the TaskParameter example,
! while it will use the newer parameter in the basic task example.
! If a component wants to use the oldest parameter, then it can do
! this:</p>
! <pre class="literal-block">
! if (post myTask() == SUCCESS) {
! param = 34;
}
</pre>
***************
*** 481,485 ****
<h1><a name="the-scheduler-in-tinyos-2-x">4. The Scheduler in TinyOS 2.x</a></h1>
<p>In TinyOS 2.x, the scheduler is a TinyOS component. Every scheduler
! MUST support basic nesC tasks. It MAY also support any number of
additional task interfaces. The scheduler component is resonsible for
the policy of reconciling different task types (e.g., earliest
--- 500,504 ----
<h1><a name="the-scheduler-in-tinyos-2-x">4. The Scheduler in TinyOS 2.x</a></h1>
<p>In TinyOS 2.x, the scheduler is a TinyOS component. Every scheduler
! MUST support nesC tasks. It MAY also support any number of
additional task interfaces. The scheduler component is resonsible for
the policy of reconciling different task types (e.g., earliest
***************
*** 494,506 ****
dispatch tasks.</p>
<p>For example, the standard TinyOS scheduler has this signature:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">module</span> <span class="pre">SchedulerBasicP</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">Scheduler;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskBasic[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">uses</span> <span class="pre">interface</span> <span class="pre">McuSleep;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>A scheduler MUST provide a parameterized TaskBasic interface.
If a call to TaskBasic.postTask() returns SUCCESS, the scheduler MUST run it
--- 513,523 ----
dispatch tasks.</p>
<p>For example, the standard TinyOS scheduler has this signature:</p>
! <pre class="literal-block">
! module SchedulerBasicP {
! provides interface Scheduler;
! provides interface TaskBasic[uint8_t taskID];
! uses interface McuSleep;
! }
! </pre>
<p>A scheduler MUST provide a parameterized TaskBasic interface.
If a call to TaskBasic.postTask() returns SUCCESS, the scheduler MUST run it
***************
*** 512,525 ****
<p>A scheduler MUST provide the Scheduler interface.
The Scheduler interface has commands for initialization and running
! tasks, and is used by TinyOS to execute tasks.</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Scheduler</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">void</span> <span class="pre">init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">bool</span> <span class="pre">runNextTask(bool</span> <span class="pre">sleep);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">void</span> <span class="pre">taskLoop();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>The init() command initializes the task queue and scheduler data
structures. runNextTask() MUST run to completion whatever task the
--- 529,540 ----
<p>A scheduler MUST provide the Scheduler interface.
The Scheduler interface has commands for initialization and running
! tasks, and is used by TinyOS to execute tasks:</p>
! <pre class="literal-block">
! interface Scheduler {
! command void init();
! command bool runNextTask(bool sleep);
! command void taskLoop();
! }
! </pre>
<p>The init() command initializes the task queue and scheduler data
structures. runNextTask() MUST run to completion whatever task the
***************
*** 535,547 ****
into a low power state when the processor is idle: it never returns.</p>
<p>This is the TaskBasic interface:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">TaskBasic</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">async</span> <span class="pre">command</span> <span class="pre">error_t</span> <span class="pre">postTask();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">void</span> <span class="pre">event</span> <span class="pre">runTask();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <p>When a component declares a task with the <tt class="docutils literal"><span class="pre">task</span></tt> keyword in nesC, it
is implicitly declaring that it uses an instance of the TaskBasic
interface: the task body is the runTask event. When a component uses the
--- 550,560 ----
into a low power state when the processor is idle: it never returns.</p>
<p>This is the TaskBasic interface:</p>
! <pre class="literal-block">
! interface TaskBasic {
! async command error_t postTask();
! void event runTask();
! }
! </pre>
! <p>When a component declares a task with the task keyword in nesC, it
is implicitly declaring that it uses an instance of the TaskBasic
interface: the task body is the runTask event. When a component uses the
***************
*** 576,618 ****
deadline first tasks, which are provided through the TaskEdf
interface:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">TaskEdf</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">async</span> <span class="pre">command</span> <span class="pre">error_t</span> <span class="pre">postTask(uint16_t</span> <span class="pre">deadlineMs);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">runTask();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>The scheduler implementation is named SchedulerEdfP, and provides both
TaskBasic and TaskEdf interfaces:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">module</span> <span class="pre">SchedulerEdfP</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">Scheduler;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskBasic[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskEdf[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>An application that wants to use SchedulerEdfP instead of
SchedulerBasicP includes a configuration named TinySchedulerC, which
exports all of SchedulerEdfP's interfaces:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">configuration</span> <span class="pre">TinySchedulerC</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">Scheduler;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskBasic[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskEdf[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">implementation</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">components</span> <span class="pre">SchedulerEdfP;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">Scheduler</span> <span class="pre">=</span> <span class="pre">SchedulerEdf;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">TaskBasic</span> <span class="pre">=</span> <span class="pre">SchedulerEdfP;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">TaskEDF</span> <span class="pre">=</span> <span class="pre">SchedulerEdfP;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>For a module to have an earliest deadline first task, it uses the
TaskEdf interface. Its configuration SHOULD wire it to TinySchedulerC.
--- 589,623 ----
deadline first tasks, which are provided through the TaskEdf
interface:</p>
! <pre class="literal-block">
! interface TaskEdf {
! async command error_t postTask(uint16_t deadlineMs);
! event void runTask();
! }
! </pre>
<p>The scheduler implementation is named SchedulerEdfP, and provides both
TaskBasic and TaskEdf interfaces:</p>
! <pre class="literal-block">
! module SchedulerEdfP {
! provides interface Scheduler;
! provides interface TaskBasic[uint8_t taskID];
! provides interface TaskEdf[uint8_t taskID];
! }
! </pre>
<p>An application that wants to use SchedulerEdfP instead of
SchedulerBasicP includes a configuration named TinySchedulerC, which
exports all of SchedulerEdfP's interfaces:</p>
! <pre class="literal-block">
! configuration TinySchedulerC {
! provides interface Scheduler;
! provides interface TaskBasic[uint8_t taskID];
! provides interface TaskEdf[uint8_t taskID];
! }
! implementation {
! components SchedulerEdfP;
! Scheduler = SchedulerEdf;
! TaskBasic = SchedulerEdfP;
! TaskEDF = SchedulerEdfP;
! }
! </pre>
<p>For a module to have an earliest deadline first task, it uses the
TaskEdf interface. Its configuration SHOULD wire it to TinySchedulerC.
***************
*** 621,638 ****
by the scheduler. For example, the module SomethingP requires two EDF
tasks:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">configuration</span> <span class="pre">SomethingC</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">...</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">implementation</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">components</span> <span class="pre">SomethingP,</span> <span class="pre">TinySchedulerC;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">SomethingP.SendTask</span> <span class="pre">-></span> <span class="pre">TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">SomethingP.SenseTask</span> <span class="pre">-></span> <span class="pre">TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>The module SomethingP also has a basic task. The nesC compiler
automatically transforms task keywords into BasicTask interfaces and
--- 626,639 ----
by the scheduler. For example, the module SomethingP requires two EDF
tasks:</p>
! <pre class="literal-block">
! configuration SomethingC {
! ...
! }
! implementation {
! components SomethingP, TinySchedulerC;
! SomethingP.SendTask -> TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];
! SomethingP.SenseTask -> TinySchedulerC.TaskEdf["TinySchedulerC.TaskEdf"];
! }
! </pre>
<p>The module SomethingP also has a basic task. The nesC compiler
automatically transforms task keywords into BasicTask interfaces and
***************
*** 642,669 ****
MUST NOT mix the two syntaxes for a given task. This is an example
implementation of SomethingP that uses keywords for basic tasks:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">module</span> <span class="pre">SomethingP</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">uses</span> <span class="pre">interface</span> <span class="pre">TaskEdf</span> <span class="pre">as</span> <span class="pre">SendTask</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">uses</span> <span class="pre">interface</span> <span class="pre">TaskEdf</span> <span class="pre">as</span> <span class="pre">SenseTask</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">implementation</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">//</span> <span class="pre">The</span> <span class="pre">TaskBasic,</span> <span class="pre">written</span> <span class="pre">with</span> <span class="pre">keywords</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">task</span> <span class="pre">void</span> <span class="pre">cleanupTask()</span> <span class="pre">{</span> <span class="pre">...</span> <span class="pre">some</span> <span class="pre">logic</span> <span class="pre">...</span> <span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">SendTask.runTask()</span> <span class="pre">{</span> <span class="pre">...</span> <span class="pre">some</span> <span class="pre">logic</span> <span class="pre">...</span> <span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">SenseTask.runTask()</span> <span class="pre">{</span> <span class="pre">...</span> <span class="pre">some</span> <span class="pre">logic</span> <span class="pre">...</span> <span class="pre">}</span></tt></div>
! <div class="line"><br /></div>
! <div class="line"><tt class="docutils literal"><span class="pre">void</span> <span class="pre">internal_function()</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">SenseTask.postTask(20);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">SendTask.postTask(100);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">post</span> <span class="pre">cleanupTask();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>If the scheduler provides two instances of the same task interface,
their unique keys are based on the name of the interface as the
--- 643,664 ----
MUST NOT mix the two syntaxes for a given task. This is an example
implementation of SomethingP that uses keywords for basic tasks:</p>
! <pre class="literal-block">
! module SomethingP {
! uses interface TaskEdf as SendTask
! uses interface TaskEdf as SenseTask
! }
! implementation {
! // The TaskBasic, written with keywords
! task void cleanupTask() { ... some logic ... }
! event void SendTask.runTask() { ... some logic ... }
! event void SenseTask.runTask() { ... some logic ... }
!
! void internal_function() {
! call SenseTask.postTask(20);
! call SendTask.postTask(100);
! post cleanupTask();
! }
! }
! </pre>
<p>If the scheduler provides two instances of the same task interface,
their unique keys are based on the name of the interface as the
***************
*** 672,696 ****
tasks and high-priority tasks. The scheduler always selects a task
for the high priority queue before the standard queue:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">configuration</span> <span class="pre">TinySchedulerC</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">Scheduler;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskBasic[uint8_t</span> <span class="pre">taskID];</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">TaskBasic[uint8_t</span> <span class="pre">taskID]</span> <span class="pre">as</span> <span class="pre">TaskHighPriority;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>A component that uses a high priority task would then wire to
TaskHighPriority with the key "TinySchedulerC.TaskHighPriority":</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">configuration</span> <span class="pre">SomethingElseC</span> <span class="pre">{</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">implementation</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">components</span> <span class="pre">TinySchedulerC</span> <span class="pre">as</span> <span class="pre">Sched,</span> <span class="pre">SomethingElseP;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">SomethingElseP.RetransmitTask</span> <span class="pre">-></span> <span class="pre">Sched.TaskHighPriority[unique("TinySchedulerC.TaskHighPriority")];</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
</div>
<div class="section" id="author-s-address">
--- 667,686 ----
tasks and high-priority tasks. The scheduler always selects a task
for the high priority queue before the standard queue:</p>
! <pre class="literal-block">
! configuration TinySchedulerC {
! provides interface Scheduler;
! provides interface TaskBasic[uint8_t taskID];
! provides interface TaskBasic[uint8_t taskID] as TaskHighPriority;
! }
! </pre>
<p>A component that uses a high priority task would then wire to
TaskHighPriority with the key "TinySchedulerC.TaskHighPriority":</p>
! <pre class="literal-block">
! configuration SomethingElseC {}
! implementation {
! components TinySchedulerC as Sched, SomethingElseP;
! SomethingElseP.RetransmitTask -> Sched.TaskHighPriority[unique("TinySchedulerC.TaskHighPriority")];
! }
! </pre>
</div>
<div class="section" id="author-s-address">
***************
*** 742,746 ****
<div class="section" id="appendix-a-changing-the-scheduler">
<h1><a name="appendix-a-changing-the-scheduler">Appendix A: Changing the Scheduler</a></h1>
! <p>The nesC compiler transforms the <tt class="docutils literal"><span class="pre">post</span></tt> and <tt class="docutils literal"><span class="pre">task</span></tt> keywords into
nesC interfaces, wirings, and calls. By default, the statement:</p>
<pre class="literal-block">
--- 732,736 ----
<div class="section" id="appendix-a-changing-the-scheduler">
<h1><a name="appendix-a-changing-the-scheduler">Appendix A: Changing the Scheduler</a></h1>
! <p>The nesC compiler transforms the post and task keywords into
nesC interfaces, wirings, and calls. By default, the statement:</p>
<pre class="literal-block">
***************
*** 775,779 ****
<p>While the fact that tasks are transformed into interfaces is built in
to the nesC compiler, the exact names can be configured. Each
! platform's <tt class="docutils literal"><span class="pre">.platform</span></tt> file passes the <tt class="docutils literal"><span class="pre">-fnesc-scheduler</span></tt> option
to the compiler. The standard option is:</p>
<pre class="literal-block">
--- 765,769 ----
<p>While the fact that tasks are transformed into interfaces is built in
to the nesC compiler, the exact names can be configured. Each
! platform's .platform file passes the -fnesc-scheduler option
to the compiler. The standard option is:</p>
<pre class="literal-block">
Index: tep107.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/Attic/tep107.html,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -C2 -d -r1.1.2.5 -r1.1.2.6
*** tep107.html 18 May 2006 23:19:15 -0000 1.1.2.5
--- tep107.html 9 Jun 2006 17:18:49 -0000 1.1.2.6
***************
*** 4,8 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title>TinyOS 2.x Boot Sequence</title>
<meta name="author" content="Philip Levis" />
--- 4,8 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>TinyOS 2.x Boot Sequence</title>
<meta name="author" content="Philip Levis" />
***************
*** 281,285 ****
</head>
<body>
- <div class="document" id="tinyos-2-x-boot-sequence">
<h1 class="title">TinyOS 2.x Boot Sequence</h1>
<table class="docinfo" frame="void" rules="none">
--- 281,284 ----
***************
*** 301,307 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-05-18</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 300,306 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">10-Dec-2004</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.8</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-09</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 309,312 ****
--- 308,312 ----
</tbody>
</table>
+ <div class="document" id="tinyos-2-x-boot-sequence">
<div class="note">
<p class="first admonition-title">Note</p>
***************
*** 342,378 ****
program). The module RealMain implements main(), and has the following
signature:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">module</span> <span class="pre">RealMain</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">uses</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">result_t</span> <span class="pre">hardwareInit();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">StdControl;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Pot;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>The mote main() function uses a mix of nesC and C:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">int</span> <span class="pre">main()</span> <span class="pre">__attribute__</span> <span class="pre">((C,</span> <span class="pre">spontaneous))</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">hardwareInit();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">Pot.init(10);</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">TOSH_sched_init();</span></tt></div>
! <div class="line">`` ``</div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">StdControl.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">StdControl.start();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">__nesc_enable_interrupt();</span></tt></div>
! <div class="line">`` ``</div>
! <div class="line"><tt class="docutils literal"><span class="pre">while(1)</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">TOSH_run_task();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>Several problems exist. Some of these calls are artifacts of old
platforms: the Pot component refers to the mica variable potentiometer
--- 342,370 ----
program). The module RealMain implements main(), and has the following
signature:</p>
! <pre class="literal-block">
! module RealMain {
! uses {
! command result_t hardwareInit();
! interface StdControl;
! interface Pot;
! }
! }
! </pre>
<p>The mote main() function uses a mix of nesC and C:</p>
! <pre class="literal-block">
! 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();
! }
! }
! </pre>
<p>Several problems exist. Some of these calls are artifacts of old
platforms: the Pot component refers to the mica variable potentiometer
***************
*** 411,421 ****
</blockquote>
<p>The Init interface has a single command, init():</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Init</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">command</span> <span class="pre">error_t</span> <span class="pre">init();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>Init provides a synchronous interface, enabling initialization
ordering. Unlike normal execution, in which operations from a wide
--- 403,411 ----
</blockquote>
<p>The Init interface has a single command, init():</p>
! <pre class="literal-block">
! interface Init {
! command error_t init();
! }
! </pre>
<p>Init provides a synchronous interface, enabling initialization
ordering. Unlike normal execution, in which operations from a wide
***************
*** 430,441 ****
execution. It is detailed in TEP 106[tep106].</p>
<p>The Boot interface has a single event, booted(), which the boot
! sequence signals when it has completed.</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Boot</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">event</span> <span class="pre">void</span> <span class="pre">booted();</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
</div>
<div class="section" id="id1">
--- 420,429 ----
execution. It is detailed in TEP 106[tep106].</p>
<p>The Boot interface has a single event, booted(), which the boot
! sequence signals when it has completed:</p>
! <pre class="literal-block">
! interface Boot {
! event void booted();
! }
! </pre>
</div>
<div class="section" id="id1">
***************
*** 445,501 ****
components that implement standard abstractions and exports the others
that are application specific. Code above the Hardware Independent
! Layer (TEP 2) SHOULD wire to MainC and not RealMainP.</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">module</span> <span class="pre">RealMainP</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">provides</span> <span class="pre">interface</span> <span class="pre">Booted;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">uses</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Scheduler;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Init</span> <span class="pre">as</span> <span class="pre">PlatformInit;</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">interface</span> <span class="pre">Init</span> <span class="pre">as</span> <span class="pre">SoftwareInit;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">implementation</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">int</span> <span class="pre">main()</span> <span class="pre">__attribute__</span> <span class="pre">((C,</span> <span class="pre">spontaneous))</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">atomic</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">Scheduler.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">PlatformInit.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">while</span> <span class="pre">(call</span> <span class="pre">Scheduler.runNextTask());</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">SoftwareInit.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">while</span> <span class="pre">(call</span> <span class="pre">Scheduler.runNextTask());</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">__nesc_enable_interrupt();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">signal</span> <span class="pre">Boot.booted();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">Scheduler.taskLoop();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">return</span> <span class="pre">-1;</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">default</span> <span class="pre">command</span> <span class="pre">error_t</span> <span class="pre">PlatformInit.init()</span> <span class="pre">{</span> <span class="pre">return</span> <span class="pre">SUCCESS;</span> <span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">default</span> <span class="pre">command</span> <span class="pre">error_t</span> <span class="pre">SoftwareInit.init()</span> <span class="pre">{</span> <span class="pre">return</span> <span class="pre">SUCCESS;</span> <span class="pre">}</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">default</span> <span class="pre">event</span> <span class="pre">void</span> <span class="pre">Boot.booted()</span> <span class="pre">{</span> <span class="pre">}</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<div class="section" id="initialization">
<h2><a name="initialization">4.1 Initialization</a></h2>
<p>The first step in the boot sequence is initializing the system:</p>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">atomic</span> <span class="pre">{</span></tt></div>
! <div class="line-block">
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">Scheduler.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">PlatformInit.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">while</span> <span class="pre">(call</span> <span class="pre">Scheduler.runNextTask());</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">call</span> <span class="pre">SoftwareInit.init();</span></tt></div>
! <div class="line"><tt class="docutils literal"><span class="pre">while</span> <span class="pre">(call</span> <span class="pre">Scheduler.runNextTask());</span></tt></div>
! </div>
! <div class="line"><tt class="docutils literal"><span class="pre">}</span></tt></div>
! </div>
<p>The boot sequence has three separate initializations: Scheduler,
PlatformInit, and SoftwareInit. The boot configuration (MainC) wires
--- 433,477 ----
components that implement standard abstractions and exports the others
that are application specific. Code above the Hardware Independent
! Layer (TEP 2) SHOULD wire to MainC and not RealMainP:</p>
! <pre class="literal-block">
! module RealMainP {
! provides interface Booted;
! uses {
! interface Scheduler;
! interface Init as PlatformInit;
! interface Init as SoftwareInit;
! }
! }
! implementation {
! int main() __attribute__ ((C, spontaneous)) {
! atomic {
! call Scheduler.init();
! call PlatformInit.init();
! while (call Scheduler.runNextTask());
! call SoftwareInit.init();
! while (call Scheduler.runNextTask());
! }
! __nesc_enable_interrupt();
! signal Boot.booted();
! call Scheduler.taskLoop();
! return -1;
! }
! default command error_t PlatformInit.init() { return SUCCESS; }
! default command error_t SoftwareInit.init() { return SUCCESS; }
! default event void Boot.booted() { }
! }
! </pre>
<div class="section" id="initialization">
<h2><a name="initialization">4.1 Initialization</a></h2>
<p>The first step in the boot sequence is initializing the system:</p>
! <pre class="literal-block">
! atomic {
! call Scheduler.init();
! call PlatformInit.init();
! while (call Scheduler.runNextTask());
! call SoftwareInit.init();
! while (call Scheduler.runNextTask());
! }
! </pre>
<p>The boot sequence has three separate initializations: Scheduler,
PlatformInit, and SoftwareInit. The boot configuration (MainC) wires
***************
*** 527,531 ****
part of making the overall hardware platform operable. One example of
this sort of initialization is clock calibration. Because PlatformInit
! calls the component PlatformC, each platform can specify the requires
initialization order. As these hidden dependencies must be due to
hardware, the sequence is platform-specific.</p>
--- 503,507 ----
part of making the overall hardware platform operable. One example of
this sort of initialization is clock calibration. Because PlatformInit
! calls the component PlatformC, each platform can specify the required
initialization order. As these hidden dependencies must be due to
hardware, the sequence is platform-specific.</p>
More information about the Tinyos-2-commits
mailing list