is there a simple way to draw lines? I can do vertical and horizontal with the rectangle function, but diagonally it gets tricky.
void drawLine(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, uint16_t color);void drawFastVLine(uint16_t x0, uint16_t y0, uint16_t length, uint16_t color);void drawFastHLine(uint8_t x0, uint8_t y0, uint8_t length, uint16_t color);
I will replace the method with the old signature with a method drawExampleBitmap()
Any such issues will be investigated later, as I can't duplicate myself.I concentrate on the small black/white/red e-papers.
Im interested in learning more about the side effects of using partial updates; has anyone been brave enough to test a device with a short, say 1 second partial update cycle, and leave it running for a few weeks to see if it actually degrades/kills the display? If not, I will probably do this myself. ereaders do partial updates, and those dont seem to die quickly.I read somewhere that you need to do a full refresh every now and then to limit the damage? No idea if that is accurate, or its its just to 'clean' the display. I also read that high temperature has a positive influence on the damage done by partial updates?As for how it looks; I also wonder, does the the ghosting effect get incrementally worse? If you alternate numbers from 0 to 9 in a loop, does there come a point where you cant read the number anymore and it becomes a smear, or is the ghosting just fairly constant and with every partial refresh, you also get a "partial cleaning" ?You asked for use cases earlier; here is my use case: a glider variometer (vertical speed indicator). This is my current prototype:https://youtu.be/7Zbjo2WrcWkIt uses an OLED display to show average climb and some other info. The OLED looks great as long as there is no direct sunlight; which unfortunately makes it useless in a glider. There arent many alternatives either; I will also test sharp memory displays, but those are hard to find. And newhaven has some small sunlight readable TFTs but with precious little arduino support.So Im looking at eink. A refresh rate of 1 per second, or maybe a few seconds is acceptable here, minutes is clearly not. Whats also not acceptable is doing periodic full refreshes: that would just be too distracting in a cockpit. However, a short life span is acceptable to me. The glider flies no more than maybe 100 hours per year. If I need to replace a €7 display every year, so be it. I'll just stockpile them .
With great pleasure to receive your email.I read the question, and I think your answer is good and correct. Here is the video show our 1.54 inch e-paper, in new code, quick full screen update ( realized by partial refresh function)https://youtu.be/M8kAfMiLMRYIf keep refreshing like this, there will be ghosting after dozens of pictures.But for 1.54'', the ghosting is slight, while for 2.13 and 2.9 inch will be obvious.Also because each customer's acceptable level of ghosting is different, so hard to give out a precise level, need to test themselves.Another point it, e-paper is not that suitable for projects that require quick refreshing all the time.Although customer do not care about lifetime, it still against the natural feature of e-paper display.But in another hand, from technical point of view, e ink is always trying to realize faster and faster refreshing, also with more colors, also with larger size.There is still a long way for e ink technology to go, but obviously, will be a bright future.At last, about the suitable display for sunlight readable needed projects, as I know, there are several choices:1) Reflective type monochrome lcd display 2) Transflective TFT lcd display3) Transmissive TFT lcd display, but with super high brightness ( We have one 5.6 inch TFT module, with 800-1600cd/m2 brightness, had been used on outdoor monitor for UAV)4) E-paper display (We have customers that use e-papers on motorcycle or similar.) But for this case, size is small, recommend to try more with e-paper displays.
And my test shows that the 1.54inch black/white e-paper display can be used with continuous partial updates every second, but shows some degradation after 9 days. So I recommend at least one full update per day for continuous use.
Good idea!Having experimented further, the issue I reported originally is caused by the bm_flip_v mode: if I use that mode in the example I posted, the bitmap is displayed at the wrong co-ordinates. I'm assuming that it is supposed to mirror the bitmap, but still display it at the same screen location.Can you confirm this?Also, the bm_flip_h mode doesn't appear to do anything at all.
With the updated version bm_flip_h and bm_flip_v are deprecated and replaced by bm_flip_x and bm_flip_y.drawBitmap to buffer is fixed to flip bitmaps in place for non-fullscreen bitmaps; bm_flip_x and bm_flip_y are both implemented.
#include <GxGDEP015OC1/GxGDEP015OC1.cpp> // 1.54" b/w
#elif defined(ESP32)// pins_arduino.h, e.g. LOLIN32//static const uint8_t SS = 5;//static const uint8_t MOSI = 23;//static const uint8_t MISO = 19;//static const uint8_t SCK = 18;// GxIO_SPI(SPIClass& spi, int8_t cs, int8_t dc, int8_t rst = -1, int8_t bl = -1);GxIO_Class io(SPI, 17, 16, 5); // arbitrary selection of 17, 16// GxGDEP015OC1(GxIO& io, uint8_t rst = D4, uint8_t busy = D2);GxEPD_Class display(io, 5,19); // arbitrary selection of (16), 4
static const uint8_t LED_BUILTIN = 13;#define BUILTIN_LED LED_BUILTIN // backward compatibilitystatic const uint8_t TX = 17;static const uint8_t RX = 16;static const uint8_t SDA = 23;static const uint8_t SCL = 22;static const uint8_t SS = 2;static const uint8_t MOSI = 18;static const uint8_t MISO = 19;static const uint8_t SCK = 5;
static const uint8_t SS = 5;static const uint8_t MOSI = 23;static const uint8_t MISO = 19;static const uint8_t SCK = 18;