Forum: Mikrocontroller und Digitale Elektronik Kontrast bei Display extrem mininmal


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mein nächstes Projekt ist eigentlich, LCD-Displays zu benutzen und 
dementsprechend (anfangs mit Arduino) zu programmieren.

Offenbar muss ich auch alles richtig verstanden, verkabelt und 
programmiert haben. Ein unbeleuchtets Billigst-Display (RCM2037R, 2x16 
Zeichen) macht brav was ich will, auch der Kontrast ist normal 
einzustellen (über 10K Poti an VEE bzw. VO), bis in den Bereich hinein, 
wo "alles" etwas dunkel wird.

Eigentlich will ich aber andere, beleuchtete Displays nutzen und hatte 
mich dazu mal mit mehreren Exemplaren TC1602A-08R (2x16 Zeichen) 
eingedeckt. Wenn ich diese (in den gleichen Versuchsaufbau!) einbaue, 
passiert Folgendes:

Auch hier erscheint der Text durchaus richtigt, aber so blass, dass man 
ihn auch bei "dunkelster Poti-Einstellung" fast nicht lesen, beim einem 
der baugleichen Exemplare nur noch erraten kann. Aber immerhin noch 
erkennbar/erratbar, dass prinzipiell die richtigen Zeichen angezeigt 
werden.

Aber dann wirds rätselhaft: Irgendwann (gewisse Zeit? Wackelkontakt auf 
dem Board? Aber welcher? Der andere DisplayTyp läuft ja korrekt! Ursache 
noch nicht herausgefunden!) zeigt das Display nur noch komische 
Sonderzeichen an, manchmal auch nur schwarze Cluster. Diese aber in 
"allertiefstem Schwarz", also mit vollem Kontrast!

Ein einzelner Defekt kann es auch nicht sein, habe mehrere der 
"TC1602A-08R" durchprobiert. Die "Verkabelung" ist, abgesehen von 
zusätzlichen K + A für die Beleuchtung auch exakt gleich wie die beim 
RCM2037R.

Kann sich da jemand einen Reim drauf machen? Warum ist der Kontrast 
anfangs so schwach? Und bei dem unerwünschten Zeichenwirrwarr dann 
"normal"?

Danke!
marc

von Sascha W. (sascha-w)


Bewertung
2 lesenswert
nicht lesenswert
Hallo,

kann es vielleich sein das dein Programm die Daten - aus welchen Gründen 
auch immer - fortlaufen ausgibt? Irgendwan hängts dann und der 
Displayinhalt wird statisch mit normalem Kontrast angezeigt.

Sascha

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort. Tja, könnte sein. Nur - wie findet man das 
heraus?
Und warum macht das einfache Display alles richtig?

Ich habe einst wirklich "bei Null" angefangen, irgendwann ist C 
sicherlich das Ziel. Mittelfristig will ich, trotz aller 
Einschränkungen, in jedem Fall bei Arduino bleiben und den Frust über 
"Anfänger-Fallstricke" in C somit umgehen!!

Allerdings gibt es dort kaum Einstellungsmöglichkeiten. Eine Bibliothek 
für LCD-Display Nutzung einbinden, die verwendeten Pins angeben, das 
war´s.

Somit wäre man dennoch wieder bei der Frage, warum beim anderen Display 
alles klappt?
Und: Vorhin hatte ich hier im Forum kein verwandtes Thema gefunden. Eben 
beim googlen aber "außenherum" doch:
Beitrag "ATmega32 + LCD TC1602-08"
Hier wurde offenbar C verwendet und das Problem dürfte ziemlich genau 
das selbe sein.

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
T. P. schrieb:
> 10K Poti

Probier mal 20K - 50K (lt. Datenblatt)

Setz doch das Timing mal deutlich höher (z.B. 2-fach) und schau was 
passiert.

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
kann sein das die Kontrastspannung nicht passt, manche Displays brauchen 
weniger als GND, ich habe einen PWM Port mit Dioden und Kondensator am 
unteren Ende vom Poti statt GND eingespiesen.

Es kann aber auch an deiner Schreibrate liegen, mehr als 4x / Sekunde 
hat keinen Sinn kann eh keiner lesen, ich schreibe in ein Schattenram 
ein Array of char aus Zeilen und Spalten und kopiere alle 250ms den 
Schattenram zum Display, flimmert nichts und ist immer der aktuell 
gültige Text lesbar, sollten mehr Änderungen nötig sein ist LCD nicht 
die richtige Wahl.

PS:
T. P. schrieb:
> LCD-Displays

ist stottern

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> PS:
> T. P. schrieb:
>> LCD-Displays
>
> ist stottern

 LCDevices-Displays ?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> LCDevices-Displays

freie Wortschöpfung?

Ich weiss viele stehen auf doppel D aber bei LCD tut dat nicht Not.

von holger (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
>> LCD-Displays
>
> ist stottern

Nur Piesepampel, Haarspalter und Beamtenseelen ziehen sich an sowas 
hoch.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
holger schrieb:
> Nur Piesepampel

ach nö, sollte kein "hochziehen" sein nur derlei Zeugs nicht immer 
unkommentiert lassen, ich weiss lohnt nicht andere zu berichtigen, dann 
verfällt eben Sprache und Kommunikation immer weiter, ist ja auch egal 
ob man sich versteht.

Ich habe mir 2 Jahre anhören dürfen "nach dem Komperativ steht immer 
als" durch Wiederholung lernt man, vielleicht auch andere, aber richtig 
wäre schön.

von T. P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
- Poti: Die Spur kann nicht leider nicht weiterführen. Die Angaben über 
die zu verwendende K-Ohm Zahl schwankt zwar. Nur ändert ein größeres 
Poti alleine den "Spreizbereich" und die Frage, wieviel Strom an 
selbigem "verbrannt" wird. Da es um zu schachen und nicht um zu starken 
Kontrast geht, ist der eingestellte Wert eh immer nahezu = VSS/GND, die 
"Potigröße" (solange nicht "kurzschlussnah" klein) daher komplett 
unerheblich. Außerdem bleibt das Phänomen, dass das Zeichenwirrwarr in 
bestem Kontrast wiedergegeben wird. Und eine "noch negativere" Spannung 
als OV braucht dieses Display laut Datenblatt eindeutig nicht!

- Schreibrate etc: ja, sowas vermute ich ja auch. Habe nochmals bei 
Pollin nachgeschaut. Beim einfachen, unbeleuchteten, mit dem alles 
klappt (s.o.) ist dort explizit u.a. "für Arduino" genannt. Bei dem 
Problem-Typ nicht. Allerdings, wie gesagt, wer anderes scheint das 
Problem mit C auch zu haben. Und vor allem: Wo stellt man in/bei Arduino 
da was ein???

(auf Leute, die hier singuläre Tippfehler bemängeln, reagiere ich nicht 
großartig. In jedem Fall 100% out of topic und daher eigentlich 
selbstredend ebenso 100% indiskutabel. Einen Erkenntniszuwachs, wie 
extrem peinlich das Rummäkeln daher ausschließlich für den 
Möchtegernkritiker selbst ist oder ein Unterlassen kann man darüber 
hinaus leider hier mit keinerlei Worten herbeizaubern.)

von Hilde (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mal welche von Pollin, die nur mit negativer Kontrastspannung 
funktioniert haben

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Betreibst du deinen Arduino per USB? Bricht evtl. die 
Versorgungsspannung ein wenn das Beleuchtete Display aktiv ist?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
T. P. schrieb:
> (auf Leute, die hier singuläre Tippfehler bemängeln,

was meinst du denn?

Es gibt Tippfehler und Wissenslücken, das erstere ist verzeihlich, dem 
zweiten kann ja abgeholfen werden, nur muss es auch einer annehmen.
Wer sich dem verweigert ist entweder arrogant oder beratungsresitent.

von Sascha W. (sascha-w)


Bewertung
2 lesenswert
nicht lesenswert
T. P. schrieb:
> - Schreibrate etc: ja, sowas vermute ich ja auch. Habe nochmals bei
> Pollin nachgeschaut. Beim einfachen, unbeleuchteten, mit dem alles
> klappt (s.o.) ist dort explizit u.a. "für Arduino" genannt. Bei dem
> Problem-Typ nicht. Allerdings, wie gesagt, wer anderes scheint das
> Problem mit C auch zu haben. Und vor allem: Wo stellt man in/bei Arduino
> da was ein???
Da gibts nichts einzustellen, eine zu hohe Schreibrate entsteht einfach 
wenn du in deinem Programm Werte/Texte in einer Loop ohne Pause 
ausgibst, vielleicht noch mit dem vorherigen völligen löschen des 
Displays. Die Displays können darauf schon unterschiedlich reagieren. 
Oder du gibts einen unterminierten String aus wobei der Inhalt des 
Display mehrfach überschrieben wird.
Wenn dann irgendwan Wirrwar mit normalem Kontrast angezeigt wird deutet 
das darauf hin das dein Programm irgendwie hängengeblieben ist oder 
zumindest nichts mehr aufs Display ausgibt. Das sollte natürlich bei 
unverändertem Programm mit jedem Display passieren.

Vielleicht willst du uns das Programm mal zeigen?

Sascha

von Dieter F. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
T. P. schrieb:
> Beim einfachen, unbeleuchteten, mit dem alles
> klappt (s.o.) ist dort explizit u.a. "für Arduino" genannt. Bei dem
> Problem-Typ nicht.

Aber mit Sicherheit nicht im Datenblatt. Und die beiden solltest Du Dir 
mal anschauen und vergleichen.

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sascha, Danke, du bist genial. Das Problem ist wenigstens gefunden, bloß 
noch nicht erklärt und gelöst.
Das Programm aus einem Buch, das ich genutzt habe, entspricht offenbar 
ziemlich genau jenem unter https://www.arduino.cc/en/Tutorial/HelloWorld

Im Buch steht noch "Serial.beginn(9600);" direkt vor der "lcd.begin();" 
Zeile. Ob die Baudrate verändert oder die ganze Zeile mit "//..." 
deaktiviert wird, ist aber recht egal und effektlos. Aber dann wirds 
sehr sehr spannend.

Mit "lcd.begin" soll ich eigentlich Zeichen und Zeilen angeben, also 
müsste ich "lcd.begin(16,2);" schreiben - schließlich hat mein Display 
2x16 Zeichen.
Tue ich das, dann wird der Kontrast arg blass. Deaktiviere ich die Zeile 
ganz oder gebe (0,0) oder auch (16,1) (.../eins!, nicht zwei!) ein, dann 
ist der Kontrast wie gewünscht "tiefschwarz" da.
(Dass die Zeilenzählung bei "lcd.beginn" mit eins, später bei 
"lcd.setCursor" mit Null beginnt, nehme ich mal verwundert zur Kenntnis, 
scheint aber schlicht so zu sein).

Bloß kann ich dann (...logischerweise) nur eine Zeile ansprechen, egal 
was ich unter "void loop" als "lcd.setCursor" vor angebe.

Wie schon gesagt, das Problem ist lokalisiert, dir sei Dank! Nur wie 
kommt man jetzt weiter? Der Sinn eines zweizeiligen Displays ist ja nun 
eigentlich schlicht, zwei Zeilen zu nutzen ;-)

(...muss es einfach noch erwähnen: Warum man hier angeben kann, a) 
Datenblätter zu lesen und b) zu entnehmen, dass keine negative Spannung 
erforderlich ist und genau das hier geraten bekommt, will und muss ich 
nicht wirklich verstehen)

von Dieter F. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
T. P. schrieb:
> a) Datenblätter zu lesen

Weil man denen das erforderliche (und durchaus unterschiedliche Timing) 
entnehmen kann

T. P. schrieb:
> b) zu entnehmen, dass keine negative Spannung
> erforderlich ist

Dazu muss man die Datenblätter halt lesen

von T. P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hast du eigentlich gerade irgendwie Spaß daran, mir nicht konstruktiv zu 
helfen, sondern nur kundzutun, dass du etwas weißt dass ich tatsächlich 
oder mutmaßlich nicht weiß?

Ich habe doch gerade beschrieben, was an "Fehlersuche" schon eingekreist 
ist und wie (...klein) die Konfigurationsmöglichkeiten in Arduino sind. 
Hast du das deinerseits gelesen?

Könntest du jetzt auch noch konkret und konstruktiv mitteilen, was ich 
deiner Meinung nach in dem Programm (s. genannter Link) verändern 
sollte?


Vielen Dank!

von myasuro (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo,
man muss es ja nur verstehen, hier gibt es ein paar Reizworte:
- Arduino
- umgehen Sprachprobleme C (wird nie und nimmer mit Arduino passieren, 
weil da, doch C(++) drinsteckt)

-> gedanke, vll. wäre es sinnvoll in Datenblatt zu gucken. Vll. geht man 
nur fälschlicherweise davon aus, dass die Pin- und Interface Kompatibel 
sind.

Und zum Display: 0. (also die eine Funktionierende) Zeile funkioniert 
komplett (Alle 16 Zeichen?)?(Nicht dass das Object lcd versucht 16 
Zeilen a 1 Zeichen anzuzeigen, und das auch noch aus irgendwelchen 
gründen funktioniert).

MfG
myasuro

von Crazy H. (crazy_h)


Bewertung
0 lesenswert
nicht lesenswert
Das TC1602A-08R benötigt eine positive Kontrastspannung und wenn ich das 
Datenblatt richtig gedeutet habe, liegt diese bei nahe 5V. Schonmal 
deine Versorgungsspannung gemessen?

von Stefan K. (stefan64)


Bewertung
-1 lesenswert
nicht lesenswert
Einfach mal die erste Antwort in diesem Thread beherzigen und ein delay 
in Deine loop einbauen.

von T. P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Saschas Antwort erfreut mich ja noch immer extrem, um es mal sehr 
diplomatisch auszudrücken.

- Ich habe die Datenblätter gelesen! Ich bin kein Informatiker. Soweit 
ich die grundlegenden Daten verstehe (u.a. Anschluss von Pin 1-14 bzw 16 
betreffend) sind die Displays "identisch" bzw. kompatibel. Wenn hier 
jemand eine geniale Idee hat, was dennoch das Problem ist, dann bitte 
konrekt beschreiben, schließlich funktioniert ja alles schon "fast".  So 
ne Art Kaffesatzlese hilft leider auch nicht weiter

- Nein, das Display braucht keine negative Spannung. Nein, das Display 
braucht nichts nahe 5V. Nahe 5V ist der Kontrast (offenbar bei jedem 
Display?!) min und nicht max. Nicht ohne Grund wird in manchen Quellen 
angeraten, einen normalen ca 15k Widerstand zur besseren "Spreizung" 
(also Einstellbarkeit) zusätzlich zu verwenden, und zwar zwischen Poti 
und VDD (!!), nicht zwischen Poti und GND!

- Ja, die eine Zeile, die mit der eigentlich fälschlichen 
"lcd.begin(16,1);" Einstellung ansprechbar ist, macht genau was ich 
will. Ich kann z.B. auch mit "lcd.setCursor(0,0)" und 
"lcd.setCursor(8,0)" zwei verschiedene Dinge ganz "ordnungsgemäß" 
anzeigen lassen.

- Ich bin durchaus in der Lage, im Datenblatt auf Seite 7 das Timing zu 
entnehmen. Aber wenn Ardiuno nur

#include <LiquidCrystal.h>
-LiquidCrystal lcd();
-lcd.begin();
-lcd.setCursor();
-lcd.print();

zum "Einstellen" anbietet, dann ist die sehr spannende Frage, wo ich da 
was einstellen soll.

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Einfach mal die erste Antwort in diesem Thread beherzigen und ein delay
> in Deine loop einbauen.
Naja, was meinst du denn, woran es liegt, dass ich diesen Tipp deiner 
Meinung nach nicht "beherzigt" und von keiner -dadurch erfolgreichen- 
Problemlösung berichtet habe?

von tommy_v (Gast)


Bewertung
1 lesenswert
nicht lesenswert
T. P. schrieb:
> Die "Verkabelung" ist, abgesehen von
> zusätzlichen K + A für die Beleuchtung auch exakt gleich wie die beim
> RCM2037R.

Kaum zu glauben:
Im Datenblatt steht Pin 15 = LED+ = +5,0V und Pin 16 = LED- = 0V.

Wenn man dann nicht weiterliest, dann verpasst man:
Operating Voltage = 3,1V @ 15mA
und
NOTE:
Do not connect +5V directly to the backlight
 terminals. This will ruin the backlight.

Du hast hoffentlich einen Vorwiderstand eingebaut.

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Widerstand: ja, klar, schon aus Prinzip.

Aber auch das ist alles sehr lustig und verwirrend. Auf Seite 4 (der 
einzigen quer gedruckten Seite) steht: "Backlight: Blue /Side 
Backlight/5.0V"
Eines der mehreren Exemplare habe ich zum "Opfer-Display" erklärt, mit 
dem ich schlicht alles ausprobiere, was mir als Lösungsansatz einfällt. 
Auch 5.0V machen der LED eindeutig nichts aus, zumindest mittelfristig. 
Stundenlangen Betrieb ohne Widerstand natürlich noch nicht probiert.

Warum kommt man überhaupt auf die Idee? Die LED hängt an Pin 15+16, 
vollkommen getrennt, offenbar und laut Datenblatt (Block Diagramm, S.3) 
Auch "verraten" das die Leiterbahnen auf der Display-Platine, soweit 
sichtbar. Zieht man auf dem Steckboard das Kabel von Pin 15 oder 16 geht 
die LED aus, klar!

Nur...,dann rutscht einem versehentlich mal das VDD Kabel ab (für VSS, 
danach verwundert ausprobiert, gilt das gleiche). Die LED leuchtet dann 
mit etwa halber Helligkeit weiter. Der Strom fließt dann offenbar 
gleichmäßig durch alle (!) restlichen Leitungen. Mit jedem weiteren 
Kabel, das man zieht (RS,E,D4-D7)leuchtet es etwas dunkler.

Also irgendwie pfuscht und wirkt die LED auch ins "Gesamtgefüge" ein, 
wie, warum, mit welchen ggf. unerwünschten Nebenwirkungen ....wer weiß.

von Planlos (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
T. P. schrieb:
> #include <LiquidCrystal.h>
> -LiquidCrystal lcd();
> -lcd.begin();
> -lcd.setCursor();
> -lcd.print();
>
> zum "Einstellen" anbietet, dann ist die sehr spannende Frage, wo ich da
> was einstellen soll.

Wie in der allerersten Antwort.

Mach in deine loop() ein delay(1000).

Das Timing wie oft was ausgegeben wird, macht dein Programm, nicht die 
lcd lib.

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Planlos schrieb:
> Mach in deine loop() ein delay(1000).

Nur geht es hier nicht um "wie oft", da es mit einem anderen Display 
funktioniert (und es hängt die selbe Library mit dem selben Timing 
dahinter).

Welche Spannung für high gibt Dein Arduino denn an den Pins aus? Das 
Pollin-Display will für ein high-Signal mindestens 0,7 mal der 
Versorgungsspannung des Displays (Datenblatt S. 5) - bei 5V also 3,5V, 
während das "Billigst-Display" mit "MC-freundlichen" 2,4V zufrieden ist.

von hinz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> da es mit einem anderen Display
> funktioniert

Das einen anderen Controller hat...

von T. P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jetzt wirklich mal Klartext:

Ich habe nicht die gerinste Ahnung, was in den letzten Jahren passiert 
ist, dass es allüberall in Foren extrem "respektlos" abgeht. Wie auch 
immer, es nervt! Ich freue mich über jede weiterführende Antwort, ganz 
besonders von Sascha. Von manchen anderen wäre es einfach unglaublich 
nett, wenn ihr eure besserwisserische, respektlose Herumraterei, 
manchmal noch mit überflüssigem Unterton, einfach unterlassen könntet. 
Für alle, die hier nur rumreden und es immer noch nicht gelesen und 
gemerkt haben: Nein, ein delay-Eintrag ändert nichts!

... vielen Dank für euer Verständnis!

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dieter, Danke, gute Frage und guter Hinweis, muss ich mal messen.
(...wobei mein Bauch mir sagt, wenn es in einer Zeile funktioniert, dann 
liegt es nicht daran. Aber der kann ja auch irren, also mess ich mal!)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
T. P. schrieb:
> Jetzt wirklich mal Klartext:
>
> Ich habe nicht die gerinste Ahnung, was in den letzten Jahren passiert
> ist, dass es allüberall in Foren extrem "respektlos" abgeht.

hmmm, kann es respektlos sein das wir hier im trüben fischen weil du 
noch nicht einmal deinen vollständigen Code hier gezeigt hast?

Hilde schrieb:
> Ich hatte mal welche von Pollin, die nur mit negativer Kontrastspannung
> funktioniert haben

kenne ich und war bei mir auch mal so

@TO

auch das könnte bei dir ein Grund sein, aber OK hast du widerlegt mit:

Sascha W. schrieb:
> eine zu hohe Schreibrate entsteht einfach
> wenn du in deinem Programm Werte/Texte in einer Loop ohne Pause
> ausgibst,
T. P. schrieb:
> Sascha, Danke, du bist genial. Das Problem ist wenigstens gefunden,

auf diesen Fehler hätte man dich ohne raten und Glaskugel hinweisen 
können mit Code!

T. P. schrieb:
> Jetzt wirklich mal Klartext:
>
> Ich habe nicht die gerinste Ahnung, was in den letzten Jahren passiert
> ist, dass es allüberall in Foren extrem "respektlos" abgeht.

ich finde deine Meckerei echt unangemessen zumal du es allen 
hilfewilligen nicht leicht machst weil du NIE deinen Code zeigst,

auch der Hinweis mit der verwendeten LIB kam spät und dann durfte man 
das auch selber googeln und reinsehen:

ich sehe zwar eine Syntax
1
LiquidCrystal(rs, enable, d4, d5, d6, d7)
2
LiquidCrystal(rs, rw, enable, d4, d5, d6, d7)
3
LiquidCrystal(rs, enable, d0, d1, d2, d3, d4, d5, d6, d7)
4
LiquidCrystal(rs, rw, enable, d0, d1, d2, d3, d4, d5, d6, d7)

aber kein Hinweis wo die Adressen der Zeilen liegen, ich musste in 
meinem Code schon öfter mal Startadressen anpassen:
1
#define LCD_CONTROLLER_KS0073 0  // < Use 0 for HD44780 controller, 1 for KS0073 controller 
2
3
/** 
4
 *  @name  Definitions for Display Size 
5
 *  Change these definitions to adapt setting to your display
6
 */
7
#define LCD_LINES           4     // < number of visible lines of the display 
8
#define LCD_DISP_LENGTH    20     // < visibles characters per line of the display 
9
#define LCD_LINE_LENGTH  0x28     // < internal line length of the display    
10
#define LCD_START_LINE1  0x00     // < DDRAM address of first char of line 1 
11
#define LCD_START_LINE2  0x40     // < DDRAM address of first char of line 2 
12
#define LCD_START_LINE3  0x14     // < DDRAM address of first char of line 3 
13
#define LCD_START_LINE4  0x54     // < DDRAM address of first char of line 4 
14
#define LCD_WRAP_LINES      0     // < 0: no wrap, 1: wrap at end of visibile line

mich wundert das es ohne derlei Anpassungen für alle Displays gehen 
soll.

: Bearbeitet durch User
von Dieter F. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
T. P. schrieb:
> wobei mein Bauch mir sagt, wenn es in einer Zeile funktioniert, dann
> liegt es nicht daran

Die Spannung hat (außer nach einem üppigen Essen) nichts mit dem 
Bauchgefühl zu tun. Wenn Du wenigstens den Typ Deines Arduino verrätst, 
dann kann man das auch so feststellen.

Ansonsten gilt: Wenn Du Dein Programm nicht öffentlich machen willst 
(aus welchen Gründen auch immer ...) einfach ein reduziertes Beispiel 
einstellen, bei welchem der Effekt auch auftritt.

von Nosnibor (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wenn es nicht das wiederholte Löschen und neu Beschreiben ist,
und auch kein Problem mit der Kontrastspannung,
dann scheint mir das hier der entscheidende Hinweis zu sein:
T. P. schrieb:
> Mit "lcd.begin" soll ich eigentlich Zeichen und Zeilen angeben, also
> müsste ich "lcd.begin(16,2);" schreiben - schließlich hat mein Display
> 2x16 Zeichen.
> Tue ich das, dann wird der Kontrast arg blass. Deaktiviere ich die Zeile
> ganz oder gebe (0,0) oder auch (16,1) (.../eins!, nicht zwei!) ein, dann
> ist der Kontrast wie gewünscht "tiefschwarz" da.
Der HD44780 (und ähnliche) kann Displays mit schaltungstechnisch einer 
Textzeile (also 8 Pixelzeilen) oder zwei Textzeilen (16 Pixelzeilen) 
ansteuern. Im zweiten Fall ist das Multiplexverhältnis natürlich 
ungünstiger.
Wie die Buchstaben jetzt auf dem Glas geometrisch angeordnet werden, ist 
ein Stück weit unabhängig von der Schaltung. Es gibt z.B.:
 - 1x20 auf dem Glas, Schaltung 2x10 (weniger Spaltentreiber nötig)
 - 2x8 auf dem Glas, Schaltung 1x16 (besseres Multiplexverhältnis)
 - 4x16 auf dem Glas, Schaltung 2x32 (mehr als zwei Zeilen kann der Chip 
ja nicht)
 ...
Hier ist wohl das eine Display 2x16 durch und durch, während das andere 
als 1x32 geschaltet ist.
Wenn die Library den Chip auf zwei Zeilen schaltet, obwohl nur eine 
Zeile angeschlossen ist, wird das Display nur in der Hälfte der Zeit 
angesteuert; dann ist es keine Wunder, daß es etwas gedimmt aussieht.
Also wäre wohl "lcd.begin(32,1);" korrekt, allerdings funktioniert dann 
die  Cursorpositionierung nicht richtig.

> (Dass die Zeilenzählung bei "lcd.beginn" mit eins, später bei
> "lcd.setCursor" mit Null beginnt, nehme ich mal verwundert zur Kenntnis,
> scheint aber schlicht so zu sein).
Das wiederum ist komplett logisch: lcd.begin() will die Anzahl der 
Zeilen wissen; da ist der kleinste sinnvolle Wert 1, denn ein Display 
ohne Zeilen ist nutzlos. Bei lcd.setCursor() ist die Nummer der Zeile 
gefragt, die fängt (wie allgemein üblich) bei 0 an zu zählen.

von T. P. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Nosnibor, vielen Dank! Interessanter Ansatz.
Nachdem ich zwecks Fehlersuche nochmal
http://www.sprut.de/electronic/lcd/
gelesen hatte, war ich auch ansatzweise auf der Fährte. Nach deiner 
Antwort nochmals genau so wie von dir angeraten ausprobiert.
Hilft nur leider nichts. So wie ich nach dem Komma eine 1 schreibe, ist 
die zweite Zeile "stillgelegt", das 16+x.te Zeichen rutscht nicht in die 
zweite Reihe.

Dieter, was das Datenblatt sagt und was Board x oder y eigentlich für 
eine Spannung hat, ist die eine Sache. Was aus sonstwas für Gründen dann 
wirklich Fakt ist, die andere Sache. Von daher geht hier wohl doch 
besser messen vor lesen. Aber auch ein sehr hilfreicher Denkansatz

Von den angeblichen 5V kommen nur 4,2V am Display an bzw aus dem 
Arduino-Board-5Volt-Pin raus. Ansonsten (folglich): RS 4.1V, E=0,12V, 
D4=0,7V, D5=3,7V, D6=2,7V,  D7=0,28V  (... allerdings auf die Schnelle 
am gegebenen Versuchsaufbau einfach mit einem Multimeter die digitalen 
Signale gemessen)

(Ansonsten lasse ich nichts auf mein Bauchgefühl kommen, der redet nicht 
nur beim Essen mit und hat fast immer Recht ;-))) )


**********************
btw:

> hmmm, kann es respektlos sein das wir hier im trüben fischen weil du
> noch nicht einmal deinen vollständigen Code hier gezeigt hast?

Schlicht nein und falsch. Einfach genau lesen. Hier "meckerst" du exakt 
auf die Art  an mir herum, die du mir fälschlich vorwirfst. Ich will und 
kann "meinen" Code nennen. Und ganz genau genommen ist es nicht 
"meiner", der Link zum kompletten Code ist daher schon lange genannt.

Und Sätze wie
>auf diesen Fehler hätte man dich ohne raten und Glaskugel hinweisen
>können mit Code!
nachdem ich mich bei Sascha bedanke, zählen dann haargenau zu dem, was 
schlicht und einfach respektlos ist.

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
T. P. schrieb:
> Von den angeblichen 5V kommen nur 4,2V am Display

Mir ging es nur darum, ob Du einen Arduino mit 5V oder mit 3,3V 
Betriebsspannung (z.B. Arduino Due) hast. Damit ist das erledigt.

Ich habe mir die Mühe gemacht mal Ausführungszeiten und 
Initialisierungs-Sequenzen mit dem Standard Hitachi HD44780 (Basis der 
Arduino-Lib) abzugleichen (für den 4-Bit Modus, den Du ja wohl nutzt). 
Das passt alles.

Das LCD ist also voll kompatibel. Bleiben noch Verkabelung und Code.

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
T. P. schrieb:
> Schlicht nein und falsch. Einfach genau lesen. Hier "meckerst" du

leider nicht wahr,

T. P. schrieb:
> Ich will und
> kann "meinen" Code nennen.

ach, jeder hier konnte das im Eröffnungsbeitrag lesen?

Autor: T. P. (marc_h2016)
Datum: 15.11.2016 14:52
T. P. schrieb:
> Hallo,

wo denn?

T. P. schrieb:
> Und ganz genau genommen ist es nicht
> "meiner"

ich habe im Thread gesucht nach:
Autor: T. P. (marc_h2016)

Ich habe nicht einmal als Anhang deinen Code gefunden und damit ist der 
Code gemeint mit dem du arbeitest und kein Link auf eine Internetseite!

Damit hätte man es schnell man nachbauen können, mit deinem Code und der 
LIB die du integriert hast.

: Bearbeitet durch User
von Georg G. (df2au)


Bewertung
1 lesenswert
nicht lesenswert
T. P. schrieb:
> das 16+x.te Zeichen rutscht nicht in die zweite Reihe.

Die zweite Zeile schließt sich bei fast allen Displays nicht nahtlos an 
die erste an. Der Beitrag von Joachim (jar) weiter oben zeigt es dir 
exemplarisch.

> Von den angeblichen 5V kommen nur 4,2V am Display an
Damit hast du ein Problem. Bei Unterspannung reagiert ein Display mit 
Kontrastverweigerung. Nur wenige neuere Typen (meist 3,3V Typen) haben 
eine eigene Kontrastspannungserzeugung auf dem Chip.

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim, ich streite nicht über Sachen, über die man nicht streiten kann 
und muss, weil die Fakten eindeutig für sich sprechen.
Und ich verbitte mir diese abermals recht respektlose Art, meine 
Beiträge hier großlächiger zu filetieren und zu kommentieren.

Ich klage hier selber immer wieder respektvollen Umgang ein und möchte 
es eigentlich jetzt auch weniger schnippisch klingend formulieren 
können, wenn es denn ginge: Aber wenn du unter dem Link keinen Code 
findest, dann kannst du offenbar einfach nicht scrollen - oder nicht die 
Stelle erkennen, an der es in den Programmcode übergeht.

von Dieter F. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Das LCD ist also voll kompatibel. Bleiben noch Verkabelung und Code.

T. P. schrieb:
> Joachim, ich streite nicht über Sachen, über die man nicht streiten kann
> und muss, weil die Fakten eindeutig für sich sprechen.

Ja und da Du weder DEINEN Code noch DEINE Schaltung offen legst suche 
halt bitte selbst weiter ... :-)

Lahalla-Marsch - und Abgang :-)

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
T. P. schrieb:
> Joachim, ich streite nicht über Sachen, über die man nicht streiten kann
> und muss, weil die Fakten eindeutig für sich sprechen.

stimmt, Fakt du hast DEINEN code nicht gezeigt, zu keiner Zeit!

T. P. schrieb:
> Und ich verbitte mir diese abermals recht respektlose Art

mach doch aber das bringt dich nicht weiter und macht dich immer 
lächerlicher!

Respektlos bist du der so um Hilfe bittet!

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kommentar fast überflüssig. Falsches wird nicht richtig, wenn man es zig 
mal wiederholt. Seid ihr bitte so respektvoll, und "erspart" mir weitere 
eurer Antworten. Vielen Dank!

von T. P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> Das LCD ist also voll kompatibel. Bleiben noch Verkabelung und Code.
> Lahalla-Marsch - und Abgang :-)

genau! Aber für wen won uns beiden wohl?
Wie oft habe ich geschriebn, dass Code und Verkabelung gleich sind, und 
nach Wechsel der Displays das unbeleuchtete fehlerfrei funktioniert, das 
beleuchtete andere nicht?
Ergo: Sie können nachweislich nicht "voll kompatibel" bzw. baugleich 
sein.
Welchen Erkenntniszuwachs soll mir und dem Rest der Welt also bitte 
diese deine "Hilfe" geben?
Ihr lest hier teilweise im Kaffeesatz aber nicht in vorherigen Einträgen 
und beschwert euch dann, wenn einem ein wenig der Unmut überkommt.... 
Unglaublich!

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
T. P. schrieb:
> Wie oft habe ich geschriebn, dass Code und Verkabelung gleich sind,

Ja, klar - und das war es jetzt auch wirklich für mich.

Beitrag "Re: falsche Pinbelegung mit AVR-Burn-O-Mat"

T. P. schrieb:
> Wie oft habe ich geschriebn, dass Code und Verkabelung gleich sind, und
> nach Wechsel der Displays das unbeleuchtete fehlerfrei funktioniert, das
> beleuchtete andere nicht?
> Ergo: Sie können nachweislich nicht "voll kompatibel" bzw. baugleich
> sein.
> Welchen Erkenntniszuwachs soll mir und dem Rest der Welt also bitte
> diese deine "Hilfe" geben?

Wenn Du das nicht verstehst - Dir sicher keinen.

von tommy_v (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wie lang sind eigentlich die Kabel zum LCD?

von Nosnibor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die 4,2 anstatt 5 Volt sind doch ein guter Hinweis. Laut Datenblatt will 
das Display mindestens 4,8V, sowohl für die Logik als auch als 
LCD-Betriebsspannung.
Zu wenig LCD-Betriebspannung erklärt den verringerten Kontrast.
Zu wenig Logikspannung ist ein akzeptabler Vorwand für gelegentliches 
"Austicken".
Fragt sich nur noch, wo das Display im Fehlerfall den Kontrast hernimmt. 
Das wäre leicht erklärt, wenn es im Fehlerfall nur noch einzeilig 
arbeiten würde.

Daß das andere Display in der gleichen Schaltung problemlos funktioniert 
hat, ist kein Widerspruch. Das andere Display ist eben anders:
 - vielleicht kommt es mit einer geringeren Versorgungsspannung besser 
klar
 - vielleicht ist es 3,3V-Logik-kompatibel
 - LCD-Betriebsspannungen hängen von allerlei Konstruktionsmerkmalen ab. 
Anderer Displaytyp -- anderer Betriebsspannungsbereich
 - vielleicht bekommt es eine höhere Versorgungsspannung zu sehen, weil 
keine Hintergrundbeleuchtung nebenbei Strom zieht

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]
  • [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.