Forum: Mikrocontroller und Digitale Elektronik I2C Unterschied einfacher LCD


von Hacker (Gast)


Lesenswert?

Hallo zusammen,

ich suche grad nach einer geeigneten Anzeige für meine 
Arduino-Anwendung.
Ich hab bereits ein Display zuhause rumliegen allerding ist dieses zu 
groß für meine Anwendung:

https://www.conrad.de/de/p/joy-it-sbc-lcd16x2-display-modul-6-6-cm-2-6-zoll-16-x-2-pixel-passend-fuer-raspberry-pi-arduino-banana-pi-cubieboar-1503825.html

Leider wird ein viel kleineres Display benötigt.
Unter I2C-Display finde ich kein Display das klein genug ist...(Max. 
4,5cm breit darf es sein)
Nun ist meine Frage ob man das ganze nicht mit einem einfachen 
LC-Display realisieren kann.
Ich hab das hier gefunden und es würde von der Größe passen.

https://www.conrad.de/de/p/lc-display-schwarz-gelb-gruen-b-x-h-x-t-40-x-20-x-10-8-mm-eadips082-hnled-181705.html

Nun ist meine Frage ob man auch auf so einem Display ohne viel Aufwand 
etwas anzeigen lassen kann.
Leider habe ich noch nicht genau verstanden was ein I2C-Display ist und 
wie es sich von einem einfach LCD unterscheidet.

Wo ist der Unterschied zum I2C-Display?
Und wie lass ich etwas durch meinen Arduino auf dem LCD anzeigen?

Danke.

von Jack V. (jackv)


Lesenswert?

Ist doch gar nicht Freitag?

von Einer K. (Gast)


Lesenswert?

Hacker schrieb:
> Leider habe ich noch nicht genau verstanden was ein I2C-Display ist und
> wie es sich von einem einfach LCD unterscheidet.

I2C ist eine Schnittstelle!
Die Verbindung zum steuernden µC.

von Hacker (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> I2C ist eine Schnittstelle

Ah ok dann hab ich das ganze falsch verstanden.

Kann man denn vom Arduino etwas auf einem LCD anzeigen, welches keine 
I2C-Schnittstelle besitzt?

von Karl M. (Gast)


Lesenswert?

Hacker schrieb:
> Kann man denn vom Arduino etwas auf einem LCD anzeigen, welches keine
> I2C-Schnittstelle besitzt?

Klar, wenn man programmieren kann und das zugehörige Datenblatt lesen 
kann und es auch versteht.

von Einer K. (Gast)


Lesenswert?

Ja!
(wenn dein Arduino die entsprechende Schnittstelle kann)

Nein!
(wenn dein Arduino die entsprechende Schnittstelle nicht kann)

Logisch, oder?
So logisch, so dass es schon unglaubwürdig ist?

Oder zu einfach?

von Hacker (Gast)


Lesenswert?

Karl M. schrieb:
> Klar, wenn man programmieren kann und das zugehörige Datenblatt lesen
> kann und es auch versteht.

Wie groß ist der Mehraufwand?
Ich finde mit einer I2C-Schnittstelle ist es ziemlich einfach einen Text 
auf das Display zu programmieren.

Wie sieht es bei anderen LCDs aus?
Gibt es viele verschiede Arten von Schnittstellen und gibt es eine 
Schnittstelle die vergleichbar leicht mit dem Arduino zu bedienen ist?

von Stefan (Gast)


Lesenswert?


von Hacker (Gast)


Lesenswert?

Stefan schrieb:
> Wie wäre es mit diesem Display ?
> Hat auch I2C.
> Ebay-Artikel Nr. 223614674179

Das wäre schon eher was.
Vielleicht muss ich mich von den üblichen Verkaufsseiten trennen um bei 
I2C zu bleiben...

von Einer K. (Gast)


Lesenswert?

Hacker schrieb:
> Gibt es viele verschiede Arten von Schnittstellen
Gefühlte Hundert verschiedene.

von Jens G. (jensig)


Lesenswert?

Arduino Fanboy D. (ufuf)

>Ja!
>(wenn dein Arduino die entsprechende Schnittstelle kann)

>Nein!
>(wenn dein Arduino die entsprechende Schnittstelle nicht kann)

>Logisch, oder?
>Zu logisch, so dass es schon unglaubwürdig ist?

>Oder zu einfach?

Vielleicht eher zu primitiv, diese Aussage, und damit vollkommen 
unglaubwürdig.
Wer programmieren kann, der kann auch dieses LCD ansprechen, welches ja 
die HD44780-Sprache versteht (übrigens auch das erstgenannte). 
Unabhängig von Arduino, oder gar einer speziellen Schnittstelle. Das 
kann man mit jedem Ding zu Fuß machen, bei dem man ein paar Port-Pins 
frei hat, und ansprechen kann ...

Warum brauchen die Leute nur für jeden Kack eine spezielle 
Schnittstelle? Ist zwar ganz praktisch, aber deren Fehlen bedeutet 
nicht, daß man es auch zu Fuß machen könnte ...

Beitrag #5966653 wurde vom Autor gelöscht.
von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Hacker schrieb:
> ich suche grad nach einer geeigneten Anzeige für meine
> Arduino-Anwendung.
> Leider wird ein viel kleineres Display benötigt.
> Unter I2C-Display finde ich kein Display das klein genug ist...(Max.
> 4,5cm breit darf es sein)
> Nun ist meine Frage ob man das ganze nicht mit einem einfachen

http://domoticx.com/arduino-library-lcd5110-nokia-5110-lcd/

Display hat 4,5cm in der Breite und macht so 6 Zeilen a 14 Zeichen

von Jack V. (jackv)


Lesenswert?

Da’s ja doch ernstgemeint zu sein scheint (wenngleich sich mir nicht 
ganz erschließt, dass man nicht weiß, was I2C sein könnte, wenn man’s 
doch benutzt …): es gibt auch I2C-„Backpack“-Platinen für 
HD44780-kompatible Displays.

Man kann die Displays mit diesem Controller zwar problemlos manuell 
ansteuern (tatsächlich könnte™ man sie auch mit einer Handvoll 
entprellter Taster benutzen), und es gibt auch Libs, aber das braucht 
selbst im 4-Bit-Modus erheblich viele Pins.

von MaWin (Gast)


Lesenswert?

Hacker schrieb:
> Wo ist der Unterschied zum I2C-Display?

In der Schnittstelle.

Es hat eine mit den üblichen Arduino-Liraries kompatible HD44780 
Schnittstelle, braucht dafür aber zumindest 6 Pins.

Hacker schrieb:
> ob man das ganze nicht mit einem einfachen LC-Display

Dein herausgesuchtes ist mitnchten ein einfaches LCD. Einfach sind 
nackte Gläser ohne Elektronik, die benötigen halt einen uC mit LCD 
Treiber wie ATmega169. Die haben dann den Vorteil, so wenig Strom zu 
brauchen, daß man sogar langen Batteriebetrieb haben kann.

https://www.mouser.de/datasheet/2/244/LCD-S401M16KR-81359.pdf

von Hacker (Gast)


Lesenswert?

Ich denke ich bleibe dann besser bei der I2C-Schnittstelle jetzt da ich 
weiß, dass es auch kleinere Varianten gibt.

Trotzdem danke,
Sehr hilfreiche Beiträge dabei.

von Jörg R. (solar77)


Lesenswert?


: Bearbeitet durch User
von Maxim B. (max182)


Lesenswert?

Hacker schrieb:
> Wo ist der Unterschied zum I2C-Display?

Auf dem ersten ist noch eine Platine mit IO-Port-IC. Ansonsten solltest 
du alles wie mit einem LCD in 4-bit-Mode machen, nur kommt dazwischen 
noch 100-kbit-I2C.
Besser auch graphische nehmen: Aufwand ist praktisch gleich wie mit 
Symbol-LCD, aber du bist nicht an bestimmten Zeichensatz gebunden.

Noch eine Option: statt I2c_Porterweiterung SPI-Porterweiterung zu 
nehmen. So sind z.B. MCP23008 und MCP23S08, genau wie auch MCP23017 und 
MCP23S17, beinahe identisch, nur bei ersten (ohne S) I2C, bei den 
zweiten (mit S) SPI-Interface. Mit SPI geht es deutlich schneller, als 
mit I2C.

Jörg R. schrieb:
> Nimm einen PCF8574 zur Ansteuerung.

Lieber MCP23008, PCF8574 kann nur 100 kbit.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Hacker schrieb:
> Leider wird ein viel kleineres Display benötigt.

Das lässt sich finden, z.B.
https://www.ebay.com/itm/132656407692

von Stefan F. (Gast)


Lesenswert?

Hacker schrieb:
> Unter I2C-Display finde ich kein Display das klein genug ist..

https://www.amazon.de/AZDelivery-Display-Arduino-Raspberry-Gratis/dp/B07BY6QN7Q

Klein genug?

Im Gegensatz zum Anbieter empfehle ich Pegelwandler, falls dein 
Mikrocontroller 5V Signalpegel hat.

Nachtrag: Hoppla, mein Namensvetter hat das auch schon vorgeschlagen.

von NichtWichtig (Gast)


Lesenswert?

Maxim B. schrieb:
> Lieber MCP23008, PCF8574 kann nur 100 kbit.

:-))

Mein MCP23S17 steuert ein 128x64 GLCD mit 8MHz SPI clock vom BluePill 
aus befeuert.
Bis auf das E alle LCD IOs am MCP, Updatezeit komplettes LCD < 7ms.

von Joachim B. (jar)


Lesenswert?

Wolfgang schrieb:
> Hacker schrieb:
>> Leider wird ein viel kleineres Display benötigt.
>
> Das lässt sich finden, z.B.
> https://www.ebay.com/itm/132656407692

OLED != LCD

OLED verbraucht die Leuchtschicht, ist schlecht für dauernd ON

von Stefan F. (Gast)


Lesenswert?

Joachim B. schrieb:
> OLED verbraucht die Leuchtschicht, ist schlecht für dauernd ON

Ja, gut dass du darauf hinweist. Diverse Hersteller von Küchen. und 
Unterhaltungselektronik scheißen darauf, aber wir wollen es ja besser 
machen. So eine mittlere Nutzungsdauer von z.B. 20.000 Stunden ist eben 
doch schneller zuende, als unser eigenes Leben.

von Klaus (Gast)


Lesenswert?

Zum selbst per Hand ansteuern:
http://www.dinceraydin.com/djlcdsim/djlcdsim.html

von Maxim B. (max182)


Lesenswert?

NichtWichtig schrieb:
> Mein MCP23S17 steuert ein 128x64 GLCD mit 8MHz SPI clock vom BluePill
> aus befeuert.

Das ist natürlich schön. Aber SPI verbraucht 4 Linien und I2C nur 2. Da 
LCD sowieso nicht besonders eilig ist, bleibt hier I2C wohl bessere Wahl 
als SPI, es sei denn, in System gibt es andere SPI-Geräte.

Graphische 128x64 habe ich selber mit MCP23S17 gemacht. So schnell ist 
das auch nicht: bei jedem Befehl braucht MCP23S17 3 bytes, und für 1 
byte Daten für 128x64 sollten mehrere Befehle kommen:
1. Daten auf Datenport.
2. Steuerung mit E=0
3. Steuerung mit E=1
4. Steuerung mit E=0.
4x3 = 12 bytes per SPI

Wenn man Daten lesen will (um zu modifizieren, kommen noch mehr Befehle, 
da Datenport als Eingang und danach zurück als Ausgang geschaltet sein 
muß, und E sollte zweimal in Bewegung kommen. Hier sind das 24 bytes.

Wenn ein Zeichen aus 5 Linien nicht gerade an Bytelinie sein sollte, 
sondern mit Verschiebung, dann sollten 2 Reihen gelesen, modifiziert und 
zurückgeschrieben werden:
1. y-Befehl, 12 bytes
2. byte lesen, 24 bytes
3. y-Befehl wieder, 12 bytes
3. byte zurück, 12 bytes
 - so 5 mal.
Dann das Gleiche für untere Bytereihe.
Insgesamt sollte man für ein Zeichen 600 bytes per SPI schicken. Ohne 
Zwischenrechnungen zu berücksichtigen, bedeutet das mit F_SPI=8MHz etwa 
650 us pro Zeichen. Für eine volle Zeile sind das 5,2 ms, für 8 Zeilen 
entsprechend 42 ms.

Natürlich wenn man nur gerade Zeichenzeilen benutzt, kommt das etwas 
schneller, 60 bytes und ~65 us pro Zeichen. Aber dann ist man von 
LCD-Struktur abhängig, dann ist das keine echte Graphik mehr.

von NichtWichtig (Gast)


Lesenswert?

SPI ist hier um den Faktor 80! schneller als I2C

Und der LCD EnablePin kommt als GPIO vom STM32
Solangt es am Beginn der Zeile 1 4Byte-SPI Cmd zu senden und 
anschließend 3 Byte Befehle bis 63.
Kein 8ms für das komplette LCD, inclusive Lesen des Statuswords beim 
Adressieren des LCDs.


Aber stimmt, die verfügbaren Pins muß man sich natürlich zuzurecht legen 
wie man sie braucht.

Wer die SPI Pins anderwertig nutzen muß nimmt eben I2C.

von Joachim B. (jar)


Lesenswert?

NichtWichtig schrieb:
> SPI ist hier um den Faktor 80! schneller als I2C

ich möchte den sehen der auf dem LCD so schnell lesen kann!

von Stefan F. (Gast)


Lesenswert?

Klaus schrieb:
> Zum selbst per Hand ansteuern:

Wahnsinn, was manche Leute alles so programmieren. Wirklich brauchen tut 
das ja niemand, aber es ist cool.

von Stefan F. (Gast)


Lesenswert?

NichtWichtig schrieb:
> SPI ist hier um den Faktor 80! schneller als I2C

Ja schön, aber das HD44780 Display kommt so schnell nicht mit.

von NichtWichtig (Gast)


Lesenswert?

Ich finde es angenehm das ich das LCD alle 500ms flott updaten kann.
Versuche mit der HAL interrupt gesteuert zuzugreifen lieferten 
schlechtere Zeiten.
Die Anbindung mit dem MCP23S17 scheint beim Timing das LCD fast 
auszureizen, dauert ein Schreibzugriff ca. 10µS. Das verkraftet das LCD 
(aus den 90ern) gerade so und die 2 x 8 Zeilen (je 64Bytes) lassen sich 
AmStück zügig updaten.

Es wird eine Menustruktur kommen welche per Encoder bedient werden soll, 
da wird die Refreshrate sicher höher werden als 2/s.

Der MCP bietet zudem verschieden smarte Ansteuerungen um Einzel- oder 
Doppelbytes zu bedienen, je nach UseCase, das spart Zeit.


So paßt jeder sein Zeugs an seine Anforderungen an, alles gut.

von Joachim B. (jar)


Lesenswert?

Stefanus F. schrieb:
> So eine mittlere Nutzungsdauer von z.B. 20.000 Stunden ist eben
> doch schneller zuende, als unser eigenes Leben.

2,3 Jahre :) manchmal weniger.

von Karl B. (gustav)


Lesenswert?

Jack V. schrieb:
> es gibt auch I2C-„Backpack“-Platinen für
> HD44780-kompatible Displays.

Jo,
aber die will er ja nicht.
Abgesehen davon ist die Routine anzupassen.

Beitrag "Re: Anfänger Will ATtiny2313 mit Display uber I2C verbinden"

ciao
gustav

von Maxim B. (max182)


Lesenswert?

NichtWichtig schrieb:
> Die Anbindung mit dem MCP23S17 scheint beim Timing das LCD fast
> auszureizen, dauert ein Schreibzugriff ca. 10µS.

LCD braucht eigentlich für die meisten Operationen ca. 40-45 us. Für 
einige Operationen 1,5 - 2 ms.

Benutzt man so etwas wie PCF8574, dann ist das 4-bit-Modus. D.h. man 
braucht pro Befehl 6x byte schicken. PCF8574 kann nur 100 kHz. D.h. für 
6 bytes wird ca. 550 us gebraucht. Deshalb habe ich MCP23008 empfohlen: 
hier sind 1,7 MHz möglich. Somit dauern 6 bytes nur ca. 33 us. So wird 
LCD nicht noch zusätzlich abgebremst.

: Bearbeitet durch User
von NichtWichtig (Gast)


Lesenswert?

Das nicht jeder Zugriff so schnell geht ist klar, jedoch das glönige 
sequenzielle Schreiben von Bytes in einer Row klappt fehlerfrei bei 
10µs/Byte.
Increment macht das LCD ja selbst und braucht nicht jedes mal ne Adresse 
und nach 63 kommt von alleine wieder 0 ;)

Hatte ich bei der HAL_SPI_Transmit() anfangs 1ms als timeout angegeben 
kamen tatsächlich Pixelfehler vor.
Dank LA+Scope konnte ich das ausfindig machen und in der Tat war SysTick 
der Schuldige wenn's überlief, das ergab zu kurze (6-8µs) SPI Zugriffe 
und das Byte wurde vom LCD ignoriert obwohl sauber Daten an allen Inputs 
anlagen.

von Maxim B. (max182)


Lesenswert?

NichtWichtig schrieb:
> jedoch das glönige
> sequenzielle Schreiben von Bytes in einer Row klappt fehlerfrei bei
> 10µs/Byte.

Daran glaube ich nicht.
Ich habe einmal eine Probe gemacht: LCD mit busy und mit delay. 
Busy-Variante hat nichts gebracht: Geschwindigkeit blieb etwa gleich, 39 
us / Befehl.

von NichtWichtig (Gast)


Lesenswert?

Anbei mal datasheet: 
https://www.lcd-module.de/eng/pdf/zubehoer/hd61202.pdf

Cycle time for E: 1000ns (Seite 29)

Da liege ich mit 10µs Faktor 10 drunter.

Und ich werte weder BUSY flag aus noch lese ich das LCD sondern halte 
eine 100% bitmap im Speicher welche dann komplett geschrieben wird.
Oder halt, nur die Zeilen welche verändert wurden.

Da ich immer 64 Bytes pro Zeile schreibe brauche ich den X Wert (1aus8) 
nur einmal am Anfang setzen.
Dann kommt ein 4 Byte SPI mit Daten für Port A (LCD-Daten) und Port B 
(LCD Ctrl)
Und dann eine loop von 1 bis <64 mit 3 Byte SPI Command nur Port A

Das LCD incrementiert intern die Position und steht am Ender wieder bei 
0.

Das Schreiben der Zeilennummer ist in der Tat häßlich, muß man den Port 
A vom MCP als Input setzen, LCD lesen und dann Port A wieder auf Output 
setzen, da sind dann 50µs durch, ab dann beginnt das Schreiben der 
Pixelbytes 1 x 4 SPI Bytes + 63 x 3 SPI Bytes.
Und das E wird als gpio vom STM bedient, da darf man nichtmal optimieren 
sonst wird das nix mit 450ns.
 E setzen
 NSS rücksetzen
 E rücksetzen
Macht in Summe ~700µs - ich les das grad vom Rigol Scope ab.

Scheint so als ob das LCD mit dem MCP wunderbar harmoniert.
Hab dann noch ein paar versuche mit anderen PI clock rates gemacht doch 
der kürzeste Zyklus ist bei 8MHz.

von spess53 (Gast)


Lesenswert?

Hi

@ NichtWichtig (Gast) Du hast aber schon bemerkt, worum es hier geht?

Textdisplay und I2C. Was sollen da deine Beiträge zu Grafikdisplay und 
SPI?

MfG Spess

von Maxim B. (max182)


Lesenswert?

Ich habe gerade chinesische LCD 4x20 per mcp23008 geschaltet, mit 
Prog-I2C. Übertragung ist derart langsam, daß die Verzögerungen nach 
Daten- und Command-Übertragung nicht notwendig sind. Byte (6x3 I2C-byte) 
braucht 313 us, d.h. ~17,4 us pro I2C-byte. Das ist schon etwa die 
Grenze.

von NichtWichtig (Gast)


Lesenswert?

Und wo ist da jetzt der Flaschenhals?
LCD, µC oder i2c?

von S. R. (svenska)


Lesenswert?

Jens G. schrieb:
> Ist zwar ganz praktisch, aber deren Fehlen bedeutet
> nicht, daß man es auch zu Fuß machen könnte ...

Ich hab hier ein schönes 640x480 LVDS-Display.
Magst du mir das bitte an einen AVR anschließen?
Ich kann das zu Fuß (also ohne passende Schnittstelle) nicht.

Stefanus F. schrieb:
> So eine mittlere Nutzungsdauer von z.B. 20.000 Stunden ist eben
> doch schneller zuende, als unser eigenes Leben.

Einbrennen ist auch ein relevantes Problem. So relevant, dass man 
Android dafür patchen muss(te), sonst bleibt die Statusleiste auch bei 
Vollbildanwendungen dauerhaft sichtbar... das iPhone verschiebt diverse 
Elemente regelmäßig um ein Pixel, damit das nicht so deutlich ist.

Nee, die großen Hersteller kochen auch nur mit Wasser. Mit Zugang zu 
besserem Wasser und manchmal extrem hohen (unnützen) Aufwand, aber es 
bleibt Wasser. Mit Kalkresten im Wasserkocher und Schimmel, wenn's 
schlecht läuft.

Bitte 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
Noch kein Account? Hier anmelden.