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

[Harald Kipp]

Henrik,

IMHO, it's a good idea to create new functions named NutStack*().

At 15:41 03.09.2005 +1000, you wrote:

>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.

Why not use NutStack*() for all targets? In the future we
may be able to optionally configure a separate memory area
for the stack. Even some ATmega128 based systems may benefit
from using fast internal RAM.


>* 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.

My first idea is to add the new functions to
   arch/<platform>/os/thread.c
and the prototypes to
   include/sys/thread.h

For now most architectures will simply pass the
calls to NutHeap*().


>* 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.

Well, hum... complicated stuff. For several times I tried to
implement a more consistent configuration for compiler/linker
options, but every time I got stuck somewhere. If you want to
do it in short time

a) Create new Make*.avr-xgcc files and update nutsetup.
(nutconf will detect them automatically)

b) or implement a new Makefile macro for additional
linker options. In this case, nutsetup and the Lua scripts
have to be modified.

I assume that option a) can be done easily. Option b) is much
better and has the potential to expand to fully configurable
compile options. But that's where I got stuck in the past.

Harald