Memory evaluation

Dear all,

I have been working on a project with an Arduino Mega board coupled to a UTFT display shell and several different sensors. The scketch is quite long with around 3500 lines. Apparently there is no logic problem and the system works well and according to the information from IDE it is occupying 34% of program storage space and 59% of dynamic memory. No memory problem warning appears.
However, when I try to implement anything else in the system even if it occupies only 2 or 3% more in the dynamic memory, the system presents characteristic flaws of lack of memory, failing to function fully. My question is whether I can do a specific and direct test if I am really working on the memory limit. Is there any way to check this objectively and quantitatively?

Thanks for your help...

Well, there are, but they almost always use more memory…

Remember, the compiler/linker only reports static memory allocation - libraries for displays may well have a mix of static and dynamic allocation, particularly for frame buffers.

Does your code use String variables?

Do you use the F() macro when printing constant text?

Do you use the smallest variable type for things like pin numbers and other small values?

Does your code use functions that have to be passed many bytes of args?

Do your functions make many nested function calls?

3500 lines. I am guessing that it could be shorter.

In my code I have a function that displays the free memory, it has saved me many times. It can be found on line in many different web sites. Another trick is to use local variables as much as possible. Example in function define your variables. You do not have to initialize them. Int x = 0; do your thing and then the statement return x; x will only exist in your function and not wast RAM space.

Answering the questions;

  • My code does not contain String variables
  • My code uses F () macro when necessary the few times it needs Print
  • The code use byte only one time
  • No nested functions
  • PROGMEM where possible

In fact, without these features it would never work with the Arduino Mega board. I would like to better understand the issue of memory distribution. I understand that this can be complicated in a situation like this, but if there is any way to measure the allocation of memory in real time during the activity of the system I would like to know. I can test pieces of the program within an available range of memory. I'm sure my code can be reduced but I don't think it will change the memory situation much.

Hi gilshultz, can you give me a link of your code?

Thank you for the help...

Using byte or char instead of int will save memory in cases where you only need numbers to range 0 to 255 or -128 to +127. For example in most for loops it is natural to write int i = all the time when often byte will do.
https://www.arduino.cc/en/Reference/VariableDeclaration

Also the use of arrays and for loops, instead of lots of near identical lines over and over saves memory.

Rugged Circuits sold out of the Quadram card but maybe they'll make more.

You can have an 8K dedicated stack space and 8 banks of 56K heaps.

Just knowing that the Mega can support directly addressable external RAM, you might find some other board.

Are you doing anything that uses dynamic memory allocation?

Even if it’s not allocating and reallocating memory, this makes it hard to realize you’re close to the limit, as dynamically allocated memory isn’t included in the estimate of memory usage.

Are you allocating any huge local variables or anything? Big arrays, etc? Because if you’re actually running into memory problems, that would imply that somehow a lot of memory that isn’t counted in the ram usage report is getting used…

My first suggestion would be to link to your code somewhere (pref. github) or attach it - and maybe list the libraries if you’re not aware of any using dynamic memory allocation, so we could point out any that do.

Another thing to, of course, consider, is whether maybe it’s not memory, and just some other sort of bug…

DrAzzy,
I'm not sure I understand what you say about using dynamic memory. Dynamic memory is not what is indicated in the IDE? Is the indication of dynamic memory allocated not accurate? Does it change according to system activity?

Thank you all for the cool collaboration. I will process all these informations.

Dynamic memory allocation, no matter how good will "shotgun" your heap, making it bigger and closer to crashing the stack.

That's okay on a PC with loads of RAM but an Uno has 2048 bytes for both heap and stack.
Want to guess how often a forum thread has been about running out of RAM needlessly?

Thank you all for the informations.
I will work with them and eventually surround my problem more objectively.

Do you understand what dynamic memory allocation is?

"Dynamic memory" is the chip SRAM (static ram which btw is not dynamic RAM, DRAM that needs constant refreshing).

Why they didn't just call it memory or RAM I don't know but it reads like they borrowed familiar terms from PC tech.

Dynamic allocation is when you create new data objects (variables, arrays, structs, class objects) then delete them which is SOP for String and all other C++ Container Class objects. Practically all the PC code I've seen that "leaked RAM" was due to dynamic allocation not working as expected. This was a staple of many Winblows apps. (Some day Micro$oft will make a product that doesn't suck. That will be the day they make vacuum cleaners.)

41% of a Mega's RAM is over 3K. It is HARD to imagine that much RAM going poof so quickly. You may have noticed "characteristic flaws of lack of memory, failing to function fully" but the real definite used-too-much-RAM flaw is crash and restart.

3500 lines on a Mega, sorry but I wouldn't do more than skim through looking for obvious things to fix.

Is the indication of dynamic memory allocated not accurate?

Not only is it not accurate it is actually none existent. The compiler does not know about any memory the code will allocate.

For example say you are running a lot of addressable LEDs, the code has to allocate memory for it to the tune of 3 bytes per LED, the compiler can not know the code will do this and so does not make any mention of it in the end of compilation report.

https://playground.arduino.cc/Code/AvailableMemory/

With a little bit of searching....... and remembering that this used to be a recurring topic, violins!