ram = variable space ?

hello,

i am currently writing a sketch on a duemilanove, which is getting fairly large and stands at 14300 bytes.

it is behaving strangely after i added some lines of code. after experimenting a bit I found no apparent bugs. I reduced the variable sizes (arrays, length of strings etc) and then it went allright again. I therefore suspect that I am reaching the end of the variable space.

is there any way to check how much variable space is being used ? can one see warnings ?

how is the compiler policy - does it make a difference to allocate variables at runtime in subroutines rather than globally (as it is now) ?

thx

s

You don't say which processor you're using - I'm guessing a 168 - but variables are held in RAM (1K), whilst code is held in flash, of which there is 16K, less 2K for the bootloader.
The amount of code doesn't necessarily reflect on the amount of RAM used.
The two spaces are entirely separate.

sorry, of course,

ATMega 328, which should be 2k RAM

again, the code seems to be working per se, I use fairly large arays to store data, which in the absence of new() I create as globals in the beg. if I reduce the array size, things work properly. i would like to understand whether i can see the variable space usage at compilation time & whether it makes sense to create the variables at runtime. if for example a string constant is created during compilation time, does it also use up variable space or data space ?

thx

s

freeMemory from here…

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1213583720/19#19

…seems to work well. The one caveat is that the stack and data are both in SRAM. Ideally, freeMemory should called from the deepest stack level which is sometimes difficult to determine.

if for example a string constant is created during compilation time, does it also use up variable space or data space ?

Yes. PROGMEM can be helpful to reduce the amount of SRAM used for constants.

thank you - sarting to make myself familiar with PROGMEM now.

or should I rather wait for the ATMEGA648 ?

s