Controller Projects

I didn’t realize, until I needed to optimize my code because I was out of RAM, that doing a Serial.print(“this text is in quotes, not a variable, however it takes RAM to store it at runtime”); will load that string into RAM at runtime.

I’ve seen a post about using PROGMEM to optimize your code in regards to things like this, where it uses the program memory (flash memory) rather than RAM to store the variable, but I stumbled across an easier way to handle it in the scenario of doing a Serial.print(“things in quotes);

According to what I read on http://jeelabs.org/2011/05/23/saving-ram-space/

The trick is to place these strings in flash memory, alongside the code, and extract the characters of the string whenever we need them. It’s a great trick, but it will affect our sketch everywhere, unfortunately.

First of all, we need to include this line at the top of our sketch:

    #include <avr/pgmspace.h>

This header file gives access to a number of preprocessor macros and functions, needed to define strings in the proper way, and to read the character data from flash memory at run time.

The reason for this added complexity, is that flash memory isn’t simply an “address” you can read out. The AVR family uses two separate address spaces for code and data. This is called a Harvard architecture. As far as pointers go in C, there is no access to data in flash memory. Well – there is, because function pointers in C automatically refer to code in flash memory, but there is no way to mix these: data pointers cannot access flash, and function pointers cannot refer to RAM.

So if you add the following function:

    void showString (PGM_P s) {
        char c;
        while ((c = pgm_read_byte(s++)) != 0)
            Serial.print(c);
    }

You can call that function with showString(PSTR(“String goes in here”)); and it will do a Serial.print(“String goes in here”) without eating up ANY additional RAM.

If you need to do the equivalent of Serial.println(“This is one line”); you can do that with showString(PSTR(“This is one line\r\n”)); and the “\r\n” does a carriage-return.

Unfortunately, I don’t know how (if it’s even possible) to use this construct to avoid using as much ram when dealing with Serial.print() of variables.

Doing a project, I ran into a limitation where I believed that I was using up all 2k of RAM on my Arduino (ATMega328).  I stumbled across a post on http://jeelabs.org/2011/05/22/atmega-memory-use/ that gave me what I needed to diagnose that scenario.

The only symptom I had was intermittent jumbled text (with ascii characters mixed in) for my Serial.print() commands and the fact that it would intermittently lock up and/or reboot.

The Arduino IDE shows at compile time how much flash it is using, but it unfortunately doesn’t give any indication for RAM.

As stated on the JeeLabs site:

There are three areas in RAM:

• static data, i.e. global variables and arrays … and strings !
• the “heap”, which gets used if you call malloc() and free()
• the “stack”, which is what gets consumed as one function calls another

The heap grows up, and is used in a fairly unpredictable manner. If you release areas, then they will be lead to unused gaps in the heap, which get re-used by new calls to malloc() if the requested block fits in those gaps.

At any point in time, there is a highest point in RAM occupied by the heap. This value can be found in a system variable called __brkval.

The stack is located at the end of RAM, and expands and contracts down towards the heap area. Stack space gets allocated and released as needed by functions calling other functions. That’s where local variables get stored.

The trick is to keep RAM usage low, because it’s a scarce resource: an ATmega has a mere 2048 bytes of RAM.

So, to use those variables and concepts to show RAM usage, you can utilize the following function:

int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

Just call it, not passing any parameters, and it will return the remaining bytes of ram.

i.e.:  Serial.println(freeRam());

I ended up (at one point) showing that freeRam() returned 64 then very shortly afterwards the arduino rebooted.  That’s a smoking gun that it’s a RAM issue.  Time to do some code optimization