A long time has passed since my last update. My plan is to build a homebrew tablet or e-book reader using a NanoPi board and an E-Ink screen. I got as far as driving the screen with the NanoPi, using most of the available GPIO and also
the CPU's PWM functionality for speed, but then realized that I don't know how to set about designing a case. Also, my old 3D printer broke down around then. So the project stagnated for a (long) while.

Now I'm trying again. This time around, I want to try to make things more modular. Instead of driving the display directly, I'm using a dedicated microcontroller to handle the display. The NanoPi communicates with it using SPI. This means that I'm not driving the display directly, but this way has several advantages:

First, the display has quite a lot of I/O lines that need to be hooked up. With the new setup, any complicated wiring is only between the microcontroller and the display, and with the MCU integrated into some future PCB, even that wiring would be done away with. Also, now that I'm using the microcontroller's GPIO pins, the parent board's I/O is free to be used for other things. And if I want to control the screen with a board that doesn't have so much I/O, like an ESP8266 board, I should still be able to do so, without having to use a shift register that might really slow things down.

Also, driving the display has some realtime timing considerations, and it's difficult to handle them in a Linux environment, while it's much easier to handle them in a dedicated microcontroller.

Finally, if I want to control the screen with an ESP8266 or some other board, I don't have to rewrite my driver code, I can just reuse the same controller.

So far I've hooked up an STM32 "Blue Pill" board, rewritten my driver code again to run on it, and got some basic functionality working: Blanking the screen and drawing rectangles.

The breadboard in the back has a few SPI RAM chips, as the STM32F103C8 on the "Blue Pill" doesn't have enough RAM for the 4-bit double-buffered 800x600 framebuffer I'm planning.

A friend of mine suggested using an ESP32 instead, as those are cheap, seem to have enough GPIO pins, and have lots of RAM, without the need for any extra chips. It may even be powerful enough as to not require a parent board. So maybe I'll be rewriting my controller code again soon.