Go Down

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

Q24H

Hi ZinggJM,

Excellent library, didn't take long for me to get my 1.54in waveshare b/w working on the ESP32! just curious, I noticed there is a pixel and rectangle fill function, is there a simple way to draw lines? I can do vertical and horizontal with the rectangle function, but diagonally it gets tricky.

Also great to hear that you are looking into other b/w/r tri colors displays! Thanks!

witchole

is there a simple way to draw lines? I can do vertical and horizontal with the rectangle function, but diagonally it gets tricky.
The E-Paper display base class is a subclass of Adafruit_GFX, so look at the documentation for adafruit gfx graphics primitives.

in particular, you want the following methods:

Code: [Select]
void drawLine(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, uint16_t color);
void drawFastVLine(uint16_t x0, uint16_t y0, uint16_t length, uint16_t color);
void drawFastHLine(uint8_t x0, uint8_t y0, uint8_t length, uint16_t color);

witchole

I will replace the method with the old signature with a method drawExampleBitmap()
Good idea!

Having experimented further, the issue I reported originally is caused by the bm_flip_v mode: if I use that mode in the example I posted, the bitmap is displayed at the wrong co-ordinates.  I'm assuming that it is supposed to mirror the bitmap, but still display it at the same screen location.

Can you confirm this?

Also, the bm_flip_h mode doesn't appear to do anything at all.

ZinggJM

Any such issues will be investigated later, as I can't duplicate myself.
I concentrate on the small black/white/red e-papers.
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.

witchole

Any such issues will be investigated later, as I can't duplicate myself.
I concentrate on the small black/white/red e-papers.
Of course, that is a much better use of your time, and I really do appreciate all the amazing work you have put into this.

(I'm also looking forward to trying the coloured e-paper myself).

ZinggJM

My Arduino library GxEPD for e-paper displays is updated on GitHub with classes for 3-color displays 1.54", 2.13" and 2.9".

GitHub - ZinggJM/GxEPD - A simple E-Paper display library with common base class and separate IO class.

Thanks to Sponsor Eric.
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.

ZinggJM

#141
Oct 13, 2017, 09:40 am Last Edit: Oct 13, 2017, 09:43 am by ZinggJM
Im interested in learning more about the side effects of using partial updates; has anyone been brave enough to test a device with a short, say 1 second partial update cycle, and leave it running for a few weeks to see if it actually degrades/kills the display? If not, I will probably do this myself. ereaders do partial updates, and those dont seem to die quickly.

I read somewhere that you need to do a full refresh every now and then to limit the damage? No idea if that is accurate, or its its just to 'clean' the display. I also read that high temperature has a positive influence on the damage done by partial updates?

As for how it looks;  I also wonder, does the the ghosting effect get incrementally worse? If you alternate numbers from 0 to 9 in a loop, does there come a point where you cant read the number anymore and it becomes a smear, or is the ghosting just fairly constant and with every partial refresh, you also get a "partial cleaning" ?

You asked for use cases earlier; here is my use case: a glider variometer (vertical speed indicator). This is my current prototype:

https://youtu.be/7Zbjo2WrcWk

It uses an OLED display to show average climb and some other info. The OLED looks great as long as there is no direct sunlight; which unfortunately makes it useless in a glider.  There arent many alternatives either; I will also test sharp memory displays, but those are hard to find. And newhaven has some small sunlight readable TFTs but with precious little arduino support.

So Im looking at eink. A refresh rate of 1 per second, or maybe a few seconds is acceptable here, minutes is clearly not. Whats also not acceptable is doing periodic full refreshes: that would just be too distracting in a cockpit. However, a short life span is acceptable to me. The glider flies no more than maybe 100 hours per year. If I need to replace a €7 display every year, so be it. I'll just stockpile them :).
I got the following answer from Dalian Good Display for your question:

Quote
With great pleasure to receive your email.
I read the question, and I think your answer is good and correct.

 Here is the video show our 1.54 inch e-paper, in new code, quick full screen update ( realized by partial refresh function)

https://youtu.be/M8kAfMiLMRY

If keep refreshing like this, there will be ghosting after dozens of pictures.

But for 1.54'', the ghosting is slight, while for 2.13 and 2.9 inch will be obvious.

Also because each customer's acceptable level of ghosting is different, so hard to give out a precise level, need to test themselves.

Another point it, e-paper is not that suitable for projects that require quick refreshing all the time.

Although customer do not care about lifetime, it still against the natural feature of e-paper display.

But in another hand, from technical point of view, e ink is always trying to realize faster and faster refreshing, also with more colors, also with larger size.

There is still a long way for e ink technology to go,  but obviously, will be a bright future.


At last, about the suitable display for sunlight readable needed projects, as I know, there are several choices:

1)      Reflective type monochrome lcd display

2)      Transflective TFT lcd display

3)      Transmissive TFT lcd display, but with super high brightness ( We have one 5.6 inch TFT module, with 800-1600cd/m2 brightness, had been used on outdoor monitor for UAV)

4)      E-paper display (We have customers that use e-papers on motorcycle or similar.)

 
But for this case, size is small, recommend to try more with e-paper displays.

And my test shows that the 1.54inch black/white e-paper display can be used with continuous partial updates every second, but shows some degradation after 9 days. So I recommend at least one full update per day for continuous use.

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.

witchole

And my test shows that the 1.54inch black/white e-paper display can be used with continuous partial updates every second, but shows some degradation after 9 days. So I recommend at least one full update per day for continuous use.
Very useful, thanks J-M!

What about the specified lifetime of "5 years or 1 million update cycles" - is there any sign of permanent degradation on your screen now?  You must have performed close to a million partial updates.


ZinggJM

I just restarted the test to find out, and the display looks as good as new.

I will modify my test code to do one full update per day for the 1.54" display, and start another long term test.

I do the long term test only for the 1.54", as this is the only e-paper I have 2 spares of it.

I initially bought the demo system with 2 1.54" e-paper displays from Dalian Good Display, and it was worth every cent, as you can see from my interest in e-paper displays.
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.

ZinggJM

Good idea!

Having experimented further, the issue I reported originally is caused by the bm_flip_v mode: if I use that mode in the example I posted, the bitmap is displayed at the wrong co-ordinates.  I'm assuming that it is supposed to mirror the bitmap, but still display it at the same screen location.

Can you confirm this?

Also, the bm_flip_h mode doesn't appear to do anything at all.
... and bm_flip_h and bm_flip_v are also "flipped"!

With the updated version bm_flip_h and bm_flip_v are deprecated and replaced by bm_flip_x and bm_flip_y.

drawBitmap to buffer is fixed to flip bitmaps in place for non-fullscreen bitmaps; bm_flip_x and bm_flip_y are both implemented.

bm_flip_h and bm_flip_v will be removed when all display classes are updated.

Note that bm_flip_y for drawBitmap to screen is not available for 2.13" b/w, as the controller of this display does not support y-increment ram data entry mode.
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.

witchole

With the updated version bm_flip_h and bm_flip_v are deprecated and replaced by bm_flip_x and bm_flip_y.

drawBitmap to buffer is fixed to flip bitmaps in place for non-fullscreen bitmaps; bm_flip_x and bm_flip_y are both implemented.
Great work Jean-Marc!

It now works correctly on the 1.54" B/W display, and the new naming is clearer, thanks.

vertigo72

Thanks a lot for the 'endurance' test. That looks promising!  I'll add my own results later, as I received my 1.54" waveshare display today.  However, I cant make it work.

Im using the adafruit huzzah32 (ESP32). I wired it like this:

3.3 > 3.3
GND > GND
CS > 17
RESET > 5
DC > 16
DIN > 23
CLK > 18
BUSY > 19

(following this example:https://www.youtube.com/watch?v=AeYbX0zaJTY)

I commented out
Code: [Select]
#include <GxGDEP015OC1/GxGDEP015OC1.cpp>    // 1.54" b/w

And modified the pinout here:

Code: [Select]
#elif defined(ESP32)

// pins_arduino.h, e.g. LOLIN32
//static const uint8_t SS    = 5;
//static const uint8_t MOSI  = 23;
//static const uint8_t MISO  = 19;
//static const uint8_t SCK   = 18;

// GxIO_SPI(SPIClass& spi, int8_t cs, int8_t dc, int8_t rst = -1, int8_t bl = -1);
GxIO_Class io(SPI, 17, 16, 5); // arbitrary selection of 17, 16
// GxGDEP015OC1(GxIO& io, uint8_t rst = D4, uint8_t busy = D2);
GxEPD_Class display(io, 5,19); // arbitrary selection of (16), 4


When I run the test example,  the serial monitor shows:

setup
setup done
Busy Timeout!
Busy Timeout!
Busy Timeout!
Busy Timeout!
Busy Timeout!

And the display istn doing anything. Idea's?

ZinggJM

I have not installed the package for huzzah32, and do not intend to install it.
So I can't check the wiring for hardware or standard SPI for it. Nor the defaults and implementation of its SPI class.

But when using SPI, I would avoid to use the standard SS pin for anything else than CS.

So I propose to use SS for CS, and use some other pin for RST.
Maybe you have continuous reset to your display, or no reset to wake it up.

Busy Timeout indicates that either the display or some other source ties your busy pin continuously low.
Wrong busy wiring could produce this, but with the timeout the display might still work, but slower.

The continued endurance test shows noticeable degradation after 10 hours, but clean again after restart.
So I will reduce the full update period to 6 hours for next test.
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.

vertigo72

Yeay, I got it working!  Thanks for pushing me in the right direction. Turns out there is no default SS pin on this board and I had everything else wrong too :).

Being a newbie, I did have a hard mapping the commented constants with the pins on the board to the pins on the display and with the calls for the class.  In case it helps anyone else:

GxIO_Class io(SPI, A, B, C);


A="slave select"   =  CS on the display -> I chose 21 on ESP (there is no default SS pin on this board!)
B=" DC "            =  DC  on the display ->I chose 23 on ESP
C= "Reset"          =  RST on the display ->I chose 22 on ESP

GxEPD_Class display(io, D, E);

D="Reset"           =  RST on the display ->I chose 22on ESP
E= "Busy"            =  BUSY on the display ->I chose 17 on ESP

Furthermore,

CLK on the display should be connected to  SCK on the ESP
DIN on the display should be connected to  MOSI on the ESP

Okay, off to do some real testing now :)

ZinggJM

#149
Oct 17, 2017, 08:54 am Last Edit: Oct 19, 2017, 10:46 am by ZinggJM Reason: ESP32 issue
My wife just told me I should learn to speak "Newbie-Language"! :)

I will try to add example mappings to the examples for ESP32 also.

First I had to re-discover how to get the ESP32 package, this time the actual one, it also contains feather_esp32:

GitHub - espressif/arduino-esp32: Arduino core for the ESP32

Then I downloaded the package as zip-file, unpacked it, and copied it to Arduino/hardware (I renamed it to remove "-master").

This does not work; there is a document in .docs how to install esp32.

So I just changed the path of the package to:
C:\Users\ZinggJ\Documents\Arduino\hardware\espressif\esp32
and double clicked:
C:\Users\ZinggJ\Documents\Arduino\hardware\espressif\esp32\tools\get.exe

This compiler obviously is more strict than the (assumed same) compiler for ESP8266; it produces warnings with the examples.
But it compiled anyway with my settings in preferences.


And in a subdirectory the variants can be found, e.g.:

C:\Users\ZinggJ\Documents\Arduino\hardware\espressif\esp32\variants\feather_esp32\pins_arduino.h

And of course the SPI pins can be found there, including SS:

Code: [Select]
static const uint8_t LED_BUILTIN = 13;
#define BUILTIN_LED  LED_BUILTIN // backward compatibility

static const uint8_t TX = 17;
static const uint8_t RX = 16;

static const uint8_t SDA = 23;
static const uint8_t SCL = 22;

static const uint8_t SS    = 2;
static const uint8_t MOSI  = 18;
static const uint8_t MISO  = 19;
static const uint8_t SCK   = 5;


These pin definitions are different from the LOLIN32 I have - I hope they are correct - so I can't provide a general mapping suggestion for ESP32.

Most variants have this SPI mapping, but there are various different ones:

Code: [Select]
static const uint8_t SS    = 5;
static const uint8_t MOSI  = 23;
static const uint8_t MISO  = 19;
static const uint8_t SCK   = 18;
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