Go Down

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

teo8976

#855
Nov 07, 2018, 12:14 pm Last Edit: Nov 07, 2018, 01:45 pm by teo8976
In summary, the display (or its HAT) with all its pins connected (haven't tested with some of them disconnected) for some reason  causes a short high spike in voltage on CS=GPIO15 both when the ESP is reset and when power supply is switched on.
Sad news. I have disconnected GPIO15 from CS (left CS unconnected, so the display wouldn't be usable, just for testing the voltage spike), and left everything else as in my last described experiment.

The spike can still be observed on GPIO15 (connected to nothing!!), it's on the processor side, even though it only happens if the display is connected. And it does cause the wrong boot mode (though less often and only on external supply), which confirms it's not just the processor actively flashing GPIO15 afterwards during the boot process.

Anyway, if I can use GPIO12 instead of 15 and 15 is not needed anymore, I guess I can try putting a 1k pulldown resistor on it.
Heck, I could even ground it if I don't use it, right? Oh I gues probably not, because of this
Quote
on ESP8266 you can't use the SS pin for anything else, if you use SPI

teo8976

I think you can use MISO for input only, because the SPIClass will set the pin to INPUT.
The SPI class hard-codedly sets the pin to INPUT even though it allows you to use it for something else other than MISO?

ZinggJM

Yes, afaik. You can check in the source, it is not so hard to understand.
C:\Users\xxx\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.2\libraries\SPI
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.

Bjack795

Hi @ZinggJM,
I had an idea on how I can solve my problem of large/fast contradiction.

It could be possibile to use two screens.
One big (7.5") on which the refresh would be slow, giving the idea of the whole text.
One small (1.54") with fast partial refresh representing a zoom of the active text (few words before and after the cursor), useful for the current modifications to the text.

Do you think that this could be a good idea?
There could be some technical issues in managing two epapers at once?

Thank you


ZinggJM

Hi Bjack795,

this is theoretically possible. GxEPD has an example GxEPD_MultiDisplayExample, but does not support overlapped operation on multiple displays (wait for not BUSY is blocking).

And it may not be pleasant for the user during the flashing refresh of the 7.5" display.
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.

Bjack795

Hi Bjack795,

this is theoretically possible. GxEPD has an example GxEPD_MultiDisplayExample, but does not support overlapped operation on multiple displays (wait for not BUSY is blocking).

And it may not be pleasant for the user during the flashing refresh of the 7.5" display.

So in practice one screen that is refreshing is blocking the refreshing of the other?

I could use a second board only receiving via Serial the characters to print and managing the second screen

ZinggJM

Or use a multi-thread OS or environment. GxEPD and GxEPD2 use SPI with transactions and should be thread-safe. But I have no experience with multi-threading on 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.

Bjack795

Or use a multi-thread OS or environment. GxEPD and GxEPD2 use SPI with transactions and should be thread-safe. But I have no experience with multi-threading on Arduino.
I don't know what it is, so the choice would be a second small arduino board only doing that work.

Thank you!

Bjack795

#863
Nov 09, 2018, 03:02 pm Last Edit: Nov 09, 2018, 03:03 pm by Bjack795
I was looking at the 7.5" specs and I noticed something that I don't understand.

Looking at this this from waveshare I see 6 seconds of full refresh.

But shouldn't it be the same panel as this from good display that has 1.49 seconds of full refresh, driven by the same universal SPI shield from waveshare?

And all in all I remember that in the library the full refresh time is indicated as 4.5 seconds.

So apparently we have the same panel with three different values of refresh?
I'm certainly missing something.

ZinggJM

The value from Good Display is too optimistic, maybe they measure somehow the visible flashing time.
The value from Waveshare is correct, maybe a bit pessimistic, but may include SW overhead.
The value I publish is the measured BUSY active time, without SW overhead.

So there is no true value, it depends on what you look at.
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.

Bjack795

The value from Good Display is too optimistic, maybe they measure somehow the visible flashing time.
The value from Waveshare is correct, maybe a bit pessimistic, but may include SW overhead.
The value I publish is the measured BUSY active time, without SW overhead.

So there is no true value, it depends on what you look at.

Perfect as always, thank you!

Bjack795

Hi!
For the "smaller screen" I'm looking at the 2.13" and the 2.9" from waveshare, are there any differences between the two on the library (partial refresh, connections etc..) for which I should prefer one or the other?
Any technical issues on one or on the other?

I've finished the coding with the 1602 LCD support so now maybe in the next weeks I will start the eink conversion.
Ordering the smaller (and cheaper :) ) screen of the project.

ZinggJM

Hi

There is a good reason to prefer the 2.9" b/w over the 2.13" b/w.

The 2.13" b/w GDE0213B1 has several drawbacks.

The visible physical dimensions of the panel is 122 * 250.

See GxGDE0213B1.h

Code: [Select]
// the physical number of pixels (for controller parameter)
#define GxGDE0213B1_X_PIXELS 128
#define GxGDE0213B1_Y_PIXELS 250

// the logical width and height of the display
#define GxGDE0213B1_WIDTH GxGDE0213B1_X_PIXELS
#define GxGDE0213B1_HEIGHT GxGDE0213B1_Y_PIXELS

// note: the visible number of display pixels is 122*250, see GDEH0213B1 V3.0 Specification.pdf
#define GxGDE0213B1_VISIBLE_WIDTH 122


But for addressing the logical width needs to be a multiple of 8.

And the "entry mode" for addressing does not work with "y-increase", which is an issue with full-screen bitmaps and a nuisance for the developer of the display library.

GxEPD2 does not care about the missing pixels, so not the entire logical screen is visible.
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.

Bjack795

Hi

There is a good reason to prefer the 2.9" b/w over the 2.13" b/w.

The 2.13" b/w GDE0213B1 has several drawbacks.

The visible physical dimensions of the panel is 122 * 250.

See GxGDE0213B1.h

Code: [Select]
// the physical number of pixels (for controller parameter)
#define GxGDE0213B1_X_PIXELS 128
#define GxGDE0213B1_Y_PIXELS 250

// the logical width and height of the display
#define GxGDE0213B1_WIDTH GxGDE0213B1_X_PIXELS
#define GxGDE0213B1_HEIGHT GxGDE0213B1_Y_PIXELS

// note: the visible number of display pixels is 122*250, see GDEH0213B1 V3.0 Specification.pdf
#define GxGDE0213B1_VISIBLE_WIDTH 122


But for addressing the logical width needs to be a multiple of 8.

And the "entry mode" for addressing does not work with "y-increase", which is an issue with full-screen bitmaps and a nuisance for the developer of the display library.

GxEPD2 does not care about the missing pixels, so not the entire logical screen is visible.

Uh wow, I understand.
Thanks to the developer of the display library for the advice!
I'll go with the 2.9".
have I to use the GxEPD2 or the GxEPD?
I mean they are the same with one the update of the other or they cover different screens?

ZinggJM

GxEPD2 is the newer and cleaned up version, with a better SW structure.

GxEPD2 is now directly available through Library Manager.

GxEPD2 is easier to use and offers to set the template parameter page_height to adapt memory use for paged drawing.
It supports paged drawing using picture loop like in u8g2, in addition to paged drawing using draw callbacks.
It also supports full buffered drawing with page_height set to display height. Use display() instead of update().

GxEPD and GxEPD2 support the same e-paper displays I have. GxEPD will continue to be supported, because it is more widely in use.

Jean-Marc
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