Arduino Speicher voll? RAM sparen mit PROGMEM, F() und den richtigen Datentypen

Drei Speicher, die ständig verwechselt werden

Ein Nano V3 oder UNO R3 hat nicht „einen“ Speicher, sondern drei völlig verschiedene – mit stark unterschiedlicher Größe:

Der Engpass ist praktisch immer das SRAM. 2048 Bytes – das sind zwei einzelne Textzeilen im Browser. Und davon gehen schon vor deiner ersten Zeile Code rund 200 Bytes für die serielle Schnittstelle drauf.

Das brauchst du

Für die Beispiele reicht ein Board und ein Display – der Rest ist reine Software.

1Testaufbau verkabeln

Der Aufbau ist bewusst „zu groß“ für einen Nano – genau darum geht es:

2Erst messen, dann optimieren

Bevor du irgendetwas änderst, brauchst du eine Zahl. Der Compiler liefert die eine Hälfte, der laufende Sketch die andere. Diese Funktion berechnet den Abstand zwischen Heap-Ende und Stack-Spitze – also den tatsächlich freien SRAM:

// Funktioniert auf allen AVR-Boards (UNO, Nano, Mega, Pro Mini)
#ifdef __AVR__
extern unsigned int __heap_start;
extern void *__brkval;

int freierSpeicher() {
  int frei;
  // Adresse einer lokalen Variablen = aktuelle Stack-Spitze
  return (int) &frei - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
#else
// ESP32 / ESP8266 bringen das selbst mit
int freierSpeicher() { return ESP.getFreeHeap(); }
#endif

void zeigeSpeicher(const __FlashStringHelper *wo) {
  Serial.print(wo);
  Serial.print(F(": "));
  Serial.print(freierSpeicher());
  Serial.println(F(" Bytes frei"));
}

void setup() {
  Serial.begin(115200);
  delay(200);

  zeigeSpeicher(F("nach setup-Start"));

  // ... deine Initialisierungen ...

  zeigeSpeicher(F("nach Init"));
}

void loop() {
  static unsigned long letzte = 0;
  if (millis() - letzte >= 5000) {
    letzte = millis();
    zeigeSpeicher(F("loop"));   // muss konstant bleiben!
  }

  // ... dein Code ...
}

Und so liest du die Compiler-Ausgabe richtig:

Der Sketch verwendet 24518 Bytes (79%) des Programmspeicherplatzes.
Globale Variablen verwenden 1743 Bytes (85%) des dynamischen Speichers,
verbleiben 305 Bytes fuer lokale Variablen. Maximum sind 2048 Bytes.

• 79 % Flash – völlig unkritisch, bis 95 % ist alles in Ordnung.
• 85 % SRAM – kritisch. Ab 75 % solltest du handeln, ab 85 % wird es unzuverlässig.
• 305 Bytes verbleibend – davon geht der Stack ab. Jede verschachtelte Funktion, jedes float-Argument, jeder lokale Puffer knabbert daran.

3Textkonstanten ins Flash: F() und PROGMEM

Das ist der mit Abstand größte Hebel. Jeder Text in Anführungszeichen wird beim Start vom Flash ins SRAM kopiert – auch wenn er sich nie ändert. Ein Sketch mit 30 Debug-Ausgaben à 25 Zeichen verbrennt so 750 Bytes, über ein Drittel des gesamten Arbeitsspeichers.

// ---------- SCHLECHT: 84 Bytes SRAM fuer reinen Text ----------
void setupSchlecht() {
  Serial.begin(115200);
  Serial.println("Wetterstation v2.1 startet");   // 27 Bytes SRAM
  Serial.println("Sensoren werden geprueft...");  // 28 Bytes SRAM
  Serial.println("Bereit. Warte auf Messwerte."); // 29 Bytes SRAM
}

// ---------- GUT: 0 Bytes SRAM, Text bleibt im Flash ----------
void setupGut() {
  Serial.begin(115200);
  Serial.println(F("Wetterstation v2.1 startet"));
  Serial.println(F("Sensoren werden geprueft..."));
  Serial.println(F("Bereit. Warte auf Messwerte."));
}

Das F()-Makro sagt dem Compiler: „Lass diesen Text im Flash und lies ihn Byte für Byte aus, wenn er gebraucht wird.“ Es kostet ein paar Mikrosekunden pro Ausgabe – und spart dir jedes einzelne Byte.

Bei Arrays von Texten – Menüeinträgen, Fehlermeldungen, Wochentagen – reicht F() nicht. Hier brauchst du PROGMEM mit einer Indirektion:

#include <avr/pgmspace.h>

// Jeder Text einzeln ins Flash
const char txt0[] PROGMEM = "Temperatur";
const char txt1[] PROGMEM = "Luftfeuchte";
const char txt2[] PROGMEM = "Luftdruck";
const char txt3[] PROGMEM = "Bodenfeuchte";
const char txt4[] PROGMEM = "Helligkeit";
const char txt5[] PROGMEM = "Einstellungen";

// Und die Tabelle der Zeiger ebenfalls
const char *const MENUE[] PROGMEM = { txt0, txt1, txt2, txt3, txt4, txt5 };
const uint8_t MENUE_ANZAHL = 6;

char puffer[16];   // ein einziger Arbeitspuffer fuer alle Eintraege

const char *menueText(uint8_t index) {
  if (index >= MENUE_ANZAHL) return "";
  strcpy_P(puffer, (char *) pgm_read_word(&MENUE[index]));
  return puffer;
}

void zeigeMenue(uint8_t auswahl) {
  for (uint8_t i = 0; i < MENUE_ANZAHL; i++) {
    Serial.print(i == auswahl ? F("> ") : F("  "));
    Serial.println(menueText(i));
  }
}

Zahlentabellen – Kalibrierkurven, Kennlinien, Tonleitern – funktionieren nach demselben Prinzip:

// Kennlinie eines NTC: 31 Stuetzstellen von -20 bis 100 Grad
const uint16_t NTC_TABELLE[] PROGMEM = {
  929, 895, 858, 817, 774, 728, 681, 632, 583, 535,
  487, 442, 398, 358, 320, 285, 253, 224, 198, 174,
  153, 135, 118, 104,  91,  80,  70,  62,  54,  48, 42
};

float temperaturAusADC(uint16_t adc) {
  // Tabelle ist absteigend sortiert -> passende Stuetzstelle suchen
  for (uint8_t i = 0; i < 30; i++) {
    uint16_t oben  = pgm_read_word(&NTC_TABELLE[i]);
    uint16_t unten = pgm_read_word(&NTC_TABELLE[i + 1]);

    if (adc <= oben && adc >= unten) {
      float anteil = (float)(oben - adc) / (float)(oben - unten);
      return -20.0 + (i + anteil) * 4.0;   // 4 Grad pro Stuetzstelle
    }
  }
  return NAN;   // ausserhalb des Messbereichs
}

62 Bytes, die sonst dauerhaft im SRAM lägen, liegen jetzt im Flash – wo ohnehin 20 % frei sind.

4Die String-Klasse: bequem, teuer, gefährlich

Die String-Klasse von Arduino ist der zweitgrößte Speicherfresser – und der einzige, der deinen Sketch nach Stunden abstürzen lässt statt sofort. Der Grund heißt Heap-Fragmentierung.

Jedes + auf einem String legt einen neuen Speicherblock an, kopiert um und gibt den alten frei. Nach ein paar tausend Durchläufen ist der Heap ein Schweizer Käse: In Summe wären 400 Bytes frei, aber kein einziger zusammenhängender Block von 60 Bytes. Die nächste Zuweisung schlägt fehl – und der Sketch hängt.

// ---------- SCHLECHT: fragmentiert den Heap bei jedem Durchlauf ----------
void sendeSchlecht(float temp, float feuchte, int boden) {
  String zeile = "";
  zeile += millis();
  zeile += ",";
  zeile += String(temp, 2);
  zeile += ",";
  zeile += String(feuchte, 2);
  zeile += ",";
  zeile += boden;
  Serial.println(zeile);
}

// ---------- GUT: fester Puffer, null Heap-Nutzung ----------
void sendeGut(float temp, float feuchte, int boden) {
  char zeile[48];
  char sTemp[8], sFeucht[8];

  // AVR kann kein %f in printf -> dtostrf benutzen
  dtostrf(temp,    4, 2, sTemp);
  dtostrf(feuchte, 4, 2, sFeucht);

  snprintf(zeile, sizeof(zeile), "%lu,%s,%s,%d",
           millis(), sTemp, sFeucht, boden);

  Serial.println(zeile);
}

// ---------- NOCH BESSER: gar kein Puffer noetig ----------
void sendeAmBesten(float temp, float feuchte, int boden) {
  Serial.print(millis());   Serial.print(',');
  Serial.print(temp, 2);    Serial.print(',');
  Serial.print(feuchte, 2); Serial.print(',');
  Serial.println(boden);
}

5Datentypen: das billigste Kilo Speicher der Welt

int ist auf dem AVR 2 Bytes, long 4, float ebenfalls 4. Wer Zählvariablen von 0 bis 20 als int deklariert, verschenkt pro Variable ein Byte. Klingt lächerlich – bei 50 Variablen und einem Array sind es plötzlich 200.

Der größte Einzelgewinn liegt meist in Messwert-Arrays. Ein Ringpuffer für 60 Temperaturmessungen als float kostet 240 Bytes – über 10 % des gesamten SRAM. In Zehntelgrad als int16_t sind es 120 Bytes bei identischer Sensorgenauigkeit:

// ---------- SCHLECHT: 240 Bytes ----------
// float verlauf[60];

// ---------- GUT: 120 Bytes, gleiche Aussagekraft ----------
// Temperatur in Zehntelgrad: 23.4 C -> 234
const uint8_t N = 60;
int16_t verlauf[N];
uint8_t schreibIndex = 0;

void speichere(float tempCelsius) {
  verlauf[schreibIndex] = (int16_t) round(tempCelsius * 10.0);
  schreibIndex = (schreibIndex + 1) % N;
}

float leseCelsius(uint8_t i) {
  return verlauf[i] / 10.0;
}

// Mittelwert ohne float-Zwischenrechnung
int16_t mittelwert() {
  int32_t summe = 0;
  for (uint8_t i = 0; i < N; i++) summe += verlauf[i];
  return (int16_t)(summe / N);
}

Und wenn du viele Ja-Nein-Zustände hast, packe sie in Bitfelder statt in einzelne bool-Variablen:

// ---------- SCHLECHT: 8 Bytes ----------
// bool pumpeAn, lichtAn, luefterAn, alarmAktiv;
// bool wlanVerbunden, sdBereit, sensorOk, nachtModus;

// ---------- GUT: 1 Byte fuer alle acht ----------
struct Zustand {
  uint8_t pumpeAn       : 1;
  uint8_t lichtAn       : 1;
  uint8_t luefterAn     : 1;
  uint8_t alarmAktiv    : 1;
  uint8_t wlanVerbunden : 1;
  uint8_t sdBereit      : 1;
  uint8_t sensorOk      : 1;
  uint8_t nachtModus    : 1;
};

Zustand z = {0};

void pruefeZustand() {
  if (!z.sensorOk) return;

  if (z.nachtModus && z.lichtAn) {
    z.lichtAn = 0;
    digitalWrite(LICHT_PIN, LOW);
  }
}

6Bibliotheken: der unsichtbare Verbrauch

Die größten Brocken kommen oft gar nicht aus deinem Code. Der Framebuffer der Adafruit-GFX-Bibliothek für ein 128x64 OLED belegt 1024 Bytes – die Hälfte des gesamten SRAM eines Nano, bevor du eine einzige Zeile geschrieben hast.

// Vorher: 1024 Bytes Framebuffer
#include <Adafruit_SSD1306.h>
Adafruit_SSD1306 display(128, 64, &Wire, -1);

void zeigeAlt(float temp, float feuchte) {
  display.clearDisplay();
  display.setCursor(0, 0);
  display.print(F("Temp:  "));
  display.println(temp, 1);
  display.print(F("Feucht:"));
  display.println(feuchte, 1);
  display.display();          // schiebt 1 KB ueber I2C
}

// Nachher: ca. 40 Bytes, kein Framebuffer
#include <U8x8lib.h>
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(U8X8_PIN_NONE);

void setupNeu() {
  u8x8.begin();
  u8x8.setFont(u8x8_font_chroma48medium8_r);
}

void zeigeNeu(float temp, float feuchte) {
  char zeile[17];
  char wert[8];

  dtostrf(temp, 4, 1, wert);
  snprintf(zeile, sizeof(zeile), "Temp:   %s C", wert);
  u8x8.drawString(0, 0, zeile);

  dtostrf(feuchte, 4, 1, wert);
  snprintf(zeile, sizeof(zeile), "Feuchte:%s %%", wert);
  u8x8.drawString(0, 2, zeile);
}

7Praxisbeispiel: von 85 % auf 46 %

Eine typische Wetterstation auf dem Nano: DHT22, OLED, 60-Werte-Verlauf, ein paar Debug-Ausgaben. Vorher 1743 Bytes SRAM (85 %). Nach den Schritten oben:

Der Sketch kann jetzt eine SD-Karte dazubekommen, ohne dass irgendetwas kippt.

Troubleshooting

Praxistipps

• Miss zuerst, optimiere danach. Ohne freierSpeicher() optimierst du blind und opferst womöglich Lesbarkeit an Stellen, die gar nichts kosten.
• F() von Anfang an benutzen. Es ist genauso schnell zu tippen wie ohne und erspart dir den späteren Umbau komplett.
• Ein Puffer für alle. Statt in jeder Funktion ein eigenes char[32] anzulegen, nimm einen globalen Arbeitspuffer. Der Stack dankt es dir.
• Ganzzahlen statt Fließkomma, wo es geht. Millivolt statt Volt, Zehntelgrad statt Grad, Millimeter statt Zentimeter. Spart RAM, Flash und Rechenzeit gleichzeitig.
• Wenn du zwei Stunden optimierst, um 200 Bytes zu sparen – nimm ein größeres Board. Ein ESP32-C3 Mini kostet wenig und hat den 200-fachen Arbeitsspeicher. Optimieren lohnt sich, wenn das Board feststeht – nicht als Selbstzweck.
• Konstanten mit const deklarieren. const uint8_t LED_PIN = 13; landet im Flash, uint8_t LED_PIN = 13; im SRAM. Ein Wort, ein Byte gespart – und der Compiler warnt bei versehentlichen Änderungen.
• Einstellungen ins EEPROM statt in RAM-Kopien. Wie das sauber geht, zeigt der Artikel Arduino EEPROM & ESP32 Preferences.