Hallo, ich habe mir ein EAdogl 128x64 gegönnt und wollte (bzw. will immer noch) dieses mit einem ATMEGA8 zumindest mal initialisieren, sodaß einzelne Zeichen oder auch nur Pixel gesetzt oder rückgesetzt werden können. Nun habe ich aber das Problem, daß das Modul überhaupt nix macht. Die Spannungen für den Kontrast-Booster usw. stehen auch nicht an. Als Initialisierung habe ich diese vom Datenblatt 1:1 übernommen, keine Makros usw.(an dieser Stelle in meinen Augen nur weitere Fehlerquellen). Im Verdacht hätte ich eine falsche SPI-Initialisierung des Controllers oder ein defektes Grafikmodul. Die Verdrahtung müßte praktisch zu 100% passen. Nun meine Fragen an Euch: 1. Ich habe die Eingänge des Grafikmoduls versehentlich mit 5V angesteuert. Wird es dadurch zerstört, bzw. wie empfindlich reagiert das Teil auf die 5V anstatt 3,3V? 2. Wie genau müssen die 3,3V eingehalten werden? Reichen da z.B. 2,8V Betriebs- und Signalspannung auch noch aus? 3. Wie habt ihr euren SPI am Atmel initialisiert? hier der Quellcode (da ich auf Nummer Sicher gehen wollte und für die Messung mit meinem Analog-Oszi, die ganzen Warteschleifen zwischen den Befehlen): #include <avr/io.h> #include <util/delay.h> #include <stdint.h> #include <stdbool.h> #include <avr/iom8.h> void SPI_MasterInit(); void SPI_MasterTransmit(); uint16_t i; void main(){ for(i=0; i<50000; i++);//Warteschl. zum abstecken des Programmiersteckers for(i=0; i<50000; i++); for(i=0; i<50000; i++); for(i=0; i<50000; i++); DDRB = (1<<PB0)|(1<<PB6)|(1<<PB7); for(i=0; i<65000; i++); SPI_MasterInit(); SPI_MasterTransmit(); } void SPI_MasterInit(){ DDRB = (1<<PB3)|(1<<PB5)|(1<<PB2);/* Set MOSI, SCK and SS output, all others input */ SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1)|(1<<CPOL)|(1<<CPHA); } void SPI_MasterTransmit(){ for(i=0; i<60000; i++); PORTB &= ~(1<<PB7); //reset anzeige ein for(i=0; i<50000; i++); PORTB |= (1<<PB7); //reset anzeige aus for(i=0; i<50000; i++); PORTB &= ~(1<<PB0); //CS enable anzeige PORTB &= ~(1<<PB6); //commando-mode for(i=0; i<50000; i++); SPDR = 0x40; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xA1; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xC0; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xA6; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xA2; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x2F; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xF8; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x00; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x27; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x81; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x16; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xAC; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x00; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xAF; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); //R schreiben PORTB |= (1<<PB6); //data-mode while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0x12; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xAA; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); SPDR = 0xF3; while(!(SPSR & (1<<SPIF))); for(i=0; i<50000; i++); PORTB |= (1<<PB0); //CS disable anzeige } Ich bedanke mich vielmals für eure Hilfe! Gruß Jones
Jones schrieb: > 1. Ich habe die Eingänge des Grafikmoduls versehentlich mit 5V > angesteuert. Wird es dadurch zerstört, bzw. wie empfindlich reagiert das > Teil auf die 5V anstatt 3,3V? -> Datenblatt unter maximum ratings > 2. Wie genau müssen die 3,3V eingehalten werden? Reichen da z.B. 2,8V > Betriebs- und Signalspannung auch noch aus? -> Datenblatt unter operating ratings > 3. Wie habt ihr euren SPI am Atmel initialisiert? > SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1)|(1<<CPOL)|(1<<CPHA); Ich hab jetzt nicht nachgeschaut, aber sind cpol und cpha nötig, da du ja nur das ganznormale samplen bei rising, schieben bei falling edge brauchst? übrigends: ist i (Zählvariable) als volatile deklariert? Sonst könnte dir der Optimierer n Strich durch die Rechnung machen. :-)
Der verbaute Tschipp ist augenscheinlich ein ST7565 [1]. Selbiger ist unter 'absulte max' mit 3.6V speckifiziert [2]. Falls auf dem Displaymodul keine Vorkehrungen gegen Überspannung getroffen wurden kann es also gut sein, dass das Modul den Exitus erreicht hat :-( Vielleicht hat der Delinquent auch überlebt und nur die Initialisierung ist falsch (SPI-Spielart, Wartezeiten wegoptimiert, ..). [1] http://www.lcd-module.de/produkte/dog.html [2] http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf
Auf http://www.lcd-module.de/download.html gibt es ein gutes Beispiel für die Initialisierung, sowie hier im Forum. Wichtig ist, am Anfang Reset auf Null und nach 5ms auf Eins zu setzen. Hast Du es inzwischen hinbekommen ? Ich habe nämlich das gleiche Problem. Bei mir hat es mit ziemlicher Sicherheit keine Überspannung gegeben. Ich bekomme aber nach drei Tagen und hunderten Versuchen mit verschiedensten Beispiel-Codes einfach kein einziges Pixel zur Anzeige. Kann man bei einem nicht initialisierten Display (DOGL128) ebenfalls bestimmte Spannungen messen bzw. hat jemand eine Idee wie ich anderweitig den endgültigen Tod des Displays feststellen kann ?
probiers mal mit zufälligem "Geklapper" an den SPI-Ports. Normalerweise ist dann relativ schnell eine Reaktion zu sehen, wenn das LCD in Ordnung und ist und der Rest (zusätzliche Spannungen etc.) stimmt.
Floh schrieb: > übrigends: ist i (Zählvariable) als volatile deklariert? > Sonst könnte dir der Optimierer n Strich durch die Rechnung machen. Deklarier deine Zählvariable als volatile, andernfalls werden deine ganzen Warteschleifen wegoptimiert. :-)
Das "Geklapper" bringt überhaupt nichts und Spannung kann ich keine über 3.3V messen. Das bedeutet vermutlich das der interne Step-Up - Wandler hinüber sein wird. Nur was habe ich falsch gemacht ? Die Schaltung ist die aus dem Datenblatt und die Versorgung erfolgt mittels LM317. Das das Display defekt ausgeliefert wurde ist ja wohl unwahrscheinlich, aber wie kann man bei einem erneuten Versuch das Diplay schützen ? Eine Dioden-Schutzschaltung hinter einem LM317 macht ja wohl wenig Sinn, oder ?
Hast du ein DSO oder LA? Dann wärs and der Zeit, deine Signale zu prüfen. Ansonsten weis ich nochmal darauf hin Floh schrieb: > Deklarier deine Zählvariable als volatile, andernfalls werden deine > ganzen Warteschleifen wegoptimiert. > :-)
feliks schrieb: > Das bedeutet vermutlich das der interne Step-Up - Wandler > hinüber sein wird. Der läuft erst an, wenn das Display korrekt initialisiert wurde und der Kontrast entsprechend eingestellt ist. Hast Du die Zählweise der Anschlusspins des LCDs (wie bei DIL-ICs) beachtet?
@Floh: Ich habe leider kein Oszi und benutze keine for-Schleifen in meinem Code! Die Nicht-SPI-Signale werden richtig übertragen. Ich glaube inzwischen auch nicht mehr an einen Software-Fehler. Danke trotzdem.
Ich meine, daß der Step-Up Wandler respektive die Ladungspumpe erst anläuft, wenn das Display richtig initialisiert wurde, den Kontrast eingestellt hat und den Befehl "ON" gesehen hat. Die Zählung der Pins beginnt unten links an den Hintergrund-LED-Pins und setzt sich nach rechts unten fort, wird oben rechts weitergeführt und endet oben links. Bei einem Display mit beispielsweise 16 Controllerpins ist Pin 1 unten links, Pin 16 unten rechts, Pin 17 oben rechts und Pin 32 oben links. Pin 17 bis 32 gehen zum Displaycontroller.
Poste doch mal Schaltung und Code, vielleicht sieht man was. Meins tut. Holger
Hi
>Meine EA-DOGs tun auch alle, sämtliche Versionen.
Meine auch. Man muss es nur richtig machen.
MfG Spess
Die Pins sind wie im Datenblatt. Hier die Schaltung und der Code. Das Prog arbeitet 1:1 die Empfehlungen der EA-Webseite für die Initialisierung ab. Habe aber auch diverse andere Beispiele ausprobiert.
1 | #include <avr/io.h> |
2 | #include <util/delay.h> |
3 | |
4 | #define DDR_SPI DDRB
|
5 | #define DDR_CLR DDRD
|
6 | #define PORT_SPI PORTB
|
7 | #define PORT_CLR PORTD
|
8 | #define DD_MOSI DDB5
|
9 | #define DD_SCK DDB7
|
10 | #define DD_LGHT DDD2
|
11 | #define DD_A0 DDD3
|
12 | #define DD_RST DDD5
|
13 | #define DD_CS DDD6
|
14 | #define P_MOSI PB5
|
15 | #define P_SCK PB7
|
16 | #define P_LGHT PD2
|
17 | #define P_A0 PD3
|
18 | #define P_RST PD5
|
19 | #define P_CS PD6
|
20 | |
21 | void SPI_MasterInit(void) |
22 | {
|
23 | // Set MOSI and SCK output, all others input
|
24 | DDR_SPI = (1<<DD_MOSI)|(1<<DD_SCK); |
25 | |
26 | // Enable SPI, Master, set clock rate fck/16
|
27 | SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0); |
28 | }
|
29 | |
30 | void SPI_MasterTransmit(char cData) |
31 | {
|
32 | /* Start transmission */
|
33 | SPDR = cData; |
34 | |
35 | /* Wait for display */
|
36 | _delay_us(10); |
37 | }
|
38 | |
39 | int main(void) { |
40 | |
41 | // Ausgangspins definieren
|
42 | DDR_CLR |= (1<<DD_RST)|(1<<DD_CS)|(1<<DD_A0)|(1<<DD_LGHT); |
43 | DDR_SPI |= (1<<DD_MOSI)|(1<<DD_SCK); |
44 | |
45 | // Setze RST CSB und A0 low
|
46 | PORT_CLR &= ~((1 << P_RST)|(1 << P_A0)|(1 << P_CS)); |
47 | _delay_ms(5); |
48 | |
49 | // Setze RST und LGHT high
|
50 | PORT_CLR |= (1 << P_RST)|(1 << P_LGHT); |
51 | |
52 | _delay_ms(100); |
53 | SPI_MasterInit(); |
54 | _delay_us(10); |
55 | |
56 | SPI_MasterTransmit(0x40); |
57 | SPI_MasterTransmit(0xa1); |
58 | SPI_MasterTransmit(0xc0); |
59 | SPI_MasterTransmit(0xa6); |
60 | SPI_MasterTransmit(0xa2); |
61 | SPI_MasterTransmit(0x2f); |
62 | SPI_MasterTransmit(0xf8); |
63 | SPI_MasterTransmit(0x00); |
64 | SPI_MasterTransmit(0x27); |
65 | SPI_MasterTransmit(0x81); |
66 | SPI_MasterTransmit(0x10); |
67 | SPI_MasterTransmit(0xac); |
68 | SPI_MasterTransmit(0x00); |
69 | SPI_MasterTransmit(0xaf); |
70 | |
71 | // Setze CSB high
|
72 | PORT_CLR |= (1 << P_CS); |
73 | |
74 | while (1) { asm("nop"); } |
75 | |
76 | return 0; |
77 | }
|
Hast Du auch im Makefile die Taktfrequenz angegeben? Andernfalls machen die delay-loops nicht ganz das, was sie sollen! Mit was für einem Takt läuft der SPI? Bei mir musste ich in einem Projekt den SPI Takt auf ca. 2 MHz runtersetzen, weil es sonst Übertragungsfehler gegeben hat (Pixel da wo ich sie nicht haben wollte -> Sollten immer komplette "pages" übertragen werden). Außerdem ist es zu empfehlen, jedes übertragene Byte zu synchronisieren. Also vor jedem Initialisierungsbyte den CS auf Low und danach wieder auf High (natürlich mit delays!!!). Das kannst Du ganz elegant in deine MasterTransmit() Funktion packen. Ansonsten hatte ich bei meinem 128x64 Pixel COG keine Probleme. Außer dass mein Controller leider nicht in der Lage war, den CS automatisch für jedes Byte passend zu setzen. Wäre ne feine Sache mit DMA...)
Mit dem SPI gab es doch schon letztens bei einem DOGM Probleme. Derjenige hatte es dann von Hand gemacht glaub ich. Also ich hab einen PIC mit 16MHz, Assembler, ausser beim Reset 100ms hab ich keine Warteschleifen die das LCD betreffen. Ich setze CS und A0 vor einer kompletten Übertragung (7*128 Byte) nur einmal und habe keinerlei Probleme mit falschen Pixeln. Holger
@ Matthias: Der µC-Takt ist 12MHz und der SPI-Takt ist somit 750kHz, sollte also kein Problem sein. Die Taktfrequenz steht auch im Makefile. Danke für den Tipp mit der CS-Synchronisation, das habe ich angepasst. Leider erweckt das aber mein LCD auch nicht zu leben.
Vielleicht arbeitet dein SPI nicht so wie es gewünscht ist. Dann doch mal mit den 3 Pins von Hand wackeln ? Holger
@Floh: also die for-Schleifen scheinen laut meinem Oszi zu gehen, die Befehle werden im Abstand von ca. 0.5sek. nacheinander an das Display rausgehauen. Aber das mit den SPI-Einstellungen werde ich auf jeden Fall noch ausprobieren. Wenn das dann nicht funktioniert, dann tret ich das Ding in die Tonne. (Hat mir schon genug Zeit und Haare gekostet) Den Wandler für die Kontrastspannung habe ich auch schon SW-mäßig ausgeschaltet und die externen 12V angelegt - leider auch ohne Erfolg. Die Pinbelegung vom Display ist vom Datenblatt, Ansicht von oben auf das Modul. Ansonsten vielen Dank für die Ratschläge!
Mal ´ne dumme Frage: Was habt ihr für Kondensatoren dran? Elkos? Falls ja, vielleicht sind die falsch gepolt? Ersetzt mal alle Kondensatoren am Display durch 1µF-Keramikpillen oder wenn ihr die nicht habt, 100nF-Keramikpillen. Damit laufen die Displays nämlich auch. Jones schrieb: > Den Wandler für die Kontrastspannung habe ich auch schon SW-mäßig > ausgeschaltet und die externen 12V angelegt - leider auch ohne Erfolg. Dazu mußt Du dann aber auch die Beschaltung der Kondensatoren ändern.
1. Ich habe überall 1µ Kerkos dran hängen, das kanns also auch nicht sein. Da die Dinger aber relativ teuer sind ist der Tipp mit den Elkos gut. Weißt Du wie dabei die Polung sein muß bzw. ob das überaupt möglich ist ? 2. Es muß doch eine Möglickeit geben, festzustellen ob das Teil nun defekt ist oder ob ich nur zu doof bin es zu initialisieren. Ein mechan. Wackeln an den SPI-Pins bringt überhaupt nichts. Hat da nicht noch jemand eine Idee ? Danke für Eure Hilfe !
Die Kerkos sind ok. Ich hab 1206 und auch schon 603 verbaut. Den Kontrast musste ich verändern, aber mit den Angaben im Datenblatt sieht man erstmal was (zufällig verteilte Pixel) Nochmal der Hinweis nicht das SPI Modul zu nutzen sondern erstmal die Pins direkt anzusprechen und auch prüfen ob die das so tun (langsam ansteuern, LED dran, wenn man keinen Oszi hat). Holger
Ich hab in der Schaltung keine Verblockung der Versorgung gefunden. So ist es recht unwahrscheinlich, dass das Display stabil läuft. Grüße, Peter
Nachdem ich hier im Forum erfahren habe [1], dass das Display 12V überleben soll, habe ich mich nun doch noch mal damit beschäftigt und mit SPI rumprobiert. Im Datenblatt habe ich nun den Fehler gefunden !! SS muß im SPI-Master-Mode aus Ausgang definiert sein bzw. auf High gelegt werden, da ein Low an SS als zweiter Master interprtiert wird, welcher Daten senden möchte, dh. SPI funktioniert in diesem Fall nicht. Nach folgender Änderung:
1 | DDR_SPI = (1<<DD_SS)|(1<<DD_MOSI)|(1<<DD_SCK); |
funktioniert alles wie es sollte. Vielen Dank noch mal für die Hilfe !!! [1]Beitrag "DOGM sehr robust" Hier noch der vollständige Code:
1 | #include <avr/io.h> |
2 | #include <util/delay.h> |
3 | #include <util/delay.h> |
4 | |
5 | #define DDR_SPI DDRB
|
6 | #define DDR_CLR DDRD
|
7 | #define PORT_SPI PORTB
|
8 | #define PORT_CLR PORTD
|
9 | #define DD_MOSI DDB5
|
10 | #define DD_SCK DDB7
|
11 | #define DD_SS DDB4
|
12 | #define DD_LGHT DDD2
|
13 | #define DD_A0 DDD3
|
14 | #define DD_RST DDD5
|
15 | #define DD_CS DDD6
|
16 | #define P_MOSI PB5
|
17 | #define P_SCK PB7
|
18 | #define P_LGHT PD2
|
19 | #define P_A0 PD3
|
20 | #define P_RST PD5
|
21 | #define P_CS PD6
|
22 | |
23 | void SPI_MasterInit(void) |
24 | {
|
25 | // Set MOSI and SCK output, all others input
|
26 | DDR_SPI = (1<<DD_SS)|(1<<DD_MOSI)|(1<<DD_SCK); |
27 | |
28 | SPCR = (1 << SPE)|(1 << MSTR)|(1 << CPOL)|(1 << CPHA); |
29 | //SPDR = 0xE3;
|
30 | }
|
31 | |
32 | void SPI_MasterTransmit(char cData) |
33 | {
|
34 | // CS auf low
|
35 | PORT_CLR &= ~(1<<P_CS); |
36 | // Start transmission
|
37 | SPDR = cData; |
38 | /* Wait for transmission complete */
|
39 | while(!(SPSR & (1<<SPIF))) ; |
40 | // CS auf high
|
41 | PORT_CLR |= (1<<P_CS); |
42 | }
|
43 | |
44 | int main(void) { |
45 | // Ausgangspins definieren
|
46 | DDR_CLR |= (1<<DD_RST)|(1<<DD_A0)|(1<<DD_LGHT)|(1<<DD_CS); |
47 | // Setze RST und A0 low
|
48 | PORT_CLR &= ~((1 << P_RST)|(1 << P_A0)); |
49 | _delay_ms(50); |
50 | // Setze RST,CS und LGHT high
|
51 | PORT_CLR |= (1 << P_RST)|(1 << P_LGHT)|(1<<P_CS); |
52 | |
53 | SPI_MasterInit(); |
54 | |
55 | SPI_MasterTransmit(0x40); |
56 | SPI_MasterTransmit(0xa1); |
57 | SPI_MasterTransmit(0xc0); |
58 | SPI_MasterTransmit(0xa6); |
59 | SPI_MasterTransmit(0xa2); |
60 | SPI_MasterTransmit(0x2f); |
61 | SPI_MasterTransmit(0xf8); |
62 | SPI_MasterTransmit(0x00); |
63 | SPI_MasterTransmit(0x27); |
64 | SPI_MasterTransmit(0x81); |
65 | SPI_MasterTransmit(0x16); |
66 | SPI_MasterTransmit(0xac); |
67 | SPI_MasterTransmit(0x00); |
68 | SPI_MasterTransmit(0xaf); |
69 | |
70 | while (1) { asm("nop"); } |
71 | |
72 | return 0; |
73 | }
|
Hallo zusammen, ich versuche auch seit Wochen die EADOGM128x64 zu Graphikanzeige zu bringen, ohne Erfolg. Den Microkontroller (ATmega328P) habe ich schon 280-mal programmiert mit versuchte Änderungen. Von diesem Sorte habe ich schon 3 GLCD-s, keine funktioniert. Gekauft vom MyAVR-Laden. Einfach enttäuchend, aber maßlos....Kennt jemand andere Fabrikate welche auch funktionieren ????
Hi >Einfach >enttäuchend, aber maßlos....Kennt jemand andere Fabrikate welche auch >funktionieren ???? Da das mit fast 100%-er Sicherheit an deiner Schaltung und/oder deinen Programmierkünsten liegt, wird ein anders Fabrikat nichts nutzen. Zeige lieber mal den Schaltplan und dein Programm. Bei mir haben alle bisher getesteten DOG-Displays funktioniert. MfG Spess
Hallo Spess, der Aufbau: ProgrammiererAVR MK-2 Controller: ATmega328P die EADOGM128x64 stammen vom MyAVR 2x als Bausatz, 1x als Fertiggerät Damit die Anaschlüsse sind festgelegt, angeschlossen sind Port D,B, und C Betreiben kann man den GLCD parallel oder seriell, ich habe gewählt seriell. Programmierumgebung: BASCOM version 2.0.7.5 Anschlüsse: CS1=PORTB.2, A0=PORTB.4, Si=PORTB.1, Sclk=PORTB.0, Rst=PORTB.3 Baudrate: 19200 Libs: glcdeadogm128x6.lbx, glcd.lbx, glcdsed.lbx Initialisierung: $40, $B0, $10, $A1, $C8, §A6, $2F, $A2, $2F, §A2, §F8 00, $27, $81 16 (16-3C wurde probiert), §AC 00, $A4, $AF Es liegen die erforderliche Fonts vor. Der Textkam schon von rechts nachlinks, auf Kopf gestanden, und jedesmal hat gewackelt sehr, mehrere Zeile übersprungen nach oben oder nach unten. Meistens das ganze Anzeigefeld ist schwarz und der Text kannman nur schwach erkennen aus bestimmten Blickwinkel. Grafikfunktion wie line, cirkle, box, boxfill hat noch nie ausgeführt, obwohl im Lib glcd.lbx wären die Funktionen angeblich vorhanden. Was ich bei Forums und bei MCS gefunden habe habe ich alles probiert, nichts hat geholfen...
Hi >die EADOGM128x64 stammen vom MyAVR 2x als Bausatz, 1x als Fertiggerät Bei MyAVR finde ich keine DOG-Displays! Die gibt es hier: http://www.lcd-module.de//deu/pdf/grafik/dogm128.pdf MfG Spess
Hi Spess, richtig, bei MyAVR kommt vor die Bezeichnung EADOGM128x64 nicht vor. Aber die technische Daten sind identisch, und zwar - Kontroller ST7565R-G - Display Format 128 x 64 DOTS - DotSize 0,33 x0,33 mm - View Angle 6 o' clock /12 o' clock - Driving Method 1/65 Duty, 1/9 Bias - Betriebsspannung 3,0 - 3,3 V - Max. Spannung 3,3 V Ist aber behauptet dass mit 5V wurde getestet ohne Schäden. Hersteller und Model des GLCD ist aber nirgendwo genannt. Lieferant ist die Laser & Co. Solutions GmbH. Das Ganze ist genannt vom MyAVR als: GraficLCD 1.00 Ich habe gleich die Frage gestellt der Fa. L&Co was für ein GLCD das ist. Ich bin gespannt ob eine Antwort kommt Der Stand : Texte werden angezeigt, sehr schwach zu sehen, und der Texte springen nach oben, nach unten und erscheinen wilde Zeichen auch. Ich denke dass die Daten im Displayspeicher werden hin und her geschoben... oder im AVR-Controllerspeicher... m.f.g. Jan
Hi >Aber die technische Daten sind identisch, und zwar Ich gehe mal davon aus, das du dieses http://shop.myavr.de/index.php?sp=article.sp.php&artID=200096 meinst. >Hersteller und Model des GLCD ist aber nirgendwo genannt. Da gibt es sogar ein Datenblatt des Herstellers bei MyAVR: http://shop.myavr.de/index.php?ws=download_file.ws.php&dlid=101&filename=produkte/myavr_board_mk3/db_lcd64x128-64128K.pdf >Ist aber behauptet dass mit 5V wurde getestet ohne Schäden. Im Datenblatt vom ST7565R steht eindeutig unter Maximum Ratings VDD -0.3 ~ 3.6 V. mit dem Zusatz Permanent damage to the LSI may result if the LSI is used outside of the absolute maximum ratings. Moreover, it is recommended that in normal operation the chip be used at the electrical characteristic conditions, and use of the LSI outside of these conditions may not only result in malfunctions of the LSI, but may have a negative impact on the LSI reliability as well. Unter dem Hintergrund sind solche Aussagen auf MyAVR wie > 3 bis 3,3 V (5 V getestet, nicht garantiert) schon fast als kriminell zu bezeichnen. >Der Stand : Texte werden angezeigt, sehr schwach zu sehen, und der Texte >springen nach oben, nach unten und erscheinen wilde Zeichen auch. >Ich denke dass die Daten im Displayspeicher werden hin und her >geschoben... Eher ein Timig, also Software-Problem. MfG Spess
Hi Spess, 1. Genau die GLCD meine ich, in der Beschreibung steht gleich darunter "Eigenschaften Add-On: Abmessungen: 90 x 60 x 22 mm Ansteuerung: 3 bis 3,3 V (5 V getestet, nicht garantiert) Betriebstemperatur: 0 - 50° C" Weil das ist ein Baugruppe, und definitiv ist behauptet dass auf AVR-Board anschliessbar ist(Steckerleiste Pin 13 = Plus, Pin 14=GND) man kqann gar nicht anderes anschliessen auf das AVR MK2 Board. Ich habe die Spannung gemessen, ist 5.0 V. Bemerkbar ist nichts was zerstört wäre durch die höhere Spannung. Kann die höhere Spannung hervorrufen die fehlerhafte Funktion???? Wenn das so ist,soll man nicht weiter versuchen in gang zu setzen. Muss ich dann die verwsorgungsspannung Leiterbahn trennen und ein 3,3V Spannungsregler einbauen. Da ich habe sowiso 3 solche Baugruppen kann ich eine ohne weiteres umbauen. Aber stellt sich die Frage wie kann man solche Baugruppen verkaufen??? 2. ST7565 Datenblatt haben die natürlich nicht zur Verfügung gestellt. Nicht mal als Download. Die myAVR Datenblatt bezieht sich nur auf die kpl. Baugruppeund kaum erwähnt ist der LCD-Kontroller. 3. Ich werde alle erstemal die 3,3 V Versorgungsspannung einbauen zuerst in einem GLCD. Dann versuche ich die Kontrast richtig einstellen, dann werde ich versuchen die stabile Funktion einzustellen. Für weitere Tipps und Ratschläge bin ich natürlich sehr dankbar. m.f.g. Jan
Hi Spess, nurzu Info Nachtrag zu meine Nachricht vom 04.05.2015 09:14 ich habe noch einen nicht eingebaute GLCD Display auch, dransteht der Herstellerstempel Hersteller: ROHS, HUAHAI GROUP Model ROHS 830LDF0120,64128KFCBW-3, ROHS 831C831070 Also wahrscheinlich aus Shenzhen China !!! m.f.g. Jan
Hi 2. ST7565 Datenblatt haben die natürlich nicht zur Verfügung gestellt. Nicht mal als Download. Die myAVR Datenblatt bezieht sich nur auf die kpl. Baugruppeund kaum erwähnt ist der LCD-Kontroller. Erzähle mal nicht so einen Unsinn: http://shop.myavr.de/index.php?sp=download.sp.php&suchwort=dl101 Dort sind die Datenblatter vom ST7565 und vom Display. >Ich habe die Spannung gemessen, ist 5.0 V. >Bemerkbar ist nichts was zerstört wäre durch die höhere Spannung. >Kann die höhere Spannung hervorrufen die fehlerhafte Funktion???? Außerhalb der Spezifikationen ist alles möglich. MfG Spess
Hi Spess, "Erzähle mal nicht so einen Unsinn: http://shop.myavr.de/index.php?sp=download.sp.php&... Dort sind die Datenblatter vom ST7565 und vom Display." Stimmt, jetzt steht plöclich da, im Zeitpunkt des Kaufes gab es keine ST7565 Datenblatt da. Alles wurde aus dem Internet zusammengekratzt. Übrigens: ich habe bis jetzt nur Kritik gehört über meine "Programmierkunst", über die Verdrahtung (Zusammenschaltung Display-Programmiergerät), ohne zu kennen die kritisierte Dinge (Verdrahtung oder Programm). Einen brauchbaren Vorschlag habe ich nicht gehört. Trotzt allem bedanke ich mich für die Tipps. So verbleiben wir, ich muss allein den Display zu laufen bringen.... m.f.g. Jan
Bitte 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.