Mit Wire.h über I2C auf LCD-Display 1602 zugreifen

Ich habe auch ein 1602-LCD.
2 Zeilen, je 16 Zeichen, es wird mit SPI angesteuert.
Daten?
mfG fE

Guido schrieb:

LCD-Display 1602

Hat das I2C überhaupt? Meistens die übliche Parallelbus Ansteuerung HD44780. Bei mir geht das bei I2C nur über Portadapter PCF8574.

ciao gustav

Init LCD ?

Ja, es hat 2 Zeilen zu je 16 Zeichen.

Es ist das LCD-Display: LCD 1602 + I2C HD44780 Modul

Man kann es also definitiv auch über I2C ansteuern.

Alternativ zu Wire.h kann man z. B. auch über das Library LiquidCrystal_PCF8574.h ansteuern. Das klappt bei mir auch.

Aber jetzt möchte ich eben mit Wire.h über I2C auf das Display zugreifen und Zeichen ausgeben ... was eben nicht klappt.

Und wie kann ich das über Wire.h das LCD-Display initialisieren? Ich dachte, das macht die Zeile:

Wire.begin ();

Guido schrieb:

Alternativ zu Wire.h kann man z. B. auch über das Library LiquidCrystal_PCF8574.h ansteuern. Das klappt bei mir auch.

Wenn es geht, warum muss das dann die andere Bibliothek sein??

Dann nimm doch die funktionierende Bibliothek und analysiere auf Sourcecode Ebene, was sie auf den Bus schickt. Dann brauchst du nur das gleiche schicken. Der Sourcecode sollte ja vorhanden sein.

Alternativ ein Scope mit I2C Analysator anschliessen. Das teilt dir genau mit, was alles gesendet werden muss.

Also letztendlich eine Aufgabe von 10 Minuten.

Für INIT musst du eine Folge von Bytes (s. Datenblatt) an das LCD senden. Das geht auch über I2C. Pausen aber einhalten !

Guido schrieb:

Es ist das LCD-Display: LCD 1602 + I2C HD44780 Modul

Man kann es also definitiv auch über I2C ansteuern.

Stimmt die I2C-Adresse, d.h. antwortet dein I2C-Bus Expander, wenn du ihn unter der im Code eingetragenen Adresse ansprichst?

Steve van de Grens schrieb:

Peter schrieb:

Also letztendlich eine Aufgabe von 10 Minuten.

Laber keinen Blödsinn!

Kein Blödsinn: Scope nehmen. SDA,SCL und GND verbinden. I2C Analysemodus einschalten. Einmal mit LyquidCristal hochfahren. Und alles steht im Scope.

Alternativ LiquidCristal Sourcecode nehmen. In der Senderoutine (die selbst wahrscheinlich Wire benutzt) die Sendebytes mit printf herausschreiben. Dann steht alles auf der Konsole.

Ist doch kein Hexenwerk.

Steve van de Grens schrieb:

Da das kein Job für Anfänger ist,

Wire.h hört sich nach Arduino an! Dann sollte das Thema eigentlich fix durch sein.

Ein I2c Scanner zeigt einem die Adresse. Libraries gibt es einige.

https://www.mikrocontroller.net/articles/HD44780 Lesen. Das Display hat ein Parallel Interface, der I2C Expander macht nur die Umsetzung serielles I2C auf Daten- und Steuerleitungen. Da müssen die richtigen Sequenzen ausgegeben werden, einfach ein ‚A‘ ausgeben reicht nicht.

J. S. schrieb:

https://www.mikrocontroller.net/articles/HD44780 Lesen. Das Display hat ein Parallel Interface, der I2C Expander macht nur die Umsetzung serielles I2C auf Daten- und Steuerleitungen. Da müssen die richtigen Sequenzen ausgegeben werden, einfach ein ‚A‘ ausgeben reicht nicht.

Ja, und von daher wäre es doch etwas einfaches, die funktionierende LyquidCristal zu nehmen, und Reverse Engineering zu betreiben.

Ich habe letztens erst so ein Display mit einen FPGA bedient, weiss also, was man für Codes hinschicken muss, und wo man welche Wartezeiten beachten muss.

Das ist schön, aber erstmal sollte dem TO klar werden warum es nicht so einfach geht und sich die Hardware sowie Datenblatt des Displays dazu ansehen.

Steve van de Grens schrieb:

Die will er ja nicht benutzen!

Von mir aus.

Zumindest kann man ja da rein schauen.

J. S. schrieb:

Das ist schön, aber erstmal sollte dem TO klar werden warum es nicht so einfach geht und sich die Hardware sowie Datenblatt des Displays dazu ansehen.

Bei I2C muss man Instructions "maskieren", da ja keine "Hardware"-Pins für R/W, RS und Enable da sind. Das macht entweder der Portadapter oder das Display hat die Ansteuermöglichkeit I2C.

Im Beispiel wie der Enable-Impuls "maskiert" wird.

ciao gustav

1

#include <LiquidCrystal_I2C.h>

2

3

LiquidCrystal_I2C lcd(0x27, 16, 2); // I2C address 0x27, 16 column and 2 rows

4

5

void setup()

6

{

7

  lcd.init(); // initialize the lcd

8

  lcd.backlight();

9

}

Das, was

LiquidCrystal_I2C lcd(0x27, 16, 2); // I2C address 0x27, 16 column and 2 da macht, musst du herausfinden und selbst nachbasteln. bei VSCode und Platformio markierst Du lcd und drückst F12, um in die Bibliothek zu gelangen. dort kannst Du dir ansehen, wie die eigentliche Initialisierung aussehen muss. Also: Eine möglichkeit. Du kannst auch mit Wire.write() nacheinander, meinethablen untereinder geschrieben, alle Bytes rausschicken, die dein LCD benötigt, BEVOR es in der Lage ist, ein "A" darzustellen.

oder eben komplett zu Fuß. Das kann man ja leicht abwandeln. UNterscheiden musst Du halt nur, ob du ein KOMMANDO oder DATEN schicken willst. Also zB <Cursor links> oder "HALLO". Hier machen die das für einen STM32. https://controllerstech.com/i2c-lcd-in-stm32/

Steve van de Grens schrieb:

Da das kein Job für Anfänger ist,

Wie habe ich das bloß 2015 bei meinem ersten ernsthaften Arduino-Gerät gemacht? Das lief nicht auf Anhieb, weil unterschiedliche I2C-Boards im Umlauf sind. Klar ist auf jeden Fall, dass neben "Wire.h" auch die "LiquidCrystal_I2C.h" eingebunden werden muß. Soweit ich mich erinnere, muß die "LiquidCrystal_I2C.h" zum I2C-Board passen.

Es finden sich im Netz massenhaft Beispiele, aus denen man abmalen kann.

empfehle ich dir die Verwendung eines Display ohne Portexpander. Dann hast du einen Chip weniger beteiligt, was die Sache sehr vereinfacht.

Auch das muss initialisiert und bedient werden, dafür bindet man die "LiquidCrystal.h" ein. Finde ich irgendwie doof, weil das Display mehr Portleitungen belegt.

Axel R. schrieb:

Das, was

LiquidCrystal_I2C lcd(0x27, 16, 2); // I2C address 0x27, 16 column and 2 da macht, musst du herausfinden und selbst nachbasteln.

Hier sieht das anders aus:

1

#include <Wire.h>

2

#include <LiquidCrystal_I2C.h>

3

4

String Version = "V 2015-11-13 01";

5

6

LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

7

lcd.begin(16,2); // initialize the lcd

8

// Cursor Position: CHAR, LINE) start at 0  

9

 lcd.setCursor(0,0); //Start at character 0 on line 0

10

 lcd.print("Loetstation mk  ");

11

 lcd.setCursor(0,1);

12

 lcd.print(Version);

13

 delay(1500);

14

15

// ab hier läuft dann das Programm los

Axel R. schrieb:

Hier machen die das für einen STM32. https://controllerstech.com/i2c-lcd-in-stm32/

Warum in die Ferne schweifen? Beitrag "[STM32/HAL] generischer Treiber für die beliebten I²C-Text-Displays"

Vielen Dank euch allen für eure Rückmeldungen.

Eigentlich hatte ich mir gewünscht und auch erhofft, dass ich den Quellcode für ein einfaches, aber funktionierendes Beispiel bekomme. Und auf diesem wollte ich dann aufbauen und dieses erweitern.

Sieht aber so aus, als ob mein Wunsch nicht in Erfüllung geht und ich mich doch wesentlich eingehender damit beschäftigen muss.

Guido schrieb:

Eigentlich hatte ich mir gewünscht und auch erhofft, dass ich den Quellcode für ein einfaches, aber funktionierendes Beispiel bekomme.

Die Arduino LCD Libraries sind funktionierende Beispiele.

Guido schrieb:

Und auf diesem wollte ich dann aufbauen und dieses erweitern.

Was hindert dich?

Guido schrieb:

Sieht aber so aus, als ob mein Wunsch nicht in Erfüllung geht und ich mich doch wesentlich eingehender damit beschäftigen muss.

Drei Möglichkeiten du hast!

1. Selber lernen macht selber schlau
2. verwende, was es schon gibt.
3. aufgeben.

Guido schrieb:

Sieht aber so aus, als ob mein Wunsch nicht in Erfüllung geht und ich mich doch wesentlich eingehender damit beschäftigen muss.

Wenn du dich endlich von Arduino trennen könntest und eine richtige IDE verwenden würdest (z.B. Atollic Truestudio oder STM CubeIDE) könnte dir leicht geholfen werden. Aber dazu müsste "man" halt richtig programmieren können und nicht nur ein paar "Libs" zusammen kopieren und nicht verstehen was da eigentlich passiert. Nachdem du aber nicht den Anschein erweckst dich vom oben Erwähntem lösen zu können mache ich auch keine Anstalten dir was vorzuschlagen.

Steve van de Grens schrieb:

Aber bei deiner Hardware muss der Bus (da nicht vorhanden) durch Software simuliert werden. Weil bei dir auch noch ein I²C Portexpander dazwischen hängt, wird es noch eine Nummer komplexer.

Nein, natürlich könnte er sein 1602 Display direkt an sein Nucleo-L152RE Board hängen. "Bus" wäre sozusagen vorhanden, aber auch mit diesem muss man erst mal umgehen (können). Ob das aus der Arduino IDE überhaupt vorgesehen ist weiss ich nicht, kann mir es nicht so recht vorstellen.

Ideal wäre es sich erst mal vom Nucleo-L152RE zu verabschieden und ein gängiges Arduino Board zu verwenden, das ist alles (fast) ganz einfach.

Steve van de Grens schrieb:

Ich bin ziemlich sicher, den TO richtig verstanden zu haben:

Ich bin ziemlich sicher dass der TO zwar viel möchte, aber wenig kann. Er muss noch viel lernen. Mich bringt meine Annahme dazu wenn ich sehe wie er mit der Arduino IDE "arbeitet" und mit existierenden Lösungen nichts zustande bringt. Siehe:

Guido schrieb:

Ich möchte in der Arduino-IDE Zeichen über I2C zum Display schicken (im Beispiel den Buchstaben "A".

Da ist der Weg sehr weit sich von fertigen Arduino Bibliotheken zu trennen und auf eigenen Beinen zu stehen. Insbesondere dann wenn es sich um einen Arduino-fremden Controller handelt. Auch wenn es dazu (fast) fertige Lösungen gibt.

Harry L. (mysth) hat eine fertige Lösung für STM32 Controller hier präsentiert, ich finde sie nur auf die Schnelle nicht.

Wastl schrieb:

Harry L. (mysth) hat eine fertige Lösung für STM32 Controller hier präsentiert, ich finde sie nur auf die Schnelle nicht.

Hier ist der Thread dazu:

Beitrag "[STM32/HAL] generischer Treiber für die beliebten I²C-Text-Displays"

Steve van de Grens schrieb:

Er möchte ausdrücklich nicht die fertigen Arduino Bibliotheken verwenden, sondern es auf niedrigerer Ebene selbst programmieren.

Ihm möchte ein Beispiel und dieses erweitern. Ich kann keinen Wunsch nach "Grundlagenarbeit" erkennen.

Guido schrieb:

Aber jetzt möchte ich eben mit Wire.h über I2C auf das Display zugreifen und Zeichen ausgeben ... was eben nicht klappt.

Wire ist Arduino. Wenn man die LCD Komponente nicht verwenden möchte aber Wire dann ist das völlig schizophren.

J. S. schrieb:

Wire ist Arduino. Wenn man die LCD Komponente nicht verwenden möchte aber Wire dann ist das völlig schizophren.

Soviel zum Könnens- und Wissensstand des TO ....

Klare Vorstellungen und Äusserungen was man eigentlich machen möchte wären wünschenswert.

Also mit Wire.h kommste bei einem I2C lCD nicht weit, du musst die besagte Library mit I2C Ansteuerung nehmen alles andere ist Mehrarbeit. Beim STM gibt es im übrigen mehrere I2C Ports auch hier musste den richtigen aussuchen. Ich hatte das gleiche Problem.Zudem würde ich erst einen Portscanner aufspielen, damit kannst du im übrigen auch den I2C Port ausfindig machen.

Sven B. schrieb:

Zudem würde ich erst einen Portscanner aufspielen, damit kannst du im übrigen auch den I2C Port ausfindig machen.

Der zeigt aber nur die Adresse des Portexpanders, der I²C auf parallel umwandelt, an; nicht das Display. Mit dem Portexpander könnte man auch ein x-beliebiges anderes (paralleles) Display ansteuern.

Karl B. schrieb:

Guido schrieb:

LCD-Display 1602

Hat das I2C überhaupt?

Da gibt es fertige Module, die du dran löten kannst.

Frank O. schrieb:

Da gibt es fertige Module, die du dran löten kannst.

Bei manchen ist es schon am Display angelötet ;) (kostet ca. 50 Cent mehr)

Das ist doch "einfach nur" ein I²C-Parallel-Konverter (aka "Portexpander") auf einer Platine, die auf die Anschlüsse eines "Standard-" Displays passt.

Zum Ansteuern gibt es die og. LCD-Library, die (vermutlich) wiederum auf der Wire-Library aufbaut (bzw. sie nutzt).

Die funktioniert definitiv. Kopiere dir raus, was du brauchst. Ich hatte nämlich auch vor kurzem so eine Platine dran gelötet und das ausprobiert. Nur mit wire.h geht das auch nicht. Du musst schon noch das Display drin haben. Wire.h schickt das raus, aber wo hin?

Dann noch gleich eine hinterher. Wenn du ein Oled Display SSD1306 nehmen willst. Hier auch noch eine Testdatei. Die sind viel schöner. Da steht jetzt nur der Text drin. Das war nur der Test, ob es klappt und bekomme ich alle Informationen angezeigt. Da lohnt es sich auch, sich in die Bibliothek einzuarbeiten.

Guido schrieb:

Sieht aber so aus, als ob mein Wunsch nicht in Erfüllung geht und ich mich doch wesentlich eingehender damit beschäftigen muss.

Das Leben ist kein Wunschkonzert und Weihnachten ist noch ein bisschen hin.

Krieg den A.sch hoch und fang an. Oder kauf dir einen fertig passend programmierten µC mit Display, bei dem du dann mit dafür bezahlst, dass andere die Arbeit für dich machen. Ingenieurbüros, die diesen Job gerne übernehmen, gibt es genug, wenn du mit den passenden Scheinen winkst.

scnr

Frank O. schrieb:

Wenn du ein Oled Display SSD1306

Noch ein Video dazu.

https://www.youtube.com/watch?v=HtuWLufEt9g

Guido schrieb:

Sieht aber so aus, als ob mein Wunsch nicht in Erfüllung geht und ich mich doch wesentlich eingehender damit beschäftigen muss.

Macht euch doch nicht so viel Arbeit. Guido ist doch schon lange Raus aus dem Thema.

Hier steht drin, wie das Display initialisiert wird https://github.com/lucasmaziero/LiquidCrystal_I2C/blob/master/LiquidCrystal_I2C.cpp und hier diese "komischen Konstanten", also die ganzen Vereinbarten Wörter, damits nicht zu unübersichtlich wird: https://github.com/lucasmaziero/LiquidCrystal_I2C/blob/master/LiquidCrystal_I2C.h

Jetzt musste doch "nur" die Reihenfolge raussuchen und mit wire.write ( oder was es da gibt) die Bytes nacheinander rausschicken. Weil das eben niemand zu Fuß beim Arduino macht (warum auch?) gibt es das fertig in der besagten Bibliothek. Wenn Du nicht nehmen willst, musst du es eben zu Fuß machen. Niemand wird sich jetzt hinsetzen und das für dich tun.

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung

statt "lcd_out" musst Du das eben durch wire.write() ersetzen, einfach gesprochen.

https://controllerstech.com/interface-lcd-16x2-with-stm32-without-i2c/ hier gibt es die Init-Sequenz auch.

Das sollte ja nun einfach sein, das auf I2C umzustricken.

Axel R. schrieb:

Das sollte ja nun einfach sein, das auf I2C umzustricken.

Meins funktioniert doch. Kann er so nehmen.

Frank O. schrieb:

Hat das I2C überhaupt?

Da gibt es fertige Module, die du dran löten kannst.

Ja, und am besten richtigherum.

Zu allem Überfluß sind nicht alle I2C-Module gleich, die LCD-Library samt Initialisierung muß dazu passen.

Frank O. schrieb:

Wenn du ein Oled Display SSD1306 nehmen willst.

Ganz tolle Sache, wenn man spielen will. Die Dinger brauchen im µC dermaßen viele Ressourcen, dass ernsthafte Anwendungen kaum noch machbar sind, hat mich an einem ATMega328 angeschissen.

Die sind viel schöner.

Vor allem sind sie bei starkem Umgebungslicht nicht mehr ablesbar und deren Lebensdauer beglückt auch nicht.

Manfred P. schrieb:

Ganz tolle Sache, wenn man spielen will. Die Dinger brauchen im µC dermaßen viele Ressourcen, dass ernsthafte Anwendungen kaum noch machbar sind, hat mich an einem ATMega328 angeschissen.

Wie das? Sobald die mit Daten beschickt sind, muss man sich nicht mehr drum kümmern, und beim Beschicken brauchen sie nicht mehr Ressourcen, als andere Monochromdisplays mit der jeweiligen Auflösung.

Rahul D. schrieb:

Sven B. schrieb:

Zudem würde ich erst einen Portscanner aufspielen, damit kannst du im übrigen auch den I2C Port ausfindig machen.

Der zeigt aber nur die Adresse des Portexpanders, der I²C auf parallel umwandelt, an; nicht das Display. Mit dem Portexpander könnte man auch ein x-beliebiges anderes (paralleles) Display ansteuern.

Das Display ist am Portexpander angeschlossen oder? Also wird mit dieser Adresse das LCD angesprochen oder? Das geht das über die sogenannte Liquid library mit I2C support.

Ich verstehe die Frage jetzt selber nicht die du mir damit gegeben hast.Wenn du aber meinst das es nicht so ist, dann bitte. Ich selber habe schon ziemlich viele von den LCD in der Schublade liegen und in gebrauch. Entweder über I2C oder Paralell. Beides geht mit der entsprechenden Library.

Sven B. schrieb:

Das Display ist am Portexpander angeschlossen oder? Also wird mit dieser Adresse das LCD angesprochen oder? Das geht das über die sogenannte Liquid library mit I2C support.

Jups.

Ich verstehe die Frage jetzt selber nicht die du mir damit gegeben hast.Wenn du aber meinst das es nicht so ist, dann bitte. Ich selber habe schon ziemlich viele von den LCD in der Schublade liegen und in gebrauch. Entweder über I2C oder Paralell. Beides geht mit der entsprechenden Library.

Das verstehe ich nun wieder nicht.

Man ändert mit dem Portexpander einfach nur die Schnittstelle. Um die Konfiguration und "Ansteuerung" (z.B. Löschen des Displays o. dergl.) muss man sich weiterhin kümmern bzw. das übernimmt die LCD-Library. Die könnte vermutlich auch mit einem anderen Schnittstellentreiber (Software wie die wire.h) ein Display ansteuern. Klassischer Fall eine Abstraktionsebene.

Jack V. schrieb:

Wie das? Sobald die mit Daten beschickt sind, muss man sich nicht mehr drum kümmern, und beim Beschicken brauchen sie nicht mehr Ressourcen, als andere Monochromdisplays mit der jeweiligen Auflösung.

Eben, der TO will ein monochromes 2x16 7-Segment Display mit integriertem Zeichengenerator ansteuern (32 Byte Daten), du redest von einem farbigen 128 x 64 Pixel Graphikdisplay mit lupenverdächtiger Schriftgröße.

Sven B. schrieb:

Das Display ist am Portexpander angeschlossen oder? Also wird mit dieser Adresse das LCD angesprochen oder?

Jein, über I2C wird genau der Portexpander angeschlossen und darüber muss man dann die 4-Bit Parallelschnittstelle mit Control-Port vom Display per Bit-Banging emulieren. Das LCD besitzt keine Adresse, sondern nur seinen Parallelport.

Sven B. schrieb:

Entweder über I2C oder Paralell.

Da war doch irgendwas mit Doppel-'l' :-(

Also wenn du das über wire.h machen willst, dann musst du die Adresse vom Portexpander wissen. Die einzelnen Pins vom Portexpander zum LCD must du dann auch wissen, und welches Bit was macht muss du auch wissen. Diese Kombination von Init mit der Initalisierung musst du natürlich von hand dann nach und nach auf den Portexpander schieben, damit das Display weiß wie es funktionieren soll.

Ein blick in die LiquidCrystal_I2C.cpp und in die LiquidCrystal_I2C.h offenbart das Geheimnis

#ifndef LiquidCrystal_I2C_h #define LiquidCrystal_I2C_h

#include <inttypes.h> #include "Print.h" #include <Wire.h>

// commands #define LCD_CLEARDISPLAY 0x01 #define LCD_RETURNHOME 0x02 #define LCD_ENTRYMODESET 0x04 #define LCD_DISPLAYCONTROL 0x08 #define LCD_CURSORSHIFT 0x10 #define LCD_FUNCTIONSET 0x20 #define LCD_SETCGRAMADDR 0x40 #define LCD_SETDDRAMADDR 0x80

Wenn du jetzt cpp kannst, dann verstehst, kannst du die Initaliesierung ganz leicht selber herauslesen.

Und ich klinke mich dann mal aus. Hier hilft vieleicht etwas Lesen und das Verständniss wie was geht.

Sven B. schrieb:

Also wenn du das über wire.h machen willst, dann musst du die Adresse vom Portexpander wissen.

Bei der Nutzung mit anderen Libraries oder eigenen Funktionen ist das nicht anders. Für einen PCF8574 gibt es 8 verschiedene Möglichkeiten, die Adresse zu konfigurieren. Die in der SW angesprochene Adresse muss zu der Beschaltung auf dem I2C-Board passen.

Rainer W. schrieb:

Sven B. schrieb:

Also wenn du das über wire.h machen willst, dann musst du die Adresse vom Portexpander wissen.

Bei der Nutzung mit anderen Libraries oder eigenen Funktionen ist das nicht anders. Für einen PCF8574 gibt es 8 verschiedene Möglichkeiten, die Adresse zu konfigurieren. Die in der SW angesprochene Adresse muss zu der Beschaltung auf dem I2C-Board passen.

Ich glaube nicht das du mir das erklären mußt. Siehe Post weiter oben. Ich habe Erfahrung mit den I2C Lcd Expander. Hatte ein von Pollin und musste die Library anpassen.

Steve van de Grens schrieb:

Für gemischte Text/Grafik Ausgabe kann ich dir meine Klasse als Alternative zu der deutlich größeren von Adafruit anbieten. Ihr Speicherbedarf passt zum ATmega328. http://stefanfrings.de/arduino_oled/

Hallo Stefan! Neuer Name? Werde mir deinen ZIP auch ansehen. Danke dafür!

Für alle anderen hier, die auf mich wegen des Displays losgegangen sind. Das war nur ein Vorschlag. In allen Büchern und Tutorials werden diese, höchstens zweizeilige, LCD Displays gezeigt. Diese OLEDs sind günstig, können viel mehr anzeigen und benutzen I²C. Wenn der TO möchte, kann er das benutzen. Zuerst hatte ich eine funktionierende Datei geschickt, die sein Display funktionieren lässt. Das andere war nur ein Angebot, auch im eine andere Richtung zu schauen. Viel wichtiger, beides funktioniert definitiv. Und Ressourcenverbrauch, klar, wenn man die Adafruit nimmt. Aber das ist eine geänderte lib.

Sven B. schrieb:

Ich glaube nicht das du mir das erklären mußt.

Das war eine Ergänzung für den TO, da dein Beitrag sich so anhörte, als ob das nur bei Nutzung der wire.h erforderlich ist.

Rainer W. schrieb:

Sven B. schrieb:

Ich glaube nicht das du mir das erklären mußt.

Das war eine Ergänzung für den TO, da dein Beitrag sich so anhörte, als ob das nur bei Nutzung der wire.h erforderlich ist.

Dann bitte an denjenigen schreiben den es Betrifft, ich hatte mich angesprochen gefühlt.

Wenn das so ist, entschuldige ich mich.

Frank O. schrieb:

Für alle anderen hier, die auf mich wegen des Displays losgegangen sind.

Tut mir leid, damit kann ich nicht dienen. Erfülle aber gerne deine Erwartungshaltung.

Mir scheint es recht egal zu sein, ob man mit einem Opel oder einem VW zum Supermarkt fährt. Es wäre allerdings gut, wenn man das Fahrzeug bedienen kann und darf.

Gut, für ein Display braucht man keinen Führerschein, aber eben doch die nötigen Fähigkeiten.

Soweit bisher ersichtlich, möchte der TO keine weitere Lib zwischen Display und Wire, sondern diese Schicht selber bauen. Leider scheint dabei eine Überforderung aufgetreten zu sein....

Meinst du nicht, dass das bei einem OLED um Größenordnungen komplexer wird? Also noch mehr Überforderung.

Zudem halten die billigen LCD durchaus eine Generation durch. Ein OLED kann nach 1/2 Jahr schon halb blind sein.

Arduino F. schrieb:

Soweit bisher ersichtlich, möchte der TO keine weitere Lib zwischen Display und Wire, sondern diese Schicht selber bauen. Leider scheint dabei eine Überforderung aufgetreten zu sein....

Das stand nicht in seinem Eingangspost. Irgendwer, ich schaue jetzt nicht nach, hat das so interpretiert und ich sehe es nicht so. Außerdem hat der TO sich nicht dagegen geäußert. Trotzdem kann er anhand dieser funktionierenden Beispiele lernen und dann selbst seine Lib schreiben, wenn man will. Kann natürlich auch an Hand vom Datenblatt alles selbst raus finden. Aber da er schon bei wire nicht weiter wusste, wird das schwer.

Arduino F. schrieb:

Zudem halten die billigen LCD durchaus eine Generation durch. Ein OLED kann nach 1/2 Jahr schon halb blind sein.

Ich habe jetzt eines von den großen Displays (2,42") drei Tage, also so um die 70 Stunden durchlaufen lassen und es funktioniert noch. Generationen benutzt du vielleicht (ich auch; mein Firmentelefon wurde jetzt nach 8 Jahren ausgetauscht, weil der Akku kaputt ist), aber in der Regel ist nach ein paar Jahren doch Schluss. Und selbst wenn, dann bestellt er gleich zwei und die halten dann zusammen eine Generation. Aber nochmal, es war nur ein Angebot, dass es da mehr gibt, als die in den Büchern beschriebenen Displays. Wenn man sowieso auf I²C gehen will.

P.S.: Wenn jemand diese Dinger nehmen will, da muss man ein bisschen was umbauen.

Frank O. schrieb:

Ich habe jetzt eines von den großen Displays (2,42") drei Tage, also so um die 70 Stunden durchlaufen lassen und es funktioniert noch. .... dann bestellt er gleich zwei und die halten dann zusammen eine Generation.

Ich bewundere deine Rechenkünste.

Steve van de Grens schrieb:

Das ist doch eindeutig, finde ich.

Ist es! Da habe ich wohl drüber gescrollt. Asche auf mein Haupt. Teilweise lese ich auf dem Mobiltelefon. Vielleicht hatte ich es deshalb überlesen. Dann sind meine Beiträge sicher nutzlos für den TO. Tut mir leid, den Faden hier verbogen zu haben.

Arduino F. schrieb:

Ich bewundere deine Rechenkünste.

Hahaha! (Bin ja auch kein Ing.) Aber wo ich dich hier so gerade dran habe. Weißt du noch, vor Jahren, wie wir hier Arduino verteidigen mussten? Da hat sich in meiner zeitweise Abwesenheit einiges getan.

Frank O. schrieb:

Ich habe jetzt eines von den großen Displays (2,42") drei Tage, also so um die 70 Stunden durchlaufen lassen und es funktioniert noch.

Doch schon so lange?

Bei OLED geht es, genauso wie bei LEDs, nicht um funktioniert/funktioniert nicht, sondern um die Abnahme des Wirkungsgrades mit der Betriebszeit. Meist wird die Lebensdauer als die Halbwertszeit der Leuchtdichte definiert.

LG gibt für seine neusten OLED Panele eine Lebensdauer von 100000 Stunden an. Bin gespannt, was dein Display nach so einer Betriebsstundenzahl noch so von sich gibt. Berichte bitte mal.

Rainer W. schrieb:

Doch schon so lange?

Ironie nicht erkannt?

Rainer W. schrieb:

LG gibt für seine neusten OLED Panele eine Lebensdauer von 100000 Stunden an. Bin gespannt, was dein Display nach so einer Betriebsstundenzahl noch so von sich gibt. Berichte bitte mal.

Das wären ~ 11 Jahre. Bis dahin bin ich ganz sicher tot. Wenn ich diese Jahr überhaupt überlebe ...

Steve van de Grens schrieb:

Ich habe zwei Datenblätter für diese kleinen OLED vorliegen.

Hast du mal einen Link oder kannst du die schicken?

Klasse Stefan! Die werden mir sehr weiter helfen. Vor allem das zweite, das wird wohl 100% zu den billigen Dingern passen. Da werde ich mich in Zukunft sehr genau mit befassen. Und was die Zeiten anbetrifft. Wenn's kaputt ist, kommt ein neues dran.

Stefan, ich lebe schon seit 1,5 Jahren auf Kredit. Im Moment geht es mir auch nicht so gut. Morgen erfahre ich was das MRT sagt. Ich muss nichts mehr für eine ferne Zukunft machen. Obwohl ich so weiter lebe (so gut es halt geht), als wäre das Ende in normaler Entfernung (aber was ist schon noch normal, nach den Spritzen; kippen doch alle um), so weiß ich was die Statistik sagt. Ich nehme die Chemo jeden Tag und werde mich hüten eine Tablette zu vergessen, trotzdem ist das keine Garantie. Mein Leben lang habe ich wie irre gearbeitet (arbeiten bin ich immer noch), für mich das Wenigste ausgegeben. Scheiß auf so ein doofes Display. So wie ich die Umwelt geschont habe, schon seit meiner Jugend, da kann ich im Zweifel so ein Display austauschen.

Ja, auf jeden Fall! Habe das gerade kurz angesehen. Kann ich die Adresse ändern?

1

Slave address bit (SA0)

2

SSD1306 has to recognize the slave address before transmitting or receiving any information by the

3

I

4

2

5

C-bus. The device will respond to the slave address following by the slave address bit (“SA0” bit)

6

and the read/write select bit (“R/W#” bit) with the following byte format,

7

b7 b6 b5 b4 b3 b2 b1 b0

8

0 1 1 1 1 0 SA0 R/W#

9

“SA0” bit provides an extension bit for the slave address. Either “0111100” or “0111101”, can be

10

selected as the slave address of SSD1306. D/C# pin acts as SA0 for slave address selection.

11

“R/W#” bit is used to determine the operation mode of the I2

12

C-bus interface. R/W#=1, it is in read

13

mode. R/W#=0, it is in write mode.

Angenommen ich will zwei Displays anschließen, die unterschiedliche Daten ausgeben. Ah, hab gerade gelesen, dann muss man die Adresse wohl erst ins Data Command Register schreiben. Hast du da was fertig? Danke erstmal für die Datenblätter!

Frank O. schrieb:

Diese OLEDs sind günstig, können viel mehr anzeigen und benutzen I²C.

Es gibt sie auch mit SPI. Der SSD1306 kann beides, die verbreiteten 0,96"-Chinesen bestücken ein paar Brücken abweichend.

Ein paar Beiträge höher habe ich ein Bild von einem 2,42" Display eingestellt. Das hat auch SPI. Man muss für I²C ein wenig was ändern. Steht aber alles in Stefans Beitrag.