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

[Guido (gui)]

Hallo,

ich habe einen Nucleo-L152RE Mikrocontroller und ein LCD-Display 1602. 
Ich möchte in der Arduino-IDE Zeichen über I2C zum Display schicken (im 
Beispiel den Buchstaben "A".

Leider wird auf dem Display nichts angezeigt. Die Verbindung selbst ist 
korrekt.

Der Quellcode ist im Anhang.

Ich wäre sehr dankbar, wenn mir jemand meinen Quellcode korrigieren 
könnte.

Guido

[Frank E. (ffje)]

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

[Karl B. (gustav)]

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

[Wolfgang S. (wolfgang_s278)]

Init LCD ?

[Guido (gui)]

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.

[Guido (gui)]

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

Wire.begin ();

[Steve van de Grens (roehrmond)]

Du kannst nicht einfach auf diese Weise Buchstaben an das Display 
senden.

Das Display muss für 4 Bit Kommunikation initialisiert werden. Dann 
musst du die Buchstaben in 4 Bit zerlegen und die Steuerleitungen des 
Display ansteuern.

Also lies das Datenblatt von HD44780 und von dem Port-Expander, der 
damit verbunden ist.

Da das kein Job für Anfänger ist, empfehle ich dir die Verwendung eines 
Display ohne Portexpander. Dann hast du einen Chip weniger beteiligt, 
was die Sache sehr vereinfacht.

> Wire.begin ();

Initialisiert weder den LCD Controller noch den Portexpander, sondern 
nur die I2C Schnittstelle des Mikrocontrollers.

[Peter (pittyj)]

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.

[Wolfgang S. (wolfgang_s278)]

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

[Steve van de Grens (roehrmond)]

Peter schrieb:
> Also letztendlich eine Aufgabe von 10 Minuten.

Laber keinen Blödsinn!

[Rainer W. (rawi)]

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?

[Peter (pittyj)]

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 (roehrmond)]

Peter schrieb:
> Ist doch kein Hexenwerk.

Danach kann er immer noch keine Buchstaben an das Display senden, so wie 
er sich das vorstellt.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Steve van de Grens (roehrmond)]

Arduino F. schrieb:
> Libraries gibt es einige.

Die will er ja nicht benutzen!

[J. S. (jojos)]

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.

[Peter (pittyj)]

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.

[J. S. (jojos)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

Steve van de Grens schrieb:
> Die will er ja nicht benutzen!
Von mir aus.

Zumindest kann man ja da rein schauen.

[Karl B. (gustav)]

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

[Axel R. (axlr)]

#include <LiquidCrystal_I2C.h>

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

void setup()
{
  lcd.init(); // initialize the lcd
  lcd.backlight();
}

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/

[Manfred P. (pruckelfred)]

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:

#include <Wire.h>
#include <LiquidCrystal_I2C.h>

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

LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
lcd.begin(16,2); // initialize the lcd
// Cursor Position: CHAR, LINE) start at 0  
 lcd.setCursor(0,0); //Start at character 0 on line 0
 lcd.print("Loetstation mk  ");
 lcd.setCursor(0,1);
 lcd.print(Version);
 delay(1500);

// ab hier läuft dann das Programm los

[Harry L. (mysth)]

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"

[Guido (gui)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Wastl (hartundweichware)]

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 (roehrmond)]

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

Das Display wurde dazu konzipiert, an den Adress- und Datenbus eine 
klassischen 8 Bit Mikroprozessors angeschlossen zu werden. Dann wäre es 
relativ einfach einfach gewesen. Dann hättest du es im 8 Bit Modus 
verwenden können und sowohl die Initialisierungs-Befehle als auch die 
Buchstaben einfach 1:1 an das Display senden können.

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.

Ein
> einfaches, aber funktionierendes Beispiel
kann es nicht geben. Eine funktionierende Bibliothek hast du.

Lies die Datenblätter der beiden Mikrochips. Probiere sie einzeln 
unabhängig voneinander aus. Solche Displays gibt es ohne Portexpander 
(mit paralleler Bus-Schnittstelle) zu kaufen. Die Portexpander kannst du 
mit ein paar LEDs und Schaltern ausprobieren. Erst wenn du mit beiden 
vertraut bist, solltest du sie miteinander kombinieren.

So eine Software baut man in Schichten eine nach der anderen auf, damit 
es einfacher zu verstehen ist.

[Wastl (hartundweichware)]

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 (roehrmond)]

Wastl schrieb:
> ein gängiges Arduino Board zu verwenden, das ist alles
> (fast) ganz einfach.

Ich bin ziemlich sicher, den TO richtig verstanden zu haben: Er möchte 
ausdrücklich nicht die fertigen Arduino Bibliotheken verwenden, 
sondern es auf niedrigerer Ebene selbst programmieren.

[Wastl (hartundweichware)]

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 (hartundweichware)]

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"

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Steve van de Grens (roehrmond)]

Steve van de Grens schrieb:
> Lies die Datenblätter der beiden Mikrochips. Probiere sie einzeln
> unabhängig voneinander aus.

Wastl schrieb:
> Ich bin ziemlich sicher dass der TO zwar viel möchte, aber wenig
> kann. Er muss noch viel lernen

Arduino F. schrieb:
> Ich kann keinen Wunsch nach "Grundlagenarbeit" erkennen.

Ich denke, die Notwendigkeit haben wir ihm deutlich genug gesagt. Jetzt 
kommt es darauf an, was er daraus macht. Sprüche wie

"Ich bin ziemlich sicher dass der TO ... wenig kann."

wirken dabei eher kontraproduktiv. Lasst ihn die nächsten Schritte 
wagen, die er sich zutraut. Wenn ihr freundlich seid, wird er sich dabei 
weiter von euch beraten lassen.

[J. S. (jojos)]

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.

[Wastl (hartundweichware)]

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.

[Sven B. (mainframeosx)]

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.

[Rahul D. (rahul)]

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.

[Frank O. (frank_o)]

Karl B. schrieb:
> Guido schrieb:
>> LCD-Display 1602
>
> Hat das I2C überhaupt?

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

[Rahul D. (rahul)]

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).

[Frank O. (frank_o)]

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?

[Frank O. (frank_o)]

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.

[Rainer W. (rawi)]

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. (frank_o)]

Frank O. schrieb:
> Wenn du ein Oled Display SSD1306

Noch ein Video dazu.

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

[Obelix X. (obelix)]

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.

[Axel R. (axlr)]

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.

[Frank O. (frank_o)]

Axel R. schrieb:
> Das sollte ja nun einfach sein, das auf I2C umzustricken.

Meins funktioniert doch. Kann er so nehmen.

[Manfred P. (pruckelfred)]

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.

[Jack V. (jackv)]

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.

[Sven B. (mainframeosx)]

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.

[Rahul D. (rahul)]

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.

[Steve van de Grens (roehrmond)]

>> Wenn du ein Oled Display SSD1306 nehmen willst.

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.

Dann hast du vielleicht eine unpassende Bibliothek verwendet. Ein Font 
braucht etwa 500 Byte Flash, und wenige 100 Bytes für den Code. 
Pufferspeicher im RAM ist gar keiner nötig.

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/

[Rainer W. (rawi)]

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' :-(

[Sven B. (mainframeosx)]

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.

[Rainer W. (rawi)]

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.

[Sven B. (mainframeosx)]

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.

[Frank O. (frank_o)]

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!

[Frank O. (frank_o)]

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.

[Rainer W. (rawi)]

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.

[Sven B. (mainframeosx)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Steve van de Grens (roehrmond)]

Arduino F. schrieb:
> Meinst du nicht, dass das bei einem OLED um
> Größenordnungen komplexer wird?

Wahrscheinlich. Dabei entfällt zwar der Portexpander, dafür muss man 
sich mit Pixeln beschäftigen, anstatt mit einfachen ASCII Zeichen.

[Frank O. (frank_o)]

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.

[Steve van de Grens (roehrmond)]

>> 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....

Frank O. schrieb:
> 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.

Ich war das. Ich helfe dir ma auf die Sprünge:

Guido schrieb:
> 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.

Das ist doch eindeutig, finde ich.

[Frank O. (frank_o)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Frank O. (frank_o)]

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.

[Frank O. (frank_o)]

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.

[Rainer W. (rawi)]

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.

[Frank O. (frank_o)]

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 (roehrmond)]

Ich habe zwei Datenblätter für diese kleinen OLED vorliegen. Eun 
Markenhersteller verspricht 10000 Stunden. Ein China Nachbau nur 4000.

Es scheint mir klug, die Helligkeit nur so hoch wie nötig einzustellen.

[Frank O. (frank_o)]

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?

[Steve van de Grens (roehrmond)]

Frank O. schrieb:
> Hast du mal einen Link oder kannst du die schicken?

Ich hatte die Zeiten falsch in Erinnerung. Es sind 10.00 vs. 50.000 
Stunden.

[Frank O. (frank_o)]

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.

[Steve van de Grens (roehrmond)]

Frank O. schrieb:
> Da werde ich mich in Zukunft sehr genau mit befassen.

Dann brauchst du wohl noch das Datenblatt des SSD1306 COG.

Ich habe dir auch die Datenblätter der größeren Displays angehängt.

[Frank O. (frank_o)]

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

Slave address bit (SA0)
SSD1306 has to recognize the slave address before transmitting or receiving any information by the
I
2
C-bus. The device will respond to the slave address following by the slave address bit (“SA0” bit)
and the read/write select bit (“R/W#” bit) with the following byte format,
b7 b6 b5 b4 b3 b2 b1 b0
0 1 1 1 1 0 SA0 R/W#
“SA0” bit provides an extension bit for the slave address. Either “0111100” or “0111101”, can be
selected as the slave address of SSD1306. D/C# pin acts as SA0 for slave address selection.
“R/W#” bit is used to determine the operation mode of the I2
C-bus interface. R/W#=1, it is in read
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!

[Steve van de Grens (roehrmond)]

Frank O. schrieb:
> Hast du da was fertig?

Siehe oben: http://stefanfrings.de/arduino_oled/

> Angenommen ich will zwei Displays anschließen,
> die unterschiedliche Daten ausgeben.

Dann musst du bei einem die SA0 Leitung (= D/C#) auf High setzen, und 
beim anderen auf Low. Fraglich ist, auf welchen Modulen die dazu nötigen 
Lötbrücken oder Pins erreichbar sind.

[Manfred P. (pruckelfred)]

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.

[Frank O. (frank_o)]

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.