mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C Unterschied einfacher LCD


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Hacker (Gast)
Datum:

Bewertung
-4 lesenswert
nicht 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.

Autor: Jack V. (jackv)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ist doch gar nicht Freitag?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hacker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Karl M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht 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?

: Bearbeitet durch User
Autor: Hacker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit diesem Display ?
Hat auch I2C.
Ebay-Artikel Nr. 223614674179

Autor: Hacker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hacker schrieb:
> Gibt es viele verschiede Arten von Schnittstellen
Gefühlte Hundert verschiedene.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht 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.
Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: Jack V. (jackv)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hacker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg R. (solar77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht 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
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hacker schrieb:
> Leider wird ein viel kleineres Display benötigt.

Das lässt sich finden, z.B.
Ebay-Artikel Nr. 132656407692

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

: Bearbeitet durch User
Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Hacker schrieb:
>> Leider wird ein viel kleineres Display benötigt.
>
> Das lässt sich finden, z.B.
> Ebay-Artikel Nr. 132656407692

OLED != LCD

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

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum selbst per Hand ansteuern:
http://www.dinceraydin.com/djlcdsim/djlcdsim.html

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: NichtWichtig (Gast)
Datum:

Bewertung
-1 lesenswert
nicht 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.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht 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
Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: spess53 (Gast)
Datum:

Bewertung
2 lesenswert
nicht 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

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.