hallo, nach tagelangem forum durchsuchen habe ich mich entschlossen nun doch einen thread aufzumachen, da ich diesbezüglich keine wirklich aussagekräftigen threads gefunden habe. das sogenannte problem: 8Bit AVR -> Epson S1D13705 LCD Controller -> Hitachi SX14Q004 Color LCD ich habe die datenblätter des Epson und des Hitachi ausgiebig studiert, bin jedoch nicht ganz im klaren wie ich diese teile nun wirklich zusammenhängen kann ? was mir fehlt ist einzig das richtige "wireing" zwischen den oben genannten komponenten. Datenblätter: Hitachi http://www.hitachi-displays-eu.com/doc/sx14q004.pdf Epson http://www.pacificdisplay.com/ics_app%20notes/epson/S1D13705.pdf Meine bis jetzt vorliegende Vorschlags-Verdrahtung: ************************************************************************ ** AVR <-> EPSON ------------- A[16:0] -> AB[16:0] D[15:0] <-> DB[15:0] RDY# <- WAIT# WE# -> WE0# + WE1# OE# -> RD# + RD/WR# CS# -> CS# OCLK -> BUSCLK N/A -> BS# (-> Vss) Info: Ich möchte zur Übetragung alle Bits Verwenden (Address = 17Bit , Data = 16Bit) und die Busverbreiterung im AVR per Software lösen. Den Epson möchte ich auf "Generic #1 Host Interface" stellen. ************************************************************************ ** EPSON <-> HITACHI LCD --------------------- FPDAT[7:0] -> D[7:0] FPLINE -> CL1 FPSHIFT -> CL2 FPFRAME -> FLM LCDPWR -> DOFF# DRDY -> N/A (???) GPIO0 -> Vdd GPIO1 -> Vdd GPIO2 -> Vdd GPIO3 -> Vdd Info: Den Epson möchte ich auf "Generic #1 LCD Interface" stellen. Der DRDY# Pin wird nicht Angeschlossen, oder gegen ein Potenzial gehängt ? Das mit dem Hardware Reset GPIO0# habe ich auch nicht ganz verstanden ? ************************************************************************ ** wenn jemand mehr Ahnung hat als ich, bitte ich um Feedback zu dem Thema ! ;) Danke & Grüsse Mario
Ich verwende meist den Generic #2 Modus, da dieser leicht mit 8bit verwendet werden kann. Dazu invertiert man A0 und legt es an BHE#. D0-7 und D8-15 werden jeweils zusammengelegt. Nun hat man nur noch D0-7, A0-17, RD\ und WR\. WAIT wird offen gelassen (da dies ein Ausgang ist). Falls das Externe Speicherinterface verwendet wird, sollte man 2 Waitstates einstellen. > EPSON <-> HITACHI LCD > --------------------- > FPDAT[7:0] -> D[7:0] > FPLINE -> CL1 > FPSHIFT -> CL2 > FPFRAME -> FLM > LCDPWR -> DOFF# > DRDY -> N/A (???) > GPIO0 -> Vdd > GPIO1 -> Vdd > GPIO2 -> Vdd > GPIO3 -> Vdd > Müsste passen. DRDY ist das M oder AC Drive Signal, einige LCDs benötigen das, andere erzeugen es intern.
hallo, danke für die antwort , hat geholfen :) jetzt hätte ich noch eine ganz dumme frage ob ich das so richtig verstanden habe mit dem daten senden im Generic#2 Modus von AVR -> S1D13705 ... AVR <-> EPSON (Generic #2) ------------- A[16:0] -> AB[16:0] D[7:0] <-> DB[7:0] + DB[15:8] RDY# <- WAIT# BHE# -> BHE# (WE1#) WR# -> WE0# RD# -> RD# N/A -> RD/WR# (-> Vdd) CS# -> CS# OCLK -> BUSCLK N/A -> BS# (-> Vdd) CS# Low = Register Zugriff CS# High = Buffer Zugriff BHE# Low , WR\ geht Low = Byte D0-7 auf Adresse A0-16 schreiben BHE# High , WR\ geht Low = Byte D8-15 auf Adresse A0-16 schreiben BHE# Low , RD\ geht Low = Byte D0-7 von Adresse A0-16 lesen BHE# High , RD\ geht Low = Byte D8-15 von Adresse A0-16 lesen danke & grüsse, Mario
Es gibt auf folgender Seite bei Epson ausführliche Datenblätter und Application Notes zu deren LCD-Controllern, insbesondere zu "Interfacing to an 8-bit Processor": http://www.erd.epson.com/index.php?option=com_docman&task=cat_view&gid=244&Itemid=40 Viele Grüße, Dirk
Nicht ganz: > AVR <-> EPSON (Generic #2) > ------------- > A[16:0] -> AB[16:0] > D[7:0] <-> DB[7:0] + DB[15:8] > RDY# <- WAIT# > A0 (invertiert) -> BHE# (WE1#) > WR# -> WE0# > RD# -> RD# > N/A -> RD/WR# (-> Vdd) > CS# -> CS# > OCLK -> BUSCLK > N/A -> BS# (-> Vdd) > CS# Low = Register Zugriff > CS# High = Buffer Zugriff Nein, CS\ muss bei jedem Zugriff immer Low sein, über MR wird unterschieden: > MR Low = Register Zugriff > MR High = Speicher Zugriff Mit BHE# = A0 invertiert ergibt sich dann: > A0 Low , WR\ geht Low = Byte D0-7 auf Adresse A0-16 schreiben > A0 High , WR\ geht Low = Byte D8-15 auf Adresse A0-16 schreiben > A0 Low , RD\ geht Low = Byte D0-7 von Adresse A0-16 lesen > A0 High , RD\ geht Low = Byte D8-15 von Adresse A0-16 lesen
Gerade mit Freude diesen Thread gesehen. Endlich fange ich mit meiner Implementation an. mega2560 Modul von robotikhardware.de und die s1D13705 LCD Controllerkarte von Mark de Jong, mdjong.de. Als Display setze ich das lmg7550XUFC von Hitachi ein, 10,4", 640x480 monochrom. Das ganze wird ein Display zur Steuerung und Anzeige von Telemetriedaten von meinem Segelbootmodell. Programmieren tue ich mit BASCOM Aus dem thread entnehme ich das ihr ebenfalls den mega2560 einsetzt mit 3,3V Betriebsspannung? Für den Zugriff auf den onchip Bildspeicher des 705 das externe RAM I/F des 2560? Meine ersten Fragen: Ist ein 16-Bit-Daten-I/F wie Mario es andenkt nicht besser? Schliesslich ist das I/F 2560 zu 705 ja schon ein Engpass. Ich hätte daher lieber einen 806 eingesetzt da der BiBlt unterstützt, konnte jedoch keinen Kartenlieferanten finden. Klar ist das auch die 256kByte Flash von mega2560 kein großer Bilddatenspeicher sein kann. Ich plane einen smd-Speicher einzusetzen, siehe threads dazu zum Thema datalogger. Da auch der native 3,3V benötigt war mein Gedanke 3,3V durchgängig zu verwenden. Dann ist der avr allerdings max. 8MHz schnell! Wo liegen da die Leistungsgrenzen Daten von der sd Karte über mega2560 an 705?
Hellmut Kohlsdorf wrote: > Aus dem thread entnehme ich das ihr ebenfalls den mega2560 einsetzt mit > 3,3V Betriebsspannung? Für den Zugriff auf den onchip Bildspeicher des > 705 das externe RAM I/F des 2560? Ja. Allerdings muss man das Interface per Hand auf >16bit Adressen erweitern. > Ist ein 16-Bit-Daten-I/F wie Mario es andenkt nicht besser? Schliesslich > ist das I/F 2560 zu 705 ja schon ein Engpass. Man muss halt vergleichen, was schneller ist: 8bit Transfer per Hardware oder 16bit Transfer per Software. Ersteres benötigt 4 Takte pro Byte, letzteres 9 pro 2 Byte. Im Prinzip ist es also eigentlich egal. Der 16bit Transfer ist aber nur bei optimaler Programmierung 9 Takte lang, was ein Compiler aber nicht immer macht. Außerdem spart man dank des Adresslatches auch noch 8 Pins. Bei 16bit braucht man: 16 (Daten) + 17 (Adressen) + MR,CS,WR,RD = 37 Pins. Ich komme dagegen mit 22 Pins aus. > Ich hätte daher lieber > einen 806 eingesetzt da der BiBlt unterstützt, konnte jedoch keinen > Kartenlieferanten finden. Kein wunder, der ist auch abgekündigt. BitBlT ist aber eine feine Sache. Ich habe vor kurzem mit einem S1D13506 gespielt, je nach angeschlossenem Display schafft BitBlT einige MByte/s und kann z.B. selbstständig einzelne Buchstaben im Grafikram von 1bpp auf 8/16bpp erweitern und aufs Display kopieren. > Klar ist das auch die 256kByte Flash von mega2560 kein großer > Bilddatenspeicher sein kann. Ich plane einen smd-Speicher einzusetzen, > siehe threads dazu zum Thema datalogger. Da auch der native 3,3V > benötigt war mein Gedanke 3,3V durchgängig zu verwenden. Dann ist der > avr allerdings max. 8MHz schnell! Wo liegen da die Leistungsgrenzen > Daten von der sd Karte über mega2560 an 705? Das ist etwas dumm mit den 8MHz, ich übertakte die AVRs meist auf 10-16MHz, aber das ist keine ordentliche Lösung, auch wenn ich bisher noch keine Probleme damit hatte. Mit 16MHz und BitBlT zeichne ich auf einem 640x480 @ 8bpp Display ein Oszilloskop und darunter das Spektrum der Kurvenform. Jeweils mit Gitter und einfacher Achsenbeschriftung. Die Daten werden von einem anderen AVR geliefert, es ist also eine reine Punkte->Linien Darstellungsaufgabe. Damit erreiche ich etwa 6-7fps. BitBlT ist nur beim Löschen des Displays und beim Darstellen der Buchstaben behilflich. Das Zeichnen der Linien muss der AVR selbst berechnen. Der Hauptaufwand liegt in der Umrechnung der Pixelkoordinaten in Speicheradressen, da diese als 32bit erfolgen muss (640*480=300kByte).
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.