Waveshare e-paper displays with SPI

[bogus105]

UlrichKu - do you recommend esp8266-12e for this display? Does it have enough room inside to store, say 100 full screen bitmaps in memory to display them randomly on 2.9inch e-paper? I guess SD card is a must in this case.

[UlrichKu]

Does it have enough room inside to store, say 100 full screen bitmaps in memory to display them randomly on 2.9inch e-paper?

One image would have 5kb (stored in the format of the display). So you could fit approx. 200 images in the 1MB of the chip.

But my question would be: Why would you want to?

[bogus105]

I'd like to make a small gadget for my son (he's 20 months old). He likes letters and digits so much so the gadget should be battery powered for long time (hence e-paper) and have just one button - this button will display random letter or digit in random font style. And then he will guess what letter/digit is it and will be happy:)

[ZinggJM]

I'd like to make a small gadget for my son (he's 20 months old). He likes letters and digits so much so the gadget should be battery powered for long time (hence e-paper) and have just one button - this button will display random letter or digit in random font style. And then he will guess what letter/digit is it and will be happy:)

Please be careful with bare EPD and children: a broken EPD glass releases toxic fluid.
Maybe adding a touch overlay is enough to protect the EPD glass, but this format is uncommon.

[bogus105]

Thank you for warning. I plan to hide EPD behind plexiglass shield anyway. I know my son - shield is a must:)

[vstrelk]

Ok, have fun.
I got this working - sort of.
And created a pull request to show you my code.

However it is working quite nicely:
Especially the double or tripple flickering of a full screen update is not present with it (probably some sort of configuration in the different LUT or the different command parameter).
And of course it is faster.

I tried you changes and it really works for my 1,5 ws epd.

UlrichKu - could you share a code for testing particular
GxGDEH029A1::updatePartial(uint16_t y1, uint16_t y2)?

[UlrichKu]

UlrichKu - could you share a code for testing particular
GxGDEH029A1::updatePartial(uint16_t y1, uint16_t y2)?

I was pondering a bit about it but I don't think I get the meaning of your question. :-)

And in any case my code is nothing that anyone should try out at the moment.

[bytecrusher]

Hi,
i use a waveshare 2.9" with an esp32.
First of all: thanks for the library and the example sketch.
I know ZinggJM have currently no experience in drawing bitmaps on the display.
Maybe someone can help me.
I already have running the gxedp library and the example sketch. Ich can show bitmaps in fullscreen and text at all. (  display.drawBitmap(BitmapExample1, sizeof(BitmapExample1)); )
But when i try to show particular bitmaps ( display.drawBitmap(0, 0, BitmapExample1, GxEPD_WIDTH, h, GxEPD_BLACK); ), the bitmap always shows mirrored.
In the libraries itself i didn't find any hint to this.
maybe someone have an idea?
thanks.

[UlrichKu]

I already have running the gxedp library and the example sketch. Ich can show bitmaps in fullscreen and text at all.
But when i try to show particular bitmaps, the bitmap always shows mirrored.

Which of the "drawBitmap" functions are you using. There is one with 2 and one with 6 parameters.
I take it the one with 6 should be working correctly?

[bytecrusher]

the one with less parameters (fullscreen) works well.
the other one with 6 parameters does not, as expected.
It shows the image too, but its mirrored. I can resize it or put it to defines coordinates.

[ZinggJM]

Preliminary support for partial update and paged drawing (AVR, low RAM), for test.
To use on AVR (UNO, NANO) Arduino IDE 1.8.x is required (optimizing linker) for code space.
Only for GxGDEP015OC1 and GxGDEH029A1 for now. More tests to be done; use cases?

Added to GxEPD on GitHub: https://github.com/ZinggJM/GxEPD

Added Warning: use level converters or series resistors with UNO, NANO or MEGA.

[UlrichKu]

Preliminary support for partial update and paged drawing (AVR, low RAM), for test.

Works also on my GxGDEH029A1.

The new updateWindow (also) does not consider rotation?
Is the doubled _writeData block with the two delay(300) deliberate?

Funnily I had uncommited local code which also got rid of the numerous _wakeUp calls. :-)

As an idea for improvement (for me) I also thought of an automatic tracking of one or two update windows. So a library user could just invoke an "updateMyLatetestChanges" without actually knowing which window this would be.

[TeK32]

Jean-Marc, thank you for adding support for ESP32. This works great as already mentioned!

[ZinggJM]

Works also on my GxGDEH029A1.

The new updateWindow (also) does not consider rotation?
Is the doubled _writeData block with the two delay(300) deliberate?

Funnily I had uncommited local code which also got rid of the numerous _wakeUp calls. :-)

As an idea for improvement (for me) I also thought of an automatic tracking of one or two update windows. So a library user could just invoke an "updateMyLatetestChanges" without actually knowing which window this would be.

By design, rotation is handled on drawing only, in method drawPixel, not on update to display, and not on direct drawing of bitmaps.

Edit: now I see the point: parameters of updateWindow should be logical points, not physical, should be transformed to physical address. I will fix this.

I think of adding a drawBitmap to buffer method with mirroring, for the bitorder of the demo bitmaps.

The doubled write seems required for subsequent partial updates, same as in demo code, I did not check about the delay.

I still consider my GxEPD library as an example, a starting point for users. I am open for modification suggestions, but major extensions are best handled by cloning it.

[ZinggJM]

...
I know ZinggJM have currently no experience in drawing bitmaps on the display.
...
But when i try to show particular bitmaps ( display.drawBitmap(0, 0, BitmapExample1, GxEPD_WIDTH, h, GxEPD_BLACK); ), the bitmap always shows mirrored.
In the libraries itself i didn't find any hint to this.
maybe someone have an idea?
thanks.

It used to work, as I know from experience earlier.

But the compiler now correctly calculates uint_16(200)*int(200) to be a negative number, even in a expression with uint16_t result.

This is now fixed (at least from my current experience), and per default bitmaps are now mirrored correctly for the example bitmaps in drawBitmap to buffer.

Added preliminary support for partial update and paged drawing also for GxGDE0213B1.

Other enhancements are pending.