Hi
Tasks are quit when waiting for a delay. Depending on how the tasks are configured, they will be polling, scheduled periodically or in the stop state. Generally their state doesn't need to be changed in any way.
Exactly how best to wait for something to be ready depends on exactly what this is. Here are a couple of examples:
1. The task has done something and the next action should be performed 10s later.This is generally performed by starting a monostable timer (see
http://www.utasker.com/docs/uTasker/uTaskerTimers.PDF ). A local state variable could be set to a certain if required (STATE) - although often simply the timer event will be adequate.
When the defined timer fires, the task will be scheduled with the timer event (EVENT) in the input queue and the second action can be performed.
2. A message is sent via an interface (eg. serial) and an answer or a timeout is expected.The message is sent and a monostable timer is started (with defined timeout EVENT). The task is again quit - possibly the local state variable is set to reflect the fact that an answer is expected.
When the message is received the task (is set as owner of the interface) will be woken (either on each character or on complete message, depeinging on interface mode). This wake up is not accompanied with an event but the read of the interface will identify that a message (or part of a message) is waiting.
If the answer is received, the monitoring timer can be stopped before it fires.
If the monitoring timer fires, the event which is received can be used to repeat the request or to signal an error.
3. Transmission to an interface (also TCP) where there is not enough buffer space (eg. when TCP window closes or serial interface is stalled due to handshake).In this case there is a system event called TX_FREE which signals the owner task that a resource has adequate space to continue.
There are further examples of this in the following threads:
http://www.utasker.com/forum/index.php?topic=91.0 (serial interface with output buffers smaller than message length)
http://www.utasker.com/forum/index.php?topic=25.msg101#msg101 (TCP transmission flow control).
Basically tasks can often also be thought of as state-machines. They know in which state they are in (if necessary) by using a local state variable (eg.
static int iState = 0;). They usually only get schedules as a result of an event (timer firing, reception from and interface, etc.). Generally the task has a job to do based in the event and is then quit (as soon as possible). Exceptions are polling tasks which are scheduled whenever others are not running.
Most processors support a low power mode. By activating SUPPORT_LOW_POWER (in config.h - supported by Coldfire and SAM7X projects) the CPU is set to the idle state (low power) and runs only when interrupts need to be handled or events need to be scheduled - events are generally results of interrupts (timer, interfaces).Regards
Mark