GDEM1085T51 and DESPI-C1085 with GxEPD2

Hi @ZinggJM
I am trying to use GxEPD2 with the GDEM1085T51, ESP32-L, and the newly available DESPI-C1085 connector board.

Having looked at the newly updated sample code from GoodDisplay and the pinout of the board, I configured the display driver as follows:

GxEPD2_DISPLAY_CLASS<GxEPD2_DRIVER_CLASS, MAX_HEIGHT(GxEPD2_DRIVER_CLASS)> display(GxEPD2_DRIVER_CLASS(/*CS=*/ 27, /*DC=*/ 0, /*RST=*/ 12, /*BUSY=*/ 13, /*CS2=*/ 14));

I have set DC to 0 since its intended pin on the ESP32-L is used for CS2 and in your code you guard for _dc being 0.

Unfortunately, my current configuration does not show any image on the display. Am I missing anything? I init the display with a simple display.init(115200); and do not manually initialize SPI.

Thank you for your help and best regards
Kevin

//GxEPD2_DISPLAY_CLASS<GxEPD2_DRIVER_CLASS, MAX_HEIGHT(GxEPD2_DRIVER_CLASS)> display(GxEPD2_DRIVER_CLASS(/*CS=*/ 27, /*DC=*/ 14, /*RST=*/ 12, /*BUSY=*/ 13, /*CS2=*/ 4)); // for GDEM1085T51 with ESP32-L

from GxEPD2/examples/GxEPD2_Example/GxEPD2_display_selection_new_style.h at master · ZinggJM/GxEPD2 (github.com) line 181
I assume I tried this.
-jz-
But my DESPI-C1085 looks different.
GxEPD2 doesn't support 3-pin SPI mode. So it needs the DC pin.
Maybe the Good Display demo uses 3-pin SPI.

Is the presence / absence of the DC pin really a matter of 3 vs 4 pin SPI? My understanding has always been that the DC pin is just an additioan pin used for distinguishing between commands and data. Thus more of a matter of data communication protocol.

But interesting that you have a different DESPI-C1085. How did they solve the issue of not having enough pins to connect both DC and CS2 to a ESP32-L?

When I first talked to Good Display support about connectivity options, they suggested that I should soldier a flying wire directly to the ribbon cable of the display!

Yes. 3-pin SPI uses 9-bit SPI transfers, with one bit used for D/C.

My DESPI-C1085 modules have 7 pins. And solder jumpers for 3 or 4 wire SPI. So the extra pin can easily be wired to any pin.

Which is not enough. Needs a different level on the BS connection.
DESPI-C1085.pdf (yun300.cn)

Too bad Good Display went with an inflexible 3-wire SPI design for their public release version of the DESPI-C1085. Probably they prioritized plug-and-play with their ESP32-L board over flexibility.

I conclude that GDEM1085T51 is thus currently incompatible with GxEPD2 unless one designs their own connector PCB...

My situation is that I have a hobby project I would love to finish, it basically displays some BMP image (XKCD comic) from the web onto the display. As PCB design is beyond my abilities, what would you recommend to me: fork your GxEPD2_1085_GDEM1085T51 class and rewrite the SPI code? Or is it easier to build something new based on the Good Display sample code? Or are you aware of a different library that could help me out?

I would first complain to Good Display that you can't use GxEPD2 with your display. And that all other users will face the same issue. Contact Mr. Chris Wu.

You could also contact @laskakit , he donated this display to me, and his shop certainly would like to sell these displays without the above issue.

As a last resort, you could implement 9bit SPI transfers in the driver class. It already has the low level IO methods locally, because of the master and slave selects.
Dependent on the processor, you can use SW SPI, or HW SPI on ESP.
I don't know if this would still work (as an example):
GxTFT/src/GxIO/GxIO_SPI_RS at master · ZinggJM/GxTFT · GitHub
-jz-

I will contact Good Display then. I will keep you updated.

I contacted Chris. His colleague then offered me a 4-wire SPI version of the board - which would solve the issue for me, but not for anyone else.

I once again replied, challenging their design decision and suggested that a connector board with 3 AND 4 wire SPI connectivity would have been a more flexible design choice, hinting not only at GxEPD2 compatibility, but also suggesting that customers may have written code for previous screens that they wish to continue using...

Anyway, I am not expecting this to have a big impact. I might actually try to use SW SPI...

In case anyone is interested, I quickly hacked together a 3wire SW SPI version of the GxEPD2_1085_GDEM1085T51 class. I basically made a copy of the original class and inserted the Good Display sample code into the respective places.

3spi.zip (13.8 KB)

I works, though I did only basic testing (Wifi example, showBitmapFrom_HTTP method).