forked from hacknology/website
Neopixelar project report updated (#38)
Neopixelar project report updated Co-authored-by: kaqu <kaqu@hacknology.de> Reviewed-on: hacknology/website#38kuppel
parent
e7055712b9
commit
5005e1a2eb
Binary file not shown.
Binary file not shown.
After Width: | Height: | Size: 922 KiB |
Binary file not shown.
Binary file not shown.
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
After Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
After Width: | Height: | Size: 629 KiB |
Binary file not shown.
After Width: | Height: | Size: 1.4 MiB |
|
@ -5,7 +5,7 @@ status: Aktiv
|
|||
difficulty: Ja ...
|
||||
time: ~1d
|
||||
date: 2020-10-29
|
||||
image: Neopixelar_Overview.jpg
|
||||
image: Neopixelar_Overview.png
|
||||
keywords: FPGA, RISC-V, Neopixel, Litex, migen, colorlight-5a-75b
|
||||
---
|
||||
|
||||
|
@ -25,7 +25,7 @@ als preiswerte Möglichkeit (~18€ !) der Umsetzung (siehe hierzu auch diesen
|
|||
|
||||
Hiermit könnte man gleichzeitig etwas über FPGAs und RISC-V lernen. Na denn ...
|
||||
|
||||
{{< image alt="Showtime" src="Neopixelar_Overview.jpg" >}}
|
||||
{{< image alt="Showtime" src="Neopixelar_Overview.png" >}}
|
||||
|
||||
## 1. Zum Aufwärmen
|
||||
|
||||
|
@ -403,21 +403,59 @@ RAM-Bank. Da das Projekt eine Netzwerkanbindung (mit Terminal-Umleitung) umfasst
|
|||
direkt in den RAM-Bereich geladen werden (mit dem Wishbone-Tool) und dann dort direkt gestartet werden.
|
||||
Da macht das Entwickeln wieder Spaß!
|
||||
|
||||
Das komplette Projekt steht als [Git Repository](https://git.hacknology.de/projekte/Neopixelar) zur Verfügung.
|
||||
## 4. NEU: Board-Umbau Ausgänge zu Eingängen
|
||||
|
||||
## 4. Fazit
|
||||
Vor einiger Zeit haben wir mal testweise einen Ausgangstreiber 74HC245 (U28) auf Eingänge (per Richtungsumschaltung, s.u.)
|
||||
umgebaut - ok, nerdyscout hat es umgelötet, ich bin ja eher Grobmotoriker ...
|
||||
|
||||
<div class="pure-g">
|
||||
{{< image alt="Umbauplanung" src="Umbauplanung.jpg" size="640x480 q90" class="pure-u-1 pure-u-md-1-2" >}}
|
||||
{{< image alt="UmbauAusfuehrung" src="Umbauausfuehrung.jpg" size="640x480 q90" class="pure-u-1 pure-u-md-1-2" >}}
|
||||
</div>
|
||||
|
||||
Damit können dann sechs 3.3(!) V Eingänge auf J1 und zwei auf J2 genutzt werden. Alternativ geht das gleiche
|
||||
z.Bsp. mit U15 (auf J8 bzw. J7).
|
||||
Wolfgang hat in der Zwischenzeit 74CBT3245 'bus switches' besorgt. Demnächst könnte dann (ohne externe Richtungsumschaltung)
|
||||
jeder I/O-Pin je nach (FPGA-)Konfiguration dynamisch genutzt werden ...
|
||||
|
||||
## 5. NEU: DRAM DMA
|
||||
|
||||
Auf einem kleineren FPGA - wie im vorliegenden Fall - ist jede Resource kostbar. Der 'Mißbrauch' als Speicherablageort
|
||||
für LED-Daten kann jedoch (weitgehend) umgangen werden, wenn man als Ablageort den Hauptspeicher nutzen könnte ...
|
||||
In migen gibt es bereits FIFOs, in LiteX das LiteDRAM Modul inkl. DMA transfer, da sollte doch was gehen!
|
||||
|
||||
Ich habe also eine kleine 'programmierbare' Transfereinheit gebaut, die es ermöglicht, für jede LED-Kette einen
|
||||
Ablageort im DRAM zuzuweisen. Die diversen Speicherbereiche (bis zu 63 St.) werden nach Freigabe automatisch
|
||||
abgearbeitet.
|
||||
Interessanter vielleicht: Das eigentliche Applikationsprogramm kann sich nach dem Zuweisen der LED-Daten-Bereiche
|
||||
komplett anderen Aufgaben widmen - das FPGA holt sich seine Daten per DMA direkt aus dem DRAM.
|
||||
Bei Bedarf kann man die LED-Daten im DRAM vom Applikationsprogramm aus direkt überschreiben, sie finden dann den
|
||||
Weg zum FPGA von alleine ...
|
||||
|
||||
{{< image alt="DRAM DMA Transfer" src="DRAMDMA.png" >}}
|
||||
|
||||
Tatsächlich werden erstaunliche Größenordnungen an LEDs ansprechbar, jedoch trübt der enorme Zeitbedarf
|
||||
bei mehr als ca. 1500 (!) LEDs die Euphorie etwas (dann: nix 'Echtzeit'!) - vom Stromverbrauch gar nicht zu reden ...
|
||||
|
||||
## 6. Fazit
|
||||
|
||||
Zunächst gilt es, eine steile Lernkurve zu überwinden, ab hier - z.B. mit diesem Projekt als Vorlage -
|
||||
geht's dann aber leicht bergab (um im Bilde zu bleiben 😉).
|
||||
|
||||
Tatsächlich bin ich mangels passender Hinweise bzw. unvollständiger Dokumentation (es gilt vor allem 'Use the source, Luke!') etliche Irrwege (einige dutzend Stunden) gegangen. Auch schadet es nicht, noch einmal die gcc/as/ld/objdump/readelf Aufrufparameter bzw. Konfigurationsdateistruktur durchzuarbeiten (speziell: RISC-V Toolchain).
|
||||
Tatsächlich bin ich mangels passender Hinweise bzw. unvollständiger Dokumentation (es gilt vor allem
|
||||
'Use the source, Luke!') etliche Irrwege (einige dutzend Stunden) gegangen. Auch schadet es nicht,
|
||||
noch einmal die gcc/as/ld/objdump/readelf Aufrufparameter bzw. Konfigurationsdateistruktur
|
||||
durchzuarbeiten (speziell: RISC-V Toolchain).
|
||||
|
||||
## 5. Ausblick
|
||||
Das komplette Projekt steht als [Git Repository](https://git.hacknology.de/projekte/Neopixelar) auf unserem
|
||||
Server zur Verfügung.
|
||||
|
||||
## 7. Ausblick
|
||||
|
||||
Was steht noch aus?
|
||||
|
||||
1. Eine NeoPixel Bibliothek mit vorgefertigten Beleuchtungsfunktionen müsste noch erstellt werden.
|
||||
2. H/W-Umbau einiger Treiber-Bausteine auf bi-directional um auch Eingänge nutzen zu können, z.B. mit I2S (vorgefertigte
|
||||
2. H/W-Umbau einiger Treiber-Bausteine auf bi-directional um wahlweise Eingänge nutzen zu können, z.B. mit I2S (vorgefertigte
|
||||
passende Logik gibt's bereits ...).
|
||||
|
||||
Und was ist jetzt mit dem RISC-V Thema? Nun, das wird wohl eine andere Geschichte ...
|
||||
|
|
Loading…
Reference in New Issue