[En-Nut-Discussion] RFC: Nut/OS Tasks

[Harald Kipp]

Hi all,

After Nathan convinced me, that timer callbacks are not the best
solution to handle background task, I investigated several other options
and would like to offer another solution. In fact, these ideas are not
new, but had been discussed in several threads in this mailing list by
Nathan, Ole, Duane and others.

What do you think about the introduction of tasks? A task is a routine,
which can be scheduled for execution. A task may be scheduled by
ordinary code as well as interrupt routines. Task are executed by a new
thread, running at highest priority.

This follows Nathan's suggestion of an all purpose background thread.

To schedule a task

 int NutTaskSchedule(prio, function, param, delay);

must be called. This will create a task structure, which is added to a
priority queue.

 prio Priority of the task
 function Pointer to the function that will be executed
 param A pointer which is passed to the function
 delay Number of milliseconds the execution will be delayed

The delay parameter will make things a bit more complicated, but provide
a convenient interface for modules that have to keep track of certain
timeouts like TCP, DHCP, ARP etc.

Not sure about the API yet. We may also need NutTaskCancel and possibly
a few other functions.

We may later think about a second task queue for low priority tasks,
executed from NutIdle.

We may also add a very high priority task queue, which is executed
immediately after returning from interrupt. This would follow the
suggestions of Duane Ellis, splitting interrupt routines into two parts
(similar to Unix/Linux kernels). However, as Duane explained, these
tasks must not call blocking functions.

A last option is to allow reentrant interrupts. However, this is most
complicated stuff and I doubt, that it is really required. Most Nut/OS
interrupts are very short and it might be a good idea to keep it this
way. Right now the most time consuming interrupts are in the UART
drivers, because buffering incoming characters or acting on hardware
handshake needs to be done in shortest time. Most other drivers can
safely delay input processing.

Harald