Hallo,
ich bin zur Zeit dabei eine VGA-Schnittstelle für meinen Zynq zu bauen.
Die Schnittstelle soll für einen 640 x 480 Monitor sein.
Zur Zeit verwende ich diesen Code:
Theoretisch sollte ich doch jetzt am Bildschirm Rot sehen oder?
Die Länge der Signale VSync und HSync habe ich überprüft und die sind
soweit richtig:
V-Sync
Länge: 16,79ms
Pulsweite: 64µs
H-Sync
Länge: 31,84µs
Pulsweite: 3,81µs
Allerdings bleibt mein Bildschirm schwarz.
Wo ist der Fehler?
Danke und Gruß
Daniel
Vorneweg: nimm statt den [ code ] Tags besser die [ vhdl ] Tags...
Kampi schrieb:> Allerdings bleibt mein Bildschirm schwarz.> Wo ist der Fehler?
Dein Verständnis vom Verhalten von Signalen im Prozess:
die letzte Zuweisung an Rot "gewinnt". Und das ist bei dir
1
if(Pixel_Counter<800)then
2
Red<='0';
Probiers mal so:
1
-- Left Black
2
if(Pixel_Counter<800)then
3
Red<='0';
4
Green<='0';
5
Blue<='0';
6
endif;
7
8
-- Color
9
if(Pixel_Counter<752)then
10
Red<='1';
11
endif;
12
13
-- Right Black
14
if(Pixel_Counter<112)then
15
Red<='0';
16
Green<='0';
17
Blue<='0';
18
endif;
Und wenns funktioniert, dann überleg mal, warum... ;-)
Ich würde es Übrigens nicht mit den "kleiner"-Abfragen machen, sondern
einfach mit "gleich"-Abfragen. Vorteil: dann ist die Reihenfolge egal...
Hallo Lothar,
danke für die fixe Antwort.
Es hat leider keine Besserung gebracht. :(
Hin und wieder flackert an dem Monitor die "No Signal" Meldung auf, aber
ansonsten bleibt er schwarz.
Das mit den Gleichheitszeichen meinst du nur bei den Abfragen für die
Farbe bzw. die Schwarzschultern oder? Hab das mal für die drei Abgleiche
gemacht.
Kampi schrieb:> Die Länge der Signale VSync und HSync habe ich überprüft und die sind> soweit richtig:
Wie hast Du das festgestellt?
Hast Du die Frequenz von Clock_VGA geprüft?
Hey,
die Impulse habe ich mir mittels LA ausgeben lassen (siehe Anhang).
Die Frequenz lasse ich über den Clock Wizard erzeugen und die liegt bei
25,6MHz.
Kampi schrieb:> Hey,>> die Impulse habe ich mir mittels LA ausgeben lassen (siehe Anhang).> Die Frequenz lasse ich über den Clock Wizard erzeugen und die liegt bei> 25,6MHz.
Will der Monitor die Syncs low- oder high-active?
Kampi schrieb:> Die Länge der Signale VSync und HSync habe ich überprüft
Erkennt der Monitor das Timing?
Mich wundert ein wenig, dass du in 800x600 auch die Sync-Signale
untetbringst. Sind die normalerweise nicht "ausserhalb"?
Lothar Miller schrieb:> Kampi schrieb:>> Die Länge der Signale VSync und HSync habe ich überprüft> Erkennt der Monitor das Timing?> Mich wundert ein wenig, dass du in 800x600 auch die Sync-Signale> untetbringst. Sind die normalerweise nicht "ausserhalb"?
Hey,
ich habe mal ein PDF angehängt, wo ich mir die Infos zum VGA raus geholt
habe. Hab noch nie wirklich mit VGA gearbeitet, von daher kann es gut
sein, dass ich da was falsch verstanden habe :(
Mit positiven Impulsen habe ich es gerade getestet. Es brachte leider
keine Änderung.
Lothar Miller schrieb:> Kampi schrieb:>> Die Länge der Signale VSync und HSync habe ich überprüft> Erkennt der Monitor das Timing?> Mich wundert ein wenig, dass du in 800x600 auch die Sync-Signale> untetbringst. Sind die normalerweise nicht "ausserhalb"?
Er will wohl 640x480, nicht 800x600.
MfG
Kampi schrieb:> Mit positiven Impulsen habe ich es gerade getestet. Es brachte leider> keine Änderung.
Hier steht was von low-active vsync by 640x480:
http://en.wikipedia.org/wiki/Video_Graphics_Array
Wenn der Monitor den Modus nicht erkennt (im OSD Status oder info
auswählen, dann stimmen die syncs nicht. Erkennt er den Mosus richtig,
aber die Farben, Helligkeit stimmen nicht, dann ist meist das Farbsignal
außerhalb des sichtbaren Bereichs nicht schwarz.
Wenn der Moni den Modus nicht unterstützt, dann sagt das OSD meist not
supported mode oder so.
MfG
Kampi schrieb:> Lothar Miller schrieb:>> Kampi schrieb:>>> Die Länge der Signale VSync und HSync habe ich überprüft>> Erkennt der Monitor das Timing?>> Mich wundert ein wenig, dass du in 800x600 auch die Sync-Signale>> untetbringst. Sind die normalerweise nicht "ausserhalb"?>> Hey,>> ich habe mal ein PDF angehängt, wo ich mir die Infos zum VGA raus geholt> habe. Hab noch nie wirklich mit VGA gearbeitet, von daher kann es gut> sein, dass ich da was falsch verstanden habe :(>> Mit positiven Impulsen habe ich es gerade getestet. Es brachte leider> keine Änderung.
Dort:
http://ece.wpi.edu/~rjduck/vga_controller_640_60.vhd
ist ein vga-controller den digilent für die xilinx starterkits
verwendet.
Du kannst ihn ja mal parallel zu deinem simulieren und nach
Unterschieden schauen. Der von digilent richtet sich nach VESA-Norm die
auch von TFT-Monis unterstützt wird. Zumindest die 800x600 Variante habe
ich selbst getestet und die tut es.
MfG,
Hallo,
so von der Logik her sieht das in etwa so aus wie bei mir, nur wie Werte
für die Sync-Signale sind anders.
Da verstehe ich nicht so ganz wie die drauf gekommen sind.
Hab die Werte jetzt mal übernommen (und meinen Code etwas umgeordnet,
sodass ich nicht mehr diesen einen großen Prozess habe).
Wo ich gerade schon dabei bin...
Wie ist das am besten wenn ich mehrere Sachen habe die bei einem
Clockimpuls gemacht werden sollen. Alles in einen Prozess oder lieber
aufteilen (quasi wie bei meinem VGA Code und dem Beispielcode - ein
schönes Beispiel)?
So hier eine schöne Liste aller VGA Signalzeiten.
http://tinyvga.com/vga-timing
Morgen oder Übermorgen paste ich hier gerne mein funktionierendes
1024x768 mit 75mHz Pixeltakt.
Hey,
genau die Seite habe ich auch bereits gefunden :)
Wäre toll wenn du deins mal zeigen könntest. Von den Sync Signalen sieht
meins (nach LA) richtig aus....ich muss nur noch schauen wie ich jetzt
die Farben da rein bekomme :)
Gruß
Für das Bild musst du die einzelnen Bits des DA-Wandlers entsprechend
setzen, aber nur innerhalb des sichtbaren Bereichs. Man sieht auch was
wenn man die außerhalb gesetzt lässt aber einige Monitore skalieren dann
das Bild nicht richtig. Also RGB Ausgänge sollten auf 0 sein wenn es
außerhalb des sichtbaren Bereichs ist.
Hey,
das war auch meine Vermutung. Ich habe deswegen mal die Farbe Rot auf
"1" gesetzt, aber nichts ist passiert.
Selbst wenn dann was falsch skaliert wird, müsste da ja was angezeigt
werden :)
Gustl Buheitel schrieb:> Für das Bild musst du die einzelnen Bits des DA-Wandlers entsprechend> setzen,
Ich gehe jetzt mal davon aus, dass der jeweilige "Farbpin" des FPGA
direkt an die VGA Buchse geführt ist...
Ja gut wenn das ein Widerstandsnetz DA-Wandler ist dann sind das mehrere
Bits, wenn man da irgendeines auf 1 setzt kann das noch ziemlich dunkel
sein. Wie muss eigentlich die Spannung bei den Farben sein? Ist da 3,3V
das Maximum oder wäre das bei mehr noch heller? Oder passt das der
Monitor dynamisch an?
Kampi schrieb:> Ich habe da einfach mal das LSB der Farben genommen (also R0).> Ob das hell genug ist weiß ich leider nicht.
LSB bedeutet "das am wenigsten signifikante Bit". Und jetzt denk mal
drüber nach, ob "das am wenigsten signifikante Bit" etwas gut
erkennbares ausmacht.
Kampi schrieb:> Wo ist der Fehler?
Wie so oft: nicht im geposteten Code, sondern ganz woanders.
Wenn das Ausgangssignal wenigstens ein Vektor oder die Hardware bekannt
gewesen wäre...
Kampi schrieb:> Die Frequenz lasse ich über den Clock Wizard erzeugen und die liegt bei> 25,6MHz.
Du könntest hier auch einfach mit einem Clock-Enable arbeiten, dann
hättest du ganz einfach ganz genau 25MHz:
1
signalen_25M:std_logic:='0';
2
3
process(PS_CLK)begin
4
ifrising_edge(PS_CLK)then
5
en_25M<=noten_25M;
6
if(en_25M='1')then
7
-- dein Code
8
endif;
9
endif;
10
endprocess;
Das erleichtert dann den Übergang von anderen Komponenten, die mit den
50MHz arbeiten...
Hallo Lothar,
danke für den Hinweis. Im Nachhinein wäre es wahrscheinlich echt
leichter gewesen die 25MHz zu nehmen, anstatt die 25,175 (vor allem wenn
man dran denkt, dass der Clock Wizard leicht buggy ist....).
Ich hab den Test gestern Abend noch mal mit dem MSB gemacht und da kam
ebenfalls nichts :(
Ich probier heute Abend noch mal den gezeigten Code aus und wenn es dann
funktioniert, gleiche ich das mal mit meinem ab und schaue wo der Hund
begraben ist.
Danke & Gruß
Du kannst auch 800x600 mit 50mHz Pixeltakt machen. Werde ich auch in
Zukunft verwenden. Die Dogilent Boards haben einen 50mHz Quarz.
http://tinyvga.com/vga-timing/800x600@72Hz
Kampi schrieb:> Ich hab den Test gestern Abend noch mal mit dem MSB gemacht und da kam> ebenfalls nichts :(
Nimm wie schon vorgeschlagen den ganzen Vektor VGA_R0..4 und beschalte
auch die VGA_Bx und VGA_Gx Pins mit "gültigen" Pegeln...
Denn theoretisch hätte es ausgereicht, an irgendeinem der VGA-Pins
herumzuzappeln, wenn die anderen alle hochohmige Eingänge sind.
Dirk schrieb:> Stimmen die Pin Zuweisungen ?
Kampi wird hoffentlich schon mal am Pin gemessen haben. Das ist
eigentlich naheliegend. Und man kann einfach auch "binäres" VGA fahren,
dann sind eben nur 8 Farben möglich: nix, R, G, B, RG, RB GB, RGB...
Jetzt hab ich mal nach den Spannungen geguckt und lese gleich mehrfach,
dass die Farben bei VGA von 0 bis 0.7V gehen. Das erstaunt mich jetzt
schon, weil der FPGA ja 3,3V anlegt.
Die Frage ist jetzt: Kann ich da mit 3,3V was kaputt machen? Soll ich
einen Spannungsteiler verwenden?
Danke!
@ -gb- (Gast)
>Jetzt hab ich mal nach den Spannungen geguckt und lese gleich mehrfach,>dass die Farben bei VGA von 0 bis 0.7V gehen.
Das ist auch so.
>Das erstaunt mich jetzt>schon, weil der FPGA ja 3,3V anlegt.
Sicher?
>Die Frage ist jetzt: Kann ich da mit 3,3V was kaputt machen?
Keine Ahnung.
> Soll ich einen Spannungsteiler verwenden?
So ziemlich ALLE FPGA-Boards haben dort passende Spannungsteiler, eben
um mit einfachsten Mitteln eine VGA-Ansteuerung zu erreichen.
Hab sie mit dem Schaltplan vom Zybo abgeglichen...die stimmen soweit.
Aber ich habe auf dem Monitor immer noch kein Bild :(
Der Monitor funktioniert, das habe ich mit einem Linuximage auf dem Zynq
getestet.
Auch die Timings für den Sync stimmen (seit der Änderung schwanken die
ab und an mal um 1-1,5µs aber das sollte hoffentlich nichts ausmachen).
Also wo zum Geier ist der kack Fehler -.-?
Hey,
so....
Ich habe mal was getestet. Ich habe mir den Originalcode von -gb-
genommen, den in mein Zynq gekloppt (mit einem Clock Wizard für die
75MHz), die Constraints von mir genommen und es getestet.
Und siehe da....es kommt eine "Out of Range" Meldung (wahrscheinlich
weil das Bild zu groß ist -> passe es jetzt mal an).
D.h. was ich sagen kann ist, dass die Constraints richtig sind (oh
wunder ^.^) und mein Code irgendwo eine Macke hat :)
Kampi schrieb:> es kommt eine "Out of Range" Meldung (wahrscheinlich> weil das Bild zu groß ist
Nein, die Meldung kommt, weil die Frequenzen nicht stimmen.
Hast Du mal einen Link zum Schaltplan des Boards?
Meine Fresse Vivado ist so buggy -.-
1 Stunde nach einem Bug von meinem Clock gesucht der auf einmal da war
und nach einem Neustart des Programms war er weg -.-
Der VGA läuft nun....der Fehler war richtig, richtig, richtig
dämlich...es lief nämlich quasi schon gestern.
Ich hatte statt
if (Pixel_Counter >= 144 ) and (Pixel_Counter < 784 )
and (Line_Counter >= 35 ) and (Line_Counter < 515 ) and (Pixel_Counter <
304) then
nämlich
if (Line_Counter >= 144 ) and (Line_Counter < 784 )
and (Pixel_Counter >= 35 ) and (Pixel_Counter < 515 ) and (Line_Counter
< 304) then
stehen, sprich die Counter waren vertauscht und die Bedingungen sind nie
eingetroffen...
Der Vollständigkeithalber noch mal der funktionierende Code (hab den
jetzt mal geordnet und jedem Funktionsblock einen einzelnen Prozess
gegeben):
Hab dann direkt noch eine weitere Verständnisfrage.
Mal angenommen ich habe jetzt in meinem RAM ein Bild liegen, welches ich
auf dem Monitor ausgeben will.
Dann würde ich diesen Prozess
1
process(Clock_VGA)
2
begin
3
ifrising_edge(Clock_VGA)then
4
if(Pixel_Counter>=144)
5
and(Pixel_Counter<784)
6
and(Line_Counter>=35)
7
and(Line_Counter<515)
8
and(Pixel_Counter<304)then
9
Red<="11111";
10
else
11
Red<="00000";
12
endif;
13
endif;
14
endprocess;
einfach dahingehend ändern, dass bei jedem Clock (wenn die Bedingungen
erfüllt sind) ein bestimmtes Pixel ausgegeben wird.
Also sowas wie (Pseudocode):
if(Clock) then
Counter + 1
Farbe = Pixelarray(Counter)
Sehe ich das richtig?
Danke noch mal für die Hilfe :)
Freue mich, dass es nun funktioniert! Und vor allem, dass meine erste
Idee quasi korrekt war (bis auf den ein oder anderen kleinen
Schönheitsfehler). :)
Gruß
Daniel
Du hast das Bild dann als Array von Werten, also wenn du ein Bild mit 9
Zeilen und je Zeile 16 Pixel mit je 8Bit Farbe, also ein 16x9 Bild hast,
wäre das ein 2D Array aus 144 8Bit Werten.
Adressenen kannst du das so,
Farbe = Array(vertikaler_counter*16 + horizontaler_counter);
Aufpassen musst du aber weil der counter auch den nicht sichtbaren
bereich enthält. Ausserdem vord das bild von oben nach unten aufgebaut,
also der vertikale counter fängt oben bei 0 an.
Hey,
danke für die Antwort.
Gut die Problematik mit dem nicht sichtbaren Bereich kann man ja
umgehen, indem man den Counter an eine Bedingung knüpft, wie z.B. das er
nur zählen soll wenn er im sichtbaren Bereich ist oder?
Ansonsten teste ich das morgen mal mit dem Bild :)
Danke & gute Nacht :)
Gruß
Daniel
Kampi schrieb:> stehen, sprich die Counter waren vertauscht und die Bedingungen sind nie> eingetroffen...
In einer Simulation sieht man das sehr schnell...
1
-- HSync
2
process(Clock_VGA)
3
begin
4
ifrising_edge(Clock_VGA)then
5
if((Pixel_Counter>0)and(Pixel_Counter<96))then
6
HSync<='0';
7
else
8
HSync<='1';
9
endif;
10
endif;
11
endprocess;
Ich würde das so schreiben:
1
-- HSync
2
processbegin
3
waituntilrising_edge(Clock_VGA);
4
if(Pixel_Counter=0)thenHSync<='0';endif;
5
if(Pixel_Counter=96)thenHSync<='1';endif;
6
endprocess;
Und vor Allem würde ich extra Zähler (x+y oder s+z) für das sichtbare
Bild einführen. Du rechnest dich ja zu Tode mit dem Offset auf dem
Pixel- und Line-Counter...
1
-- x-Position
2
processbegin
3
waituntilrising_edge(Clock_VGA);
4
if(x<639)thenx<=x+1;endif;
5
if(Pixel_Counter<144)thenx<=0;endif;
6
endprocess;
7
8
-- y-Position
9
processbegin
10
waituntilrising_edge(Clock_VGA);
11
if(Pixel_Counter=748andy<479)theny<=y+1;endif;
12
if(Line_Counter<35)theny<=0;endif;
13
endprocess;
Kampi schrieb:> Mal angenommen ich habe jetzt in meinem RAM ein Bild liegen, welches ich> auf dem Monitor ausgeben will.
Dann hättest du mit den oben berechneten x und y kein Problem, darauf
zuzugreifen...
Hallo Lothar,
danke für den Hinweis.
Eine Simulation hatte ich da nie gemacht (muss ich einfach mal öfters
bei den Dingern machen...).
Welchen Grund hat das, dass du die If-Abfrage aufteilst?
Den Zähler für den sichtbaren Bereich habe ich gestern schon angefangen
einzuführen, als ich ein paar Blöcke auf dem Display ausgeben wollte und
mich die Rechnerei genervt hat :P
Kampi schrieb:> Welchen Grund hat das, dass du die If-Abfrage aufteilst?
Es sieht schöner aus... ;-)
Ich verwende hier die implizite Priorisierung von Signalzuweisungen im
Prozess: die letzte Zuweisung an ein Signal gewinnt. So lassen sich
leicht im Prozess zuerst die "normalen" Bedingungen bearbeiten (Zähler
hochzählen und sättigen), und zum Schluss dann die Reset-Bedingung. Und
genau so habe ich es gemacht...
Hey,
ich wollte das jetzt mal ausprobieren mit dem Bild.
Dafür habe ich die Idee aufgegriffen ein 16x9 Bild darzustellen (wollte
es nachher über eine Zeitverzögerung noch länger machen oder so...) aber
ich bekomme schon mit dem 3D Array Probleme.
Mein Bild ist im Moment ein gestreifter Kasten:
Das ist ja jetzt ein Array mit den "Abmaßen" 16x9 und jede Stelle
beinhaltet 5 Bits oder sehe ich das falsch?
weil Vivado spuckt mir den Fehler hier aus:
[Synth 8-691] width mismatch in association of array element 0; element
has 5 bits, expression has 8 bits
["C:/Users/Daniel/Desktop/VGA/VGA.srcs/sources_1/new/VGA_Top.vhd":63]
Ah ok :)
Gut es funktioniert nun....allerdings nicht ganz so wie gedacht.
Hab das Array nun auf 20x16 vergrößert (der Rest ist gleich geblieben)
Auf dem Bild sehe ich nun aber keinen kleinen, gestreiften Kasten,
sondern sowas...
Skaliert der Displaycontroller das hoch? Oder ist das ein Codefehler?
Huiuiuiuiu, also da ist einiges drinnen was mir so nicht gefällt, z.B.:
1
if(Line_Counter>0)thenVSync<='0';endif;
2
if(Line_Counter<3)thenVSync<='1';endif;
Was soll da sein wenn Line_Counter den Wert 1 hat? Das ist > 0 und < 3.
Sowas ist da mehrmals, also ändere das mal so wie es sein soll und gucke
ob das was ändert.
Hey,
danke für die Antwort.
Ich hatte noch ein paar Probleme damit die Vereinfachungen von Lothar
Miller zu verstehen, bzw. ich habe sie falsch verstanden. Daher waren da
noch die Größer/Kleiner Zeichen drin.
Mittlerweile hat sich das erledigt und ich schaue noch mal drüber :)
Gustl Buheitel schrieb:> Was soll da sein wenn Line_Counter den Wert 1 hat? Das ist > 0 und < 3.
Dann merkt sich das Flipflop den zuletzt gespeicherten Wert...
Aber ich würde da einfach auf "gleich" vergleichen, dann muss man dich
nicht immer diese plusminus 1 Geschichte bei "kleiner" und "größer"
antun.
Lothar Miller schrieb:> Dann merkt sich das Flipflop den zuletzt gespeicherten Wert...
Das ist mir auch klar aber ... ich finde das trotzdem nicht sauber,
schon gar nicht für Anfänger, da sollte alles möglichst einfach und
verständlich lesbar sein.
Es ist sofar weniger Schreibarbeit:
Hey,
Lothar Miller schrieb:> Gustl Buheitel schrieb:>> Was soll da sein wenn Line_Counter den Wert 1 hat? Das ist > 0 und < 3.> Dann merkt sich das Flipflop den zuletzt gespeicherten Wert...>> Aber ich würde da einfach auf "gleich" vergleichen, dann muss man dich> nicht immer diese plusminus 1 Geschichte bei "kleiner" und "größer"> antun.
also die Schreibweise hat mir jetzt keine Probleme bereitet. Es war nur
das Verständnis nicht sofort da, warum der Code vom Lothar genau das
selbe gemacht hat wie mein "langer" Code (worunter übrigens auch der
Vergleich mit dem "=" fiel).
Ich habe mir dann aber mal beide Codes genommen und die logisch
durchgespielt und dann war das eigentlich auch relativ klar (vor allem
auch mit dem Vergleich durch "=") :)
Vergleiche mit "Größer", "Kleiner" etc. zu machen ist bei mir noch
irgendwie drin....ka warum. Ist halt erst mal wieder etwas Umgewöhnung.
Hab die Zähler jetzt mal angepasst. Jetzt habe ich am oberen Rand 4
Linien und am unteren Rand 2. Ich vermute mal, dass es jetzt daran
liegt, dass ich zu "früh" anfange zu Zeichnen und dann noch im
Schwarzbereich bin oder?
Aber ich verstehe auch noch nicht, warum ich Linien habe. Eigentlich
sollte ich doch nur einen einzelnen Kasten haben.
Die Zählschleifen sehen nun so aus (hab den Parameter "range" der
Zählerstände noch um 1 vermindert, weil ich die Stelle 0 wieder nicht
mit gezählt hatte):
Mir ist noch unklar wie du das "Bild" ausgeben möchtest, möchtest du das
20x16 Bild in einer Ecke des Bildschirmes sehen oder soll das auf den
ganzen Anzeigebereich "skaliert werden"?
Bei Letzterem und 16 Zeilen und 20 Spalten müsste bei einer 800x600
Bildschirmauflösung
Der Zähler für die Spalte alle 800/20 Pixel um eines hochzählen und der
Zähler für die Array-Zeile alle 600/16 Bildschirm-Zeilen um eines
hochzählen.
Also ganz grob:
Farbe <= Array(horizontal_zähler/20,vertikal_zähler/16);
Mit angepassten Zählern die nur im sichtbaren Bereich fon 0 ... 799 bzw.
von 0 ... 599 zählen.
Au man, ihr zieht hier mit VGA eine Lachnummer ab.
Ich als alter Anfänger(Pensionär) kann jetzt schon Text auf den VGA
bringen mit eingebundener Tastatur und serieller Schnittstelle.
Man lernt auch im Stillem....hab mich lange nicht mehr gemeldet.
Viel Hilfe die einem etwas nützt kommt hier im Forum nicht bei raus,
wird viel rum gesabbert ohne eine klare Aussage.
Gruss von der Heimentwicklung mit VHDL.
@ Peter Bierbach: Manch einer will halt auch verstehen, was er macht und
fängt klein an anstatt einfach fertige Code-Schnipsel zusammen zu
kopieren. Aber wir wissen ja jetzt dass du der Überflieger schlechthin
bist.
Sehr geehrter Herr Bierbach, Sie bringen in die vielschichtige
Diskussion interessante neue Aspekte ein, die die Problematik von einer
völlig neuen Seite beleuchten. Ihre Ausführungen zeugen von hoher
Sachkenntnis und überzeugen auch im Detail. Besonders im Mittelteil
transportieren sie eine Fülle hochwertiger Informationen, die dem Kreis
der betroffenen Nutzer nicht vorenthalten werden dürfen.
peter schrieb:> Au man, ihr zieht hier mit VGA eine Lachnummer ab.>> Ich als alter Anfänger(Pensionär) kann jetzt schon Text auf den VGA> bringen mit eingebundener Tastatur und serieller Schnittstelle.>> Man lernt auch im Stillem....hab mich lange nicht mehr gemeldet.>> Viel Hilfe die einem etwas nützt kommt hier im Forum nicht bei raus,> wird viel rum gesabbert ohne eine klare Aussage.>> Gruss von der Heimentwicklung mit VHDL.
Vielen Dank. Du bist das perfekte Beispiel für viel drum herumreden ohne
klare Aussage.
Wenn ich nur VGA laufen lassen will, hätte ich den fertigen IP-Core von
Xilinx genommen, mit meinem Tastaturencode und nem fertigen UART Core
vom Xilinx. Hätte die Dinger zusammen ins Zynq geschossen und wäre
happy.
Aber für mich gehört zu einem Lernprozess halt auch, dass ich mich mal
mit der Materie beschäftige und wirklich verstehen möchte wie sie
funktioniert.
Mittlerweile gibt es eh für alles fertigen Code im Netz. Das sind zwei
paar Schuhe ob man den Code nur kopiert oder ob man ihn auch versteht...
Also das Quadrat habe ich nun hin bekommen.
Der Fehler bestand einfach darin, dass ich in den Zeilen wo ich Rot
zeichne die Farbe nicht mehr deaktiviert habe, sprich der Ausgang Rot
wurde aktiviert und bliebt halt aktiviert, bis die nächste Bildzeile
kommt.
Hab das Problem nun behoben, indem ich am Ende meines "Bildes" eine
schwarze Spalte eingefügt habe.
Direkt nach dem Einschalten ist das Bild in Ordnung -> ein rotes,
gestreiftes Quadrat in der Ecke. Aber wenig später sieht es dann so aus:
Also so ganz ok sieht das irgendwie auch nicht aus. Ist das wirklich wie
im Array? Oder schreib doch mal ein Zeichen ins Array, also ein
Buchstaben mit 20*16 Auflösung oder ein Muster an dem man erkennt ob es
passt.
Und dann in Zukunft kleinere Dateigrößen, das ließe sich super zurecht
schneiden.
Lothar Miller schrieb:> Kampi schrieb:>> das perfekte Beispiel für viel drum herumreden ohne klare Aussage.> Man muss ein wrnig nach hinten schauen, zeitlich, dann sieht man in> einem anderen Licht, was peter schrieb:>>>> Man lernt auch im Stillem....> http://www.mikrocontroller.net/search?query=bierba...
Naja gut...ich reagiere halt immer leicht allergisch auf sowas, weil um
die Sachen zu verstehen muss man halt nachfragen (wobei es natürlich
auch mit bisschen Eigenarbeit verbunden ist...)
Aber zurück zum Thema :)
Ja, du hast Recht. Richtig sieht das nicht aus. Direkt nach dem
Einschalten sieht es so aus wie auf dem Foto, bis irgendwann ein
"Sprung" zu dem eben gezeigten Bild kommt.
Mach wirklich mal kleinere Dateianhänge, also nur den interessanten
Bereich ausschneiden. Und dann würde ich ein Muster ins Array schreiben
an dem man einfacher erkennen kann was falsch ist. Also Z.B. in jeder
Zeile einen Verlauf von "11111" nach "01001", also am Ende einen
Helligkeitsverlauf. Das könntest du noch in jeder Zeile variieren um
diese unterscheiden zu können. Oder mit Farben.
peter schrieb:> Viel Hilfe die einem etwas nützt kommt hier im Forum nicht bei raus,> wird viel rum gesabbert ohne eine klare Aussage.
Wie man in den Wald ruft tönt es zurück. Ich für meinen Teil habe schon
hin und wieder mal einen ganz nützlichen Tipp oder zumindest einen
weiterführenden Denkanstoss bekommen. "Chapeau" den Unermüdlichen hier.
peter schrieb:> Man lernt auch im Stillem....hab mich lange nicht mehr gemeldet.
Es war eigentlich schön ruhig, so...
> Viel Hilfe die einem etwas nützt kommt hier im Forum nicht bei raus,> wird viel rum gesabbert ohne eine klare Aussage.
Peter, du bist echt arrogant und eingebildet! Ich möchte dich nur mal
auf dein hoffnungsloses Rumgegurke vor 3 Monaten hinweisen.
> Ich als alter Anfänger(Pensionär) kann jetzt schon Text auf den> VGA bringen mit eingebundener Tastatur und serieller Schnittstelle.
Ich denke, den Code "deiner" seriellen Schnitte kenne ich in- und
auswendig. Und vermutlich auch den "deiner" Tastaturschnittstelle...
P. K. schrieb:> Ich für meinen Teil habe schon hin und wieder mal einen ganz nützlichen> Tipp oder zumindest einen weiterführenden Denkanstoss bekommen.
Ich auch. Und genau das ist es wert.
Gustl Buheitel schrieb:> Mach wirklich mal kleinere Dateianhänge, also nur den interessanten> Bereich ausschneiden.
Ja, und stell den Foto gleich mal um auf Bilder mit 300kB. Sonst muss
ich die 3MB-Bilder hinterher wieder zurechtschneiden. Und vor allem:
unterwegs mit dem Tablet dauert das Laden ewig (vom Traffic mal
abgesehen).
> Und dann würde ich ein Muster ins Array schreiben> an dem man einfacher erkennen kann was falsch ist.
Z.B. ein Fadenkreuz oder sowas...
Hey,
sorry wegen der Fotogröße. Hab die Bilder mit meiner Digicam gemacht und
nicht daran gedacht, dass die Bilder so riesig sind...
Ich habe jetzt mal ein Fadenkreuz implementiert:
Wenn x außerhalb des Kastens oder y außerhalb des Kastens,
was passiert dann mit Red?
Bleibt x auf 19? Und damit wird die letzte Spalte immer wieder
ausgegeben?
Bleibt y auf 19? Und damit wird die letzte Zeile immer wieder
ausgegeben?
Was bewirkt
"if(Pixel_Counter < 144)" bzw. "if(Line_Counter < 44)"?
Soll damit der Kasten einen (x/y)-Offset bekommen?
Hey,
meinst du mit "Kasten" den sichtbaren Bereich?
Mit der Abfrage if(Pixel_Counter < 144)" bzw. "if(Line_Counter < 44)
möchte ich, dass der Zähler so lange auf 0 bleibt wie das Display noch
im Schwarzbereich ist.
Was mit x und y passiert ist eine gute Frage...
Ich setze die nirgends zurück. Ich vermute mal, da die eine range von
0-19 haben, dass die auf dem Wert 19 bleiben, da die sich nicht bei 19
reseten sondern erst bei 20.
Stimmt das so?
Cool dein Denkanstoß war genial :)
Habe die Signale nun auf
range 0 to 18 gesetzt. Damit werden die automatisch zurück gesetzt und
siehe da...
Das müsste dann ja so funktionieren (bitte korrigieren falls falsch!):
Mein Array hat eine Breite von 20. Der Integer eine range von 0-18, d.h.
19 Werte. Beim nächsten Takt würde der Counter dann auf 19 springen und
den Integer reseten, sodass der wieder auf 0 steht und damit würde ich
dann wieder die Adresse 0 des Arrays ansprechen.
Aber wo bleibt dann der 20. Wert vom Array? kopfkratz
Oder habe ich da einen Denkfehler?
Ok noch mal etwas weiter gespielt...
Anscheinend hatte ich einen Denkfehler. Wenn ich die Signale für x und y
bis 18 mache, werden die immer resetet, wodurch sich die Kreuze dann
immer wiederholen.
Lasse ich die Signale aber auf der range von 19, habe ich oben in der
Ecke ein einzelnes Kreuz, so wie es sein muss.
Bleibt nur die Frage warum ab und an nach dem Einschalten ein lang
gezogenes Kreuz erscheint...
----------------------------
Mittlerweile gibt es eh für alles fertigen Code im Netz. Das sind zwei
paar Schuhe ob man den Code nur kopiert oder ob man ihn auch versteht...
----------------------------
Mittlerweile gibt es fertige Fernseher, Auto, Handy....
Ich brauche nicht alle verstehen wie sie entwickelt worden sind, sondern
nur wie einzelne Funktionen zu handhaben sind....
-------------------------
also die Schreibweise hat mir jetzt keine Probleme bereitet. Es war nur
das Verständnis nicht sofort da, warum der Code vom Lothar genau das
selbe gemacht hat wie mein "langer" Code (worunter übrigens auch der
Vergleich mit dem "=" fiel).
------------------------
Au man er schreibt immer noch "Code"...was sagt Miller dazu?
peter schrieb:> -------------------------> also die Schreibweise hat mir jetzt keine Probleme bereitet. Es war nur> das Verständnis nicht sofort da, warum der Code vom Lothar genau das> selbe gemacht hat wie mein "langer" Code (worunter übrigens auch der> Vergleich mit dem "=" fiel).> ------------------------>> Au man er schreibt immer noch "Code"...was sagt Miller dazu?
Code ist ja auch richtig...
Siehe Wikipedia:
http://de.wikipedia.org/wiki/Very_High_Speed_Integrated_Circuit_Hardware_Description_Language
Nur deine Aussagen das du ein FPGA programmierst sind falsch...
Ein Code kann vieles sein...auch hier wieder Wikipedia:
http://de.wikipedia.org/wiki/Code
In VHDL codierst du eine Schaltung. Du drückst mit Worten die Funktion
aus und legst nicht, wie bei der Software, mit bestimmten Befehlen ein
Verhalten einer Schaltung fest.
peter schrieb:> ----------------------------> Mittlerweile gibt es eh für alles fertigen Code im Netz. Das sind zwei> paar Schuhe ob man den Code nur kopiert oder ob man ihn auch versteht...> ---------------------------->> Mittlerweile gibt es fertige Fernseher, Auto, Handy....> Ich brauche nicht alle verstehen wie sie entwickelt worden sind, sondern> nur wie einzelne Funktionen zu handhaben sind....
Dann mal viel Spaß wenn du Programme oder Schaltungen anpassen oder
ändern musst. Dann kommt es nämlich sehr wohl auf das Verständnis der
ganzen Schaltung an...
Heyho,
so mal ein kleines Update :)
Habe ein bisschen an dem Code rum gearbeitet und mich dazu entschlossen
die drei Farben in einen Vektor zu legen. Dadurch kann ich ganz einfach
die Farben je nach Hexwert schalten:
-- Pixelcounter zurücksetzen und Zeilencounter erhöhen
149
if(Pixel_Counter=800)then
150
Pixel_Counter<=0;
151
Line_Counter<=Line_Counter+1;
152
endif;
153
154
-- Zeilencounter zurücksetzen
155
if(Line_Counter=525)thenLine_Counter<=0;endif;
156
157
endif;
158
endprocess;
159
endVGA_Top_Arch;
Woran ich jetzt noch arbeite ist eine Offsetfunktion, sodass ich das
Bild irgendwo im Display darstellen kann und vielleicht noch einen
Counter um das Bild wiederholt darstellen zu können.
Sowas bekomme ich im Moment nur hin, indem ich die Variablen für die x
und y Koordinaten vom Parameter "range" 1 kleiner mache als die
Bildgröße...aber das ist irgendwie nicht zielführend.
Im Moment sieht das so aus wie auf dem Foto...da bin ich eigentlich
schon ganz zufrieden mit :)
Die mehrfarbige Darstellung klappt auch. Jetzt packe ich demnächst noch
das Array für das Bild an, wo dann das Bild jedes mal abgelegt wird und
dann werden einfach nur Bildinformationen da rein geschrieben und die
Schaltung gibt das Bild dann aus (wenn jemand eine bessere Idee hat, ich
bin immer für Kritik offen :) )
Danke noch mal für die Hilfe zum Umsetzen der Schaltung. Hat zwar etwas
gedauert, aber dafür weiß ich jetzt auch was die macht und wie sie
funktioniert.
Ach eine Frage noch...wenn ich auf dem Display jetzt Buchstaben
wiedergeben möchte....wie mache ich sowas am besten? Da muss ich ja
jeden Buchstaben in dem Code definieren, also was Länge und Breite und
dann das Pixelmuster angeht (wobei Länge und Breite ja im Grunde für
alle Buchstaben fest sind).
Wie kann man sowas geschickt abbilden?
Danke und Gruß
Daniel
peter schrieb:> Au man er schreibt immer noch "Code"...was sagt Miller dazu?
Ein "Code" ist noch lange kein (Software-)"Programm". Das hatte ich
schon mal in einem deiner Threads geschrieben, Peter.
Kampi schrieb:> Habe ein bisschen an dem Code rum gearbeitet und mich dazu entschlossen> die drei Farben in einen Vektor zu legen.
Da ist es ganz praktisch, dass es diese "seltsame" Aufteilung der
Bitbreiten gibt...
Dieser Prozess hat eine fehlerhafte Sensitivliste, dadurch ist die
Simulation falsch: die Daten werden dort einen "halben" Takt versetzt an
Color weitergegeben.
1
-- Bild ausgeben
2
process(Clock_VGA)
3
begin
4
Color<=Bild(y,x);
5
endprocess;
Du kannst das hier problemlos und fehlerfrei abkürzen (so wie der
Synthesizer das auch macht), und am besten auch den zweifelhaften
Kommentar streichen:
1
-- Bild ausgeben <-- hui, hier wird ein GANZES Bild ausgegeben?
2
Color<=Bild(y,x);
> Ach eine Frage noch...wenn ich auf dem Display jetzt Buchstaben> wiedergeben möchte....wie mache ich sowas am besten?
Ähnlich wie diese "Sprites", die du hier ausgibst: du legst eine
Zeichentabelle ab, wo jeder Buchstabe drin ist, und greifst dann mit
einem Offset auf das gewünschte zeichen zu.
Kampi schrieb:> Wie kann man sowas geschickt abbilden?
Momentan hast Du das (signal) Bild und die Ansteuerung in derselben
Entity. Wenn Du nun daran gehen willst, Text oder sonst was
darzustellen, solltest Du das trennen:
- Video I/F (liest Framebuffer und generiert die Ausgangssignale)
- Framebuffer (RAM, X*Y Pixel)
- Bespassung des Framebuffers (z.B. *.bmp via anderes I/F reinladen,
Character Buffer, oder andere Aufbereitung)
Da Du offensichtlich Characters darstellen willst, brauchst Du einen
Characterbuffer und eine LUT (ROM) wo Deine Characters drinnstehen. Wie
sowas geht könntest Du einem Character LCD-Treiber abschauen (z.B.
PCF2119)
Hey,
danke euch beiden für die Antwort.
Über die "seltsame" Aufteilung der Bitbreite bin ich aus versehen
gestolpert...wunderte mich dann auch warum Grün 6 Bit lang ist, aber das
kann evtl. was damit zu tun haben, dass ein Mensch Grün stärker wahr
nimmt...
Der Kommentar ist wirklich doof gewählt...da suche ich was besseres :)
Stimmt...wenn man genauer drüber nachdenkt fällt einem auch schnell ein,
dass man für die Zeile
Color <= Bild(y,x);
gar keinen Process braucht. Die Koordinaten x und y werden ja schon
getaktet erhöht und die Zeile soll ja nur den Eingang entsprechend eines
aktuellen Pixels im RAM setzen.
Kannst du mir noch erklären wie du auf einen halben Takt kommst? Ich
würde eher vermuten, dass dann ein ganzer Takt Verzögerung drin ist,
weil mit Takt 1 werden die neuen Array Koordinaten generiert und Takt
würde die Koordinaten dann in die entsprechende Zelle umwandeln und
diese dann ausgeben.
Theoretisch passiert das ja alles gleichzeitig, aber es kann ja nicht
gleichzeitig der Counter für die Koordinaten erhöht werden und dann die
aktuellen Zelleninhalte ausgegeben werden.
@ pek:
Ja diese Idee ist mir jetzt auch über Nacht gekommen. Im Grunde ist der
Teil, an dem ich bisher gearbeitet habe nur für die Darstellung da,
sprich er greift auf einen Buffer (halt das Array) zu und gibt den
Inhalt aus.
Für die Bildgenerierung innerhalb des Arrays ist ein anderer Teil
zuständig.
Daher habe ich den Codeteil für die Bilderstellung jetzt schon mal
ausgelagert in ein einzelnes Modul und das dann instanziert.
Ich wollte da heute noch ein paar Schönheitsänderungen machen und mich
dann an einen zweiten Teil setzen, der die Bilderzeugung übernimmt (halt
den Framebuffer den du meintest).
Die Idee mit dem LCD Controller ist super :)
Den Framebuffer mache ich dann wahrscheinlich direkt so groß, dass dort
die 640x480 Pixel rein passen oder eher kleiner machen?
Ich hatte mir das so überlegt, dass ich das Array in der Größe des
sichtbaren Bereiches mache und dann halt die entsprechenden Zellen
beschreibe (z.B. mit Buchstaben).
Kampi schrieb:> Über die "seltsame" Aufteilung der Bitbreite bin ich aus versehen> gestolpert...wunderte mich dann auch warum Grün 6 Bit lang ist, aber das> kann evtl. was damit zu tun haben, dass ein Mensch Grün stärker wahr> nimmt...
Ja, und damit, dass 5+5+6 ganz gut und zudem genau in 2 Byte passen...
;-)
> Kannst du mir noch erklären wie du auf einen halben Takt kommst?
Das kommt, weil der Simulator den Prozess bei jeder Änderung von
Clock_VGA neu berechnet, also auch bei der fallenden Flanke.
Wenn du nur Zeichen ausgeben willst,
könnte auch folgender Ablauf helfen:
(nur die Idee, ich kann kein/kaum VHDL)
Zusätzlich zu x und y noch ein Spalte und Zeile verwenden.
(Beispiel: Zeichen sind 8x8 groß)
Wobei
Spalte mehr oder weniger x / 8
Zeile mehr oder weniger y / 8
ist. Kannst auch direkt x und y nehmen (und die unteren
Adressleitungen weglassen).
Dann etwas in der Art:
Zeichen_an_Zeile_Spalte = Zeichenbuffer(y,x);
Color <= Bild(Zeichen_an_Zeile_Spalte,y,x);
"Bild" ist dann die Pixel-Darstellung aller Buchstaben/Zeichen.
Peter P. schrieb:> Wobei> Spalte mehr oder weniger x / 8> Zeile mehr oder weniger y / 8> ist. Kannst auch direkt x und y nehmen (und die unteren> Adressleitungen weglassen).
Das macht der Synthesizer bei /8 sowieso. Wobei das bei einem signed
Integer eigentlich nicht richtig ist: bei negativen Zahlen wird da
falsch gerundet...
peter schrieb:> if(x < (Bild_Breite - )) then>> So kann das nicht laufen....
Sorry, da ist mir die 1 flöten gegangen. Vielleicht kann das ein
Moderator ja eben korrigieren :)
Darum laufen hier viele VHDL nicht korrekt, weil die kleine Fehler
beinhalten und nicht berichtigt werden obwohl erkannt.
Miller, deine Ausrede ist irgendwie blöd....gegenüber dem, der das
Programm geschrieben hat. Der möchte das andere evtl sein Programm mal
Testen und du lässt ihn nicht den Fehler berichtigen.
Hoffentlich hast du keine gewerbliche Firma angemeldet...
peter schrieb:> Der möchte das andere evtl sein Programm mal Testen und du lässt ihn> nicht den Fehler berichtigen.
Wenn da einer so blöd oder faul ist, nur den Code zu kopieren und nicht
mal zwei Beiträge davor und danach zu lesen, dann bin ich nicht an
dessen Scheitern schuld...
> Miller, deine Ausrede ist irgendwie blöd....
Menschen, die mich duzen und meinen Nachnamen dabei benutzen obwohl
ihnen der Rufname vor der Nase liegt, sind mir extrem unsympathisch.
Eist billig und hochnäsig.
Und, Peter: VHDL Beschreibungen "laufen" nicht "nicht korrekt", Sie
werden bestenfalls "nicht korrekt umgesetzt".
-----------------------------------
dann bin ich nicht an dessen Scheitern schuld...
-----------------------------------
Aber eine Mitschuld und Mitverantwortung von Fehlerhaften VHDL , wenn du
davon Weisst(Vorsatz) und diesen mit Absicht öffentlich verbreitest.
Peter Bierbach schrieb:> -----------------------------------> dann bin ich nicht an dessen Scheitern schuld...> ----------------------------------->> Aber eine Mitschuld und Mitverantwortung von Fehlerhaften VHDL , wenn du> davon Weisst(Vorsatz) und diesen mit Absicht öffentlich verbreitest.
Wer Code ohne nachdenken aus dem Internet kopiert muss sowieso damit
rechnen das er falsch ist....
Ich habe heute noch mal etwas weiter gebastelt.
Ich habe mir jetzt ein eigenes Design für einen VGA Controller gebaut,
der die Syncs und die Koordinaten für das Bild erzeugt.
Inspiriert wurde ich durch das Bild hier:
http://eewiki.net/pages/viewpage.action?pageId=15925278
Der VGA-Controller ist an für sich nun abgeschlossen (hab dem ganzen
auch nen Reset spendiert ;) ).
Jetzt geht es um die Umsetzung eines Bildes, aber davor habe ich noch
ein (kleines) Problem.
Heute Mittag (bevor ich die Änderungen gemacht hatte) habe ich es
geschafft, dass sich das Kreuz über den Bildschirm bewegt. Dazu hatte
ich einen langsameren Clock genommen und die Koordinaten hoch gezählt.
Jetzt habe ich diesen Code
einfüge bekomme ich die im Screenshot sichtbaren Meldungen (sie
verschwinden auch wieder sobald ich den Block wieder entferne).
Woher kommt die Meldung und was kann man dagegen machen?
Laut Xilinx bedeutet sie das Pins im Constraint nicht geroutet sind, was
aber hier nicht zutrifft.
Btw: Clock_Div ist ein simpler Clock Divider...einfach nur um einen Takt
ohne Clock Wizard runter zu teilen.
Danke für die Hilfe
Gruß
Daniel
Kampi schrieb:> Und wenn ich jetzt in der Architektur das hier> Pos_x <= Pos_x + 1;> einfüge bekomme ich die im Screenshot sichtbaren Meldungen> "Multiple Drivers Pos_x ... Pos_y"
Das bedeutet, dass du Pos_x und Pos_y von 2 Stellen aus "treibst". Das
ist wie wenn du in der Hardware 2 Ausgänge aufeinander schaltest.
Und wenn wir das Ganze mal verfolgen wird blitzschnell klar, was da
passiert:
1
componentVGA_Controlleris
2
Port(...
3
x_out:outinteger;
4
y_out:outinteger);
5
:
6
:
7
VGA_Core:VGA_Controllerportmap(...Pos_x,Pos_y);
Vom VGA_Controller wird ein Ausgang x_out auf Pos_x gelegt, deshalb
darfst du da nicht noch zusätzlich einen Zähler draus machen.
> Woher kommt die Meldung und was kann man dagegen machen?
Es sollte eher die Frage sein: was willst du machen? Die Pos_x und
Pos_y kommen aus dem Controller und zeigen dir an, wo die ausgaben
bezogen auf die generierten Sync-Impulse gerade ist. Du darfst also
nicht an diesen beiden Signalen herumschrauben, sondern musst auf sie
reagieren.
BTW:
Was ist die absicht dabei, dass du diese Ausgabe hier taktest?
1
-- Pixel ausgeben
2
process(Clock_VGA)
3
begin
4
if(rising_edge(Clock_VGA))then
5
Color<=Bild(Pos_y,Pos_x);
6
endif;
7
endprocess;
Warum schreibst du nicht einfach so:
1
-- Pixel ausgeben
2
Color<=Bild(Pos_y,Pos_x);
Kommt dabei ein Unterschied heraus (mal abgesehen davon, dass der zweite
Vorschlag einen Takt früher dran ist)?
Peter Bierbach schrieb:> Aber eine Mitschuld und Mitverantwortung von Fehlerhaften VHDL
Das ist in etwa so wie Parken auf dem Mutter-Kind-Parkplatz nachts um
3...
> Aber eine Mitschuld und Mitverantwortung von Fehlerhaften VHDL
Ich bin mir diesem Druck bewusst und werde ihm wie ein Mann
entgegenstehen!
Hey Lothar,
danke für die ausführliche Antwort :)
Das kann gut sein das dieser Process bei der Pixelausgabe daran schuld
ist...den hatte ich gestern aus irgendeinem Grund eingefügt und nicht
mehr daran gedacht. Ich probier das heute Abend mal aus.
Ach direkt noch eine Frage zu dem abgelegten Zeichensatz für die
Textausgabe im FPGA...
Ich habe noch ein paar Probleme damit mir zu überlegen wie man das am
besten machen kann.
Wenn ich das Datenblatt des LCD Controllers
http://www.nxp.com/documents/data_sheet/PCF2119X.pdf
als Grundlage nehme und diesen Zeichensatz samt Adressierung nachbauen
will, wie kann man das am besten realisieren?
Gibt es die Möglichkeit, ähnlich wie in C, eigene Headerfiles zu
importieren, wo ich dann z.B. den Zeichensatz drin habe?
Und wie kann man die Zeichen am optimalsten speichern?
Ich brauch ja dafür (denke ich mal) ein 1-D Array, wo jede Stelle 2-D
ist um das Zeichen zu beschreiben.
Kann man sowas implementieren? Und wenn ja wie? :)
Hallo,
danke für die Antwort.
Ich habe mal am Wochenende wieder etwas weiter rumprobiert und bei
meinen Suchen bin ich auf dieses PDF gestoßen:
->
http://ece.gmu.edu/coursewebpages/ECE/ECE448/S13/viewgraphs/ECE448_lecture8_VGA_2.pdf
Die Schaltung für das Font-ROM verstehe ich... aber dadrunter die
Schaltung für den "Text generation" Circuit" verstehe ich nicht
wirklich...
Ich verstehe noch nicht so ganz, wie ich aus den x und y Koordinaten die
mein VGA-Controller ausgibt und dem Zeichensatz, welcher im Font-ROM
gespeichert ist, ein Bild mit Text generieren kann :(
Kampi schrieb:> Ich verstehe noch nicht so ganz, wie ich aus den x und y Koordinaten die> mein VGA-Controller ausgibt und dem Zeichensatz, welcher im Font-ROM> gespeichert ist, ein Bild mit Text generieren kann :(
In diesem projekt: http://www.mikrocontroller.net/articles/Durchblicker
hat es auch eine Zahlenausgabe, ebenso in diesem FPGA-nachbau eines
Einplatinencomputers mit ASCII-Ausgabe:
http://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA#Textausgabe
Letzlich geschieht die Zeichengenerierung über einen ROM, der das
Bitmuster der zeichen enthält. Die unteren bits der x und y Koordinaten
werden in Adressbits des ROM umgerechnet. Das ist das ganze Geheimnis.
MfG,
Kampi schrieb:>> Aber ich bekomme keine Linie :(> Wo ist das Problem?
2 Fehler:
Erstens solltest du Clock_VGA benutzen um die Line zu erzeugen.
Zweitens hast du keine Farbe für ausserhalb der Linie definiert.
Letzteres kann man auf 2 Arten läussen,
a) ein else
b) Hintergrundfarbe am Anfang des Prozesses ausgeben.
Hallo,
ich habe eine neue Frage...
Und zwar versuche ich gerade ein paar animierte Objekte auf dem
Bildschirm darzustellen.
Dazu habe ich versucht einen Code aus einem Buch zu übernehmen:
Eigentlich sollte da jetzt eine einfarbige Linie auf einem einfarbigen
Hintergrund erscheinen.
Aber es erscheint nur die Linie und ich verstehe gerade nicht so ganz
warum :(
Danke für die Hilfe!
Kampi schrieb:> Hat das einen bestimmten Grund?
Ja. Du solltest niemals ohne Not eine zweite Taktdomäne aufmachen.
Blitzschnell hast du da nämlich Taktverhältnisse, die "nicht zueinander
passen" an der Backe und damit ein asynchrones Design im FPGA. Arbeite
stattdessen mit Clock-Enables!!
Such mal hier im FPGA-Forum nach "Postulate"...
> Aber es erscheint nur die Linie und ich verstehe gerade nicht so ganz> warum :(
Wie ist color an die Hardware angeschlossen?
BTW
Dieser sehr ausführliche Bar_on Prozess könnte so viel übersichtlicher
geschrieben werden:
Color <= x"FC00" when Bar_in='1' else x"001F";
Hallo,
danke für die Antwort.
Color ist wie folgt angeschlossen:
Bits 0-4 Farbe 1
Bits 5-9 Farbe 2
Bits 10-15 Farbe 3
Wie gesagt, das Beispiel ist erst einmal nur abgeschrieben und an meinen
Code angepasst. Schöner machen kommt nachher :)
Gruß
Daniel
Kampi schrieb:> Lothar Miller schrieb:>> Dieser sehr ausführliche Bar_on Prozess könnte so viel übersichtlicher>> geschrieben werden: ...> das Beispiel ist erst einmal nur abgeschrieben
Da wo du das herhast, würde ich nichts abschreiben...
> Color ist wie folgt angeschlossen:
Was passiert, wenn du das umdrehst:
1
if(Bar_On='1')then
2
Color<=x"001F";
3
else
4
Color<=x"FC00";
5
endif;
Was passiert, wenn du die Farbe in der Mitte nimmst?
Was passiert, wenn du alle Bits setzt?
Wenn ich es umdrehe habe ich einen roten Balken und der Rest ist
schwarz.
Bei den Bits in der Mitte ist der Balken dann Lila und wenn ich alle
Bits setze, ist da ebenfalls ein Violetter Balken.
Was ich mich halt frage ist warum der Hintergrund keine andere Farbe
hat...
Kampi schrieb:> Wenn ich es umdrehe habe ich einen roten Balken und der Rest ist> schwarz.> Bei den Bits in der Mitte ist der Balken dann Lila und wenn ich alle> Bits setze, ist da ebenfalls ein Violetter Balken.>> Was ich mich halt frage ist warum der Hintergrund keine andere Farbe> hat...
Pins richtig zugeordnet?
Lattice User schrieb:> Kampi schrieb:>> Wenn ich es umdrehe habe ich einen roten Balken und der Rest ist>> schwarz.>> Bei den Bits in der Mitte ist der Balken dann Lila und wenn ich alle>> Bits setze, ist da ebenfalls ein Violetter Balken.>>>> Was ich mich halt frage ist warum der Hintergrund keine andere Farbe>> hat...>> Pins richtig zugeordnet?
Jap. Habs ausprobiert
Kampi schrieb:> Lattice User schrieb:>> Kampi schrieb:>>> Wenn ich es umdrehe habe ich einen roten Balken und der Rest ist>>> schwarz.>>> Bei den Bits in der Mitte ist der Balken dann Lila und wenn ich alle>>> Bits setze, ist da ebenfalls ein Violetter Balken.>>>>>> Was ich mich halt frage ist warum der Hintergrund keine andere Farbe>>> hat...>>>> Pins richtig zugeordnet?>> Jap. Habs ausprobiert
Dann muss es funktionieren, der Fehler liegt nicht im gepostetem Code.
(Es sei denn ich bin blind)
Kampi schrieb:> Was ich mich halt frage ist warum der Hintergrund keine andere Farbe> hat...
Hat er doch. Nur die komplett falsche...
Kampi schrieb:>> Pins richtig zugeordnet?> Jap. Habs ausprobiert
Wie?
Hast du schonmal ein blaues oder ein grünes Bild erzeugt?
Kampi schrieb:> Bei den Bits in der Mitte ist der Balken dann Lila
Eher Magenta? Also die Mischung von Baul und Rot?
http://www.bewegtesbild.de/content/index.php?option=com_content&task=view&id=31&Itemid=29Kampi schrieb:> Sorry, meinte ein kaum sichtbarer schwarzer Balken bei allen Pins auf 1.
Kurios! Wird da noch was invertiert?
Evtl. verdaut der Monitor die hohen 3V-Pegel doch nicht... :-/
Da wäre jetzt ein Oszilloskop recht hilfreich. Hast du sowas?
Lattice User schrieb:> der Fehler liegt nicht im gepostetem Code.
Ganz deiner Meinung.
mmh ein Oszi habe ich.
Aber ich habe gerade ein anderes Problem festgestellt.
Und zwar wollte ich mir die drei Farben mal ausgeben lassen, aber es
werden immer nur 2 Farben angezeigt.
Hab den Code mal umgeformt:
Im Moment werden Rot und Grün angezeigt. Tausche ich jetzt die
Koordinaten in der Abfrage von Grün und Blau, wird ein roter und ein
blauer Balken angezeigt :/
Kampi schrieb:>> Im Moment werden Rot und Grün angezeigt. Tausche ich jetzt die> Koordinaten in der Abfrage von Grün und Blau, wird ein roter und ein> blauer Balken angezeigt :/
Könnte natürlich sein, dass x_pos nie 400 oder grösser wird, oder dass
das Timing nicht stimmt un der Monitor nur das halbe Bild anzeigt.
Definiere eine Hintergrundfarbe, und schau wo die 2 sichtbaren Balken
erscheinen und ob sie eventuell abgeschnitten werden.
Lattice User schrieb:> Du hast wieder vergessen eine Hintergrundfarbe (z.B. Schwarz) zu> definieren>> z.B. so if(rising_edge(Clock_VGA)) then> Color <= x"0000";> if(Red = '1') then> .....
Chaka :)
Das wars!
Kannst du mir erklären warum ihn das stört?
Wobei ich es mir fast denken kann...im Grunde tritt in den
Zwischenspalten keine der Bedingungen in Kraft, wodurch die Pins so
gesetzt bleiben (in meinem ersten Beispiel). Aber warum wurde der
Bildschirm dann am Ende des 2. Balkens doch wieder Schwarz?
Kampi schrieb:> Chaka :)> Das wars!> Kannst du mir erklären warum ihn das stört?
Den FPGA sollte es jedenfalls nicht stören.
> Wobei ich es mir fast denken kann...im Grunde tritt in den> Zwischenspalten keine der Bedingungen in Kraft, wodurch die Pins so> gesetzt bleiben (in meinem ersten Beispiel). Aber warum wurde der> Bildschirm dann am Ende des 2. Balkens doch wieder Schwarz?
Hat du mit dem Osci die VGA Signale angeschaut, mit und ohne Änderungen?
So ist das alles im rumgestochere im Nebel.
Hey,
also ich habe da eigentlich nichts merkwürdiges gemessen.
Kann aber auch sein das Vivado wieder etwas rumgesponnen hat und die
Synthese nicht geklappt hat >.< (hatte ich die Tage öfters, nach einer
zweiten Synthese funktioniert die Schaltung dann).
Naja....bin im Moment dabei einen Punkt zur Bewegung zu bringen :)
Hab irgendwie gerade Lust mir mein eigenes Pong Game zu bauen :o
Die Ausgabe funktioniert auch super, nur wenn ich den Kreis jetzt über
den Bildschirm wandern lasse, wird er eckig dargestellt :(
Woran das liegt kann ich mir in etwa denken (wahrscheinlich daran, dass
ich die letzten drei Bits der Koordinaten auf dem Bildschirm für das
Array nutze).
Nur wie bekomme ich das jetzt anders hin, sodass der Kreis weiterhin
rund bleibt :/?
Einen separaten Counter für die Adresse?
Danke für die Hilfe!
Hab das Problem quasi gelöst. Ich habe einfach gesagt, dass die
Schrittweite nicht 1 ist, sondern ein vielfaches von 8.
Dann wird der Speicher richtig ausgelesen und der Ball ist rund :)