Hi Jon

Generally (in my opinion and experience) a high percentage of embedded projects don't have
any real advantage using a pre-emptive scheduler. A pre-emptive scheduler requires a certain
amount of design skill, more resources and higher risk of 'hidden' errors (things that can go
wrong only when a number of things take place in certain orders at certain timers and thus are
often difficult to find).

Pre-emptive capabilities can however have important advantage in some projects and so are
preferred for such projects - in some projects they may also be the only feasible solution.

Interrupts are very important in drivers in a non-pre-emptive design since they allow fast
reaction to events such as data reception and then an 'offline' processing of the data content -
it is assumed that the processing itself is not highly time-critical since it will take place once
its handling task is next scheduled.

A single SPI based device shouldn't be a problem in an interrupt routine. The accesses are not
that slow and only make a few us difference compared to an on-chip or parallel device. This
shouldn't normally make any real difference and so received data can be copied to a driver
input buffer, making the further processing less critical. When several devices are sharing an
SPI it becomes more complicated due to the fact that disturbance of active SPI accesses need
to be avoided - this required the interrupt to be blocked during accesses so that other
interrupts can't take place which could try to use it (at least blocking between setting and
clearing the CS line). This is however not a weakness of a non-pre-emptive solution but more
general and so there shouldn't be any real disadvantages in this particular case. As long as
interrupt handling is fast (the interrupt processing time itself doesn't cause other events in the
system to be unacceptably delayed) things should be fine.

In a single case it is also quite simple to run longer interrupt handlers (eg. the reception and
processing of data from an interrupt driven peripheral) in a low priority interrupt routine. This
means that the interrupt occurs but the processors interrupts are allowed to continue arriving
(either based on level or all) while the routine continues to handle the data. This will of
course block other tasks from operating during this time but not other interrupts - these can
continue being handled. In fact this shouldn't have any disadvantages over a pre-emptive
solution which first detects the interrupt and then causes a high priority task to run - the high
priority task will need to be switched to as fast as possible and then blocks any other tasks in
the system to ensure it meets its speed requirements; simply staying in the interrupt (but
unmasking where possible) results in the same effect but without the need to get from the
start of the interrupt to the handling as fast as possible using task a context switch - the
context switch becomes redundant since the handling can simply continue and so is also
optimally fast.

Of course, when interrupt masking based on levels is used (the standard situation in uTasker
project is that all interrupts are closed when handling any interrupt) there are other potential
pitfalls and the design also gets a little more complicated, but it is still a powerful technique.

Generally I don't think that interrupt handling is something which the uTasker scheduling
technique suffers from compared to a pre-emptive solution using context switching; a context
switching will always introduce larger delays and more overhead generally. Generally using
standard interrupt and interrupt nesting techniques allows most critical problems to be solved
quite well. Where the pre-emptive solutions have main advantages is in cases where tasks
need to perform a large amount of work (task run through time is high) and this work can not
(easily) be "time -sliced" - an example is when calling library routines that have a high
processing overhead (like encryption libraries) - in these cases there is a definite advantage -
but at the end of the day choosing the best tools for a job is also the art of getting a job done
the best. It must be able to do the job in hand but not be over-kill or too complicated...

Regards

Mark