Ich habe gerade eine Platine gebaut um kurze LED-Stripes mit APA102 LEDs
ansteuern zu können.
Ziel waren 30 LEDs, entsprechend habe ich einen 1,8A Stepdown verbaut.
Als Controller langweilt sich da drauf ein ATSAMC21E18A-AU um die Module
mit CAN-FD ansteuern zu können.
Das Ziel ist später aus einem definierten Satz von "Licht-Animationen"
auf Anforderung eine abzuspielen.
Jetzt nehme ich das Ding gerade in Betrieb und mache die erste Software
dafür.
Fürs erste habe ich 6 APA102 angeschlossen.
Ich bin recht zügig bei einem 2-dimensionalen Array gelandet:
Gibt es schon irgendwelche Tools mit denen man sowas sinnvoller befüllen
kann und die mir Google mangels der richtigen Stichworte dazu noch nicht
angezeigt hat?
Am besten visuell mit Farben und Simulation wie das dann aussieht?
Ich hatte kurz überlegt das mit Excel zu machen, das hilft aber auch nur
begrenzt und wird auch schnell sehr unübersichtlich.
Zum Teil kann man sowas sicher auch in Programm-Form lösen und immer nur
die nächste Zeile berechnen.
Das läuft aber auf viel herumprobieren raus bis das wirklich auf dem
Stripe so aussieht wie man sich das vorstellt.
Ideen? Anregungen? Tipps?
Rudolph R. schrieb:> Ideen? Anregungen? Tipps?
Jedes Malprogramm kann RGB24-Bitmaps beliebiger Größe erstellen. Und der
Code, um die Bitmapdaten aus der Bitmapdatei zu extrahieren ist recht
kurz.
c-hater schrieb:> Jedes Malprogramm kann RGB24-Bitmaps beliebiger Größe erstellen.
Hmm, okay, muss ich mal ausprobieren, danke.
Aber spontan klingt das nur wenig leichter das zu pixeln.
Rudolph R. schrieb:> c-hater schrieb:>> Jedes Malprogramm kann RGB24-Bitmaps beliebiger Größe erstellen.>> Hmm, okay, muss ich mal ausprobieren, danke.> Aber spontan klingt das nur wenig leichter das zu pixeln.
Wenn man Gimp als Malprogramm verwendet, kann man übrigens direkt als
C-Quelltext exportieren...
Immer noch zu aufwendig?
Rudolph R. schrieb:> die mir Google mangels der richtigen Stichworte dazu noch nicht> angezeigt hat?
Ich würde "bmp to c converter" probieren. Muss ja nicht jeder seinen
eigenen schreiben... ;-)
c-hater schrieb:> Wenn man Gimp als Malprogramm verwendet, kann man übrigens direkt als> C-Quelltext exportieren...
Es ging mir nicht um das exportieren, sondern um das Pixeln.
Aber ich habe gerade Paint.net offen und das sieht tatsächlich gar nicht
schlecht aus das so zu machen.
Und ich habe für Paint.net ein Addon gefunden um Sprites zu animieren,
das müsste dafür auch gehen, dann hat das Sprite eben nur eine Zeile
Höhe.
Rudolph R. schrieb:> Das läuft aber auf viel herumprobieren raus bis das wirklich auf dem> Stripe so aussieht wie man sich das vorstellt.
Der Trick ist, die Abläufe algorithmisch zu steuern und von außen die
Parameter vorzugeben, z.B. in Script-Form.
Mit Einzel-LEDs will sich bei soetwas doch keiner abmühen.
Wolfgang schrieb:> Der Trick ist, die Abläufe algorithmisch zu steuern und von außen die> Parameter vorzugeben, z.B. in Script-Form.
Sorry, aber als Antwort ist das so für sich nur leeres Geschwätz, zumal
ich praktisch das gleiche auch schon geschrieben habe in dem Satz den Du
passenderweise nicht zitiert hast.
Wenn Du mehr beizutragen hast, gerne, immer raus damit, ich bin bestimmt
auch nicht der einzige den das interessiert.
> Mit Einzel-LEDs will sich bei soetwas doch keiner abmühen.
Naja, zumindest müsste man erstmal ein Lichtmuster für eine bestimmte
Funktion oder einen Effekt haben, bevor man sich überhaupt überlegen
kann wie man das in einen Algorithmus zerlegt.
Und selbst wenn man irgendwann einen Satz Algorithmen zusammen hat, wird
man immer wieder neue Lichtmuster finden, die sich zunächst nicht in
Algorithmen zerlegen lassen.
Rudolph R. schrieb:> Und selbst wenn man irgendwann einen Satz Algorithmen zusammen hat, wird> man immer wieder neue Lichtmuster finden, die sich zunächst nicht in> Algorithmen zerlegen lassen.
Wenn du bis zu vordefinierten Rauschmustern alles vorhalten willst,
kommst du entweder nicht um Einzeldefinition auf Pixelbasis oder um
passende Algorithmen drumrum - egal ob auf dem Zielsystem oder in
irgendeiner Licht-Animations-Kompositionssoftware.
Neue Algorithmen kannst du über eine Plug-In Struktur nachrüsten.
Wenn du es nicht über Algorithmen beschreiben kannst, wäre der
Algorithmus "Leses es aus pixelweise einer Datei ein". Ohne Algorithmus
bleib nur das Handzusammenbasteln. Wie die Datenstruktur dazu am besten
aussieht, ist ein völlig anderes Problem. Erstmal musst du Klarheit
gewinnen, wie du was für Daten erzeugen willst. Wo das Erzeugen statt
findest, ist bis vielleicht auf verfügbare Rechenleistung und Resouren,
auch erstmal völlig egal.
c-hater schrieb:> Wenn man Gimp als Malprogramm verwendet, kann man übrigens direkt als> C-Quelltext exportieren...
Ist nur die Frage, was dabei eigentlich heraus kommt:
Das kann ich mir schenken und GIMP ist mir ohnehin zu überladen.
Lothar M. schrieb:> Ich würde "bmp to c converter" probieren. Muss ja nicht jeder seinen> eigenen schreiben... ;-)
So es bisher aussieht werde ich da nicht drum herum kommen wenn ich das
Array gleich gebrauchsfertig haben will, anstatt da noch dran herum
rechnen zu müssen.
Tja, endlich mal ein Grund was anderes als Embedded zu machen.
Harald schrieb:> Vielleicht hilft Dir das als Anregung für dein eigenes Projekt weiter> https://www.bhencke.com/pixelblaze
Nicht so richtig, das ist ja eher ein Produkt und Closed-Source.
Das Format der Lichtmuster-Dateien ist auch ordentlich kryptisch.
Tolles Teil, so weit komme ich damit sicher nie, war aber auch nie der
Plan.
Rudolph R. schrieb:> Sorry, aber als Antwort ist das so für sich nur leeres Geschwätz
Nein, das war es nicht, er hatte völlig recht.
Im Prinzip ist das ein Problem wie beim Film. Du kannst keinen Film
drehen, wenn du kein Drehbuch hast.
Was dir vorschwebt ist wohl die ultimative DWIW-Software (DWIW: Do What
I Want). Das kannst du knicken. Gibt es nicht. Das Dehbuch schreiben
musst du immer selbst.
Die einzige Alternative: klaue Drehbücher, die andere Leute geschreiben
haben. Da gähnt dann jeder herzhaft, wenn er dieselbe Story schon wieder
sieht...
Also Drehbuch schreiben. Auch das geht mit Gimp. Da ist nämlich Python
als Scriptsprache integriert. Du kannst damit jede beliebige Animation,
die sich irgendwie mit den Mitteln von Gimp in Einzelbildern darstellen
läßt als Script vorgeben. Um die Kleinarbeit des Animierens (also die
Erzeugung der der Einzelbilder) und des Speicherns dieser Einzelbilder
(auch in C) kann sich Gimp kümmern.
Man kann sowas natürlich auch ganz ohne Gimp allein auf einem µC
erledigen. Der Denkaufwand für das Drehbuch ist genau dasselbe. Man
spart allerdings massiv Speicher, weil man die Einzelbilder nicht
vorberechnet im Speicher liegen haben muss, sondern zur Laufzeit
errechnen kann.
Schau Dir doch mal die Animationen (Generatoren) bei Jinx oder Glediator
an, dann hast Du eine Idee wie sowas fertig aussehen kann.
Und dann kannst Du Dir mit relativ wenig Aufwand eigene Generatoren
schreiben. Ist jetzt nicht unbedingt Hexenwerk. Ich würde übrigens
empfehlen für die Generatoren den HSV-Farbraum zu verwenden und dann am
Ende nach RGB umzurechnen. Mit HSV kann man (meiner Meinung nach)
einfacher Farbverläufe, korrektes Fading etc. programmieren.
Habe mir so ein "Framework" für eine 20x20 Matrix programmiert, einige
Ideen sind mir dann auch erst während der Programmierung gekommen.
Das einfachste wäre erstmal ein Balken der einmal den kompletten
Farbraum durchläuft (bei HSV einfach den H-Wert einmal von 0..max
durchlaufen lassen), ggfs. dann noch mit Scrolling der Pixel, das dürfte
schonmal ganz nett aussehen.
Kannst natürlich auch Funktionen wie Sinus o.ä. mit einbauen.
Aber das ist natürlich eher der generische Ansatz, nicht der Ansatz
fertige Muster abzuspielen. Ich finde ersteres geschickter, da man so
auch Zufallsmuster etc. mit einbauen kann.
Sieht dann so aus: https://youtu.be/2vCMYM5h7xI
Markus M. schrieb:> Schau Dir doch mal die Animationen (Generatoren) bei Jinx oder Glediator> an, dann hast Du eine Idee wie sowas fertig aussehen kann.
Das ist schon heftig, sowas wollte ich nicht mal ansatzweise umsetzen.
Aber die sind auch nicht für sowas langweiliges wie eine einzelne Zeile.
Markus M. schrieb:> Und dann kannst Du Dir mit relativ wenig Aufwand eigene Generatoren> schreiben. Ist jetzt nicht unbedingt Hexenwerk.
Ich denke auch, dass es darauf hinaus läuft, vor allem kann man so ja
auch sehr viel mehr Schritte machen ohne das einem gleich der Speicher
ausgeht.
Aber erstmal fange ich mit dem Abspielen von Animationen an.
Wenn das alles grundsätzlich funktioniert und ich "Generatoren" habe die
einfach nur die nächste Zeile aus einem Array liefern, dann kann ich
anfangen richtige Generatoren zu schreiben welche die nächste Zeile
berechnen.
Erst Krabbeln, dann laufen.
Ich habe etwas auf Github gefischt und das hier gefunden:
https://github.com/BiancoZandbergen/bmpdump
Blöderweise ist das ohne Lizenz veröffentlicht, so kann ich damit zwar
für mich rumspielen, das aber nicht einfach wieder auf Github werfen.
Mal schauen, ob der Autor auf meine Bitte per Mail reagiert da eine
Lizenz dran zu packen.
Dank VScode und PlatformIO war das ein Kinderspiel das für Windows_x86
zu bauen und die modifizierte create_c_array_24bit() wirft jetzt schon
mal 2D Arrays aus mit Spalten und Zeilen dem Bild entsprechend und als
BGR.
Jetzt muss ich erstmal von den initalien 6 APA102 auf 30 aufrüsten und
den Code vom Test-Gefrickel auf einen sauberen Stand heben der einen
Puffer für 30 LEDs über den SPI per DMA schickt.
> Ich würde übrigens empfehlen für die Generatoren den HSV-Farbraum> zu verwenden und dann am Ende nach RGB umzurechnen.> Mit HSV kann man (meiner Meinung nach) einfacher Farbverläufe,> korrektes Fading etc. programmieren.
Ich habe mir das gerade angesehen und auf den ersten Blick macht das
schon Sinn das so umzusetzen.
Das kostet vielleicht zusätzliche Rechenzeit, ich habe aber auch nur 30
LEDs und werde somit kaum in die Verlegenheit kommen 20ms pro "Frame" zu
überschreiten.
Thread beobachten
Seitenaufteilung abschalten