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.
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.
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?
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.
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?
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?
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...
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 ...
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 einfachenhttp://domoticx.com/arduino-library-lcd5110-nokia-5110-lcd/
Display hat 4,5cm in der Breite und macht so 6 Zeilen a 14 Zeichen
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.
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
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.
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.
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.
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.
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.
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.
Klaus schrieb:> Zum selbst per Hand ansteuern:
Wahnsinn, was manche Leute alles so programmieren. Wirklich brauchen tut
das ja niemand, aber es ist cool.
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.
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.
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.
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.
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.
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.
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
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.
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.
