search

todd-herbert / heltec-eink-modules

Third-party Arduino Library for Heltec E-Ink displays
21 stars 4 forks source link

ESP8266/ESP32 Support #4

Closed kritch83 closed 1 year ago

kritch83 commented 1 year ago

ESP32 Boards: Xiao ESP32C3, Lolin S2 Mini, ESP8266 Boards: Adafruit Huzzah 8266, Wemos D1 Mini Pro

Issue: Compiling failure for ESP32/8266 platforms, all boards.

Software: Arduino SDK 2.1.1 CLI 0.32.3 ESP32 Core: 2.0.10 ESP8266 Core: 3.1.2 heltec-eink-modules: 2.4.1

Steps taken: removed & re-installed esp32/esp8266 cores & library. Tried several boards with same error.

Error:

`/Users/kritch/Documents/Arduino/libraries/heltec-eink-modules/src/Displays/DEPG0150BNS810/paging.cpp: In member function 'bool DEPG0150BNS810::calculating()':
/Users/kritch/Documents/Arduino/libraries/heltec-eink-modules/src/Displays/DEPG0150BNS810/paging.cpp:139:72: error: no matching function for call to 'min(int, uint8_t&)'
         page_bottom = min(page_top + pagefile_height - 1, winrot_bottom);
                                                                        ^
In file included from /Users/kritch/Library/Arduino15/packages/esp32/tools/riscv32-esp-elf-gcc/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/include/c++/8.4.0/algorithm:62,
                 from /Users/kritch/Library/Arduino15/packages/esp32/hardware/esp32/2.0.9/cores/esp32/Arduino.h:172,
                 from /Users/kritch/Documents/Arduino/libraries/heltec-eink-modules/src/Displays/DEPG0150BNS810/DEPG0150BNS810.h:1,
                 from /Users/kritch/Documents/Arduino/libraries/heltec-eink-modules/src/Displays/DEPG0150BNS810/paging.cpp:1:
/Users/kritch/Library/Arduino15/packages/esp32/tools/riscv32-esp-elf-gcc/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/include/c++/8.4.0/bits/stl_algo.h:3456:5: note: candidate: 'template<class _Tp, class _Compare> _Tp std::min(std::initializer_list<_Tp>, _Compare)'
     min(initializer_list<_Tp> __l, _Compare __comp)
     ^~~
/Users/kritch/Library/Arduino15/packages/esp32/tools/riscv32-esp-elf-gcc/esp-2021r2-patch5-8.4.0/riscv32-esp-elf/include/c++/8.4.0/bits/stl_algo.h:3456:5: note:   template argument deduction/substitution failed:
/Users/kritch/Documents/Arduino/libraries/heltec-eink-modules/src/Displays/DEPG0150BNS810/paging.cpp:139:72: note:   mismatched types 'std::initializer_list<_Tp>' and 'int'
         page_bottom = min(page_top + pagefile_height - 1, winrot_bottom);`
todd-herbert commented 1 year ago

Library.properties indicates support for AVR microcontrollers only.

https://github.com/todd-herbert/heltec-eink-modules/blob/a9cdf2e9648baddb078e3b7a105464d557a63860/library.properties#L9

Target is specifically "Arduino UNO" (R3)

https://github.com/todd-herbert/heltec-eink-modules/blob/a9cdf2e9648baddb078e3b7a105464d557a63860/docs/README.md#L4

Library's main function is to implement paged drawing, allowing low-resource boards, specifically those based on ATMega328, to make use of these displays. An ESP microcontroller has memory to spare; it makes no sense to implement paging.

https://github.com/todd-herbert/heltec-eink-modules/blob/a9cdf2e9648baddb078e3b7a105464d557a63860/docs/README.md#L21-L28

I will admit that the "Out of Box" support for Heltec Displays is poor, especially for ESP, however it is outside the scope of this library.

If you have not discovered it already, https://github.com/ZinggJM/GxEPD2 casts a wider net, and should offer what you are looking for, specifically full screen buffer support.

The table of information in identifying your display may help you configure GxEPD2.

Best of luck.

todd-herbert commented 1 year ago

Change in plans: ESP support is under investigation in branch test/ESP32. Code is currently unsuitable for general use.

junzzhu commented 1 year ago

Great! I happen to have two of the e-ink screens (DEPG0290BNS75A and DEPG0213RWS800) and would love to do tests on ESP32. Please keep me updated once you have ESP32 wiring and bare_minimum example. Thanks

todd-herbert commented 1 year ago

Currently, the included examples, originally written for UNO, are working fine on my generic ESP32 Dev Kit. As of this evening, I have ~8 hours total experience working with ESP32, in any capacity. Proceed with caution.

As ESP32 has no shortage of memory, paging serves no purpose. At this stage, the display is rendering in a single pass, but drawing operations must still be run from inside while ( display.calculating() ), as some of the initialization and update code is still taken care of by this loop. This is the same syntax as used to draw with UNO.

Provisional ESP32 Wiring

Display ESP32
VCC 3V3
GND GND
D/C 22 *
SDI 23
CS 5 *
CLK 18
BUSY 21 *

* These pins must be configured at the top of an example, or manually passed in the constructor. You should be able to change these pin assignments, but this is untested.

Moving forward, the plan is to enable the more powerful platforms, such as ESP32, to perform drawing operations without a .calculating() paging loop. This will cause a few breaking changes to the API, regarding "fastmode" (partial refresh). As a result, proper ESP support will probably come as v3.0.0

junzzhu commented 1 year ago

I have tried a few examples on both of my e-ink panels, with ESP32-WROOM. The results are excellent! I followed the wiring table, defined three pins only, but did not see where to configure CLK or SDI. It works anyway. Here are details.

    #define DC_PIN 22
    #define CS_PIN 5
    #define BUSY_PIN 21

I wonder if fast_mode works for BW panels only, as I got such errors when trying to run it on the BWR screen:

/home/jun/Github/heltec-eink-modules/examples/fast_mode/fast_mode.ino: In function 'void setup()':
/home/jun/Github/heltec-eink-modules/examples/fast_mode/fast_mode.ino:89:13: error: 'class QYEG0213RWS800' has no member named 'setFastmode'
     display.setFastmode( display.fastmode.ON );
             ^~~~~~~~~~~
/home/jun/Github/heltec-eink-modules/examples/fast_mode/fast_mode.ino:89:34: error: 'class QYEG0213RWS800' has no member named 'fastmode'
     display.setFastmode( display.fastmode.ON );
                                  ^~~~~~~~
/home/jun/Github/heltec-eink-modules/examples/fast_mode/fast_mode.ino:97:21: error: 'class QYEG0213RWS800' has no member named 'setFastmode'
             display.setFastmode( display.fastmode.FINALIZE );
                     ^~~~~~~~~~~
todd-herbert commented 1 year ago

but did not see where to configure CLK or SDI.

This is a good note, thank you. With Arduino UNO, the SPI pins are fixed. Because of this, there has so far been no option for user to specify CLK and SDI pins. I will look into adding this as a configuration option for ESP32.

todd-herbert commented 1 year ago

  • DEPG0213RWS800 // 2.13" V2 - BWR - Red Tab bare_minimum - works without issues fast_mode - seems not supported xbitmap_multicolor - works amazingly with three red apples

  • DEPG0290BNS75A // 2.9" V2 - BW - Red Tab bare_minimum - works without issues fast_mode - works without issues

Thank you for reporting your results!

I wonder if fast_mode works for BW panels only, as I got such errors when trying to run it on the BWR screen

Completely correct. Unfortunately the refresh operation for BWR is much more complicated. I believe that hardware limitations of most 3-Color displays impair fastmode (partial refresh).

My vague understanding of E-Ink technology is that the displays contain a fluid with a mixture of small white particles, and heavier black particles. During refresh, a finely tuned voltage is applied to different regions of the screen, so that, in some areas, the lighter white particles are drawn to the surface, leaving the heavier black particles behind.

With 3-Color displays, I believe (?) that a third, red particle, of intermediate size, is also present. An even more precise sequence takes place, to separate the heavy black, intermediate red, and light white particles, in the appropriate regions.

During a "full refresh" (fastmode.OFF), the displays pulse several times, to aid separation of the particles. During "partial refresh" (fastmode.ON, fastmode.FINALIZE), the display applies a stronger voltage, once only. The result is a faster update operation. The trade-off is lower image quality, and increased display wear.

For almost all 3-Color displays, separating all the different particles seems to be too fine of an operation to be performed in one brute step.

A quick search of the web suggest that fastmode support for 3-Color displays might be possible, but only when drawing with Black & White.

todd-herbert commented 1 year ago

Work continues in the dev branch. Preliminary support for ESP8266 has been added, although more testing is needed.

Note that the dev branch is now using the new v3 codebase. There are a small number of breaking changes, but no documentation just yet.

Suggested Wiring

  VCC GND D/C SDI CS CLK BUSY
ESP32 3.3V GND GPIO 2 GPIO 23 (VSPI MOSI) GPIO 4 GPIO 18 (VSPI CLK) GPIO 5
ESP8266 3.3V GND GPIO 2 GPIO13 (HSPI MOSI) GPIO 4 GPIO14 (HSPI SCK) GPIO 5

V3 sample code

// Display instance
DEPG0154BNS800 display(DC_PIN, CS_PIN, BUSY_PIN);

// Enable fastmode (Partial Refresh)
display.fastmodeOn();

// Universal drawing code, Arduino Uno compatible
DRAW(display) {
    display.drawCircle(40, 40, 20, BLACK);
    display.drawRect(10, 10, 30, 20, BLACK);
}

delay(4000);

// ESP-only: overwrite the existing screen image
display.fastmodeOff();
display.drawLine(0, 0, 100, 100, BLACK);
display.overwrite();
todd-herbert commented 1 year ago

v3.0.0 is released, with support for ESP32 and ESP8266. If you spot any bugs, please open an issue, and I'll do my best to fix them.