ESP8266/ESP32 Support

[kritch83]

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]

Library.properties indicates support for AVR microcontrollers only.

heltec-eink-modules/library.properties

Line 9 in a9cdf2e

architectures=avr

---

Target is specifically "Arduino UNO" (R3)

heltec-eink-modules/docs/README.md

Line 4 in a9cdf2e

Run-time graphics on Arduino UNO, using Adafruit-GFX (via [ZinggJM/GFX_Root](https://github.com/ZinggJM/GFX_Root))

---

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.

heltec-eink-modules/docs/README.md

Lines 21 to 28 in a9cdf2e

	## What is paging?
	*In this context,* it means that the display is calculated and transmitted in several small pieces, rather than in one big memory-clogging lump.
	This means more calculations are performed, but less RAM is needed.
	The resulting increase in calculation time ends up being insignificant, especially when compared to the slow refresh time of E-INK displays.
	Most importantly, it is the what allows the *Arduino Uno* to work with these displays, which would otherwise overload the limited memory.

---

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]

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

[junzzhu]

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]

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]

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

• 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

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]

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]

• 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]

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]

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.