Eine recht einfache Option ist den Vergleichs-String mit snprintf() zu bilden. Dann brauchst du nur RAM für den Puffer. Je nach Anwendungen kann man den Puffer auch für andere Dinge verwenden.
Wo du bei sowas Speicher sparen kannst:
Die ganzen C String Funktionen haben _P() Versionen bei der ein konstanter String per PSTR() oder PROGMEM im Flash stehen kann. Bei strcmp_P() ist das der Vergleichs-String. Bei snprintf_P() ist es der Format-String. Die AVR Version von printf() hat neben %s für Strings im RAM auch %S für Strings im PROGMEM.
Oder du schreibt eine Funktion die ersten den Anfang des Strings vergleicht der konstant ist. Dann den Variablen Teil. Und dann den Rest der wieder konstant it. Wie kompliziert das ist, hängt davon ab wie der String genau aufgebaut ist.
Vielleicht können wir ja da ansetzen. Wenn Du den Sketch postest, finden wir vielleicht die Ursache für den Speichermangel.
Hau ich mir dessen Verwendung wieder den Speicher voll wie irre? vgl. sprintf?
snprintf ist die sichere Variante von sprintf, wenn also sprintf den Speicher "voll haut", dann dürfte das auch mit snprintf passieren, aber wenigstens kannst Du Pufferüberläufe vermeiden.
Nee, dann ist s(n)printf nix ... das habe ich schon durch.
Normalerweise denke ich bei "Speicher wird knapp" nicht an die Sketchgrösse, sondern an das RAM (zumindest bei einem ATmega328-basierten Arduino).
Bei Dir wird also der Sketch zu gross. Abhilfe hätte ich einige. Du könntest z.B. die Strings für die serielle Debugging-Ausgabe eliminieren und einfach Resultat-Codes zurückgeben. Ist zugegebenermassen nicht sehr komfortabel, aber für reine Debugging-Zwecke ausreichend. Zudem würde die ganze Debugging-Ausgabe in "#ifdef"s einbetten, damit Du sie in der produktiven Version komplett abschalten kannst. Dann könntest Du z.B. die Entwicklung auf einem Mega2560 machen (mehr als genügend Speicher und die fertige Version für den 328er optimieren.
Zur snprintf-Problematik bin ich der gleichen Meinung wie Whandall, sofern ich Dein Problem richtig verstanden habe.
if (strcmp(topic, "AAAA/BBBB/CC/DDDD/EEE/FF") == 0 )
Hau ich mir dessen Verwendung wieder den Speicher voll wie irre? vgl. sprintf?
ich habe fast nix mehr an Speicher
Was meinst du mit "vgl. sprintf" ? sprintf und snprintf sind in dieser Hinsicht das Gleiche. Und du kannst dir natürlich relativ leicht "den Speicher voll wie irre" füllen, wenn du nicht nachdenkst.
Texte sind nun mal der pure Luxus auf kleinen MikroKontrollern. Klar kann man mit PSTR und PROGMEM viel sparen, aber man kann sich auch fragen, warum man sowas überhaupt macht
Und warum auf einem atmega328p ?
Musst du tatsächlich lange Zeilen lesen, speichern und mit Vergleichs-Texten vergleichen?
Dein Link zeigt auf was, wo digitalWrite - Overhead wegoptimiert wurde. Das ist ja wohl eine andere Kategorie.
@Pylon: Das Cross-Entwickeln hatte ich auch schon mal überlegt, aber die kompilierte Größe variiert schon ohne Änderungen am Code, so dass ich der Meinung bin, dass das am Ende noch komplizierter wird.
Das Debugging "muss" - gerade - im Produktivsystem bleiben, die einzige Schnittstelle nach außen wenn es irgenwo hakt.
@Michael_X bitte den Thread lesen und nicht nur einzelne Punkte rauspicken, die nicht dem gesamten Thread entsprechen bzw nicht der Intention dahinter.
Mir ging und geht es eigentlich "nur" darum, oben den Wert von mqttClientId zu ändern, und alle Zeichenketten, die den gleichen Wert wie mqttClientId haben, heißen im fertigen Code auch so.
Die Alternative - zur Developerzeit - wäre Strg+h
Dann muss ich aber bei Änderung von mqttClientId immer neu kompilieren, wollte das eigentlich dynamisch von außen machen können ...
Ist am Ende nicht so wichtig ... but nice to know.
Strg+H in der Arduino IDE, keine Ahnung, code mit AS7.
Und ob die Zeichenlänge nun MQTT ist oder nicht, ist imho auch egal, es kommt am Ende ja auf den Vergleich an. Und das der Topic als Byte-Array kommt hab ich ja gesagt.