Hallo, ich möchte ein TFT-Display ansteuern. Insgesamt hat das Teil 24 Daten-Pins. Nun meine Frage: Komm ich da mit nem Atmega16 hin? Außerdem kann ich die Pins ja nicht genau gleichzeitig schalten, stört das im Betrieb? Gibts da noch nen Controller zum dazwischenhängen, damit der Atm16 nicht so viel zu tun hat? Habe den AVR32 LCD Controller auf meiner Recherche gefunden. Hilft der mir bei meinem Vorhaben? Für erste Tests würde mir auch eine einfache 2-Farb-Ansteuerung reichen. Da dürften ja weniger Daten-Pins reichen (wenn man weiß welche^^) Hier mal das Datenblatt zum Display: http://ics.nxp.com/support/design/microcontrollers/lcd.controller/innolux/pdf/datasheet.pdf
Du könntest mit 8-fach D-FlipFlop-ICs arbeiten, damit alle Signale gleichzeitig ankommen. Fraglich, ob dann die Verarbeitungsgeschwindigkeit reicht. Andererseits kannst du bestimmt auch nur die höchstwertigsten Farb-Bits übertragen, da könntest du mit 8 Bit (bzw. 6 mit 2bit pro Farbe) hinkommen. Zudem habe ich gesehen, dass es eine serielle (3-wire) Ansteuermöglichkeit gibt. Schau doch mal, ob der Mikrocontroller dafür schnell genug läuft.
Ein 8 Bit Controller wie der Atm16 ist für ein grafisches Farbdisplay mit 320x240 um den Faktor 10 zu langsam und vom Speicher zu klein. Zum zwischenspeichern des Bildes werden ja schon 32kByte SRAM im Controller gebraucht.
butchja schrieb: > Du könntest mit 8-fach D-FlipFlop-ICs arbeiten Hm, wie tropf schreibt, ist er ATM16 auf jeden Fall zu langsam. butchja schrieb: > Andererseits kannst du bestimmt > auch nur die höchstwertigsten Farb-Bits übertragen Das würde mir für meine Zwecke locker reichen. 2 Bit pro Farbe würden dann insgesamt 6 Bit machen. D.h. 64 verschiedene Farben. Wie ist das bei 24 Bit? Stehen vorne oder hinten die höherwertigen Bit? Wären dann (wenn die höherwertigen vorne stehen): Rot: Data00+Data01 Grün: Data08+Data09 Blau: Data16+Data17 butchja schrieb: > eine serielle (3-wire) Ansteuermöglichkeit gibt. Schau doch mal, ob > der Mikrocontroller dafür schnell genug läuft. 3-wire sagt mir ehrlich gesagt nichts... Hab mir jetzt aber mal den entsprechenden Teil im Datenblatt durchgeschaut. Wäre gut, dann habe ich noch viele Pins übrig. Was braucht er um schnell genug zu sein? (Ist dann ja auch vom Programm abhängig oder?!) siehe unten: Muss auch nicht unbedingt ein Atmega16 sein tropf schrieb: > Ein 8 Bit Controller wie der Atm16 ist für ein grafisches Farbdisplay > mit 320x240 um den Faktor 10 zu langsam Ich bin nicht unbedingt an einen ATM16 gebunden. Ich setze auch gernen einen anderen ein. Aber wie oben beschrieben würden mir auch 6 Bit Farben reichen. Dafür dürfte der ATM16 ausreichend dimensioniert sein, oder? (Habe auch noch ATM8 und ATM32 hier rumfliegen, ATM16 müsste ich eh erst bestellen) Die 3-Wire-Technik scheint nicht schlecht zu sein (wenn es denn so einfach umzusetzen ist). Habe leider noch keine Seite gefunden wo das gut erklärt ist.
Das Display braucht wahrscheinlich einen Pixeltakt von 4-5MHz, d.h. aller 200ns muss ein neues Pixel an das Display geschickt werden. Ob das nun 1bit oder 24bit Farbtiefe hat, spielt erstmal keine Rolle. Dafür dürfte so ziemlich jeder normale uC zu langsam sein. Von Microchip gibt es einige PIC24 mit eingebautem Grafikkern oder von Epson die üblichen LCD-Controller. Allerdings ist die Einarbeitung in diese Controller ein gewaltiges Stück Arbeit.
Michael N. schrieb: > Komm ich da mit nem Atmega16 hin? Außerdem kann ich die Pins ja nicht > genau gleichzeitig schalten, stört das im Betrieb? Nein, vergiss es. Schau Dir den NXP LPC2478 an, das ist genau das Richtige dafür. Oder den PIC24FJ128DA210. Die haben passende TFT-Controller eingebaut und sind eine ganze Ecke schneller als ein AVR. fchk
Entschuldigung aber das "zu langsam" Argument kann man so einfach nicht behaupten, wenn man nicht genau weiß, was der OP genau machen will. Einfacher Text mit 8x9 Pixeln geht ziemlich einfach, auch mit einem AtMega 16. Pixel mit halber Taktfrequenz auszugeben ist trivial möglich, beispielsweise über den SPI.
Christian Berger schrieb: > Entschuldigung aber das "zu langsam" Argument kann man so einfach nicht > behaupten, wenn man nicht genau weiß, was der OP genau machen will. Doch, das kann man behaupten: Der TO benötigt eine ca.5MHz Pixelcklock (@60Hz), dazu die H- und V Sync Signale, dies alles in Software. Lassen wir einen x-beliebigen AVR mit 20MHz arbeiten, (ich weiß, kann nicht jeder bei jeder Spng.), dann bedeutet das für den µC: alle 4 Takte muss der RGB-Datenbus aktualisiert werden und die entsprechenden Sync-Signale generiert werden. Das ist halt nicht zu machen, selbst wenn der µC nichts anderes zu tun hat (4 Takte sind im besten Fall 4 Befehle). Es ist auch egal, ob der TO nur Text oder auch Grafik (ob 1,2 od. 24Bit) anzeigen will, weil das verwendete LC-Display keinen VideoRAM besitzt muss der µC den Bildschirminhalt ständig (60x/ s) erneuern. Den AVR32 kenn ich nicht, der hat AFAIK ja eine entsprechende Schnittstelle eingebaut, damit sollte es klappen. Gruss Uwe P.S. Die serielle Schnittstelle des LCD-Moduls hab ich allerdings noch nicht ganz verstanden: darüber werden keine Bilddaten übertragen, nur einige Parameter wie Sättigung, Kontrast oder Eingangsformat ?
Es geht zwar auch ohne speziellem Display-Controller, aber nur mit externer Hardwareunterstützung und erheblicher Reduktion des Farbraums. Beispielsweise orientiert an Benedikts Projekten oder meiner VRAM-Variante. Allerdings ist das präsentierte Datasheet wohl nicht ausreichend, da die via serieller Schnittstelle bedienten Steuerregister nahezu undokumentiert sind.
Uwe N. schrieb: > Es ist auch egal, ob der TO nur Text oder auch Grafik (ob 1,2 od. 24Bit) > anzeigen will, weil das verwendete LC-Display keinen VideoRAM besitzt > muss der µC den Bildschirminhalt ständig (60x/ s) erneuern. Benedikt hatte eine Variante mit S/W-LCDs als Textschirm ohne vollständigen Videospeicher gebaut, mit just-in-time Umsetzung der Zeichen zu Grafik in einem Mega8. Der dort verwendete Schirm hatte zwar 4 aufeinanderfolgende Bits als Displaywort, was den Displaytakt viertelt, aber dem liesse sich mit einem Schieberegister vielleicht nachhelfen. Das Prinzip liesse sich wohl von S/W auf 4 Farben aufbohren, aber mehr wäre sicherlich nicht drin.
Du meinst dieses hier ? Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" A. K. schrieb: > Der dort verwendete Schirm hatte zwar 4 aufeinanderfolgende Bits als > Displaywort, was den Displaytakt viertelt, aber dem liesse sich mit einem > Schieberegister vielleicht nachhelfen. Hm, das funktioniert hier leider nicht (rein aus dem Bauch heraus).
Uwe N. schrieb: > Hm, das funktioniert hier leider nicht (rein aus dem Bauch heraus). Direkt nicht. Ansatz: Zwei externe 4-Bit Schieberegister dran, ergibt 2 Bit pro Pixel also 4 Farben. Dazu etwas Drumrum mit Zähler, um bei jedem Schreibvorgang in die Schieberegister 4 Displaytakte zu erzeugen. Ob der Code passend umgebaut werden kann um statt 4 Bits nun 8 Bits zu produzieren weiss ich grad nicht.
Problem ist halt wirklich, dass Benedikt 4 Pixel auf einmal schreiben konnte. Das geht beim angehängten Display nur mit extra Hardware. Und auch dann hast du nur 1 bit pro pixel. Vielleicht 2. Aber mehr dürfte dem Gefühl nach nicht drin sein. Und dann ists eigentlich etwas schade um das Display. Da gibts genug Graustufen-Panels für 5-10€ die das genauso gut können. Bzw sogar besser - die kann der AVR nämlich auch mit 3bpp ansteuern ;) Wenn du dieses Display mit einem AVR ansteuern willst solltest du auf jeden Fall einen externen displaycontroller verwenden. Benedikt hat auch da mal was umgesetzt: Beitrag "VGA Grafikkarte mit AVR und 8MB SDRAM" Glaube, den Displaykontroller hat erst ab etwa der hälfte des Threads verwendet. Einfach mal reinschaun. Und um gleich noch etwas Eigenwerbung zu machen: Den Passenden Controller (Epson S1D13504) hab ich grad übrig. Vielleich hab ich auch noch nen RAM, müsste ich mal schaun ;) Aber schau dir auf jeden Fall vorher das Datenblatt des Controllers an, ob der sich wirklich mit dem Display verträgt Am Sinnvollsten ists wohl, nen ARM oder ähnliches mit integriertem Displaycontroller zu verbauen. Der bringt dann auch die nötige Performance, um das Display in angemessener Zeit mit Inhalt zu füllen. Viele Grüße, Sebastian
Frank K. schrieb: > Michael N. schrieb: > >> Komm ich da mit nem Atmega16 hin? Außerdem kann ich die Pins ja nicht >> genau gleichzeitig schalten, stört das im Betrieb? > > Nein, vergiss es. Schau Dir den NXP LPC2478 an, das ist genau das > Richtige dafür. Oder den PIC24FJ128DA210. Die haben passende > TFT-Controller eingebaut und sind eine ganze Ecke schneller als ein AVR. > > fchk Wie soll ich so ein Ding nur jemals verlöten (auf Lochraster ;) )... Naja da würd ich mir halt nen Adapter kaufen. Wie läuft das dann mit den Controllern? Kann mir das leider noch nicht vorstellen, wo dann zB die Daten für das Display generiert werden. Läuft das komplette Programm dann darauf oder ist weiterhin zB ein Atmega dafür zuständig? Uwe N. schrieb: > Den AVR32 kenn ich nicht, der hat AFAIK ja eine entsprechende > Schnittstelle eingebaut, damit sollte es klappen. Hier mal das entsprechende Datenblatt (genau das scheint es nichtmehr zu geben, aber besimmt irgendeinen Nachfolger): http://www.atmel.com/dyn/resources/prod_documents/doc32063.pdf Sebastian ... schrieb: > Problem ist halt wirklich, dass Benedikt 4 Pixel auf einmal schreiben > konnte. Das geht beim angehängten Display nur mit extra Hardware. Und > auch dann hast du nur 1 bit pro pixel. Vielleicht 2. Aber mehr dürfte > dem Gefühl nach nicht drin sein. Und dann ists eigentlich etwas schade > um das Display. Lieber ein einfarbiges funktionierendes Display als eines das im Schrank verstaubt ;) Trotzdem wäre etwas Farbe (zumindest je 2 Bit pro Farbe) schon wünschenswert. Wenn ein solcher AVR32-LCD-Controller nicht all zu teuer ist, würde ich gerne den nehmen. Im Datenblatt steht
1 | TFT single scan display |
2 | Up to 24 parallel data lines are used to shift data to successive horizontal lines one at |
3 | a time until the entire frame has been shifted and transferred. The 24 data lines are |
4 | divided in three bytes that define the color shade of each color component of each |
5 | pixel. The LCDD bus is split as LCDD[23:16] for the blue component, LCDD[15:8] for |
6 | the green component and LCDD[7:0] for the red component. If the LCD Module has |
7 | lower color resolution (fewer bits per color component), only the most significant bits |
8 | of each component are used. |
Soweit sollte das ja passen. Allerdings steht auch drin: The needed bandwidth is (320 x 240 x 24/8 x 60 Byte/s = 13.8MB/s) 13.8MB/s...This is feasible by the AVR32AP7000 as it can handle up to 300MB/s on the external bus interface. Super d.h. ich brauch nen AVR32AP7000 und der hat immerhin 256 Pins !!!! Also wenn ich mir die Komplexität ansehe, reicht mir das ganze wirklich einfarbig oder halt normal RGB (je 1 Bit). Aber selbst das scheint ja mit "normaler" Hardware für einen Hobbybastler nicht lösbar zu sein. Für jede Farbe nen eigenen Mikrocontroller^^ Gibts denn für 3 Bit TFTs eine gute Ansteuerhardware? Dann nehm ich halt wie oben beschrieben nur die höchstwertigen Bits. edit: Gibts einen billigen Controller mit dem man dann das Display vom PC aus ansteuern kann? Nen schöner Dual-Core mit je 3,16GHz bringt etwas mehr Power, der könnte ja das Display mit genügend Daten versorgen. Hab mich mal umgeschaut. Fertige Lösungen gibts da ja viele, hab aber noch nichts einfaches für eigene TFTs gefunden. Anschluss wäre am besten USB...
Michael N. schrieb: > Frank K. schrieb: >> Michael N. schrieb: >> >>> Komm ich da mit nem Atmega16 hin? Außerdem kann ich die Pins ja nicht >>> genau gleichzeitig schalten, stört das im Betrieb? >> >> Nein, vergiss es. Schau Dir den NXP LPC2478 an, das ist genau das >> Richtige dafür. Oder den PIC24FJ128DA210. Die haben passende >> TFT-Controller eingebaut und sind eine ganze Ecke schneller als ein AVR. >> >> fchk > > Wie soll ich so ein Ding nur jemals verlöten (auf Lochraster ;) )... > Naja da würd ich mir halt nen Adapter kaufen. > Wie läuft das dann mit den Controllern? Kann mir das leider noch nicht > vorstellen, wo dann zB die Daten für das Display generiert werden. Läuft > das komplette Programm dann darauf oder ist weiterhin zB ein Atmega > dafür zuständig? Da gibt es einen Satz an Registern, in denen Du die Displayparameter (Pixelgröße, Farbtiefe, Timings etc) und die Adresse des Bildschirmspeichers reinschreibst. Der Controller sorgt dann selber für den Bildaufbau. Du musst nur noch die Daten in den Bildschirmspeicher reinschreiben. > Gibts denn für 3 Bit TFTs eine gute Ansteuerhardware? Dann nehm ich halt > wie oben beschrieben nur die höchstwertigen Bits. Nur mit Lochraster wirst Du nicht weit kommen, sorry. fchk
Michael N. schrieb: > Wie soll ich so ein Ding nur jemals verlöten (auf Lochraster ;) )... Wie kriegst du das Display an Lochraster angeschlossen? 2,54er Raster wird das Folienkabel wohl kaum haben. Ein Ansatz für Lochraster, der 16 oder 256 Farben hergibt, basiert auf VRAMs wie in Beitrag "Re: Grafik-LCD Controller mit AVR und VRAM", aber mit grösseren VRAMs als dort. 256Kx4 VRAMs gibts als Restbestand bei Segor in ZIP28. Die Pins sind da zwar eigentlich versetzt angeordnet, lassen sich aber auch in zwei einreihige gedrehte Sockelleisten wuchten.
Jetzt muss ich nun auch mal meinen Senf dazu abgeben. Wenn du das Display schon gekauft hast dann sag ich mal das war sehr voreilig. Wenn nich dann lass es sein und versuch erst einmal kein anzufangen mit einem Einfachen Textdisplay. Eventuell danach ein kleines S/W Grafik Display mit einem KS108/107 oder T6963. Bei so einem Display kommst du um SMD einfach nicht rum. Und mit nur einem Prozessor ist es auch nicht unbedingt getan. Bei so was wie dem LPC2478 oder AP7000 brauchste noch entsprechend RAM und das ist nicht mal schnell mit dem Steckbrett verdrahtet. Wenns unbedingt farbig sein soll dann nimm lieber sowas http://www.watterott.com/de/MI0283QT-2-Adapter Ist mit entsprechendem Pegelwandler von 5 auf 3,3 Volt ausgestattet und hat normale Stiftleisten, sowie Touch und lässt sich recht simpel ansteuern über SPI ansteuern. Übers Timing brach man sich keine Gedanken machen. nur noch was man ans Display schicken will. Das Ding kannste dann mit nem ATmegaxx ansteuern. Dennoch kann man sagen mit viel Gehirnschmalz kann mit einem AVR ein SW Display sehr gut ansteuern sieht man ja an Benedikts Text / Grafik Kontroller. Es ist nicht böse gemeint von den Leuten die sagen lass das mit dem TFT erst einmal bleiben sondern eine ernst gemeinte Antwort. Dennoch viel Spaß beim Basteln. MfG Kai
Michael N. schrieb: > Super d.h. ich brauch nen AVR32AP7000 und der hat immerhin 256 Pins !!!! Hat Atmel die AVR32 AP Reihe nicht mittlerweile wieder eingestellt?
Also: 1. 4 Taktzyklen sind eine Menge! 2. Die Schieberegister gibts schon in Form des SPIs. Der kann jeden zweiten Taktzyklus ein Bit ausgeben. Der steuert dann beispielsweise einen Umschalter an, der zwischen 2 Farben auswählt, und schon hat man 2 Farben aus einer großen Palette. Damit kann man beispielsweise Schrift auf vertikalen Farbverläufen darstellen. Hier mal ein kleines Beispiel was denn so geht, wenn man sich ein wenig anstrengt: Beitrag "Re: ATMega32 16 MHz PAL mit Farbe ohne externen Chip" Schaltplan: Beitrag "Re: ATMega32 16 MHz PAL mit Farbe ohne externen Chip" Die Abtastrate des Signales ist übrigens 16 MHz bei 16 MHz Taktrate des Microcontrollers.
@ TO Vielleicht hilft dir der Link weiter. http://cgi.ebay.de/4-3-TFT-LCD-Module-Touch-Panel-Screen-PCB-Adapter-/200519609734?pt=LH_DefaultDomain_0&hash=item2eafe66d86 Das ist ein 4.3" TFT mit lochrasterkompatibler Adapterplatine und TFT-Controller. Ich denke mal, mit dessen Programmierung hast du mehr als genug zu tun. Ist preislich auch noch im erträglichen Rahmen. Viel Erfolg.
Frank K. schrieb: > Der Controller sorgt dann selber für > den Bildaufbau. Du musst nur noch die Daten in den Bildschirmspeicher > reinschreiben. D.h. ich schreibe einmal das Bild, bis sich das halt wieder ändert?! Der Controller sendet das dann zB 60 mal in der Sekunde ans TFT? Frank K. schrieb: > Nur mit Lochraster wirst Du nicht weit kommen, sorry. Mal sehen. Wenn möglich wollte ich ohne selbstgemachte Platinen auskommen. Direkt auf Lochraster wirds natürlich nicht gehen, aber vielleicht bekomm ich das ja mit ein paar "Flugleitern" hin... Nen gescheiden Anschluss für das 60Pin-Kabel bräuchte ich aber auch noch. Mal gucken ob ich da was finde (oder hat jemand von euch sowas schonmal gekauft und zufällig einen Link?) Kai B. schrieb: > Wenn nich dann lass es sein und versuch erst einmal kein anzufangen mit > einem Einfachen Textdisplay. Eventuell danach ein kleines S/W Grafik > Display mit einem KS108/107 oder T6963. Hm, Display ist zwar schon gekauft, war aber nicht so teuer. Mit dem Anfang mit einem Textdisplay könntest du recht haben :) Würde allerdings dann lieber gleich zu einem kleinen Grafik-Display greifen (ist die Ansteuerung dann hier auch ähnlich schwer wie bei meinem schon gekauten Display, oder lässt sich das eher mit dem Testdisplay vergleichen?) Kai B. schrieb: > Es ist nicht böse gemeint von den Leuten die sagen lass das mit dem TFT > erst einmal bleiben sondern eine ernst gemeinte Antwort. Ist schon ok. Hab noch kaum Erfahrung mit der ganzen Thematik, deshalb wende ich mich ja auch an euch. Und wie es aussieht, wird das wirklich nichts mit dem TFT... Kai B. schrieb: > Dennoch viel Spaß beim Basteln. Dankeschön Dann noch eine neue Frage: Wie schwer schätzt ihr den selbstbau einer Grafik-LCD Schaltung (einfarbig) ein, die man per USB-Schnittstelle ansteuern kann (Einiges an Software gibt es ja schon. zB SmartLCD)
Grafik-LCD einfarbig ist insofert relativ leicht, als dass es da von Benedikt schon ein paar Schaltungen gibt: 320*240 Text SW: Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" 320*240 Grafik mit bis zu 8 Graustufen: Beitrag "Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" 640*480 Grafik SW Beitrag "LCD Controller für 640x480 LCD mit mega8515" Und auch andere haben für sowas schon Schaltungen veröffentlich. Die ersten beiden Schaltungen (bei der dritten weiß ichs nicht) kann man über den UART ansteuern. Du könntest also einfach eine USB-UART-Bridge verbauen und vom PC aus dann wie über eine serielle Schnittstelle auf das Display zugreifen. Sollte - je nach vorkenntnissen - ganz gut machbar sein. Auch gibts externe Grafikkontroller die diese Displays ansteuern können und weniger Pins haben, also leichter verlötbar sind. Mögliche Probleme gibts aber trotzdem noch genug ;) Ich hab nochmal etwas nachgedacht: Mit einigem Hardwareaufwand (logikgatter, RAM) könnte man vielleicht mit einer ählichen Schaltung wie bei Benedikts Graustufenansteuerung ein Paar Farben aus deinem Display kitzeln. ABER: Durchgerechnet hab ichs nicht, der Hardwareaufwand ist groß und der Prozessor dürfte sehr stark ausgelastet sein. In Jedem Fall wäre es sinnvoll, Benedikts Schaltung einwandfrei zu verstehen, bevor man versucht, sie anzupassen. Diesen Weg empfehle ich also explizit nicht ;) Viele Grüße, Sebastian
Sebastian ... schrieb: > 320*240 Grafik mit bis zu 8 Graustufen: > Beitrag "Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Wie ist das jetzt genau: Kann ich damit einen TFT ansteuern? Ich glaube es ist ja so, dass bei einem LCD die Bildwiederholrate relativ gering sein kann. (nur bei einer Änderung auf dem Display sollte das natürlich relativ zeitnah geschehen) Bei einem TFT muss sollte man mind. 50mal pro Sekunde das Bild aktualisieren. Stimmen meine Aussagen soweit, gibt es dann noch andere Unterschiede? Reicht die Schaltung von oben dann für mein LCD (natürlich mit verminderter Farbvielfalt) Sebastian ... schrieb: > Du könntest also einfach eine USB-UART-Bridge > verbauen und vom PC aus dann wie über eine serielle Schnittstelle auf > das Display zugreifen. Sollte - je nach vorkenntnissen - ganz gut > machbar sein. Wenn die Steuerung schon für UART ausgelegt ist, dann ist das mit einer USB->UART-Bridge natürlich recht einfach. Sobald das ganze mal am Rechner hängt dürfte ich das denke ich hinbekommen (ist für mich zumindest das kleinste Problem) Sebastian ... schrieb: > Mit einigem Hardwareaufwand > (logikgatter, RAM) könnte man vielleicht mit einer ählichen Schaltung > wie bei Benedikts Graustufenansteuerung ein Paar Farben aus deinem > Display kitzeln. ...oh hab ich ja schon oben gefragt^^ Liese sich mit der Steuerung wenigstens relativ einfach EINE Farbe steuern. Andere Einfarb-Displays sind teurer als das hier, von daher würde mir der Farbverlust wirklich nicht wehtun. Sebastian ... schrieb: > Diesen Weg empfehle ich > also explizit nicht ;) Hm dann bräuchte ich wieder ein Grafik-LCD... Ich überlege schon wegen einem normalen Zeichendisplay (gibts ja dann genügend fertigen Code). Allerdings möchte ich auf jeden Fall unbedingt jemals in meinem Leben einfach Grafik-LCD mit Touch angesteuert haben. Und das hätte ich dann immer noch nicht gemacht. (Wäre aber sicherlich ein guter Zwischenschritt)
>Hm dann bräuchte ich wieder ein Grafik-LCD... >Ich überlege schon wegen einem normalen Zeichendisplay (gibts ja dann >genügend fertigen Code). Allerdings möchte ich auf jeden Fall unbedingt >jemals in meinem Leben einfach Grafik-LCD mit Touch angesteuert haben. Für KS0108 und T6963C Controller gibt es haufenweise Code. Mit KS0108 findet man Displays bis 240x64. T6963C geht bis 240x128. Ist alles monochrom aber zum anfangen reichts für einen AVR. T6963C würde ich bevorzugt nehmen. Dann gibts noch die DOGM. Dann wären da noch diverse Handydisplays, auch in Farbe, aber vergiss die Mäusekinos;) Vergiss den Touch erstmal.
Schau Dir mal ebay #270717542222 oder #290543146877 an. Das sind Displays, die einen eingebauten Displaycontroller und eingebauten Grafikspeicher haben. Das kannst Du problemlos mit einem AVR ansteuern. Ich würde dafür allerdings einen größeren AVR wie einen Mega128 oder mit externem Adress/Datenbus verwenden, dann ist der Zugriff schneller. fchk
Hi >Allerdings möchte ich auf jeden Fall unbedingt >jemals in meinem Leben einfach Grafik-LCD mit Touch angesteuert haben. Dann kauf dir ein DOG-XL mit Touch. MfG Spess
holger schrieb: > T6963C geht > bis 240x128. Ist alles monochrom aber zum anfangen reichts > für einen AVR. T6963C würde ich bevorzugt nehmen. Reicht das einer zum aufbrutzeln auf Lochraster oder muss es so ein Hammer-AVR im Miniformat sein? Frank K. schrieb: > Ich würde dafür allerdings einen größeren AVR wie einen Mega128 oder mit > externem Adress/Datenbus verwenden, dann ist der Zugriff schneller. Nicht so einfach, wenn man noch nie eine Platine selbst entworfen hat. Bis jetzt nur ein paar kleine Schaltungen auf Steckbrett oder Lochraster gebaut. holger schrieb: > Vergiss den Touch erstmal. Denke auch das ist erstmal zu vernachlässigen. Das kann ich dann ja immer noch nachziehen (sind ja nur 2 Werte oder so per ADC) spess53 schrieb: > Dann kauf dir ein DOG-XL mit Touch. Reicht das nen kleiner Atmega?
Angehängte Dateien:
-
T6963USB.jpg
53 KB
>> T6963C geht >> bis 240x128. Ist alles monochrom aber zum anfangen reichts >> für einen AVR. T6963C würde ich bevorzugt nehmen. >Reicht das einer zum aufbrutzeln auf Lochraster oder muss es so ein >Hammer-AVR im Miniformat sein? Geht auch mit DIP. ATMega32 oder ATMega644 wär schon eher was für ein Grafikdisplay. ATmega16 evtl. schon ein bißchen zu klein. Im Anhang mal ein Bild von einem T6963 an einem PIC18F2550.
Mein lieber Michael, nun hast du dir ein schönes Display gakauft und kriegst es nicht an. Naja, es gibt 3 verschiedene Lösungen: a) ein Controller mit eingebautem TFT-Anschluß. Sowas gibt's, z.B. den 2478 von Philips. Da ist das Routen des Layouts aber eine üble Herausforderung. Und obendrein braucht der 2478 auch noch externes RAM. b) ein Grafikcontroller von Epson. Da gibt es welche mit internem RAM. Problem ist die Beschaffung. c) ein Grafikcontroller im Eigenbau per CPLD und RAM. Ein Coolrunner mit 128 Makrozellen oder etwas mehr reicht aus, z.B. xc2c128 oder einer aus der 95er Reihe. Nachteil: Du mußt viel nachdenken und dich in programmierbare Logik einarbeiten. Vorteile: du kannst das alles erstmal ohne Lötkolben am PC tun und es ist kostenlos, selbst den Programmieradapter (Xilinx Parallelkabel #3) kannst du dir mit einem simplen TTL selber bauen. Obendrein kann man bei CPLD's die Pinbelegung weitgehend nach eigenem Gusto gestalten, so daß du es mit dem Layout einfach hast. Aber mal was Grundsätzliches: 1. Du solltest für sowas einen 32 Bit Controller mit herausgeführtem Bus verwenden. Alle kleineren CPU's sind Mist, weil du später ständig an deren Grenzen anstößt. Plane mal einen Adreßraum von 76800 Worten (153600 Bytes) für den Bildwiederholspeicher ein. Also 2 Chips 128K x 8 oder besser 1 Chip 256K x 16 (ja, die gibt's, 128Kx16 sind eher exoten) sollten reichen. Allein aus dem Adreßumfang kannst du sehen, daß du mit einem 8 Bitter schlecht dastehst. 2. Als Pixelformat empfehle ich die 565-Masche: also 5 Bit rot, 6 Bit grün, 5 Bit blau. Das kommt am besten. Die niederwertigsten Bits am Display legst du einfach auf GND. W.S.
W.S. schrieb: > Naja, es gibt 3 verschiedene Lösungen: Deine drei vorgeschlagenen Lösungen enden nach dem Gelesenen eigentlich in der 4. Möglichkeit: "Mach erst einmal etwas anderes, um Erfahrungen zu sammeln. Da Du wohl noch ein junger Mensch bist, hast Du noch ein paar Jahre Zeit, einmal in Deinem Leben etwas mit TFT-touch gemacht zu haben." Anders wird das doch nichts! Was die Auswahl des Prozessors/Grafikcontrollers angeht, stimme ich W.S. voll zu.
holger schrieb: > Im Anhang mal ein Bild von einem T6963 an einem PIC18F2550. Das ist wirklich recht hübsch. Darf ich erfragen, mit welcher Software (auf dem PC) du das gemacht hast? Gibts dafür eine Bauanleitung oder ähnliches? spess53 schrieb: >>Reicht das nen kleiner Atmega? > > Ja. > > MfG Spess Gut, dann ist das für mich passend ;) holger schrieb: > Und hier mal T6963 mit ATMega32. Auch schön. Ist das ein fertiges/festes Bild oder woher kommt das? Bauanleitung, Programm o.Ä.? Willi schrieb: > W.S. schrieb: >> Naja, es gibt 3 verschiedene Lösungen: > > Deine drei vorgeschlagenen Lösungen enden nach dem Gelesenen eigentlich > in der 4. Möglichkeit: > "Mach erst einmal etwas anderes, um Erfahrungen zu sammeln. Da Du wohl > noch ein junger Mensch bist, hast Du noch ein paar Jahre Zeit, einmal in > Deinem Leben etwas mit TFT-touch gemacht zu haben." > Anders wird das doch nichts! Genau diese vierte Möglichkeit dachte ich mir auch, als ich mir die ersten 3 durchgelesen hatte^^ Und wie du schon sagst, bin ich ja noch jung. Hab noch ne 1 vornedran, von daher bleibt noch viel, viel Zeit. Willi schrieb: > Was die Auswahl des Prozessors/Grafikcontrollers angeht, stimme ich W.S. > voll zu. Gut, das werde ich dann später in meinem Leben gebrauchen können. W.S. schrieb: > 2. Als Pixelformat empfehle ich die 565-Masche: also 5 Bit rot, 6 Bit > grün, 5 Bit blau. Das kommt am besten. Die niederwertigsten Bits am > Display legst du einfach auf GND. Interessant. Beruht das auf irgendeiner bestimmten Feststellung oder so?
Michael N. schrieb: > Interessant. Beruht das auf irgendeiner bestimmten Feststellung oder so? Das Auge hat die meisten Sensoren für Grün, daher wird dieser Farbe ein Bit mehr spendiert.
Aso, hab ich noch nicht gehört. Aber wird man sich schon was dabei gedacht haben ;) Woher bekomme ich jetzt günstig ein Display mit T6963 Controller? Schön wäre eine Auflösung von mind ca. 240x120 (natürlich lieber mehr) damit ich auch richtig ein Menü bauen kann (zB 4 Menübuttons in der Höhe) Dann würde ich halt einen Atmega328P-PU verbauen (davon hab ich sowieso mindestens einen übrig und schon "auf Lager") Außerdem würde ich dann wie schonmal oben erwähnt gerne nen USB-Anschluss dranhaben. Was nehm ich dann da als USB->UART Konverter? Schön wäre es, wenn dann die komplette Stromversorgung über USB laufen könnte. Vielleicht gibts ja auch schon was fertig mit Schaltplan umguck... Kann ich dann solche Programme wie LCDproc o. Ä. verwenden? http://lcdproc.org/index.php3
Michael N. schrieb: > Woher bekomme ich jetzt günstig ein Display mit T6963 Controller? Es muß nicht wirklich ein Display mit dem T6963 sein. Andere Displays mit etwas anderen Controllern tun es auch. Der gemeinsame Nenner ist eigentlich fast immer so, daß das Display aus uC-Sicht ein Gerät mit 2 8 Bit-Ports darstellt: - 8 Datenbis - /RD und /WR ODER R/W - A0 oder RS - CE (und/oder /CE) guck dich einfach mal bei Pollin um, die haben sowas. Beispiel: (http://www.pollin.de/shop/dt/NDU2OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_SHARP_M078CKA_A3QKLA0057.html) Allerdings ist auch für solche Teile eine ordentliche Leiterplatte nötig. Mit fliegendem Aufbau und Streifenleiterplatte macht man sich sowas nur ganz schnell kaputt. Und denk bei deiner Controller-Auswahl auch hier an den RAM-Bedarf: 240x64/8 sind 1920 Bytes (wenn mich der Alzheimer...äh...), die du als Speicher für den Aufbau des Bildes haben mußt. Dazu kommt noch das, was deine eigentliche Anwendung an RAM braucht. Ich hab dir mal ein ganz klitzekleines GDI angehängt nebst einigen unterschiedlich großen Fonts. Damit du auf den Geschmack kommst... war für Fujitsu (big endian) und Arm (little endian), aber beides 32 Bit CPUs. W.S.
W.S. schrieb: > Beispiel: > (http://www.pollin.de/shop/dt/NDU2OTc4OTk-/Baueleme...) Das ist ja mal wirklich bezahlbar. W.S. schrieb: > Allerdings ist auch für solche Teile eine ordentliche Leiterplatte > nötig. Mit fliegendem Aufbau und Streifenleiterplatte macht man sich > sowas nur ganz schnell kaputt. Hab leider garnix um eine eigene Platine herzustellen. Hätte mir jetzt halt eine passende Klemme dazubestellt und das ganze dann auf Lochraster Flugverkabelt... Natürlich trotzdem schön isoliert usw. dann dürfte da doch nix kaputt gehen. W.S. schrieb: > Und denk bei deiner Controller-Auswahl auch hier an den RAM-Bedarf: > 240x64/8 sind 1920 Bytes (wenn mich der Alzheimer...äh...) Hm der Atmega32 hat 2K RAM... nicht gerade das gelbe vom Ei dafür Aber der Atmega32 ist da ja schon ein recht großer...
Um die Displays mit integiertem Controller anzusteuern, brauchst du im µC eigenlich keinen zusätzlichen RAM, es mach keinen Sinn die Daten 2x vorzuhalten, zumal ein Kompletttransfer unnötig bremst und eine Selektion der veränderten Daten unnötigen Overhead produziert. Wenn etwas an das Display ausgegeben wird, so nimmt man die Daten aus den Flash (Font- oder Grafik-Daten) und schreibt sie an die entsprechende Position in den Displayspeicher. Sascha
D.h. ich schicke einmal das Bild an den LCD-Controller und der frischt das Bild mehrmals in der Sekunde auf dem LCD dann auf? Außerdem bin ich mal gespannt wie ich das mit Buttons oder so mache... Da muss ich ja eine kleine Menüstruktur bauen und zB den aktiven Button invertieren (oder wie man das nennt^^)
>D.h. ich schicke einmal das Bild an den LCD-Controller und der frischt >das Bild mehrmals in der Sekunde auf dem LCD dann auf? Ja. >Außerdem bin ich mal gespannt wie ich das mit Buttons oder so mache... >Da muss ich ja eine kleine Menüstruktur bauen und zB den aktiven Button >invertieren (oder wie man das nennt^^) Vergiss deine Buttons und den Touch. Dein erstes Ziel ist ein "Hello world" auf dem Display. Mehr nicht.
Hallo Michael, ich kann mich da meinem Vorredner nur anschliessen und Dir aus eigenen Erfahrungen den Tip geben, mit den Grundlagen zu beginnen. Welche Erfahrungen hast Du denn schon bereits in Richtung MCU Programmierung, Hardwareentwichlung etc. Es ist wirklich nur ein gut gemeinter Ratschlag, sodaß Du nachher nicht frustriert da stehst und den Kopf in den Sand steckst. Hast Du Dir schon mal überlegt, wie Du die Bilder erzeugen bzw. ablegen willst, die Du später zum Displaycontroller schicken möchtest? Gruß Dirk
>Es ist wirklich nur ein gut gemeinter Ratschlag, sodaß Du nachher nicht >frustriert da stehst und den Kopf in den Sand steckst. Das fängt schon beim Display kaufen an. Schöne hohe Auflösung zum kleinen Preis ist ja immer geil. Aber dann: Das Display hat nur einen Folienleiteranschluß. Kann man nicht anlöten. Adapter finde man kaum. Hintergrundbeleuchtung dann evtl. keine Leds sondern EL, dann muss man einen Inverter kaufen. Kontrastspannung wird nicht vom LCD selbst erzeugt. Dann muss man da wieder teuer basteln. Zieh dir ein TG12864B von Pollin. Hat zwar nur 128x64 Pixel und kostet 20 Euro, aber da ist alles drauf und man findet jede Menge Software dafür. Ideal zum anfangen.
Dirk schrieb: > Welche Erfahrungen hast Du denn schon bereits in Richtung MCU > Programmierung, > Hardwareentwichlung etc. Naja bis jetzt hab ich ein bisschen was mit PWM (Hardware als auch Software) und ADC neben den Standardsachen (Eingang, Ausgang, ...) gemacht. Dirk schrieb: > Es ist wirklich nur ein gut gemeinter Ratschlag, sodaß Du nachher nicht > frustriert da stehst und den Kopf in den Sand steckst. Merk ich leider viel zu oft selbst... Man möchte es hinbringen, es geht aber einfach nicht. Aber mittlerweile komm ich mit Mikrocontrollerprogrammierung ganz gut klar. Manchmal muss ich ne Nacht drüber schlafen wenn ein Fehler drin ist, aber dann klappt das auch. Dirk schrieb: > Hast Du Dir schon mal überlegt, wie Du die Bilder erzeugen bzw. ablegen > willst, die Du später zum Displaycontroller schicken möchtest? Gedanken gemacht schon. Aber hab noch keine Idee gehabt wie ich das mache. Da ich sowieso eher (dann wenn alles klappt) Buttons oder so erstmal erzeugen möchte, dachte ich mir, ist das auch für den anfang nicht so interessant. Aber wie wärs mit ner Funktion "bild_logo", an die man die Stelle im Display übergeben kann und diese dann halt eine bestimmte Folge von Bits (weiß ja jetzt nicht genau wie die Ansteuerung läuft) an das Display übergibt. Michael N. schrieb: > W.S. schrieb: >> Beispiel: >> (http://www.pollin.de/shop/dt/NDU2OTc4OTk-/Baueleme...) > > Das ist ja mal wirklich bezahlbar. holger schrieb: > Das fängt schon beim Display kaufen an. > Schöne hohe Auflösung zum kleinen Preis ist ja immer geil. > Aber dann: Das Display hat nur einen Folienleiteranschluß. Zum Display von oben gibt es auch einen passenden Stecker. Die Schaltung soll ja keinen schönheitspreis gewinnen, sondern soll fürs erste einfach mal funktionieren. holger schrieb: > Zieh dir ein TG12864B von Pollin. Hat zwar nur 128x64 Pixel > und kostet 20 Euro, aber da ist alles drauf und man findet > jede Menge Software dafür. Vielleicht keine so schlechte Idee... holger schrieb: > Vergiss deine Buttons und den Touch. Dein erstes Ziel > ist ein "Hello world" auf dem Display. Mehr nicht. Das gute alte Hello World... Muss ich mir auch noch einen Generator für Buchstaben basteln (gibt es aber ja schon ähnliches im Internet)
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.