"Low memory available, stability problems may occur."

Projects Programming
1

My sketch reads data from 2 DS18b20s, a DHT 11, and a DS3231 rtc, then logs the data, and displays an LCD.

The most recent compilations are acting a little strange, however…sometimes the serial data gets corrupted, sometimes it quits after just a few iterations, and sometimes it works ok for a while, but reports an error opening the datalog.

I had this circuit working nicely, before trying to add the rtc module...I am wondering if this is just because I am running low on memory:

"Sketch uses 23,956 bytes (74%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,652 bytes (80%) of dynamic memory, leaving 396 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur."

Are the errors I am experiencing typical, of low memory conditions?
Would switching the project to a Mega enable me to work around this difficulty?

2

Actually, the sketch memory is less than 32K because of the bootloader. Still, my guess is that it is SRAM that's the major problem. Keep in mind that string literals are duplicated in SRAM. Try using the F() macro to move the string literals from SRAM in flash memory and see if that helps. That is, instead of:

Serial.print("Write something on  the Serial Monitor");

try framing it with the F() marco:

Serial.print(F("Write something on the Serial Monitor that is stored in FLASH"));

and see if the problem persists.

3

Whoa…I'm going to have to learn about the macro, first…Thanks.

4

Yup - you can use F() for any place where you're print()ing or println()ing.

Those are definitely the sort of symptoms I'd expect if you were running out of memory. I suspect you're also throwing around the String class, which behaves horribly in low memory situations.

5

charlestonchu:
Would switching the project to a Mega enable me to work around this difficulty?

While a Mega is commonly used for datalogging projects, what you are doing should fit in a Uno OK. A sketch using 23900 should not cause problems and, as remarked elsewhere, using strings is probably the cause of all your problems. In that event, moving to a Mega may simply be putting off the inevitable. As it is, I bet there is no need to use strings, there hardly ever is. For the DS18B20s, just read the floats and print them. I imagine the DHT is the same.

6

I ran in the same problems, on a Mega2560.

I have a pretty big sketch, about 60kB program space.
Just by adding F() to all serial.prints, the global variables dropped from 76% to 57%.

7

I have the same problem. After the rtc module DS3231 is added and the following code is added in my sketch.

Serial.print(rtc.getDOWStr());

The error "Low memory available, stability problems may occur." is shown after compiling.

I have tried to add F() to the print as follows.

Serial.print(F(rtc.getDOWStr()));

It prompts the following errors. What should I do to deal with this error? Thanks.

error: initializer fails to determine size of '__c'
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

^

note: in expansion of macro 'F'

Serial.print(F(rtc.getDOWStr()));

^

error: array must be initialized with a brace-enclosed initializer

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

8

F() works when you wrap it around a constant string. Like a menu item or other human-readable sentence. F("This is a string because it has quotes around it.")

You can't wrap it around variables and function calls. That makes no sense to the compiler.

9

So to avoid the low memory warning, I can only use F and the constant declaration method stated in the following url to store constant?

Thanks.

10

hgchcw:
So to avoid the low memory warning, I can only use F and the constant declaration method stated in the following url to store constant?

PROGMEM - Arduino Reference

Thanks.

Yeah - put constants into PROGMEM and access them as described on that page. You can use F() macro for strings that you're printing - though if you need to do more sophisticated things than just printing them, you may have to use the more awkward methods described in PROGMEM - Arduino Reference (see also the relevant avr-libc documentation: avr-libc: Data in Program Space avr-libc: <avr/pgmspace.h>: Program Space Utilities )

(an aside - it takes 2 or 4 extra bytes of flash to put a string in the F() macro. I have been in a situation where I was removing F() macros to make my program fit in flash - I had enough RAM to spare, but had filled the flash)

11

F macro works like a charm. I ran into this message -- 77% of memory used -- and just by introducing F macro into all of my Serial.print and Serial.println statements involving literals, it instantly went down to 55%, warning went away. The repetitive editing forced me to refresh my memory of vim macro recording :slight_smile: a beneficial side effect.