What is the default stack size for function calls?

Is there a way to inspect this or increase it?

I suspect I may be exceeding the stack for local variables.

A function that was working no longer works.

#define ARRAY_SIZE 4

void display()
{

char bigBuff[1024];

   for(int i=0; i < ARRAY_SIZE ; i++)
   {

    sprintf(bigBuff,"\n%11s %lu", var1,var2); // var1, var2 are globals
    Serial.print(bigBuff);

   }

}

I’m actually printing many more variables than what is above.
What is posted is for brevity.
I’ve tried making the char array larger too (4096)

}

char bigBuff[1024];

Which Arduino you are using? The ATmega328 only has 2K of RAM. That's a reasonable buffer if your program is doing nothing else...

[quote author=James C4S link=topic=82772.msg621662#msg621662 date=1323640421] char bigBuff[1024];

Which Arduino you are using? The ATmega328 only has 2K of RAM. That's a reasonable buffer if your program is doing nothing else... [/quote]

I'm using an Uno Rev2. My program has a lot of other code- which isn't display. Currently, the compiled code is just under 9k (which is much more than "only has 2K of RAM"), out of 32k,

I thought the compiled code goes in the "32k" part of ram.

Where can I find map of what code goes where? We can skip the 512 bytes of EEPROM for now. That's in a separate part of memory, and I'm not using it at the moment.

You are confused about the diferent types of memory used on the ATmega chip.

There are three memory spaces:

FLASH: 32k RAM: 2k EEPROM: 512bytes

Complied code is stored in FLASH (also known as Program Memory.)

Programs use SRAM when running. That's where variables go. You only have 2048 bytes of that available.

[quote author=James C4S link=topic=82772.msg621693#msg621693 date=1323642203] You are confused about the diferent types of memory used on the ATmega chip.

There are three memory spaces:

FLASH: 32k RAM: 2k EEPROM: 512bytes

Complied code is stored in FLASH (also known as Program Memory.)

Programs use SRAM when running. That's where variables go. You only have 2048 bytes of that available. [/quote]

Thanks. I've seen this info before, but forgot the details. So- does this mean the heap is in the 32k part of memory?

Damn the compiler for not telling us when we exceed that 2k.

Are there any inspection tools available to help diagnose this issue? Right now, my board seems to "reset itself" when I call certain functions.

This implies some kind of corruption.

When I changed the character array back to 128 bytes, my problem went away. I've also moved that char array into global space, because I may need it to be larger.

So- does this mean the heap is in the 32k part of memory? Nope, it consumes RAM too.

Damn the compiler for not telling us when we exceed that 2k. It can't tell what heap and stack your program will consume

Are there any inspection tools available to help diagnose this issue? There are a number of freemem functions implemented - mentioned often in the forums

Right now, my board seems to "reset itself" when I call certain functions. This implies some kind of corruption. Kind of, it means you ran out of memory and the heap and stack are damaging each other. Unpredictable things will result

When I changed the character array back to 128 bytes, my problem went away. I've also moved that char array into global space, because I may need it to be larger. Keep it on the stack - at least that way it's only consuming memory when that routine is called.

Damn the compiler for not telling us when we exceed that 2k.

Well, it can’t. Variables go in SRAM, and the compiler could tell you when you have more variables allocated than can fit. However, other stuff goes in SRAM, to, like the stack, where function call data is pushed when a function call is made. While the compiler can determine how much stack space is required for any given function, it can not determine the order that function calls will be made in, so it is impossible to predict the total stack space required at any given point in time.

Once a program starts running, PROGMEM can't be altered. So no, the heap isn't there.

The compiler can report the static data usage but it would only catch mistakes like making arrays too big. It cannot, however, calculate how much RAM the program will be using when it starts running. Only the programmer can do that.

http://www.arduino.cc/playground/Code/AvailableMemory

wildbill:
Nope, it consumes RAM too.

If the user allocates a very large local array, (or close to 2k worth of variables) the compiler should be able to catch this easily

There are a number of freemem functions implemented - mentioned often in the forums

I tried one of those- the include file can’t be found in Arduino 0023

Here's one I found somewhere here (Playground?):

// this function will return the number of bytes currently free in RAM      
extern int  __bss_end; 
extern int  *__brkval; 
int freemem()
{ 
 int free_memory; 
 if((int)__brkval == 0) 
   free_memory = ((int)&free_memory) - ((int)&__bss_end); 
 else 
   free_memory = ((int)&free_memory) - ((int)__brkval); 
 return free_memory; 
}

cappy2112: I tried one of those- the include file can't be found in Arduino 0023

You realize that the instructions are to create the include file?

[quote author=James C4S link=topic=82772.msg621737#msg621737 date=1323643901]

cappy2112: I tried one of those- the include file can't be found in Arduino 0023

You realize that the instructions are to create the include file? [/quote]

Not until I read this http://www.arduino.cc/playground/Code/AvailableMemory

The first post I had read about "stack size" didn't have the instructions.

wildbill: Here's one I found somewhere here (Playground?):

// this function will return the number of bytes currently free in RAM      
extern int  __bss_end; 
extern int  *__brkval; 
int freemem()
{ 
 int free_memory; 
 if((int)__brkval == 0) 
   free_memory = ((int)&free_memory) - ((int)&__bss_end); 
 else 
   free_memory = ((int)&free_memory) - ((int)__brkval); 
 return free_memory; 
}

Right- but this doesn't include the instructions on how to create the header. I've done that- and got it to compile

[quote author=James C4S link=topic=82772.msg621737#msg621737 date=1323643901]

cappy2112: I tried one of those- the include file can't be found in Arduino 0023

You realize that the instructions are to create the include file? [/quote]

In the function I suspect is having problems, the output from this

Serial.print("Freemem serviceUart: "); Serial.println(freeMemory(),DEC);

is --114

I have a fair amount of static strings in that function. It's a menu for the serial console.

That function tells you how much space there is left between the top of the stack and the bottom of the heap. If that's really -114, as I surmised earlier, your heap and stack are trying to use the same memory. Very bad things will result.

wildbill: That function tells you how much space there is left between the top of the stack and the bottom of the heap. If that's really -114, as I surmised earlier, your heap and stack are trying to use the same memory. Very bad things will result.

Yep- I kinda guessed that a negative value wouldn't be good ;-)

I've found the location of the .elf file, copied it to the directory where the avr tools are, and did an avr-objdump on the elf file.

I'm looking at the assembly + source listing now.

In general- is there a link for "Good Practices" for Arduino programming? When I started my project, I had everything laid out on paper- but didn't give much thought to the 2K ram limit.

I'm sure there are some sensible ways to cut back on my over-usage of that 2K memory. Thanks

Look at progmem - see what constant strings you can keep in flash until they're needed.

If you need buffers, make sure they're no bigger than needed - not 1024 just in case. This is rather old school compared to anything you might do on a PC these days ;)

Look at progmem - see what constant strings you can keep in flash until they're needed.

If you need buffers, make sure they're no bigger than needed - not 1024 just in case. This is rather old school compared to anything you might do on a PC these days ;)

wildbill: Look at progmem - see what constant strings you can keep in flash until they're needed.

If you need buffers, make sure they're no bigger than needed - not 1024 just in case. This is rather old school compared to anything you might do on a PC these days ;)

This is where I am now

avr-size myproject.cpp.elf text data bss dec hex filename 7240 598 380 8218 201a myproject.cpp.elf

freeMemory() is now reporting 898 in the function I suspect that has problems.

But that function calls Serial.print - and nothing is being displayed. I may still be short on SRAM space.

cappy2112: avr-size myproject.cpp.elf text data bss dec hex filename 7240 598 380 8218 201a myproject.cpp.elf

freeMemory() is now reporting 898 in the function I suspect that has problems.

But that function calls Serial.print - and nothing is being displayed. I may still be short on SRAM space. [/quote]

Ok- I'm getting 972 from freeMemory() now- looks like I'm back in business. My function is executing normally now. I'm seeing the output of Serial.print.

I did all the opti by hand, turned some functions into macros so that code will be inline, instead of on on the stack after another function call. I think I'll go thru and move some strings to progmem, to give me some extra room.

Thanks to everyone who replied (to all the threads)!