ZinggJM:
...
And the current GxIO_SPI only works correctly on ESP8266 and ESP32, because the setFrequency() method only works for these. I work on a fix for this. For these displays max SPI frequency is 4MHz.
...
Interim fix applied to GxIO_SPI, GxEPD updated on GitHub GitHub - ZinggJM/GxEPD: A simple E-Paper display library with common base class and separate IO class for Arduino.
Hi. Thank's for this library. I'm using it with a nodemcu (esp8266) and a Waveshare 2.9 e-paper. And it works showing decent text in my case.
However I am trying to write a "partial update" function and I am a bit at a loss understanding the protocol used in communicating with the display. Also and especially after looking in the datasheet by Waveshare. :o
There seems to be some code/communication dedicated to this (_SetRamArea, _SetRamPointer)? But I don't understand the parameters used there and if they really are what I hope them to be.
ZinggJM:
...
Fourth, I will provide a new version of the small e-paper GxEPD classes for AVR (UNO and Nano) with reduced buffer and support for bitmaps in PROGMEM. Only the reduced part of the display will be available for use with Adafruit_GFX. An initial version for 2.9inch runs on my Nano. But this is not my priority.
...
And finally the idea trickled into my head ("s'zwänzgi isch abegheit") - I had a short look at U8g2, for a ST7565 display. Divide the display into 4 pages, let the user draw or print his picture 4 times, each time updating one page window to the display using the "partial update" function of these displays.
Not really my recommendation to use UNO or Nano with e-paper displays, but interesting coding practice for me anyway.
UlrichKu:
Hi. Thank's for this library. I'm using it with a nodemcu (esp8266) and a Waveshare 2.9 e-paper. And it works showing decent text in my case.However I am trying to write a "partial update" function and I am a bit at a loss understanding the protocol used in communicating with the display. Also and especially after looking in the datasheet by Waveshare. :o
There seems to be some code/communication dedicated to this (_SetRamArea, _SetRamPointer)? But I don't understand the parameters used there and if they really are what I hope them to be.
I wrote my last post at the same time, there you can see that I intend to use partial update.
And Good Display have the actual demo code available on their downloade page, with improved partial update.
http://www.good-display.com/download_list/downloadcategoryid=35&isMode=false.html
(_SetRamArea, _SetRamPointer) basically are the same functions as for TFT displays (e.g. setWindow or setWindowAddress), but the x-address is not a pixel number but a byte address (x/8). This fact, combined with the missing read GRAM function, makes direct pixel draw to GRAM impossible.
ZinggJM:
I wrote my last post at the same time, there you can see that I intend to use partial update.
I noticed that. 
Funny conincidence.
However in my case I'm looking for it to speedup thing and/or improve redraw.
ZinggJM:
And Good Display have the actual demo code available on their downloade page, with improved partial update.
What environment does this target? My knowledge stops as C++ and Arduino IDE at the moment.
ZinggJM:
(_SetRamArea, _SetRamPointer) basically are the same functions as for TFT displays (e.g. setWindow or setWindowAddress), but the x-address is not a pixel number but a byte address (x/8). This fact, combined with the missing read GRAM function, makes direct pixel draw to GRAM impossible.
But you could update ie only 8 pixels (1 byte) with this if you wanted to?
The demo code is for STM32 using Keil5 programming environment. The - earlier version of the - code is the base of the waveshare code and of my GxEPD display classes.
Write single byte may be possible, I have no experience, but display update time will not be shorter than for a full line, I guess.
ZinggJM:
Write single byte may be possible, I have no experience, but display update time will not be shorter than for a full line, I guess.
Probably not. The question was just if I understood this correctly.
So one would:
?
May well be the case, I would need to look at the code. But I have no time, guest coming. Bye for now.
ZinggJM:
May well be the case, I would need to look at the code. But I have no time, guest coming. Bye for now.
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.
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.
bogus105:
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?
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:)
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:)
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.
Thank you for warning. I plan to hide EPD behind plexiglass shield anyway. I know my son - shield is a must:)
UlrichKu:
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)?
vstrelk:
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.
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.
bytecrusher:
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?
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.