Hallo liebe Hobby/Geschäftsbastler, Ich habe ein kleines Verständnisproblem. Ich habe von einem Kollegen ein TFT-Display geschenkt bekommen. Das Datenblatt dazu findet ihr im Anhang. Jetzt habe ich zwei große Fragen: 1. Im Datenblatt auf Seite 16 bzw. 8-6/6 findet ihr die Anschlussbelegung der Anschlussbuchse (typische LIF/ZIF Version). Da ist von 6 Bits für jede Farbe die Rede, ich kenne aber nur die drei Bit-Variante MSB -> 2. Bit -> LSB Nun die Frage: Muss ich hier eine andere Ansteuerungsart verwenden bzw. eine andere Ansteuerungsschaltung, da hier ja 6 Bits für jede Farbe verwendet werden ? 2. Es wird überall im Zusammenhang mit (TFT)Displays sehr oft von FPGA's / CPLD's als Videoansteuerung gesprochen. Ich habe einmal gaaanz grob :-) ein Bild hingekritzelt, Anhang 2, wie ich mir die Darstellung auf dem TFT denke.(ja, ohne Farbe, nur s/w, oder sonst irgendwelchen Spielereien.) Würde Ich das auch mit einem AVR hinkriegen ? z.B Atmega32 ? Oder muss ich doch zu einem FPGA/CPLD greifen ? Wenn ja, dann wäre die Sache gestorben, denn die Welt der FPGA/CPLD will mir nich so richtig in Kopf. Verstanden hab ich die Materie einigermaßen: Man programmiert einen IC mit Logikgattern und FlipFlops und dem Zeugs in VHDL oder ABEL oder Verilog, daraus werden dann die integrieten Schaltkreise im FPGA/CPLD gebildet. Aber wie in Gottes Namen kann ich dann so eine Ansteuerung für ein Display machen, da müsste ich doch dann gleich ne halbe Grafik-CPU programmieren, oder ? :-S Wenn irgendjemand n Denkansatz für mich hätte, wäre ich euch sehr dankbar. bis die Tage, euer christian_k edit: Wenn ich im falschen Forum hiermit bin, Bitte an die Moderatoren, mich in die richtige Ecke verschieben. Danke !
Angehängte Dateien:
-
Unbenannt.png
682 Bytes
>Da ist von 6 Bits für jede Farbe die Rede, ich kenne aber nur die drei >Bit-Variante MSB -> 2. Bit -> LSB MSB -> 4. Bit -> 3. Bit -> 2. Bit - >1. Bit -> LSB ? >(ja, ohne Farbe, nur s/w, oder sonst irgendwelchen Spielereien.) Na, dann haste auch nur 1 Bit. Einfacher geht es nicht, hm? :-) >Würde Ich das auch mit einem AVR hinkriegen ? z.B Atmega32 ? Ja, 320x240 ist vom Timing vermutlich noch machbar. Du hast halt nicht genug Speicher für eine komplette Bildseite und must deine Inhalte dann zur Laufzeit mit 'Tricks' erzeugen, aber ich behaupte mal, das ist nicht so wild solange deine Ansprüche in einem realistischen Rahmen bleiben. ;-) >Aber wie in Gottes Namen kann ich dann so eine >Ansteuerung für ein Display machen, da müsste ich doch dann gleich ne >halbe Grafik-CPU programmieren, oder Nö, wieso? Ein paar Zähler für die sync-Geschichte und evtl. Adresszähler für Framebuffer falls gewünscht, halb so wild. Jedenfalls wenn du nicht gleich irgendwelche linedraw Funktionen usw. hardwareseitig implementieren willst.
dave schrieb: > MSB -> 4. Bit -> 3. Bit -> 2. Bit - >1. Bit -> LSB ? wie müsste ich das in diesem Fall dann ansteuern ? Mich verwirren die zusätzlichen Bits ein wenig... > Na, dann haste auch nur 1 Bit. Einfacher geht es nicht, hm? :-) OK, das hört sich ja schon mal sehr gut an. Wie realisiere ich dann mit dem Atmega 32 die Ansteuerung ? Hast du mir evtl. ein paar Schaltplan-vorlagen oder Anregungen ? Sorry für die vielen Fragen, hab noch nicht mit graphischen TFT( digitaler RGB) gearbeitet, nur mal hie und da gelesen.. > Ja, 320x240 ist vom Timing vermutlich noch machbar. > Du hast halt nicht genug Speicher für eine komplette Bildseite und must > deine Inhalte dann zur Laufzeit mit 'Tricks' erzeugen, aber ich behaupte > mal, das ist nicht so wild solange deine Ansprüche in einem > realistischen Rahmen bleiben. ;-) > Hm... an welche Trickkiste denkst du ? Ich hätte jetzt an einen externen Speicher per I2c oder SPI Bus gedacht, oder ist der zu langsam ? > Nö, wieso? Ein paar Zähler für die sync-Geschichte und evtl. > Adresszähler für Framebuffer falls gewünscht, halb so wild. > Jedenfalls wenn du nicht gleich irgendwelche linedraw Funktionen usw. > hardwareseitig implementieren willst. OK, ich kapituliere. Das sind schon bömische Dörfer von wegen Zähler und Adressgeschichten, sorry :-)
>Wie realisiere ich dann mit dem Atmega 32 die Ansteuerung ? Alle Farbbits zusammen an einen Portpin. Dazu musst du noch gemäß dem Diagramm auf s.12 die Signale wie Hsync, DTMG, DCLK erzeugen usw. Dazu brauchts auch keinen Schaltplan, das ist ein software-Problem was zu lösen ist. >nur mal hie und da gelesen.. Am Besten mal sehr gründlich das Datenblatt lesen und verstehen, wie der ganze Kram ablaufen soll. >Hm... an welche Trickkiste denkst du ? Ich hätte jetzt an einen externen >Speicher per I2c oder SPI Bus gedacht, oder ist der zu langsam ? 320x240x1Bit bei z.B. 60 Bildern/s würde eine Datenrate von 4,6Mbit/s nur zur Ausgabe des Bildes erfordern. Ich glaube nicht, dass das mit einem AVR so gut klappt. (Zwischendurch müssen ja auch noch Daten rein.) Dann schon eher ein paralleles SRAM. Wenn du nicht unbedingt jeden Pixel einzeln verändern können musst, geht es auch ohne externen Framebuffer. Du kannst dir im AVR z.B. einen Zeichensatz aus 8x8 Pixel blöcken erstellen und dann damit arbeiten. Es gibt div. AVR VGA-Terminal Projekte, schau dir die mal an und lass dich inspirieren. :-) >Das sind schon bömische Dörfer von wegen Zähler Schau dir einfach mal die timing charts auf Seite 12 an und überlege dir, wie man zyklisch solche Signalformen erzeugen könnte. Vielleicht kommt dir dann eine Idee.
Hallo Christian, ich habe zufälligerweise vor kurzem so etwas entwickelt und dann auf der embedded display conference einen Vortrag drüber gehalten. Daher kann ich dir aus Erfahrung sagen, dass das Ganze nicht besonders aufwändig ist, allerdings schon ein FPGA-Design erfordert. In meinem Fall habe ich den Display Controller, der die Daten- und Timing-Signale für das Display erzeugt, im FPGA realisiert, und dem FPGA einen externen Speicher für die Bilddaten spendiert. Das führt zur Frage, wie die Bilddaten in den Speicher kommen. Dazu habe ich einen NIOS-Prozessor in das FPGA gesetzt, der vom Hauptrechner die Daten via SPI annimmt und in den externen Speicher schreibt. Alles in allem überschaubar und trotzdem sollte man für so etwas einige Erfahrung im FPGA-Design haben. Unsere Firma veröffentlich solche Designs zum Teil. Schau doch mal nach bei embedded-platform.com -> download -> ADON02, so heißt das Board. Du müsstest Dich zwar registrieren, aber wir nerven unsere User nicht mit Mails etc. Grüße, Harald
Ich hab sowas auch schonmal mit einem Xmega128A1 probiert. Allerdings im 5-5-5 er Format. Also jeweils 5 Bit je Farbe. Eventfunktionen benutzt, Xmega übertaktet und trotzdem war das Resultat ernüchternd. Das ist eine verdammt hohe Datenmenge die da kontinuierlich ins TFT geschaufelt werden muss. Ich hatte da einen 16Mb SDRAM dran hängen. Allerdings können die Xmegas bloß 4Bit´s lesen in einem Zyklus. Das bremste die ganze Sache so ungemein aus. Hier mal der Link dahin Beitrag "Re: Xmega Programmierung in ASM" Grüße Steffen
Hey Leute, tut mit leid, aber ich war krank mit 40°C Fieber. Musste also alles ein bischen warten. @dave > Dazu brauchts auch keinen Schaltplan, das ist ein software-Problem was > zu lösen ist. ähm... ok, wie kann ich die Timer dazu missbrauchen ? So dass diese im passenden Verhältnis sind ? > Dann schon eher ein paralleles SRAM. Welchen Atmega kannst du mir empfehlen, der nen passenden Anschluss für nen parallelen SRAM hat ? > Wenn du nicht unbedingt jeden Pixel einzeln verändern können musst, geht > es auch ohne externen Framebuffer. > Du kannst dir im AVR z.B. einen Zeichensatz aus 8x8 Pixel blöcken > erstellen und dann damit arbeiten. Hast du ne Bascom-Lösung oder Ansatz ?
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.