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.

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.

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?

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.

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.

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.

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.

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?

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.