Hallo!
Vorgeschichte
Vor kurzem ist mir die Bildröhre in einem alten Steuergerät verreckt.
Ersatz nicht ohne Weiteres zu bekommen.
Freundlicher Weise hat der Steuerrechner einen externen
Bildschirmausgang. Leider in einem etwas ungünstigen Format, sodass man
einen modernen Bildschirm damit nicht so ohne weiteres beglücken kann
(50Hz vertikal, ~21kHz horizontal, RGB jeweils digital wie es aussieht,
mit 64ns als kleinsten Puls den ich ausmachen konnte (wohl ~ 1 Pixel))
Da dachte ich mir: die Perfekte Ausrede um sich mal wieder etwas mit
FPGAs zu beschäftigen. ;-) Kann vom Konzept her ja nicht so schwierig
sein das Bild einzulesen und an einen Bildschirm auszugeben.
Also gesagt getan, für eins von den niedlichen kleinen Artix 7 Boards
von Trenz ein Board mit VGA Buchse gebastelt und losgelegt.
Ein paar Stunden später hatte ich den Umstieg von ISE (lang ist's her)
auf Vivado seelisch überstanden und die erste blinke-Demo laufen.
Einen Tag später lief dann auch mein proof-of-concept:
/Vorgeschichte
Zwei Zustandsautomaten, ein Framebuffer aus BRAMs für 800x600x1bit (bzw
sogar zwei mittlerweile ^^)
Eingangsseitig alles zwischen den H-Sync Impulsen einlesen, Zeile
speichern, wiederholen bis V-SYNC...
Ausgangsseitig ein einfacher VGA Controller der das Ganze wieder mit
brauchbarem Timing ausgibt.
Und tatsache, vom Konzept her war es auch nicht so wild. Aber der Teufel
steckt wie immer im Detail. ;-)
Und zwar zittern die Pixel um einen Pixel horizontal. (manchmal sogar
als diagonales Muster erkennbar, aber nicht überall) Ich nehme an das
liegt daran, dass ich weder die genaue Pixelfrequenz kenne noch die
Ausgabe und mein Einlesen synchron sind.
(Ausgabe von mit Testmuster vorgeladenem BRAM zeigt kein Flackern)
Erste Idee wäre jetzt, meinen Pixeltakt zum Einlesen irgendwie auf die
Flanke des H-Sync Signals des Steuerrechners zu synchronisieren. Wenn
die in einer festen Beziehung zueinander stehen kann man den Rest ja
ausprobieren bis es passt.
Die Frage ist nur, wie würde man das angehen? Hat der FPGA Boardmittel,
die ich dafür benutzen kann? Wenn nicht, nach welchen Konzept könnte man
das erreichen?
Oder ist ein ganz anderer Weg vielversprechender?
Ich freue mich über Ideen!
Danke :-)
Peter
Viel wichtiger als die Bestimmung der Pulsbreite eines Einzelpulses
(~64ns) wäre es, ebenso auch breitere Pulse zu vermessen und
nachzurechnen, ob diese exakten Vielfachen entsprechen. Ggf. lohnt auch
ein Blick auf die Elektronik des Steuergeräts, um die dort eingebauten
Quarzoszillatoren zu identifizieren. Wenn es sich wirklich um ein
uraltes Gerät handelt, dürften da noch keine allzu modernen PLLs verbaut
sein, die beliebige Takte ineinander "umrechnen".
Weiterhin solltest Du vorzugsweise eine deutliche Überabtastung des
HSYNC-Signals betreiben und den Pixeltakt daran ausrichten, ggf. mit
experimenteller Bestimmung eines sinnvollen Versatzes um Bruchteile des
Pixeltaktes. Um Synthesezeit einzusparen, kann es sinnvoll sein, diesen
Versatz per DIP-Schalter o.ä. am FPGA von außen einstellbar zu machen.
>Auf externes (asymmetrisches) Signal synchronisieren?
Was ist denn in Deinem Sprachgebrauch ein "asymmetrisches" Signal?
Peter schrieb:> Erste Idee wäre jetzt, meinen Pixeltakt zum Einlesen irgendwie auf die> Flanke des H-Sync Signals des Steuerrechners zu synchronisieren.
Das wäre in der Tat eine gute Idee, weil DAS!!!! die ureigenste Idee
beim frame buffering ist, nämlich vollsynchron zu arbeiten.
Da kannst natürlich deine internen Takte auch auf den Schlafrythmus von
Sigmar Gabriel, die Mondphasen von Marsmond Europa oder den Busfahrplan
von Wipperfürt synchronisieren, aber dann zappelt das Bild weiter.
@Andreas
Ahh, gute Idee, danke!
Ich werde mal genauer in die Kiste gucken.
Ein schönes 80er Bauteilgrab, 2x Platinen ~A3 Format, alles THT
natürlich.
Da wird sich bestimmt was finden.
Und HSYNC überabtasten / Takt verschieben ist auch in absehbarer Zeit
ausprobiert.
@ Weltbester ... (was bitte ist ein Pongo? :-))
Asymmetrisch im Sinne von on-time >> off-time.
Ich wusste nicht ob das relevant ist, deswegen wollte ich es
vorsichtshalber erwähnen. ;-)
Danke für die Bestätigung meiner glorreichen Idee!
Sozi-Sigmars Schlafzyklus war der erste, offensichtliche Gedanke.
Immerhin sollte es ja eine besondere Beziehung zwischen den Beiden geben
- auf der einen Seite der Lenker der Arbeiterpartei, auf der anderen
Seite das Werkzeug des Facharbeiters.
Könnte er sie nicht auch führen, die Maschine, mit gleicher Konsistenz,
Konsequenz und Nachhaltigkeit?
Ich habe mich dann letztlich lieber doch für HSYNC entschieden.
Falls du mich in die richtige Richtung stupsen möchtest, tu dir keinen
Zwang an. ;-)
Peter
@Peter (Gast)
>Und zwar zittern die Pixel um einen Pixel horizontal. (manchmal sogar>als diagonales Muster erkennbar, aber nicht überall) Ich nehme an das>liegt daran, dass ich weder die genaue Pixelfrequenz kenne noch die>Ausgabe und mein Einlesen synchron sind.
So ist es. Das klassische Problem bei unsynchronisierter Abtastung,
genauer, dein Abtasttakt vom FPGA ist nicht phasenstarr zum Pixeltakt
deiner Quelle.
Gute Digitalmonitore etc. haben eine "echte" PLL, die sich phasenstarr
auf den H-Sync synchroniesiert und damit einen phasenstarren Pixeltakt
erzeugt. Dann zittert auch nix mehr.
>Die Frage ist nur, wie würde man das angehen? Hat der FPGA Boardmittel,>die ich dafür benutzen kann? Wenn nicht, nach welchen Konzept könnte man>das erreichen?
Hmm, mit viel Firepower könnte man das schaffen, Stichwort volldigitale
PLL. Darüber hab ich mal ne Diplomarbeit geschrieben ;-)
Man nehme einen tierisch hohen Takt, sagen wir 100-200 MHz und
synchronisiere sich auf die Flanke von H-Sync. Als Oszillator nimmt man
einen DCO (digital controlled oscillator), je nach Anforderung einen
sehr einfach gestrickten (wie im originalen 74HC297) oder etwas cleverer
auf DDS Basis. Phasenvergleicher, Schleifenfilter, fertig ist die
volldigitale PLL.
Mit etwas Glück und feststehendem Pixeltakt kommt man auch etwas
einfacher ans Ziel, letztendlich muss man ja nur die Flanke mit
möglichst hoher Zeitauflösung synchronisieren und dann mit festem,
geteiltem Takt, abtasten. Wenn der Takt deutlich über der Pixelfrequenz
liegt (64ns = 15,625 MHz), kann man mit Subpixel Zeitauflösung die
Abtastphase festlegen und damit praktisch jitterfrei abtasten. Ich sag
mal Faktor 4-10 sollte reichen, macht max. 160 MHz, das ist kein Thema
für ein modernes FPGA.
Danke für die Antwort!
So ähnlich habe ich mir das vorgestellt, probiere ich aus wenn ich
wieder wach bin. ;-)
Der MMCM des Artix haben anscheinend ziemlich coole features, vom
manuellen Verschieben der Phase im Betrieb bis hin zu externem feedback
im PLL Modus. Hätte ja sein können dass man das damit schon
abfrühstücken kann und das jeder weiß nur ich nicht. (Und dann im
stillen Kämmerlein das Rad neu erfinde...in kantig, und unwuchtig, nach
langer Arbeit ;-))
Ich probiere das erst einmal so und hebe mir das Erkunden des MMCM für
die nächsten verregneten Sonntage auf. :-)
Peter
@Peter (Gast)
>Der MMCM des Artix haben anscheinend ziemlich coole features, vom>manuellen Verschieben der Phase im Betrieb bis hin zu externem feedback>im PLL Modus. Hätte ja sein können dass man das damit schon>abfrühstücken kann und das jeder weiß nur ich nicht.
Nun ja, soweit mir bekannt ist, können die diversen PLLs, DLLs etc.
nicht aus derartig niedrige Frequenzen wie 15 kHz synchronisieren, da
geht das Leben eher bei 5 MHz los. Darum muss man das selber stricken.
Falk B. schrieb:> etztendlich muss man ja nur die Flanke mit> möglichst hoher Zeitauflösung synchronisieren und dann mit festem,> geteiltem Takt, abtasten.
Das wird man bei einem Takt dieser Grössenordnung nicht einfach genau
genug hinbekommen. Ich habe für eine andere APP einen selbstanpassenden
Quarzteiler geschrieben, der in der Lage ist, einen Teiler bis auf ein
Digital genau anzupassen. Das braucht(e) man, wenn die Frequenz nicht
genau genug bekannt ist und sich ändern kann. Die exakte Frequenz wird
im FPGA durch Verschieben der IO-Delays vollzogen, die einen Takt
dynamisch um z.B. 1/(128+k) einstellen kann. Man bekommt z.B. aus einem
festen 27.00xxx MHz-Quarz genau die 27.yyyy MHz raus, deren Teilung
langfristig synchron zu dem echten HSYNCH ist, dessen 27MHz-Quelle man
nicht direkt sieht. Der Rest geht asynchron auf Takteebene mit FiFos.
Einfacher und für den hiesigen Zweck auch noch ausreichen wäre ein
Abtasten, das asynchron auf Datenebene liefe, also Zeilenweises
übernehmen und völlig unsynchronisiertes Ausgeben. Damit ist die Ausgabe
immer taktstabil, es kommt nur zu Datenbrüchen, wenn die die Zeilen sich
"sehen". Bei Displayanwendungen ist das aber unerheblich.
Falk B. schrieb:> Nun ja, soweit mir bekannt ist, können die diversen PLLs, DLLs etc.> nicht aus derartig niedrige Frequenzen wie 15 kHz synchronisieren,
Von einer so geringen Frequenz ausgehend nach "oben" zu gehen, würde
auch gewaltigen Jitter produzieren. Besser ist es, eine möglichst hohe
Frequenz runterzuteilen und "unten" zu synchen.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten