Hallo ich möchte folgendes Display: http://www.lcdfriends.com/picture/200548105150831.pdf mit einem AVR ansteuern. Auch nach längerer Suche habe ich keine Informationen gefunden, wie das funktioniert. z.B. welche Signale man anlegen muss um einen bestimmten RGB-Pixel ansteuern kann oder ob Initialisierungs-Befehle am Anfang nötig sind. Ich hoffe mir kann hier jemand weiterhelfen Danke im voraus
Hm, steht doch alles in dem Datenblatt. Allerdings stehen deine Chancen sehr schlecht, das Ding einfach mit einem AVR anzusteuern. Hast du dir mal den Speicherbedarf für EIN Bild ausgerechnet, wenn du gerademal ein Bit pro Farbe verwendest? Das packt kein AVR, auch nicht mit externem RAM (Ausser mit Tricks wie Banking usw.). Ausserdem benötigt das Display wohl auch eine bestimmte Bildwiederholrate (Hab' ich jetzt net gesucht, wird aber schon irgendwo stehen). Da hast du wohl auch mit einem übertakteten AVR eher wenig Chancen. Da musst du schon einen Displaycontroller (Ob fertig oder als FPGA/CPLD) verwenden, sonst wird das wohl nix...
Das mit AVR war auch mehr zum experimientieren gemeint für den Anfang und nicht für eine fertige Anwendnung. Allerdings werde ich aus dem Datenblatt nicht schlau was die Ansteuerung angeht. Wie ich eine Farbe definier ist klar, auch wie die einzelnen Pixel durchnummeriert sind, aber wie ich dem Display mitteile welchen Pixel ich ansteuern will versteh ich nicht.
Du könntest dieses design in etwas modifizierter form verwenden: http://www.ulrichradig.de/home/index.php/cpld/8bit_c_graka Statt der Widerstandsnetze schliesst du einfach die Datenleitungen an. Mit 3.3V ist dieser CPLD auch kompatibel zu deinem Display.
Naja, die Ansteuerung ist im Grunde ja relativ simpel, das Display besitzt eben einfach keine "Intelligenz". Wenn ich das Datenblatt richtig verstehe, dann geht das etwa so: An DCLK deinen Pixeltakt von ca. 25MHz anlegen. Bei jedem Pixel die Farbdaten auf die entsprechenden Leitungen legen. Am Ende der Zeile jeweils einen negativen Impuls an HS und am Ende des Displays (Letzte Zeile) an VS. DTMG jeweils zwischen den HS-Impulsen auf High während die Daten reinkommen. Ist aber alles ohne Gewähr.
Philipp Burch wrote: > besitzt eben einfach keine "Intelligenz". Wie viele hier im Forum. Um so ein Display sinnvoll ansteuern zu können, musst Du einen Grafikcontroller drauf setzen. Die gibt es von Epson, Fujitsu, Solomon Systech. Die Erzeugen das Timing und haben meist internen Speicher. Können je nach Ausführung noch viele Sonderfunktionen ausführen. Dies ist ein VGA Display. Wenn Du es mit 8 Bit Farbe (256 Farben) betreibst, kommst Du auf einen Bildschirminhalt von 300Kb, bei 4 Bit (16 Farben) auf 150Kb. Weiter runter lohnt sich nicht, sonst brauchst Du auch kein TFT mehr verwenden. 150KB sind für einen AVR wohl ungeeignet. Ich mache gerade mehrere Projekte mit TFTs QVGA (also 320x240 Pixel) und hab nen ARM7 dran, um mit dem Modul sinnvoll was anstellen zu können. Das Beispiel von Ulrich Radig ist hier unpassend, da er auf einen VGA Ausgang geht. DU hast hier aber Digital RGB. Geht also nicht. Dirk
@ arm-dran Warum sollte die Grafikkarte von Ulrich Radig dafür nicht ausreichen?? Und warum sollte ein AVR dafür nicht geeignet sein?? Er schreibt doch nicht das er Videos auf dem TFT anschauen will oder den gesamten Framebuffer in den Speicherbereich des uC mappen will. Das CPLD liefert Hsync,Vsync,RGB Daten (Digital aus dem CPLD , siehe Post von "DerJan" ) und den Pixelclock kann man auch noch rausführen oder vom Quarzoszillator des CPLDs nehmen. Bei mir läuft es jedenfalls :-) Zwar mit FPGA , aber das Prinzip ist identisch. Evtl. muss man die CPLD Grafikkarte noch auf VESA Timmings anpassen weil die meisten 640x480 TFTs dieses direkt unterstützen ( bei mir ein Sharp LQ-irgendwas ).
..Ich mache gerade mehrere Projekte mit TFTs QVGA (also 320x240 Pixel) und hab nen ARM7 dran, um mit dem Modul sinnvoll was anstellen zu können... @Dirk Hofmann Hast Du eine Empfehlung für preiswerte und beschaffbare Controller/TFTs? Beispielsweise Epson ..13705+TFT.
Angehängte Dateien:
-
s1d1_epson.jpg
150 KB
Claude wrote: > @ arm-dran > Warum sollte die Grafikkarte von Ulrich Radig dafür nicht ausreichen?? > Und warum sollte ein AVR dafür nicht geeignet sein?? Er schreibt doch > nicht das er Videos auf dem TFT anschauen will oder den gesamten > Framebuffer in den Speicherbereich des uC mappen will. > > Das CPLD liefert Hsync,Vsync,RGB Daten (Digital aus dem CPLD , siehe > Post von "DerJan" ) und den Pixelclock kann man auch noch rausführen > oder vom Quarzoszillator des CPLDs nehmen. > Bei mir läuft es jedenfalls :-) Zwar mit FPGA , aber das Prinzip ist > identisch. Evtl. muss man die CPLD Grafikkarte noch auf VESA Timmings > anpassen weil die meisten 640x480 TFTs dieses direkt unterstützen ( bei > mir ein Sharp LQ-irgendwas ). @Claude Dann schau nochmal genau das Datenblatt an. Das Modul hat ein Digitales 18Bit RGB parallel Interface mit den Synch-Signalen. Die Karte von Ulrich Radig, bringt ein Analoges VGA Signal raus und geht auf einen TFT Monitor, der das Signal umsetzt. Das Modul von Michael ist aber nackig. Da kannst nicht einfach mit nem Analog Signal vom SUB_D draufgehen. Die Grafikcontroller greifen auf den internen Speicher des G-controllers zu. Dieser übernimmt das gesamte Timing und Verwaltung. Es gibt ganz versch. Ausbaustufen und Preise. @Grünschnabel Ich kann Dir leider nur sagen, welche geeigneten Typen es gibt. Da ich gewerblicher Nutzer bin, hab ich andere Bezugsquellen. http://www.epson-electronics.de/cgi-bin/panamafe/panama/demand/catalog/browseCatalog.do?colorStyle=green&tabId=1&categoryOid=-8467&BV_SessionID=@@@@0690817127.1177841409@@@@&BV_EngineID=cccdaddkgllliifcflgcefldhgjdhkg.0 Unter diesem Link findest Du die aktuell verfügbaren Typen im "Standardbereich". Es gibt auch noch welche für Mobile Anwendungen aber die bekommt man kaum und sind alle im BGA Gehäuse. Auch die Standardtypen sind alle im TQFP oder QFP Gehäuse. Mit DIL oder PLCC ist hier nix mehr. Brauchst also entweder einen Platinenadapter oder musst Dier eine eigene machen. Von Hand Drähte an jeden Pin wird sehr schwierig :-(. Das geht los bei 80Pin, 100Pin, 128Pin Pitch wird dann immer kleiner. Im Anhang mal ein Bild, von den 3 Typen, die ich aktuell einsetze. S1D13706F00A2 hat 80KB internen RAM TQFP100 S1D13A05F00A1 hat 256KB im QFP128 (etwas dickeres Gehäuse) S1D13506F00A2 hat intern nix (extern bis 2MB anschließbar) im TQFP128 (Größe wie TQFP100 nur engeres Pitch) BGA Typen gibts auch noch. Die Datenblätter findest Du im Link oben. Die Chips kosten bei Einzelstücken so zwischen 8-15 Euro (gewerblich) Keine Ahnung was die bei Privatanbietern verlangen. TFT Module gibts ja von vielen Herstellern. Ich verwende momentan hauptsächlich von 3,5" bis 7". Dirk
..Da ich gewerblicher Nutzer bin, hab ich andere Bezugsquellen... Danke Dirk, ich auch :-) Mich interessiert, ob es Probleme bei der Ansteuerung der TFTs gibt. Ich hatte mir den 13705 ausgekuckt, habe aber keine Ahnung, ob die QVGA-TFTs sich allesamt damit ansteuern lassen, oder welche Feinheiten zu beachten sind. 16 Farben würden mir reichen, aber ich bin mir nicht sicher, ob Ausgabe des Controllers und Inputs vom TFT so variabel sind, dass diese zusammenpassen. Ich dachte auch so an 5-7". Hast Du hier Preiseinschätzungen, ggf. auch mit touchscreen?
@arm-dran ich weiss wie ein TFT mit Digitalen Parallelen RGB Eingängen funktioniert und wie es zu beschalten ist, verdiene u.a. mit sowas meine Brötchen ;-) Bei Ulrich Radigs Grafikkarte kommt ein Digitales RGB Signal aus dem CPLD, dieses wird über einen R2R DAC zu einem Analogen RGB Signal, für VGA Monitore mit 75R, gewandelt. Wenn man nun diese Digitalen RGB Signale , bei Ulrich Radig im Format RGB 222 also 6 Bit 64 Farben, an die jeweiligen (CPLD Rot MSB -> TFT Rot MSB , CPLD Grün MSB -> TFT Grün MSB ......) Eingänge des TFT und die verbleibenden niederwertigen Bits auf GND legt ist das TFT schon so gut wie angeschlossen. Das CPLD erzeugt auch die Synchronisations Signale (HSync,Vsync) im weitgehendst VESA konformen Timing. Was jetzt noch übrig bleibt um das oben genannte TFT so zu betreiben sind die Signale DTMG und der Pixel Clock. Den Pixel Clock kann man sich aus dem CPLD rauslegen und das DTMG Signal wird aus Hsync und Vsync gebildet. Ich verwende fast nur PLDs für solche Aufgaben. PLDs sind meistens billiger und einfacher zu beschaffen als spezielle Grafik Controller. Und da in fast allen unseren Produkten sowiese ein FPGA oder CPLD vorhanden ist bietet es sich einfach an. Einen Altera Cyclone 2 bekommt man auch schon für 15€ , da passt dann neben dem LCD Controller , Bresenham in Hardware , BLIT/BLT usw auch noch die CPU im ARM7 Kaliber mit rein ;-)
Hallo Michael, Ich arbeite auch gerade einem fast identischen Projekt. Display ist bei mir ein LQ10D367 von Sharp. Ich hab mir dein Datenblatt jetzt nicht genau angeschaut, aber die Displays scheinen (fast) gleich angesteuert zu werden. 640x480 Pixel und 3x6Bit Farbtiefe haben beide. Als Ansteuerung will ich einen S1D13504 von Epson verwenden. Der wird zwar eigentlich nicht mehr hergestellt, aber bei csd-electronics bekommt man ihn noch für 15 Euro das Stück. Der Controller unterstützt leider nur 16Bit Farbtiefe, dafür wären auch 600x800 Pixel kein Problem. Der Controller braucht dann noch einen externen Specher. Wenn ich das richtig im Kopf habe einen EDO oder FPM DRAM mit 512k*16 oder 1M*16. Aber da bin ich mir nicht mehr sicher. Ich hab meinen jedenfalls bei Segor für ca. 8 Euro gefunden. Großer Nachteil dieses Controllers ist, dass er in TQFP 128 mit 0,4mm Pitch verpackt ist. Einzelne Drähte anzulöten brauchst du da eigentlich garnicht probieren. Ich hab mir eine Adapterplatine ätzen lassen und dann den Chip von einem Forenmitglied per Lötofen löten lassen. Der Displaycontroller soll dann über einen ATMega64 angesteuert werden. Aktueller Projektstand ist, dass die Verbindungen zwischen ATMega, S1D13504 und RAM mit Fliegender Cu-Lackdraht-verdrahtung gelötet sind. Ich werde sie dann noch alle kontrollieren und dann versuchen, den S1D13504 anzusteuern. Wenn das klappt schließ ich das Display an. Soweit mal eine kurze Zusammenfassung über meinen Lösungsweg. Darf man fragen was du für dein Display gezahlt hast? Meines bekommt man für etwa 100-130 Euro. Gruß, Sebastian
@Claude absolut auf Krampf sowas. Nen Grafikcontroller mit 256KB RAM und 2D Engine, dazu noch nen ARM7 mit 512 KB Flash, 64K RAM usw. mal schnell in ein FPGA. Überdenk lieber noch mal den Quark, den Du hier schreibst. Bald existieren nur noch Firmen, wie Altera, Xilinx, Lattice oder wie. @Sebastian... >> Der Controller unterstützt leider nur 16Bit Farbtiefe, dafür wären auch >> 600x800 Pixel kein Problem. Du willst einen ATmega64 ranhängen? DasDisplay hat leider nur 16Bit Farbtiefe??? Wie willst Du mit einem ATmega64 16Bit Farbtiefe verwalten und das bei 800x600 Pixel? Ein Bildschirminhalt hat dann 937,5Kbyte also fast 1MB !?!?! Ich würde mich mal vorher über gewisse Gegebenheiten informieren, bevor ich so ein Projekt beginne und anderen Ratschläge gebe, die total ins aus gehen. @Grünschnabel Der S1D13705 ist dafür optimal geeignet. Er arbeitet auch mit 5V. 8 Bit Farbtiefe sind vollkommen ausreichend, machmal sogar 4Bit. Die meisten Navigationssysteme arbeiten auch nur mit 4 oder 8Bit. Probleme gibt es in der Regel keine. Kommt auch darauf an, welchen µC Du ranhängen willst? Die Grafikcontroller haben von Haus aus mal ein 16Bit Datenbus zum µC. Da ist ein µC mit mit 16Bit natürlich auch aus Geschwindigkeitsgründen gut geeignet. Für versch. µC Typen ist das Speicherinterface schon vorhanden, lässt sich aber durch leichte Modifizierungen anpassen. Also bei meiner Bezugsquelle kostet ein TFT mit 5,7" 320x240 um die 50€ 7" Wide VGA 800x480 cs. 80€. Touch kommt noch dazu. Dirk
@Dirk welche Bezugsquelle ist das wenn ich fragen darf? Ich bräuchte nähmlich grade ein 320x240 Pixel TFT-Display ;)
@Dirk Ich vermute mal, das sind keine Preise für Einzelstücke. Nach meiner Einschätzung sind die angestrebten Farbspielereien mit >64 Farben sehr fragwürdig. Für eine Bedienereingabe eignen sich wesentlich nur die Farben Rot, Blau, Schwarz und Weiß mit voller Helligkeit. Grün und Gelb sind schon schlecht zu lesen. Zwischentöne und geringere Helligkeiten sind kaum auszumachen. Wichtiger für mich wäre das Attribut Blinken vom Display-Controller zu erledigen. Einen direkten Weg dafür scheint es aber nicht zu geben. Prozessorleistung/Interface ist kein Problem (SH7211 :-)
Opacer Ich wrote: > @Dirk > > welche Bezugsquelle ist das wenn ich fragen darf? Ich bräuchte nähmlich > grade ein 320x240 Pixel TFT-Display ;) @Opacer Ich, ist eine gewerbliche Quelle. Die verkaufen nicht an Privat oder bist Du auch komerzieller Anwender. 320x240 bei welcher Diagonale ? 3,5", 5,7", 7" ,10,2" ??? Könnte Dir aber eins mit besorgen, wenn Du willst. Dirk
@Dirk gewerblich und in größeren Stückzahlen im Endeffekt. Bräuche 3.5" besser noch 3.8" und transflexiv
Grünschnabel wrote: > @Dirk > > Ich vermute mal, das sind keine Preise für Einzelstücke. > > Nach meiner Einschätzung sind die angestrebten Farbspielereien mit >64 > Farben sehr fragwürdig. Für eine Bedienereingabe eignen sich wesentlich > nur die Farben Rot, Blau, Schwarz und Weiß mit voller Helligkeit. Grün > und Gelb sind schon schlecht zu lesen. Zwischentöne und geringere > Helligkeiten sind kaum auszumachen. > > Wichtiger für mich wäre das Attribut Blinken vom Display-Controller zu > erledigen. Einen direkten Weg dafür scheint es aber nicht zu geben. > Prozessorleistung/Interface ist kein Problem (SH7211 :-) @Grünschnabel doch, das sind Preise für Einzelstücke. Natürlich ohne Grafikcontroller. Das mit der Farbtiefe ist richtig. 4 Bit (16 Farben) sind meist für solche Anwendungen vollkommen ausreichend. Beim 3705 kann man aus einer Palette von 4096 Farben sich die geeigneten aussuchen. SH72... µC ist natürlich genug Leistung, diese Renesas Teile arbeiten doch mit 200-400 MHz oder? Was meinst Du mit blinken? Einen Cursor oder Symbolik wie Warnzeichen am Modul komplett flashen zu lassen. Dies lässt sich realisieren, in dem man einen Grafikcontroller nimmt, der ausreichend Speicher für mehrere Pages hat, und man ein Overlay realisieren kann. Dann kann man sogar eine Art GIF animieren. Die EpsonController für Mobil Application beherrschen da einiges, sind aber für den allgemeinen Markt nicht verfügbar, außerdem nur BGA. Dirk
Opacer Ich wrote: > @Dirk > > gewerblich und in größeren Stückzahlen im Endeffekt. Bräuche 3.5" besser > noch 3.8" und transflexiv Na wenn Du gewerblicher Anwender bist, ist das ja kein Problem. Es gibt halt unterschiedliche Hersteller und Qualitäzsstufen. Muß man aber selbst ausprobieren. Das Drama ist immer, daß kein TFT zum anderen wirklich Anschlußkompatibel ist. Daher sollte man beim Design seines Boards mind. 2-3 versch. Typen vorsehen (zur Sicherheit). Die Produktverfügbarkeit/Abkündigung ist ja zu einem echten Problem geworden, vorallem wenn man nicht im kurzlebigen ConsumerMarkt tätig ist. Statt 3,8" kannst Du auch ein 4" WideScreen (Panorama) nehmen. Ist wie beim TOMTOM Go 910 Navi. Dirk
Endlich habe ich Zeit gefunden wieder in den Thread zu schauen und bin echt positiv überrascht wie viele Tipps gekommen sind. Danke @ all! Das mit AVR-Graka hört sich schon mal interessant an, da es für den Einstieg als Tutorial gut beschrieben ist (Schaltpläne etc) und wenn man damit Monitore über die VGA-Schnittstelle ansteuern kann, findet sich auch sicher unabhängig von dem oben genannten Display eine geeignete Anwendung ;-) @ Claude: Wie wird das DTMG Signal aus Hsync und Vsync gebildet? @ Sebastian: Das Display habe ich umsonst bekommen, kann also nicht sagen was es normal kostet Mit CPLD und ähnlichem habe ich mich bis jetzt noch nicht beschäftigt (habe mit den Standard-TTL der 74iger-Reihe angefangen und dann zum AVR gewechselt), ist aber mal ne gute Gelegenheit um damit anzufangen. Die Grafikcontroller sehen auch interessant aus (hatte aber noch keine Zeit mir die Datenblätter genauer anzusehen), gibt es da auch welche die per I2C oder über UART angesteuert werden können? Michael
@Dirk Hofman: Wie wär's mal mit einem bischen anderen ton? Ich werd mir sicherlich ein Display für 100€ kaufen und dann nochmal über 70 In Halbleiter und Platinen investieren, wenn ich nicht vorher zumindest halbwegs sicher bin, dass das so was werden könnte. Mitdenken Junge! Das ganze Bild im AVR zu speicher ist natürlich nicht möglich. Brauch ich aber auch garnicht. Bei meiner Anwendung reicht es, wenn ich die änderungen zum Display schicke. Der Größte Teil des Bildes wird sowieso immer gleich bleiben. Zusätzlich wird wohl sehr viel Text anzuzeigen sein, was den RAM-Bedarf im AVR nochmal stark senken sollte. Außerdem hab ich nirgends Ratschläge gegeben, sondern nur gesagt, wie ich es mache. In keiner einzigen Silbe hab ich Michael geraten es genauso zu machen. Wegen der Farbtiefe-diskussion: Wisst ihr, was Michael anzeigen will? Vielleicht machen bei ihm 16 Bit ja sinn... Ich wollte mir die Möglichkeit offen halten, um später eventuell auch kleine Grafiken anzeigen zu können. Sorry für den Tonfall, aber das musste jetzt einfach mal raus. Sebastian
Zum Thema Farbtiefe: Für den Anfang reichen mir einige wenige Farben (wird vorerst hauptsächlich Text, Tabellen und evtl noch Diagramme sein) aber wie Sebastian möchte ich mir auch die Möglichkeit offen halten grafisch aufwendigere Dinge darzustellen am besten ohne mich dann mit einer komplett neuen Elektronik beschäftigen zu müssen. Michael
> Brauch ich aber auch garnicht. Bei meiner Anwendung reicht es, > wenn ich die änderungen zum Display schicke. > Der Größte Teil des Bildes wird sowieso immer gleich bleiben. Das geht bei einem "nackten" TFT-Panel nicht, bei dem muss zyklisch der gesamte Inhalt neu geschrieben werden. Eine Adressierung einzelner Bildpunkte ist nicht möglich, die werden alle sequentiell geschrieben. Die übliche Refreshrate bei TFT-Panels liegt bei 60 Hz, die mag zwar vielleicht etwas reduziert werden können, aber um das grundlegende Problem kommt man nicht herum. Das sieht erst dann anders aus, wenn zwischen dem -unverändert angesteuerten- Display und dem das Display ansteuern sollenden Controller ein Display-Controller mit eigenem Bildspeicher liegt. Und der muss ausreichend groß sein, um den kompletten Bildschirminhalt des Displays in der gewünschten Farbtiefe zu speichern. Bei Verzicht auf Graphikfähigkeit und Verwendung eines Zeichengenerators ließe sich die Speichermenge etwas reduzieren, aber der Nutzen des TFT-Displays reduziert sich damit gleichermaßen ...
@arm-dran Komisch nur das dieser "Quark" in Stückzahlen läuft und gekauft wird ! Und noch komischer das ich mir dank dieses "Quarks" realativ wenig Sorgen über meine Finanzen machen muss. Hab auch nie was von 512kb Flash und ARM7 im FPGA geschrieben, sondern nur etwas von "ARM7 Kaliber" damit meinte ich sog. Softcore Prozessoren wie Nios2 oder Microblaze. Wenn Du die ganze Zeit von einem ARM7 Single Chiper gesprochen hast (ich geh mal davon aus wenn Du schreibst 512k Flash,64k Ram), was soll dann der Vorteil so eines Chips gegenüber einem AVR sein? Das der eine 60 Mips hat und der andere 16 Mips? Die Speichergrößen können es ja nun nicht mehr sein. Wenn Du mal über den NXP/ATMEL etc. Tellerrand schauen würdest, würdest Du erkennen das beide Lösungen, Klassischer uC mit Display Controller oder Programmierbare Logik, ihre Daseinsberechtigung haben. Es gibt leider nicht nur den einen gangbaren Weg. Ulrich Radigs Grafikkarte hat eben schön zur Aufgabenstellung AVR+TFT Display gepasst, ist leicht nachbaubar wegen DIP und PLCC Bausteinen , einfach in der Software (3 Register) und die nötigen Bauteile kann man bei jedem Elektronik Versender bekommen. Ich geh jetzt lieber zu dem Thema in Deckung, will keinen Flamewar anzetteln. Der Umgangston ist ja schon etwas härter geworden. @Michael Das DTMG Signal kannst Du dir mit einem AND Gatter aus Hsync und Vsync im CPLD bilden. Das ganze AVR-Grafikkarten Projekt von Ulrich Radig ist nicht in VHDL oder Verilog sondern Schematic realisiert d.h. Du kannst die Funktionen im CPLD auf Schaltplanebene bearbeiten. Das erleichtert den Einstieg in das Thema gewaltig. Gruß Claude
Wie wär's damit (wenn's wieder lieferbar ist)? http://www.embeddedartists.com/products/uclinux/ucl_qvga.php
@Claude Würde mich mal interessieren, in welchen Cyclone 2 von Altera Du das alles reinpackst? Werde doch mal konkret und bringe ein kleines Beispiel. Ich kenne Altera und auch die Cyclone 123 Familie. Für 15€ bekommst Du aber so ziemlich den einfachsten (120 Kbit RAM) Dir richtigen Geschosse gehen an die 100-200€. TQFP144 ist schon fast das mindeste. Den VideoRAM musst dann auch noch extern hinschalten. Was erledigt die eingebettete MCU dann im FPGA? Dirk
@Dirk
Ein 2C8 reicht fuer einen NiosII plus standard Peripherie, einem Display
Controller fuer TFTs mit HW beschleunigung nach wahl und wenn man will
evtl. noch einen Ethernet MAC.
FLASH und RAM sind extern, hat wohl auch neimmand was anderes behauptet.
Dafuer kann man gleich einen DDR2 Baustein nehmen, dann macht auch UMA
richtig spass.
>Was erledigt die eingebettete MCU dann im FPGA?
Zumindest muss die sich nicht um die TFT ansteuerung kuemmern.
Gruss, Roger
@ Claude: Was genau machst Du beruflich, und aus welchem Bereich kommen Deine Kunden? Gruß, Feadi
@arm-dran Ich hab hier momentan ein Design das in einem EP2C20 ganze 5082 LEs und 158kbit RAM beansprucht (das meiste RAM geht für einen 32 Bit breiten und 4096 tiefen FIFO drauf der 2 Clock Domains trennt). Da is enthalten : Nios2F CPU,SDRAM Controller,SRAM Controller,CFI Flash Controller,LCD Controller,2 Timer,PS2 Controller. Wenn ich den FIFO verkleinere passt das ganze locker in einem EP2C8! Frag doch mal die Preise für solch einen Baustein bei deinem Distributor an... bei meinem bei 100er Stückzahl für ca. 13€. Noch ein Config Prom (den freien Platz im Prom kann man als Flash für die CPU nehmen) und etwas SDRAM (32MB 32Bit) dazu bin ich bei knapp 20€. Wenn ich jetzt einen ARM7 Single Chiper + Epson TFT Controller + DRAM für den Epson rechne komm ich locker über 20€. @feadi Ich arbeite in einem Systemhaus für Hard und Software Entwicklung. Wir sind auf Feldbusse und Dezentrale Steuerungen spezialisiert.Die Kunden kommen in der Regel aus der Industrie und wir betreiben Auftragsentwicklung,Fertigung und was alles dazu gehört. So, genug OT :-) Gruß Claude
@Claude Offensichtlich hast Du kostenlose Entwicklungswerkzeuge, keinerlei Entwicklungskosten und hohe Stückzahlen, dass Du alleine die Bauteilekosten berücksichtigen mußt :-)
@Claude Also der EP2C20 kostet jenseits der 20€. Mein Grafikcontroller + ARM7 mit allen Schnittstellen, Flash + RAM + VideoRAM kostet mich bei 100Stk. etwa. 12€. Verfügbarkeit ist garkein Problem. Denke einfach, daß wir in 2 vollkommen versch. Anwendungsfeldern tätig sind. Ich muß das ganze, incl. Pheripherie (und das ist einiges) mit ner Platine auf den Rücken eines 3,5" Displays bringen. 32MB x 32 SDRAM wofür? Ich stecke sehr viel in optimale Ausnutzung durch Programmierung. Du hast dann warscheinlich eher eine Art PC-ähnliches Segment. Da zieht es mich abolut nicht hin. Ist jetzt keine Kritik aber das ist absolut nicht mein Ding. Dirk
Ja, scheint so als wir in verschiedenen Welten Arbeiten :-) Klar kostet ein EP2C20 mehr als 20€, ein EP2C8 aber nicht und in den würde das o.g. Design Problemlos Fitten. Das o.g. Design ist auch nicht etwas was unbedingt zu einem Produkt werden soll sondern nur ein Bespiel für den Resourcenverbrauch. Die 32MB SDRAM sind nur drinn weil ich davon gerade Preise zu Hand hatte. Ok bei den Preisen die Du hast sieht das schon ganz anders aus. Bin von 8€ für die CPU ausgegangen, 15€ für den Epson und nochmal 2-3 € für den FPM oder EDO. Schönen Tag noch, Claude
@Claude Hast Du schon Erfahrungen mit der Langzeitverfügbarkeit von den Cyclonen ? Zumindest Ersatztypen voll Kompatibel.
@dirk Nein Sorry, als ich zu den FPGAs gekommen bin war schon der Cyclone 1 aktuell. Aber ich denke das man die vorgänger ACEX heute noch bekommt. Ob man daraus auf die Verfügbarkeit der Cyclones schließen kann weiss ich nicht. Bei Xilinx sieht es anderes aus , hab erst vor ein paar Wochen XC5204 FPGAs bestellt und sogar noch in ROHS konform bekommen.
In Farbe wird das etwas aufwendiger, aber hier erst mal schwarz-weiß mit FPGA, http://www.fpga4fun.com/GraphicLCDpanel.html und Benedikts alter Thread mit AVR, im Dezember das letzte Mal kommentiert: Beitrag "LCD Controller für 640x480 LCD mit mega8515"
@Dirk Hofmann ich bin schon eine Zeit lang auf der suche nach günstigen TFTs mit 5,7" (320x240). Du httest eine Preis um die 50€ erwähnt. Ich brauche das gewerblich. Verrätst du mir deine Bezugsquelle? Schönen Tag, Dirk Schlichte
@Dirk Hofmann na ja, keine Antwort ist auch eine Antwort. Auf jeden Fall weiß ich jetzt das sich das weitersuchen lohnt. Die bisher günstigsten Angebote die ich bekommen habe liegen bei knapp unter 100 Euro.
Dirk Schlichte wrote: > @Dirk Hofmann > > na ja, keine Antwort ist auch eine Antwort. > Auf jeden Fall weiß ich jetzt das sich das weitersuchen lohnt. > Die bisher günstigsten Angebote die ich bekommen habe liegen bei knapp > unter 100 Euro. Sorry, hab nicht mehr mitgelesen. Hersteller heisst Innolux. Schau mal auf der Website von denen. Dirk
Hallo Dirk, hast Du fuer die, die die Schriftzeichen dieser Website nicht deuten koennen noch einen Tip? Google spuckt bei 'innolux' 51700 Seiten aus. Welche davon sollte man sich ansehen? Danke und Gruss Udo
uCler wrote: > Hallo Dirk, > > hast Du fuer die, die die Schriftzeichen dieser Website nicht deuten > koennen noch einen Tip? > > Google spuckt bei 'innolux' 51700 Seiten aus. Welche davon sollte man > sich ansehen? > > Danke und Gruss > Udo @Udo die offzielle Website ist www.innolux.com.tw Website ist leider in Chinesisch oder taiwanesisch. Manuals usw. gibt es aber in Englisch. Ich beziehe die Displays in einer Cooperation direkt von dort. Deswegen kann ich keinen wirklichen Distributor nennen. Nur kurz zur Info. Innolux hat tolle sonnentaugliche TFTs deren Kontrast durch den Lichteinfall noch besser wird (TMR). Dirk
Auf welches Fragezeichen muss ich auf dieser Webseite drücken um zu den Displays zu gelangen?
Feadi aus Frankreich wrote: > Auf welches Fragezeichen muss ich auf dieser Webseite drücken um zu den > Displays zu gelangen? Hallo Feadi, geht leider nicht, man muß registrierter Benutzer sein um Infos zu bekommen. Nur für OEMs gedacht, leider. Schönes Wochenende Dirk
Hallo Michael, wie ist denn der Stand deines Projekts? Schon für eine Lösung entschieden? Sebastian
Hat jemand vielleicht auch mal einen Schaltplan wie man so ein Displaycontroller mit einem TFT verbinden muss.
So weit ich weiß, muss man einfach die entsprechenden Pins miteinander verbinden und fertig. Welche das bei dir genau sind erschließt sich ja aus dem Datenblatt. Ich lasse mich aber gerne Korrigieren, wenn es nicht so einfach geht. Sebastian
Hallo ich möchte ein ähnliches Display per vga ansteuern, wenn ich das Datenblatt und die oben gegenen Antworten richtig verstehe, dann müsste das ja (theoretisch) so funktionieren: - HSync, VSync, DCLK direkt vom VGA durchverbinden - DTMG mit AND-Gatter aus HSnc und VSync bilden - Analoge RGB-Signale von VGA jeweils mit einem 6Bit-AD-Wandler in einen Digitalwert umsetzen Ist das so möglich oder ist da ein Denkfehler drin? Carl
Carl wrote: > Hallo > > ich möchte ein ähnliches Display per vga ansteuern, wenn ich das > Datenblatt und die oben gegenen Antworten richtig verstehe, dann müsste > das ja (theoretisch) so funktionieren: > > - HSync, VSync, DCLK direkt vom VGA durchverbinden > - DTMG mit AND-Gatter aus HSnc und VSync bilden > - Analoge RGB-Signale von VGA jeweils mit einem 6Bit-AD-Wandler in einen > Digitalwert umsetzen > > Ist das so möglich oder ist da ein Denkfehler drin? > > Carl Displays, die sich per VGA ansteuern lassen, gibts ja zu hauf. Auf der anderen Seite brauchst Du ja dann trotzdem eine Grafikkarte oder einen Grafikchip. Der springende Punkt hier ist wohl eher, digitale Pixeldaten von einem µC zu verarbeiten, in einen Speicher zu schreiben der Sie dann auf das TFT ausgiebt.
Die Frage war evtl. etwas offtopic und nicht als Antwort auf die Frage ganz oben gemeint. Deshalb habe ich einen extra Thread dazu angefangen: Beitrag "TFT-Display mit VGA ansteuern" Carl
@Sebastian hab mich noch nicht für eine Lösung entschieden (hat einfach die Zeit in den letzten Tagen gefehlt). So eine Beispiel-Beschaltung eines Displaycontrollers würde mich auch interessieren. > So weit ich weiß, muss man einfach die entsprechenden Pins miteinander > verbinden und fertig. Ich hab mir mal das Datenblatt vom S1D13706 angeschaut, werde aber aus den Signalnamen im Vergleich zu den Signnalen im Datenblatt des Displays nicht schlau. Welcher Controller wäre eigentlich am geeignetsten für dieses Display?
@Michael Dein Modul kann 640x480 Pixel Auflösung (also VGA) bei 18Bit Farbtiefe (262K) Folgender Speicherbedarf um eine komplette Bilschirmseite bei VGA Auflösung zu halten ist notwendig: 16 Farben = 4 Bit --> 150 Kbyte RAM 256 Farben = 8 Bit --> 300 Kbyte RAM 65536 Farben = 16 Bit --> 600 Kbyte RAM Der S1D13706 hat 80KB RAM, damit könntest Du bei voller Auflösung höchstens 4 Farben darstellen. Der S1D13A05 hat 256KB RAM, geht also für 16 Farben, 256 reicht nicht mehr. Der S1D13506 hat 2MB (muß man extern an den Chip anschließen) mit dem kannst DU die volle Farbvielfalt ausreizen. Alle 3 Typen habe ich weiter oben in einem Beitag in einem Bild gezeigt. Wenn Du mir sagst, welche der obigen Anforderungen Deinen entsprechen, dann kann ich Dir konkreteres über das Interface sagen. Zu beachten ist, das die Chips generell einen 16 Bit breiten Datenbus haben. Dirk
Ich hab mir die Signale aus den Timing-diagrammen zusammengereimt. Zumindest die, wo's nicht sofort offensichtlich war. Bei mir ist es dann so: Display Controller Hsync FPLINE CK FPSHIFT ENAB DRDY Vsync FPFRAME @Dirk Kann der 13506 tatsächlich 18Bit, oder so wie der 13504 "nur" 16 Bit? Der 16-Bit Datenbus ist ja generell erst mal kein Problem. Höchsten etwas mehr aufwand. Sebastian
Für den Anfang würde zwar wahrscheinlich auch der S1D13A05 reichen, aber da ich mir die Möglichkeit offen halten will, dass später auszubauen, würde mich dann doch der S1D13506 interessieren.
@Sebastian @Michael zusammenreimen braucht man sich da nicht viel. Die Anschlußbedingungen sind ziemlich klar. Der 3506 kann auch (nur!!) 16 Bit. Dabei werden die LSBs von 2 Farben einfach auf 0 gelegt. Für diesen Typ gibt es sogar Applikationsschriften von Epson von EDO RAM oder ISSI. Ich denke 16 Bit Farbe sind vollkommen ausreichend und von 18 oder 24 Bit kaum zu unterscheiden. Was eben zu beachten ist .... die Datenmenge bei einem ATmega64. Wenn Du Bitmaps ablegen möchtest, dann könntest Du Dir zum Beispiel extern über SPI serielle DataFlashs ranschalten. Gibt es im SO8 oder etwas größerem Gehäuse mit z.B. 1MB, 2MB, 4MB, 8MB. Daraus kannst Du dann Deine festen Grafiken holen oder eben selbst erzeugen. Dirk
Eine nicht ganz unwichtige Frage stellt sich mir grad, wo kriegt man (als Privatperson) die Controller und zu welchem Preis? Google konnte mir dazu keine zufriedenstellende Antwort geben. Michael
@Micha Kann ich Dir auch nicht genau sagen. Da hier im Forum ab und zu bei Digikey eine Sammelbestellung abgelassen wird (Michael Rubitschka) könntest Du Dich dort mit ranhängen. S1D13706 = 9.93€ S1D13A05 = 11.57€ (allerdings im BGA) geht auch S1D13A04 S1D13506 = 9.56€ Die Preise sind für Einzelstücke zzgl. anderer Gebühren beim Import
Ich hab meine SED 13504 von csd-electronics.de für 15 Euro bekommen. Aber die haben ihn nicht mehr. Bei Segor bekommt man ihn (also den SED 13504) für 26,50 Euro. An sich kannst du den Controller auch nehmen. Ist halt kein aktueller typ. Aber vielleicht kennt Dirk ja noch andere Quellen. Sebastian
Hier liegt noch meine Schaltung mit S1D13704 und AVR 8515: Beitrag "Grafikcontroller S1D13706" Die Anbindung an einen 8-Bit-Datenbus ist in einer Epson-Applikation sehr kurz beschrieben. der 13704 hat allerdings nur 40k RAM, damit kommt ein Farbdisplay nicht weit.
Christoph Db1uq wrote: > Hier liegt noch meine Schaltung mit S1D13704 und AVR 8515: > Beitrag "Grafikcontroller S1D13706" > Die Anbindung an einen 8-Bit-Datenbus ist in einer Epson-Applikation > sehr kurz beschrieben. der 13704 hat allerdings nur 40k RAM, damit kommt > ein Farbdisplay nicht weit. @Christoph Warum postest Du hier diesen Link? Das macht ja alles noch verrückter und verwirrender! Mit 40K kannst Du bei VGA gerade mal eine Farbe bzw. sw/ws anzeigen. Um bei diesem Display mit 8Bit Farbe zu arbeiten, brauchst Du 300KB. Was hat das eine App. mit 8515 zu suchen? Das Bild soll ja auch irgendwann mal angezeigt werden oder ? Dirk
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.