Hardware-Encoder für NeoPixel (WS2812)/Hardware: Unterschied zwischen den Versionen

Aus Hackerspace Bielefeld Wiki
Zur Navigation springen Zur Suche springen
K (Admin verschob die Seite Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware nach Hardware-Encoder für NeoPixel (WS2812)/Hardware, ohne dabei eine Weiterleitung anzulegen)
(Den Weg der Daten eingefügt.)
Zeile 1: Zeile 1:
== Wir werden konkret ==
[[Datei:WS_Encoder_top.png|right|thumb]]
Bevor wir loslegen können, müssen wir uns noch ein paar darüber machen, was unsere Schaltung tun und wie sie arbeiten soll. Da I/O-Pins an einem µController immer Mangelware sind, bieten sich für die Datenübertragung zu unserem Encoder serielle Schnittstellen an. Eigentlich immer vorhanden sind UARTs und SPI-Schnittstellen.  


SPI braucht zwar mehr Leitungen als ein UART, ist dafür aber schneller und man kann, sofern die restliche Schaltung das zulässt, mehrere Geräte an ein und derselben Schnittstelle betreiben. UART hat vor allem den Vorteil, daß praktisch jeder Microcontroller einen oder mehrere davon an Bord hat. Dazu kommt, daß sich die Schaltung auch an einem normalen PC oder Mac betreiben lässt. Falls dort keine echte Schnittstelle mehr vorhanden ist, kann man einfach einen USB-Adapter verwenden.
Unser Grobkonzept steht, jetzt geht es in die Details. Dazu machen wir uns zuerst Gedanken darüber, wie unser Encoder-System grundsätzlich arbeiten soll. Daraus ergeben sich erste Funktionsblöcke, die zur Gesamtschaltung verbunden werden. Bei Bedarf werden diese Blöcke noch weiter unterteilt, bis wir auf einem Level angekommen sind, daß wir gut beschreiben und '''testen''' können.


Da selbst kleine FPGAs (Spartan 6 LX 4 z.B.) mehr als genug Ressourcen für unser Projekt bieten, können wir einfach beide Schnittstellen implementieren.
== Der Weg der Daten ==
Beginnen wir bei den Eingabedaten und verfolgen ihre Verarbeitung. Im einfachsten Fall werden wir ein RGB-Farbtripel an den Encoder schicken, daß in das WS-Protokoll überführt und ausgegeben wird. Egal, welche unserer seriellen Schnittstellen wir benutzen, das übertragene Datum steht nach dem erfolgreichen Empfang in einem Register und kann parallel weiter verarbeitet werden. Unsere ersten Funktionsblöcke werden also einmal ein '''UART-Modul''' und ein '''SPI-Modul'''.


Die ankommenden Bytes könnten wir jetzt direkt in den Pixel-Encoder stecken. Allerdings müssen wir dann immer alle Daten neu übertragen und die zeitliche Entkopplung der Ausgabe an den Encoder ist auch nicht gegeben. Das können wir durch einen Pufferspeicher lösen. Wir benötigen für 512 LEDs je 3 Bytes, also 1,5KiB RAM.  
Damit die Datenübertragung zum Encoder die Ausgabe an die LEDs nicht beeinflusst, brauchen wir einen Pufferspeicher zur Entkopplung, in den die empfangenen Daten geschrieben werden. Wir benötigen also ein Modul, daß RAM implementiert und ansteuert, also einen '''VRAM-Controller'''.


Jetzt können wir die Daten per UART oder SPI in das RAM schreiben und der Encoder kann sie auslesen, wie es ihm passt, und sie zur Anzeige bringen. Sind wir fertig? Noch nicht ganz. Neben Zugriff auf den Speicher wäre es sinnvoll, verschiedene Einstellungen bei Bedarf anpassen zu können. Z.B. gibt es vom WS2812 zwei Varianten mit leicht abweichenden Timings. Dann kann es sein, daß deine Hardware eine andere ist, ein anderes FPGA, anderer Takt - kurzum: Wir wollen Zugriff auf Konfigurationsregister.
Aus diesem Video-RAM holt sich der eigentliche '''WS2812-Encoder''' die Daten, wandelt sie und gibt sie aus.
 
Damit wird die Sache noch ein bisschen komplexer: Wir müssen festlegen können, wann wir LED-Daten senden und wann wir auf ein Register zugreifen wollen, und auf welches. Wir brauchen ein Protokoll! Und einen Automaten, der es versteht. Also einen Protokoll-Interpreter.

Version vom 7. Mai 2017, 18:07 Uhr

Unser Grobkonzept steht, jetzt geht es in die Details. Dazu machen wir uns zuerst Gedanken darüber, wie unser Encoder-System grundsätzlich arbeiten soll. Daraus ergeben sich erste Funktionsblöcke, die zur Gesamtschaltung verbunden werden. Bei Bedarf werden diese Blöcke noch weiter unterteilt, bis wir auf einem Level angekommen sind, daß wir gut beschreiben und testen können.

Der Weg der Daten

Beginnen wir bei den Eingabedaten und verfolgen ihre Verarbeitung. Im einfachsten Fall werden wir ein RGB-Farbtripel an den Encoder schicken, daß in das WS-Protokoll überführt und ausgegeben wird. Egal, welche unserer seriellen Schnittstellen wir benutzen, das übertragene Datum steht nach dem erfolgreichen Empfang in einem Register und kann parallel weiter verarbeitet werden. Unsere ersten Funktionsblöcke werden also einmal ein UART-Modul und ein SPI-Modul.

Damit die Datenübertragung zum Encoder die Ausgabe an die LEDs nicht beeinflusst, brauchen wir einen Pufferspeicher zur Entkopplung, in den die empfangenen Daten geschrieben werden. Wir benötigen also ein Modul, daß RAM implementiert und ansteuert, also einen VRAM-Controller.

Aus diesem Video-RAM holt sich der eigentliche WS2812-Encoder die Daten, wandelt sie und gibt sie aus.

Abgerufen von „https://wiki.hackerspace-bielefeld.de/index.php?title=Hardware-Encoder_für_NeoPixel_(WS2812)/Hardware&oldid=451“