AW: [En-Nut-Discussion] Suggestion for C++ initialisation change.

[Oliver Schulz]

Hi Phil,

(Concerns only avr-gcc compiler!)

Yes, I see the problem. Because the constructors for static objects are
called in .init6 section, the right place for initializing the heap is
indeed the .init5 section.

But there is still one minor problem, that can cause a crash anyway. At the
stage of calling the c++ constructors, the stack pointer is still
initialized to the end of the ram, because the main/idle thread is not yet
created. Hopefully the c++ constructors don't need temporarily so much heap
memory, that it will run in the stack area...

Anyway, I have modified the avr_nutinit.c file to have the heap
initialization in section .init5.
I hope, that there is no problem with icc compiler.

To Harald: Perhaps I missed something, but I think the files cfg/arch/avr.h
and cfg/arch/avrpio.h must also be included in avr_nutinit.c to have the
EEPROM emulation also compiled, right?

Regards,
Oliver.


> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de 
> [mailto:en-nut-discussion-bounces at egnite.de] Im Auftrag von Phil Maker
> Gesendet: Freitag, 25. Februar 2005 01:32
> An: en-nut-discussion at egnite.de
> Betreff: [En-Nut-Discussion] Suggestion for C++ initialisation change.
> 
> G'day,
> 
> The problem:
> 
> 	malloc/new inside C++ constructors always return 0 since they
> 	are not initialised. e.g.
> 
> 	class V {
> 	  float *p;
> 	public:
> 	  V(int n) {
> 	    p = malloc(sizeof(float)*n);
> 	  }
>         };
> 
> 	V x(10);
> 
> The answer, I think (whence this message):   
> 
> 	Modify avr_nutinit.c so we initialise the Heap before 
> 	calling the constructors. I've done this by breaking 
> 	the NutInit function into NutInitHeap and NutInit and putting
> 	them in separate init sections, i.e.
> 
> 
> void NutInitHeap(void) __attribute__ ((naked)) __attribute__ 
> ((section(".init5")));
> void NutInit(void) __attribute__ ((naked)) __attribute__ 
> ((section(".init8")));
> 
> void NutInit(void)
> {
>     /*
>      * We can't use local variables in naked functions.
>      */
> #ifdef NUTDEBUG
>     outp(7, UBRR);
>     outp(BV(RXEN) | BV(TXEN), UCR);
> #endif
> 
>     /* Create idle thread
>      */
>     NutThreadCreate("idle", NutIdle, 0, NUT_THREAD_IDLESTACK);
> }
> 
> void NutInitHeap(void)
> {
> 
>     /* If we have external RAM, initialize stack pointer to
>      *  end of external RAM to avoid overwriting .data and 
> .bss section
>      */
>     SP = (u_short)(NUTMEM_END);
> 
>     /* Then add the remaining RAM to heap.
>      *
>      * 20.Aug.2004 haraldkipp: This had been messed up 
> somehow. It's nice to have 
>      * one continuous heap area, but we lost the ability to 
> have systems with
>      * a gap between internal and external RAM.
>      */
>     if ((u_short)NUTMEM_END - (u_short) (&__heap_start) > 384) {
>         NutHeapAdd(&__heap_start, (u_short) NUTMEM_END - 256 
> - (u_short) (&__heap_start));
>     }
> }
> 
> 	The alternative would be to move the whole 
> initialisation process
> into a lower number init segment. 
> 
> 	Any comments/thoughts from the gentle audience.
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>