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?
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.
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
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 ?
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 AVRnicht 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.
