POC LED Chaser Engine (Smaltalk Niveau)

[The Man]

> Thread-Intention
Dieser Thread soll erstmal eher Smalltalk-Niveau sein, ohne Code. Eher
eine Konzept-Betrachtung und ein Try-Of-Concept.
-
Zu einem guten Teil auch für mich als Gehirnjogging gedacht, habe ich
nicht nach existierendem gesucht.
Bin jetzt aber interessiert, wenn jemand eine Bibliothek in der Richtung
kennt.

>Motivation
Aus der Verbindung von meinem sekundär RC-Hobby und Faible für Licht,
habe ich während Corona eine dieser Karren mit jeder Menge WS2812
ausgestattet.
BES - jede Menge LED´s (youtube.com)

>Grobe Konzept-Skizze
Weil ich auch Lauflichteffekt wie den Night-Rider oder ähnliche haben
wollte (Betonung liegt auf "ähnliche"), wollte ich nicht einfach ein
rotes Pendel-Licht hard coden, sondern ein Konzept, welches den Effekt
abstrahiert und auch andere Erscheinungsformen zulässt. Z.B. sind ja
diese Teardrops sehr ähnlich zum Night-Rider Effekt.

Grundsätzlich wollte ich mir eine "Chaser-Effekt-Engine" ausdenken, wo
a) Die Effektform (also z.B. Night-Rider oder Teardrop) von außen
vorgebbar ist
b) es sollen mehrere Effekte-Instanzen auf einem LED-Segment
gleichzeitig laufen können
c) ein Effekt soll auf LED-Segmenten mit unterschiedlich vielen LEDs
gleich schnell laufen können

Meine Lösung ist, einen Kernel zu definieren - die Namensgebung ist in
Anlehnung an Filter-Kernel, als eine Abfolge von Werten. Die Denkweise
ist "den Kernel über das Segment zu schieben".
Die Position des Kernels ist eine relative in 0 bis 1000. In einem
"Kernel-Mover", welcher eine Referenz auf den Kernel und das Zielsegment
bekommt, wird mit der Position die Zielpixel auf dem Segment berechnet.
-
Dazu kommen Überlegungen, ob z.B. das LED-Segment ein Kreis ist und
immer alle Kernel-Pixel sichtbar sein sollen, also ein implementierter
Wrap-Around, oder ob Kernel-Pixel deren Position außerhalb des Segmentes
liegen, unsichtbar sein sollen.

Das ist ein erstes Try-Of-Concept mit Wrap-Around und ohne unsichtbare
Pixel.
Chaser Engine Try_1 (youtube.com)

[wkrug]

Möglich ist da vieles.
Ich habe mich mal an einem Lichtmodul für den Modellbau versucht, das geht ja in eine Ähnliche Richtung.

Mehrere verschiedene Chaser zu programmieren sollte kein Problem sein.
Für die Effekte, die Du haben willst müssten die LED's aber auch gedimmt werden - Sprich die Ausgänge werden vermutlich per PWM angesprochen werden müssen.
Das bedeutet für jeden Step der Sequenz müssen Parameter für Farbe und Dimmwert hinterlegt sein.
Das kann zu einem Problem werden, wenn man mehrere Sequenzen auf den gleichen LED's laufen lassen will - Da müsste man Prioritäten festlegen.

Das mit der unterschiedlichen Anzahl von led's und gleicher Laufzeit versteh Ich nicht ganz.
Soll der Effekt bei 8 LED's von sagen wir 5 Sekunden bei 64 LED's auch 5 Sekunden Dauern? Oder sollen die Steps gleich lang sein?

Ich vermute mal das Ganze soll auf einem Microcontroller laufen. Wenn jede LED gedimmt werden muß brauchst Du sehr viele PWM Ausgänge - Für jede LED - Farbe eine.
Da musst Du gucken ob du einen Controller mit genügend PWM Ausgängen findest.
Alternativ kannst Du auch PWM per Software generieren, aber je nach Controller ist da die PWM Frequenz nicht berauschend.
Alternativ könntest Du auch LED mit Intelligenz einsetzen oder die PWM Aufgabe auf externe Chips ( Schieberegister oder Spezial IC's ) oder weitere Microcontroller auslagern.

Die PWM Dimmung darf aber nicht zu langsam sein, da man sonst das Flackern warnehmen kann. Ich würde hier mindestens 100Hz erreichen wollen - Mehr wäre besser.

Für die Ansteuerung der Sequenzen gibt es sicher mehrere Möglichkeiten ( Serielle Schnittstelle, externes Programmiergerät, einfache Potentiale auf Pins ).
Beim rclineforum wurde auch mal an einer Lichtsteuerung für Modellfahrzeuge gearbeitet - eventuell findest Du dort auch Anregungen.

Wenn Platz keine Rolle spielt kannst Du auch mal das DMX512 Protokoll anschauen.
Das ist im Prinzip eine serielle Schnittstelle für Lichtsteuerung. Die einzelnen Geräte setzen dabei nur die Werte um, die von einem Controller ( z.B. PC mit Interface ) aus gesendet werden.

[The Man]

Die WS2812, die ich oben meinte sind diese Digital LED - die haben den PWM-Treiber für jeden Farbchip im Gehäuse mit drin. Der µC schickt nur einen Bitstream, in dem jeded Pixel codiert ist.

"Soll der Effekt bei 8 LED's von sagen wir 5 Sekunden bei 64 LED's auch 5 Sekunden Dauern? Oder sollen die Steps gleich lang sein?"
-> das erste. In die Mimik welche den "Kernel" (also die PWM-Werte eines Musters) bewegt, wird eine relative Posistionsangabe auf die Anzhal der Pixel normiert.

[Holomino]

Klingt irgendwie nach proggen eines Device-Context auf'm PC.

Das kannst Du durch einen zyklisch behandelten Ausgabepuffer (löschen/neu beschreiben/rausschieben) realisieren.
Wenn das vom Speicher her knapp wird, schau Dir mal die alten Konzepte von Bitmap-Dateien mit verminderter Farbtiefe an. Die haben dann keine 24 Bit mehr pro Pixel, sondern lösen das über eine Farbpalette mit 2, 16 oder 256 Farben.
Ist noch die Frage, ob man beim Start irgendwie herausbekommt, wieviele LEDs an Data-Out hängen. Kriegt man das durch Rückführung des Data-Out an der letzten LED zum Controller hin? Dann wüsste man, wie groß der Ausgabepuffer sein muss und kann das beim folgenden Setzen der Werte berücksichtigen.

[wkrug]

Die WS2812, die ich oben meinte sind diese Digital LED

Entschuldige, das hab Ich überlesen.

...wird eine relative Posistionsangabe auf die Anzahl der Pixel normiert

Dazu muss der Controller "wissen" wie viele LED's angeschlossen sind und welche Ablaufgeschwindigkeit gewünscht wird.
Daraus kann dann der Controller errechnen wie lange ein Umschaltzeitpunkt von einem Step zum anderen dauern muß.
Ich würde das mit einem Timer und Comparematch lösen. Ist der Comparematch Wert erreicht wird ein Interrupt ausgelöst der eine Weiterschaltung auf den nächsten Step startet.
Je niedriger der Comparematch Wert umso schneller läuft die Geschichte. Aus den 2 Werten Zeit pro Durchlauf und Anzahl der LED's kann der Wert für den Comparematch berechnet werden.

Irgendwo wird es aber eine Grenze der maximal zu verwendenden LED's geben, weil das verfügbare RAM bei jedem Controller endlich ist und für jede LED Farbe 3 Werte abgelegt werden müssen ( 3* Helligkeit*Anzahl der Steps*Anzahl der Sequenzen ).

Fall 1:
Die einzelnen Chaser haben ja eine endliche Länge, diese dürfte in einem Fall die minimale Anzahl der LED's festlegen. Bei mehr LED's müsste man hochskalieren, also mehrere LED pro Step ansteuern.
Möglich wäre auch den Effekt mehrfach innerhalb einer Reihe ablaufen lassen, dann passt aber die Geschwindikgeitsanpassung nicht mehr.
Außerdem stelle Ich mir das bei vor und rücklaufenden Effekten schwierig vor ( Gedankenexperiment: Du benutzt 16Steps und hast 20LED. Wann läuft dann der Effekt zurück damit es gut aussieht ).

Bei vielfachen den benutzten Steps wird das einfacher z.B. 16,32,48,64 usw.
Dadürch würde aber bei Lauflichtern immer gleich um 4 LED weiter geschaltet werden.

Fall 2:
Ein anderer Weg wäre die maximale Anzahl von Steps und damit LED's in den einzelnen Chasern zu verwenden und dann bei weniger LED's Steps zu überspringen.
Das braucht aber viel FLASH Speicher.
Es wird also für 256LED geproggt, bei 128LED wird nur jeder 2te Step benutzt.


Meine ursprüngliche Aussage, das bei gemischten Programmen Prioritäten gemacht werden müssen lass Ich mal stehen.
Ein Programm sagt Rot 128 Helligkeit das zugemischte andere sagt aber Rot255, dann müsste IMHO der Wert 255 genommen werden.

Ich beziehe mich hierbei auf die Möglichkeiten von ATMEL AVR Controllern - mit anderen Controllertypen sind da evtl. ganz andere Vorgehensweisen möglich.

Wie viele LED sollen es nun maximal werden und welche Controller(-familie) sollen verwendet werden?

Wie gesagt, das sind alles nur Gedankenexperimente ohne schon fertigen Code.
Eine Fleißaufgabe dürfte auch das Programmieren der einzelnen Sequenzen sein.
U.U. könnte man da auch in einer Tabellenkalkulation was rechnen lassen und die Ergebnisse dann als Tabelle in den Controller Code einfügen ( Hab Ich schon mal für ein anderes Projekt gemacht ).
Damit sollte sich der Speicherverbrauch berechnen lassen.

[The Man]

Ui , das hat meiner Seits jetzt etwas gedauert
-
so, vor dem ganzen selbst-beweihräucherndem Geschwätz unten, erstmal ein blinkender Teaser
Chaser Try 3 - YouTube

auf einige genannte Aspekte geh ich mal selektiv ein - meine aktuell schlussendliche Lösung ist dann ganz unten - soll nicht methaphorisch gemeint sein :>

Wie viele LED sollen es nun maximal werden und welche Controller(-familie) sollen verwendet werden?
Ja, das erstmal vor ab - läuft auf einer STM32-Bluepill und ich hab ein Framework von einem RogerClark aus Melbourne da drauf und nutze auch dessen WS2812 Bibliothek,

"Das kannst Du durch einen zyklisch behandelten Ausgabepuffe"
Ist auch so geworden. Für jeden Farbkanal gibt es ein Buffer-Vector, -> "Dazu muss der Controller "wissen" wie viele LED's angeschlossen sind"
Weiß er, da die von mir verwendete library für die PixelLED ohnehin ein #define fordert

"Die einzelnen Chaser haben ja eine endliche Länge, diese dürfte in einem Fall die minimale Anzahl der LED's festlegen. Bei mehr LED's müsste man hochskalieren..."
Ich hatte mich jetzt dazu entschieden, (erstmal) keine Skalierungs oder Step-Interpolationen ein zu bauen. Wollte den Aufwand überschaubar halten, um das Konzept
was mir vorschwebte erstmal aus zu probieren. => Try-Of-Concept so zu sagen

Wann läuft dann der Effekt zurück damit es gut aussieht
Richtig, es gibt definitiv Konstelationen - insbesondere wenn ich es langsam laufen lasse - wo man das Ruckeln sieht. Das habe ich im Moment gekauft, weil es bei "mittlerer" Effektdynamik und fahrendem Vehicle nicht ins Auge fällt.

Ein anderer Weg wäre die maximale Anzahl von Steps und damit LED's in den einzelnen Chasern zu verwenden und dann bei weniger LED's Steps zu überspringen.
Muss zugeben, ich habe auf die Schnelle das gedankliche Konzeptkostrukt hinter der Aussage nicht verstanden.
Meine Mimik funktioniert aktuell so, dass die Pixelposition des ersten Pixel eines Chasers ausgerechnet wird nach (ich benutze nicht 100(%) Einheiten, sondern 1000, weil der Kram auf int-Typen läuft.
Ist zugegeben eher nonsense auf einem µC der FPU hat.
posCalcDyn = (pos*segmentGroup[0].length) / 1000;//calculates position of first Pixel of kernel
Die Folgepixel werden einfach stumpf ohne ausrechnen auf die Folge-Indexe des Segmentes geschrieben. Dadurch bleibt die Enten-Pixelfamilie zusammen ;>
-
Um zum Ausgangsgedanken zurück zu kommen - ich denke, ein Überspringen würde sich damit von alleine ergeben. Hab es aber nicht explizit getestet, sondern nur
geschaut, ob ich mit der aktuellen Erscheinung zu mindet 85% zu frieden bin

################################################## ################################################## #############################

Mein aktuelles Konzept was nach erster Benutzung zwar funktioniert, aber ganz sicher nutzungs-ergonomische Macken hat (typischer Fall von "von innen nach außen entwickelt - statt außen nach innen):
Es gibt pro Farbe einen uint16_t vector. Ich habe uint16_t gewählt, weil sich dann Überläufe bin zu einem gewissen Maße erkennen lassen, wenn der Wert > 255 ist. Außer es haben so viele
Effekte drauf geschrieben, dass das der Wert von 2^16 übergelaufen ist.

Grundsätzlich folgt mein Ansatz einem Petruschka-Prinzip (selbst erfundenes Wort), wo jeder Layer eine bestimmten Baustein in der Abstraktion liefert.
Segmente definieren Ausschnitte vom Framebuffer einer Farbe. Segmente gleicher Länge können in Vectoren zu Segmentgruppen zusammengefasst werden - das hilft für symmetrische Effekte
Es gibt Kernel, welche nicht farbsensitiv sind, und nur vector-basiert eine Ansammlung von Werten darstellen.
Segmentegruppen und Kernel werden einem Kernel-Mover übergeben. Wie der Name impliziert, bewegt dieser den Kernel über die angegeben Segmente. Dazu bekommt er eine relative Position, die er mit Hilfe der Vector.Size() Eigenschaft
der Segmente auf die konkrete Pixelzahl der Segmente normiert.
-
Ein Kernelmover wird EINEM Effekt mitgegeben. Die Aufgabe eines Effektes ist, seinen Kernelmover mit einer Position zu versorgen. Dabei kann der Effekt "seinen" Kernel parametrisierbar oft mit ebenfalls parametrisierbarem Positions-Shift anwenden.
-
Mehrere KernelMover wiederrum können einer Sequenz übergeben werden. Eine Sequenz macht aus einem Tick(); unter Verwendung einer speed-Variable durch Auf akkumulieren einen Position, die dann eben an die Effekte geht.
Über den numerischen Wert, der speed-Variable kann die Effektgeschwindigkeit eingestellt werden.
=> Da die Position wie oben beschrieben letztendlich auf die konkrete Segmentlänge normiert wird, laufen alle Segmente innerhalb einer Sequenz synchron mit der gleichen Geschwindigkeit. Das ergib für das Auge eine zeitlich-symmetrische Erscheinung. Da das menschliche Hirn u.A. darauf programmiert ist, nach Symmetrien zu suchen, wird das am ehesten als "stimmig" wahr genommen.