Vielen Dank dir!
Die Audio-Probleme kamen in die neue Audio-Lib rein, weshalb ich diese auf zumindest einem Branch wieder reverted habe, leider war der Mqtt-Branch noch davon betroffen. Habe ich auch dort korrigiert. Hier ist der Issue dazu:
zu 1) Mqtt:
finde den Vorschlag von @JHB von hier gut: Neues Namensschema für MQTT - #22 von JHB
Wenn das allgemeine Zustimmung findet, könnte man das auf diesem Branch noch mit einbauen und wäre glaub sehr gut und komfortabel für die Zukunft aufgestellt.
Zusätzlich habe ich jetzt auf dem Mqtt-branch noch den Zustand „PlayPause“ ausgegeben, da das uns eine deutlich schönere Integration in z.B. Home-Assistant o.ä. ermöglicht. Aber auch dieser Punkt ist zur Diskussion …
zu 2) Audio-Task auflösen:
war ursprünglich ja der Wunsch von @Wolle und ist bezüglich dem Overhead des Tasks und der Queues auch wirklich Sinnvoll, da es uns zusammen mit der jetzt neuen Verteilung der Tasks auf die Cores viel Luft für die Zukunft gibt und zeitgleich den Audio-Teil sauber vom Rest trennt und somit deutlich robuster machen sollte, und bei mir auch nachhalitg die Audio-Probleme gelöst hat.
Zusätzliche Optionen wie das parallele Uploaden und Abspielen und den LED-Task nicht mehr anzuhalten sind zur Diskussion (ich bevorzuge klar den Fall, dass alles unengeschränkt weiterläuft und man dafür etwas langsamer uploaden kann, das ist aber Geschmacksache).
Die Aufteilung auf einen „dreckigen Core“ und einen „sauberen Core“, auf welchem nur noch der Arduiono-Loop-Taks und der Audio-Task läuft halte ich für eine sehr gute und zukunftsfähige Lösung, bei der wir nicht bei jeder Änderung wieder über die Tasks nachdenken müssen sondern pauschal einfach alles neue auf Core 0 packen können, ohne dass wir dadurch negativ im Kern unserer Funktkionen einbüsen / verschlechtern. Durch nur noch ein Delay im Loop-Task (war mal eine Lösung für die LEDs das aufzuteilen), gewinnen wir zusätzlich noch ordentlich Luft.
Aufgrund dieser verschiedenen Facetten, ist das hier vermutlich der größte Brocken, auch wenn ich die Änderungen sehr überschaubar finde.
Zu 3) LEDs:
Das ist ja leider kein neues Thema, sondern kam immer wieder hoch (auch in der Vergangenheit), wurde jetzt aber unter Arduino 3 leider nochmal sehr viel schlechter, da dort die RMT-Treiber von Espressiv umgebaut wurden. Ich wollte hier jetzt nicht einfach nur wieder eine Lösung, sondern was möglich robustes und zukunftsicheres:
Fast-Led bietet die Möglichkeit die LEDs auf dem ESP auch per SPI anzusteuern, was ich auch in der Vergangenheit schon auf anderen CPUs genutzt habe und immer sehr stabil war.
Damit das möglich ist, mussen in FastLED ein paar Anpassungen rein, diese sind dort jetzt aber im master
Ein Bug auf Seiten von espressiv hat hier auch zu problemen geführt, mit dem „Hack“ sind wir hier jetzt aber deutlich besser dran und brauchen auch weniger CPU-Last für den Task, da wir nicht abwarten bis alles übertragen wurde.
Diese Lösung unterscheidet sich von allen vorherigen dadurch, dass es jetzt völlig egal ist, wie und wie oft der LED-Task unterbrochen wird oder auf welchem Core er läuft, was uns die Vorteile von der neuen Task-Aufteilung die ich unter 2) beschrieben habe erst ermöglicht. Da die RFID-Reader auf die andere noch verfügbare SPI-Schnittstelle gehen, sollte das kein Konflikt sien, habe bei mir aber nur den PN5180 und konnte deshalb den anderen Reader nicht testen.
Soweit mal dazu …
Den LED-PR habe ich mal komplett separat rausgezogen. Trotzdem ist es für mich eher ein Gesamtkonzept … Bei interesse kann ich auch den MQTT-PR noch separieren, der Prio nach sehe ich den Audio-Task aber wichtiger als die Mqtt-Änderungen.
Bin gespannt auf eure Rückmeldungen und Diskussionen!
…
…
… Bei interesse kann ich auch den MQTT-PR noch separieren, der Prio nach sehe ich den Audio-Task aber wichtiger als die Mqtt-Änderungen.