From 577aa865c2f53a46a5869b1e4dda69dc06d0a962 Mon Sep 17 00:00:00 2001 From: Sadeep Madurange Date: Mon, 5 Jan 2026 12:17:09 +0800 Subject: Tighten e-reader prose. --- _site/log/e-reader/index.html | 72 +++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 41 deletions(-) (limited to '_site/log/e-reader/index.html') diff --git a/_site/log/e-reader/index.html b/_site/log/e-reader/index.html index a5dbc01..41f58ff 100644 --- a/_site/log/e-reader/index.html +++ b/_site/log/e-reader/index.html @@ -3,7 +3,7 @@ - ESP32 e-reader prototype + ESP32 prototype e-reader @@ -37,7 +37,7 @@
-

ESP32 E-READER PROTOTYPE

+

ESP32 PROTOTYPE E-READER

24 OCTOBER 2023

First project with e-paper displays and ESP32.

@@ -46,61 +46,51 @@ -

System: ESP-WROOM-32, 7.5” Waveshare e-paper display, three buttons +

ESP-WROOM-32, 7.5” Waveshare e-paper display, three-button interface (prev/next/sleep).

-

2023-09-23: 512KB SRAM, 4MB flash (shared with FreeRTOS and ESP-IDF). Not -enough storage for books. Using ESP32’s built-in WiFi to stream them over HTTP. -Recording the reading progress in RTC memory.

+

Memory: 512KB SRAM + 4MB flash–insufficient for local library. Streams via +HTTP Range requests over WiFi. Reading progress saved to RTC memory; persists +through deep sleep.

-

Rasterized pages encoded as tightly packed bitmaps (1 byte => 8 pixels), no -headers, arranged along 48 KB (480x800) boundaries; Reader can stream pages -using HTTP Range requests with zero server-side logic. Keeps both ends lean.

+

EBM format: Raw bitmap sequence. 1 byte = 8 pixels, 1 page = 48 KB (display +resolution), headerless. Optimized for HTTP Range requests:

-

Page table stores 3 pages (prev/current/next) in a circular buffer. When the -user requests a page, program cycles through the table, updates the screen, and -downloads the next page.

+
int r0 = ((page_n - 1) * PAGE_SIZE);
+int rn = page_n * PAGE_SIZE - 1;
 
-
Responsiveness is inadequate. Scheduling GPIO (user input), SPI, and HTTP on
-one core causes input lag. Pinned the GPIO and SPI tasks to one core, the HTTP
-task to the other core.

+int n = snprintf(NULL, 0, "bytes=%d-%d", r0, rn) + 1;
+char *buf = malloc(sizeof(char) * n);
+snprintf(buf, n, "bytes=%d-%d", r0, rn);
 
-
Better, but screen updates are blocking user input; Made SPI transfer async:

-
-
void epd_draw_async(const uint8_t *buf, size_t n)
-{
-    static spi_transaction_t t[3];
+esp_http_client_set_header(http_client, "Range", buf);
+esp_http_client_perform(http_client);
+

 
-    memset(&t[0], 0, sizeof(t[0])); 
-    t[0].length = 8;
-    t[0].tx_data[0] = 0x13;
-    t[0].user = (void*) 0; 
-    t[0].flags = SPI_TRANS_USE_TXDATA;
+
Page buffer: Three pages (prev/current/next) in RAM—maximum possible. On
+request: cycles buffer, updates screen, prefetches next page.

 
-    memset(&t[1], 0, sizeof(t[1])); 
-    t[1].length = 8 * n;
-    t[1].tx_buffer = buf;
-    t[1].user = (void*) 1; 
+
c_page_num++;
+pg.page_num = c_page_num + 2;
+pg.page_buf = pages[(c_page_num + 1) % PAGE_LEN];
 
-    memset(&t[2], 0, sizeof(t[2])); 
-    t[2].length = 8;
-    t[2].tx_data[0] = 0x12;
-    t[2].user = (void*) 0; 
-    t[2].flags = SPI_TRANS_USE_TXDATA;
+xSemaphoreGive(mutex);
+xQueueSend(http_evt_queue, &pg, portMAX_DELAY);
 
-    for (int i = 0; i < 3; i++)
-        spi_device_queue_trans(spi, &t[i], portMAX_DELAY);
-}
+epd_draw_async(pages[c_page_num % PAGE_LEN], PAGE_SIZE);
+epd_draw_await();
 

 
-
Much better.

+
Responsiveness: inadequate. Scheduling GPIO, SPI, and HTTP tasks on a single
+thread causes input lag. Pinned GPIO/SPI tasks to one core and the HTTP task to
+the other.

 
-
2023-10-06: Moved the page table to DMA-capable memory; Reclaimed a few more
-CPU cycles from the SPI transfers.

+
Better, but screen updates block user input. Moved SPI buffers to DMA and made
+transfers async. Few more cycles saved.

 
 
Can’t think of anything else.

 
-
Verdict: Works but limited. Led to Etlas.

+
Verdict: Functional but limited. Led to Etlas.

 
 
Commit:
 7f691c4

-- 
cgit v1.2.3