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
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
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.
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.
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
Marc V. schrieb: > LCDevices-Displays freie Wortschöpfung? Ich weiss viele stehen auf doppel D aber bei LCD tut dat nicht Not.
>> LCD-Displays > > ist stottern Nur Piesepampel, Haarspalter und Beamtenseelen ziehen sich an sowas hoch.
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.
- 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.)
Ich hatte mal welche von Pollin, die nur mit negativer Kontrastspannung funktioniert haben
Betreibst du deinen Arduino per USB? Bricht evtl. die Versorgungsspannung ein wenn das Beleuchtete Display aktiv ist?
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.
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
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.
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)
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
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!
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
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?
Einfach mal die erste Antwort in diesem Thread beherzigen und ein delay in Deine loop einbauen.
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.
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?
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.
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ß.
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.
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.
Dieter F. schrieb: > da es mit einem anderen Display > funktioniert Das einen anderen Controller hat...
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!
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!)
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
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.
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.
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.
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.
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
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.
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.
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 :-)
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!
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!
>> 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!
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.