S65 Display Unterschiede zw LPH88* und LP-88* ?

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

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

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.

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

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?

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.

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.

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.

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…

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!

@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??

>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

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.

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

Gruß Hagen

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.

@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

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

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!

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....)

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

#define F_CPU 16000000

in display.h fehlt....

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

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

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