summaryrefslogtreecommitdiffstats
path: root/_log/e-reader.md
diff options
context:
space:
mode:
authorSadeep Madurange <sadeep@asciimx.com>2025-12-20 21:36:45 +0800
committerSadeep Madurange <sadeep@asciimx.com>2025-12-20 21:36:45 +0800
commite15f1076b59e997108914f6a5b9b28652d323268 (patch)
tree294b0c5da8f8410ad0aab89dd2c5d107f581e083 /_log/e-reader.md
parent31616ee1b8ff316d6558a0e7c87e4bd4211c9932 (diff)
downloadwww-e15f1076b59e997108914f6a5b9b28652d323268.tar.gz
Change website structure to a log.
Diffstat (limited to '_log/e-reader.md')
-rw-r--r--_log/e-reader.md94
1 files changed, 94 insertions, 0 deletions
diff --git a/_log/e-reader.md b/_log/e-reader.md
new file mode 100644
index 0000000..cab744a
--- /dev/null
+++ b/_log/e-reader.md
@@ -0,0 +1,94 @@
+---
+title: Experimental e-reader
+date: 2023-10-24
+layout: post
+project: true
+thumbnail: thumb_sm.png
+---
+
+This project features an experimental e-reader powered by an ESP-WROOM-32
+development board and a 7.5-inch <a href="https://www.waveshare.com/"
+class="external" target="_blank" rel="noopener noreferrer">Waveshare</a>
+e-paper display built with the intention of learning about e-paper displays.
+
+<video style="max-width:100%;" controls="" poster="poster.png">
+ <source src="ereader.mp4" type="video/mp4">
+</video>
+
+## Introduction
+
+The prototype e-reader comprises an ESP32 microcontroller, an e-paper display
+HAT, and three buttons: yellow, blue, and white for turning the page backwards,
+forwards, and putting the device to sleep, respectively. The prototype does not
+store books on the microcontroller. It streams books from a server over HTTP.
+The e-reader employs RTC memory to record the reading progress between
+sessions.
+
+The most formidable challenge when trying to build an e-reader with an ESP32 is
+its limited memory and storage. My ESP-WROOM-32 has a total of 512KB of SRAM
+and 4MB of flash memory, which the freeRTOS, ESP-IDF, and the e-reader
+application must share. To put things into perspective, a Kindle Paperwhite has
+at least 256MB of memory and 8GB of storage. That is 500x more memory than what
+I'd have to work with.
+
+Despite its size, as microcontrollers go, ESP32 is a powerful system-on-a-chip
+with a 160MHz dual-core processor and integrated WiFi. So, I thought it’d be
+amusing to embrace the constraints and build my e-reader using a $5 MCU and the
+power of C programming.
+
+## The file format
+
+The file format dictates the complexity of the embedded software. So, I’ll
+begin there. The e-reader works by downloading and rendering a rasterized
+monochrome image of a page (a .ebm file).
+
+The EBM file contains a series of bitmaps, one for each page of the book. The
+dimensions of each bitmap are equal to the size of the display. Each byte of
+the bitmap encodes information for rendering eight pixels. For my display,
+which has a resolution of 480x800, the bitmaps are laid out along 48KB
+boundaries. This simple file format lends well to HTTP streaming, which is its
+main advantage, as we will soon see.
+
+The pdftoebm.py script enclosed in the tarball at the end of the page converts
+PDF documents to EBM files.
+
+## How does it work?
+
+As the e-reader has no storage, it can't store books locally. Instead, it
+downloads pages of the EBM file over HTTP from the location pointed to by the
+`EBM_ARCH_URL` setting in the Kconfig.projbuild file on demand. To read a
+different book, we have to replace the old file with the new one or change the
+`EBM_ARCH_URL` value. The latter requires us to recompile the embedded
+software.
+
+Upon powering up, the e-reader checks the reading progress stored in the RTC
+memory. It then downloads three pages (current, previous, and next) to a
+circular buffer in DMA-capable memory. When the user turns a page by pressing a
+button, one of the microprocessor's two cores transfers it from the buffer to
+the display over a Serial Peripheral Interface (SPI). The other downloads a new
+page in the background. I used the ESP-IDF task API to schedule the two tasks
+on different cores of the multicore processor to make the reader more
+responsive.
+
+I designed the EBM format with HTTP streaming in mind. Since the pages are laid
+out in the EBM file along predictable boundaries, the e-reader can request
+pages by specifying the offset and the chunk size in the HTTP Range header. Any
+web server will process this request without custom logic.
+
+## Epilogue
+
+My fascination with e-paper began back in 2017, when I was tasked with
+installing a few displays in a car park. Having no idea how they worked, I
+remember watching the languid screens refresh like a Muggle witnessing magic.
+This project was born out of that enduring curiosity and love of e-paper
+technology.
+
+Why did I go to the trouble of building a rudimentary e-reader when I could
+easily buy a more capable commercial e-reader? First of all, it's to prove to
+myself that I can. More importantly, there's a quiet satisfaction to reading on
+hardware you built yourself. You are no longer the powerless observer watching
+the magic happen from the sidelines. You become the wizard who makes the
+invisible particles swirl into form by whispering C to them. There's only one
+way to experience that.
+
+Files: [source.tar.gz](source.tar.gz)