https://www.waveshare.com/wiki/1.54inch_e-Paper_Module Ich möchte endlich mal das Display (mit Arduino) ansteuern und habe erst mal Literatur gesucht. Anscheinend hat sich mit der Anschlussbelegung noch kein Standard gebildet, jeder macht es anders. Das Display hat einen SPI-Bus, wobei nur die Datenrichtung zum Display hin benutzt wird. Rückmeldung per Hardware über eine Busy-Leitung, insgesamt sind 6 Portpins belegt, mit Data/Control, ChipSelect und Hardware-Reset. Das Display von Waveshare scheint mit mit dem hier identisch zu sein: https://www.good-display.com/product/208.html demnach ist der Controller ein SSD1681 von Solomon Systech. https://www.buydisplay.com/download/ic/SSD1681.pdf Hier im Forum wurden schon andere Typen genannt. Unten auf der Seite gibt es auch eine Software für Arduino. Sehr seltsam finde ich, dass SPI-Daten und Clock am Arduino vertauscht sind. //IO settings int BUSY_Pin = 8; int RES_Pin = 9; int DC_Pin = 10; int CS_Pin = 11; int SCK_Pin = 12; (=Arduino MISO) int SDI_Pin = 13; (=Arduino SCK) #define EPD_W21_MOSI_0 digitalWrite(SDI_Pin,LOW) #define EPD_W21_MOSI_1 digitalWrite(SDI_Pin,HIGH) #define EPD_W21_CLK_0 digitalWrite(SCK_Pin,LOW) #define EPD_W21_CLK_1 digitalWrite(SCK_Pin,HIGH) Die defines wären für SPI ja unnötig, wenn man die Arduino-SPI-Hardware benutzen würden, wieso machen die Bit-Banging? Hier anders belegt: https://www.waveshare.com/wiki/E-Paper_Driver_HAT#Hardware_connection_2 DIN D11 CLK D13 CS D10 DC D9 RST D8 BUSY D7 hier nochmal anders https://forum.arduino.cc/t/waveshare-e-paper-displays-with-spi/467865 BUSY->D6(MISO), RST->D4, DC->D3, CS->D8(SS), CLK->D5(SCK), DIN->D7(MOSI) wenigstens sind Clock und Daten hier anscheinend korrekt angeschlossen, wie sind diese "D" am Arduino definiert? Pin 8-13 sind Port B 0-5 Im Controller-Datenblatt wird dieses Ablaufdiagramm gezeigt. Ähnlich wie z.B. HD44780 mit Zeitverzögerungen, die man vermutlich einhalten muss. Die Tabelle der einzelnen Befehle ist reichlich unübersichtlich. Mal weitersehen, kann mir schon jemand dazu etwas sagen?
Angehängte Dateien:
-
Flussdiagramm.png
20 KB
:
Bearbeitet durch User
Zu e-paper muß man gegenüber normalen LCD beachten, dass die Spannungen temperaturabhängig eingestellt werden müssen. Das macht weitgehend der Controller, muss aber dazu aufgefordert werden, siehe Flussdiagramm oben. Der im Waveshare-Wiki verlinkte "ZinggJM" ist recht aktiv: https://forum.arduino.cc/t/initialization-problems-with-the-v2-waveshare-e-paper-display/642458 Display Library example for SPI e-paper panels from Dalian Good Display and boards from Waveshare (hier wird explizit Good-Display und Waveshare genannt, scheint also identisch zu sein): https://github.com/ZinggJM/GxEPD2/blob/master/examples/GxEPD2_Example/GxEPD2_Example.ino Noch ein (identisches?) Display 200*200, mit Softwarebeispielen https://draeger-it.blog/arduino-lektion-106-e-paper-display-mit-154-zoll/ aber von Heltec wird eine Auflösung von 152 x 152 genannt: Der Beitrag scheint Spam zu enthalten: ".CN/" also _ entfernen: https://docs.heltec.c_n/#/en/products/display/eink/heltec_eink_display_list Von Good-Display gibt es eine FAQ in etwas holprigem Englisch https://www.e-paper-display.com/news_detail/newsId=44.html Q: What is waveform? A: Waveform are predefined voltage impulse sequences used by display controller to manipulate ink. The voltage sequence and temperature range are stored in a lookup Table(LUT) and is precisely paired to the display by production lots to enable precise placement of pigment to achieve accurate gray-level. Q: Why does waveform need? A: Because of every lots of E INK material has slightly different at ink characteristics which effects are temperature dependent. So, waveform is a driving method which consider the factor of temperature, production lot, display size and waveform type to control the each lots of EPD performance at same range, ZinggJM schlägt diese Anschlüsse für Arduino vor: https://github.com/ZinggJM/GxEPD2/blob/master/ConnectingHardware.md mapping suggestion for AVR, UNO, NANO etc. BUSY -> 7, RST -> 9, DC -> 8, CS-> 10, CLK -> 13, DIN -> 11 so sind immerhin SCK und MOSI korrekt verbunden. https://github.com/ZinggJM/GxEPD2/blob/master/MyEPDs_UpdateInfos.pdf hier nennt er als Controller den IL3829 für das 200*200-Display https://cursedhardware.github.io/epd-driver-ic/IL3829.pdf
:
Bearbeitet durch User
Ob da schon mal jemand selbst etwas programmiert hat, oder alle nur die Libraries anderer benutzen. Ich denke, ich werde einen Artikel dazu verfassen müssen, da man kaum etwas an Applikationsschriften findet. Ähnlich wie hier in der Artikelsammlung zum "Industriestandard" HD44780 https://www.mikrocontroller.net/articles/HD44780 Die beiden Controller SSD1681 und IL3829 scheinen sich sehr ähnlich zu sein, dürfte auch sozusagen ein Standard sein. Die Datenblätter werfen mehr Fragen auf als Antworten zu geben. Wieso soll man kein Displayupdate im hellen Sonnenlicht machen, was passiert wenn man länger als nötig Spannung anlegt. Das Waveshare-Wiki ist da ziemlich unbefriedigend. Wieso nenne die das "waveform" und was wird temperaturabhängig geändert, ist das keine simple Rechteckschwingung? Das segmentweise Beschreiben und Löschen scheint ja eine Möglichkeit zu sein, die Ausgabe zu beschleunigen, kann ich den Bildschirm irgendwie geschickt aufteilen, dass das geht? Altern die Displays, und kann ich das aufhalten? ZinggJMs erste Software ist immerhin schon 4 Jahre alt, aber anscheinend ist das Thema e-paper immer noch exotisch.
:
Bearbeitet durch User
Angehängte Dateien:
-
e_paper.jpg
180 KB
Das Waveshare 1,54" Displays liegt hier auch auf meinem Tisch. Nach einem funktionierenden Beispiel mit einem Arduino suche ich noch. Bisher noch ohne Erfolg. Das Modul mit Controller sollte 5V tolerant sein aber bisher habe ich es weder am Nano noch am Mega2560 zum Laufen bekommen. Das Heltec Modul am 3,3V Arduino Nano macht kein Problem. Sollte ich in den nächsten Tagen Erfolg haben melde ich mich. Vielleicht hast du ja vorher einen Code zum Laufen gebracht.
Angehängte Dateien:
'n Abend zusammen, hab kürzlich auch mit dem Teil etwas rumgespielt und mich dabei länger auf den Waveshare-Seiten rumgetrieben. Das anhängende Bild fand ich dabei im Wiki zu "E-Paper_Shield", daran habe ich mich gehalten. Die Seiten sind ansonsten ja schon etwas merkwürdig gebaut, immerhin hilft manchmal neu laden... Zum Laufen gebracht habe ich das Display schließlich, indem ich einfach alle fünf Git-Arduino-Beispiele epd154in* durchprobiert habe, nur eins davon hat funktioniert. Bei allen anderen tut sich rein gar nichts. Welche Hardware-Version man also tatsächlich hat, ist anders wohl kaum rauszukriegen. Viel Erfolg!
Christoph db1uq K. schrieb: > Im Controller-Datenblatt wird dieses Ablaufdiagramm gezeigt. Ähnlich wie > z.B. HD44780 mit Zeitverzögerungen, die man vermutlich einhalten muss. > Die Tabelle der einzelnen Befehle ist reichlich unübersichtlich. Ja, unübersichtlich ist das, stimmt. Das EINKM-154 in s/w (gibts auch dreifarbig, da ist aber ein anderer Controller drin) läuft bei mir nach einer Initialisierungssequenz, die man bei Waveshare in den Beispielen findet, aber völlig problemlos. Allerdings nicht mit Arduino sondern mit einem PIC16F1519 angesteuert. Code selber geschrieben, aber die Initialisierungssequenz und die LUT(s) habe ich übernommen. Einige Werte habe ich angepasst, aber ich kann mich grad nicht erinnern warum ich das im Einzelnen so gemacht habe. Ich glaube seit 2018 nicht mehr in den Code geschaut zu haben. Hauptakteur in dem Projekt war ja nicht das Display ;)
Angehängte Dateien:
-
EPA20A_2.jpg
41 KB
Christoph db1uq K. schrieb: > Ob da schon mal jemand selbst etwas programmiert hat, oder alle nur die > Libraries anderer benutzen. Ich denke, ich werde einen Artikel dazu > verfassen müssen, da man kaum etwas an Applikationsschriften findet Ja aber SSD1606 als Controller. EPA20A von EA
Mein 1,54" läuft damit: https://github.com/ZinggJM/GxEPD In der Beispieldatei GxEPD_Example.ino muss #include <GxGDEP015OC1/GxGDEP015OC1.h> // 1.54" b/w selektiert sein. Vieleich hilft es ja, eventuell kannst Du das auch auf das 1,54" Display abspecken. Zur Zeit unterstützt die Library mehrere Displays.
Ich habe in meinen Archiv gesucht - siehe Anhang. Läuft nur mit der V1 Variante des Waveshare Modules !
Angehängte Dateien:
-
Waveformspannung.png
12 KB
http://pepijndevos.nl/images/Winstar_E-Paper_Application_Note_V2.pdf eine alte Appnote von 2011, da wird die "waveform" mal ausführlicher gezeigt. Auf Seite 6, das sind ja ziemlich große Spannungen 60 bis 80 Vss zwischen den Elektroden. Im Datenblatt zum SSD1681 steht +/- 10 bis 20V, also max. 40Vss. Jetzt ist auch klar, wozu die kleine Schaltung auf dem Modul dient, der Controller liefert eine Oszillatorschwingung GDR, damit transformiert der Transistor die 3,3V auf diese Spannungen PREVGL und PREVGH hoch.
Hallo Christoph. Christoph db1uq K. schrieb: > was passiert > wenn man länger als nötig Spannung anlegt. Vermutung: Die spannung muss ja relativ hoch sein. Vielleicht ist es günstig, die Spannung abzuschalten, um die Leckströme so kurz wie möglich fliessen zu lassen, um elektrolytischer Zersetzung vorzubeugen? > Das Waveshare-Wiki ist da > ziemlich unbefriedigend. Wieso nenne die das "waveform" und was wird > temperaturabhängig geändert, ist das keine simple Rechteckschwingung? > "waveform"? Vielleicht eine miese Übersetzung für etwas, was eigentlich so etwas wie Tastverhältnis oder eine Kombination von Spitzenspannung und Tastverhältnis meint? Temperaturabhängig, weil Du irgendwelche winzigen Körper, die in einer opaken Flüssigkeit treiben, über elektrostatik manipulierst. Die Viskosität der Flüssikkeit könnte temperaturabhängig sein, und weil Du die Spannung gering halten möchtest, kannst Du sie bei höherer Temperatur reduzieren, wenn dir die Änderungsgeschwindigkeit langt. Auf der anderen Seite müsstest Du bei höherer Temperatur gegen stärkere Brownsche Bewegungen ankämpfen, was zumindest öftere Refreshs bedeuten würde. > Altern die Displays, und kann ich > das aufhalten? Siehe meine Bemrkung oben über Leckströme. > ZinggJMs erste Software ist immerhin schon 4 Jahre alt, aber anscheinend > ist das Thema e-paper immer noch exotisch. Ich interessiere mich schon länger dafür, aber die Informationen, die man findet, sind spärlich. Könnte ein Henne<>ei Problem sein. Wenig Nachfrage nach Information > wenig Angebot an Information. Es könnte auch aber ein Kommunikationsproblem nicht nur linguistischer, sondern auch sozialer Art sein. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Nachtrag: Bernd W. schrieb: > Ich interessiere mich schon länger dafür, aber die Informationen, die > man findet, sind spärlich. Könnte ein Henne<>ei Problem sein. Wenig > Nachfrage nach Information > wenig Angebot an Information. Es könnte > auch aber ein Kommunikationsproblem nicht nur linguistischer, sondern > auch sozialer Art sein. Gerade noch einmal probiert: https://www.google.de/search?as_q=E-Paper+Application+Note&as_epq=&as_oq=&as_eq=&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=&as_occt=any&safe=active&as_filetype=pdf&tbs= Scheint jetzt etwas besser zu sein. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Bernd Ich bin gerade dabei, eine vernünftige Pinbelegung am Arduino festzulegen. Ich möchte alles am Port B anschließen, damit sind nur ein paar Timerausgänge blockiert. Durch den SPI-Bus liegen SCK und MOSI fest. Damit ist aber MISO während der SPI-Ausgabe blockiert, obwohl ich den nicht benutzen kann. Der Datenausgang des Displays ist auf der Modulplatine nur DIN genannt, scheint aber bidirektional zu sein. Am Arduino müsste der aber zusätzlich auf MISO geführt werden, was einen weiteren Portpin belegt. Der Hardware-Reset wird nur am Anfang der Initialisierung benötigt, der könnte anschließend als MISO-Eingang auf high bleiben, evtl. ein Pull-up dran. Da der ATmega keinen 9-Bit-SPI unterstützt werde ich auf 4-Bit SPI mit zusätzlichem D/C-pin bleiben. Der 0-Ohm Widerstand dafür ist ab Werk so bestückt. Die restlichen Pins kann ich nach Belieben verteilen, D/C, Busy und CS. Die anderen Ports mit ADC-Eingängen, I2C-Bus, 2*Interrupt und die serielle Schnittstelle am USB-Wandler bleiben so benutzbar. Die Timer kann ich intern benutzen, 3 Timerpins sind noch verfügbar.
Christoph db1uq K. schrieb: > Die anderen Ports ..................... bleiben so benutzbar. Gerade bei diesen langsamen, zähen Displays bietet sich Soft- SPI geradezu an. Damit schafft man annähernd die Datenrate des Hardware-SPI, bekommt aber zusätzlich die Möglichkeit das Interface auf praktisch beliebige Portpins nach eigenem Bedarf zu verteilen. Ausserdem könnte man bei der Soft-SPI-Implementierung gleich per #define-Klammerung verschiedene Port-Konfigurationen für diverse AVR-Prozessoren vorsehen und somit die Source schnell auf andere Verhältnisse kompilierbar machen. Dazu müsste "man" allerdings Display- und SPI-Layer sauber trennen um nicht in einen Dschungel von C-Code zu geraten.
Der USART im ATmega kann auch 9-bit, ich werde aber aus dem Datenblatt nicht schlau, ob das auch im SPI-Modus oder Synchron-Modus (es gibt zwei) benutzbar ist. Ich hätte gern alle Displayanschlüsse an einem Port, dann muss ich z.B. nicht ständig Datenrichtungsregister bitweise umschalten. Da ich eventuell noch einen One-Wire-Bus bedienen möchte, der ein zeitkritischeres Timing hat, will ich die Interrupts vor allem dazu einsetzen. Schade, dass der asynchrone Anschluss schon mit dem USB belegt ist, den kann man trickreich auch für One-Wire benutzen. Dazu gibt es eine Appnote von Dallas.
https://www.maximintegrated.com/en/design/technical-documents/tutorials/2/214.html das ist die Appnote von 2002 Es geht mir im Moment um ein Akku-Entladegerät. Unsere portablen Prüfgeräte, schon vor über 20 Jahren entwickelt, enthalten Li-Ionen Akkus. Die Sicherheitsvorschriften haben sich seither verschärft. Neuste Anschaffung ist ein feuerfester Lagerschrank, aber auch für den Lufttransport muss schon seit 2016 der Akku auf <30% der Nennkapazität entladen sein. Im Lagerschrank sollen die Akkus mit max. 80% eingelagert werden, und spätestens nach Unterschreiten von 30% wieder aufgeladen werden, das sei der schonendste Bereich. Außerdem enthalten alle Akkupacks ein "Tankuhr"-IC von TI/Benchmarq, das einen vollen Lade/Entladezyklus braucht, also Entladen auf etwa 0 %. Natürlich nicht immer derselbe Typ, sondern drei unterschiedliche, 1* OneWire, 2*I2C-Bus. Das e-paper hätte den Vorteil, dass das Entladegerät völlig abschaltet und trotzdem der letzte Zustand angezeigt wird.
Auf dem Display-Folienkabel ist eine Nummer hink-e0154a05 aufgedruckt, damit habe ich noch das hier gefunden; https://www.trs-star.com/produkte/displays/display-details/e-paper-displays Controller SSD1608, noch ein dritter Vorschlag nach SSD1681 und IL3829, das älteste Datenblatt. https://v4.cecdn.yun300.c_n/100001_1909185148/SSD1608-1.pdf Der Beitrag scheint Spam zu enthalten: wieder _ entfernen Marke "Holitech" http://www.holitech.net/en/product/p12/p1/20161011/1305.html https://github.com/Ineltek-UK/eink-xplained-pro-asf4 https://homematic-forum.de/forum/viewtopic.php?t=54714 ELV hat das von "Good Display" im Programm https://de.elv.com/elv-e-paper-display-modul-edm100-komplettbausatz-150674?fs=429023252
:
Bearbeitet durch User
Jetzt habe ich mal die originale Software von Waveshare näher betrachtet: https://github.com/waveshare/e-Paper oben rechts unter "Code" kann man das zip herunterladen. Darin im Gesamtordner "e-Paper-master" drei Unterordner für Arduino/Raspberry/STM32. In "Arduino" gibt es für mein 1.54 Inch Display drei Unterordner epd1in54/epd1in54b/epd1in54b_V2 Welches gehört zu meinem Exemplar? Anscheinend gibt es zwei nicht kompatible Controller, hier anhand des Befehls, der am Schluss einer Ausgabe das Display in dem Tiefschlaf versetzt: epd1in54.h: #define DEEP_SLEEP_MODE 0x10 epd1in54b.h und epd1in54b_V2.h: #define DEEP_SLEEP 0x07 (ohne "MODE") Das "b" scheint für das dreifarbige e-paper mit zusätzlich roter Darstellung zu sein. Die Tabelle von trs-star nennt SSD1675 oder UC8151C als Controller, für zwei dreifarbige mit nur 152*152 Pixeln statt 200*200. https://cdn-learn.adafruit.com/assets/assets/000/092/748/original/SSD1675_0.pdf deep sleep =0x10 ??? kein Wunder, wenn die Software nur teilweise läuft. https://cursedhardware.github.io/epd-driver-ic/UC8151c.pdf deep sleep =0x07 Alle drei bisher genannten Controller haben 0x10, die sind soweit kompatibel. Auch in beiden Flussdiagrammen, die ich bisher gefunden habe steht 0x10. Kein Wunder, dass zur ersten Inbetriebnahme der Anschluss eines PC als serielles Terminal empfohlen wird, das wenigstens eine Fehlermeldung ausgeben kann, wenn das Display nicht reagiert, z.B. so in epd1in54b-demo.ino: void setup() { Serial.begin(115200); Epd epd; if (epd.Init() != 0) { Serial.print("e-Paper init failed"); return;
:
Bearbeitet durch User
Wie ich oben schon schrieb: am gescheitesten ist es das auszuprobieren. Solange VCC, GND und vielleicht noch BUSY richtig angeschlossen sind, ist das schlimmste was passieren kann, daß der Controller mit den Befehlen nichts anfangen kann und das Display deshalb aus bleibt. Kaputtgehen sollte dadurch nichts. Die Verzeichnisse auf github korrespondieren ansonsten direkt mit den offiziellen Display-Bezeichnungen (zu sehen etwa in Links und bei "Related products"): 1.54inch e-Paper Module - schwarz/weiß 1.54inch e-Paper Module (B) - schwarz/weiß/rot 1.54inch e-Paper Module (C) - schwarz/weiß/gelb "V2" ist offenbar jeweils Version 2, also neuer. Bei 2.9 inch ist es übrigens noch bunter, dort gibt es Varianten mit und ohne Levelshifter. Trotzdem hat man sich mit dem Wiki noch weniger Mühe gegeben, denn für alle wird auf das allerälteste Verzeichnis verwiesen, während es bei mir nur mit dem neuen läuft.
Aus den drei Datenblättern der e-paper-Controller habe ich mal die Unterschiede zusammengesucht. Der dritte hat nur 160*296, kann also keine 200*200. Dem ersten fehlen drei der im .h-Text genannten Befehle. Es scheint daher der IL3829 mit 2 RAMs zu je 200*300 = 15000 Byte bestückt zu sein, der auch für dreifarbiges e-paper ausreicht. Leider kann man nicht nachschauen oder eine Kennung abrufen. Meine Portbelegung dazu, es ist wie geplant nur Port B benutzt, ich kann die Ausgaben über die SPI-Hardware des ATmega machen, für Lesebefehle müsste ich es zu Fuß erledigen. Für den Hardware-Reset darf der SPI nicht initialisiert sein, weil der Pin sonst als MISO Eingang benutzt ist: .equ Busy = 0 ; Busy-Flag Bit0 von PortB, Arduino D8 .equ D_C = 1 ; Data/Command = Bit1 von PortB, Arduino D9 .equ CS = 2 ; ChipSelect = Bit2 von PortB, Arduino D10 .equ Dat = 3 ; Dat = Bit3 von PortB , Arduino D11 MOSI .equ Reset = 4 ; Reset = Bit4 von PortB , Arduino D12 MISO .equ Sclk = 5 ; Sclk = Bit5 von PortB , Arduino D13 Sclk Das display-RAM im IL3829 ist also für das s/w-Modell dreimal so groß wie nötig "On chip display RAM with double display buffer [200x300 / 8 * 2 = 15000Byte]" The On chip display RAM is holding the image data. 1 set of RAM is built for historical data and the other set is built for the current image data. The size of each RAM is 200x300 bits. Damit kann man vermutlich die neuen Pixel langsam übertragen und in einem Rutsch auf das neue Bild umschalten. Der Arduino hat nur 2k SRAM, das könnte helfen.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Damit kann man vermutlich die neuen Pixel langsam übertragen und in > einem Rutsch auf das neue Bild umschalten. Nicht ganz. Bei den Schwarz-Weiß-ePaper-Displays kann eine Bitplane das aktuell angezeigte Bild enthalten und die zweite Bitplane das neue Bild. Pro Pixel sieht das dann bspw. so aus:
1 | alt neu adressierte LUT |
2 | 0 0 1 |
3 | 0 1 2 |
4 | 1 0 3 |
5 | 1 1 4 |
6 | |
7 | 0=Schwarz |
8 | 1=Weiß |
Vorteil dabei ist, daß das angezeigte Bild nicht erst gelöscht werden muß, sondern daß die entsprechende Waveform der LUT das Pixel gezielt von Schwarz nach Weiß (LUT 2 im Beispiel) bzw. von Weiß nach Schwarz (LUT 3) umschaltet oder gar nix tut, wenn neu=alt (LUT 1 und 4). Bei dreifarbigen ePaper-Displays klappt das nicht mehr, weil ja drei verschiedene Waveforms erforderlich sind. Drei der vier möglichen Bitkombinationen der beiden Bitplanes adressieren dann die LUTs für Schwarz, Weiß und Gelb bzw. Rot, die vierte kann irgendwas (evtl. redundant auch eine der drei Farben) oder nichts machen. Damit das funktioniert, müssen die Waveforms entweder erstmal einen definierten Zustand des Pixels herstellen (bspw. alle schalten das Pixel erstmal auf Weiß, egal was es am Ende werden soll) und setzen direkt im Anschluß die gewünschte Farbe - oder das Display wird vorher explizit gelöscht (etwa alle Pixel auf Weiß, dann Display-Update) und danach wird das gewünschte Bild dargestellt. Ich kenne den aktuellen Stand nicht, ggf. dürften die bei den Dreifarb-ePapers im OTP-Memory mitgelieferten Waveforms von einem gelöschten Display ausgehen. Wenn man da einfach ein Bild nach dem anderen anzeigen läßt, ohne zwischendurch zu löschen, gibt's deutliches Shadowing. Mit selbstdefinierten LUTs/Waveforms läßt sich natürlich der oben beschriebene Mechanismus für SW-ePapers auch bei Dreifarb-Displays anwenden, solange man sich auf zwei Farben beschränkt (ggf. temporär; werden drei Farben gebraucht, muß man die LUTs halt wieder umschalten).
Danke Horst für die Erklärung. Ich bekomme allmählich Respekt vor der Komplexität dieser Technik. Kein Wunder, dass bisher wenig Bastlerliteratur existiert. Ein LCD ist wesentlich einfacher anzusteuern, vor allem ohne Wissen um die unmittelbare Vorgeschichte des Bildinhalts. Das soll mich aber nicht abschrecken, weiter zu bohren.
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.