C Hilfe: Nicht-flüchtige "parasitäre" Zeichen auf meinem OLED-Display!?

[analog]

Hallo Leute,

sorry, ich war lange nicht mehr im Forum und starte mein "Comeback" gleich mit einem Hilferuf:

Ich "spiele" derzeit mit den bei Reichelt erhältlichen OLED-Displays (2 x 16) von Electronic Assembly, deren Controller zu einem gängigen LCD-Controller kompatibel sein sollen. Macht nix: hab auch mit LCDs bisher keine Erfahrungen gemacht.
Da dieses spezielle Thema Neuland für mich ist, war ich froh, dass alles zunächst trotz "quick and dirty" quasi auf Anhieb geklappt hat. Ansteuerung im 8-Bit-Modus, Laufschriften programmiert (alles in C/C++) etc. SUPER!

JETZT KOMMT'S: Nachdem ich mich dann an die Programmierung eigener Zeichen (5x8) gewagt hatte, war die Welt zunächst auch noch in Ordnung: die Zeichen wurden so dargestellt, wie ich das haben wollte. Dann hatte ich aber einen Fehler in meinem umgebenden Programm, der sich als ziemliches Geflimmer auf dem Display äußerte. Zurück geblieben sind zwei vertikale Linien, die auch beim Ausschalten des Controllers/Displays nicht verschwinden, letztlich auch vom Programm unabhängig irgendwo im Display gespeichert(?) bleiben. Eine Beobachtung dazu: die Zeichen waren zunächst heller, als der Normaltext, später mal kurz verschwunden, und jetzt sind sie ganz schwach wieder da.

Hab ich das Display abgeschossen, durch Zufall irgendwas irgendwohin programmiert, ist das reversibel, oder muss ich einfach nur zum Augenarzt???

Danke für Eure Ratschläge/Hilfe.

LG Andreas

 

[Dirk]

Hallo Andreas,

möglicherweise ist das OLED beschädigt. Je nach Helligkeit der Pixel und Leuchtdauer zu benachbarten Pixeln (bei Farb-OLED auch farbabhängig), kann man nach einiger Zeit Unterschiede in der Helligkeit erkennen. Besonders dann, wenn man eine Fläche füllt, dort tritt der Effekt oft unangenehm auf. Bei den neueren OLED im Smartphone-Bereich, ist das nicht mehr so kritisch. Ich vermute, dass durch einen Fehler das Multiplexen nicht richtig funktioniert hat oder dass Zeilen/Spalten-Treiber zu viel Stom geliefert haben, so dass eine Ziele/Spalte defekt ist. Oder ein Zeichen hat sich "eingebrannt", so dass dieser "Schatteneffekt" oder die "Geisterschrift" entsteht.


Dirk

 

[TommyB]

Ich weiß jetzt nicht ob ich dich richtig verstanden habe. Also das Display hat keinen Speicher (wie Flash, EEPROM), nur den flüchtigen Speicher wo du rein schreibst.

Ich habe das Display (in weiß) hier selber im Einsatz.
Das was du beschreibst mit dem heller / dunkler. Du hast in der Init Sequenz ja ein Power On Befehl. Dieser macht nichts anderes als den internen DC-DC Konverter anzuschalten. Ist der aus laufen die LEDs nur mit der Betriebsspannung (dunkel aber sichtbar) statt mit der eigentlich benötigten (heller).

Das mit den Linien kann auch an fehlerhafter Initialisierung liegen. Diese OLED Module haben nämlich auch einen Grafik Modus (bin ich per Zufall mal rein geraten als ich den Zeichensatz auswählen wollte. Im 4-Bit Modus stehen nur 2 zur Verfügung, nicht alle 4). Das könnte die komischen Linien erklären.

Ich würde da mal suchen
Sofern das Display (mit nichts dran angeschlossen außer Betriebsspannung) schwarz bleibt ok, wenn nicht hat es wohl nen Schlag weg.

Mal mein Init Code (4-Bit, allerdings in Assembler)

LCD_Init:

	; Initialize hardware (I/O pins, see HW_Display)
	lcd_HWInit
	
	; Initialize display
	LDI		ARGS1	, 0b00110011	; Ensure 8bit mode...
	RCALL	lcd_SendCmd
	LDI		ARGS1	, 0b00110010	; ... and switch to 4bit mode
	RCALL	lcd_SendCmd
	RCALL	lcd_Wait5us				; wait 5 µS
;	LDI		ARGS1	, 0b00101000	; 4bit mode, en_jp charset
	LDI		ARGS1	, 0b00101010	; 4bit mode, en_ru charset
	; Note: Other charset(s) are NOT available in 4 bit mode... <_<
	RCALL	lcd_SendCmd
	RCALL	lcd_Wait5us				; wait 5 µS
	LDI		ARGS1	, 0b00001000	; Display off
	RCALL	lcd_SendCmd
	LDI		ARGS1	, 0b00000110	; Entry mode (auto increment, no shift)
	RCALL	lcd_SendCmd
;	LDI		ARGS1	, 0b00011111	; Power on (grapic mode - unsupported here)
;	LDI		ARGS1	, 0b00010111	; Power on (text mode, high brightness)
	LDI		ARGS1	, 0b00010011	; Power off (text mode, low brightness)
	RCALL	lcd_SendCmd
	LDI		ARGS1	, 0b00000001	; Clear display
	RCALL	lcd_SendCmd
	RCALL	lcd_Wait6ms2			; wait 6,2ms
	LDI		ARGS1	, 0b00000010	; Return home
	RCALL	lcd_SendCmd
	LDI		ARGS1	, 0b00001100	; Display on
	RCALL	lcd_SendCmd

RET

 

[analog]

Danke erstmal und noch ne Frage ....

Danke, Dirk und TommyB,

da hab ich erstmal Stoff zum Nachdenken und Ausprobieren. Was mir mittlerweile aufgefallen ist, nachdem ich das Display mit komplett ausgefüllten 5x8-Blöcken beschrieben habe: Die "Geisterpixel" liegen nicht im normalen Zeichenrahmen sondern quasi in den Fugen dazwischen. Das würde die These erhärten, dass es da sowas wie einen Grafik-Modus gibt?! Muss mich wohl wirklich nochmal intensiver mit der Theorie dieser Displays beschäftigen. Wir wollen in einem Projekt gleich mehrere dieser nicht gerade billigen Teile verwenden und können uns net leisten, sie eins nach dem anderen abzurauchen :-(

Zur richtigen Initialisierung mal noch eine Frage; kann sein, dass da mein wesentlicher Fehler liegt: Mit welchem Befehl kriegt man denn in C eine eintaktige Verzögerung hin? Brauche die Verzögerungen ja für das richtige Timing auf den Steuerleitungen. In Assembler heißt das - glaube ich - NOP für No Operation oder so?! In C habe ich als leeren Befehl das Semikolon genommen; kann aber sein, dass das Quatsch ist und mir keine Verzögerung liefert, weil der Compiler es evtl wegoptimiert?

Danke und Grüße aus dem Odenwald

Andreas

 

[TommyB]

Also bei dem Display was ich habe (Vorsicht, es gibt 2 Versionen!) da sind die Pixel zwischen den Buchstaben garnicht verdrahtet, können also niemals leuchten, weder im Text- noch im Grafikmodus. Es soll aber auch das selbe Modul geben wo die angeschlossen sind. Vielleicht sowas wie Revision 1 und 2. Schade eigentlich, weil auf dem Display selbst sind die Pixel immer da.

Den Grafikmodus ansich hatte ich nicht vernünftig zum laufen bekommen, von wirren Pixeln abgesehen (ich habs aber auch nicht sonderlich lange probiert). Soll wohl so sein dass man einfach den Speicher beschreibt wie im Char Mode, nur dass halt jedes gesetzte Bit 1 Pixel zum leuchten bringt.

Aber wenn der Rest soweit geht wundert mich die Reihe zwischen den Zeilen doch schon. Hat das Display vielleicht mal einen (mechanischen) Schlag bekommen? Oder irgendwas (wie Metallstaub, ein abgekniffener Drakt, ...) drauf?
Mach sonst einfach mal eine "dumme" Testanwendung, so ala Hallo Welt, um Fehler aus anderen Bereichen des Codes auszuschließen.

Das was Dirk sagte mit dem "Einbrennen" das stimmt. Das haben LEDs aber generell, nicht nur OLEDs. Ich hab in meinem Laptop auch schon mal die LEDs (Power, HDD, ...) ausgetauscht deswegen. Mein Display läuft aber noch wie am ersten Tag
Ich würde aber auch so etwas wie einen Bildschirmschoner einbauen (bei Inaktivität nach x Minuten abschalten, bei 5V ist es immer noch lesbar (geschätzte 40% Helligkeit), oder halt komplett aus schalten). Aber das kommt halt drauf an wofür es eingesetzt wird.

Mit C kann ich dir aber leider nicht helfen. Dafür gibt es hier viele Andere
In purer Verzweiflung würde ich vermutlich irgendeine Dummy-Variable incrementieren. Ist dämlich, aber tuts erstmal ^^
Das Display ist nicht soo Zeitkritisch. Langsamer geht immer.

 

[analog]

Latest News ....

Bin derzeit zeitlich leider bisschen knapp; trotzdem nochmal DANKE und der Vollständigkeit halber: Das Display ist das EA W162-XBLG; wenn Du es in weiß hast, dann isses wohl in Deinem Fall das XBLW? Ganz schön teuer mit 56,- (Reichelt); meines gibt es derzeit gar nicht bei Reichelt oder überhaupt net mehr?

Ich hab die Sache mal nur mit Betriebsspannung probiert: dann sieht man nix! Hoffe, das ist ein gutes Omen.

Mit dem ASSEMBLER-Code muss ich mich nochmal beschäftigen, hab das 10 Jahre net mehr gemacht. Und damals war es auch so, dass ich drei Tage später net mehr wirklich wusste, was mein Programm eigentlich macht, grins ...

Sehe ich das richtig in Deinem Code? Du fragst dieses Busy-Flag gar net ab, sondern wartest einfach lange genug, bis Du den nächsten Befehl/Zeichen schickst? Ich schalte immer um und realisiere eine waitWhileBusy()-Funktion wie in der Anleitung von Electronic Assembly vorgeschlagen. Vielleicht liegt da ein Fehler. Muss dabei ja den Datenport von Output auf Input schalten ... da ist Dein Dings sicher zweckmäßiger, wenn ich das überhaupt richtig verstanden habe.

Viele Grüße aus dem Odenwald

Andreas

 

[TommyB]

Richtig
Wobei ich glaub ich musste "nur" so um die 40€ löhnen. Ist aber schon lange her.
Meins ist das "EA W162-X3LW" (Kostet bei Reichelt grade 31,15€)

Und ja, ich frag das Busy Flag garnicht ab. Kann man natürlich tun, wäre vermutlich sogar schneller, aber ich warte einfach die Zeiten ab die im Datenblatt stehen
Ich hab die R/W Leitung auch garnicht verdrahtet. Ich les davon eh nie (außerdem hatte ich kein Pin mehr frei ^^)

Mein Code musst du nicht so ernst sehen
Ich hatte dir den nur gepostet damit du siehst wie ich mein Display initialisiere. Und ob es nun Assembler, C oder Bascom ist, die Kommentare und die 0b00000000 Konstanten sollte ja jeder lesen können
Ist ja auch nicht der komplette Code, nur die Initialisierung

 

[maik]

Hallo,
vielleicht wären auch die Displays von Display Elektronik eine Möglichkeit.
... sind etwas günstiger ;-)

DEP16216-Y
DEP20231-Y

Grüße Maik

 

[dino03]

Hallo,
vielleicht wären auch die Displays von Display Elektronik eine Möglichkeit.
... sind etwas günstiger ;-)

DEP16216-Y
DEP20231-Y

Grüße Maik

DEP20231-Y - OLED 20x2 gelb/schwarz
• kontrastreiche OLED-Anzeige gelb
• Controller Driver US2066
• 1/16 Duty Cycle
• Anschluss direkt an 4- oder 8-Bit-Datenbus, I²C oder SPI
• Versorgungsspannung, typ. +3,3V
• Betriebstemperaturbereich -40...+70°C
... hört sich für den RasPI sehr interessant an

Gruß
Dino