Go Down

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

bytecrusher

Hey ZinggJM,
the coordinate 0,0 is now in the upper right corner, but it seems to be in the upper left corner, right?
Is this issue only on not fullscreen bitmaps?
Thanks.
regards bytecrusher

ZinggJM

The 0,0 coordinates are now at the origin of the display screen, the way the screen is addressed by the controller. This was not the case before, because of the y-decrement Ram Data Entry Mode used by the display class, combined with the un-mirroring code I had added for the display buffer.
For the buffered graphics you just use setRotation as you need.

For the direct drawing of bitmaps to the screen I have kept the original orientation; one flip mode is already implemented, more may be added later.

I currently spend too much time on this, need to slow down a bit, but will try to fix reported errors as soon as possible.
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

Waveshare 2.9inch display is now also supported by u8g2, available with Library Manager.

It is on GitHub: https://github.com/olikraus/U8g2_Arduino
 
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

#78
Sep 10, 2017, 05:25 pm Last Edit: Sep 26, 2017, 07:40 am by ZinggJM
I noticed that Waveshare has several shops on AliExpress, so I provide some links for e-papers here:

Waveshare Electronics

WS Development Tool Store

Waveshare Development Kit Store

Development Board Store

There may be more, and the prices may differ, and the e-papers sold also
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.

bytecrusher

Hi,

does anybody know a way to print a degree sign ° on the display?
thanks.

ZinggJM

Hi,

does anybody know a way to print a degree sign ° on the display?
thanks.
I had this need also. For one of my OLED displays I had found a font that has this symbol.
For one of my e-paper displays I used drawing text at cursor positions, and draw an "o" separately at elevated position.

Searching for a font with this symbol, and with same format as the free fonts is not high on my priority, but I will gladly add such a font to GxEPD.

Are there free font compatible fonts that contain additional symbols, such as ° ?
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.

bytecrusher

Hi ZinggJM,

another posibility would be to draw a circle, or to create a custom icon.
This will also work for me.
so, not to much effort for searching a font for it.
Thanks.

bytecrusher

#82
Sep 12, 2017, 11:13 pm Last Edit: Sep 12, 2017, 11:35 pm by bytecrusher
Hi ZinggJM,

i trying to do some partial update, but it doesn't work as i expected. what am i do wrong?
first i made display.drawBitmap and do display.update (something like a boot screen).
in the next step i clear the screen with display.fillScreen and print some text with display.println.
now i want to update some partial with display.print again and display.updatewindow with the correct coordinates.
but thats what happened now:
i get the screen with the drawbitmap again and only the partial text. But not the text i print before.
this sounds like the text is not in the same memory as the picture? am i right?

Update: maybe i fond my issue: after the display.update i have to make a display.updatewindow without rotation. now it works.
But, on every updatewindow the display lost a bit of contrast. is it possible to fix this?

UlrichKu

Update: maybe i fond my issue: after the display.update i have to make a display.updatewindow without rotation. now it works.
But, on every updatewindow the display lost a bit of contrast. is it possible to fix this?
I take it that there are some hidden "features" in those displays still. Like this flashing between two screen contents...
To avoid this the display content needs to be written a second time to the display memory after the first update finishes (wait until not busy). This is what updateWindow does. Your first update call should be superfluous.

The "partial update" doesn't really do a partial update - at least not from the perspective of the display. That one always draws the full area.
What it does is a fast(er) update that is missing the double flashing that really refreshes all the pixel. So after some fast updates there should always be a full update to improve unchanged pixels.

ZinggJM

#84
Sep 13, 2017, 10:35 am Last Edit: Sep 13, 2017, 11:01 am by ZinggJM
Hi ZinggJM,
...
Update: maybe i fond my issue: after the display.update i have to make a display.updatewindow without rotation. now it works.
But, on every updatewindow the display lost a bit of contrast. is it possible to fix this?
Did you forget to call update() after the first println?

I assume you use the 2.9inch display.

A display.updateWindow to the full screen is required to avoid strange effects. Loss of contrast occurs after many partial updates or after long delay without full refresh.

Did you observe this also with the PartialUpdateExample?, or modification of it with more repetitions and longer delays?

You could also post your example for investigation. Thank you for the feedback.
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

I take it that there are some hidden "features" in those displays still. Like this flashing between two screen contents...
To avoid this the display content needs to be written a second time to the display memory after the first update finishes (wait until not busy). This is what updateWindow does. Your first update call should be superfluous.

The "partial update" doesn't really do a partial update - at least not from the perspective of the display. That one always draws the full area.
What it does is a fast(er) update that is missing the double flashing that really refreshes all the pixel. So after some fast updates there should always be a full update to improve unchanged pixels.
I am not sure if this is really so. I see a difference between the displays that have partial update with separate partial update LUT (waveform table), and those that have only some of the functions needed for partial update, and even in between those.

The e-paper display controllers use double buffering; one buffer contains the new data for refresh, and one for the old data. It looks like for full update the old data is used to first turn the display to full white, then the new data to produce the picture. For partial update the difference is used to turn the pixels that need be changed.
And turning pixels happens in multiple steps or phases.
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.

bytecrusher

Did you forget to call update() after the first println?

I assume you use the 2.9inch display.

A display.updateWindow to the full screen is required to avoid strange effects. Loss of contrast occurs after many partial updates or after long delay without full refresh.

Did you observe this also with the PartialUpdateExample?, or modification of it with more repetitions and longer delays?

You could also post your example for investigation. Thank you for the feedback.
Yes, i didn't call update(), because i thought if i use updatewindow this will be enough.
Yes, your right. I use the 2.9inch one.
A few weeks ago, i tried an example from waveshare and did notice the issue with the contrast.
Then i tried your library with partialupdate and i didn't notice the contrast lost.
But today i notice again the lost of contrast. Maybe i am wrong with my remember to no lost contrast. This might be the only explanation.

bytecrusher

Attached you will find a short example of my code.
Here i have the following situation:
not every pixel has the lost contrast issue.
only, that pixel that is in the updatewindow area.
Not every pixel of a number has the same contrast.

is there any other way, to update partial area (or the hole screen), without flickering?

jpg63

Vous trouverez ci-joint une petite demo utilisant un ecran 1,54 pouce. Cet example pourra peut être servir à d'autre, il presente le futur ecran de notre variometre


ZinggJM

#89
Sep 16, 2017, 09:33 am Last Edit: Sep 16, 2017, 05:12 pm by ZinggJM
Attached you will find a short example of my code.
Here i have the following situation:
not every pixel has the lost contrast issue.
only, that pixel that is in the updatewindow area.
Not every pixel of a number has the same contrast.

is there any other way, to update partial area (or the hole screen), without flickering?
I have re-introduced delays of 2 x 300ms in the partial update code, that was present in the demo code from Waveshare. This delay is now declared as a macro #define PU_DELAY 300 in the classes .cpp files to allow easy experimentation. It should improve contrast degradation.

Note that these e-paper displays have a specified lifetime of 5 years or 1'000'000 update cycles.
So they are not really suitable for 1s update cycles (as in your example with the modification), which could result in serious degradation or end of life after 12 days. You can download the specification from good-display.com.

I found one specification with more details on lifetime:



So update interval should be at least 3 minutes of long lifetime.

Fortunately I took this interval for my temperature and humidity 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.

Go Up