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!
Hallo Zusammen
Nach Durchsicht des Controller Datenblatts und bestätigt durch einen
anderen Artikel (Beitrag "Displaycontroller ST7565"), müsste
eine ST7565 library eigentlich funktionieren.
Also, beispielsweise U8glib:
http://code.google.com/p/u8glib/wiki/device
Voraussetzung wäre allerdings, dass die notwendigen Leitungen zum
Umschalten auf SPI mode bei dem Display herausgeführt sind. Ansonsten
müsste man die U8glib etwas erweitern, was aber auch kein großes Problem
wäre.
Grüße,
Oliver
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.
Ich hab das Display auch geordert.
Bei Epson bin ich insoweit fündig geworden, dass der verbaute Prozessor
wohl mit dem SED1565 entspricht
Siehe: http://www.lcd-module.de/eng/pdf/zubehoer/s1d15605.pdf
Vielleicht hilft uns das weiter :-)
Gruß
Bernd
Hi
>Bei Epson bin ich insoweit fündig geworden, dass der verbaute Prozessor>wohl mit dem SED1565 entsprichtBeitrag "Re: Displaycontroller ST7565"
MfG Spess
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.
moin,
ich kann irgendwie die Eagle-Dateien nicht richtig laden,
mag die vielleicht nochmal einer reinstellen, oder notfalls auch nur den
Schaltplan zeigen, kann mir das dann notfalls auch selber nochmal
zusammenklicken.
mfg und Danke
Hi,
vielen Dank für den Code, habe noch ein paar Kleinigkeiten geändert,
weil ich die Datenleitungen auf zwei Ports verteilen musste.
Zur Info: Weil ich gerade keine anderen Kondensatoren da hatte läuft die
Schaltung bei mir mit 5 x 1µF Elkos für die Regelung und 3 x 2,2µF für
den Booster.
Gruß
Benedikt
Wie kann ich mit dem Quelltext String ausgeben?
Also nicht so ein String -> lcd_string_P("hallo welt")
sondern so eins:
char MyString[10] = "Hallo";
lcd_String( MyString );
wie kann man das realisieren?
Danke! :)
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:
Tom M. schrieb:> Hast du diese include in der s1d1565.c?>> #include <avr/pgmspace.h>
Leider ja... ich hatte diesen Hinweis auch schon gefunden und überprüft.
>In file included from s1d1565.c:5:0:>font6x8s.c:2:1: error: unknown type name ‘prog_char’>> #include <avr/pgmspace.h>>Leider ja... ich hatte diesen Hinweis auch schon gefunden und überprüft.
Und das auch vor dem Schwachsinn eine C Datei in eine C Datei
zu includen?
#include <avr/pgmspace.h>
#include "font6x8s.c"
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 :)
Ahhh... habe noch was gefunden...
Im Makefile muss ich die CFLAGS ergänzen um folgendes ergänzen:
-Wno-deprecated-declarations -D__PROG_TYPES_COMPAT__
Damit sollte es ohne Code-Änderungen funktionieren.
Ich werde das morgen mal testen!
Danke für die Tipps!
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
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?
Ich bin zwar jetzt auch nicht so die Granate, aber ich würde die
Fehlermeldung so deuten, das "Font" mehrfach definiert ist.
Wenn ich das richtig sehe einmal in der "s1d1565.h" und einmal in der
"font6x8s.h".
@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 :-(
Wie gesagt: In der s1d1565.c wird steht ein #include "font6x8s.c". Also
wird folgerichtig der gesamte Inhalt dort eingefügt und kompiliert. Hier
wird unter Anderem ein Symbol "Font" definiert.
Weiterhin kompilierst du offenbar die font6x8s.c -- zumindest wird ein
.o dafür erzeugt. Hier wird ein Symbol "Font" definiert. Danach versucht
du das alles zu linken und der beschwert sich. Da "Font" zweimal
definiert wurde. Einmal in der s1d1565.c und einmal in der font6x8s.c.
Entweder du kompilierst font6x8s.c nicht, oder du schreibst ein static
davor, oder du nimmst das include raus und definierst "Font" als extern.
@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...)
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
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
Hi, hat zufällig noch jemand den FPC-SMT-30pol-0.5-Vertikal- für Lau
rumliegen?
Bei Pollin gibt es den nicht mehr und Versandkosten sind ja auch nicht
ohne.
Gruß,
Philipp