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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.