Hallo Wir möchten zu Testzwecken ein Led Display mit den Außmaßen 100x150cm aufbauen mit mind. 50 pixel/meter Es sollte wie erwähnt vorerst nur ein Testaufbau sein, um zu prüfen ob der Effekt so herüber kommt wie gedacht. zur wahl stehen bislang: - ein aufbau mit LED Stripes z.B. GEH60RGB2812BC ->60 pixel/m - ein aufbau mit Modulen 16x16 z.B. auf Aliexpress ->100 pixel/m Auf dem Display sollen nachher Animationen laufen. Hat hier jemand bereits Erfahrung damit?
Zu Displays aus WS2812 LED Streifen finden sich genug Beispielprojekte im Internet. Was ist nun die spezielle Frage?
Mw E. schrieb: > Was ist nun die spezielle Frage? Er will natürlich ein fertige Wichsvorlage sowohl für die Hardware als auch für die Software. So, wie das heute scheinbar üblich ist. Er wird aber an dem Projekt scheitern, selbst wenn er die komplette Dokumentation und Software bekommen würde. Möglicherweise schon beim Bezahlen der Rechnung für die Bauteile, spätestens aber bei der Inbetriebnahme. Da braucht man nicht prophetisch begabt sein, um das prognostizieren zu können. Allein die Fragestellung klärt das schon hinreichend. So ist dem Typen offensichtlich nicht mal klar, dass er bei einfachen LED-Stripes nicht jede LED einzeln ansteuern kann. Eindeutig ein VBW.
Samuel schrieb: > Wir möchten zu Testzwecken ein Led Display mit den Außmaßen 100x150cm > aufbauen mit mind. 50 pixel/meter Das sind aber mit WS2812 und 60LED/m = 90 * 60 = 5400 RGB LEDs. Ergibt 16200 Bytes pro Frame, einzeln rausgeschickt dauert es 48.6ms. Rausschicken mit 8 Pins gleichzeitig dauert nur 6.075ms, aber um die ganze Byte- und Bitschieberei fertigzukriegen, bedarf es mindestens einen ARM.
Marc V. schrieb: > Das sind aber mit WS2812 und 60LED/m = 90 * 60 = 5400 RGB LEDs. > Ergibt 16200 Bytes pro Frame, einzeln rausgeschickt dauert es > 48.6ms. > Rausschicken mit 8 Pins gleichzeitig dauert nur 6.075ms Bis hierhin korrekt gerechnet. > aber um die > ganze Byte- und Bitschieberei fertigzukriegen, bedarf es mindestens > einen ARM. Dann aber doch als Lamer geoutet. Nö, das ginge noch recht locker mit einem AVR (sogar in C, wenn man's denn wenigstens einigermassen beherscht, was ja die meisten nicht tun, die in C "programmieren"). Für Animationen werden üblicherweise 30fps als völlig ausreichend betrachtet. D.h: für jedes Frame stehen 33,33..ms zur Verfügung, für einen mit 20MHz betriebenen AVR also satte 6,6 Millionen Instruktionen pro Frame oder 22222 Instruktionen pro Frame und LED. Das ist ein Witz. Nur Programmierern, deren Fähigkeiten sich im Zusammensetzen von anderen vorgefertigter Programmstücke erschöpfen, treibt das ernsthaft den Schweiss auf die Stirn...
c-hater schrieb: > Er will natürlich ein fertige Wichsvorlage sowohl für die Hardware als > auch für die Software. Ich mag ihn und mich :-) Spruch notiert!
c-hater schrieb: > Marc V. schrieb: > >> Das sind aber mit WS2812 und 60LED/m = 90 * 60 = 5400 RGB LEDs. >> Ergibt 16200 Bytes pro Frame, einzeln rausgeschickt dauert es >> 48.6ms. >> Rausschicken mit 8 Pins gleichzeitig dauert nur 6.075ms > > Bis hierhin korrekt gerechnet. Bin zu faul das zu überprüfen. > >> aber um die >> ganze Byte- und Bitschieberei fertigzukriegen, bedarf es mindestens >> einen ARM. > > Dann aber doch als Lamer geoutet. Nö, das ginge noch recht locker mit > einem AVR (sogar in C, wenn man's denn wenigstens einigermassen > beherscht, was ja die meisten nicht tun, die in C "programmieren"). Naja, mind. einen arm braucht man schon, mit hand und fingern dran zum coden, sonst dauert es ewig. > > Für Animationen werden üblicherweise 30fps als völlig ausreichend > betrachtet. War nicht mal was mit knappen 20 fps? Zumindest beim Film/Animationsfilm war es wohl bei 18 fps, um es als "laufbild" zu sehen.
c-hater schrieb: > Für Animationen werden üblicherweise 30fps als völlig ausreichend > betrachtet. D.h: für jedes Frame stehen 33,33..ms zur Verfügung, für > einen mit 20MHz betriebenen AVR also satte 6,6 Millionen Instruktionen > pro Frame oder 22222 Instruktionen pro Frame und LED. Verdammt, Tippfehler im Taschenrechner. Faktor 10 daneben. Es sind 666666 und 2222. Rest bleibt aber wahr.
18 fps gabs bei Super 8. In der Projektion waren es aber 3 x 18 Bilder (Flügelblende).
c-hater schrieb: > Verdammt, Tippfehler im Taschenrechner. Faktor 10 daneben. Es sind > 666666 und 2222. Rest bleibt aber wahr. Verdammt, auch bei mir Tippfehler. Es sind nicht 48.6ms sondern 162ms wenn einzeln gesendet wird und 20.25ms wenn im 8-er Block gesendet wird. c-hater schrieb: > Das ist ein Witz. Nur Programmierern, deren Fähigkeiten sich im > Zusammensetzen von anderen vorgefertigter Programmstücke erschöpfen, > treibt das ernsthaft den Schweiss auf die Stirn... Das hatten wir doch schon... Animation heisst, dass bestehende Werte in bestimmter Weise verändert werden. Um irgendeinen Wert zu verändern, muss dieser Wert irgendwo stehen. Das man bei einem AVR irgendwo 16200 Bytes reinschreiben kann, wage ich zu bezweifeln. Ausser bei XMEGAs aber selbst da spricht Preis/Leistungsverhältnis eindeutig für ARM. Und selbst wenn, um die RGB-Werte auf acht Kanälen gleichzeitig auszugeben, müssen die ursprünglichen RGB-Werte mit einem Byte-Offset von (Breite * 3) und bit-Offset von n+1 in einen Byte reingeschoben werden. 90LEDs x 3RGB x 8 Reihen = 2160 Bytes die abzuarbeiten sind. Da diese Bytes aber auf 8 Reihen gleichzeitig ausgegeben werden braucht man nur 2160/8 = 270 Bytes auf einmal ausgeben. 270 Bytes x 10us ergibt 2.7ms. Das muss 8 Mal wiederholt werden. 8 x 2.7ms ergibt eine Framezeit von 21.6ms. > Für Animationen werden üblicherweise 30fps als völlig ausreichend > betrachtet. D.h: für jedes Frame stehen 33,33..ms zur Verfügung, für Fall a) - WS2812 per Bitbanging - CPU Auslastung = 100% 33.33ms - 21.6ms = 11.9ms / 50ns(fur 20MHz) = 234,600 Cycles. 234,600Cy / 16200 = 14Cy pro Byte. Und jetzt sieht man warum deine Rechnung nicht stimmt - es bleiben max. 14Cy fur die ganze Rechnerei. In diesen 14 Cy muss altes Wert geladen werden, Animation bzw. neues Wert berechnet werden und dieses Wert wieder zuruckgeladen werden. Damit man nicht beim rausschicken umrechnen muss, wird mit Byteversetzten bitwerten gerechnet, da geht jedem AVR schon längst die Puste aus... Fall b) - WS2812 per SPI - CPU Auslastung = 80% 21.6ms x 80% = 17.28ms 33.33ms - 17.28ms = 16.05ms / 50ns(fur 20MHz) = 321,000 Cycles. 321,000Cy / 16200 = 20Cy pro Byte. Sieht auch nicht viel besser aus, schafft man nichtmal mit XMEGA und DMA. c-hater schrieb: > Dann aber doch als Lamer geoutet. Nö, das ginge noch recht locker mit > einem AVR (sogar in C, wenn man's denn wenigstens einigermassen > beherscht, was ja die meisten nicht tun, die in C "programmieren"). Wohl doch nicht. c-hater schrieb: > Er wird aber an dem Projekt scheitern, selbst wenn er die komplette > Dokumentation und Software bekommen würde. Möglicherweise schon beim > > Da braucht man nicht prophetisch begabt sein, um das prognostizieren zu > können. Allein die Fragestellung klärt das schon hinreichend. So ist dem Agree.
18fps schrieb: > 18 fps gabs bei Super 8. > In der Projektion waren es aber 3 x 18 Bilder (Flügelblende). Die Flügelblende ist aber nur gegen das Flimmern, es bleibt trotzdem bei 18 Bildwechseln (Frames) pro Sekunde.
c-hater schrieb: > So ist dem > Typen offensichtlich nicht mal klar, dass er bei einfachen LED-Stripes > nicht jede LED einzeln ansteuern kann. Da sieht man mal, was passiert, wenn ein "hater" unreflektiert postet. Der Typ des Stripes stand dabei. Hättest du den mal bei Google eingegeben, wäre dir sofort aufgefallen, dass man bei diesem sehr wohl die LEDs einzeln ansteuern kann. In Anbetracht solch eines Fauxpas solltest du dir vielleicht angewöhnen, in Zunkunft nicht ganz so überheblich zu sein.
Marc V. schrieb: > Fall b) - WS2812 per SPI - CPU Auslastung = 80% LOL. Da war ich wohl etwas müde um die Zeit... Mit SPI kann man gar keine 8 Kanäle parallel ausgeben.
Hallo, c-hater schrieb: > Verdammt, Tippfehler im Taschenrechner. Faktor 10 daneben. Es sind > 666666 und 2222. Rest bleibt aber wahr. Kurze Gegenprobe: Wenn wirklich 2222 Befehle pro LED und Frame zur Verfügung stehen würden, müsste dein AVR mit 2222 Zyklen * 5400 LED * 30 fps = 360 MHz getaktet sein... Es stehen beim AVR pro LED inkl. Ausgabe nur 20 MHz / 5400 LED / 30 fps = 124 Zyklen zur Verfügung. Da die ATMegas nur eine SPI haben, müsste Bit-Banging gemacht werden, und da stehen dann genau 5 Zyklen pro Bit zur Verfügung. Mit optimiertem Code eventuell möglich, aber nur, wenn ein statisches Bild ausgegeben werden soll (da keine Rechenleistung mehr zum Ändern des Bildinhaltes vorhanden ist). Dann braucht es aber auch keine 30 fps. Mit einem XMega mit 4 SPI könnte man es hinbekommen - allerdings sind das dann auch keine "klassischen" AVR und man könnte genauso gut einen ARM nehmen, mit dem Vorteil gleich auch genug Speicher zu bekommen. Schöne Grüße, Martin
Hi Samuel, angenommen, ja, es gibt hier Leute, welche die Gesamtanforderungen (Hardware/Firmware) Deines Projektes verstehen und umsetzen können. Was möchtest Du haben? Was brauchst Du? Grüße, marcus
:
Bearbeitet durch User
Angehängte Dateien:
-
hqdefault.jpg
15 KB
Hallo Samuel(Gast) Schreib doch bitte, WAS es werden soll... StromTuner
Marc V. schrieb: > Animation heisst, dass bestehende Werte in bestimmter Weise verändert > werden. Um irgendeinen Wert zu verändern, muss dieser Wert irgendwo > stehen. Das man bei einem AVR irgendwo 16200 Bytes reinschreiben kann, > wage ich zu bezweifeln. Also erstmal: 5200*3 sind 15600 (das habe ich einfach mal im Kopf gerechnet, da konnte kein Tippfehler im Taschenrechner passieren ;o). > Ausser bei XMEGAs Mega1284P hat 16384 Bytes RAM. Würde also völlig ausreichen. Allerdings: Es ist überhaupt nicht nötig, dass die zu verändernden Daten im RAM des µC stehen, insbesondere dann nicht wenn sie ohnehin ständig geändert werden sollen. Das wäre sogar ziemlich unsinnig... > Fall a) - WS2812 per Bitbanging - CPU Auslastung = 100% Unsinn. Um acht Kanäle auszugeben, braucht man erstmal nur eine einzige Operation, nämlich ein out Port, DataHolderRegister pro "Schritt". Wobei ein "Schritt" hier dem 3- oder 4-fachen der WS281x-Bitrate entspräche, also mit ca. 2,4..3,2Mhz erfolgen muss. Natürlich muss das "DataHolderRegister" auch immer wieder aktualisiert werden, sonst macht diese Ausgabe natürlich absolut keinen Sinn. Aber die Diskussion des Pollingbetriebs verschiebe ich mal auf weiter unten, zuerst möchte ich noch eine Sache aus deinem Posting kommentieren, die zwar mit dem konkreten Problem nix zu tun hat, aber trotzdem der Erwiderung bedarf. > Fall b) - WS2812 per SPI - CPU Auslastung = 80% Das ist natürlich völliger Schwachsinn. Ich selber habe hier bereits eine funtionierende Implementierung gepostet, deren CPU-Last <45% ist. Siehe: Beitrag "The secret of WS2812B" BlinkingLights_FunctionDemo.zip Der Code enthält eine vollständige Dokumentation des Laufzeitverhaltens. Der Code kann eine komplette WS281x-Kette mit 1024 LEDs bei ca. 33Hz Framerate (kürzere Ketten mit entprechend höherer Framerate) treiben und ist so geschrieben, dass er nicht nur auf einen Framebuffer verzichten kann (weil genug Rechenzeit bleibt, um Effekte live zu berechnen) sondern obendrein darauf optimiert, möglichst viel "sonstiges" in einer konkreten Anwendung möglich zu machen, insbesondere auch interruptgetriebenes Zeug. Man beachte: Der Demo-Code braucht zwar für die live-Berechnung des Effekts schon grosse Teile der Rechenzeit, er ist aber auch für einen ATtiny gedacht. Auf einem Mega (mit HW-Multiplikation) läßt der gleiche Code sehr, sehr viel mehr Rechenzeit für eine zusätzliche echte Anwendung über. ... Aber klar, alles soweit ganz schick, reicht aber performancemäßig für die vom OP angestrebte Anwendung natürlich nicht aus. Wir haben eben nur eine oder maximal zwei SPI-fähige UARTs in einem klassischen AVR8. Also: Verzicht auf die Universalität des Codes, Verzicht auf Interrupts zur "Schachtelung" der Codepfade ist erstmal zwingend. Wir sind also bei einer auf die spezielle Anwendung optimierten Busy-Loop und müssen den Code "von Hand" in der (ziemlich sicher recht weit "unrolled") Schleife schachteln. Die Lösung habe ich aber oben schon angedeutet und sie übernimmt prinzipiell die Grundidee meines SPI-Codes, nämlich: man braucht KEINEN Framebuffer, wenn man programmieren kann. Für die konkrete Anwendung wäre also die Lösung: Laß' doch den PC den ganzen Quatsch liefern, wenn er sowieso 30mal in der Sekunde was anderes will. Es läuft also darauf hinaus, dass der µC-Code nur die eigentliche Ausgabe inclusive deren Timing und die Encodierung der RGB-Daten in das serielle Format der WS281x erledigt. Und natürlich den (möglichst grosszügig gepufferten) Datentransfer vom PC. Ein Job für einen Mega1284P, denn der bietet 16k Bufferspeicher. Da darf sich dann auch mal die datenliefernde Anwendung ein Weile in die Abgründe der Multitasking-Waitqueue eines OS verziehen. Hauptsache, sie schafft es wenigstens im Mittel, die Daten hinreichend schnell zu liefern. Nachdem man so das Konzept für eine derartige Anwendung erstmal sinnvoll erarbeitet hat, DANN kann man anfangen, zu rechnen, ob es möglich ist. Im konkreten Fall bietet der bestehende Code der von mir bereits ziemlich gut optimierten SPI-Lösung einen guten Ansatzpunkt zur Abschätzung der Möglichkeiten, da man vielfach die darin enthaltene Timing-Doku direkt verwenden kann und dadurch nicht mehr sehr viel rumrechnen muss. Die Ausgabe eines Color-Triple auf einer WS281x-Line dauert 576 Takte. Das entspricht 72 Ausgaben (bei der gewählten und offensichtlich auch funktionierenden Encodierung mit 3 Bits pro Payload-Bit), wenn man es per Bitbanging erledigen muss. Pro Ausgabe stehen dann also 8 Takte zur Verfügung und nur einer davon wird für die eigentliche Ausgabe benötigt, es bleiben also 7 pro Ausgabe über bzw. 504 pro Color-Triple. Die Encodierung der RGB-Daten für ein RGB-Triple auf das Ausgabeformat erfordert 59 Takte. Wir brauchen aber gleichzeitig 5 WS281x-Buslines, also auch 5 Triples, um die insgesamt geforderte Anzahl LEDs erreichen zu können. Sind wir also bei 295 Takte für diesen Job, bleiben 504-295=209 Takte für "sonstiges", denn die eigentliche Ausgabe ist damit ja bereits weitgehend abgegessen! (Natürlich kann man dabei die Beschleunigungstabellen des Beispielcodes nicht direkt verwenden, sie müssten natürlich sinngemäß angepasst werden, was eine Vergrösserung um den Faktor 8 bedeuten würde, was für die 128k Flash eines 1284P aber absolut kein Problem darstellen und nebenbei auch noch einige der 59 Takte der Vorlage einsparen würde). Aber rechnen wir mal mit den 209 pro 576 Takten der Vorlage (immerhin ca. 36% der vefügbaren Rechenzeit) weiter und überlegen, was in diesen eigentlich noch passieren muss. Das ist nämlich nicht mehr sehr viel. Nur die Verwaltung eines Doublebuffer-Systems und das Einlesen von der Quelle in den gerade "freien" Buffer. Ersteres ist leicht abzuhandeln, am rechenzeitsparendsten mit eine Statemachine und soviel (leicht verschiedenen) Exemplaren des Ausgabecodes, wie diese Statemachine States besitzt. Letzteres ist allerdings der einzige ernsthafte Knackpunkt der gesamten Sache. Wie kriege ich nämlich einen Durchsatz von 5200*3*30 = 468000Bytes/s = 3,7MBit/s vom PC in den AVR und das verschachtelt mit dem Ausgabecode? Könnte nur mit einer Sache übherhaupt klappen: paralleler 8Bit-Transfer (also z.B. ein "LPT" als Quelle). In Ermangelung einer solchen Schnittstelle habe ich es mir gespart, die oben beschriebenen Ansätze in konkreten Code zu überführen. Ich würde statt dessen einfach 5x Tiny2313A nehmen, wenn es mein Problem und nicht das des TO wäre. Im Verhältnis zu den LEDs und deren Stromversorgung fallen 5 Tinys nämlich ganz sicher überhaupt nicht in's Gewicht. Und dann könnte ich ganz entspannt den bestehenden Code verwenden. In 321 Takten kann ich nämlich ganz locker Transfer und DoubleBuffering für einen Durchsatz von dann nur noch 1/5 der genannten Werte realisieren. Das ist sehr viel einfacher, als das, was der Demo-Code macht, um den Effekt zu berechnen. Und modular für spätere Erweiterungen ist es auch noch...
c-hater schrieb: > Also erstmal: 5200*3 sind 15600 (das habe ich einfach mal im Kopf > gerechnet, da konnte kein Tippfehler im Taschenrechner passieren ;o). Nein, aber 60 * 90 = 5400 * 3 = 15600 c-hater schrieb: > Das ist natürlich völliger Schwachsinn. Ich selber habe hier bereits > eine funtionierende Implementierung gepostet, deren CPU-Last <45% ist. Uninteressant, mit SPI müssen 60 * 90 = 5400 LEDs * 3Byt nacheinander ausgegeben werden, das sind 15600 Bytes * 10us = 156ms pro Frame. Wenn dir das ausreicht, OK... Und jetzt nochmal ganz langsam die 8-bit Ausgabe, da du offensichtlich Schwierigkeiten mit verstehen hast: Marc V. schrieb: > 90LEDs x 3RGB x 8 Reihen = 2160 Bytes die abzuarbeiten sind. > Da diese Bytes aber auf 8 Reihen gleichzeitig ausgegeben werden braucht > man nur 2160/8 = 270 Bytes auf einmal ausgeben. > 270 Bytes x 10us ergibt 2.7ms. Das muss 8 Mal wiederholt werden. > 8 x 2.7ms ergibt eine Framezeit von 21.6ms. Wahrend diese Zeit kann der uC nichts anderes tun, zumindest nichts sinnvolles, es ist fur mich eine 100%-ige Auslastung. Also, sind wir wieder am Anfang: Marc V. schrieb: > 33.33ms - 21.6ms = 11.9ms / 50ns(fur 20MHz) = 234,600 Cycles. > 234,600Cy / 16200 = 14Cy pro Byte. Da die Bytes die ausgegeben worden sind, schon vorbereitet waren, stimmt die Rechnung bis jetzt. Aber: Marc V. schrieb: > In diesen 14 Cy muss altes Wert geladen werden, Animation bzw. neues > Wert berechnet werden und dieses Wert wieder zuruckgeladen werden. > Damit man nicht beim rausschicken umrechnen muss, wird mit > Byteversetzten bitwerten gerechnet, da geht jedem AVR schon längst > die Puste aus... Ist dir das Ganze jetzt ein bisschen klarer ?
:
Bearbeitet durch User
Marc V. schrieb: > Ist dir das Ganze jetzt ein bisschen klarer ? Ja, ich sehe, dass du nichtmal die Grundidee (Verzicht auf den für die Anwendung überflüssigen Framebuffer) begreifst, geschweige denn die positiven Konsequenzen, die sich daraus ergeben. Ich sehe weiter, das dir das Konzept von parallel laufenden Codesträngen in einem Code mit dem Zweck der Nutzung möglichst wirklich jeden Taktes bei gleichzeitiger Einhaltung der timing constraints der Anwendung völlig fremd ist. Was für einen C-only-Lamer allerdings nicht ungewöhnlich ist. Es ist also wohl völlig sinnlos, weiter mit dir darüber zu diskutieren.
c-hater schrieb: > Ja, ich sehe, dass du nichtmal die Grundidee (Verzicht auf den für die > Anwendung überflüssigen Framebuffer) begreifst, geschweige denn die > positiven Konsequenzen, die sich daraus ergeben. Und ich sehe, dass du wieder mal mit idiotischen Vorschlägen direkt an der Sache vorbeiredest. Deine Lösung: Flexibles Led Display mit M1284P und ohne Framebuffer, alles auf einem PC platzsparend montiert - nur wie man diesen Framebuffer vom PC zum AVR rüberkriegt ist dir noch nicht ganz klar... Ohne Framebuffer gibt es ganz einfach keine Animation. Punkt. Und dieser Framebuffer kann auf einem AVR nicht bearbeitet werden. Punkt. Es sei denn, du verstehst unter Animation wildes Blinken, zufälliges aufleuchten von LEDs, Knightrider, Farbüberblendungen und solchen Kinderkram. c-hater schrieb: > Ich sehe weiter, das dir das Konzept von parallel laufenden Codesträngen > in einem Code mit dem Zweck der Nutzung möglichst wirklich jeden Taktes > bei gleichzeitiger Einhaltung der timing constraints der Anwendung > völlig fremd ist. Was für einen C-only-Lamer allerdings nicht > ungewöhnlich ist. Mit möglichst vielen Worten und viel Anglizismus nichts gescheites zu sagen, scheint deine Spezialität zu sein. Leider ist das hier keine politische Rede auf dem Dorf wo so etwas durchgehen mag, sondern ein uC Forum und solche Sätze sollte man nicht leichtsinnig durch die Gegend schmeissen - es könnte sein, dass dich jemand auffordert, deinen obigen Satz etwas ausführlicher zu erklären. c-hater schrieb: > Es ist also wohl völlig sinnlos, weiter mit dir darüber zu diskutieren. Natürlich, für eine Diskussion braucht man Argumente und du hast keine. Mit dir kann man höchstens eine Polemik führen, aber dazu ist mir meine Zeit zu schade.
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.