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?
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, 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
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
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...
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.