Unerwarteter Speichermangel Lichtmaschine 101

[screatch]

Hallo . liebe Mobaliber, ich habe eine Frage zur Programmierung des LED Nano. Ich habe das unte zusehende Programm auf den Nano geladen.

Prog_Gen_Data_15_06_2026_actuell_mit Weichen391-395_erweitert. [code][attachment=0]Prog_Gen_Data_15_06_2026_actuell_mit Weichen391-395_erweitert.MLL_pgf

[/code]
Wenn ich alle Programmzeilen aktiviere zur Programmierung erhalte ich 97 % Programm und 75 % dynamisch angezeigt .
Das Programm läuft aber nicht, dh. Heartbeat auf der Platine flackert nur schwach unkontrolliert.
Ich habe danach einzelne Programmteile abgewählt und dann erneut programmiert:
- ohne BBW Zeile 10 -22 deaktiviert 97% 71%
-einige Stepper- deaktiviert Zeile 110 -127 91% 69%.
Ich habe die Stepper auf LED Kanal 2 umgestellt, von der LED Steuerung Kanal 0 getrennt.
Jetzt meine Frage: was ist an meinem Programm nicht in Ordnung, das die Speicherauslastung so hoch ist, oder geht nicht mehr drauf.
Ich habe ja nur 62 LED Kanal 0 und 21 auf Kanal 2. Braucht die Steppersteuerung zu viel Speicher?
Wer könnte mir dazu mal ein Feedback geben.
Noch eine Anmerkung: bei der Prommierung nur Zeile 3 - 46 blitzen alle LED´s sporadisch.

[PeterVT11]

Hallo Dietmar,

Das ist eindeutig Zuviel für den Arduino. Genaue Zahlen (sprich Prozentzahlen) hab ich nicht. Aber mir ist das auch passiert. Abhilfe gibt es nur mit der Lichtmaschine Pro (mit dem ESP32) oder zwei Lichtmaschine Classic (mit Arduino). Früher gab es auch eine ESP32-Erweiterung, aber die war aus meiner Sicht nicht optimal.
Da sicher noch mehr Programmzeilen dazu kommen, ist die Lichtmaschine Pro die richtige Wahl.

[Frank_TT]

Hallo Dietmar,

versuche mal über den Programmgenerator den Bootloader für Full Memory zu installieren.
Vielleicht kommst du damit für den Moment ein Stück weiter.

[raily74]

Hallo Dietmar,

leider habe ich aktuell keinen Zugriff auf die MobaLedLib und kann mir die PGF nicht anschauen. Gut 80 LEDs sind aber in der Tat ziemlich wenig, wo doch der Arduino bis zu 256 RGBs schalten könnte.

Ohne dass ich es mir genauer ansehen kann, so kann ich aber zumindest aufzählen, welche Funktionen Speicher belegen und somit die Anzahl der maximal möglichen LEDs reduzieren.

• Muster aus dem Pattern Configurator (vor allem mit 8 Bits)
• Variablen (glaube ich)
• Reservierte LEDs (z. B. für ungenutzte WS2811)
• Farbeinstellungen (um vorgegebene Helligkeiten zu ändern)
• RGB LEDs statt einstellbarer LEDs

Wenn du davon viel verwendest, ist die Lichtmaschine Pro wie von Peter beschrieben die beste Lösung.

[PeterVT11]

Hallo Dietmar,

ich hab gerade versucht deine PGF zu laden. Leider schlägt das fehl. Daher meine Frage:

Welche Version der MobaLedLib verwendest Du? (Steht im Prog_Generator im Excel-Sheet oben rechts).

[jueff]

Servus Zusammen,

irgend etwas stimmt hier nicht zusammen.
- das Export File lässt sich nicht importieren, es sind zusätzliche, unerwartete Zeilenumbrück in der Datei

Wird der Export manuell korrigiert und importiert zeigt es bei mir

- Flash: 27762 bytes (90%) of 30720
- RAM: 997 bytes (48%) of 2048

bei Dietmar: 97 % Programm und 75 % dynamisch angezeigt .

Bei mir läuft das importierte Programm.

Was anzumerken ist: Es sind drei Scheduler konfiguriert, einer davon wird gar nicht verwendet.
Der Scheduler braucht ca 1000 byte + ca 110 Byte pro Instanz = 1330 gesamt, das ist im Umfeld der MobaLedLib RIESIG viel Speicher. Zusätzlich braucht der Scheduler mindestens 30 Byte RAM pro Instanz, also 90. Diese werden vom Scheduler dynmisch allokiert, werden also bei der Kompilierung nicht ausgewiesen. Sind schon 75% benutzt sind noch 500 Byte RAM übrig, für die Scheduler und den MobaLedLib Core. Das könnte je nach Situation knapp werden.

Grundlegend wäre zu klären:
1.) warum 97% und 75%?
2.) Kann der Scheduler optimiert werden?


zu 2.) ich glaube ja, bezüglich RAM werden einige Variablen als Instanzvariablen angelegt, die nur im Konstruktor verwendet werden (start_Std, start_Min, end_Std, end_Min), manche Instanzvariablen können durch lokale variablen ersetzt werden (DstVar, z_diff), optimierungsmöglichkeiten bei Variablen neuZufall und orgZufall. Auch die Flash Speichernutzung kann deutlich reduziert werden, weil einiges an redundantem Code vorhanden ist. Würde ca. 300 byte sparen.

Soweit mein Feedback dazu.
Jürgen...

[screatch]

Hallo alle zusammen, danke für das tolle Feedback von allen. Also ich habe Programm Version 3.5.0 und Pattern 05.11.25. Das Patterngenerator-
file hatte ich vergessen anzuhängen.

Code: Alles auswählen

[attachment=0]Stepper_Test_Example.MLL_pcf[/attachment]

Bei den Speicherbelegungsbeispiele waren ja immer nur Teile des Programms aktiviert. Alles ausgewählt war dann 97% 75%. Aber aus den Beiträgen konnte ich herauslesen, das ich den Nano gestresst habe mit den vielen Pattern Files für die Stepper (12 Stück). Leider bin ich Laie in der Programmierung und dachte , das das optimal wäre, mein Lösungsweg.

Was anzumerken ist: Es sind drei Scheduler konfiguriert, einer davon wird gar nicht verwendet.
Der Scheduler braucht ca 1000 byte + ca 110 Byte pro Instanz = 1330 gesamt, das ist im Umfeld der MobaLedLib RIESIG viel Speicher. Zusätzlich braucht der Scheduler mindestens 30 Byte RAM pro Instanz, also 90. Diese werden vom Scheduler dynmisch allokiert, werden also bei der Kompilierung nicht ausgewiesen. Sind schon 75% benutzt sind noch 500 Byte RAM übrig, für die Scheduler und den MobaLedLib Core. Das könnte je nach Situation knapp werden.

Die Scheduler sind im BBW und im Bahnhof, die ich aktiviert gelassen hatte, aber die Programmteile BBW und den Bahnhof hatte ich abgewählt bei der Programmierung.
Was werde ich jetzt tun:
1. Schedulerfunktionen reduzieren - hatte nicht die Menge beachtet und die nur für später angelegt
2.dann das aktuelle Pr0gramm nochmals laden um zu prüfen wie die Speicherauslastung ist.
3. den Bootloader full Memory aufspielen

zu 2.) ich glaube ja, bezüglich RAM werden einige Variablen als Instanzvariablen angelegt, die nur im Konstruktor verwendet werden (start_Std, start_Min, end_Std, end_Min), manche Instanzvariablen können durch lokale variablen ersetzt werden (DstVar, z_diff), optimierungsmöglichkeiten bei Variablen neuZufall und orgZufall. Auch die Flash Speichernutzung kann deutlich reduziert werden, weil einiges an redundantem Code vorhanden ist. Würde ca. 300 byte sparen.

Da stoße ich an meine Grenzen, was die Variablen (DstVar ,z_diff )anlegen für mich bedeutet.
Ich werde mich dannach wieder melden.