Go Down

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

ZinggJM

This should be simple. The device has 32kB RAM, so the ~5kB display buffer is no problem.

I need to fix the GxIO_SPI class for AVR and SAM or all non-ESP processors, and will add SAMD.
I will make sure it compiles with SAMD, and try to check it with my MKR-1000 (sitting idle in some drawer waiting to be used).

I can't promise a deadline, but should be ready in less than a week or so.
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.

jpg63

Thank you
No problem for the delai, it will be a pleasure to use your library when it is ready

bogus105

Sorry i'm not writing everyday ZinggJM nut i'm at work and i can't read this forum every day:)

Youv'e said you compiled Waveshare string example on Uno/Nano with no issues.
How?

I use Arduino IDE 1.6.8

When attempt to compile original 'string.ino' example from waveshare i got error: global variables use 3 313 bytes (161%) od dynamic memory, leaving -1 265 bytes for local variables. Maxiumum is 2 048 bytes.

So 'string' exmple simply won't fit in Uno/Nano:/

I also tried to load an example from your library: GxEPD_SPI_TestExample
The following errors came up:

Code: [Select]


In file included from C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.cpp:31:0,

                 from C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master\examples\GxEPD_SPI_TestExample\GxEPD_SPI_TestExample.ino:37:

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:37:30: warning: integer overflow in expression [-Woverflow]

 #define GxGDEH029A1_Y_PIXELS 296

                              ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:41:28: note: in expansion of macro 'GxGDEH029A1_Y_PIXELS'

 #define GxGDEH029A1_HEIGHT GxGDEH029A1_Y_PIXELS

                            ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:43:53: note: in expansion of macro 'GxGDEH029A1_HEIGHT'

 #define GxGDEH029A1_BUFFER_SIZE GxGDEH029A1_WIDTH * GxGDEH029A1_HEIGHT / 8

                                                     ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:85:21: note: in expansion of macro 'GxGDEH029A1_BUFFER_SIZE'

     uint8_t _buffer[GxGDEH029A1_BUFFER_SIZE];

                     ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:85:44: error: overflow in constant expression

     uint8_t _buffer[GxGDEH029A1_BUFFER_SIZE];

                                            ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:85:44: error: size of array '_buffer' is negative

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.cpp: In member function 'virtual void GxGDEH029A1::fillScreen(uint16_t)':

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:37:30: warning: integer overflow in expression [-Woverflow]

 #define GxGDEH029A1_Y_PIXELS 296

                              ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:41:28: note: in expansion of macro 'GxGDEH029A1_Y_PIXELS'

 #define GxGDEH029A1_HEIGHT GxGDEH029A1_Y_PIXELS

                            ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:43:53: note: in expansion of macro 'GxGDEH029A1_HEIGHT'

 #define GxGDEH029A1_BUFFER_SIZE GxGDEH029A1_WIDTH * GxGDEH029A1_HEIGHT / 8

                                                     ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.cpp:112:28: note: in expansion of macro 'GxGDEH029A1_BUFFER_SIZE'

   for (uint16_t x = 0; x < GxGDEH029A1_BUFFER_SIZE; x++)

                            ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.cpp: In member function 'virtual void GxGDEH029A1::drawBitmap(const uint8_t*, uint32_t)':

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:37:30: warning: integer overflow in expression [-Woverflow]

 #define GxGDEH029A1_Y_PIXELS 296

                              ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:41:28: note: in expansion of macro 'GxGDEH029A1_Y_PIXELS'

 #define GxGDEH029A1_HEIGHT GxGDEH029A1_Y_PIXELS

                            ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.h:43:53: note: in expansion of macro 'GxGDEH029A1_HEIGHT'

 #define GxGDEH029A1_BUFFER_SIZE GxGDEH029A1_WIDTH * GxGDEH029A1_HEIGHT / 8

                                                     ^

C:\Users\Raport\Documents\Arduino\libraries\GxEPD-master/GxGDEH029A1/GxGDEH029A1.cpp:147:28: note: in expansion of macro 'GxGDEH029A1_BUFFER_SIZE'

   for (uint32_t i = 0; i < GxGDEH029A1_BUFFER_SIZE; i++)

                            ^

exit status 1
Error compiling for board Arduino Nano.


Does it mean it's not suitable for Arduino Nano because of Nano's poor memory reservours?
Have a good day.

ZinggJM

Now you have understood what I need from you if I should try to help you.

First, as I already told you, the waveshare string example can be successfully compiled for Arduino Nano.
I did not yet try to run it on my Nano, but I have it ready complete with level converter.

Second, the current version of my GxEPD on GitHub is not suitable for UNO or Nano, as it needs a buffer of ~5kB in RAM. 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.

Third, you need to upgrade your Arduino IDE to the actual version (1.8.3) to compile the waveshare string example, as I already told you. And GxEPD most likely will need version 1.8.x, at least for UNO, Nano.

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.

Bear in mind that I am a hobby Arduino user like you; I do this for fun, and provide help only as long as I consider it a pleasure.
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.

bogus105

Now i understand:) Thank you for your time. Your reply convinced me to order esp8266. Too much constrains with Nano - RAM size being the most anoying.
I'll try to change IDE to the newest one but as i said - i can play with arduino at work only and IDE must be installed by company's administrator (he's not at work now and it's not easy to convience him to do it thanks to company policy:(:(:(

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 https://github.com/ZinggJM/GxEPD
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.

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.

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.
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

#23
Jul 29, 2017, 10:52 am Last Edit: Jul 29, 2017, 11:01 am by ZinggJM
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.
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.

UlrichKu

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.

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.

UlrichKu

(_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?

ZinggJM

#26
Jul 29, 2017, 11:05 am Last Edit: Jul 29, 2017, 11:10 am by ZinggJM
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.
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.

UlrichKu

#27
Jul 29, 2017, 11:17 am Last Edit: Jul 29, 2017, 11:30 am by UlrichKu
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:
* Use correct LUT
* Set ram pointer and area correctly
* Write partial data
* Update display (with 0x04 data instead of 0xc7)

?

ZinggJM

May well be the case, I would need to look at the code. But I have no time, guest coming. Bye for now.
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.

UlrichKu

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.

Go Up