Go Down

Topic: testbericht zum WS2812 (Read 32 times) previous topic - next topic

uwefed

#60
Feb 26, 2013, 09:51 pm Last Edit: Feb 26, 2013, 10:03 pm by uwefed Reason: 1

Ich hab noch immer keine WS bestellt :(

Aber: die Bibliothek kann doch Ports initialisieren, hat das jetzt schon mal jemand *getestet*?

Code: [Select]

  FastSPI_LED.setPin(PIN);
    FastSPI_LED.init();
  FastSPI_LED.start();


initialisiert das Ganze, also kann der PIN übergeben werden
Was passiert, wenn man im Sketch mit

Code: [Select]
FatsSPI_LED.stop();

das ganze beendet und auf einem anderen Port neu initialisiert??

Eventuell noch mit verschiedenen Längen diese anpassen (FastSPI_LED.setLeds).

Das einzige Problem könnte die Verzögerung sein, die dann zwischen den Strängen entsteht, aber ist das ein Problem?

Und @Til: Wenn du deine Beleuchtung zonenabhängig machst, willst du dann die LED einzeln ansprechen können? Ansonsten könnte man ja auch Stränge parallel betreiben?

Dirk


Es ist kein Unterschied ob 3x2400Byte an einen Ausgang verschickt oder diese nacheinander in Teilen an verschiedene Pins. Die Zeit um für 2400 LED die Daten zu senden bleibt fast gleich (die Stückweise Sendung ist etwas langsamer, da das Umschalten und Initialisieren auch Zeit braucht).
Wenn wir jetzt die 2400 LED so gruppieren, daß bei Farbwechseln nur eine Gruppe beteiligt ist, dann ist die Wiederholrate natürlich größer und der Übergang weicher. 

Die Ansteuerung der WS2811/12 ist sehr zeitkritisch. Da muß man schon gute Assembler / Maschienensprachekenntnisse haben und das Innenleben des Kontrollers kennen Um das Programm zu schreiben. Ich traue es mir das zB nicht zu.
Die Ansteuerung zB des WS2801 (in einem Anderen aktuellen Tread) ist weniger Zeitkritisch da die Daten mit eimen Takt übergeben werden und die max mögliche Frequenz größer ist.

Wie bereits Vorgeschlagen würde ich einen Teensy3.0 nehmen (da dort bereits Beispiele gibt) oder die LED in Gruppen aufteilen und jeweils von einen ATmega328 oder ATmega2560 ansteuern lassen. Das Programm wird von einem zentralen "Server" übergeben. Da könnte jeder ATmega 328 ca 150 LED ansprechen da so der Speicher für 2 bis 3 Datensätze ausreichend ist und die Wiederholrate bei Farbüberläufen genügend hoch ist. Man muß Zeit für die Datenübertragung und auch die Zeit für die Berechnung der neuen Werte berücksichtigen.

Grüße Uwe

uwefed


Nein, genau das eben nicht.
Das Timing muss passen, die Daten müssen an die Kette im 125us-pro-Bit-Rhytmus, ohne Pause bis zum Reset (anzeigen).
...
Dirk


Der WS 2811/12 hat eine Zykluszeit von 1,25µS pro Bit im Fast-Modus; der WS2811 auch eine Zykluszeit von 2,5µS im slow Modus.

Grüße Uwe

dischneider

Ups, da ist mir das Komma verloren gegangen, Uwe entgeht mal wieder nichts.
War ein Test :)


Es ist kein Unterschied ob 3x2400Byte an einen Ausgang verschickt oder diese nacheinander in Teilen an verschiedene Pins. Die Zeit um für 2400 LED die Daten zu senden bleibt fast gleich ( die stückweise sendung ist etwas langsamer da das umschalten und initialisieren auch Zeit braucht.
Wenn wir jetzt die 2400 LEd so gruppieren, daß bei Farbwechseln nur eine Gruppe beteiligt ist, dann ist die Wiederholrate natürlich größer und der Übergang weicher.


Das war mir klar, es ging eher um die Möglichkeit einzelne Stränge definiert anzusprechen, um ggf. statische Stränge gar nicht ansprechen zu müssen.

Danke für die Fehlerkorrektur.

Dirk
using arduino leonardo
--
tomorrow today will only be yesterday, so live your life today!

Eisebaer

hi,

Quote
wieso 16MHz?
Der DUE rennt doch mit 84MHz?
genuegend Zeit die Pins zu wechseln, und wieder zurueckzuschalten, oder?


Du hast keine library für den DUE !!!

bei der library für den teensy gibt es kein umschalten.

außerdem war das nur ein beispiel, um Dir zu erklären, wie die WS2811 arbeiten und welche zeitprobleme es gibt. auf das umschalten bin ich nirgends eingegangen. was das umschalten bringen könnte, wäre, speicherplatz zu sparen. dafür hat man auch nirgends den istzustand gespeichert. muß aber auch nicht unbedingt sein.

ansonsten kommt es darauf an, was man mit den LEDs zeigen will.
langsame farbübergänge sind mit dem teensy möglich, aber um als beispiel ein knight-rider-licht einmal um den raum laufen zu lassen, geht eben nicht. bei diesem beispiel wird jede led innerhalb nicht mal einer sekunde von 0 auf 100% und wieder zurück gesetzt. das geht nicht in vertretbaren schritten mit 2400 LEDs, die von einer zentralen stelle gesteuert werden, egal ob das ein UNO, ein DUE oder ein cray-supercomputer ist.

ich sehe nicht viele möglichkeiten. mit einem UNO kannst Du, sagen wir mal, 500 LEDs steuern, dann geht Dir der speicher bald aus. also jeder raumteil mit zwei UNOs, aber dann wird die programmierung für ein solches knightrider-licht in einem solchen raumteil sehr unkomfortabel.

oder ein ATmega1284P für jeden raumteil, gesteuert von einem zentralen uno, am besten mit ethenet-shield, dann kannst Du alles vom handy/tablet/computer aus steuern

gruß stefan

Eisebaer

hi,

Quote
die LED in Gruppen aufteilen und jeweils von einen ATmega328 oder ATmega2560 ansteuern lassen. Das Programm wird von einem zentralen "Server" übergeben. Da könnte jeder ATmega 328 ca 150 LED ansprechen da so der Speicher für 2 bis 3 Datensätze ausreichend ist


vernünftige aussage.
nur die 150 seh' ich als zu niedrig an. jede rgbLED braucht 3 Byte, also sollten 400 doch leicht machbar sein. ein ATmega1284P mit 16k speicher für 800 LEDs geht sicher. und mit 800 LEDs hat man eine wiederholrate von sagen wir mal 30fpS, weil rechnen will der microconroller ja auch.

gruß stefan

Go Up