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 ?
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?
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.
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.
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..)
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 ...
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.
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).
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.
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.
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.
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.
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.
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!
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?
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.htmlhttps://www.tztstore.com/goods/show-7858.html
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.
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.
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.
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.
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.
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.
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.
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.ä. ?
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.
