I2C-LCD-Treiber/Lib mit Contrast & Backlightdim

Hi,

ich spiele seit einiger Zeit mit I2C-LCDs, weil's einfach bequemer ist.

Nun frage ich mich, ob es auch Treiber- bzw. Backpackplatinen gibt, die es ermöglichen über I2C den Kontrast und die Displayhelligkeit einzustellen?
Und welche I2C-Lib das dann auch unterstützen würde. Die, die ich verwende ( GitHub - johnrickman/LiquidCrystal_I2C: LiquidCrystal Arduino library for the DFRobot I2C LCD displays ) tut das nämlich nicht:

////Unsupported API functions (not implemented in this library)
uint8_t status();
void setContrast(uint8_t new_val);

VG
da_user

Die LCD, die zu der Library passen, lassen sich nicht extern über I2C einstellen.

Die Helligkeit kannst du nur direkt am Display und unabhängig von I2C einstellen, den Kontrast überhaupt nicht.
Das geht nur am entsprechenden Poti auf der Platine, oder du bastelst dir selbst etwas.

Sorry, du hast irgendwie kein Wort von meiner Frage verstanden.

Meine Frage war nicht, wie das bei den üblichen Huckepackplatinen geht, sondern ob es Huckepackplatinen gibt, die das unterstützen.

Und wie der von mir gepostete Codauszug zeigt, kann ich mit der von mir bis dato verwendeten Lib dazu auch nix anfangen. Darum auch meine Frage, welche Libs das unterstützen würden.

da_user:
Sorry, du hast irgendwie kein Wort von meiner Frage verstanden.

Meine Frage war nicht, wie das bei den üblichen Huckepackplatinen geht, sondern ob es Huckepackplatinen gibt, die das unterstützen.

Und wie der von mir gepostete Codauszug zeigt, kann ich mit der von mir bis dato verwendeten Lib dazu auch nix anfangen. Darum auch meine Frage, welche Libs das unterstützen würden.

Dann nochmal deutlicher.
Nein, die gibt es nicht, Hardware sowie Software.
Mir ist auch nicht bewusst, warum du den Kontrast einstellen musst.

Was es gibt sind Module wie Sparkfun SerLCD. Das sind Module in der Form eines I2C-Backplane, aber von der Technik her kleine Controllerboards mit PIC-Prozessor. Die werden aber über UART angesprochen, nicht über I2C. Dort gibt es kein Poti, die Helligkeit wird mit einem Transistor und PWM geregelt. Die Helligkeit kann man über die Schnittstelle steuern. Kontrasteinstellung haben die aber auch nicht.

Korrektur:
Es scheint mittlerweile neue Modelle zu geben. Mit AVR statt PIC und sie sprechen UART, I2C und SPI. Anscheinend kann man die aber hauptsächlich komplett mit passendem LCD dran kaufen.

Hi

Alternativ nimmt man einen anderen Port-Expander.
Wenn man mit '8 Beinchen' nicht aus kommt, nimmt man halt 16.
Diesen '8 Zusatzbeinchen' kann man dann ein Digital-Poti anlöten oder sonst einen Quatsch mit treiben.

DAS wäre natürlich nicht mehr C&P-mäßig zu programmieren - also für den TO wohl:
Nein, gibt es so nicht.
Wenn Du Das hier nicht richtig gelesen hast: NEIN :wink:

Das hier drüber Genannte kann man genauso mit einem zusätzlichen Arduino erschlagen - wäre dann quasi der 'PIC/AVR' - nur, daß man selber dran rumprogrammieren kann - mit der IDE.
Man müsste wohl etwas Pinne pollen, daß man bei den ganzen Display-Befehlen, Die dann als INPUT an kommen, nicht durcheinander kommt und müsste dann den ganzen Kram auf anderen Beinchen an das ebenfalls angeschlossene LCD aufbügeln.
Neben den Zusatz-Features, Die man so braucht.
DA dann einen halbwegs brauchbaren Quasi-Standard für zu entwickeln, Den auch Andere als sinnvoll erachten und eben übernehmen, wird ein weiteres, nicht ganz einfaches Thema.

Alternativ: Ja, geht Alles - mein PC kann Das z.B. - mit der Maus bisschen rumgeklickt, und schon ist sogar die Auflösung eine Andere.
Ist halt die Frage, warum ich vom Arduino unbedingt meinen PC fernsteuern will ...

In diesem Sinne
MfG

postmaster-ino:
nur, daß man selber dran rumprogrammieren kann - mit der IDE.

Kann man wohl sogar. Deswegen haben sie von PIC zu AVR gewechselt. In der Doku ist beschrieben, wie man den Displaycontroller mit der Arduino IDE umprogrammieren kann. So gesehen ist es ein zweiter Arduino.

Kontraststeuerung hat die AVR Version wohl auch.

HotSystems:
Mir ist auch nicht bewusst, warum du den Kontrast einstellen musst.

Muss dir auch nicht bewusst sein. Mir ging es erstmal nur mal um die theoretische Betrachtung. Immerhin ist da eine entsprechende Methode in der Lib drinnen, und irgendwer muss sich dabei etwas gedacht haben. Also gehe ich davon aus, dass es evtl. Platinchen gibt, die das können und wenn ja, würde ich die gerne kennen.

ArduFE:
Korrektur:
Es scheint mittlerweile neue Modelle zu geben. Mit AVR statt PIC und sie sprechen UART, I2C und SPI. Anscheinend kann man die aber hauptsächlich komplett mit passendem LCD dran kaufen.

Die SerLCD-Module habe ich jetzt auf die schnelle sogar ohne LCD gefunden. Die anderen Varianten nicht. Interessant dass es sowas gibt, und sich der AVR darauf wohl sogar schön unprogrammieren lässt.

Preislich ist das für mich allerdings eher uninteressant, das ist es ökonomischer, einfach eine 5. Leitung zu legen, und das Backlight per PWM vom Controller anzusteuern.

postmaster-ino:
Das hier drüber Genannte kann man genauso mit einem zusätzlichen Arduino erschlagen - wäre dann quasi der 'PIC/AVR' - nur, daß man selber dran rumprogrammieren kann - mit der IDE.
Man müsste wohl etwas Pinne pollen, daß man bei den ganzen Display-Befehlen, Die dann als INPUT an kommen, nicht durcheinander kommt und müsste dann den ganzen Kram auf anderen Beinchen an das ebenfalls angeschlossene LCD aufbügeln.
Neben den Zusatz-Features, Die man so braucht.
DA dann einen halbwegs brauchbaren Quasi-Standard für zu entwickeln, Den auch Andere als sinnvoll erachten und eben übernehmen, wird ein weiteres, nicht ganz einfaches Thema.

Das war tatsächlich auch meiner ersten Gedanken.
So schwer wäre es ja wohl nichtmal, der Controller müsste ja "nur" Befehle von der I2C-Schnittstelle empfangen, und das Display passend über die normale LiquidCrystalLib ansteuern. Dann noch den gewünschten Zusatzkram dazu, eine passende, zur Standardlib komplatible Lib...
Wird aber auch wieder teuer, und die Mannstunden die da reingehen...
Damit landet man dann wieder bei der 5. Leitung...

Weiterer Gedanke war, da man das Backlight bei den jetzigen Platinen ein- und ausschalten kann, da sowas wie eine SoftwarePWM reinzuprogrammieren.
Ob da aber der I2C-Bus flott genug ist? Und vor allem dürfte es da wohl Probleme geben das in "Echtzeit" so hinzubekommen, dass das gut ausschaut, wenn da auf dem Bus etwas los ist. Dann müsste man den Ein-/Ausbefehl wohl in den I2C-Buffer mit reinschieben, statt hinten ran hängen.

Ich denke ich werde wohl mal bei Gelegenheit(TM) experimentieren, ob das mit der einfachen Methode klappt und dabei gut ausschaut. Aber allzuviel Energie da reinzustecken ist wohl eher sinnlos.

Danke für die Infos!

Hi

Einen passives PWM-Dimmen - also sämtliche An/Aus-Befehle einzeln über den Bus schicken - halte ich nicht nur für äußerst 'eigen', auch wird Dir diese Spielerei rechnt schnell auf die Füße fallen, wenn wirklich Mal was auf dem I2C-Bus los ist.
Aber: Es gibt I²C-PWM Chips - eigentlich für 16 Kanäle Servos oder eben PWM - aber dann hast Du Da noch 15 nutzlose PWM-Kanäle rumdümpeln.
Denke, sinnvoller wäre wirklich eine 5.te Leitung oder der genannte Zusatz-µC, Der den Port-Expander der LCD-Platine ersetzt mit zusätzlichen Befehlen zum Dimmen des Backlight oder Anpassen des Kontrast (aka Digi-Poti) - da der Arduino noch ein paar Pinne über hat, sollte sich Das So realisieren lassen - nur, ob's die große Masse übernimmt, Du also den Quasi-Standard setzen kannst, ist fraglich.
Es wird sich wohl kaum Einer einen Arduino als I2C-Slave ans Display hängen, wenn's die normalen I2C-PortExpander für billig Geld mit bereits angelötetem Display für kleines Geld zu kaufen gibt.

Ein nettes Projekt, aber ob's Aussicht auf Erfolg hat?

MfG

Wie gesagt, SoftPWM würde ich einfach mal, auch dem Interesse halber, ausprobieren. Aber halt dann wenn Zeit ist. Aber schon sehr wahrscheinlich, dass einem das auf die Füße fällt.

Man könnte den I2C-Portexpander auch durch so einen I2C-PWM-Chip ersetzen. Man müsste halt dann die Ausgänge von dem, die am Display hängen "digital" ansteuern, also mit 0 oder 256/100%. Aber Aufwandmässig natürlich auch völliger Unsinn.

Das mit dem Zusatzcontroller ist natürlich ein schönes Projekt, und wie ich das gelesen habe, hat SparkFun das auch schon irgendwie umgesetzt. Aber als reinen I2C-Displaytreiber zu teuer und zu übertrieben. Das wäre dann evtl. was, wenn man da deutlich mehr in die Richtung HMI darüber laufen lässt. Den Controller also z.B. die komplette Menüsteuerung inkl. Eingabemöglichkeiten überlässt und zwischen dem Displaycontroller und Master nur noch einzelne Werte austauscht.
Also so wie es z.B. die Nextion-Touch-Displays machen.

Wie gesagt: ich habe halt gesehen, dass das in so mancher Lib wohl zumindest "vorbereitet" ist, und mich hätte interessiert, ob es dann auch die Hardware dazu gibt.