Announcement: there is an English version of this forum on Hallo, ich benutze im Moment als Anzeige einige HD44780 Displays für meine Bastelprojekte. Meine Googlesuche nach einem e-paper-mäßigem Ersatz war nicht sehr erfolgreich. Displays gibt es ja jede Menge, aber immer ohne Zeichensatz. Jedenfalls habe ich nichts weiter gefunden oder verstehe es nicht richtig. Ich brauche keine Graphik, mir würde ein numerische Anzeige mit 2..4 Zeilen reichen. Kennt vielleicht jemand zufällig eine (E-paper) Anzeige, die man einfach irgendwie seriell ansprechen kann ? Danke für sachdienliche Hinweise.
:
Bearbeitet durch User
Bot N. schrieb: > Kennt vielleicht jemand zufällig eine (E-paper) Anzeige, die man > einfach irgendwie seriell ansprechen kann ? Du meinst mit sowas wie bei Arduino üblich:"lcdPrint("Hallo");" Oder meinst du die Schnittstelle in Hardware? In Software, joa das geht mit allen wenn die Funktion existiert. In den meisten Library für "Grafik Displays" ist ein Standard font hinterlegt und mit den entsprechenden Funktionen kann damit ein Text ausgegeben werden. Für die Hardware Seite: wo soll das Display denn angeschlossen werden? Machst du was eigenes oder ist das von einem fertigen Gerät vorgegeben?
Kilo S. schrieb: > Du meinst mit sowas wie bei Arduino üblich:"lcdPrint("Hallo");" > Oder meinst du die Schnittstelle in Hardware? > In Software, joa das geht mit allen wenn die Funktion existiert. In den > meisten Library für "Grafik Displays" ist ein Standard font hinterlegt > und mit den entsprechenden Funktionen kann damit ein Text ausgegeben > werden. > > Für die Hardware Seite: wo soll das Display denn angeschlossen werden? > > Machst du was eigenes oder ist das von einem fertigen Gerät vorgegeben? Ja und nein. Ich habe meine HD44780 Displays via I2C angeschlossen und sende so die Daten und Steuerzeichen an das Display. Es sind eigene Boards die ich verwende , aber ich habe nur I2C,SPI oder RS232 (3.3V/5V) Schnittstellen und wenig Platz im Codebereich.
Das Problem ist erst mal, dass e-paper-Displays grafisch, also mit Pixeln gefüllt werden müssen. Das HD44780 braucht Texte als ASCII-Code. https://www.reichelt.de/de/de/shop/suche/e-paper?q=%2Fde%2Fde%2Fshop%2Fsuche%2Fe-paper&GROUPINDEX=0&search=e-paper&sort=article_price%20asc Zum Beispiel das billigste (15,50€ 128H×296V schwarz-weiß): https://www.waveshare.com/wiki/2.9inch_e-Paper_Module Schnittstelle SPI-Bus, mehrere Versorgungsspannungen Dazu gibt es dann Softwareunterstützung für Arduino, Raspi oder ESP32 Also einfach HD44780 raus und das hier rein wird nicht funktionieren.
Danke für die Antworten. Ist mir schon klar, dass man das nicht einfach tauschen kann. Dachte aber dass es vielleicht doch was gibt mit einem kleinen Controller der die Charakter macht und den man einfach via ASCII oder ähnliches ansteuern kann. Meine SW kann ich jederzeit ändern. Vielleicht muss ich doch selber was bauen.
Bot N. schrieb: > ich habe nur I2C,SPI oder RS232 (3.3V/5V) Schnittstellen und wenig Platz > im Codebereich. OK, sei mir nicht bös... 1.) 3,3-5V Pegel Serielle Schnittstelle = USART, !=RS232 2.) I2C/SPI sind sozusagen Standard Schnittstellen für Displays, da findet sich was. 3.) Codeoptimierung, genau das was ich gerade auch Versuche zu lernen. Ziel:10% des Speicher zu nutzen anstelle 18%. (2xSPI, GPIO, LCD Init + Nötigsten Funktionen, SPI Flashspeicher + Funktionen usw..) SPI:https://www.az-delivery.de/products/2-9-zoll-epaper-display I2C:https://www.rasppishop.de/19-Zoll-E-Paper-Modul-I2C-Bus-fuer-Temperatur-und-Luftfeuchtigkeitsmesser Das sind nur Beispiele, aber da findet sich noch mehr.
Bot N. schrieb: > Kennt vielleicht jemand zufällig eine (E-paper) Anzeige, die man > einfach irgendwie seriell ansprechen kann ? Ja, aber der Preis wird Dir nicht gefallen: https://www.reichelt.de/de/de/shop/produkt/e-paper_display_2_172x72_pixel_mit_intelligenz-156567
Du kannst ja einen Arduino, ESP8266, ESP32 oder sowas in der Art quasi als Treiber davor setzen und damit die alte Anzeige bitgenau emulieren. Prüfe aber vorher, wie oft und wie schnell sich deine Anzeige ändert. Ein full display refresh kann gerade bei den preiswerten Bastler-EPapern schon mal eine oder mehrere Sekunden dauern. Schlimmer ist es noch bei mehrfarbigen Anzeigen. Da haben wir gerade ein Projekt beerdigt, wo ein Kunde angefragt hatte, das 10-Zoll TFT eines Verkaufsautomaten gegen Epaper zu ersetzen, weil dort oft die Sonne voll draufsteht und das TFT kaum mehr lesbar ist. Das Ding (4 Farben) zappelt und flimmert fast 15 Sekunden, bevor das neue Bild erscheint ... wir versuchen es derzeit nochmal neu mit einem deutlich schnelleren monochromen Display (full refresh laut Datenblatt 4s), aber dazu muss die GUI geändert werden, weil diese bisher intensiv Farben genutzt hat. Der Refresh nur einzelner Regionen geht deutlich schneller, ist aber von der Software her nicht ganz trivial und die Displays, die das per Hardware unterstützen, sind deutlich teurer. Nicht umsonst kosten gute EBook-Reader mehrere hundert Euro. Apropos Sonne: EPaper sollen UV-sensibel sein. Einerseits werden teilweise die im Display integrierten Controller irritiert, andererseits soll es auch schädlich für die Lebensdauer der Anzeige-Partikel sein. Also evtl. UV-Filter vorsehen ...
Frank E. schrieb: > zappelt und flimmert fast 15 Sekunden, bevor das neue Bild erscheint Krass, das schaffe nicht mal ich! Und aktuell bin ich auch eher auf einem niedrigen stand was Programmierung angeht. Welche Mengen an Daten schickt ihr auf das Display das Aufbereiten und Transfer so lange brauchen? Gut, aktuell hab ich noch Probleme mit Lowercase Charakter, die werden einfach Uppercase dargestellt (aber immerhin nicht falsch!) bei dem Display der Fumot 25000. Aber Verzögerungen im Bildaufbau hab ich keine. Heftig, muss ja ne ausladende GUI sein.
> Apropos Sonne: EPaper sollen UV-sensibel sein.
Alles ist UV-Sensibel. Deshalb hat man da ja immer einen Filter vor.
Auch bei ganz normalen monochromen LCDs.
Wie sieht es denn da mit dem Temperaturbereich aus? Oder steht die
Verkaufskiste immer im warmen?
Vanye
:
Bearbeitet durch User
Kilo S. schrieb: > Welche Mengen an Daten schickt ihr auf das Display das Aufbereiten und > Transfer so lange brauchen? Der eigentlich Datentransfer geht per SPI für 900x480 Pixel mit je 8 Bit (wovon nur 4 genutzt werden) in weniger als einer Sekunde. Das Geflimmer veranstaltet tatsächlich der im Display integrierte Controller (sitzt ungefähr dort, wo das Flex-Kabel am Display endet).
Vanye R. schrieb: > Wie sieht es denn da mit dem Temperaturbereich aus? Oder steht die > Verkaufskiste immer im warmen? Der Automat ist in die Hauswand eingelassen. Von Hinten hat er es zumindest frostfrei (unbeheizter Büro-Nebenraum), die Front mit Display ist schon draussen. Extra geheizt wird die Kiste nicht. Aber es kam ja noch nicht zu einem Austausch. Das TFT macht problemlos -20 Grad mit.
:
Bearbeitet durch User
Ich hatte ein 2,9“ ePaper von Waveshare mit einem Arduino angesteuert. Waveshare liefert liefert passende Treiber, in allen möglichen Schriftgrössen. Das Flimmern hielt sich bei dem S/W Display mit ca 2-3s in Grenzen. Darstellung ist wirklich sehr schön. Beim partiellen Update ohne Flimmern verbleiben Schatten des alten Inhalts. Der Inhalt bleibt ohne Versorgungsspannung monatelang ohne Kontrastverlust stehen. Bezüglich UV-Schutz, schaue mal nach Museumsglas. Das Waveshare Display ist Portrait-Ausgerichtet. Will man es quer (landscape) beschreiben geht das auch, aber man braucht einen Bildspeicher. Könnte bei Arduino eng werden, je nach HW-Plattform. Für das 2,9“ waren es 3 kByte. Ich hatte vor 2 Jahren mal einen ausführlichen Test hier im Forum zum Thema serielle Displays im Sonnenlicht beschrieben.
Frank E. schrieb: > (sitzt ungefähr dort, wo das Flex-Kabel am Display endet). ;-) und leider meistens nur ein nicht näher spezifizierbarer (beschriftet) Silizium Block.
Kilo S. schrieb: > Frank E. schrieb: >> zappelt und flimmert fast 15 Sekunden, bevor das neue Bild erscheint > > Krass, das schaffe nicht mal ich! Dann guck dir einmal die Preisschilder beim Discounter an (z.B. Lidl schwarz/weiß/rot). Genau so sieht das aus, wenn der Bildinhalt neu geschrieben wird - gefühlt ewige Flackerei. Wulf D. schrieb: > Das Waveshare Display ist Portrait-Ausgerichtet. Will man es quer > (landscape) beschreiben geht das auch, aber man braucht einen > Bildspeicher. Könnte bei Arduino eng werden ... Mit einem ATmega328 vom Arduino Nano ist man da sicher fehl am Platz, aber der SAM3X8E ARM Cortex-M3 vom Arduino Due sollte das locker gebacken kriegen. Bei 296x128 B/W-Pixeln müsste der Bildinhalt in 5kByte Speicher passen. Kilo S. schrieb: > I2C:https://www.rasppishop.de/19-Zoll-E-Paper-Modul-I2C-Bus-fuer-Temperatur-und-Luftfeuchtigkeitsmesser Das Display ist kein Graphikdisplay, sondern hat 91 fest vorgegebene Segment, die die Anwendung eng begrenzen. Als Ersatz für ein HD44780 Display ist das wegen der Portrait Ausrichtung nicht geeignet und 2x16 oder 4x16 Zeichen bekommt man da schon gar nicht drauf angezeigt.
:
Bearbeitet durch User
> > Krass, das schaffe nicht mal ich! > Dann guck dir einmal die Preisschilder beim Discounter an (z.B. Lidl Ich hab auch schon mit kleineren Oled im 1-2" Bereich rum gespielt und hab da Updateraten unter eine Sekunde, aber schon noch leicht nervig. Aber bedenke das er oben von 10" schreibt und noch von Farbe! Andererseits ich hab seit ein paar Jahren ein Boox Note Air mit dem ich EXTREM zufrieden bin. Das braucht zum umblaettern in guter Qualitaet sicher unter einer Sekunde, und es kann mit 10-15Bildern/s auch Videos auf Youtube darstellen wenn man "schlechte Qualitaet" also Artefakte akzeptiert. Farbige ePaper sind deutlich langsamer. So langsam das ich sowas nicht haben will! Ich denke mal sinnvoll ist sowas nur mit graustufen ePaper das man segmentweise updaten kann und eine angepasste Bedienoberflaeche die in Segmentgrenzen arbeitet. Man muss also vorher gut die Technik verstehen und designt dann danach die Oberflaeche. Aber wenn ich mir die Kaffemaschine in der Firma mit TFT anschaue wie ruckelig, lahm und komisch da die Oberflaeche designt/programmiert ist dann scheint man sich heute auch mit Abfall unter die Kunden trauen zu koennen und es wird trotzdem gekauft. Erstaunlich! Vanye
Kilo S. schrieb: > SPI: https://www.az-delivery.de/products/2-9-zoll-epaper-display Blödes Beispiel. Woanders wird für die verschiedenen Varianten dieses Displays aktuell ein Preis von 17.49€ angezeigt. https://de.aliexpress.com/item/1005006297023539.html
:
Bearbeitet durch User
Habe die Beiträge mit Interesse gelesen. Da anscheinend sehr viel Wissen zu E-Paper vorhanden ist , das mir leider bisher fehlt, möchte ich bitte folgende Frage stellen: Wenn ich eine kleine, hauptsächlich numerische/alphanumerische Anzeigeeinheit mit z.B dem Waveshare 1,54" 200x200 E-Ink E-Paper Display erstellen wollen würde, welche kleinste Arduino, ESP oder ähnliches würde denn nötig sein? Ansteuerung der Anzeige mit UART, SPI oder I2C. Sonst würde nichts weiter brauchen. Kann da bitte jemand helfen und was "schönes" dazu sagen?
:
Bearbeitet durch User
Bot N. schrieb: > Wenn ich eine kleine, hauptsächlich numerische/alphanumerische > Anzeigeeinheit mit z.B dem Waveshare 1,54" 200x200 E-Ink E-Paper Display > erstellen wollen würde, welche kleinste Arduino, ESP oder ähnliches > würde denn nötig sein? Was meinst du mit "klein"? Mehrere Beispiele mit einem Arduino Uno (ATmega328) und dem 1.54" 200x200 TZT MH-ET LIVE Display laufen wohl problemlos mit der Waveshare Bibliothek. Ein Arduino Nano sollte es dann genauso tun. Und wenn dir der µC zu klein wird, weil deine Anwendung einen größeren µC benötigt, guckst du in deiner Bastelkiste z.B. nach einem ESP. Fang einfach an. https://elektro.turanis.de/html/prj330/index.html https://www.tztstore.com/goods/show-7858.html
:
Bearbeitet durch User
Bot N. schrieb: > welche kleinste Arduino, ESP oder ähnliches > würde denn nötig sein? Dafür kann ein ATtiny85 reichen. Für einen 5x8 Pixel Zeichensatz brauchst du ungefähr 500 Bytes Flash und dann noch ca. 200 Bytes für den Programmcode zum Ausgeben von Text. Der ATtiny85 hat 8 kB Flash. Die Grafik-Bibliothek von Adafruit ist größer und braucht RAM als Puffer für das ganze Display, aber die muss man ja nicht benutzen. 5 Bytes pro Buchstabe an die richtige Adresse zu schreiben, ist kein Hexenwerk.
:
Bearbeitet durch User
Bot N. schrieb: > Kann da bitte jemand helfen und was "schönes" dazu sagen? Sehr schön ist die aus allen Sichtwinkeln kontrastreiche Anzeige. Weniger schön ist das umständliche beschreiben: man muss jedesmal vorher löschen, bevor man einen Text ändert. Letztlich erfordert das ein anderes Anzeigekonzept in deiner Software. Musst du beurteilen, wieviel Aufwand das bedeutet. Und richtig, zur Not tut es ein Attiny85 für das kleine quadratische Display.
Rainer W. schrieb: > Das Display ist kein Graphikdisplay Das waren ja auch nur Beispiele, da ging's mir drum das man Displays mit allen möglichen Schnittstellen findet. Rainer W. schrieb: > Dann guck dir einmal die Preisschilder beim Discounter an (z.B. Lidl > schwarz/weiß/rot). Genau so sieht das aus, wenn der Bildinhalt neu > geschrieben wird - gefühlt ewige Flackerei. So ein Dingen hab ich hier! Hab ich irgendwann mal in der Stadt gefunden, Grau/Schwarz glaube. Ich such das dingelchen mal raus!
Kilo S. schrieb: > So ein Dingen hab ich hier! > Hab ich irgendwann mal in der Stadt gefunden, Grau/Schwarz glaube. > > Ich such das dingelchen mal raus! Für einige davon gibts Open Source Firmware, die man über interne Testpunkte einspielen kann. Ohne dem - keine Chance. Vielleicht hast du ja Glück und dein Typ passt.
Frank E. schrieb: > Ohne dem - keine Chance. Ich meine sogar deshalb ist es in die "Schauen vielleicht findet sich später was dazu" Box geflogen. Wird mir die Tage in die Finger fallen denke ich.
Danke sehr für die vielen, teils sehr hilfreichen Beiträge. Nachdem ich mir dann einige Referenzdesigns und Codes ansehen konnte, werde ich es wohl mal selber mit einem MSP430 für diese Displays versuchen. Die CPUs kenne ich und habe da erheblich bessere Tools zum Code erzeugen und Debuggen.
Jetzt muss ich nochmals ganz dumm nachfragen zum Waveshare 1.54" E-Paper Display. Es irritiert mich ungemein, dass die Schnittstelle SPI sein soll. Für mich ist es kein I2C (trotz SCL und SCL Bezeichnung und Datenblatt), aber auch keine klassische SPI Schnittstelle. Muss man da mit Bitbang arbeiten? Oder sehe ich das falsch ? Zu > MSP430 haben halt leider oft erbärmlich wenig RAM. Aber nicht immer, für diesen Zweck sollten eine MSP430 reichen.
:
Bearbeitet durch User
Bot N. schrieb: > Jetzt muss ich nochmals ganz dumm nachfragen zum Waveshare 1.54" E-Paper > Display. > > Es irritiert mich ungemein, dass die Schnittstelle SPI sein soll. > Für mich ist es kein I2C (trotz SCL und SCL Bezeichnung und Datenblatt), > aber auch keine klassische SPI Schnittstelle. Muss man da mit Bitbang > arbeiten? Oder sehe ich das falsch ? Du siehst das falsch. Was dich irritiert, ist das Fehlen von MISO. Das ist aber prinzipiell kein Problem. Das Display ist halt write-only. Deswegen empfiehlt es sich ja, einen Prozessor mit hinreichend RAM zu nehmen, weil Du nichts zurücklesen kannst. Und dass Du noch weitere Leitungen hast (DC, Reset, Busy), ist auch nicht weiter schlimm. fchk
Bot N. schrieb: > Jetzt muss ich nochmals ganz dumm nachfragen zum Waveshare 1.54" E-Paper > Display. Welches genau? Also der Link zu deinem exakten Modell. Ich finde die anscheinend nur mit SPI Schnittstelle.
Angehängte Dateien:
Danke für den Hinweis, aber ich habe in einem Datenblatt gelesen, das man auch lesen können muss. Bild ist aus "1.5inch e-Paper V2 Specifications"
:
Bearbeitet durch User
Bot N. schrieb: > Danke für den Hinweis, aber ich habe in einem Datenblatt gelesen, das > man auch lesen können muss. > > Bild ist aus "1.5inch e-Paper V2 Specifications" ok, ich sehe es. Kein Problem. Verbinde MISO von Deinem MSP direkt mit SDA des Displays. Verbinde MOSI von deinem MSP über einen ca 1k Ohm Widerstand mit MISO (und damit mit SDA des Displays). Wenn Du jetzt was sendest, bekommst Du die Sendedaten wieder empfangen. Wenn Du was liest, dann musst Du aber auch immer was senden - so ist das bei SPI halt. Aber durch den 1k Widerstand kann das Display den von Dir gesendeten Pegel problemlos überschreiben, und Du bekommst Deine Daten. Das wird beispielsweise bei Microwire-EEPROMS (93C46/56/66/76/86) an Netzwerk oder USB-Chips auch oft gemacht. fchk
Danke , aber da wäre noch D/C bei 4 wire SPI. Man müsste dann wohl auf 3 wire SPI gehen. Nachtrag: Bei 3 wire SPI müsste der Master 9 bit können, geht aber beim MSP430 nicht. Nur 7 und 8 bit. Entweder man braucht wirklich nicht lesen , andernfalls bleibt nur bitbang. Wie macht das der Arduino o.ä. ?
:
Bearbeitet durch User
Bot N. schrieb: > Danke , aber da wäre noch D/C bei 4 wire SPI. Man müsste dann wohl auf > 3 wire SPI gehen. Nö. Du musst einfach nur DC vor einer SPI-Transaktion passend setzen. Gar kein Problem. Solltest Du hinbekommen. > Nachtrag: Bei 3 wire SPI müsste der Master 9 bit können, geht aber beim > MSP430 nicht. Nur 7 und 8 bit. > Entweder man braucht wirklich nicht lesen , andernfalls bleibt nur > bitbang. Wie macht das der Arduino o.ä. ? Wenn Du im Wiki schaust: die lesen offenbar nichts zurück. SDA wird dort immer nur mit MOSI verbunden. fchk
Frank K. schrieb: > Nö. Du musst einfach nur DC vor einer SPI-Transaktion passend setzen. > Geht das , müßte ja synchron sein , oder? Siehe Bild oben.
Bot N. schrieb: > Frank K. schrieb: >> Nö. Du musst einfach nur DC vor einer SPI-Transaktion passend setzen. >> > > Geht das , müßte ja synchron sein , oder? Siehe Bild oben. Ja, das machen alle so. Du musst halt nur wissen, wann das Schieberegister des SPI leer ist. Das sollte machbar sein. fchk
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.