Re: [avr-chat] A new AVR architecture

[Ned Konz]

On Saturday 02 July 2005 6:11 pm, Ron wrote:
> I have used AVRs for around eight years as my workhorse processor. As
> long as the application could be served by my task based non-preemptive
> operating system, this was the chip I used. Recently, however, I had a
> couple of projects that, although their specification required a
> prioritised pre-emptive operating system and therefore some hardware
> memory protection, they really didn't need a full-blown 32-bit
> processor.
>
> I am finding that new project specifications are increasingly combining
> complex background processing with a range of prioritised events where
> response times are critical, but where, apart from the requirement for
> preemption, an 8-bit processor would be quite adequate. For those
> readers who have implemented a preemptive operating system (OS) on an
> AVR I agree it is possible but I am philosophically against preemption
> without memory protection, particularly where the customer can
> subsequently add new modules to my design. Stack overflow is simply
> intractable in this hardware.

Of course, it's quite possible to have preemption on the AVR; we do it all the 
time. There is already hardware for interrupt prioritization.

If you use a task architecture that does not require (or allow) individual 
tasks to preempt each other you don't need:

* stack switching
* mutexes
* stack overflow detection

The problem with most existing preemptive multitaskers is the concept of 
long-running tasks that can preempt each other. But that's not the only way 
to organize an embedded system.

If you use a run-to-completion model, with events posted to tasks by interrupt 
handlers (and also possibly by other tasks), then you never have one task 
preempting another, and so avoid most of the problems you're trying to guard 
against. You can use one stack, for instance, without the need to swap 
registers in and out.

I've been working on a port of Miro Samek's Quantum Framework, Quantum Event 
Processor, and Quantum Kernel to AVR/gcc. See http://www.quantum-leaps.com 
for a description of these.

These comprise a robust hierarchical state machine framework, high-performance 
event queuing (unicast or multicast), and a multitasking kernel with 
priorities.

Each time a task is awakened by the receipt of an event, it merely responds to 
that event and returns. Very simple.

Take a look at it...
-- 
Ned Konz
http://bike-nomad.com