Go Down

Topic: Waveshare e-paper displays with SPI (Read 100783 times) previous topic - next topic

panEarth

@ZinggJM

Thank you for your incredible investigation! I can confirm that now it work like a charm.

@panEarth,

see addition in #798

Added: Now I have checked with ESP32 and 7.5" b/w and it works.

Tested with GxFont_GFX_Example, board LOLIN32 Lite, board selected "Wemos LOLIN32"
Also tested on ESP8266, board Wemos D1 mini pro.
Font u8g2_font_helvR14_tf shows umlauts.


smbaker

I'm new to this and trying to understand partial update. I have a few of the waveshare 3-color displays that have really annoying refresh behavior. If I want to set just one pixel black, it takes several seconds and the whole thing flickers many times. From what I've read, that's just the way it is with this display, due to the lack of double-buffering.

I tried modifying the waveshare code for a 2.13" 3-color displays to send only an 8-pixel window, but I still ended up with the entire display flickering, and the update taking several seconds. It didn't seem any better than doing a full update, except possibly in the data transfer time. This is working as expected on these displays?

Reading ZinggIM's posts in this thread, I see there are two partial updates, a slow partial update and a fast partial update / differential update. Is there a list of which displays are capable of which partial update modes? From what I read the 4.2" display (GDEW042T2) can do it, but are there any larger ones?

I'm looking to be able to update about a dozen pixels, and do so at least 3 times a second.

Thanks,
Scott

ZinggJM

@smbaker,

The 1.54" b/w 200x200 e-paper display is the only one I know that can do more than 1 partial update per second, I think 3 per second is about the limit.

Wavshare has a list with update times and information about partial update or not.
3-color e-paper displays can have partial update of screen parts, but always slow and with flicker.

As you have several e-papers but don't tell wich ones, you best try yourself by using example PartialUpdateExample.ino of library GxEPD

I have produced many posts in this topic about partial refresh.
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

smbaker

The ones I have are the 2.13 flexible black/white, and then I have three color ones: 2.13, 2.7, and 5.83. When I bought these I didn't have much plan in mind, other than I knew I wanted to do something with ePaper, so I chose a variety, and the 3-color ones seemed more interesting than the black/white ones, so I leaned in that direction.

The flexible 2.13 black/white display has a raspberry pi demo using the waveshare code that displays a digital clock, incrementing once per second.

Watching Ben Kasnow's video, IIRC he was getting about three updates per second on the 4.2" display? I'm thinking about picking up some more of those.

Anyhow, thanks for the reply, there's a lot of information in this thread -- it's taking me a while to distill it all.

ZinggJM

#814
Oct 07, 2018, 10:07 am Last Edit: Oct 10, 2018, 11:20 am by ZinggJM
Quote
I tried modifying the waveshare code for a 2.13" 3-color displays to send only an 8-pixel window, but I still ended up with the entire display flickering, and the update taking several seconds. It didn't seem any better than doing a full update, except possibly in the data transfer time. This is working as expected on these displays?
The 2.13" 3-color can do partial refresh of a screen part, flashing only in this part and the screen boarder.
Same for 2.7" 3-color; but this also leaves unpleasant boarder traces of the partial window.

The 4.2" 3-color has a problem with the controller, so I had to use full screen refresh for it.

Quote
Is there a list of which displays are capable of which partial update modes?
No, this is missing yet. But I should create one, also for me to remember the capabilities of each e-paper I have.

I have added MyEPDs_UpdateInfos.pdf to GxEPD and GxEPD2.

Quote
From what I read the 4.2" display (GDEW042T2) can do it, but are there any larger ones?
No, the controller of the bigger ones has levels of grey support instead and no differential update.

I would avoid shorter partial update periods than 2 seconds with the 4.2" b/w, to get reasonable lifetime.
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

Bjack795

#815
Oct 13, 2018, 09:28 am Last Edit: Oct 13, 2018, 09:30 am by Bjack795
Hi ZinggJM!
I'm not dead  :)  and I won't make questions, just giving some news (useful or not I don't know)

Regarding this

Yes, according to description, as it provides SPI communication. But you would need to look at the demo code.

I see that they have updated their Wiki page:

No, according to the Wiki page, you need more RAM for the demo:

It looks like the demo code can now be downloaded
About this kit:

I've asked to Waveshare and effectively the Wemos D32 pro fulfills the memory requirements but of course it's not software supported.
(I attach their answer)

Maybe in the next future I will give a try on that looking at the demo code, this was just to answer to your "you need more RAM for the demo".

There is enough RAM for this in the D32.

Regards

Bjack795







wkoszyk

Hello,

I've got huge problems with making 7.5" BW Waveshare e-paper display to work. I've connected wires to my NodeMCU v3 like on attached image (default wiring from waveshare connected like on tutorial I've seen somewhere on google):





I'm trying to get to work example from GxEPD library called "GxEPD_SPI_TestExample". I've changed two things in the default code:

1) Uncommented appriopiate library
Code: [Select]
#include <GxGDEW075T8/GxGDEW075T8.cpp>      // 7.5" b/w

2) Changed pins (I've got BUSY connected to D6 - that's the only difference from the instructions from examples, but I've also tried having that on D2 - no change)
Code: [Select]
// GxIO_SPI(SPIClass& spi, int8_t cs, int8_t dc, int8_t rst = -1, int8_t bl = -1);
GxIO_Class io(SPI, D8, D3, D4);
// GxGDEP015OC1(GxIO& io, uint8_t rst = D4, uint8_t busy = D2);
GxEPD_Class display(io, D4, D6);


Code compiles, starts, writes in Serial Monitor that it's drawing some shapes and the result is that completely nothing happens on the screen. It's all the time set as default (waveshare logo etc.). I've tried also on Wemos D1 Mini - same result. What I'm doing wrong?

ZinggJM

@wkoszyk,

The default wiring used by GxEPD is the suggested wiring as documented in the examples and in the library:

Code: [Select]
// mapping suggestion from Waveshare SPI e-Paper to Wemos D1 mini
// BUSY -> D2, RST -> D4, DC -> D3, CS -> D8, CLK -> D5, DIN -> D7, GND -> GND, 3.3V -> 3.3V

// mapping suggestion from Waveshare SPI e-Paper to generic ESP8266
// BUSY -> GPIO4, RST -> GPIO2, DC -> GPIO0, CS -> GPIO15, CLK -> GPIO14, DIN -> GPIO13, GND -> GND, 3.3V -> 3.3V



Both wirings are same; some boards use inking with GPIO numbers, some use Dx names.

Waveshare use a different default wiring, I think two pins are exchanged.

For GxEPD you either use the default wiring, or you adapt the values in the constructors to your wiring.

The examples of the actual version of GxEPD should be easier to understand and adapt:

Code: [Select]
#if defined(ESP8266)

// for SPI pin definitions see e.g.:
// C:\Users\xxx\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\variants\generic\common.h

GxIO_Class io(SPI, /*CS=D8*/ SS, /*DC=D3*/ 0, /*RST=D4*/ 2); // arbitrary selection of D3(=0), D4(=2), selected for default of GxEPD_Class
GxEPD_Class display(io /*RST=D4*/ /*BUSY=D2*/); // default selection of D4(=2), D2(=4)
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

Go Up