CALE-IDF-SPI Optimierung des elektronisches Papierdisplays

Die Methode, die normalerweise in jedem GxEPD-Modell ausgeführt wird

Im Gegensatz zum E-paper-Modul ist das, was mit der Update-Methode passiert, etwas ähnlich.

Aufruf der persönlichen Methode 1. _wakeup(). In den meisten epaper-Controller-Modellen sendet und initialisiert Power On (0x04CMD) zunächst LUTs
Senden Sie die Tabelle (normalerweise 4 42-44 Bytes pro SPI CMD+DATA).
2. Geben Sie den Befehl aus, um das Senden des Puffers zu starten (CMD0x13). Der Pixelpuffer sendet 0 am Ende von sizeof (_buffer).
Lesen nach Byte im generierten GFX_buffer, IO. An Daten (Bytes) gesendet.
3. Rufen Sie den Befehl auf, um den Display Slave zu aktualisieren (normalerweise 0x012)
4. Wenn die Aktualisierung erfolgt, rendert epaper neue Pixel
I.O. Daten(Byte) schaltet den CS Gpio Low-> sendet -> CS wieder hoch

Good display epaper IC drivers

Offensichtliche Optimierungspunkte
Das Umschalten von CS zwischen jedem an Daten gesendeten Byte ist überplant. Nach jeder Übertragung, selbst wenn es mehrere Nanosekunden dauert, um GPIO zu reduzieren oder zu verbessern, wird die Leistung stark beeinträchtigt, wenn ein voller Puffer an einen großen epper gesendet wird. Offensichtlich ist dies keine effektive Methode.
Zum Beispiel verfügt ein 12,48-Zoll-Display über 1304,984 Pixel. So ist es 1.283 Millionen Pixel im Allgemeinen. Es ist einfach, die Anzahl der Bytes zu messen, die durch den SPI durch den CS-Pin übertragen werden.
1,283,136/8=160,392 Bytes
Daher wird CS GPIO auf 160000-mal umgewandelt, niedrig ->übertragen ->hoch, um Pixelpuffer zu senden. Brauchen Sie Optimierungen?
Sie können stattdessen eine andere Datenfunktion verwenden.
EpdSpi::data(const uint8_t*data,int len)｛｝
Senden Sie die gesamte Leitung durch SPI, schalten Sie CS-Pin und senden Sie einmal pro Y-Linie. Dieser Vorgang kann auf dem Display als einzelner SPI ausgeführt werden. In Wave12I48 ist es jedoch viel effizienter, die ganze Zeile an jeden Epper zu senden, als sie nach Byte zu senden. Entsprechend der SPI-Datei kann jeder SPI in jedem Datentransfer bis zu 4Kb Daten übertragen. Dies deutet darauf hin, dass es Raum für weitere Optimierungen geben kann.
Da der epaper eine komplexe Gitterstruktur hat, wird für jeden epaper Controller, der in vier Gittern angeordnet ist, die GPio CS Umwandlung um mindestens das 80-fache reduziert (80–8640), und jede Anzeige reicht aus, um komplette Röntgenaufnahmen abzugeben. Für andere Einzel-SPI-Displays planen wir jedoch, unter der Prämisse einer stabilen Implementierung möglichst viel zu optimieren, um die SPI-Grenze zu erreichen.
Es gibt ein Sprichwort in der Programmierwelt, dass "vorzeitige Optimierung die Wurzel aller Übel ist". Aber es ist noch nicht zu früh. Das ist eine offensichtliche Optimierung. Insbesondere eine übermäßige Optimierung auf epapers mit kleinen Puffern wird keine signifikanten Unterschiede hervorrufen, kann aber bei solchen größeren epapers durchgeführt werden. Daher gilt sie für alle möglichen neuen Modellklassen.

Eine weitere interessante Lektüre zur SPI Optimierung:

Official ESP-IDF documentation

https://github.com/krzychb/esp-epaper-29-ws