----- Ursprüngliche Nachricht -----
Von: Peter Bigot
Gesendet am: 19.April.2012 15:39:38
On Thu, Apr 19, 2012 at 7:37 AM, Doug Carlson <carl...@cs.jhu.edu> wrote:
>> Two questions, which may be more general gcc/ld-related than msp-specific
>> 1. While it's impossible in the general case to determine the maximum stack
>> size that a program will use, is there any mspgcc setting (or standalone
>> tool) that can handle the simple cases that dominate in MCUs (no recursion,
>> no function pointers, no nested ISRs) and spit out a maximum stack depth?
>Not that I know of.
Nor do I.
The stack, by definition, grows if necessary by the program flow.
There is no way to limit it.
On PC, the memory management may throw a violation if the stack grows below
its reserved memory segment. On MSP, this is possible too, but only from
outside.
One can set a write access trigger on a memory location, and once the stack
grows to this point, a breakpoint will be triggered.
Well, it doesn't work anyway, if a large local array is placed on the stack, and
this particular array element is never written too.
The only thing that can be done is to put a guard value at a strategic location,
and check it inside a timer ISR or such.
However, the same problem as with the breakpoint applies, if this location is
'skipped'.
Calculating the required stack space before execution can only be done by
simulating all possible program runs, deepest possible iterations, worst
case appearance of the ISR with the heaviest stack usage
(even more complex with nested ISRs) etc.
Well, this is an area where a clean program structure surely helps the
developer. It's still a guess anyway.
Engineers rule: carefully calculate, add a safety margin,
and then double the result, just to be sure.
>> a. Use the RESERVE_RAM
>> annotation<http://mspgcc.sourceforge.net/manual/x1023.html> on
>> the main method. This is somewhat undesirable to me because I'm working in
> It also probably won't work. I don't think that feature is present
> anymore; there are other ways to reserve RAM above the stack (these
> involve replacing a function in a CRT section).
The CCS and IAR compilers have a 'stack size setting', which causes a
'stack segment' placed on top of ram (or at least as last ram segment)
like a normal linker object.
So if you know you need a certain amount of ram, you'll get a linker error if
global variables and 'reserved' stack space won't fit into ram together.
It is a convenient reminder if used on purpose, but causes confusion by
those who don't exactly know how it works. There are many people in the
MSP forum who think this 'stack size' setting will actually limit the stack.
>At best,
>you'd be able to detect at link time that your static data is too
>large, but you don't need linker support to do that (check the output
>of msp430-size).
Well, a linker error based on a project-specific setting is way better
than having to check the map file after each compiler run.
However, I auto-run msp430-ram-usage on the final elf file in my make
script, and it tells me 'stack can grow up to xxx bytes' right at the end
of the make output.
It's almost as convenient as a 'stack size' setting, less intrusive, and
you get a display even if you forget to change the default 'setting' :)
JMGross
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
