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?
Wie wäre es mit diesem Display ? Hat auch I2C. https://www.ebay.de/itm/IIC-I2C-0-91-128-x-32-Weiss-OLED-LCD-Display-Modul-3-3V-5v-fur-AVR-Arduino/223614674179?hash=item3410792503:g:cwgAAOSwTj9dOR7H
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 ...
Beitrag #5966653 wurde vom Autor gelöscht.
Angehängte Dateien:
-
Bild.jpg
77 KB
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
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.
Nimm einen PCF8574 zur Ansteuerung. Gibt es in SMD, DIL und auch als fertiges Breakout. https://www.nxp.com/docs/en/data-sheet/PCF8574_PCF8574A.pdf https://eckstein-shop.de/PCF8574-IO-Expansion-Board?curr=EUR&gclid=EAIaIQobChMIh73PtefD5AIVkOJ3Ch3mqQoUEAQYASABEgIne_D_BwE https://www.reichelt.de/remote-8-bit-i-o-expander-for-i2c-bus-pdip-16-pcf-8574-n-p216402.html?&trstct=pos_4
:
Bearbeitet durch User
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
Hacker schrieb: > Leider wird ein viel kleineres Display benötigt. Das lässt sich finden, z.B. https://www.ebay.com/itm/132656407692
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.
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.
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
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.
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!
Klaus schrieb: > Zum selbst per Hand ansteuern: Wahnsinn, was manche Leute alles so programmieren. Wirklich brauchen tut das ja niemand, aber es ist cool.
NichtWichtig schrieb: > SPI ist hier um den Faktor 80! schneller als I2C Ja schön, aber das HD44780 Display kommt so schnell nicht mit.
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.
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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.