[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep106.txt, 1.11,
1.12 tep107.txt, 1.5, 1.6
Phil Levis
scipio at users.sourceforge.net
Tue Jul 12 11:20:31 PDT 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19561
Modified Files:
tep106.txt tep107.txt
Log Message:
Incorporated comments from TinyOS devel.
Index: tep106.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep106.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** tep106.txt 6 Jul 2005 23:22:03 -0000 1.11
--- tep106.txt 12 Jul 2005 18:20:28 -0000 1.12
***************
*** 131,141 ****
| ``interface TaskParameter {``
! | ``async error_t command post(uint16_t param);``
! | ``event void run(uin16_t param);``
| ``}``
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 ``run`` event with the passed parameter, which contains
the task's logic.
--- 131,141 ----
| ``interface TaskParameter {``
! | ``async error_t command postTask(uint16_t param);``
! | ``event void runTask(uin16_t param);``
| ``}``
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.
***************
*** 179,186 ****
A scheduler MUST provide a parameterized TaskBasic interface.
! If a call to TaskBasic.post() returns SUCCESS, the scheduler MUST run it
! eventually. The scheduler MUST return SUCCESS to a TaskBasic.post()
! operation unless it is not the first call to TaskBasic.post() since
! that task's TaskBasic.run() event has been signaled.
A scheduler MUST provide the Scheduler interface.
--- 179,186 ----
A scheduler MUST provide a parameterized TaskBasic interface.
! If a call to TaskBasic.postTask() returns SUCCESS, the scheduler MUST run it
! eventually. The scheduler MUST return SUCCESS to a TaskBasic.postTask()
! operation unless it is not the first call to TaskBasic.postTask() since
! that task's TaskBasic.runTask() event has been signaled.
A scheduler MUST provide the Scheduler interface.
***************
*** 204,212 ****
runNextTask(TRUE) always return TRUE.
! The TaskBasic interface is this:
| ``interface TaskBasic {``
! | ``async command error_t post();``
! | ``void event run();``
| ``}``
--- 204,212 ----
runNextTask(TRUE) always return TRUE.
! This is the TaskBasic interface:
| ``interface TaskBasic {``
! | ``async command error_t postTask();``
! | ``void event runTask();``
| ``}``
***************
*** 217,224 ****
wired to the Scheduler with a unique identifier as its parameter.
The parameter MUST be obtained with the ``unique`` function in nesC,
! with a key of ``"BasicScheduler.TaskBasic"``.
The SchedulerBasic implementation uses these identifiers as its queue
! entries.When TinyOS tells the Scheduler to run a task, it pulls the
next identifier off the queue and uses it dispatches on the
parameterized TaskBasic interface.
--- 217,226 ----
wired to the Scheduler with a unique identifier as its parameter.
The parameter MUST be obtained with the ``unique`` function in nesC,
! with a key of ``"BasicScheduler.TaskBasic"``. The nesC compiler
! automatically does this wiring when the ``task`` and ``post``
! keywords are used.
The SchedulerBasic implementation uses these identifiers as its queue
! entries. When TinyOS tells the Scheduler to run a task, it pulls the
next identifier off the queue and uses it dispatches on the
parameterized TaskBasic interface.
***************
*** 247,252 ****
| ``interface TaskEDF {``
! | ``async command error_t post(uint16_t deadline);``
! | ``void event run();``
| ``}``
--- 249,254 ----
| ``interface TaskEDF {``
! | ``async command error_t postTask(uint16_t deadlineMs);``
! | ``event void runTask();``
| ``}``
***************
*** 277,282 ****
For a module to have an earliest deadline first task, it uses the
! TaskEDF interface. Its configuration SHOULD wire it to TinyScheduler,
! using a unique value generated from the key "TaskEDF." For example:
| ``configuration SomethingC {``
--- 279,287 ----
For a module to have an earliest deadline first task, it uses the
! TaskEDF interface. Its configuration SHOULD wire it to TinyScheduler.
! The key used for task unique identifiers MUST be "TinyScheduler.TaskInterface",
! where *TaskInterface* is the name of the new task interface as presented
! by the scheduler. For example, the module SomethingM requires two EDF
! tasks:
| ``configuration SomethingC {``
***************
*** 285,293 ****
| ``implementation {``
| ``components SomethingM, TinyScheduler;``
! | ``SomethingM.TaskEDF -> TinyScheduler.TaskEDF["TaskEDF"];``
! | ``TaskBasic = SchedulerEDF;``
! | ``TaskEDF = SchedulerEDF;``
| ``}``
--- 290,344 ----
| ``implementation {``
| ``components SomethingM, TinyScheduler;``
! | ``SomethingM.SendTask -> TinyScheduler.TaskEDF["TinyScheduler.TaskEDF"];``
! | ``SomethingM.SenseTask -> TinyScheduler.TaskEDF["TinyScheduler.TaskEDF"];``
| ``}``
+ The module SomethingM also has a basic task. The nesC compiler
+ automatically transforms task keywords into BasicTask interfaces and
+ wires them appropriately. Therefore, for basic tasks, a component
+ author can either use the ``task`` and ``post`` keywords or use a TaskBasic
+ interface. A component SHOULD use the keywords whenever possible, and it
+ MUST NOT mix the two syntaxes for a given task. This is an example
+ implementation of SomethingM that uses keywords for basic tasks:
+
+ | ``module SomethingM {``
+ | ``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();``
+ | ``}``
+ | ``}``
+
+ If the scheduler provides two instances of the same task interface,
+ their unique keys are based on the name of the interface as the
+ scheduler presents it (the "as" keyword). For example, imagine
+ a scheduler which provides two instances of TaskBasic: standard
+ tasks and high-priority tasks. The scheduler always selects a task
+ for the high priority queue before the standard queue:
+
+ | ``configuration TinyScheduler {``
+ | ``provides interface Scheduler;``
+ | ``provides interface TaskBasic[uint8_t taskID];``
+ | ``provides interface TaskBasic[uint8_t taskID] as TaskHighPriority;``
+ | ``}``
+
+ A component that uses a high priority task would then wire to
+ TaskHighPriority with the key "TinyScheduler.TaskHighPriority":
+
+ | ``configuration SomethingElseC {``
+ | ``}``
+ | ``implementation {``
+ | ``components TinyScheduler, SomethingElseM;``
+ | ``SomethingElseM.RetransmitTask -> TinyScheduler.TaskHighPriority[unique("TinyScheduler.TaskHighPriority")];``
+ | ``}``
Index: tep107.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep107.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep107.txt 7 Jul 2005 21:28:44 -0000 1.5
--- tep107.txt 12 Jul 2005 18:20:29 -0000 1.6
***************
*** 187,191 ****
2) If no such flag exists, the Init.init() implementation MAY
temporarily enable interrupts. It MUST NOT call any other
! component or return unless it has re-disabled interrupts.
Unless part of a hardware abstraction architecture (HAA)[tep2]_, the
--- 187,199 ----
2) If no such flag exists, the Init.init() implementation MAY
temporarily enable interrupts. It MUST NOT call any other
! component or return until it has re-disabled interrupts.
!
! As 2) means that interrupts may be temporarily enabled during
! initialization, components that control interrupts SHOULD NOT
! cause interrupts to fire after their Init.init() returns.
! However, it is possible that other components will cause an
! interrupt to fire due to hardware interactions or semantics.
! Therefore, a component MUST properly handle interrupts at
! all times.
Unless part of a hardware abstraction architecture (HAA)[tep2]_, the
***************
*** 195,202 ****
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 to the boot
! sequence, unless there is a temporal ordering requirement.
5. Author's Address
--- 203,213 ----
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
! 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.
5. Author's Address
More information about the Tinyos-beta-commits
mailing list