Re: [avr-gcc-list] stack layout

[Klaus Rudolph]

> For a design that has a lot of I/O events, a simulator has to be very, very
> carefully scripted, if it is possible at all, to create the randomness and
> nesting as will be seen in the real, "noisy" world of interrupts.
>  
Sometimes it is useful to have a deep look inside the code and you can 
see that a lot of conditions
will not run into failures. If interrupts could not come when an other 
interrupt is active the situation is not
complex. But yes, to randomise all the things is difficult but one of 
the solutions
is to trace all events on a real hardware with a logic analyser and 
replay the event list
in the simulation. But we are talking over avr, here we have not 
hundrets of potentional parallel irq´s :-)
For me worst case analysis was allways good enough. Most problems occur 
inside the heap management when
fragmentation is a problem. And if you have recursive function calls you 
can waste a lot of stack space at all.
These things could be simulated very fast and simple whithout a lot of 
external event scripting. After that
you have real facts for the software under the tested conditions. All in 
hardware monitoring
solutions have allways the problem of a different timing behaviour. And 
simulation give you also an idea which task/function
in your software has consumed which bytes on the stack and also how 
often this was happened.
For me simulation is the best solution because it is convinient and 
faster then real hardware turnaround cycles.
Sometimes we have no hardware so simulation is the only solution for the 
problem :-)


Regards,
  Klaus




> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> Klaus Rudolph
> Sent: Friday, June 24, 2005 11:07 PM
> To: Torsten Mohr
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] stack layout
>
> Hi Torsten,
>
>
> to get a complete overview on memory layout whithout touching the
> software itself you simply run your application in a simulator and
> monitor the stack and maybe the heap usage if needed.
> You can also manipulate the irq load and other environment things there
> for worst case situations to get an error free application. To do this in
> real hardware is not a easy thing. If you add monitoring code
> to your software the timing relevant things will be totally differnt and 
> maybe
> your application works only with debug code but you will maybe have
> problems if you run your "relaese" version.
>
> Bye
>  Klaus
>
>
>  
>
> > Hi,
> >
> > i'd like to change the memory layout of a program, especially the
> > stack.
> >
> > So i linked my program with --defsym,__stack=0x900
> >
> > When i look into the listing of my program that i got with:
> > avr-objdump -h -S file.elf
> >
> > Then in __init the stackpointer still gets loaded as 0x10ff.
> > But in the beginning of main it gets reloaded to 0x8ff.
> >
> > Is it a bug that the stack is set to 0x10ff in __init?
> >
> > Can i change the options somehow to _always_ use 0x8ff for
> > the stack, also in __init?
> >
> > Shouldn't the startup code also refer to the symbol __stack?
> >
> > __stack seems to be only a symbol, not a section.  Would it make
> > sense to define an own section for the stack, so some overlap
> > checking could be done?
> >
> >
> >
> > Best regards,
> > Torsten.
> >
> >
> >
> >    
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
>
>
>