From 65f3fc43893bc6395ed47e8d43d79639a0cdbe28 Mon Sep 17 00:00:00 2001 From: scipio Date: Sat, 20 Jan 2007 00:39:14 +0000 Subject: [PATCH] Addressed review comments. --- doc/txt/tep106.txt | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/doc/txt/tep106.txt b/doc/txt/tep106.txt index 4c9d1e5d..971e44ee 100644 --- a/doc/txt/tep106.txt +++ b/doc/txt/tep106.txt @@ -178,9 +178,8 @@ to take an integer parameter could look like this:: Using this task interface, a component could post a task with a ``uint16_t`` parameter. When the scheduler runs the task, it will signal the ``runTask`` event with the passed parameter, which contains -the task's logic. Note, however, that this does not save any RAM: if -anything, it will cost RAM as space must be allocated in the scheduler -and may then also be allocated in the component. Furthermore, as +the task's logic. Note, however, that this does not save any RAM: +the scheduler must have RAM allocated for the parameter. Furthermore, as there can only be one copy of a task outstanding at any time, it is just as simple to store the variable in the component. E.g., rather than:: @@ -271,6 +270,11 @@ runNextTask(TRUE) always return TRUE. The taskLoop() command tells the scheduler to enter an infinite task-running loop, putting the MCU into a low power state when the processor is idle: it never returns. +The scheduler is repsonsible for putting the processor to sleep +predominantly for efficiency reasons. Including the sleep call +within the scheduler improves the efficiency of the task loop, +in terms of the assembly generated by the TinyOS toolchain. + This is the TaskBasic interface:: interface TaskBasic { @@ -293,6 +297,10 @@ entries. When TinyOS tells the scheduler to run a task, it pulls the next identifier off the queue and uses it to dispatch on the parameterized TaskBasic interface. +While the default TinyOS scheduler uses a FIFO policy, TinyOS +components MUST NOT assume a FIFO policy. If two tasks must run +in a particular temporal order, this order should be enforced by +the earlier task posting the later task. 5. Replacing the Scheduler ==================================================================== @@ -396,7 +404,9 @@ implementation of SomethingP that uses keywords for basic tasks:: The requirement that basic tasks not be subject to starvation requires that a scheduler supporting EDF tasks must ensure that basic tasks run eventually even if there is an unending stream of -short deadline tasks to run. +short deadline tasks to run. Quantifying "eventually" is difficult, +but a 1% share of the MCU cycles (or invocations) is a reasonable +approximation. If the scheduler provides two instances of the same task interface, their unique keys are based on the name of the interface as the -- 2.39.2