mikrocontroller.net

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


Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht 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/Dis... 
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?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gregor B. (gregor54321)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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…

Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. Ich hab das SPI-Vorteiler-Register jetzt so beschrieben:
SPCR = (_BV(MSTR) | _BV(SPE));  // SCK auf Clk/4
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/dat...) 
von Christians Beispielprogramm (Speziell LPH* Satz)? Denn darauf muss 
ich mich blind verlassen können!

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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??

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gregor B. (gregor54321)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: toxico (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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:
  j=0;
  for (i=0; i<6; i++)
  {
    lcd_comtype(ct1[i]);
    lcd_comdat(cd1[j++],cd1[j++]);
  }
Aber prinzipiell sollte es ja das gleiche sein wie
  j=0;
  for (i=0; i<6; i++)
  {
    lcd_comtype(ct1[i]);
    lcd_comdat(cd1[j+1],cd1[j]);
    j+=2;
  }
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.
#define LCD_CS     PB4
#define LCD_RESET  PB1
#define LCD_RS     PB0
#define LCD_MOSI   PB5
#define LCD_MISO   PB6
#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

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht 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.
  j=0;
  for (i=0; i<6; i++)
  {
    lcd_comtype(ct1[i]);
    lcd_comdat(cd1[j+1],cd1[j]);
    j+=2;
  }
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....)

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht 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....

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Christian K. (christiank)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Christian K. (christiank)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal der Anhang, ist glaube ich bei der Vorschau-Funktion 
verschwunden...

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.