Hallo,
ich möchte gerne dieses Display:
http://www.wvshare.com/product/3.2inch-320x240-Touch-LCD-B.htm
ansteuern.
Das Datenblatt vom verwendeten Controller SSD1289 findet sich hier:
http://www.wvshare.com/product/3.2inch-320x240-Touch-LCD-B.htm
Das Display ist soweit fertig verkabelt und ich befinde mich noch ganz
am Anfang ein entsprechendes Programm zu schreiben. Verwendeter
Controller ist ein Atmega 1284P. Ich programmiere in ASM mit dem AVR
Studio 5.
Ich hab eine kleine Frage zum Ablauf wie ich das Display anspreche. Auf
Seite 72 im Datenblatt ist eine Initialisierungssequenz angegeben. Aber
wie genau schicke ich jetzt dem Display die Befehle? Als erstes
natürlich das Commandregister, als Befehl oder als Daten? Und direkt
danach einfach der Inhalt des Ensprechenden Register? Auch als Befehl
oder als Daten? ich bin da ziemlich ratlos.
Danke für jede Hilfe!
Hi
>Eigentlich müsste es so funktionieren und>zumindest die ersten paar Pixel die Farbe wechseln. Tun sie natürlich>nicht.
Schon mal etwas von einem Stackpointer gehört?
MfG Spess
Ja, natürlich. Aber musste man das bei den neuren AVRs nicht mehr
machen?
Wie dem auch sei, ich nach dem letzen .equ noch das hier:
RESET:
ldi r16,high(RAMEND)
out SPH,r16
ldi r16,low(RAMEND)
out SPL,r16
eingefügt.
Es ändert sich nichts.
Hi
>Ja, natürlich. Aber musste man das bei den neuren AVRs nicht mehr>machen?
Stimmt. Kann ich mich nicht so richtig dran gewöhnen. Aber hast du das
JTAG-Interface (PortC) deaktiviert?
MfG Spess
spess53 schrieb:> Musst du nur von C nach Assembler übersetzen:
Hi Spess,
ich nehme an, du meintest:
Beitrag "Re: Suche LCD Treiber SSD1289"
Frage an den TE: Warum hast du dich auf Assembler festgelegt?
Du willst doch sicherlich etwas mehr als "Hello, World!" darauf
darstellen.
Grüße
Stefan
Hi
>ich nehme an, du meintest:>Beitrag "Re: Suche LCD Treiber SSD1289"
Klar. Falschen Link kopiert.
>Frage an den TE: Warum hast du dich auf Assembler festgelegt?>Du willst doch sicherlich etwas mehr als "Hello, World!" darauf>darstellen.
Was kann C, was Assembler nicht kann? Eher würde ich sagen, das es mit
dem ATMega1284P etwas knapp wird.
MfG Spess
Ich hab, bis jetzt, noch nichts mit C im Mikrocontroller bereich
gemacht. Deshalb wollte ich jetzt nicht das Pferd wechseln :)
Und wieso sollte es mit dem ATMega1284P knapp werden? Klar, für Videos
oder ähnlich Späße ist der natürlich zu schwach. Aber z.B. ein Bild vom
PC empfangen und auf dem Display ausgeben sollte ja wohl drin sein.
spess53 schrieb:> Was kann C, was Assembler nicht kann?
Das hängt davon ab, was du unter "können" verstehst.
Natürlich kann ich alles auch allein in Assembler machen. (Alternative
für die ganz Harten: Direkt codieren im Hex-Editor...)
Aber ich weiß es zu schätzen, dass mir der Compiler bei großen Projekten
(Routine-) Arbeit abnehmen kann und ich trotzdem bei Bedarf noch
Einfluss darauf nehmen kann, was er so treibt. Und wenn nötig, kann ich
immer noch einzelne Funktionen auf Assemblerebene optimieren.
> Eher würde ich sagen, das es mit dem ATMega1284P etwas knapp wird.
Das denke ich auch. Immerhin hat sein Display 76800 Pixel und 16 Bit
Farbtiefe.
Grüße
Stefan
Pitz schrieb:> Aber z.B. ein Bild vom> PC empfangen und auf dem Display ausgeben sollte ja wohl drin sein.
Tipp: Rechne mal nach, wie viel Byte Daten das sind und vergleiche das
mit den Daten des ATMega.
Grüße
Stefan
HI
>Und wieso sollte es mit dem ATMega1284P knapp werden? Klar, für Videos>oder ähnlich Späße ist der natürlich zu schwach.
Das Display hat 76800 Pixel. Und wenn ich das Datenblatt richtig
verstanden habe, sind pro Pixel mindestens zwei 16-Bit-Zugriffe
notwendig.
Der RAM ist zwar mit 16K für AVRs recht üppig kann aber auch kein
vollständiges Bild zwischenspeichern. D.h. dein Bild muss stückchenweise
übertragen werden.
Im Flash ließe sich bei reduzierter Farbtiefe (8 Bit) gerade ein Bild
unterbringen.
Wenn AVR, würde ich bei dem Display einen ATXMega mit externem RAM
benutzen.
MfG Spess
Stefan Wagner schrieb:> Pitz schrieb:>> Aber z.B. ein Bild vom>> PC empfangen und auf dem Display ausgeben sollte ja wohl drin sein.>> Tipp: Rechne mal nach, wie viel Byte Daten das sind und vergleiche das> mit den Daten des ATMega.>> Grüße>> Stefan
Wiso nachrechnen? Er muss doch einfach die Daten an das Display
weiterreichen und eben nur zwischenspeichern, also nicht das ganze Bild
im AVR hinterlegen.
Eben, dass ich das Bild nicht komplett im ram haben kann ist mir schon
klar. Und wenn ich jetzt ein einfaches Interface (das Display hat einen
touchscreen) mit ein paar Buttons etc. anzeige muss ich ja auch nicht
jedes Pixel einzeln wissen. Es reicht ja z.B. eine Funktion zu haben die
ein Rechteck bestimmer Farbe zeichnet. Die kriegt dann ja nur Größe
Farbe und Position übergeben. Viel Daten sind das nicht.
Du solltest trotzdem einen anderen Prozessor nehmen: einen mit externem
Memory Interface. Beispiel: Mega 640/1280/2560/641/1281/2561. Das
Display hat nämlich ein Interface, was kompatibel zum Speicherinterface
des AVR ist. Da musst Du nicht mehr Portpins einzeln ansprechen, sondern
nur noch einen Speicherzugriff auf eine externe Adresse machen. Die
ganzen Pins bedient der AVR dann automatisch. Das geht dann auch VIEL
schneller - etwa Faktor 10.
Außerdem kannst Du dann noch problemlos einen extra RAM-Chip anklemmen.
fchk
Hi
>Eben, dass ich das Bild nicht komplett im ram haben kann ist mir schon>klar. Und wenn ich jetzt ein einfaches Interface (das Display hat einen>touchscreen) mit ein paar Buttons etc. anzeige muss ich ja auch nicht>jedes Pixel einzeln wissen. Es reicht ja z.B. eine Funktion zu haben die>ein Rechteck bestimmer Farbe zeichnet. Die kriegt dann ja nur Größe>Farbe und Position übergeben. Viel Daten sind das nicht.
Setzt aber voraus, das du die Initialisierung und das Beschreiben der
Pixel gebacken bekommst.
>Das>Display hat nämlich ein Interface, was kompatibel zum Speicherinterface>des AVR ist. Da musst Du nicht mehr Portpins einzeln ansprechen, sondern>nur noch einen Speicherzugriff auf eine externe Adresse machen.
Nein. Das Display hat keinen Adressbus.
MfG Spess
"Setzt aber voraus, das du die Initialisierung und das Beschreiben der
Pixel gebacken bekommst."
Vollkommen richtig, das ist der erste Schritt. Und den versuche ich
gerade zu machen.
spess53 schrieb:>>Das>>Display hat nämlich ein Interface, was kompatibel zum Speicherinterface>>des AVR ist. Da musst Du nicht mehr Portpins einzeln ansprechen, sondern>>nur noch einen Speicherzugriff auf eine externe Adresse machen.>> Nein. Das Display hat keinen Adressbus.
Doch. Zwar nur ein Bit breit, aber er ist da. Nennt sich RS und kommt an
A1.
Das einzige, was noch dazukommt, ist ein Latch für die oberen 8 Bit. Ist
auch noch Zurücklesen gewünscht, braucht es noch ein zweites. Die
Ausdekodierung des CS für Display und Latch macht man sinnigerweise über
A0. Dann klappen auch 16 Bit Zugriffe einfach so.
fchk
Nö, die unteren Bits werden beim AVR wie beim 8031 per ALE auf den
Datenbus auf Port A gemultiplext. Wenn Du das dafür nötige Latch
einsparen willst, kannst Du auch A8 und A9 verwenden, die auf Port C.0
und C.1 liegen. Du kannst bitweise von unten Adressbits auf Port C
schalten und die restlichen Portbits ganz normal weiter benutzen. Steht
alles im Datenblatt. Ich denke, lesen kannst Du selber.
Ich habe übrigens die ganze Logik mal in einem 9572XL CPLD
implementiert, das dann so nebenbei auch als Level Shifter dient. Meine
Displays sind nämlich nicht 5V-tolerant.
fchk
Ich habe diese Display:
http://www.ebay.de/itm/190451748066?
Kontroller ist der gleiche wie bei deinem.
Ic hänge mal meine LCD-Routine, eine grobe Main-Routine für einen Mega64
und zwei unterschiedlich große Schriften mit an.
Vielleicht hilft es dir.
