Hardware-Encoder für NeoPixel (WS2812)/Hardware - Versionsgeschichte

Hartmut am 22. April 2023 um 13:31 Uhr

2023-04-22T13:31:04Z

← Nächstältere Version		Version vom 22. April 2023, 13:31 Uhr
Zeile 45:		Zeile 45:

	[[Hardware-Encoder für NeoPixel (WS2812)\|Zurück zum Inhaltsverzeichnis]]		[[Hardware-Encoder für NeoPixel (WS2812)\|Zurück zum Inhaltsverzeichnis]]

			[[Kategorie:Projekt]]

Fki: Bild eingefügt, Links zu Hardwaremodulen gesetzt, Navigation hinzugefügt.

2017-05-09T19:55:00Z

Bild eingefügt, Links zu Hardwaremodulen gesetzt, Navigation hinzugefügt.

@@ Zeile 1: / Zeile 1: @@
 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.
@@ Zeile 22: / Zeile 24: @@
 == Infrastrukturmaßnahmen ==
 Strukturieren wir das Projekt also nach unseren neuesten Erkenntnissen um:
 * Das WS2812-Encodermodul bekommt ein Wishbone-Slave-Interface.
@@ Zeile 33: / Zeile 36: @@
 * Wir bauen einen kleinen Steuercontroller, der das Wishbone-Master-Interface steuert
 * Die seriellen Schnittstellen erhalten, wie das WS-Modul, ein Wishbone-Slave-Interface.

Fki: Text erweitert.

2017-05-09T18:49:35Z

Text erweitert.

← Nächstältere Version		Version vom 9. Mai 2017, 18:49 Uhr
Zeile 8:		Zeile 8:

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

			== Das Konfigurations-Interface ==
			Dinge ändern sich. Zum Beispiel die Timings von einer Version des WS2812 zur anderen. Oder dein FPGA-Board wird mit einem anderen Takt betrieben als meins. Lange Rede, kurzer Sinn: Wir wollen bestimmte Parameter einstellen können. Und dazu brauchen wir neben der reinen Datenverarbeitung ein Konfigurationsinterface.

			Das Konfigurationsinterface besteht aus Registern, der Hardware-Entsprechung zu Variablen in der Programmierung. Hier können wir Parameter hinterlegen, die die Datenverarbeitung steuern, z.B. die Anzahl der LEDs auf einem angeschlossenen Streifen oder die Dauer des Reset-Signals. In meinem aktuellen Entwurf habe ich 12 solcher Register vorgesehen. Es lohnt sich also, darüber nachzudenken, wie man den Zugriff auf diese Register regeln kann, ohne daß die Modulschnittstelle überfrachtet wird.

			Ein weiteres Thema ist Wiederverwendbarkeit. Dir passen die seriellen Schnittstellen nicht, du willst lieber ein paralleles Interface? Je nachdem, wie die Schnittstelle des Encoder-Moduls aussieht kann das simpel sein oder zu einem Schreikrampf führen. Ziel ist also eine möglichst einheitliche, übersichtliche Modulschnittstelle. Das führt uns zu Bussen.

			== Wir nehmen den Bus ==
			Ein Bus besteht aus Daten-, Adress-, und Steuerleitungen. Die Adresse legt fest, auf welches Register wir zugreifen wollen, die Daten sind die Daten, die wir schreiben oder lesen wollen und die Steuerleitungen sind dafür da, die Abläufe zu koordinieren.

			Es gibt eine ganze Menge verschiedenster Busse, parallele, serielle, schnelle für kurze Distanzen, langsamere für groß, whatever. Für uns interessant sind vor allem Busse, die sich dazu eignen, Systeme aus Modulen auf einem FPGA zusammenzuschalten. Da gibt es selbstverständlich auch mehrere, AXI oder AMBA zum Beispiel. Ich favorisiere in diesem Zusammenhang den [http://opencores.org/opencores,wishbone "Wishbone-Bus"], eine offene Busspezifikation, frei verwendbar und sehr leistungsfähig und flexibel.

			== Infrastrukturmaßnahmen ==
			Strukturieren wir das Projekt also nach unseren neuesten Erkenntnissen um:
			* Das WS2812-Encodermodul bekommt ein Wishbone-Slave-Interface.
			* Das Modul umfaßt die Buslogik, den VRAM und den eigentlichen Encoder

			Um die Daten von den seriellen Schnittstellen in den Encoder zu bekommen, müssen diese über ein Wishbone-Master-Interface verfügen. Hier könnten wir jetzt jeder Schnittstelle ein solches Interface verpassen oder ein kleines Hilfsmodul bauen, daß Daten von den Schnittstellen abholt und über den Wishbone-Bus an das WS2812-Modul überträgt. Diese Lösung hat darüber hinaus den Vorteil, daß es nur einen Master gibt. Gäbe es mehrere, müssten diese untereinander aushandeln, wer gerade übertragen darf. Diese zusätzliche Komplexität würde ich mir gerne schenken.

			Das Abholen der Daten von den externen Schnittstellen kann natürlich auch wieder per Wishbone erfolgen. Ein weiterer Vorteil dabei ist, daß man einfach Schnittstellen austauschen oder hinzufügen kann, in dem man sie an den Bus koppelt.

			Erweitern wir unsere Liste von oben also noch ein wenig:
			* Wir bauen einen kleinen Steuercontroller, der das Wishbone-Master-Interface steuert
			* Die seriellen Schnittstellen erhalten, wie das WS-Modul, ein Wishbone-Slave-Interface.

Fki: Bild getauscht.

2017-05-07T18:35:10Z

Bild getauscht.

← Nächstältere Version		Version vom 7. Mai 2017, 18:35 Uhr
Zeile 1:		Zeile 1:
	~~[[Datei:WS_Encoder_top.png\|right\|thumb]]~~

	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.		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 ==		== Der Weg der Daten ==
			[[Datei:WS_Encoder_grob.png\|right\|thumb]]
	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'''.		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'''.

Fki: Den Weg der Daten eingefügt.

2017-05-07T18:07:05Z

Den Weg der Daten eingefügt.

← Nächstältere Version		Version vom 7. Mai 2017, 18:07 Uhr
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~~.

Admin: 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

2017-04-04T22:40:59Z

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

← Nächstältere Version	Version vom 4. April 2017, 22:40 Uhr
(kein Unterschied)

Admin: Die Seite wurde neu angelegt: „== Wir werden konkret == 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-…“

2017-04-04T21:53:37Z

Die Seite wurde neu angelegt: „== Wir werden konkret == 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-…“

Neue Seite

== Wir werden konkret ==
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.

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.

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.

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.

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.