hallo zusammen!
Mir fällt kein besserer Betreff ein. Es geht um folgendes: ich
experimentiere mit einem TFT mit 24 bit rgb Interface. Das funktioniert
auch wie gewünscht. Derzeit wird ein Testbild ausgegeben welches anhand
von Pixelzählern und hsync/vsync Timings generiert wird.
Was ich nun möchte ist es mit den Schaltern meines eval Boards
verschiedene Farbquellen auszuwählen. d.h. ich kann ein festes Testbild
jetzt schon generieren. Dann möchte ich sicher einen Framebuffer
anzeigen, einen Textgenerator, einen Framebuffer im externen RAM, double
buffered Framebuffer, ein Signal vom A/D Wandler, klassisches Pong.....
Jetzt soll das Alte aber nicht weggeworfen werden sondern das Design
soll wachsen.
Wenn ich mit 8 Schaltern aus maximal 8 entities auswählen möchte, die
irgendwie Pixelwerte ausspucken bin ich mir unsicher wie ich das am
besten mache. Ich bin bei FPGA ein Neuling, bezüglich Digitalschaltungen
habe ich grundkenntnisse, daher bitte ich um Hilfe.
Mir würde einfallen:
- Das TFT Interface bekommt die Pixeldaten aus einem Multiplexer der
dann im Extremfall ein 8x1 mux ist. Nur bei 24 bit Farbtiefe stelle ich
mir einen Mux als Monster vor. Jedenfalls wenn ich mir das als 74er
Platine vorstelle.
- Alle Entities die Pixeldaten ausspucken bekommen ein enable Signal
welches ich aus den Schaltern erzeuge. Könnte ich dann auch theoretisch
2 entities gleichzeitig aktivieren? Intern währen die Komponenten ja an
Signale angeschlossen. Dürfen dann mehrere quellen gleichzeitig ihre
Daten auf das Signal schreiben?
- Die Entities als eine Art Bus schalten? Aber so weit ich es verstanden
habe geht es innerhalb des FPGA nicht tri-state Buffer zu machen um die
Quellen zu trennen
- ??? Ja wie gehe ich mein Problem an?
Ich werde an dem Projekt sicher noch lange spielen. Einmal zum lernen,
einmal wegen Zeitmangel. Darum soll es zum einen möglichst nicht zu
unsinnig angegangen werden und außerdem weiß ja jeder dass man sich
einmal falsch eingeprägtes sehr schwer abschütteln kann....
Ich danke euch!
Multiplexer ist das einfachste und erfüllt deine Anforderung. Nicht in
Gattergräbern denken. Auf dem FPGA sind das 3 bis 6 LUTs, die da
draufgehen. Von 50.000 die dir z.B. zur Verfügung stehen... Die anderen
Lösungen erzeugen nicht weniger Logik.
Christian F schrieb:> Wenn ich mit 8 Schaltern aus maximal 8 entities auswählen möchte
Mein Tipp: lass das. Das ist kindische Spielerei: das behalten, was man
schon hat, und noch mehr dazubekommen.
Du kämpfst so immer mit alten, unerfahrenen Beschreibungen herum und
traust dich nicht, mal was komplett Neues und Anderes auszuprobieren.
BTW: zur Auswahl von 8 Quellen auf 1 Ziel braucht man nur 3 Schalter. Du
musst dir das Hardware-Denken noch antrainieren...
Christian F schrieb:> Darum soll es zum einen möglichst nicht zu unsinnig angegangen werden
Mach für jedes Design ein neues Projekt und kopiere das, was von einem
Alten Design brauchbar ist, ins neue hinein.
Nur so wirst du dich und deinen Beschreibungsstil weiterentwickeln. Ich
habe z.B. gut 1000 kleine und große Designs abgelegt und kann da immer
wieder mal schauen, ob sich irgendwas mit der Toolchain getan hat.
Für mich wäre es im obigen Fall jetzt angenehmer je Verhalten ein bit
vorzusehen. Wenn ich meine Phantasie spielen lasse und als Pixelquelle
verschiedene simple Videospiele ala Pong annehme dann ist das doch
schöner.
Aber,ja, ihr habt grundsätzlich sicher Recht damit lieber zeitig einen
cut zu wagen, als alles krampfhaft mit zu schleppen.
Bei dem Projekt ist das Gerüst aber ja quasi erst mal die TFT
Ansteuerung - ohne dass mir einer da Fehler zeigt, wüsste ich auch nicht
was ich beim Neustart anders machen würde....
hm. Nun aber grundsätzlich wäre, allgemein gesehen, der richtige Weg die
einzelnen Daten zu multiplexen?
Schaue Dir bitte nochmal Deine Liste an:
> ... ein festes Testbild jetzt schon generieren. Dann möchte ich> sicher einen Framebuffer anzeigen, einen Textgenerator, einen> Framebuffer im externen RAM, double buffered Framebuffer,> ein Signal vom A/D Wandler, klassisches Pong.....
und nimm einmal an, Dein Problem sei nicht eines der Signalumschaltung
sondern des "Systemdesigns".
Die Liste ist von diesem Standpunkt aus sehr heterogen - sie nennt
Elemente die in einer Reihe von denkbaren Gesamtsystemen sehr
unterschiedliche Stellungen einnehmen.
- Ein "Framebuffer" und ein "Framebuffer mit externem RAM" sind
strukturell eine Teileinheit eines Systems in dem Bilder angezeigt aber
nicht notwendigerweise "erzeugt" werden. Ausserdem ist die Bezeichnung
"Framebuffer" generischer als "Framebuffer mit externem RAM". Analoges
gilt für die Beziehung zwischen "Framebuffer" und "double buffered
Framebuffer".
- Hingegen sind "Framebuffer mit externem RAM" und "double buffered
Framebuffer" sozusagen "orthogonale" Begriffe. Sie beziehen sich nicht
unmittelbar aufeinander. Es mag beides in Kombination vorliegen oder
auch nicht.
- Ein "Textgenerator" ist weder mit den verschiedenen
"Framebuffer"-Varianten vergleichbar noch mit einem "A/D-Wandler" noch
mit "Pong". Er wandelt lediglich einen ASCII-Code in eine Menge von
Pixeln um.
Insofern wäre er, je nach Systemdesign (da ist er, der Begriff) eine
Teilstruktur eines Pong-Spiels (für die Spielstand-Anzeige) oder eines
"A/D-Wandler" (für die Messwert-Anzeige).
Vielmehr ist der "Textgenerator" vergleichbar mit den ungenannten
Teilstrukturen, die aus A/D-Wandlungsergebnissen eine Grafik erzeugen
oder aus X-Y-Position der Bälle und Schläger das Bild dieser Elemente im
Spielkontext.
Möglicherweise ist Dir nun schon klar, worauf ich hinaus will. Ein
"Umschalter" oder Multiplexer ist zwar eine für den Anfänger
naheliegende abstrakte Möglichkeit, dass Problem in einem ersten Schritt
zu beschreiben. Aber es passt im Detail dann doch nicht wirklich so,
dass man ein ökonomisches Design daraus machen kann. Würde man so
nämlich fortschreiten, hättest Du ein Pong-Spiel, einen A/D-Wandler,
eine Textanzeige usw. die in sich komplett sind und bei denen am Ende
über einen Multiplexer nur noch das Videosignal ausgewählt wird.
Nun stammt der Vorschlag eines "Multiplexers" nicht von Dir; Du wirst
Dich demnach mit Recht missverstanden fühlen können. Es geht mir aber
nicht so sehr darum, dass lediglich der Multiplexer ein unpassendes
Detail ist, sondern darum, Dich dazu zu bringen, Dir das Gesamtsystem
vorzustellen.
Ich könnte Dir da jetzt mal eine Skizze machen, möchte das jedoch
(vorerst) nicht tun. Vielleicht magst Du das ja mal versuchen. Es wird
zwar nicht 100%ig hinhauen, aber "aus Fehlern lernt man" - "am meisten"
könnte man hinzufügen.
Ein Ansatzpunkt sollten die oben erwähnten Bemerkungen zu den
Unterschieden zwischen den genannten Einheiten in Bezug auf Ihre
Funktion sein.
Ich hoffe das Dir das hilft, wenn es auch keine simple Antwort ist.
Hm. Doch also ich hatte ursprünglich schon an einen Multiplexer gedacht
der rgb Werte aus völlig unterschiedlichen Quellen durchschaltet.
An der länge deines Posts sehe ich, dass du dir einige Gedanken gemacht
hast mir etwas zu sagen. Was das ist, ist mir noch nicht so ganz klar...
Ich werde also noch mal zu Gemüte führen und auf eine Erleuchtung
hoffen.
Als dann vielen Dank!
Die These das das (mein) Problem im Systemdesign liegt ist naheliegend
und vermutlich DAS Kernproblem. Es fällt ja auch nichts vom Himmel. Ich
habe das nicht wirklich gelernt aber die Herausforderung angenommen.
Ich muss feststellen, dass ich das 'erweitern' des Designs ganz charmant
finde, weil ich dann etwas angehen kann, was ich glaube zu verstehen bzw
zum entsprechenden Zeitpunkt in den Griff zu bekommen. :-( Aber so eine
richtige Alternative fällt mir auch nicht ein. Der Vorschlag zu Beginn
ein entsprechend komplexes Design komplett zu erschlagn ist wohl
sinnvoll, aber ich sehe leider dazu noch keinen Hebel...
Beispiel: Ich könnte mir vorstellen, dass als nächster Schritt einen
Framebuffer auf dem Display anzuzeigen derzeit im Bereich des Machbaren
ist. Wenn auch wundersame Weise Daten im Speicher stehen, und ich bei
dem Cellular Ram vom Nexys Board den SRAM Modus benutzen kann.
Wenn ich aber auch Daten reinschreibe bin ich bei allem Überlegen immer
wieder früher oder später am Ende. Egal wo die Daten herkommen, von
einem Controller über spi oder von einem Modul was Linien malen
kann...irgendwann kollidiert die Schreibadresse ja mit der Leseadresse.
Das kann ich ja abfangen und das Schreiben in dem Fall einfach einen
Zyklus verzögern....aber diese Kollision könnte ja öfter passieren, so
würde das reinschreiben ja immer weiter nach hinten durchrutschen... Ich
hoffe ihr versteht was ich meine. Deshalb war meine Vorstellung dieses
derzeit(vermeindlich) unlösbare Problem, nämlich etwas konkret
umzusetzen, etwas double buffered zu machen. Das ist natürlich
Vermeidungstaktik und wird früher oder später wieder vor den Poller
laufen.
Über Ideen oder Vorschläge wie ich meine Blockade überwinden kann wäre
ich dankbar. Ich hab es nicht gelernt. Gilt auch für Blockschaltbilder
zeichnen - anscheinend echt schwer wenn man das nicht Schritt für Schrit
gelernt hat.
