[En-Nut-Discussion] RFQ: Changes to Nut/OS to support AT90CAN128
hmlists at focus-sw.com
Sat Sep 3 07:41:26 CEST 2005
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.
proconX - Protocol Converter, Device Server and Industrial Gateways
http://www.proconx.com Tel: +61-7-3376 3911 Fax: +61-7-3102 9206
More information about the En-Nut-Discussion