Programm Speicher gezielt voll machen. ( Speicher-Testung)

[Megaquaeler]

Hallo
Wie kann ich gezielt DATENMÜLL erzeugen?

Genauer gesagt einen Code basteln der einfach in der Größe veränderbar ist zb von 0,5 KB bis hin zu 4 MB.

Der Code soll/Brauch keine Funktion zu haben es geht mir einzig und alleine um den Speicher Test.
Soll heisen code hochladen und wieder auslesen um zusehen ob der Speicher noch ok ist.

Jemand eine Idee dazu ?

Bis jetzt habe ich das immer so gemacht das ich mir irgendein Beispiel gesucht habe zum Beispiel eins von den neopixeln und da Funktionen gebastelt habe die nie aufgerufen werden.

Problem ist da aber ich kann die Größe nicht so gut einteilen.
Und mit fortschreitender Intelligenz in den Bibliotheken macht mir LTO (Oft nicht mehr abwählbar) immer öfter zusätzlich Probleme.

VIELEN DANK.

[my_xy_projekt]

Was hindert Dich daran ein Array zu definieren?

[Megaquaeler]

Das es so wie ich das verstanden habe eine maximale Größe gibt.

[combie]

Eigentlich dachte ich, ich kenne mich einigermaßen mit Arduinos aus,
Auch mit Speicher und Speichertests.

Aber was du da von dir gegeben hast hört sich für mich an wie Kauderwelsch.
Ganz schlimm ist der fehlende Kontext!
z.B. geheime LTO Probleme
Oder, welcher µC überhaupt
Oder, was das ursprüngliche Problem ist, welches du fangen möchtest.

[uwefed]

@combie

welcher µC überhaupt

Na einen NANO mit RAM Steroiden.

Grüße Uwe

[my_xy_projekt]

Naja, die ergibt sich aus dem Speicher.
Wenn Du den Speicher vollständig beschreiben willst, mach ein Array auf, welches die Größe des Speichers hat.
Beschreibe es.
Lese es aus.

Ändert aber nix an der Tatsache, dass Speicher auch für den Code gebraucht wird.
Du weisst also nicht, wenn ein Problem auftritt, wo das passiert....

[noiasca]

@Megaquaeler

Der Code soll/Brauch keine Funktion zu haben es geht mir einzig und alleine um den Speicher Test.

du wirst den Datenmüll trotzdem im Code nutzen müssen, ansonsten kann es der Compiler wegoptimieren.

so kannst du SRAM verbrauchen:

/*
 * https://forum.arduino.cc/t/programm-speicher-gezielt-voll-machen-speicher-testung/1386494
 */

template <size_t arrSize>
class Garbish {
    uint8_t bin[arrSize];
  public:
    Garbish() {}
    void begin() {
      for (auto &i : bin)
        i = random(256);
    }

    void debug() {
      for (auto &i : bin) {
        Serial.print(i);
        Serial.print(' ');
      }
      Serial.println();
    }
};

Garbish <200>garbish; // n bytes SRAM sinnlos verbrauchen

void setup() {
  Serial.begin(115200);
  garbish.begin();
  garbish.debug();
}

void loop() {
  // put your main code here, to run repeatedly:

}

[combie]

@noiasca

ansonsten kann es der Compiler wegoptimieren.

__attribute__((used))

[michael_x]

@noiasca

so kannst du SRAM verbrauchen

Und das Ergebnis des Tests ist?
Was macht der Sketch, wenn es den RAM gar nicht gibt?
Wenn das Testobjekt andere Variable oder benutzte Bereiche des Stack überlagert?

[noiasca]

@michael_x

Und das Ergebnis des Tests ist?

Da gibt es keinen Test. Das macht der TO mit seinem übrigen Code.

[MicroBahner]

Wenn ich das richtig sehe, will der TO den Programmspeicher testen und nicht das RAM. Also einfach einen Code, der viel Speicher verbraucht. Z.B. viele konstante C-Strings.
Interessant wäre dabei noch, welches Board @Megaquaeler überhaupt verwenden/testen will.
Beim hochladen kann man dann einfach den Flash verifizieren lassen.

[combie]

@MicroBahner

Interessant wäre dabei noch, welches Board @Megaquaeler überhaupt verwenden/testen will.

Wir sind es nicht wert, das zu erfahren.
Wir haben nur die willigen/billigen Zuarbeiter zu sein!

Ich gehe davon aus, dass da wieder einer der "Undefined Behavior" Effekte auftritt und an der falschen Stelle gesucht wird.
Und nicht da wo er steckt, im auch wieder geheimen Code.

Denn: Meist sitzt der größte Fehler direkt vor dem Monitor.

[Megaquaeler]

OK Gab mehr Rückmeldung wie ich dachte.
Also mal der reihe nach.

@combie

Aber was du da von dir gegeben hast hört sich für mich an wie Kauderwelsch.

ICH bin er Meinung das ich mein Problem gezielt beschreien habe.
Sollte das nicht der fall sein bin ich klar für Rückfragen offen.

@combie

Ganz schlimm ist der fehlende Kontext!
z.B. geheime LTO Probleme
Oder, welcher µC überhaupt
Oder, was das ursprüngliche Problem ist, welches du fangen möchtest.

Ok fasse ichs mal kurz zusammen.
Ich möchte gerne NEUE und/ Oder schon ordentliche gebrauchte mikrocontroller testen.
Besser gesagt ihren PROGRAMMSPEICHER und NICHT den Ram.
Das soll vom Attiny 13 bis ESP32 Gehen.

du wirst den Datenmüll trotzdem im Code nutzen müssen, ansonsten kann es der Compiler wegoptimieren.

Genau das ist mein Problem.
Ich kann/Möchte den Daten Müll ja nicht ausführen und sobald der Compiler sieht das es nicht aufgerufen wird, oder er den punkt zum aufrufen nicht erreichen kann schmeißt er es oft einfach weg, Was der ja eigentlich genau richtig macht aber nicht für meinen anwendungsfall.

Wenn ich das richtig sehe, will der TO den Programmspeicher testen und nicht das RAM. Also einfach einen Code, der viel Speicher verbraucht.

Genau Richtig.

Wir sind es nicht wert, das zu erfahren.
Wir haben nur die willigen/billigen Zuarbeiter zu sein!

Interesante einstellung ich kenne zur dein Problem nicht aber wer nicht helfen will oder kann muss dies auch nicht tuhen.

Ich gehe davon aus, dass da wieder einer der "Undefined Behavior" Effekte auftritt und an der falschen Stelle gesucht wird.
Und nicht da wo er steckt, im auch wieder geheimen Code.

Den es zur zeit noch nicht gibt

Denn: Meist sitzt der größte Fehler direkt vor dem Monitor.

Dem stimme ich dir zu.

Ich werde mir dann mal den Vorschlag mit den C-Strings ansehen.

[combie]

@Megaquaeler

sobald der Compiler sieht das es nicht aufgerufen wird, oder er den punkt zum aufrufen nicht erreichen kann schmeißt er es oft einfach weg,

Wie man das verhindert habe ich eben geschrieben!
Gefällt dir das nicht?
Warum nicht?

Außerdem verwendet man kein Zufallsdaten für Flashtests sondern geschickt ausgewählte Muster.
Natürlich den Temperaturbereich voll abdecken.

[michael_x]

@combie

den Temperaturbereich voll abdecken

Meinst du "Wertebereich" ?

@Megaquaeler

Das soll vom Attiny 13 bis ESP32 Gehen.

Wenn du einen ESP per Arduino-IDE beschreibst, erreichst du nur einen minimalen Teil des Speichers. Das meiste wird für das Betriebssystem oder gar ein FileSystem verwendet (Schau die mögliche Aufteilung des Flash bei ESP-Controllern an).
Wenn du es ohne Arduino-IDE machst, musst du für jeden Controller was anderes erfinden.

Wenn dir als Test das Verifizieren nach dem Code-Hochladen reicht, sollten die Tips bisher schon reichen

[combie]

@michael_x

Meinst du "Wertebereich" ?

Nein!
Ein Flash/EEPROM Baustein, welcher im Kühlschrank prächtig funktioniert, kann bei Zimmertemperatur versagen.
Also beim Test den vollen Temperaturbereich durchfahren.
Ohne ist der Test unsinnig.

[Plumps]

Ist der Test nicht generell unsinnig? Hattet ihr schon mal Speicher Probleme? Ich bisher nicht, will auch kein Maßstab sein.

[wwerner]

@Plumps

Hattet ihr schon mal Speicher Probleme?

Ganz ganz ganz selten. Eher PIN Defekte.

[combie]

@Plumps

Hattet ihr schon mal Speicher Probleme? I

2 mal in 10 Jahren.

Einmal EEPROM auf einem Nano kaputt.
Mein Fehler, zu oft beschrieben.

Der andere war mein Test UNO, Flash Fehler.
KA, warum. Evt. auch zu oft beschrieben....

Daraus leite ich ab, dass jeder Test den AVR näher an den Tot bringt.

[Megaquaeler]

@MicroBahner

Also einfach einen Code, der viel Speicher verbraucht. Z.B. viele konstante C-Strings.

Ja das geht in die gewünschte Richtung.

Vielen dank für euere Tipps und Anregungen.