JSON Parsing macht bei einem Zeichen mehr plötzlich Probleme

Hallo Forum! :slight_smile:

Aktuell versuche ich mit Ardunio IDE 2.1.1 Input aus dem Twitch-Chat auf einer 64x64 LED Matrix mit einem ESP32 Trinity sichtbar zu machen. Mit der Form !{"Pixel":"x,y,r,g,b"} (i.e. !{"Pixel":"1,1,255,0,0"}) kann man die Matrix über den Chat ansteuern.

Das ganze funktioniert auch wie es soll, BIS die Zeichenzahl (ohne Kommas) 10 überschreitet. Es funktioniert beispielsweise !{"Pixel":"1,1,255,255,11"} , aber nicht wenn ich ein Zeichen (z.B. die 1 am Ende) hinzufüge: !{"Pixel":"1,1,255,255,111"}.

Dann bekomme ich folgende Fehlermeldung:

07:59:24.836 -> payload_str: :twitchname!twitchname@twitchname.tmi.twitch.tv PRIVMSG #twitchname:!{"Pixel":"1,1,255,255,111"}
07:59:24.836 -> 
07:59:24.836 -> quote_start: 68
07:59:24.836 -> quote_end: 96
07:59:24.836 -> {"Pixel":"1,1,255,255,111"}
07:59:24.836 -> 
07:59:24.836 -> assert failed: heap_caps_free heap_caps.c:381 (heap != NULL && "free() target pointer is outside heap areas")
07:59:24.836 ->
07:59:24.869 ->
07:59:24.869 -> Backtrace: 0x400836ed:0x3ffcabf0 0x4008bca9:0x3ffcac10 0x40091129:0x3ffcac30 0x40083c56:0x3ffcad60 0x40091159:0x3ffcad80 0x400dac9a:0x3ffcada0 0x400daca9:0x3ffcadc0 0x400d4303:0x3ffcade0 0x400d458e:0x3ffcae30 0x4016a19b:0x3ffcae90 0x4016a655:0x3ffcaeb0 0x4016a61a:0x3ffcaee0 0x400d6450:0x3ffcaf00 0x4016a5d9:0x3ffcaf30 0x400d66b2:0x3ffcaf50 0x400d6741:0x3ffcaf80 0x400d699e:0x3ffcafa0 0x400d6a02:0x3ffcafe0 0x400d66b2:0x3ffcb000 0x400d6741:0x3ffcb030 0x400d67d5:0x3ffcb050 0x400d682e:0x3ffcb090 0x400d69e7:0x3ffcb0d0 0x400d7971:0x3ffcb0f0 0x400d7b49:0x3ffcb230 0x400d350e:0x3ffcb250 0x400dc5e5:0x3ffcb270
07:59:24.901 ->
07:59:24.901 ->
07:59:24.901 ->
07:59:24.901 ->
07:59:24.901 -> ELF file SHA256: a8a734367dd22622
07:59:24.901 ->
07:59:25.184 -> Rebooting...

Da es ja scheinbar irgendwas mit dem Memory-Handling (?) zu tun hat, habe schon versucht an der Größe des StaticJsonDocument<200> doc; rumzuspielen bzw. dieses dynamisch zu machen - ohne Erfolg. Debuggen hat mich jetzt auch nicht wirklich weitergebracht... :melting_face:.

Die Frage ist warum sind 10 Zeichen okay, aber bei >=11 scheint irgendwas bei der Verwendung der JSON nicht mehr zu funktionieren :thinking:.

Wenn mir jemand unter die Arme greifen könnte oder mich zumindest in die richtige Richtung stupsen könnte, wäre ich sehr dankbar :slightly_smiling_face:.

Und hier ist der ganze Code:

Liest sich so als ob der heap voll läuft.

Gibt es einen Grund warum du das display dynamisch mit new erzeugst oder kannst du es auch statisch machen:

MatrixPanel_I2S_DMA dma_display = MatrixPanel_I2S_DMA(mxconfig);

Zugriffe auf das display dann natürlich nicht mehr mit -> sondern mit.
Also statt

dma_display->drawPixel(...);

Sondern

dma_display.drawPixel(...);

Schon,
ist nur die Frage, ob durch mehr statischen RAM der mögliche heap nicht kleiner wird.
Aber das ist bei solchen Controllern mit Betriebssystem und viel RAM nicht mehr so einfach zu beantworten.
Ich würde versuchen rauszufinden, was in parseMessage passiert.

Hast recht. Im besten Fall würde das dann aber nach dem kompilieren bereits ausgegeben werden wenn mehr als 100% vom RAM benutzt werden...

Sicherlich auch nicht verkehrt :grin:
Strings mit F makro könnten auch noch etwas RAM sparen...

Vielen Dank erstmal für eure Antworten! :slight_smile:

Das würde ich auch gerne :sweat_smile:. Ich weiß aber nicht genau wo ich da anfangen soll. Weil nicht mal die "("deserializeJson failed: ");" ausgegeben wird. Das der Fehler bei der Zeile DeserializationError error = deserializeJson(doc, pixel_str); liegen müsste.

Aber den String der deserialized wird ist laut Serial.println(pixel_str): {"Pixel":"1,1,255,255,111"}. Und das scheint ja erstmal richtig zu sein. Ich weiß halt nicht warum der selbe String mit nur einem Zeichen mehr dann plötzlich abgelehnt wird: {"Pixel":"1,1,255,255,11"} :thinking:.

Weil ich nicht sonderlich bewandert bin mit der Libary und erstmal Beispielcode benutz habe :face_with_peeking_eye:. Habe es mit einer statischen Methode jetzt auch leider nicht zum Laufen bekommen. Aber Danke für den Vorschlag!

Okay, das komische ist: parseMessage() läuft einmal komplett durch, gibt die Werte weiter an setRgb(). Die LED geht nämlich auch kurzzeitig an UND erst danach crasht die Anwendung.

Also scheint es nicht direkt an der Deserialization des Jsons zu liegen :thinking:.

Das ist typisch für Speicherprobleme, dass bei irgendwelchen Anderungen der Fehler woanders auf einmal anders aussieht.

Im schlechtesten Fall schafft man es, dass ein "crash" nur noch sporadisch auftritt.

Hmm... %d parst welchen Datentyp?

Oh mein Gott du hast mich nochmal auf die richtige Richtung geschickt... :face_with_peeking_eye:
Ich hatte mir davon schon mal gedacht, dass %d ja eine int returned aber ich eine uint8_t brauche und da irgendwas nicht passen kann. Habe auch was anderes ausprobiert, aber es dann doch nicht mehr weiter verfolgt, weil es ja eigentlich mit %d funktioniert hat.

Die Lösung ist einfach %hhu anstatt %d zu nehmen... Richtig unnötig :sweat_smile:

Aber VIELEN DANK dir! :star_struck: