[En-Nut-Discussion] Status of CAN128 Port?

[Henrik Maier]

Harald,

I am prepared to take on the challenge again and "play" with this 
option. However I think I need a kind of a break to re-charge my 
enthusiasm after finding this issue before I continue and I also like to 
wait what work-around and statement Atmel is coming up with.

Cheers

Henrik

FOCUS Software Engineering Pty Ltd
Brisbane, Australia - Web: www.focus-sw.com
Phone: +61-402 970 933 - Fax: +61-7-3009 0399



Harald Kipp wrote:
> IMHO, this could be solved without re-writing the linker
> script. All stack space is allocated in thread.c and should
> use a different heap.
> 
> We may use
> 
>   u_char nutmem_onchip[NUTMEM_RESERVED];
> 
> defined in os\arch\avr_nutinit.c, then add
> 
>   NutHeap2Add(nutmem_onchip, NUTMEM_RESERVED);
> 
> and use
> 
>   threadMem = NutHeapAlloc2(stackSize + sizeof(NUTTHREADINFO));
> 
> in os\arch\avr_thread.c, then it may work. The
> correct value of NUTMEM_RESERVED should be checked
> against the map file. For auto detection of the CPU
> crystal clock to work correctly,
> 
>   volatile u_char ms62_5 = 0;
> 
> in os\nutinit.c must be located in internal RAM too.
> 
> A simple copy of heap.c named heap2.c may provide the
> second heap.
> 
> Hope, I didn't overlook something.
> 
> Harald
> 
> At 09:56 05.04.2005 +0200, you wrote:
> 
>> Hi all,
>>
>> > Maybe someone else has a better idea.
>>
>> Maybe one could change the calling convetions in the manner that the
>> interrupts will be disabled on any stack operation like function calls?
>> But IMHO this would need a change in the compiler to be convenient.
>>
>> Any other opinion?
>>
>> Bye,
>>
>> Ole
> 
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 
> 
>