Re: [avr-gcc-list] task/thread stack usage

[Tvrtko A. Ursulin]

On Friday 25 April 2003 17:48, Larry Barello wrote:

> I don't know how ethernut, bdmicro or Tvrktko do their interrupt
> handling - apparently I am the only one who saves the entire context
> prior to entering the code that might cause a context switch.  Even if
> I delayed the context switch until I needed it, that would leave an
> unspecified amount of junk on the interrupt handler stack which would
> have to be copied onto the user stack, or restored or something.
> Anyway, I decided the overhead of a 1/2 context switch upon entry into
> RTOS managed interrupt handlers was a decent trade off between overall
> cycles and code size and SRAM footprint (I originally developed on a
> 2313, so SRAM footprint was  a pretty big {small} concern... :)

I laso save the entire context as a first thing when entering kernel 
scheduler. But it is also important that I never enter kernel scheduler when 
context switch will not occur. To be precise, if task X has priority P (which 
translates to time quantum Q), then it will run interrupted the whole Q. So 
there are no uneccesary switches. But X can call something like 
schedule(_timeout), down, wait_complete, sleep_on(_timeout) and in that case 
it forces a context switch.

When RAM usage is concerned, each task uses 35 bytes for minimum stack space. 
Kernel uses minimum 8+6*Ntasks (or more if some extra features are compiled 
in).  Also, there is always the system idle task as task 0. All interrupts, 
kernel + task have theirs unified stack which starts at RAMEND-2. Memory map 
is as follows:

.word   IrqStackPointerStorage
.block  IrqStackSpace
.block  Task0Stack
.block  Task1Stack
.....

There are 3 new gcc attributes: task, irq and softirq. Therefore it is not 
neccesary to call any manual entry/exit macros/functions in tasks and 
interrupt handlers.

All this currently runs on 8515 - don't know about others.

If it sound interesting to the community, maybe I can put it under GPL and 
release it.