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!
So, hier ist der akutlle Code. Eigentlich müsste es so funktionieren und zumindest die ersten paar Pixel die Farbe wechseln. Tun sie natürlich nicht.
1 | .include "m1284pdef.inc" |
2 | .equ DatenDDR0 = DDRA |
3 | .equ DatenDDR1 = DDRC |
4 | .equ DatenPORT0 = PORTA |
5 | .equ DatenPORT1 = PORTC |
6 | .equ DatenPIN0 = PINA |
7 | .equ DatenPIN1 = PINC |
8 | .equ D0 = PORTA0 |
9 | .equ D1 = PORTA1 |
10 | .equ D2 = PORTA2 |
11 | .equ D3 = PORTA3 |
12 | .equ D4 = PORTA4 |
13 | .equ D5 = PORTA5 |
14 | .equ D6 = PORTA6 |
15 | .equ D7 = PORTA7 |
16 | .equ D8 = PORTC0 |
17 | .equ D9 = PORTC1 |
18 | .equ D10 = PORTC2 |
19 | .equ D11 = PORTC3 |
20 | .equ D12 = PORTC4 |
21 | .equ D13 = PORTC5 |
22 | .equ D14 = PORTC6 |
23 | .equ D15 = PORTC7 |
24 | .def temp0 = r16 |
25 | .def temp1 = r17 |
26 | .def temp2 = r18 |
27 | |
28 | .equ SteuerDDR = DDRD |
29 | .equ SteuerPORT = PORTD |
30 | .equ CS = PORTD7 |
31 | .equ RS = PORTD6 |
32 | .equ WR = PORTD5 |
33 | .equ RD = PORTD4 |
34 | .equ LCDRESET = PORTD3 |
35 | |
36 | |
37 | |
38 | |
39 | rcall DELAY |
40 | rcall INIT |
41 | rcall LCD_INIT |
42 | rcall LCD_DATA |
43 | rcall LCD_DATA |
44 | rcall LCD_DATA |
45 | rcall LCD_DATA |
46 | rcall LCD_DATA |
47 | rcall LCD_DATA |
48 | rcall LCD_DATA |
49 | rcall LCD_DATA |
50 | rcall LCD_DATA |
51 | rcall LCD_DATA |
52 | rcall LCD_DATA |
53 | main: |
54 | rjmp main |
55 | |
56 | LCD_COMMAND: ; schreibt Befehl r20 r21 in Register r22 |
57 | push temp0 |
58 | ldi temp0, (0<<CS) | (1<<RS) | (0<<WR) | (1<<RD) |
59 | out SteuerPORT, temp0 |
60 | out DatenPORT0, r22 |
61 | ldi r16,0 |
62 | out DatenPORT1, r16 |
63 | sbi SteuerPORT, CS |
64 | ldi temp0, (0<<CS) | (0<<RS) | (0<<WR) | (1<<RD) |
65 | out DatenPORT0, r20 |
66 | out DatenPORT1, r21 |
67 | sbi SteuerPORT, CS |
68 | pop temp0 |
69 | ret |
70 | |
71 | LCD_DATA: ;schreibt r20 r21 ins lcd ram |
72 | push temp0 |
73 | ldi temp0, (0<<CS) | (0<<RS) | (0<<WR) | (1<<RD) |
74 | out DatenPORT0, r20 |
75 | out DatenPORT1, r21 |
76 | sbi SteuerPORT, CS |
77 | pop temp0 |
78 | ret |
79 | |
80 | DELAY: ; 52 mS Delay |
81 | push temp0 |
82 | push temp1 |
83 | push temp2 |
84 | ldi temp0,0 |
85 | ldi temp1,0 |
86 | ldi temp2,0 |
87 | |
88 | DELAY_loop0: |
89 | inc temp0 |
90 | cpi temp0,0 |
91 | brne DELAY_loop0 |
92 | inc temp1 |
93 | cpi temp1,0 |
94 | brne DELAY_loop0 |
95 | inc temp2 |
96 | cpi temp2,4 |
97 | brne DELAY_loop0 |
98 | |
99 | pop temp2 |
100 | pop temp1 |
101 | pop temp0 |
102 | ret |
103 | |
104 | INIT: ;Ports initialisieren |
105 | ldi temp0,255 |
106 | out DatenDDR0,temp0 |
107 | out DatenDDR1,temp0 |
108 | out SteuerDDR,temp0 |
109 | sbi SteuerPORT, LCDRESET |
110 | ret |
111 | |
112 | LCD_INIT: ;LCD initialisieren, siehe Datenblatt S.71 |
113 | ldi r22,0x07 |
114 | ldi r21,0x00 |
115 | ldi r20,0x21 |
116 | rcall LCD_COMMAND |
117 | ldi r22,0x00 |
118 | ldi r21,0x00 |
119 | ldi r20,0x01 |
120 | rcall LCD_COMMAND |
121 | ldi r22,0x07 |
122 | ldi r21,0x00 |
123 | ldi r20,0x23 |
124 | rcall LCD_COMMAND |
125 | ldi r22,0x10 |
126 | ldi r21,0x00 |
127 | ldi r20,0x00 |
128 | rcall LCD_COMMAND |
129 | rcall DELAY |
130 | ldi r22,0x07 |
131 | ldi r21,0x00 |
132 | ldi r20,0x33 |
133 | rcall LCD_COMMAND |
134 | ldi r22,0x22 |
135 | ldi r21,123 |
136 | ldi r20,123 |
137 | rcall LCD_COMMAND |
138 | ret |
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
Hat denn niemand Erfahrung mit dem Display? Das kriegt man bei ebay ja fast nachgeworfen ;)
Hi
Musst du nur von C nach Assembler übersetzen:
>Beitrag "Hilfe bei SSD1289 Display Controller"
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
Hi >Doch. Zwar nur ein Bit breit, aber er ist da. Nennt sich RS und kommt an >A1. Und dafür opfert man einen ganzen Port? MfG Spess
Angehängte Dateien:
-
DSC05167s.JPG
120 KB -
DSC05168s.JPG
190 KB
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.
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.