[En-Nut-Discussion] RFQ: Changes to Nut/OS to support AT90CAN128

[Henrik Maier]

The AT90CAN128 requires the stack to always point to internal memory due 
to a silicon bug (Refer Atmel's latest AT90CAN128 errata). I published 
related posts a few months ago. This requirement is in conflict with 
Nut/OS' stack allocation mechanism for threads which places the stack 
anywhere on the heap. In order to support the AT90CAN128 the mechanism 
has to be modified.

I have been working on this issue for a while and recently continued 
with a possible implementation. Before I publish the changes and commit 
them to the CVS I thought I discuss them first:

There are now two heaps. One heap for the thread stack and one standard 
heap. When a thread is created, it's stack is dynamicaly allocated on 
the special "thread stack heap" which is always kept in internal memory. 
All other heap allocations are made on the "standard heap" which is in 
external memory after the .data/.bss segments. The .data/.bss segments 
start at the the beginning of external memory right after the stack heap.

Using this concept one can run approx 8 to 16 threads on the AT90CAN128 
which is sufficient for most apps. There is a limit compared to the flat 
heap model used for ATmega128 as the stack heap can only be 4KB (= 
internal RAM size) large and limits the amount of threads able to run. 
Each thread needs a few hundred bytes of stack.

Three new functions NutStackAlloc, NutStackFree and NutStackAdd have 
been introduced. They wrap the standard heap functions NutHeapAlloc, 
NutHeapFree and NutHeapAdd and make them operate on a different heap 
node list. Hence a separate heap call "stack heap" now exists.

The thread creation has been modified:
- NutThreadCreate calls NutStackAlloc instead of NutHeapAlloc
- NutThreadDestroy calls NutStackFree instead of NuHeapFree
- NutInitHeap calls now NutStackAdd and NutHeapAdd

The thread heap only exists for AT90CAN128 MCUs to overcome it's silicon 
bug. For all other CPUs the classic model is still used.

I am not quite sure how to resolve the following issues:

* thread.c currently contains an #ifdef to check if NutThreadDestroy 
should call NutStackFree or NutHeapFree. Not nice as this is meant to be 
a generic piece of code.

* Where to put the prototypes for the 3 new functions
NutStackAlloc, NutStackFree, NutStackAdd. Currently I put them into 
avr.h embedded in an #ifdef __AT90CAN128__ . This works for now but 
there should be a more appropriate place.

* How to incorporate the linker flag -Wl,-Tdata=0x801100 into nutconf's 
build model. All apps compiled for the AT90CAN128 require relocation of 
.data/.bss into the external RAM.

Comments and suggestion are welcome.

Henrik

-- 
proconX - Protocol Converter, Device Server and Industrial Gateways
http://www.proconx.com  Tel: +61-7-3376 3911   Fax: +61-7-3102 9206