Waveshare e-paper displays with SPI

Other Hardware Displays
161

Try a few leds on the digital pins to check if the pins are working and correctly numbered?

162

vertigo72:
Try a few leds on the digital pins to check if the pins are working and correctly numbered?

thanks.. that could help, i will try tonight

163

... and check your solder connections of the pins.

The small solder rings around the holes can provoke cold joints. Solder should clearly flow and be sucked into the hole.

I found pocket_32 - thanks to your link - it is on my other notebook. I need to update the ESP package on my development notebook.

164

has anyone by any chance found or made some fritzing components for these displays?

165

devros:
thanks.. that could help, i will try tonight

I have the same board you've got, assuming it's not a dud, I can assure you it does work with e-paper once you've figured out how to connect it. This video was very helpful https://www.youtube.com/watch?v=AeYbX0zaJTY

166

Q24H:
I have the same board you've got, assuming it's not a dud, I can assure you it does work with e-paper once you've figured out how to connect it. This video was very helpful https://www.youtube.com/watch?v=AeYbX0zaJTY

Thanks figured out that my pin 23 wasnt working

unfortunately, the usb connector from the board has broken yesterday (and its so tiny that i cant fix it)
i will have to setup FTDI connection, then it should work

167

Hi,

I have Uno and 1.54 BWR display. I've tryed GxEPD_SPI_TestExample with pins BUSY-> 7, RST -> 9, DC-> 8, CS-> 10, CLK-> 13, DIN-> 11 and 3.3V->3.3V, GND->GND

#include <GxGDEW0154Z04/GxGDEW0154Z04.cpp> // 1.54" b/w/r

Nothing happens.

I have tryed to create a simplified code but this also not works:
#include <GxEPD.h>
#include <GxGDEW0154Z04/GxGDEW0154Z04.cpp> // 1.54" b/w/r

#include <Fonts/FreeMonoBold9pt7b.h>
#include <Fonts/FreeMonoBold12pt7b.h>
#include <Fonts/FreeMonoBold18pt7b.h>
#include <Fonts/FreeMonoBold24pt7b.h>

#include <GxIO/GxIO_SPI/GxIO_SPI.cpp>
#include <GxIO/GxIO.cpp>

#define PIN_SPI_SS (10)
#define PIN_SPI_MOSI (11)
#define PIN_SPI_MISO (12)
#define PIN_SPI_SCK (13)

GxIO_Class io(SPI, SS, 8, 9);
GxEPD_Class display(io);

void setup() {
display.init();
}

void loop() {
display.fillScreen(GxEPD_WHITE);
display.println();
display.println(" !"#$%&'()*+,-./");
display.update();
}

Could You help me?

168

I do not know where I should place this IMPORTANT WARNING:

Do NOT use these e-paper displays directly with normal 5V UNO, NANO, MEAGA ...

They are for 3.3V and these processors can source up to 40mA into any anti-latch-up diodes of the controller!

Your mapping looks ok. Use at least series resistors.

Does Serial Monitor show anything?

I have tested this combination with 3.3V Arduino Pro Mini.

169

I have used the 3.3V PIN on my UNO.
The serial monitor don't show anything.

170

gdudas:
I have used the 3.3V PIN on my UNO.
The serial monitor don't show anything.

All output pins will source 5V !!!

GxEPD_SPI_TestExample does initialize Serial with 115200; you should see at least "setup" and then "setup done".

171

Ops... Thanks for clearing. When I tested GxEPD_SPI_TestExample then the serial wrote:

setup
setup done
Busy Timeout!
Busy Timeout!

and so on...

172

Busy Timeout with no reaction on the display means you have a bad SPI connection, most likely.
Busy Timeout with display output would mean bad BUSY line connection.

Make sure the connector to the display is firmly pushed in.
Make sure your DuPont connectors make good contact (I had to replace them in one case).
Make sure your UNO has good solder joints (I have some clones with questionable soldering).

Verify connections with a voltmeter or a scope.

173

Hello ZinggJM,

it is possible to add support for this display?

https://www.waveshare.com/wiki/4.2inch_e-Paper_Module_(B)

It's a three-colors variant GDEW042T2.

Thanks you for your answer.

174

tull:
Hello ZinggJM,

it is possible to add support for this display?

https://www.waveshare.com/wiki/4.2inch_e-Paper_Module_(B)

It's a three-colors variant GDEW042T2.

Thanks you for your answer.

Yes, it is possible to add support for this display.

But I add only support for displays I have and can test with.
And I only buy displays I want to use for myself, or are interested in learning how to use.

So I would need a Sponsor for this display;
Waveshare provides their own demo examples and have not discovered that GxEPD may also help them sell more of these displays.

175

I understand ... it is not enough to write it alone :wink:

176

Hello guys,

Any plans to make partial update to work on the black/white/red display? More specifically on the GxGDEW0154Z04

Thanks!

177

jones12ax7:
Hello guys,

Any plans to make partial update to work on the black/white/red display? More specifically on the GxGDEW0154Z04

Thanks!

There are two prerequisites for partial update:

  1. capabilities of the controller: setting a partial update window for the device RAM and writing to that window

  2. availability of a waveform table for partial update (LUT table) for fast update.

For the controller of the GDEW0154Z04 both prerequisites are not available, see the specs of the controller.

For the e-papers with controllers that have the partial update capability, but no fast update method yet, I would like to experiment with partial update waveforms, but I do not have the knowledge to do it.

So any information for creation of partial update waveforms for the e-papers that officially have no partial update is welcome.

The controller specs of the GDEH029A1 has quite detailed information about the waveform table: IL3820

178

Im happy to report my 1.54 B/W screen should have done well over 1 million partial update cycles now, andn after a full refresh, it still looks like new. In fairness, Im not updating every pixel every cycle, Im just showing incremental numbers, but still, this is good news.

I would like to come back to the matter of speed though. The current library seems to max out at ~2FPS despite a fast microcontoller (esp32). Further decreasing #define PU_DELAY has no effect. When I look at some other demo's like this one:

I wonder if either Im doing something wrong, or if there is something that can be done to achieve that kind of speed? For my application, generally 2FPS is ok. But when navigating menu's with a click encoder, its kind of painful and it would be really nice to be able to temporarily trade extra speed for more ghosting.

179

Thank you very much! That's all I needed to know to decide my goals.
I think will be easier to use the B&W version instead.

I'm not an expert on programming (just an electronics enthusiast), but will have a check on the partial update waveforms.

Thanks!

ZinggJM:
There are two prerequisites for partial update:

  1. capabilities of the controller: setting a partial update window for the device RAM and writing to that window

  2. availability of a waveform table for partial update (LUT table) for fast update.

For the controller of the GDEW0154Z04 both prerequisites are not available, see the specs of the controller.

For the e-papers with controllers that have the partial update capability, but no fast update method yet, I would like to experiment with partial update waveforms, but I do not have the knowledge to do it.

So any information for creation of partial update waveforms for the e-papers that officially have no partial update is welcome.

The controller specs of the GDEH029A1 has quite detailed information about the waveform table: IL3820

180

vertigo72:
Im happy to report my 1.54 B/W screen should have done well over 1 million partial update cycles now, andn after a full refresh, it still looks like new. In fairness, Im not updating every pixel every cycle, Im just showing incremental numbers, but still, this is good news.

I would like to come back to the matter of speed though. The current library seems to max out at ~2FPS despite a fast microcontoller (esp32). Further decreasing #define PU_DELAY has no effect. When I look at some other demo's like this one:

https://www.youtube.com/watch?v=enzUbiSWenQ

I wonder if either Im doing something wrong, or if there is something that can be done to achieve that kind of speed? For my application, generally 2FPS is ok. But when navigating menu's with a click encoder, its kind of painful and it would be really nice to be able to temporarily trade extra speed for more ghosting.

The pervasive demo looks impressive. I do not know these e-paper displays, and don't know their actual prices.
I assume the pervasive displays use higher voltages to achieve higher update speed.

You do nothing wrong, the update time is mostly defined by the waveform table.

I had added the delays to give the displays a chance to live longer and show less degradation. Code execution time should be negligible compared to the update time, maybe except for paged display for AVR.

But these e-papers are not made for fast and frequent updates; their original destination was for shelf labels.

Thanks to Dalian Good Display we get affordable e-papers to play with.

Jean-Marc