ESP8266 Community Forum

- Sun Apr 16, 2017 2:57 am #64993

This is an amazing display, for sure!

I would think about adding this as a display in u8g(2)lib https://github.com/olikraus/u8g2. You'd get graphic primitives for free

u8g2 looks like a good and small graphics library. Would be useful to integrate my code to it, then it would be available for other microcontrollers as well. Do you plan to integrate it in NodeMCU? Currently there is only u8g.

Note, there is a newer version of the original code for the EPD display:

https://github.com/embeddedartists/grat ... n/epd_v2.c

This doesn't work with my display, because I have the revision C hardware with a now obsolete version of the actual ePaper. Currently they sell revision D, with newer ePaper with even higher contrast. And looks like they changed the update sequence for it: in the original Raspberry Pi code for my display, they required to send the inverse version of the old image first, before sending the new display, with additional steps for inverse version of the new display and full black and white stages. This is bad for microcontrollers with low memory. The new code (with the new hardware) does only the reverse version of the new image, then two other stages, possibly full black and full white, then the new image. The code looks also much cleaner than their original Raspberry Pi code (which I already cleaned up a bit in my version).

I think I should base my code on the new version of their code and buy the new version of the display. I can buy it from Digikey with other parts I need for my project. I can buy one display for you, too, and send it to you, to save shipping costs. If you want to port their code, I'll send you the display for free

Another really useful feature would be partial updates of the display, which is currently not possible with the original code or my port, but the hardware should allow it, because you can update individual lines and you can specify for each pixel if the hardware driver should turn it on, turn it off or do nothing for it (the line format needs 2 bits per pixel).

Does your library support bit blits? Once I wrote a Lua graphics library for my http://luaplayer.org where I could create offscreen images and blit it to the screen, and with support for loading and printing True Type fonts. But of course, this is not possible for many small microcontrollers. But I really would like to have a fast method to blit a whole display content with a string as the input, as with my only function of my current code.

- Sun Apr 16, 2017 3:19 am #64994 PS: if someone doesn't need the broken display detection or the ID verification, MISO is not needed. So might be a good idea for the SPI module to add a function to change the pin mode for MISO back to GPIO as well, as it is possible with the not implemented platform_spi_select function. Maybe something general in the SPI module to switch back any lines you want (except clock), because for some applications it might be useful to have only MISO and have MOSI as a GPIO pin.

- Mon Apr 17, 2017 1:47 am #65019

Regardless of possible problems with interfering with the WiFi stack, this is very bad for power consumption, because of the long required delays up to hundreds of milliseconds for the ePaper and might be in general a good idea to fix this, e.g. for os_delay_us with parameters > 100 use a different implementation with CPU sleep, interrupts and possibly triggering the watchdog.

Note that tmr.delay() will go away sooner or later anyway: https://github.com/nodemcu/nodemcu-firmware/issues/1892

https://frightanic.com/
https://nodemcu-build.com/
https://github.com/marcelstoer/nodemcu-pyflasher

- Fri May 12, 2017 5:58 pm #65870 This project is awesome! What is the largest panel that you would be able to power with only solar? A 10 inch+ would be amazing!