Hi, Weiss jemand zufällig wie schnell die der I2C Bus der DDC-Schnittstelle von DVI/HDMI getaktet ist? Schaff ich da einen ATmega88 mit 20 MHz anzuhängen? Grüsse, Fabian
Da der I2C-Bus dazu dient, das EDID-EEPROM im Monitor auszulesen, und I2C selten mit mehr als 400 kHz spezifiziert wird, sollte das praktisch jeder µC hinbekommen. Was hast Du denn genau vor?
Klingt gut, vielen Dank! Ich habe mir einen 8" Digitalfotorahmen mit Touchscreen für wenig Geld gekauft. Der hat ein normales paralleles RGB Interface und ich möchte da eine Benutzeroberfläche anzeigen. Leider kriege ich auch mit AT32UC3 und FPGA als GPU nicht ausreichend Daten dahin und es ist viel zu kompliziert. Jetzt versuche ichs mit einem TFP401A von Texas Instruments, einem DVI Receiver. Da füttere ich die TMDS-Signalpaare rein und auf der anderen Seite kommt paralleles RGB raus. Da ich zudem noch gerne Befehle wie Helligkeitsänderung über DDC empfangen möchte muss ich sowieso einen MCU an den DDC-Bus hängen, also spar ich mir das EEPROM gleich und schreib meine EDID direkt in den MCU. Mal sehen ob das klappt, DVI soll ja sehr heikel und störanfällig sein… Immerhin sind es nur 800x600 Pixel, das sollte kein allzuhoher Datendurchsatz erzeugen. Grüsse, Fabian
Fabian Schuiki schrieb: > Mal sehen ob das klappt, DVI soll ja sehr heikel und störanfällig sein… Naja, ich hatte mal testweise eine Platine mit dem TFP401A gemacht, war sogar mit SprintLayout gemalt und hab damit ein 800x600 Display angesteuert. Das ging wunderbar und da hab ich nix mit impedanzkontrollierten Leiterbahnen usw. gemacht.
Hallo Fabian, Fabian Schuiki schrieb: > Leider kriege ich auch mit AT32UC3 und > FPGA als GPU nicht ausreichend Daten dahin und es ist viel zu > kompliziert. Hm, ein FPGA schafft das locker, irgendwo hast du einen "Flaschenhals" ;-) > Jetzt versuche ichs mit einem TFP401A von Texas Instruments, einem DVI > Receiver. Da füttere ich die TMDS-Signalpaare rein und auf der anderen > Seite kommt paralleles RGB raus. Das wird so nicht einfacher (im Gegenteil), und auch hier muss ein kontinuierlicher Datenstrom vorliegen, sonst hast du kein (stabiles) Bild. Wo kommt dieser Datenstrom her ? > DVI soll ja sehr heikel und störanfällig sein… Davon hab ich so noch nix gehört. Irgendwelche Quellen ?
Christian R. schrieb: > Das ging wunderbar und da hab ich nix mit > impedanzkontrollierten Leiterbahnen usw. gemacht. Das klingt sehr vielversprechend, das hab ich nämlich auch nicht gemacht. Nur Widerstände in den Leitungen um die Reflexionen einzudämmen. Hab ich aber auch nur gemacht weil das Originalboard von Agfa diese auch hat ^^. Uwe N. schrieb: > Hm, ein FPGA schafft das locker, irgendwo hast du einen "Flaschenhals" Das Bild kriegt er schon ganz hübsch hin, aber um da irgendwas sinnvolles anzuzeigen, muss ich ja auch Blitting-Funktionen in den FPGA packen, sodass der AT32UC3 nicht ständig Bilddaten nachzeichnen muss, sondern einfach Texturbefehle senden kann. Und da ich gerne ein bisschen Animation im Interface hätte (Transparenzänderung, Zoom), würde das wohl auch zum Anschlag kommen. V.a. so eine GPU selber zu entwickeln soll ja laut Nvidia ein minimaler Arbeitsaufwand sein ;) . > Das wird so nicht einfacher (im Gegenteil), und auch hier muss ein > kontinuierlicher Datenstrom vorliegen, sonst hast du kein (stabiles) > Bild. > Wo kommt dieser Datenstrom her ? Der Datenstrom kommt von der Grafikkarte eines ZOTAC Micro-PCs mit Linux, sollte also nicht wirklich ein Problem darstellen. Im grossen und ganzen versuche ich, einen 8" 800x600 Computermonitor zu bauen, der zusätzlich noch einen Touchscreen über USB exponiert. >> DVI soll ja sehr heikel und störanfällig sein… > > Davon hab ich so noch nix gehört. Irgendwelche Quellen ? Nein leider nicht, hab nur auf dem Originalboard die längenkorrigierten Leiterbahnschlingen gesehen und hab mir zusammen mit ~1Gbit Datenrate einen Reim daraus gemacht. Schön wenn ich falsch liege :). Achja vlt. weiss das jemand: Mein Display will HSYNC und VSYNC invertiert haben. Ist das ein Feature, dass ich im EDID konfigurieren kann oder muss ich einen schnellen Inverter zwischen DVI Empfänger und LCD setzen der das realisiert? Grüsse und vielen Dank für die Antworten :) Fabian
Fabian Schuiki schrieb: > ... hab nur auf dem Originalboard die längenkorrigierten > Leiterbahnschlingen gesehen und hab mir zusammen mit ~1Gbit Datenrate > einen Reim daraus gemacht. Ein Längenabgleich der LBs ist nicht wirklich kritisch (ausser man vergisst es :-)), und die Tatsache, das DVI differentielle Signale verwendet macht das ganze ja schon Störungstoleranter. Ich würde schon versuchen, möglichst viele Bildfunktionen in den FPGA auszulagern (-> Microblaze, PLASMA o.ä.), damit der AT32UC3 noch was anderes machen kann ausser der Bildverarbeitung. Ist natürlich auch eine Frage der zur Verfügung stehenden FPGA-Ressourcen.
Uwe N. schrieb: > Ist natürlich auch eine Frage der zur Verfügung stehenden > FPGA-Ressourcen. Zur Verfügung stehen würde ein Xilinx XC3S50. Das ist der einzige der genügend IO hat in einem für mich lötbaren Gehäuse. Ich denke ich werde es zuerst mal mit dem TFP401A versuchen :) Grüsse, Fabian
Fabian Schuiki schrieb: > Zur Verfügung stehen würde ein Xilinx XC3S50. Hm, naja, in den Mini-Krümel passt ja nix sinnvolles rein....da solltest du vielleicht mal über ein kleines Board nachdenken, wo ein BGA drauf sitzt und die I/Os nach außen geführt sind auf normale Steckerleisten...gibts ja von verschiedenen Firmen.
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.