I'm running IDE v1.8.8, and for the ATMega328P it compiles ok, but warns about instability when I use more than 75% of RAM. I know there's other stuff the IDE adds on top of my code, like the millis() interrupt and Serial.print stuff, but is there any way to pin this down a bit? All my variables are global, but does the compilation process produce any information about local variable usage by the code I can't see? I assume the 75% is a rule of thumb, but is there any way to pin down how little RAM I need to leave unused by my code?
If it matters, the code is an IR remote raw capture sketch, and I'd like to be able to capture as many transitions as possible to cover those oddball remotes that send an extended stream. At the moment I'm up to 650 unsigned integers without getting the warning, but would like to provide for more if I can.
650 integers take up 1300 bytes out of 2048, or about 63%
Given that an empty arduino sketch takes up about 300-400 bytes. It's unlikely that you'll be able to increase your data buffer by any amount.
In general, the atmega328 controller is very old. There are now many new, arduino-compatible options that have tens and even hundreds of times more available memory than it.
The 75% is an arbitrary limit.
But if you use screens (and other libraries) that allocate large buffers during runtime, you will easily run out if ram.
If you really have globals only, your program may run stable above 75%...
Agree with @b707 that it is not really worthwhile to spend days on reducing ram memory. Better boards are often cheaper than arduino R3.
what is the range of these integers? 0..65535 or e.g. only 0..1023?
If the values are e.g. 10 bits (think analogRead) long, have a look at this library.
It uses less bits per element and can store 1600 -10 bits ints into a 1000 bytes.
(plus some admin overhead).
These are periods of carrier on or off produced by an IR remote control. They are routinely above 1023, but also up into the 40000 range on a repeat.
Well, thanks for everyone's comments. This is code that I'm making available to others on Github, so I want to stick with the 328P, at least for now. I think I will honor the rule of thumb.
you might use scaling to reduce the range.
If all values are (roughly) multiples of 256, you could just divide all measurements by 256. Would save 8 bits per value.
Another trick is clustering, e.g if there are effectively only 100 clusters of approx. equal values, you could create a lookup table and use just one byte per value(+100for lookuptable)