color gdeh042Z96 400x300 B|R - martinberlin/cale-idf GitHub Wiki
- Size: 400 * 300 4.2" Black/Red
- Controller: SSD1619
- Status: Implemented and merged in master
- Refresh time: 15 seconds (measured until last red flash)
- NOTE: This class will be moved into color directory soon
Buy this GDEH042Z96 epaper here
Statistics in milliseconds
This is a fast controller, it receives the full buffer in 108 millis, powers up and starts rendering in 2 seconds.
108 _wakeUp settings+send Buffer 2004 _powerOn 2113 total time in millis
Curiosities of this display
First detail is that for some reason that is out of my scope sending the buffer progressively from start to end, SPI optimized from the start in this model, rendered everything correctly but mirrored. So I had to invert the X axis in the drawPixel method:
x = width()-x;
It works but actually drawPixel should not be aware of this display controller oddities. Is not a problem, but it kinds of bug me, that I need to mirror it on the GFX method that should take care only of graphics and not be display aware. But as there is a separate class for each display, it won't matter much, and I'm not that a C++ purity angel so feel free to suggest a better placement or just send a pull request.
And second detail is that the black RAM buffer, sent with SPI command 0x24, is not the same as in other controllers:
A White pixel in RAM(BW) = 1 A Black pixel in RAM(BW) = 0
So 8 white pixels in the black part of the RAM will be: 0xFF (In most displays is 0x00)
| 1 | 1 | 1 | 1 | 1 | 1 |² 1 |¹ 1 | 1 byte 0xFF
But Red is not the same. For the red buffer that is sent after SPI command 0x26, things look back to normal:
A Red pixel in RAM(RED) = 1 A White pixel in RAM(RED) = 0
Same as in other models a 0xFF will make 8 red pixels and a byte like this:
| 0 | 0 | 0 | 0 | 0 | 0 |² 0 |¹ 0 | 0x00 will render 8 white pixels.
It just works right and once the CalEPD class is made you can just implement it and will abstract all this for you.