POC LED Chaser Engine (Smaltalk Niveau)

[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.