Paying Bills
PCBWay graciously offered to sponsor this project. They are quite thorough with their file approval process to avoid any surprises once boards ship. Thanks PCBWay!
Introduction
The goal of this project is simple: democratize e-books. instead of repeating what I've already written, read the first project log to understand the ethos of the project. I'm writing this nearly a year after publishing that project log and I can happily say I now have a proof-of-concept for a cloud-to-hardware open source e-reading solution. For granular details take a look at the project's repository.
Hardware
Below is a high level system diagram and schematic of the project.
The heart of the e-reader's hardware is the Raspberry Pi Compute Module 4. The e-paper is GDEY042T81-FT02 from Good Display, which includes a front-light and a touchscreen. The e-paper communicates to the Compute Module via SPI. The TPS61165 from Texas Instrument's drives the front-light and the Compute Module controls brightness via PWM. A 1250 mAh lithium polymer battery powers the project. BQ24075 charges the battery, BQ27441 monitors the battery's status and reports to the Compute Module via I2C, and the TPS63701 boosts battery voltage to 5V.
Now, I would be remiss if I did not mention The Open Book by Joey Castillo. The e-paper driver he released is copy-and-pasted in this project and largely reduced the hardware hurdles nee
There is also a Raspberry Pi Hat (pre Pi 5 form factor) as well, but the carrier board is the true form factor.
Software
Below is a high level system diagram for the software
I mentioned in the intro that this project is a proof-of-concept and I'd say the most proof-of-concept-y component is the software. It's pretty meh honestly. One of the reasons I stopped updating the project was I effectively was writing an e-reader OS from scratch. The firmware for the peripherals in the hardware section (i.e driving the e-paper, reading the touchscreen, etc.) can be used as a known-good working example. The UI and application code... maybe don't use.
A would go into detail about the each software file but again... it's not very good so instead I'll talk about the major libraries and tech stacks used.
MuPDF
The heart of this project's application code is MuPDF. A comprehensive document rendering library that supports just about every e-book format. It reads documents from the filesystem, lays out the document for the screen dimension, and outputs a pixel map. The library also compiles to 60+ MB so centering this project on a microcontroller is out of the question. This leads us to the next part of the technical stack.
LVGL
Light and Versatile Graphic Library is designed for embedded systems. I could've used the Linux frame buffer to drive the e-paper display, but writing the GUI with LVGL allows me to easily port to a microcontroller if I can squeeze down MuPDF capabilities to a flash chip. Also, sending LVGL widgets to the e-paper display was much more straight forward than the frame buffer device.
Calibre
Just about every e-book lover reading this has heard of Calibre, an all in one e-book management software. You can read e-books, edit metadata, purchase e-books, and even self-host a book server. The latter is how Calibre comes into this project. The software allows one to run a web server that makes a book library available on a local network or on the world wide web with port forwarding. Put you don't need Calibre to serve books. In fact, there's an open spec for digital distribution.
OPDS
The Open Publication Distribution System is an open, decentralized way to present machine-readable catalogs to e-reader clients. If that went over your read, OPDS is to e-books as RSS feeds are to podcasts. That's an oversimplification, but it's my laymen explanation. OPDS is how the project fetches books from Calibre, and thus, the project can fetch books from any OPDS compatible server.
400x300 display... Ouch :/
Maybe you will be interested: https://github.com/Quill-OS/quill