Go Down

Topic: Memory creep any suggestions? (Read 1 time) previous topic - next topic


I know my listing is a mess but it is work in progress.
It is yet another weather monitor with a simple web printout of current status, with averaging function on all readings,  saved to SD card with time stamp.

I seem to be suffering memory creep thus my program and data is crashing into each other. how can I reduce the overheads? I noticed that Long's and floats use 4 bytes each. I could use strings more but not sure if this would save much? (or even how!)
Yours Simon M.


I seem to be suffering memory creep thus my program and data is crashing into each other.

What ever else is happening this is not. This is because the processor has Harvard architecture where data space and program space are separate.


As mike said, you are not colliding data and code, however you could be running out of memory or getting fragmented to the point where it fails.  Using Strings extensively can lead to that sometimes.  To test for out of memory conditions just include:

#include <MemoryFree.h>

and then print it so you can check what's going on.


You can sprinkle these prints around to see what code does what and so forth. 

You need about 200 bytes free to allow for subroutine calls, temporary variables and such so check accordingly.


I have used the #include <MemoryFree.h> 'utility' and indeed when I go below 240 ish it dies. Why does is number go down over time? is the SP overflowing? I do expect the amount to drop through the program execution, but I can't understand why on each loop it gets less & less?  I do use arrays for averaging but these are reused on each full loop through. I might resort to storing raw data and calculate the other stuff when called.
Will clearing the arrays save memory, or will filling the arrays at boot to their max stop fragmentation?

Yours Simon M.


Having variable(s) go out of scope should free them but for the next use is whether or not there is a big enough continuous space to allocate for the next new need.

I'm new to this but it appears that println() assembles the string to be printed in RAM. Does that de-allocate when the string is printed? Oh no, it's worse than I thought:
(Note: string literals take up room in the Flash (program) memory AND the RAM. When the program starts, the strings are copied from Flash to RAM.)

To say the least, there is room for improvement. Hmmm, it's already been seen to:
Third, if you have a lot of strings that you absolutely need, or large arrays of data that do not change, then use the PROGMEM directive. This is a way of telling the Arduino to put data into Flash (program) memory only, without copying it into RAM. This technique is useful if you have a lot of data that does not change, and still have Flash (program) memory available.

The quotes are from an excellent article by Gian Pablo, Making the most of Arduino memory:

Long ago I remember when VM was taught as used to make 1k of RAM seem like 16k. Don't laugh (so okay I did!), that was back in the day when the dinosaurs ruled and school texts still taught decade-old techniques.
Perhaps a VM library to be used alongside the SD library?
Nick Gammon on multitasking Arduinos:
1) http://gammon.com.au/blink
2) http://gammon.com.au/serial
3) http://gammon.com.au/interrupts


Without a memory fault exception, implementing VM is going to be tricky.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.


I seem to be suffering memory creep

Do you mean you consume a bit more memory after ever loop?

If so one way to find out what is happening is to simplify your program bit by bit. For example take out averageing() and see if THAT gives you memory creep problems. Then take out webServer() and see if THAT gives you problems.

Do this on a copy of your program so that when you find the culprit you can correct it in your original.

It may be neither, but it would be good to eliminate them.

Go Up