What's the logic behind GCC's low memory warning?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been testing a data-logging program on different Arduino boards, making the data array as large as possible before the compiler gives a warning. But I can make no sense of the results.

 

On the ATmega328:

Sketch uses 15,552 bytes (48%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,555 bytes (75%) of dynamic memory, leaving 493 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

On the ATmega32U4:

Sketch uses 18,132 bytes (63%) of program storage space. Maximum is 28,672 bytes.
Global variables use 1,959 bytes (76%) of dynamic memory, leaving 601 bytes for local variables. Maximum is 2,560 bytes.
Low memory available, stability problems may occur.

On the ATmega2560:

Sketch uses 15,970 bytes (6%) of program storage space. Maximum is 253,952 bytes.
Global variables use 6,196 bytes (75%) of dynamic memory, leaving 1,996 bytes for local variables. Maximum is 8,192 bytes.
Low memory available, stability problems may occur.

It seems to arbitrarily give a warning if less than 25% of the RAM is available for the stack. But why should a program need more stack/local variable space just because there's more RAM available?

 

Can I ignore this warning and allocate a fixed amount of stack space instead?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at your local variable use. If it is modest e.g. 4 ints and not recursive, you probably don't use more than 64 bytes of stack.
.
If you have big local arrays or structs, you can eat stack quite quickly.
I suspect that you have global buffers for your logging. In which case the SRAM report will calculate the space.
.
No one knows what a punter might do. Hence anything is "advisory".
.
You can use 99.999% of program space. Only you can assess your SRAM safety.
.
The GCC model does not allow you to set Stack space. Stack and Heap just have to keep their distance.
.
David.

Last Edited: Tue. May 10, 2016 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your reply. So essentially you agree that GCC's warning is meaningless?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) This is a warning from the Arduino IDE, not a warning from gcc.

 

It seems to arbitrarily give a warning if less than 25% of the RAM is available for the stack. But why should a program need more stack/local variable space just because there's more RAM available?

2) It's guessing that the fact that you have more global variables (reported at compile time) probably means that you have more local variables and program complexity (stack and heap memory consumed at runtime) as well.   That's not unreasonable, IMO.  If you know differently ("it's the same program but I'm allocating a bigger buffer because there is more total RAM."), you can go ahead and ignore the warning.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

johnsondavies wrote:

Thank you for your reply. So essentially you agree that GCC's warning is meaningless?

Yes, pretty much.  Just going to a chip with more RAM doesn't mean you need more space for the stack.

 

Your program can determine what the maximum stack size has been after running a while.

 

At main, you can write a pattern in the heap memory from the beginning of the heap to the bottom of the stack.  With my avr-gcc, the heap starts at the address of __heap_start.

 

extern char __heap_start;

 

The bottom of the stack can be gotten by creating a local object and taking it's address.

 

After running for a while, you can examine the heap by going through it and seeing where the pattern has been overwritten by the stack.

 

I always do that, and I can look at it any time on my PC.  I do allocate memory from the heap.

 

Last Edited: Tue. May 10, 2016 - 10:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
1) This is a warning from the Arduino IDE, not a warning from gcc.

+1

 

The only tool in the "gcc" package that might give you any information about your RAM limits is avr-size and even that is not part of "gcc" as such. It is a component of avr-binultils. The GCC tools themselves are just the compiler and the linker (in fact even avr-ld is a binutil!) and while they will build the code and I guess the .map file generated (optionally) by the linker may give you some information about the layout of symbols in memory it is the responsibility of the programmer, not the build tools to know when they may be approaching any boundaries or limits on size or whatever.

 

It's true that an "improvement" was made to avr-size at one stage to add the -C option which then attempts to give % used figures based on the selected device but this is not part of the mainstream development and because it required a knowledge of all the AVR devices and their sizes it ceased to be maintained some time ago.

 

Both Atmel in Studio 5/6/7 and Arduino in the above have attempted to add functionality to their "compiler wrappers" to perform some analysis on the .map/avr-size/avr-nm information but it's just a static analysis (in the case of RAM) of the fixed size of .data and .bss. It does not try to analyze the run time operation of the code and its potential use of "heap" (malloc/free) or stack frame automatics.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Search for ezstack.c by fellow Freak ezharkov. Not perfect, but quite handy, and growing all the time.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the replies/suggestions.