Context switch

[orenl]

Hello

I read the uTasker Operating System Basics document.
I didn't see any thing that remind a context switch.
Does the uTasker support context switch?
Is it true that a task always start from the beginning and it can't resume to the point it was before?

[mark]

Hi

Please see the following thread for details concerning this:
http://www.utasker.com/forum/index.php?topic=59.msg235#msg235

The uTasker is not a pre-emptive solution. It is state-event driven and supports methods to solve most wait situations and is designed for simplicity and reliability in (mainly) communications oriented applications. There are some projects (although surprisingly fewer that one might first expect) which demand pre-emptive support. For projects with specific demands for pre-emptive operation, beyond those achieved by using interrupts and the the mechanisms in the uTasker, other solutions may be better suited.

There is however no guarantie that a pre-emptive solution (especially when not absolutely necessary) will result in better performance, better reliability, faster development time or better end-products - sometimes the inverse will be true and some bugs (design errors) in such systems can be very difficult to find - resulting in increased project delays and long-term reliability difficulty.

We believe that the uTasker is a suitable solution for a large percentage of embedded projects - it is up to the user to make the final decision based on his/her specific requirements.

Regards

Mark

[orenl]

If i understood correct:
If i want to go out from a task (waiting for a long delay), in order to come back to the next line code (after the delay) do i need a state machine in the task?
Does UTASK_STOP exit from the specific task and when returning to the task(by event) my state machine needs to bring me to the next step in the task?

Thanks

[mark]

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