Pollin Grafik LCD-Modul OPTREX F-51320AE

Ich habs auch schon bestellt.

Kenne mich aber mit den Commands auf Seite 10,11 und 12 der Spec. nicht 
aus.
Application note hab ich bis jetzt nicht gefunden.

A0 schaltet ja zwischen Command und Data um
Heißt das, dass man zuerst mit A0 = low das z.B. Page address set 
command sendet und unmittelbar danach mit A0= high die page adresse 
sendet?

nirgends beschrieben und nicht zu finden.

Vielleicht weiss jemand mehr und kann helfen. Wäre seeeehr hilfreich!

Da steht das nicht drin
habe das jetzt gefunden, muss erst lesen.
http://optrex.com/engineering/appnotes.asp?AppNoteID=148

LG Rudi

Gibts schon Erfolge, hab auch so ein Ding bestellt?

Hallo,

so wie ich es jetzt gesehen habe sind nicht alle benötigten Pins für den 
SPI mode herausgeführt. Die Pins SCL und SI sind herausgeführt (D6 und 
D7) aber der Pin P/S nicht. Mit dem schaltet man das Display um zwischen 
Parallel und Serial Data also SPI. Korigiert mich fals ich falsch liege.

MfG Tom

PS: Vielleicht ist auf dem Folienleiter ein Pullupwiderstand für den Pin 
P/S. Dann könnte man den doch anzapfen.

Moin!

Ich habe mir das Display auch vor einiger Zeit besorgt und bin nun dazu 
gekommen, mich damit zu beschäftigen. Falls jemand auch noch daran 
bastelt habe ich alles hier hochgeladen, was hilfreich sein könnte.

Optisch finde ich weiß auf blau recht schick und für 6,95€ kann man 
wirklich nicht meckern. Ich habe mir eine kleine Adapterplatine für ein 
Steckbrett gebastelt und habe dann mit einem mega16 herumprobiert, bis 
alles lief.
Für den Controller habe ich die Routinen von Benedikt genutzt und noch 
etwas angepasst. (Beitrag "Routinen für  SED1565 (z.B. für 128x64 LCD Hyundai HP12542")

SPI ist mit dem Display allerdings nicht möglich, da P/S nicht 
herausgeführt wurde.

Grüße, Basti

Wie sieht's eig aus? Hat es noch jemand zum Laufen gebracht?

Habe alles nach dem Datenblatt meiner Meinung nach richtig 
Initialisiert, und LCD lebt nicht... :(
Bin mir aber bei Flexprintbuchse nicht ganz sicher, ob die Pins am 
richtigen Pol anliegen. Weiß nicht wo Pin1 am Band und wo Pin 1 an der 
Buchse ist. Einfach mal dem Bauchgefühl nachgegangen.
Hoffe kann mir einer damit weiter helfen.

@Alex
> Habe alles nach dem Datenblatt meiner Meinung nach richtig
> Initialisiert, und LCD lebt nicht... :(

Poste doch mal deine Initialisierung und deine Beschaltung!

> Bin mir aber bei Flexprintbuchse nicht ganz sicher, ob die Pins am
> richtigen Pol anliegen.

Ich habe mal ein Bild mit hochgeladen, aus dem die Belegung ersichtlich 
sein sollte.

Ansonsten könntest du die Spannung zwischen Vdd (Pin15) und V5 (Pin27) 
messen, die sollte im Bereich von ~9V liegen.

Grüße, Basti

Hallo Sebastian,

Also was die Initialisierung angeht, ich habe jetzt dein Code 
(angepasst) genommen und es geht trotzdem nicht. Wird doch 
Hardwarefehler sein, da ich zwischen den Pins (15 und 27) gar keine 
Spannung habe.

Vllt. hab ich dich falsch verstanden und du meinst tatsächlich die 
Spannungen gegen Masse an den 2 Pins mit 2 Mal ~9V?! Gemessen habe ich 
mit Oszi, Kontakte an den von dir genannten Pins. Resultat wie gesagt 
0Volt.

Könnte ein oder andere Elko defekt sein?!

Bei den 5x  0,68µ Elkos habe ich, da ich keine gleichwertigen Elkos 
hatte, welche mit 0.47µ Elkos mit Parallel 0.22µ Folienkondensator 
geschaltet.
Messgeräte zeigen dementsprechend die Summe davon. Aber vllt. gibt es 
elektisch doch andere eigenschaft. Vllt. weißt du das?!

Danke dir.

Gruß,
Alex

P.S.
Die Pins sind richtig rum, Gott sei Dank lag mein Gefühl richtig. Nach 
langer Suche bei Google fand ich den Pin1 vom Flachband. Mit dem 
Kontakten nach oben, von Links nach Rechts steigend.

Der Fehler ist behoben. Lag an den 2 Pins die Kuzschlüsse zu benahbarten 
Pins hatten, SMD halt.

Die Spannung die du angegeben hattest ist bei mir trotzdem immer noch 
bei Null.

Welcher Typ kondensator ist demnach egal. Der Bessere Kondensator, in 
meinem Fall der FoKo, verbessert lediglich das Frequenzverhalten wenn 
die zusammen Parallel geschaltet sind.

Was ich noch hinzufügen will, fall es bei jemanden was anzeigt aber 
Pixel falsch dargestellt werden, kann am daran liegen, dass das 
Zeitverhalten nicht stimmt. Guckt zu, dass die Zeiten richtig sind. Bei 
mir läuft der mit 12MHz quarz besser wie mit 16Mhz. Obwohl alles dafür 
optimiert wurde, seltsam.

Hallo,

vorab, Danke für die tolle vorarbeit.

Leider hab ich ein Problem mit dem Quellcode.
Ich hab den Quellcode in Eclipse geladen, und die Fuses so gesetzt, wie 
ich sie vermutet habe (low = CE, ghigh = DE, ext. = 01).

Da ich nur einen Atmega168 zur hand hab, habe ich die Datenleitungen und 
die Controll leitungen umgelegt.

Datenleitungen liegen von PD0 - PD7:

1

#define LCDP  PORTD  //Port für D0-7

2

#define LCDPI  PIND

3

#define LCDDD  DDRD

Controlleitungen liegen von PC0 - PC4

1

#define LCD    PORTC  //Port für Steuerleitungen

2

#define LCDCDD  DDRC

3

4

#define  CS    0

5

#define Reset  1

6

#define A0    2

7

#define RW    3

8

#define Enable  4

Nach dem Flashen wird aber nur Pixel müll auf dem Display ausgegeben 
(aber zumindest wird etwas ausgegeben, das heißt für mich das die 
Initialisierung funktioniert). Ich hab zum Testen auch schon alles außer 
lcd_init auskommentiert, aber leider ändert das nichts.

Am Atmega ist ein 16MHz Crystal.

Ich hoffe ihr könnt mir evtl. weiterhelfen.

Gruß,
Kubax

Edit: Achja, ich hab als Condensatoren für die Platine SMD-Keramik 
genommen. Also keine Elkos mit Polung (wie sie in Eagle eingezeichnet 
sind)  kann das evtl. das problem sein? Ich hab meine Adapter Platine 
mal angehängt. Auch wenn ich nicht denke das man viel erkennen kann ;)

Hallo zusammen,

ich habe mir auch dieses Display bestellt. Im Moment habe ich aber 
leider noch keine Möglichkeit eine doppelseitige Platine (für den 
Adapter) selber herzustellen.

Hat vielleicht jemand einen guten Tipp wo ich die Platine kostengünstig 
herstellen lassen kann? Oder hat vielleicht jemand direkt mehrere 
hergestellt und könnte mir eine abtreten :-)

Wenn ich mir von eagle ein Angebot erstellen lasse, dann soll das ca. 50 
€ kosten... das ist bei einem 6,95 € Display ja nicht sinnvoll.

Danke vorab und viele Grüße
Ralf

Hallo,

bei mir läuft das Display auch! Allerdings gibt es Probleme mit den 
grafischen Anzeigen im C-Code. Wie man auf dem Bild sieht gibt es jede 
Menge falsche Pixel. Das Problem hängt eindeutig mit dem Lesen und 
Überschreiben eines Bytes zusammen. Leider konnte ich aber keine 
funktionierende Lösung finden. Ich habe mir daher selbst einen ASM-Code 
gestrickt, der problemlos funktioniert. Vom Startbild wechselt die 
Anzeige in die Darstellung des kompletten ASCII-Codes, wozu ich 
allerdings auch noch die Font-Datei ersetzen mußte.

Vielleicht hat jemand Spaß damit!

batman schrieb:
> Wie sieht das Display im Tageslicht aus? Kann man da noch was ablesen?
> Ich denke da an einen Betrieb im Amaturenbrett im Auto, also Tag+Nacht.

Ich hatte es zwar noch nie draußen, aber ich meine da gibt es keine 
Probleme. Festgestellt habe ich allerdings, daß die Darstellung besser 
wird, wenn das Bild immer wieder neu aufgebaut wird.

Gruß Bruno

Hallo zusammen,

ich habe den Adapter nun nachgebaut. Wow... meine erste doppelseitige 
Platine :-)

Leider habe ich nun ein Problem beim kompilieren von deinem Code, 
Sebastian.
Ich versuche es unter Linux (avr-gcc 4.7.0) und erhalte folgende 
Fehlermeldung:

1

Compiling: s1d1565.c

2

avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2   -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=s1d1565.lst  -std=gnu99 -DF_OSC= -DF_CPU=16000000 -MD -MP -MF .dep/s1d1565.o.d s1d1565.c -o s1d1565.o 

3

In file included from s1d1565.c:5:0:

4

font6x8s.c:2:1: error: unknown type name ‘prog_char’

5

make: *** [s1d1565.o] Fehler 1

Was kann ich tun?

Danke vorab und Gruß
Ralf

Ralf J. schrieb:
> Ich glaube dieser Beitrag hilft mir weiter:
>
> Beitrag "Alter Code mit prog_char und neue avr-libc"
>
> Offenbar ist prog_char veraltet und muss ersetzt werden. Ich bin zwar
> noch Anfänger, versuche mich aber trotzdem mal daran :)


Genau das ist das Problem. Mit dem AVR Studio 6.0 geht das nicht mehr.
Ersetze in font6x8s.c das

1

prog_char Font [256] [6] = {

durch

1

const char Font [256] [6] PROGMEM= {

dann sollte es funktionieren.

@Bruno

Danke! Das hat funktioniert.

Nun gibt es leider noch beim Linken einen Fehler:

1

Linking: main.elf

2

avr-gcc -mmcu=atmega32 -I. -gdwarf-2   -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o  -std=gnu99 -DF_OSC= -DF_CPU=16000000 -MD -MP -MF .dep/main.elf.d main.o s1d1565.o font6x8s.o   --output main.elf -Wl,-Map=main.map,--cref    -lm

3

font6x8s.o:(.progmem.data+0x0): multiple definition of `Font'

4

s1d1565.o:(.progmem.data+0x0): first defined here

5

make: *** [main.elf] Fehler 1

Ich versuche ja unter Linux zu kompilieren - kann es daran liegen? 
Ansonsten sagt mir der Fehler nichts - dafür bin ich noch zu unerfahren.

Hat noch jemand eine Idee?

@Kubax & Apr

Ja, so habe ich das auch gedeutet. Ich kann allerdings weder in den .h 
noch in den .c Dateien eine Mehrfachdefinition finden. Die Konstante 
"Font" wird einmal in font6x8s.c definiert und dann in s1d1565.c 
verwendet. Das sollte doch soweit stimmen - oder???

Ich kann mir auch nicht vorstellen, dass der Autor einen Code einstellt, 
in dem noch solch offensichtliche Fehler sind. Ich vermute daher, dass 
es etwas mit der Umgebung zu tun hat...

Ich muss es wohl doch mal mit AVR Studio versuchen :-(

@apr

OK, nun habe ich es verstanden :-)

Wie ich vermutete lag es an meiner "Umgebung". Durch deinen Hinweis bin 
ich darauf gekommen: Ich habe fälschlicherweise alle C-Dateien im 
Makefile eingetragen. Das war ja wegen des includes nicht nötig bzw. 
führte dann zu der doppelten Deklaration...

Danke für die "Erleuchtung" :-)

@Bruno

Die Grundprobleme hätte ich nun gelöst. Nun habe ich aber leider das 
Problem mit der Darstellung im Grafikmodus, dass du auch hattest (siehe 
Foto).

Kannst du mir einen Tipp geben, wie ich die .asm und die .inc Dateien 
von dir einbinde? Damit habe ich bislang überhaupt keine Erfahrung...

Nachtrag: Ich habe mir die asm-Datei mal näher angeschaut (und auch 
deinen Beitrag noch mal genau gelesen).

Wenn ich das alles richtig verstehe, dann hast du für die Programmierung 
unter C noch keine Lösung für das Grafikproblem gefunden und daher die 
Assembler-Lösung aufgesetzt.

Wenn ich die verwenden möchte, dann muss ich vermutlich auch in 
Assembler programmieren - oder?

Hat vielleicht noch jemand dieses Grafikproblem und eine Lösung in C 
gefunden? Ich lerne ja gerade C in Verbindung mit µC und da erscheint 
mir ein Exkurs in die Maschinensprache doch etwas verfrüht bzw. im 
Moment zu aufwändig...

Noch ein NACHTRAG:

Von t-g-m kam der Hinweis, dass die CPU-Frequenz bei der 
Pixeldarstellung auch eine Rolle spielt. Er schreibt z.B., dass das 
Display bei 12Mhz besser läuft als bei 16Mhz.

Ich habe daher mal die Frequenzen von meinem Mega32 durchgespielt (1, 2, 
4, 8 - intern und 16Mhz extern).

Tatsächlich gibt es signifikante Unterschiede bei der Darstellung: Bei 
manchen Frequenzen ist die Textdarstellung ebenfalls 
betroffen/fehlerhaft und bei manchen Frequenzen stimmt die Position der 
Uhrzeit (rechte obere Ecke). Beim 16Mhz Betrieb wie auf meinem Foto, 
stimmt die Position nicht.

Vielleicht ist das ein Hinweis auf die Fehlerquelle???

Ich habe nun mal den Originalcode von Benedikt getestet.

Beitrag "Routinen für  SED1565 (z.B. für 128x64 LCD Hyundai HP12542"

Damit funktioniert die Textdarstellung mit allen Frequenzen zuverlässig. 
Leider sind aber keine Grafikroutinen enthalten.

Vielleicht hilft das auch bei der Eingrenzung des Fehlers :-)

Ich habe meine Versuche mit dem Code noch nicht aufgegeben.

Es ist mir inzwischen gelungen die Fehlerquelle einzugrenzen.

1

void lcd_setpixel(unsigned char x, unsigned char y, unsigned char color)

2

{

3

  unsigned char temp;  

4

  lcd_setadress(x,y / 8);

5

//  temp = lcd_readdata();

6

  lcd_setadress(x,y / 8);

7

  if(color)

8

    lcd_writedata(temp | (1 << (y % 8))); 

9

  else

10

    lcd_writedata(temp & ~(1 << (y % 8))); 

11

}

Wenn ich das "lcd_readdata()" auskommentiere (wie im Code oben), dann 
wird der Text-/Grafikmodus nicht mehr zerschossen.

Bislang war das ja so, dass bei einem Reset sowohl die Grafik als auch 
der Text - mehr oder weniger stark - zerschossen wurde.

Nun, mit dem auskommentierten readdata ist der Textmodus in Ordnung und 
die Grafiken werden ebenfalls besser gezeichnet, wenn auch nicht 
vollständig. Die Ergebnisse sind nun reproduzierbar (es sieht also immer 
gleich aus) während beim Aufruf der readdata() Funktion das Display 
immer willkürlich zerschossen wird - also immer anders schrottig 
ausschaut!

Siehe Foto: Das Ergebnis ist wesentlich besser als auf den Bildern zuvor 
(z.B. stimmt die Position der Uhrzeit nun immer).

Fakt ist jedenfalls, dass das Aufrufen von lcd_readdata() das Display 
völlig aus dem Tritt bringt - aber warum?

Die Funktion sieht so aus (und sagt mir rein gar nix... Anfänger 
halt...)

1

unsigned char lcd_read (unsigned char com)

2

{

3

  unsigned char byte;

4

  if (com==1) {cbi(LCD,A0);}

5

  else {sbi(LCD,A0);}

6

  LCDP=255;

7

  LCDDD=0;

8

9

  cbi(LCD,CS);

10

  sbi(LCD,RW);

11

  sbi(LCD,Enable);

12

  cbi(LCD,Enable);

13

  sbi(LCD,CS);

14

15

  cbi(LCD,CS);

16

  sbi(LCD,Enable);

17

  _delay_us(1);

18

  byte=LCDPI;

19

  cbi(LCD,Enable);

20

  sbi(LCD,CS);

21

22

  LCDDD=255;

23

  return byte;

24

}

Weiß jemand Rat?

Hallo Ralf!

Ich habe im Moment viel zu tun, deswegen kann ich keine funktionierende 
Lösung bieten, nur einen Ansatz.

Die Funktion, die bei dir Probleme macht, hat den einfachen Ursprung, 
dass man bei diesem Display immer ein Byte auf einmal schreibt. Das 
Display ist also in 128 Spalten und 8 Zeilen à 8 Pixel eingeteilt. Will 
man also einen einzelnen Pixel ändern, so ist man gezwungen den Zustand 
von 8 Pixeln fest vorzugeben. Weiß man von den anderen 7 Pixeln nicht, 
ob diese hell oder dunkel sind, gibt man diesen einen festen Zustand vor 
und überschreibt so die alten werte.
Über die Funktion "lcd_readdata()" wird dies vermieden und das gesamte 
Byte in der aktuellen Spalte/Zeile ausgelesen. Anschließend entsprechend 
verändert und per write wieder an die alte Position geschrieben.

Ich kann mich daran erinnern, dass das ganze für meinen Anwendungszweck 
funktionierte, aber instabil lief, sobald ich die Taktfrequenz (16MHz) 
geändert habe. Warum konnte ich mangels Zeit nicht ergründen. Ein Ansatz 
wäre, in dem Datenblatt vom Controller S1D15605 aus meinem Beitrag 
weiter oben 
(Beitrag "Re: Pollin Grafik LCD-Modul OPTREX F-51320AE") 
nachzusehen (11. Timing Characteristics 6800Series MPU), ob alle 
Wartezeiten beim Auslesen eingehalten werden und entsprechend Delays zu 
setzen.

Ein einfaches Workaround wäre natürlich, readdata auszukommentieren, auf 
den Grafikmodus zu verzichten und Text nur in ganzen Zeilen zu 
schreiben, sodass man keine anderen Pixel überschreiben kann, das 
entspricht dann in etwa dem Quelltext von Benedikt, den ich erweitert 
habe.

Vielleicht hilft dir das ein wenig weiter!

Hi Sebastian,

danke für die erklärende Antwort. Mir war der Sinn des Auslesens in der 
Tat zunächst schleierhaft - nun ist es klar.

Ich werde dann bei Gelegenheit mal mit dem Datenblatt und den Timings 
jonglieren... vielleicht kriege ich es ja hin :-)

Bei mir läuft das Display übrigens auf einem Mega32 mit 16Mhz Quarz.

Der Workaround mit dem Grafikverzicht funktioniert. Mir war das heute 
auch aufgefallen und dann dachte ich mir schon, dass Benedikts Code 
einfach das readdata nicht verwendet und daher "funktioniert"...

Gruß
Ralf

Mal wieder ein wenig schlauer...

Das Display kommt aus dem Tritt wenn das RW Bit gesetzt wird (also in 
der Funktion lcd_read() die Anweisung sbi(LCD,RW). Danach kommt nur noch 
Murks. Nimmt man die Anweisung raus, dann bleibt das Display in der Spur 
und nur die Bytes für die grafischen Elemente stimmen nicht mehr.

Die Timings aus dem Datenblatt sind für mich noch nicht verständlich. Im 
Kontext zur Software wird es nicht einfacher. Da bin ich als AVR und C 
Anfänger dann doch (noch) stark überfordert :-(

Ich habe ein wenig trial and error gemacht aber ohne Erfolg.

Vielleicht könnte ein erfahrener User da mal schauen und noch ein paar 
Tipps geben? Wäre klasse :-)

Argh...

Et lüppt!

Es war ein Hardware-"Fehler". Weil ich mit dem SMD-Sockel vorsichtig 
umgehen wollte habe ich wohl die Arretierung des Flachbandkabels zu 
leicht reingedrückt. Jedenfalls war es auf der R/W Seite nicht richtig 
arretiert und hatte dadurch wohl keinen richtigen Kontakt.

So was Dummes!!!

Na ja, immerhin habe ich durch diesen Fehler wirklich viel aus dem Code 
gelernt. Ich hätte mir die Display-Routinen sonst sicher nicht so 
gründlich angeschaut - so hatte es dann doch was Gutes!!! :-)

Nochmals vielen Dank an alle für die Geduld (mit mir) und die vielen 
guten Tipps. Ohne hätte ich es nicht geschafft!

Gruß
Ralf

Ein Tip für alle mit dem gleichen Problem, die aber keinen 
Hardwarefehler finden können.

Angeregt durch den Erfolg von Ralf (dafür herzlichen Dank), habe ich das 
Display auch noch einmal ausgepackt und die Hardware überprüft. Ergebnis 
negativ! Dann habe ich mir nochmals den Code angesehen und versuchsweise 
in der lcd_read das _delay_us(1) auf _delay_us(2) geändert und siehe da, 
die Anzeige ist nun OK.

Gruß
Bruno

@Bruno: Schön, dass es bei dir nun auch fehlerfrei funktioniert.

Ich habe übrigens noch nach einer Möglichkeit gesucht, dass Backlight 
schaltbar zu machen. Ich benötige das für meine Anwendung.

Nach etwas Grübeln bin ich dann auf eine funktionierende Lösung 
gekommen. Ich  steuere einfach über einen freien Ausgang meines ATmega32 
einen Transistor an, der seinerseits die Beleuchtung einschaltet. Den 
Code habe ich dann noch um ein LCD_Backlight_on() bzw. ...off() 
erweitert. Klappt super.

Ist vermutlich hier unter den Profis ein alter Hut aber vielleicht hilft 
es ja einem suchenden Anfänger wie mir :-)

Schöne Grüße
Ralf

Hallo Ralf,
dann könntest du das Backlight auch gleich per PWM dimmen.

Gruß Michael

Michael D. schrieb:

> dann könntest du das Backlight auch gleich per PWM dimmen.

Stimmt! Das wäre auch ein netter Effekt. Werde ich mal versuchen...

Gruß
Ralf