ESP8266 Community Forum

I added a C Lua module for ePaper, see my project page for details:

https://hackaday.io/project/20466-wifi-epaper

I forked the nodemcu-firmware Github repository, here are the changes:

https://github.com/FrankBuss/nodemcu-fi ... f694403cf3

It is working, but still a bit of a hack with the long blocking delays which might cause trouble with the WiFi stack, and I run into memory problems with normal update scheme which requires to delete the previous image first. But if there is any interest, I can try to improve it.

Any ideas how to get rid of the blocking delays? Can I create timer callbacks from within the C code, or should I implement a lower-level interface in C for e.g. just transferring one line of image data and then implement the rest in Lua?

Great stuff Frank! Can I suggest you create a PR for the upstream project? I believe you stand a much better chance at engaging the committers into a discussion.

I don't know if it is not too early for a PR. There are major hacks, like I hardcoded all pins and the constant temperature setting, and the Lua interface could be better, like more functions, e.g. clear screen or partial updates.

And in general SPI can be a shared bus. Maybe would be better if the user initializes it with the SPI module first, and then the EPD module just calls the SPI functions? Of course, this would definitely require the implementations of the now unimplemented framework function platform_spi_select, because the ePaper requires control over the CS signal in software.

But removing the blocking delay would be most important. I found in the documentation that it is implemented with a busy loop comparing the internal CPU clock (docs/en/lua-developer-faq.md and "#define os_delay_us ets_delay_us"). 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. Then I even wouldn't need to fix my code

PS: thanks for your nodemcu-firmware docker image

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