Hackerspace Bielefeld Wiki - Benutzerbeiträge [de]

Laufschrift Eingangstür

2018-05-23T16:24:52Z

Fki: /* Hardware */

== Ansprechpartner ==
[[Benutzer:Fki|Fki]]

== Beschreibung ==
Da die Leuchtdioden des Laufschrift-Panels über der Space-Eingangstür nur noch schwach und unterschiedlich hell glimmen, wird es Zeit für eine Überarbeitung. Bisher wurde lediglich ein statischer Schriftzug angezeigt, da der bisher zur Ansteuerung verwendete Arduino keine Verbindung zum Netzwerk im Hackerspace hatte. Dazu war er so verbaut, daß er nur schwer zugänglich war. Durch den Einsatz eines ESP8266-Moduls soll die neue Steuerung vom Netzwerk aus mit Anzeigedaten gefüttert werden können, ohne daß störende Kabel oder Teildemontagen der Wandverkleidung nötig sind. ;-)

== Hardware ==
* 3 Stk. LED-Matrix-Panel der Fa. Christ Elektronik, 32 x 12 LEDs, rot (Spende, sind älter, vermutlich aus Mitte der '90er Jahre).
* STM32F072 Discovery-Board zur Ansteuerung
* Eigenbau-Treiberplatine (Aufbau auf Punkt-Streifenraster)
* ESP8266-Modul (ESP-01) als WLAN-Bridge zur Verbindung mit und Ansteuerung aus dem Space-Netzwerk.

== Schaltung ==
=== Die LED-Matritzen ===
Herzstück des Projekts sind drei LED-Matritzen der Fa. Christ. Jede dieser Matritzen verfügt über 384 LEDs, welche in vier Gruppen organisiert sind. Die Gruppen teilen sich drei Schieberegister mit je 32 Ausgängen, welche die einzelnen LEDs innerhalb der gerade aktiven Gruppe schalten. Jede Gruppe besteht damit aus 96 LEDs. Die LED-Matritzen können einfach hintereinander gesteckt werden, so daß die gesamte Laufschrift aus 1152 LEDs besteht.

Die verwendeten Schieberegister sind vom Typ UCN5833. Eigentlich sind es Schieberegister mit Leistungstreibern und Datenlatch in einem Gehäuse. Man kann also Daten in die Register eintakten, ohne daß das Auswirkungen auf die Anzeige hat. Erst durch Aktivieren des Latches ändern sich die Ausgänge. Zur Ansteuerung der Schieberegister werden die Signale SCLK (Serial Clock), SDI (Serial Data In) und STB (Strobe) benötigt.

Dabei teilen sich alle Register die Clock- und Strobe-Leitung, die Datenleitungen jedes Registers sind separat herausgeführt. Werden an eine LED-Matrix weitere Matritzen angeschlossen, werden SCLK und STB einfach durchverbunden, die SDI-Leitungen der Folgeplatine werden mit den SDO-Pins (Serial Data Out) der vorhergehenden Platine verbunden (Daisy Chain). Bei drei hintereinander gesteckten Platinen versorgt der Mikrocontroller also pro Datenleitung 96 LEDs über drei verschaltete Schieberegister.

== Anleitung ==
In Arbeit.

=== Zugriff ===
In Arbeit.

=== Funktionen ===
In Arbeit.

[[Kategorie:Projekt]]

Laufschrift Eingangstür

2018-05-23T16:23:18Z

Fki: /* Schaltung */ Untergliederung nach Baugruppe eingeführt.

== Ansprechpartner ==
[[Benutzer:Fki|Fki]]

== Beschreibung ==
Da die Leuchtdioden des Laufschrift-Panels über der Space-Eingangstür nur noch schwach und unterschiedlich hell glimmen, wird es Zeit für eine Überarbeitung. Bisher wurde lediglich ein statischer Schriftzug angezeigt, da der bisher zur Ansteuerung verwendete Arduino keine Verbindung zum Netzwerk im Hackerspace hatte. Dazu war er so verbaut, daß er nur schwer zugänglich war. Durch den Einsatz eines ESP8266-Moduls soll die neue Steuerung vom Netzwerk aus mit Anzeigedaten gefüttert werden können, ohne daß störende Kabel oder Teildemontagen der Wandverkleidung nötig sind. ;-)

== Hardware ==
* 3 Stk. LED-Matrix-Panel der Fa. Christ Elektronik, 32 x 12 LEDs, rot (Spende, sind älter, vermutlich aus mitte '90er).
* STM32F072 Discovery-Board zur Ansteuerung
* Eigenbau-Treiberplatine (Aufbau auf Punkt-Streifenraster)
* ESP8266-Modul (ESP-01) als WLAN-Bridge zur Verbindung mit und Ansteuerung aus dem Space-Netzwerk.

== Schaltung ==
=== Die LED-Matritzen ===
Herzstück des Projekts sind drei LED-Matritzen der Fa. Christ. Jede dieser Matritzen verfügt über 384 LEDs, welche in vier Gruppen organisiert sind. Die Gruppen teilen sich drei Schieberegister mit je 32 Ausgängen, welche die einzelnen LEDs innerhalb der gerade aktiven Gruppe schalten. Jede Gruppe besteht damit aus 96 LEDs. Die LED-Matritzen können einfach hintereinander gesteckt werden, so daß die gesamte Laufschrift aus 1152 LEDs besteht.

Die verwendeten Schieberegister sind vom Typ UCN5833. Eigentlich sind es Schieberegister mit Leistungstreibern und Datenlatch in einem Gehäuse. Man kann also Daten in die Register eintakten, ohne daß das Auswirkungen auf die Anzeige hat. Erst durch Aktivieren des Latches ändern sich die Ausgänge. Zur Ansteuerung der Schieberegister werden die Signale SCLK (Serial Clock), SDI (Serial Data In) und STB (Strobe) benötigt.

Dabei teilen sich alle Register die Clock- und Strobe-Leitung, die Datenleitungen jedes Registers sind separat herausgeführt. Werden an eine LED-Matrix weitere Matritzen angeschlossen, werden SCLK und STB einfach durchverbunden, die SDI-Leitungen der Folgeplatine werden mit den SDO-Pins (Serial Data Out) der vorhergehenden Platine verbunden (Daisy Chain). Bei drei hintereinander gesteckten Platinen versorgt der Mikrocontroller also pro Datenleitung 96 LEDs über drei verschaltete Schieberegister.

== Anleitung ==
In Arbeit.

=== Zugriff ===
In Arbeit.

=== Funktionen ===
In Arbeit.

[[Kategorie:Projekt]]

Laufschrift Eingangstür

2018-05-18T14:48:39Z

Fki: Text zur Schaltung erweitert.

== Ansprechpartner ==
[[Benutzer:Fki|Fki]]

== Beschreibung ==
Da die Leuchtdioden des Laufschrift-Panels über der Space-Eingangstür nur noch schwach und unterschiedlich hell glimmen, wird es Zeit für eine Überarbeitung. Bisher wurde lediglich ein statischer Schriftzug angezeigt, da der bisher zur Ansteuerung verwendete Arduino keine Verbindung zum Netzwerk im Hackerspace hatte. Dazu war er so verbaut, daß er nur schwer zugänglich war. Durch den Einsatz eines ESP8266-Moduls soll die neue Steuerung vom Netzwerk aus mit Anzeigedaten gefüttert werden können, ohne daß störende Kabel oder Teildemontagen der Wandverkleidung nötig sind. ;-)

== Hardware ==
* 3 Stk. LED-Matrix-Panel der Fa. Christ Elektronik, 32 x 12 LEDs, rot (Spende, sind älter, vermutlich aus mitte '90er).
* STM32F072 Discovery-Board zur Ansteuerung
* Eigenbau-Treiberplatine (Aufbau auf Punkt-Streifenraster)
* ESP8266-Modul (ESP-01) als WLAN-Bridge zur Verbindung mit und Ansteuerung aus dem Space-Netzwerk.

== Schaltung ==
Herzstück des Projekts sind drei LED-Matritzen der Fa. Christ. Jede dieser Matritzen verfügt über 384 LEDs, welche in vier Gruppen organisiert sind. Die Gruppen teilen sich drei Schieberegister mit je 32 Ausgängen, welche die einzelnen LEDs innerhalb der gerade aktiven Gruppe schalten. Jede Gruppe besteht damit aus 96 LEDs. Die LED-Matritzen können einfach hintereinander gesteckt werden, so daß die gesamte Laufschrift aus 1152 LEDs besteht.

Die verwendeten Schieberegister sind vom Typ UCN5833. Eigentlich sind es Schieberegister mit Leistungstreibern und Datenlatch in einem Gehäuse. Man kann also Daten in die Register eintakten, ohne daß das Auswirkungen auf die Anzeige hat. Erst durch Aktivieren des Latches ändern sich die Ausgänge. Zur Ansteuerung der Schieberegister werden die Signale SCLK (Serial Clock), SDI (Serial Data In) und STB (Strobe) benötigt.

Dabei teilen sich alle Register die Clock- und Strobe-Leitung, die Datenleitungen jedes Registers sind separat herausgeführt. Werden an eine LED-Matrix weitere Matritzen angeschlossen, werden SCLK und STB einfach durchverbunden, die SDI-Leitungen der Folgeplatine werden mit den SDO-Pins (Serial Data Out) der vorhergehenden Platine verbunden (Daisy Chain). Bei drei hintereinander gesteckten Platinen versorgt der Mikrocontroller also pro Datenleitung 96 LEDs über drei verschaltete Schieberegister.

== Anleitung ==
In Arbeit.

=== Zugriff ===
In Arbeit.

=== Funktionen ===
In Arbeit.

[[Kategorie:Projekt]]

Laufschrift Eingangstür

2018-05-18T11:44:50Z

Fki: Erste Beschreibung und verwendete Hardware hinzugefügt.

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

2017-05-09T19:55:00Z

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

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

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 ==
[[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'''.

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.

== 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 ==
[[Datei:WS_Encoder_WB.png|right|thumb]]
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.

== Die Komponenten im Detail ==
Da die Besprechung der einzelnen Blöcke umfangreich wird, habe ich entsprechende Unterseiten eingerichtet:
* Zum [[/Wishbone|Wishbone-Bus ->]]
* Zum [[/SPI|SPI-Modul ->]]
* Zum [[/UART|UART-Modul ->]]
* Zum [[/WS_Encoder|WS2812-Encoder ->]]

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

Datei:WS Encoder WB.png

2017-05-09T19:38:37Z

Fki:

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

2017-05-09T19:00:06Z

Fki: Navigation am Seitenende eingefügt

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir schreiben einen WS2812-Encoder-Modul, statten es mit einem UART und einer SPI-Schnittstelle aus und verbinden das Ganze über einen kleinen Steuerautomaten. Daraus erzeugen wir eine Konfiguration für ein FPGA und sind fertig. Soweit die Theorie...

[[Datei:WS_Encoder_top.png|right|thumb]]

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken?

'''Nachteile von Softwarelösungen:'''
* Die Timings des WS-Protokolls sind sehr eng und dadurch schwierig auf einem Mikrocontroller einzuhalten.
* Wegen der Timings können keine Interrupts während der Ausgabe auf die LEDs benutzt werden.
* Hardware-Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. zu langsam (durch Overhead).

'''Vorteile der Hardwarelösung:'''
* Das Protokoll ist nicht sehr kompliziert, dadurch hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertige Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle und damit ca. 17 m bzw 8,5 m gesamtlänge der Streifen.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

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

2017-05-09T18:49:35Z

Fki: Text erweitert.

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 ==
[[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'''.

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.

== 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.

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

2017-05-07T18:35:10Z

Fki: Bild getauscht.

Datei:WS Encoder grob.png

2017-05-07T18:33:07Z

Fki: Grobe Blockstruktur des Encoders. Eigene Arbeit.

Grobe Blockstruktur des Encoders. Eigene Arbeit.

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

2017-05-07T18:07:05Z

Fki: Den Weg der Daten eingefügt.

[[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.

== 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.

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

2017-05-07T16:49:50Z

Fki: /* Das Grobkonzept */

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

2017-05-07T16:48:38Z

Fki: Bild eingefügt

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir schreiben einen WS2812-Encoder-Modul, statten es mit einem UART und einer SPI-Schnittstelle aus und verbinden das Ganze über einen kleinen Steuerautomaten. Daraus erzeugen wir eine Konfiguration für ein FPGA und sind fertig.

[[Datei:WS_Encoder_top.png|right|thumb]]

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken?

'''Nachteile von Softwarelösungen:'''
* Die Timings des WS-Protokolls sind sehr eng und dadurch schwierig auf einem Mikrocontroller einzuhalten.
* Wegen der Timings können keine Interrupts während der Ausgabe auf die LEDs benutzt werden.
* Hardware-Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. zu langsam (durch Overhead).

'''Vorteile der Hardwarelösung:'''
* Das Protokoll ist nicht sehr kompliziert, dadurch hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertige Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle und damit ca. 17 m bzw 8,5 m gesamtlänge der Streifen.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

Datei:WS Encoder top.png

2017-05-07T16:44:50Z

Fki: Eigene Arbeit.

Eigene Arbeit.

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

2017-05-07T16:42:48Z

Fki: Kleinere Textüberarbeitungen

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir schreiben einen WS2812-Encoder-Modul, statten es mit einem UART und einer SPI-Schnittstelle aus und verbinden das Ganze über einen kleinen Steuerautomaten. Daraus erzeugen wir eine Konfiguration für ein FPGA und sind fertig.

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken?

Nachteile von Softwarelösungen:
* Die Timings des WS-Protokolls sind sehr eng und dadurch schwierig auf einem Mikrocontroller einzuhalten.
* Wegen der Timings können keine Interrupts während der Ausgabe auf die LEDs benutzt werden.
* Hardware-Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. zu langsam (durch Overhead).

Vorteile der Hardwarelösung:
* Das Protokoll ist nicht sehr kompliziert, dadurch hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertige Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle und damit ca. 17 m bzw 8,5 m gesamtlänge der Streifen.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

Hardware-Encoder für NeoPixel (WS2812)

2017-05-07T16:15:20Z

Fki:

[[Kategorie:Projekt]]

Dieses Projekt ist in seiner Entstehung begriffen und wird mit der Zeit erweitert! Bei Fragen oder Anregungen bitte auf meiner [[Benutzer Diskussion:Fki|Diskussionsseite]] melden!

== Projektbeschreibung ==
Ziel dieses Projektes ist es, eine Schaltung in VHDL für einen WS2812(b) Encoder zu erstellen. Das Protokoll der WS2812-Controller ist relativ einfach, stellt jedoch einige Anforderungen an das Timing und ist daher schwierig auf Mikrocontrollern zu implementieren.

Der Grundgedanke ist nun, den zeitkritischen Codiervorgang auf ein FPGA auszulagern und den Zugriff darauf über verbreitete Schnittstellen nach Außen zur Verfügung zu stellen. Da bieten sich serielle Schnittstellen wie UART oder SPI an, parallele Schnittstellen sind ebenfalls möglich, brauchen aber mehr IO-Ports am Controller.

== [[/Einleitung|Einleitung]] ==
Hier geht es um Vorüberlegungen zu dem Hardware-Encoder. Taktraten, Timings und die Codierung des WS2812 werden betrachtet.

== [[/Hardware|Hardware]] ==
In diesem Abschnitt geht es um die zu beschreibende Hardware, Features, Schnittstellen und Blockdiagramme. Unterkapitel widmen sich den einzelnen Schaltungsblöcken im Detail.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/UART|UART]] ===
Dieses Kapitel ist der seriellen asynchronen Kommunikation gewidmet. Hier geht es um das Protokoll sowie die Implementierung eines entsprechenden Schnittstellenmoduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/SPI|SPI]] ===
Im Gegensatz zum UART befassen wir uns hier mit synchroner Datenübertragung und der Implementierung des passenden Moduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/VRAM|VRAM]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/LED-Encoder|LED-Encoder]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/Steuerung|Ablaufsteuerung]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/BUI|Bussteuerung]] ===

== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Protokoll|Protokoll und Software]] ==

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

2017-05-07T16:14:12Z

Fki:

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir nehmen einen FPGA, statten ihn mit einem UART und einer SPI-Schnittstelle aus, basteln einen Transmitter für das WS2812-Protokoll und hängen das Ganze mit einem kleinen Steuerautomaten aneinander.

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken? Aus mehreren Gründen:
* Das Protokoll ist nicht sehr kompliziert, also hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Das Timing des Protokolls mit seinen 800kHz Bit-Takt ist schon wieder so eng, daß grade in kleineren µControllern, wie den ATMegas, ein sehr hoher Aufwand betrieben werden muss, um die Timings einzuhalten.
* Das bedeutet häufig, daß Interrupts abgeschaltet werden müssen.
* Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. haben zu viel Overhead.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertigste Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

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

2017-05-07T16:13:18Z

Fki:

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir nehmen einen FPGA, statten ihn mit einem UART und einer SPI-Schnittstelle aus, basteln einen Transmitter für das WS2812-Protokoll und hängen das Ganze mit einem kleinen Steuerautomaten aneinander.

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken? Aus mehreren Gründen:
* Das Protokoll ist nicht sehr kompliziert, also hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Das Timing des Protokolls mit seinen 800kHz Bit-Takt ist schon wieder so eng, daß grade in kleineren µControllern, wie den ATMegas, ein sehr hoher Aufwand betrieben werden muss, um die Timings einzuhalten.
* Das bedeutet häufig, daß Interrupts abgeschaltet werden müssen.
* Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. haben zu viel Overhead.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertigste Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

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

2017-05-07T16:12:27Z

Fki:

[[Hardware-Encoder für NeoPixel (WS2812)|Zurück zum Inhaltsverzeichnis]] | [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware| Weiter zu Hardware ->]]

== Das Grobkonzept ==
Wir nehmen einen FPGA, statten ihn mit einem UART und einer SPI-Schnittstelle aus, basteln einen Transmitter für das WS2812-Protokoll und hängen das Ganze mit einem kleinen Steuerautomaten aneinander.

=== Wofür das Ganze? ===
Wozu nun dieser Aufwand, es gibt doch bereits fertige Software-Bibliotheken? Aus mehreren Gründen:
* Das Protokoll ist nicht sehr kompliziert, also hat man ein relativ gut durchschaubares Beispiel für die Beschäftigung mit VHDL.
* Das Timing des Protokolls mit seinen 800kHz Bit-Takt ist schon wieder so eng, daß grade in kleineren µControllern, wie den ATMegas, ein sehr hoher Aufwand betrieben werden muss, um die Timings einzuhalten.
* Das bedeutet häufig, daß Interrupts abgeschaltet werden müssen.
* Timer mit entsprechenden Routinen sind bereits zu ungenau bzw. haben zu viel Overhead.
* Die Verwendung von Hardware-Schnittstellen wie SPI oder UART kann Interrupt-gesteuert ablaufen.
* Je nach Controller auch unter Verwendung von DMA.
* Die Entkopplung der LEDs vom Host ermöglicht, alles als Host zu benutzen, was eine serielle Schnittstelle hat: PCs, Raspberry Pi usw.

== Der LED-Controller ==
Wie arbeitet dieser ominöse WS2812 jetzt eigentlich? Der WS2812 steuert eine RGB-LED an und zwar mit 8 Bit pro Farbe bzw. 24 Bit Farbtiefe pro LED. Die Reihenfolge der Farbbytes unterscheidet sich dabei vom gewohnten RGB: Die LEDs erwarten ein GRB-Format, also erst das Byte für Grün, dann Rot und zum Schluss Blau. Das höchstwertigste Bit wird zuerst übertragen.

Wenn mehrere NeoPixel hintereinander geschaltet werden, übernimmt der Controller der ersten LED in der Kette die ersten 24 Bit in sein Farbregister, alle weiteren Bits gibt er über seinen Datenausgang an den nächsten Pixel weiter. Angezeigt werden die Farben jedoch erst nach einem RESET-Signal.

[[Datei:WS2812_Timing.png|right|thumb]]
Das Übertragungsprotokoll sieht so aus: Ein Bit wird innerhalb von 1,25µs übertragen. Innerhalb dieser Zeit geht die Signalleitung für eine gewisse Zeit auf High- und anschließend auf Low-Pegel. Für ein "1"-Bit sind es 0,8µs High und 0,45µS Low, für ein "0"-Bit 0,4µs High und 0,85µs Low. Pro Phase sind bis zu 0,15µs Abweichung erlaubt. Liegt die Signalleitung für mehr als 50µs auf Low, wird das als Reset-Signal interpretiert und die übertragenen Farbwerte werden angezeigt.

Hier gibt es das ausführliche Datenblatt[https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf].

=== Takte, Timings, LEDs ===
Ein paar Eckdaten sind noch zu klären:
* Wie viele LEDs kann ich (sinnvoll) hintereinander schalten?
* Wie knapp sind die Timings wirklich?

Rechnen wir mal ein bisschen:
* Für flüssig erscheinende Animationen brauchen wir mindestens 24 Bilder/Sekunde. Dabei flackert es aber noch sichtbar.
* Moderne Computermonitore arbeiten mit 60 Bildern/Sekunde.

In Anlehnung an Monitore werde ich auch hier von FPS (Frames Per Second - Bilder pro Sekunde) sprechen, wenn ich vollständige Übertragungszyklen zu den NeoPixeln meine, auch wenn das vielleicht nicht ganz korrekt ist.

Die erste Frage können wir damit schon mal beantworten: Technisch gesehen können wir beliebig viele LEDs hintereinander schalten, je mehr es werden, desto niedriger wird unsere Bildrate. Interessant ist also vielmehr, wie viele LEDs bei 30 oder 60 FPS hintereinander gehängt werden können. Betrachten wir das Ganze einmal für 60 FPS:

* Wir haben für einen Durchlauf 1/60s Zeit, also 16,7ms.
* Um einen Pixel mit 24 Bit zu übertragen, brauchen wir 24 * 1,25µs = 30µs.
* Pro Durchlauf kommt noch ein Reset mit 50µs dazu.

In eine Formel gegossen könnte das so aussehen:
* T_FRAME = x * T_LED + T_RESET.
Dabei ist x die gesuchte Anzahl der LEDs, T_LED = 30µs und T_RESET = 50µs. T_FRAME = 16,7ms ist die Zeitspanne für einen Durchlauf. Umgestellt nach x erhalten wir:
* x = (T_FRAME - T_RESET) / T_LED
Mit eingesetzten Werten:
* (16700µs - 50µs) / 30µs = 555 LEDs
Die nächstkleinere Zweierpotenz wären 512 LEDs. Halten wir also fest: Mit 512 LEDs erreichen wir unsere 60 FPS, 1024 LEDs können wir immer noch mit 30 FPS ansteuern. Zum Vergleich: Die gängigen LED-Streifen auf Rolle haben 30 oder 60 LEDs / Meter, das wären dann 150 bzw. 300 LEDs pro 5m-Rolle.

==== Bleiben noch die Timings ====
Wie knapp wird es denn jetzt wirklich? Nehmen wir als Beispiel einen ATMega mit 20 MHz Takt, wie er von den Arduinos bekannt ist. Diese Mikrocontroller benötigen für die meisten Befehle einen Takt, für Sprünge zwei.

* Bei 20 MHz dauert ein Takt 1 / 20.000.000 Hz = 0,000.000.050 s oder 50 ns.
* Die kürzeste Schaltdauer sind 400 ns (T0H).
* Diese Zeitspanne entspricht 400 ns / 50 ns = 8 Takten (+-3 Takte Toleranz).
* Ein ganzes Bit entspricht 25 Takten.

Das ist unter Einsatz von taktoptimiertem Assemblercode gerade noch machbar. Wenn wir mit höheren Takten arbeiten können, entspannt sich die ganze Situation ein wenig, allerdings nicht in einem Maße, als daß es uns von handoptimiertem Code erlösen würde.

20MHz 40MHz 60MHz 80MHz 100Mhz
T1H 16 32 48 64 80
T1L 9 18 27 36 45
T0H 8 16 24 32 40
T0L 17 34 51 68 85
'''Sequenz 25 50 75 100 125'''
RST 1000 2000 3000 4000 5000

Hardware-Encoder für NeoPixel (WS2812)

2017-05-07T16:11:28Z

Fki: Projektbeschreibung verändert

[[Kategorie:Projekt]]

Dieses Projekt ist in seiner Entstehung begriffen und wird mit der Zeit erweitert! Bei Fragen oder Anregungen bitte auf meiner [[Benutzer Diskussion:Fki|Diskussionsseite]] melden!

== Projektbeschreibung ==
Ziel dieses Projektes ist es, eine Schaltung in VHDL für einen WS2812(b) Encoder zu erstellen. Das Protokoll der WS2812-Controller ist relativ einfach, stellt jedoch einige Anforderungen an das Timing und ist daher schwierig auf Mikrocontrollern zu implementieren.

Der Grundgedanke ist nun, den zeitkritischen Codiervorgang auf ein FPGA auszulagern und den Zugriff darauf über verbreitete Schnittstellen nach Außen zur Verfügung zu stellen. Da bieten sich serielle Schnittstellen wie UART oder SPI an, parallele Schnittstellen sind ebenfalls möglich, brauchen aber mehr IO-Ports am Controller.

== [[/Einleitung|Einleitung]] ==
Hier geht es um Vorüberlegungen zu dem Hardware-Encoder. Taktraten, Timings und die Codierung des WS2812 werden betrachtet.

== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware|Hardware]] ==
In diesem Abschnitt geht es um die zu beschreibende Hardware, Features, Schnittstellen und Blockdiagramme. Unterkapitel widmen sich den einzelnen Schaltungsblöcken im Detail.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/UART|UART]] ===
Dieses Kapitel ist der seriellen asynchronen Kommunikation gewidmet. Hier geht es um das Protokoll sowie die Implementierung eines entsprechenden Schnittstellenmoduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/SPI|SPI]] ===
Im Gegensatz zum UART befassen wir uns hier mit synchroner Datenübertragung und der Implementierung des passenden Moduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/VRAM|VRAM]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/LED-Encoder|LED-Encoder]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/Steuerung|Ablaufsteuerung]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/BUI|Bussteuerung]] ===

== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Protokoll|Protokoll und Software]] ==

Hardware-Encoder für NeoPixel (WS2812)

2017-05-07T16:05:37Z

Fki: /* Einleitung */

[[Kategorie:Projekt]]

Dieses Projekt ist in seiner Entstehung begriffen und wird mit der Zeit erweitert! Bei Fragen oder Anregungen bitte auf meiner [[Benutzer Diskussion:Fki|Diskussionsseite]] melden!

== Projektbeschreibung ==
Ziel dieses Projektes ist es, eine Schaltungsbeschreibung in VHDL für einen WS2812(b) Encoder zu erstellen. Das Protokoll der WS2812-Controller ist relativ einfach, stellt jedoch einige Anforderungen an das Timing und ist daher hakelig auf Mikrocontrollern, gerade kleineren, zu implementieren.

Der Grundgedanke ist nun, eine gut unterstützte Schnittstelle an einem beliebigen Mikrocontroller zu nutzen, z.B. UART oder SPI, um die Daten zu den Konverter zu schicken, der dann den passenden Datenstrom an die NeoPixel schickt.

== [[/Einleitung|Einleitung]] ==
Hier geht es um Vorüberlegungen zu dem Hardware-Encoder. Taktraten, Timings und die Codierung des WS2812 werden betrachtet.

== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware|Hardware]] ==
In diesem Abschnitt geht es um die zu beschreibende Hardware, Features, Schnittstellen und Blockdiagramme. Unterkapitel widmen sich den einzelnen Schaltungsblöcken im Detail.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/UART|UART]] ===
Dieses Kapitel ist der seriellen asynchronen Kommunikation gewidmet. Hier geht es um das Protokoll sowie die Implementierung eines entsprechenden Schnittstellenmoduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/SPI|SPI]] ===
Im Gegensatz zum UART befassen wir uns hier mit synchroner Datenübertragung und der Implementierung des passenden Moduls.

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/VRAM|VRAM]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/LED-Encoder|LED-Encoder]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/Steuerung|Ablaufsteuerung]] ===

=== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Hardware/BUI|Bussteuerung]] ===

== [[Projekt:Hardware-Encoder für NeoPixel (WS2812)/Protokoll|Protokoll und Software]] ==