Forum: Mikrocontroller und Digitale Elektronik S65 Display Unterschiede zw LPH88* und LP-88* ?


von Gregor B. (gregor54321)


Lesenswert?

Hallo,
weiß jemand ob es Unterschiede gibt zwischen dem LPH88* Display und dem 
LP-88*? Ich versuche mich gerade in die Ansteuerung mit Hilfe von 
http://www.superkranz.de/christian/S65_Display/DisplayIndex.html 
einzuarbeiten. Konnte dem Display aber noch nichts außer der 
Hintergrundbeleuchtung entzaubern. Ich habe auf einem Steckbrett den 
Atmega32 bei 5V und 8MHz laufen. Über einen LM317 hab ich 2.75V (soll: 
2.9V/1.8V) für den Displaycontroller bereit gestellt. Pinning ist über 
U-Teiler (3k9/4k7) so ausgelegt:

LCD       Atmega32

1  RS     PB2  I/O
2  Reset  PB1  I/O
3  CS     PB4  !SS
4  CLK    PB7  SCK
5  DAT    PB5  MOSI
6  2.9V   ---  2.75V
7  GND    ---  GND
8  1.8V   ---  2.75V
9  LED+   ---  10V
10 LED-   ---  GND

CS wird LOW, wenn mit dem Display gesprochen wird. Ist das korrekt?

von Hagen R. (hagen)


Lesenswert?

Hast du am LM317 eine Dauerlast, zb. Widerstand ? Die Stromaufnahme des 
Displays liegt nämlich weit unterhalb der notwendigen Dauerlast für den 
LM317 damit dieser die Ausgangspannung genau regeln kann.

Gruß hagen

von Lothar L. (lole)


Lesenswert?

Das Problem hatte ich beim ersten Versuch auch. Christians Quellen gehen 
von 16MHz aus, als ich die 8MHz eingesetzt habe ging es auf Anhieb. Ich 
arbeite allerdings mit 3V, also ohne Pegelwandler. Deine 
Widerstandswerte finde ich zu hoch. Kann sein, dass bei Deinen 4MHz 
SPI-Clk die Flanken zu sehr verschleifen.
Grüsse
Lothar

von Gregor B. (gregor54321)


Angehängte Dateien:

Lesenswert?

Die Grundlast ist mittels R1+R2 der Grundschaltung gegeben, da fließen 
knapp 5mA. Oszi zeigts auch Sauber an.

Ich habe die Spannung jetzt auch auf 3V erhöht. Weiter werde ich mich 
nicht trauen. Bisher noch ohne Erfolg.

Ich habe für mein LP-8836* Display die RS Leitung entfernt. Nach 
Programm und Oszi bleibt diese Leitung während der gesamten Laufzeit 
HIGH. Außerdem habe ich das SPI2X für SPSR nicht gesetzt (SPI also nicht 
auf doppelter Geschwindigkeit). Auch Tests auf 4MHz waren nicht 
erfolgreich.
Zusätzlich habe ich Bergeweise delays eingebaut. Ich hab das 
(AVR-Studio-) Projekt mal hinten dran gehängt.
Vielleicht kann mir jemand mal seine Routine schicken. Das Display (auch 
mein LP-88*?) haben ja schon mehrere in Gang bekommen.

von Lothar L. (lole)


Lesenswert?

Wenn Du einen Oszi hast, ein LA wäre besser, kontrolliere die 
Initialisierungssequenzen, vor allem die Pausenzeiten dazwischen. Die 
scheinen ziemlich zeitkritisch zu seien. Weil es schon öfter Probleme 
mit LPx berichtet wurden, habe ich gleich ein LS20 genommen.
Grüsse
Lotahr

von Gregor B. (gregor54321)


Lesenswert?

LogikAnalyser hab ich leider nicht. Pausenzeiten sind aber mit dem 
AVR-Simulator geprüft. Flanken sind jetzt mit 390R/470R tatsächlich viel 
besser. Geht leider trotzdem nicht. :-(

Sehe ich das Richtig, das CS während der Kommunitation LOW ist und in 
die lcd_init_c() Verzögerungen eingebracht werden mussten?

Gibt es noch eine weitere Seite im Netz, die sich mit den Sequenzen der 
verschiedenen S65 Displays beschäftigt?

von Lothar L. (lole)


Lesenswert?

SPI kann durchaus mehrere periphere Geräte ansteuern, nur das mit 
/CS=low wird angesprochen. Da Du nur das Display dran hast, kann /CS 
auch ständig auf Low liegen, ist in Christians Programm aber nicht der 
Fall (glaube ich). Müsste ich heute Abend mal nachschauen. Einem 
Simulator würde ich nur begrenzt vertrauen. Wenn die Fuses nicht 
stimmen, gerade beim Takt, stimmt gar nix mehr. Kannst Du aber am 
SPI-Clk mit dem Oszi kontrollieren.

von Gregor B. (gregor54321)


Lesenswert?

SPI Frequenz an SCK bei uC@8MHz liegt bei 500kHz(SPI2X = 0) bzw 
1MHz(SPI2X = 1).

Mit gerade nachgerüstetem Quarz@16MHz auf 1MHz bzw 2MHz, dann aber 
wieder mit schlechten Flanken. Aber die ist die Frequenz überhaupt ein 
limitierendes Element? Wenn es etwas länger dauert, wäre es für mich 
auch nicht schlimm.

von Lothar L. (lole)


Lesenswert?

Wenn ich nicht falsch liege, müsste bei 16MHz Quarz der SPI-Clk bei 
4/8MHz liegen. Der SPI-Clk ist mit Sicherheit nicht kritisch, in Deinem 
Fall könnte es aber sein, dass irgendwas mit dem Takt generell nicht 
passt. Dann wären auch die Delays falsch und das mag das Display nicht. 
Wie oben gesagt, mein Fehler meine 8MHz nicht korrekt zu definieren 
brachten keine Anzeige. Da waren die Pausen zwischen den Initsequenzen 
um den Faktor zwei verlängert. Wenn Dein Oszi speichern kann, kannst Du 
die Pausen auch messen. Ich habe auch mit LA einige Versuche gebraucht, 
um die interessierenden Bereiche zu "fangen". Bei den 4MHz SPI-Clk sieht 
man den ClearScreen schon sehr deutlich. Bei 3V komme ich aber nicht 
viel höher und wegen der Versorgung mit LiPo auch nicht über 3V.

von Simon K. (simon) Benutzerseite


Lesenswert?

Lothar Lehmann wrote:
> Das Problem hatte ich beim ersten Versuch auch. Christians Quellen gehen
> von 16MHz aus, als ich die 8MHz eingesetzt habe ging es auf Anhieb. Ich
> arbeite allerdings mit 3V, also ohne Pegelwandler.

Jeder AVR kann bei 3V Versorgungsspannung nur bis 8MHz Takt…

von Gregor B. (gregor54321)


Lesenswert?

So. Ich hab das SPI-Vorteiler-Register jetzt so beschrieben:
1
SPCR = (_BV(MSTR) | _BV(SPE));  // SCK auf Clk/4
2
SPSR = 1;                       // SPI2X bit stzen
Damit hat SCK tatsächlich Taktung/2. Aber ich glaube nur mit 
Schmitt-Trigger-Eingängen am Display zu gebrauchen.

Sollte das Demoprogramm "simple.c & disp.c" von Christian nicht ohne 
Änderungen funktionieren? Ich hab dann jetzt schon Delays eingefügt, SPI 
umgeschrieben... Stimmt denn die Initialisierungssequenz (siehe 
http://www.superkranz.de/christian/S65_Display/data/LPH_display4_V02.zip) 
von Christians Beispielprogramm (Speziell LPH* Satz)? Denn darauf muss 
ich mich blind verlassen können!

von Lothar L. (lole)


Lesenswert?

@Simon
Sagte ich ja, da 3V nur 8MHz. Ich setze einen Mega88 ein, da sollte noch 
ein bisschen mehr gehen, aber keine 16MHz. Da ich nix zeitkritisches 
mache, nehme ich den internen RC, könnte ich etwas nach oben trimmen, 
ist aber nicht nötig.
@Gregor
Im Assemblerteil sieht das bei mir so aus.
   ldi             r24,(1<<MSTR) | (1<<SPE);
   out             SPCR,r24
   ldi             r24,1                       ; double speed bit
   out             SPSR,r24

Ist also, mit anderem Syntax, das Gleiche wie bei Dir. Wenn die Pin 
Definitionen dann noch stimmen, hmmmm, dann kann es nur noch am Display 
liegen. Wie gesagt, ich habe ein LS020 das funzt mit den Quellen von 
Christian. In dem Thread wurde aber mehrfach von Problemen mit den LPH 
berichtet. Die Zeiten zwischen den Initsequenzen weichen bei meinem 
LA-Scan von Christians ab. Die Quellen habe ich trotzdem 1-1 übernommen.
Hast Du die Möglichkeit das mit einem LS020 zu testen??

von Hagen R. (hagen)


Lesenswert?

>Jeder AVR kann bei 3V Versorgungsspannung nur bis 8MHz Takt…

Falsch, ATMega168 kann zb. 14Mhz, 19Mhz mit 3.75V, fast alle neueren 
AVRs die mit 20Mhz angegeben sind können das. Bei 5V sogar 24Mhz.

Gruß hagen

von Lothar L. (lole)


Lesenswert?

AVRs lassen sich besser übertakten als Intel oder AMD. Ich habs nicht 
getestet, aber laut Elektor um 50%. Ein Mega88 sollte bei 3V schon fast 
12MHz schaffen, +50% runde 18MHz, wäre mal einen Versuch wert, selbst 
wenn der AVR dabei den Geist aufgibt. Wenn der interne RC genutzt wird, 
ist die Grenze vorbestimmt.

von Hagen R. (hagen)


Lesenswert?

ein Mega88 schafft lauf Datenblatt bei 3V exakt 14Mhz und ist dabei 
nochnichtmal übertaktet.
Mega88 = Mege168 = Mega48, nur Flash/SRAM ist unterschiedlich.

Gruß Hagen

von Lothar L. (lole)


Lesenswert?

Ich dachte 12, 14 ist natürlich noch besser. Wird der letzte Akt in 
meinem Projekt sein, mit der RC-Calibration den Takt auszureizen.
Aber wir weichen vom Thema ab.
Wenns flinker sein soll, dann eben einen ARM, oder einen Propeller.

von Gregor B. (gregor54321)


Lesenswert?

@lothar
Ich habe leider kein LS020 zur Hand. Kann das leider nicht testen.
In den Quellen zum "Simplen" Testprogramm fürs LPH steht drin, das RS 
für dieses Display nicht gebraucht wird. Woanders steht wieder, jemand 
hätte "ein braunes und ein grünes" Display parallel geschaltet und beide 
hätten was angezeigt. In den Quellen fürs LPH stehen auch nicht die 
Initialisierungssequenzen so drin, wie sie in dem hier umher 
schwirrenden pdf von Benjamin Metz stehen. Außer in Christians 
LPH-Democode habe ich fürs LPH die Sequenz noch nirgendwo dokumentiert 
gesehen. Lässt sich das LPH (ohne RS?) auch mit dem Code fürs LS020 
betreiben?

Hat irgend jemand ein LPH am laufen?
Danke für eure Hilfe!

Grüße, Gregor

von Lothar L. (lole)


Lesenswert?

Scheint niemand einen Tip zu haben. Kämpf Dich noch mal durch Christians 
Tread, der hat gerade 922 Beiträge. Da wurden die verschiedenen Displays 
abgehandelt. Ich errinnere mich noch daran, das sehr oft die Meinung 
vertreten wurde, dass die LS020 keine Probleme machen, alle anderen 
schon.
Ich wünsch Dir viel Erfolg

von Gregor B. (gregor54321)


Lesenswert?

Ich hatte mich gestern schon bis Februar 2006 durchgelesen, bis dahin 
war der Stand der, dass das LPH* auf Grund des (nur für dieses Display) 
vorhandenen Datenblatts den größten Funktionsumfang bot. Da ich jetzt 
auch dieses Datenblatt auf meinem Rechner habe, werde ich die 
Ansteuerung halt auch nochmal neu erfinden. (Wenn zwischen Feb 2006 und 
Dez 2007 nichts Welt bewegendes mehr steht). Dann verstehe ich nachher 
wenigstens warum alles funktioniert. ;o)

Danke trotzdem an alle Diskussionsteilnehmer!

von toxico (Gast)


Lesenswert?

Hallo, da ich zur Zeit auch dabei bin, ein LPH Display anzusteuern und 
es trotz mehreren Versuchen nicht geklappt hat, würde mich mal 
interessieren, ob sich bei dir mittlerweile was getan hat.
Ich nutze auch den simply.c Code von superkranz.de (Dank an Christian!), 
allerdings compiliert mein gcc den nicht ganz ohne Warnung:

disp.c:231: warning: operation on `j' may be undefined

Es ist ja auch nicht ganz so klar, wie folgender Code interpretiert 
wird:
1
  j=0;
2
  for (i=0; i<6; i++)
3
  {
4
    lcd_comtype(ct1[i]);
5
    lcd_comdat(cd1[j++],cd1[j++]);
6
  }
Aber prinzipiell sollte es ja das gleiche sein wie
1
  j=0;
2
  for (i=0; i<6; i++)
3
  {
4
    lcd_comtype(ct1[i]);
5
    lcd_comdat(cd1[j+1],cd1[j]);
6
    j+=2;
7
  }
Aber auch so will mir das Display nichts anzeigen (und ja ich hab es 
natürlich auch anders herum probiert ;-)) Des Weiteren bin ich ein wenig 
verwirrt was die Kommentare in der Initialisierungsroutine angeht. Da 
steht mehrmals "// starts at xxx ms" allerdings stehen im Code weder 
delays noch irgendetwas anderes was diese Verzögerung bewirken könnte.
Aus lauter Ratlosigkeit habe ich mir einen Timer gebaut (100µs genau) 
und habe die einzelnen Initialisierungsteile timergenau laufen lassen. 
(Mit dem Speicheroszi nachgemessen) -> nix!
Mit den verschiedenen SPI Frequenzen habe ich natürlich auch schon 
rumgespielt. -> nix

Hardware mäßig läuft bei mir ein ATMega32 mit 16MHz Die Pins hab ich 
dementsprechend angepasst.
1
#define LCD_CS     PB4
2
#define LCD_RESET  PB1
3
#define LCD_RS     PB0
4
#define LCD_MOSI   PB5
5
#define LCD_MISO   PB6
6
#define LCD_SCK    PB7
Da sich die Hardware SPI des ATMega32 an anderen Pins als beim 128er 
befindet. Mittlerweile schon fast 100 mal die Verkabelung überprüft, 
aber es funktioniert natürlich nichts.

Also entweder ist mein Display defekt oder die Initialisierungsbefehle 
stimmen nicht.

Von daher mal meine Bitte an Euch. Kann jemand mal eine 
Initialisierungsroutine speziell fürs LPH posten, die auch wirklich 
funktioniert? Ich wäre Euch sehr zu Dank verpflichtet.

mfg
toxico

von Uli (Gast)


Lesenswert?

Hallo Toxico,

hattest du mittlerweile Erfolg?
Ich habe die gleiche konstellation wie du - ich hab sogar die gleiche 
Pinbelegung gewählt ;D

Leider geht bei mir die Anzeige auf dem Display auch nicht. Ich habe 
mithilfe eines Osziloskops alle Leitungen durchgemessen, und eigentlich 
stimmt auch alles - bis auf die Startsequenz, bei der ich nicht weiters 
testen kann.

Ich habe ein relativ neu bezogenes Display (ca 1 Monat alt) mit grüner 
Platine.

Wie gesagt scheint alles sauber anzukommen am Display, jedoch geht nur 
die Hintergrundbeleuchtung.

Also wenn du mittlerweile irgendwelche Erfahrungen gemacht hast, dann 
wäre es nett, wenn du das Kund tun könntest. Mein Verdacht ist, dass die 
Startsequenz nicht stimmt (da es evtl eine neue ist (neue Revision des 
Controllers vlt)...

Grüße Uli

von Christian K. (christiank)


Lesenswert?

Hallo,

die Probleme mit dem LPH scheinen sich zu häufen, könnt ihr das Original 
hex file ausprobieren? (gleiche Beschaltung)

In diesem Thread haben die Orignal-hex files funktioniert, aber nicht 
die neu kompilierten:
Beitrag "Re: Reengineering: Siemens S65 Display"

Ich befürchte hier könnte ein Problem mit einer neueren Compiler Version 
vorliegen.

Diese Änderung ist schoneinmal auf jeden Fall notwendig.
1
  j=0;
2
  for (i=0; i<6; i++)
3
  {
4
    lcd_comtype(ct1[i]);
5
    lcd_comdat(cd1[j+1],cd1[j]);
6
    j+=2;
7
  }
Gibt es noch irgendwelche Warnungen wenn ihr alle diese Stellen geändert 
habt?

Ich habe bisher noch keine neuere gcc Version installiert, ich bin in 
solchen Dingen immer sehr träge... (never change a running system....)

von Christian K. (christiank)


Lesenswert?

Ach ja, in dem oben genannten Thread habe ich auch festgestellt, das die 
CPU Frequenz definition:

#define F_CPU 16000000

in display.h fehlt....

von Daniel R. (sliderbor)


Lesenswert?

Da hier gerade so schön diskutiert wird:

Muss ich beim L2F50 irgendetwas beachten im Gegensatz zu den LS20?

Bin blutiger Anfänger mit Displays und hab mir ein L2F50 bestellt, 
sollte morgen oder Montag kommen...

Danke schonmal!

Daniel

von Christian K. (christiank)


Lesenswert?

So,

ich habe den Quelltext für das LPH überarbeitet. Lässt sich jetzt mit 
dem gcc 4.2.1 ohne Warnungen kompilieren und funktioniert bei mir mit 
atmega128 bei 16MHz ohne Probleme.

!Ich habe die PWM Backlight Ansteuerung eingebaut damit ich was sehen 
konnte!

Ich hoffe das löst eure Probleme.

Im Anhang der Compiler-log nach make clean; make.

Grüße
  Christian

von Christian K. (christiank)


Angehängte Dateien:

Lesenswert?

Hier nochmal der Anhang, ist glaube ich bei der Vorschau-Funktion 
verschwunden...

von Uli (Gast)


Lesenswert?

Hallo Christian,

schön, dass du dich um uns kümmerst :)

Ich hab mein Display leider zuhause liegen lassen, und kann die 
Änderungen am Code erst wieder am Freitag testen.
Warum ich jedoch jetzt schon antworte ist, weil ich schonmal nach einer 
neuen Version auf deiner Homepage geschaut hab, aber (zumindest ich 
hier, gibt evtl mittlerweile einen Proxy der cached) es ist immernoch 
nur eine V2 verlinkt, die 2007 erstellt worden ist.

ich bekomm bei meiner abgeänderten version noch übrigens folgenge 
Warnung:
disp.c:187: warning: no previous prototype for 'lcd_write16'

>!Ich habe die PWM Backlight Ansteuerung eingebaut damit ich was sehen konnte!
ist dies zwingend nötig? da ich beim testen das Testboard über meine ISP 
mit Strom Versorge, und mit erstnoch einen 12V Kreis dazubauen muss.
Ich habe ein M65 Handy, und kann dort auch Inhalte schwach lesen, wenn 
es -vermeindlich- die Displaybeleuchtung ausschaltet. Es könnte aber 
auch sein, dass dies nur eine Stromsparschaltung ist.

Grüße, Uli

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
Noch kein Account? Hier anmelden.