Ich stehe vor der Frage, wie ich die Show-Informationen für einen LED-Aufbau speichere - gewissermaßen das Beleuchtungsprogramm. Zum Beispiel habe ich 8 Meter an WS2812B Stripes mit 30 RGB-LEDs pro Meter. Jede RGB-LED benötigt wegen der drei einzelnen Farben daher 3 * 8 Bit an Informationen, um eine (gemischte) Farbe zu schalten. Bei 8 Metern * 30 LEDs habe ich also 240 * 24 = 5760 Bit an Farbinformationen. Dies muss dann natürlich noch mit der "Frame-Rate" multipliziert werden. Bei 30 Bildern pro Sekunde sind das bereits 172800 Bit oder 21,6 Kilobyte. Für eine Lichtshow mit einer Dauer von 60 Sekunden muss ich also mit 1296 Kilobyte etwas mehr als ein Megabyte speichern. Nun sollen natürlich aber mehrere Shows gespeichert werden können. Und dort stehe ich nun vor der Frage, wie ich das am besten bewerkstelligen kann. Ich könnte die Informationen natürlich einfach in Form von Einsen und Nullen abspeichern. Dann hätte ich obigen Speicherverbrauch. Ich könnte versuchen, die Daten zu komprimieren (Beitrag "Re: Daten dekomprimieren für AVR - LHA,GZIP o.ä."). Ich könnte allerdings auch die Werte über eine Beschreibung speichern, sodass diese zur Laufzeit berechnet werden müssten. Nach obigem Beispiel gibt es 2^(24*240) mögliche Zustände der Lichtshow. Dieser Wertebereich könnte die eine Achse eines Koordinatensystems, die Zeit die andere sein. Die Wertepaare könnten über eine Funktion beschrieben werden. Vielleicht ließe sich die Path-Funktionalität von SVG hierzu gut verwenden. Allein: Sind das Dimensionen, die einen atmega hoffnungslos überfordern? Ist das vielleicht viel zu kompliziert gedacht von mir? Gibt es dafür schon gute Lösungen? Ich konnte leider nicht herausfinden, wie kommerzielle Hersteller zum Beispiel ihre Shows in den typischen Baumarkt-LED-Sets hinterlegen. Prinzipiell könnte ich das Problem natürlich auch mit Speicher totschlagen.
> Sind das Dimensionen, die einen atmega hoffnungslos überfordern? Nö, ist durchaus vorstellbar, dass das geht. Auf Kompression würde ich verzichten, weil es kompliziert ist und performancemäßig kritisch werden könnte. Viel Speicher ist hingegen leicht zu bekommen und auszulesen, zum Beispiel eine SD Karte. Dafür gibt's hier im Forum die avrfat Library, mit der ich auf Anhieb super zurecht kam (mit soft-SPI). http://www.mikrocontroller.net/articles/AVR_FAT32 http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten Versorge den AVR mit 3,3V, dann brauchst du keinen pegelwandler für die Datenleitungen zur SD Karte.
Einfacher als SD ist ein serieller Flash. z.B. die AT45DB Reihe. Man braucht für sowas ja nicht GB sondern da reichen meist 1-8 MB dick aus.
Die SD Karte kann man jedoch leicht mit einem CP befülllen. Bei dem seriellen Flash Speicher müsste man sich noch was einfallen lassen, wie die Daten da hinein kommen.
Stefan Us schrieb: > Die SD Karte kann man jedoch leicht mit einem CP befülllen. > Bei dem seriellen Flash Speicher müsste man sich noch was einfallen > lassen, wie die Daten da hinein kommen. Richtig, das ist ein klassischer Tradeoff für den ein Monetizing nicht gerantiert werden kann. Aber die Synergie aus einfacher Ansteuerung und Verzicht auf ein Dateisystem kann eine Win-Win Situation darstellen. Kommt natürlich auf die User-Story und das sonstige Ecosystem an.
> CP
Ich meine natürlich PC.
Du kannst auch bei SD Karten durchaus auf ein Filesystem verzichten und
sie Sektorweise beschreiben. Aber wozu, wir haben ja schon eine bewährte
Library?
Stefan Us schrieb: > Aber wozu, wir haben ja schon eine bewährte > Library? Schon richtig. Wollte nur eine Alternative aufzeigen und nicht gleich den Game-Changer machen.
Basti schrieb: > Ich könnte allerdings auch die Werte über eine Beschreibung speichern, > sodass diese zur Laufzeit berechnet werden müssten. Nach obigem Beispiel > gibt es 2^(24*240) mögliche Zustände der Lichtshow. Genau das dürften kommerzielle Lightshow-Adapter machen: Das Lichtprogramm ist als Algrorithmus hinterlegt, und beim Umschalten des Programms wird einfach auf einen anderen Algorithmus umgeschaltet. - Larson-Scanner - Lauflicht - Plasma - Rainbow und vieles andere mehr, mit ggf. verschiedenen Parametern abwandelbar. Dein Programm berechnet dann einfach aus dem aktuellen Lichtzustand anhand von Algorithmus und Parametern den nächsten Zustand, der nach wenigen Sekundenbruchteilen ausgerechnet ist und dann angezeigt wird.
Einfache pulte arbeiten mit "Bildern", also statischen Einstellungen, zwischen denen überblendet wird (Fading). Für 60sek Show sollte man nicht mehr als 100 verschiedene Bilder brauchen. 30FPS ergeben sich durch Interpolation. Reicht das nicht?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.