DOGXL240-7 Kontrastspannung

[Niklas G. (erlkoenig)]

Hallo Forum,

ich versuche ein Display DOGXL240N-7 in Betrieb zu nehmen ( 
http://www.lcd-module.de/fileadmin/pdf/grafik/dogxl240-7%20preliminary.pdf 
). Der verbaute LCD-Controller ist ein UC1611s ( 
http://www.lcd-module.de/fileadmin/eng/pdf/zubehoer/uc1611s_v1_0.pdf ).
Zur Ansteuerung verwende ich I²C und einen STM32F373CC. Die Schaltung 
ist auf einem PCB, habe ich nicht selber gebaut, entspricht aber der 
Standard-Beschaltung laut Datenblatt.

Ich habe das Problem, dass das Display die Kontrastspannung nicht 
richtig erzeugt, und daher nichts anzeigt. Im Datenblatt von EA steht 
natürlich nicht, welche Spannung man einstellen soll. Daher habe ich 
testweise mal die Ladungspumpe deaktiviert, und mit einem Netzteil eine 
externe Spannung auf den Vlcd Pin gegeben. Bei 15V ging das Display an. 
Jetzt möchte ich die Kontrastspannung mit der internen Ladungspumpe 
erzeugen.

Dazu schicke ich per I²C folgende Befehle:

0x28 (Set Panel Loading, Command 6)
0xEB (Set LCD Bias Ratio, Command 27)
0x81 75    (Set Potentiometer, Command 11)
0xA9  (Set Display Enable, Command 20)
0xA5   (Set All Pixels on, Command 18)

Die werden auch alle korrekt quittiert (ACK-Bit) und sollten 
funktionieren (haben sie ja mit Netzteil auch).
Mit diesen Parametern sollte (laut Formel im Datenblatt) eine 
Kontrastspannung von 15V erzeugt werden. Mit dem Oszilloskop am Vlcd Pin 
kann man erkennen, dass nach dem Senden der I²C-Befehle tatsächlich die 
Spannung fast linear von 0V auf die gewünschten 15V ansteigt, und dann 
sofort wieder auf 0V zusammenbricht und dort bleibt. Somit zeigt das 
Display natürlich nichts an.

Das skurrile ist: Ich habe exakt die gleiche Schaltung mal auf einem 
Breadboard zusammengebaut, und mit dem STM32 über lange Strippen 
verbunden, und dort hat sie funktioniert! Auf einem zweiten Exemplar der 
Schaltung(PCB) (und einem zweiten Display) funktioniert sie aber auch 
nicht.

Hat irgendjemand eine Idee was hier falsch ist, was die Ladungspumpe 
dazu bewegen könnte einfach abzuschalten wenn sie die Zielspannung 
erreicht?!

[Niklas G. (erlkoenig)]

Hat niemand eine Idee? Hier im Anhang noch ein Oszillogramm von der 
Kontrastspannung. Es ist zu sehen wie sie ansteigt und dann 
zusammenbricht.

[J. D. (jch)]

Hallo,
Ich habe das gleiche Problem an meinem DOGM240-6. Wie hast Du das 
Problem gelöst? Ich versuche schon seit ewigkeiten, die Kontrastspannung 
zum laufen zu kriegen.

[Niklas G. (erlkoenig)]

Plötzlich hat die Kontrastspannung einfach funktioniert. Ich habe keine 
Ahnung warum. Die einzige Vermutung ist dass es bei geringer 
Lufttemperatur nicht funktioniert...

Ich hatte danach aber noch eine Menge weitere Probleme, da der I²C Bus 
scheinbar extrem störanfällig ist. Das LCD-Modul selbst stört den Bus so 
stark dass ständig Fehlübertragungen auftreten, die vom LCD-Controller 
dann als falsche Kommandos interpretiert werden, sodass der ständig 
irgendeinen Unsinn macht. Als "Lösung" verwende ich den Reset-Pin, um 
den Controller regelmäßíg zu resetten (wobei das Panel auch schön 
flackert), um ihn aus irgendwelchen ungültigen Zuständen herauszuholen. 
Außerdem habe ich an allen I²C Transfers Timeouts implementiert, und 
initialisiere das LCD bei Überschreitung komplett neu. Insgesamt sehr 
aufwändig dieses LCD mit I²C halbwegs "stabil" ans Laufen zu bekommen.

[J. D. (jch)]

Hallo,
Ich habe mal die Vlcd gemessen. Die Springt von 0 auf 14,2V innerhalb 
von ein paar ms. Dann liegt die Spannung linear ca 3 Sekunden lang an 
und springt innerhalb von ein paar ms wieder auf 0V.
Wenn man die DIV/s auf 500ms stellt, sieht es wie ein sauberer 
Rechteckimpuls aus.

Nach diesen 3 Sekunden verschwindet auch mein Text.

Deine Spannung steigt ja sehr Trapezförmig an. Dies ist bei mir nicht 
so.

Die Temperatur ist mMn nebensächlich, da ich es auch an heissen Tagen in 
der Sonne ausprobiert habe.

Mein Text erscheint zuverlässig (wenn die Kontrastspannung passt) obwohl 
das Signal aif dem Oszi ziemlich grauenhaft aussieht. Mit 
Fehlübertragungen hatte ich noch kein Problem.

[Michael U. (amiga)]

Hallo,

zum Display kann ich nichts sagen, aber:

I2C ist eigentlich sehr stabil, wird schließlich in fast allen 
Fernsehern, Radios usw. genutzt.

keine zu langen leitungen, passende PullUp-Widerstände (2,2k bei 5V 
sollte immer passen), evtl. in SDA und SCL einen 100 Ohm Widerstand beim 
Slave in die Leitungen gegen Reflektionen.

Gruß aus Berlin
Michael

[J. D. (jch)]

Da ich den oberen Beitrag nicht Editieren kann, kommt jetzt das Bild vom 
Oszi über Pin 29 (Vlcd)

[J. D. (jch)]

Ich habe mal meine Schaltung gefönt und die Anzeigetzeit ging von 
2-3Sekunden auf ca 0,5 Sekunden runter.
In Kühlschrank zeigt es ca 7 Sekunden etwas an und in der Gefriertruhe 
sind es ca 20 Sekunden.

Niklas G. schrieb:
> Die einzige Vermutung ist dass es bei geringer
> Lufttemperatur nicht funktioniert...

genau umgekehrtes Verhalten?!?

[Crazy Harry (crazy_h)]

Ich hab das DOGXL240 am laufen, jedoch via SPI. Pullups mit 2.2k halte 
ich bei einem im Datenblatt des LCDs angegebenen Innenwiderstand der 
I2C-Schnittstelle von 600-1000 Ohm für ein Gerücht. Ich habe schon beim 
diesbezüglich gleichen DOGXL160 I2C gleich an den Nagel gehängt, da die 
erreichbare Geschwindigkeit unter aller S.. war. Beim 240er benötigt ein 
kompletter Display-Refresh via SPI ca. 18ms.

[Crazy Harry (crazy_h)]

Sorry mit dem Tablet kann ich nicht editieren .... geschweige denn 
copy/paste.
Init erfolgt nach Datenblatt:

    WriteLCD($F1,false);                          // Set COM to 127
    WriteLCD($7F,false);
    WriteLCD($F2,false);                          // Set display start line to 0
    WriteLCD($00,false);
    WriteLCD($F3,false);                          // Set display end line to 127
    WriteLCD($7F,false);
    WriteLCD($81,false);                          // Set contrast
    WriteLCD($8F,false);
    WriteLCD($C0,false);                          // Set bottom view
    WriteLCD($02,false);
    WriteLCD($A3,false);                          // 9.4 kilo-lines/second
    WriteLCD($25,false);                          // Set temp.compensation -0.10%/°C
    WriteLCD($A9,false);                          // Enable display in black/white mode
    WriteLCD($D1,false);                          //

[J. D. (jch)]

Ich nutztze die Library von U8glib. Ich habe jetzt auf SPI 4 Draht 
umgebaut. Der Fehler ist exakt gleich geblieben.

War Deine Kontrastspannung auf einen Hardware- oder Softwarefehler 
zurückzuführen?

Hat jemand von euch mal U8glib ausprobiert?

[Niklas G. (erlkoenig)]

J. D. schrieb:
> War Deine Kontrastspannung auf einen Hardware- oder Softwarefehler
> zurückzuführen?
Ich weiß es nicht, es hat am zweiten Tag plötzlich funktioniert :/ 
Einzige Vermutung wie gesagt Temperaturabhängigkeit, beim ersten Versuch 
wars draußen in einer kalten Garage, beim zweiten im gemütlich warmen 
Labor...

Hast du die Pins für die Ladungspumpe mal ans Oszilloskop gehalten? 
Vielleicht sieht man da was. Was passiert, wenn du nach Einstellen der 
Konstrastspannung gar nichts mehr sendest? Bricht sie dann auch ein?

Michael U. schrieb:
> I2C ist eigentlich sehr stabil, wird schließlich in fast allen
> Fernsehern, Radios usw. genutzt.
Bei diesem LCD koppeln die Impulse der Ladungspumpe stark auf die 
I²C-Leitungen ein (kann man auf dem Oszilloskop sehen), und das LCD hat 
100Ω Serienwiderstände in den Datenleitungen. Somit gibt es keinen 
richtigen Low-Pegel wenn das LCD "0" sendet, sondern nur eine Spannung 
die sich durch den Spannungsteiler von 100Ω und den Pullups ergibt. 
Außerdem sind auf dem PCB (nicht von mir gemacht...) SDA und SCL ca. 7cm 
lang und direkt nebeineinander und übersprechen gegenseitig. Da I²C 
keinerlei Fehlererkennung/Korrektur hat, ist das dann alles andere als 
stabil :-/ Man kann auf dem Oszilloskop sehen, wie das LCD oft 7 
reinkommende Bits als 8 Bits erkennt und dann beim 8. Bit schon "ACK" 
sendet, was dem I²C-Master vom Mikrocontroller gar nicht gefällt. 
Umgekehrt werden manchmal auch 9 Bits als 8 gezählt.
Ist mir ein Rätsel wie Leute sowas als Hausbus oder gar Fahrzeugbus ans 
Laufen kriegen.

J. D. schrieb:
> Hat jemand von euch mal U8glib ausprobiert?
Nö

Ich verwende momentan folgende Sequenz per I²C zum Initialisieren. Diese 
wird bei jedem Timeout/I²C-Busfehler/alle 200 Frames neu durchlaufen, 
denn das LCD erkennt regelmäßig fälschlicherweise Datenbytes als 
Befehle, die irgendwelche Parameter umstellen. Daher setze ich alle 
Parameter auf "richtig", auch wenn einige Werte die Standardwerte sind:

static uint8_t initSeq [] = {
  0xF1, 0x7F,  // Last COM Electrode
  0xF2, 0,  // Display Start Line
  0xF3, 0x7F,  // Display End Line

  0x81, 0x8F,  // Contrast
  0xC0, 0x02,  // View

  0xA3,    // Line Rate
  0x25,    // Temp Comp
  0xA9,    // Enable Display
  0xD1,    // Black & White Mode

  0x2B,    // Panel Loading
  0x2F,    // Internal Charge Pump active

  0x40,    // Scrolling
  0x50,    // Scrolling
  0x82, 0x13, 1, // Isolation Clock Front
  0x82, 0x14, 0, // Isolation Clock Back
  0x84,    // Partial Display Disable
  0x89,    // RAM Address Control
  0x90,    // Fixed lines
  0xA4,    // All Pixels Off
  0xA6,    // Don't invert image

  0xC8, 0,  // N-Line Inversion
  0xEA,    // Bias Ratio

  0xF4, 0,  // WPC0
  0xF5, 0,  // WPP0
  0xF6, 239,   // WPC1
  0xF7, 15,   // WPP1

  0xF8,    // Window Mode
};

Dieser Datenblock kann in einem Rutsch an die I²C Adresse für Befehle 
(je nach Adresspin-Belegung) gesendet werden (mach ich per DMA).
Keine Ahnung ob die alle so optimal sind, aber es funktioniert 
halbwegs...

[J. D. (jch)]

Ja ich habe mal die einzelnen Kondensatoren gemessen:

Ich habe mein Programm so abgespeckt, dass nur noch der Constructor und 
die Einbindung der Library dort steht.

Jetzt wollte ich die Zip Datei vom Constructor hochladen. Scheint aber 
nicht zu gehen.