Hi,
im Zuge der Analyse zu den LEDs habe ich festgestellt, das FastLED auch nur die sed_strip lib von espressif nutzt und alles andere einfach sehr viel overhead ist.
Auch können wir durch FastLED auf manche Einstellungen keinen Einfluss nehmen, die aber durchaus relevant für unser System sind.
Was haltet ihr davon direkt auf led_strip zuzugreifen?
Viele Grüße
Joe
Also grundsätzlich begrüße ich das, wenn man auf zusätzliche Libs verzichtet - das haben wir (äh du) zuletzt bei MQTT ja auch so gemacht. Aber wenn ich mir led_strip anschaue, dann ist das eher die grundsätzliche Ansteuerung und die ganzen Komfortfunktionen müssen wir dann nachbilden und letztlich mehr oder weniger eine eigene (abgespeckte) Lib schreiben, oder?
Wie gehst du da vor? Pickst du dir das bei fastled raus?
Im led_strip kommen schon die Möglichkeiten mit hsv oder rgb mit. Das bisschen was wir extra brauchen würden (also vor allem eine globale Helligkeit, die dann nochmal eine Stufe tiefer greift) können wir relativ einfach auch mit einer eigenen hsv-methode abbilden.
Ich vermute, es würde auf nur eine oder zwei zusätzliche Funktionen rauslaufen, die dann entweder aus FastLED übernommen werden können, oder mit relativ wenig aufwand selbst geschrieben werden.
Der grunsätzliche Aufbau bleibt gleich, da die Core-Funktionen (set und show) ja auch so schon mit FastLED verwendet wurden.
Die Farbkorrekturen sind Geschmacksache, aber auch die könnte man in der einen Schnittstellen-Funktion einbauen (würde ich aber eher weglassen im ersten Schritt).
So zumindest mal mein Vorschlag.
Die Motivation wäre, dass wir vielleiht auch wieder auf einen stabilen Task zurückgehen könnten oder aber auch einfach selbst bessere Kontrolle über die Low-Level Dinge haben, wo wir bei FastLED nicht ran kommen. (Und natürlich eine Lib weniger 
)
[…]
Ok, klingt auf jeden Fall interesant. Muss zugeben, dass ich mir das bisher so tief nicht angeschaut habe.
D.h. du hättest eigentlich schon auch eher das Bedürfnis, den Neopixel wieder in einen Task zu stecken? Bringt dein Umbau ohne Task doch größere Probleme mit sich? Hatte leider noch keine Zeit, es zu testen.
Ich bin mir noch unschlüssig, aktuell haben wir aber zu wenig Kontrolle, um das sauber beurteilen zu können 
.
Wenn die Audio-Lib (also der loop()-call) in den Sonder-Situationen weniger blockierend wird, was hoffentlich bald der Fall ist, gibt es keinen Grund einen Task zu verwenden, sondern eigentlich nur Vorteile dies nicht zu tun, zumindest bei unseren aktuellen Laufzeiten der main loop (mit noch ganz schön viel Luft).
Aktuell kann es in bestimmten Situationen zu verzögerten Ausgaben kommen, dass z.B. die Progress-Anzeige beim Track-Wechsel erst 0,4 Sekunden später startet.
Wird vielen vermutlich nicht auffallen (und ist mir definitiv lieber als die Lösung mit dem Task auf dem jetzigen Stand der FastLED) und auch ein Task würde das nur dann beheben, wenn diese Zeit in der Audio-Loop nicht blockierend genutzt wird.
Aber allein die Möglichkeit zu haben auf einen Task gehen zu können (ohne Nachteile) fände ich schön.
Und das glaube ich könnten wir schauffen, wenn wir Kontrolle über die Buffer-Size, die Geschwindigkeit und die für den RMT-Controller Daten haben.
Die FastLED-Bibliothek ist für den ESPuino schon sehr überdimensioniert, daher fände ich eine schlankere Lösung auch gut.
Allerdings würde ich den LED-Task jetzt nicht entfernen wollen. Das System der Tasks für verschiedene Aufgaben wie LED, RFID, Audio und Web finde ich ganz gut & hat sich bewährt, auch für die Zukunft z.B. wenn neue Funktionen mehr Rechenzeit verbruachen würde es nicht blockieren. Im aktuellen Master gibt es keine Probleme mit der LED-Darstellung, das Problem tritt erst jetzt mit Arduino 3 auf, also liegt es nicht unbedingt am Task.
Leider scheint es ganz tief unten zu haken, schwierig da die Ursache zu finden.
Bin bei dir, hatte die Probleme aber auch schon davor mit den LEDs. Ich vermute wenn ich auf dem fork von FastLED noch ein paar Anpassungen mache, dass wir dann das auch wieder mit einem Task hinbekommen könnten.
Könnte eventuell auch was mit weniger ISR-calls im IRAM zu tun haben, ist aber auf jeden Fall ziemlich tief vergraben was da jetzt den Unterschied macht.
Im ersten Schritt sehe ich das ohne Task aber für den Moment als die beste Lösung, muss ja aber auch nicht morgen fertig werden
Würde mich eine Sache hinzustellen:
Ein Multitask-System ist schön, wenn die Prozesse dafür geschrieben wurden, die Laufzeit egal ist und es reicht wenn ein Task irgendwann dran kommt.
Das ist bei uns alles nicht der Fall.
Daher glaubt ich, dass wir mit z.B. einen schnellen und einen langsamen Loop-Task mit festem Zeit-Slots sehr viel besser fahren würden, weniger Probleme mit dem ganzen Finetuning hätten und überhaupt wieder mehr die Kontrolle über das System bekommen (Beispiel RFID-Task, prio-Einstellungen bei jeder größeren Änderung usw.)
Das ist jetzt unabhängig von der LED-lib, meiner Meinung nach aber wichtig für die Zukunft des Projekts.
Schaut euch doch im ersten Schritt Mal den Stand mit den aufgelösten Tasks an und lasst uns dann nochmal über die vor- und Nachteile von den Tasks reden…
Ich melde mich, sobald ich dazu gekommen bin. Diese Woche sieht es abends leider mau aus mit Freizeit. Vielleicht schaffe ich es ja morgen Abend.