Tighten e-reader prose.

1 files changed, 34 insertions, 43 deletions

diff --git a/_log/e-reader.md b/_log/e-reader.md
index fbc7b94..87417f7 100644
--- a/_log/e-reader.md
+++ b/_log/e-reader.md
@@ -1,5 +1,5 @@
 ---
-title: ESP32 e-reader prototype
+title: ESP32 prototype e-reader 
 date: 2023-10-24
 layout: post
 project: true
@@ -12,62 +12,53 @@ First project with e-paper displays and ESP32.
   <source src="ereader.mp4" type="video/mp4">
 </video>
 
-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;
+
+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);
 
-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.
+esp_http_client_set_header(http_client, "Range", buf);
+esp_http_client_perform(http_client);
+```
 
-Better, but screen updates are blocking user input; Made SPI transfer async:
+Page buffer: Three pages (prev/current/next) in RAM—maximum possible. On
+request: cycles buffer, updates screen, prefetches next page.
 
 ```
-void epd_draw_async(const uint8_t *buf, size_t n)
-{
-    static spi_transaction_t t[3];
-
-    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;
-
-    memset(&t[1], 0, sizeof(t[1])); 
-    t[1].length = 8 * n;
-    t[1].tx_buffer = buf;
-    t[1].user = (void*) 1; 
-
-    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;
-
-    for (int i = 0; i < 3; i++)
-        spi_device_queue_trans(spi, &t[i], portMAX_DELAY);
-}
+c_page_num++;
+pg.page_num = c_page_num + 2;
+pg.page_buf = pages[(c_page_num + 1) % PAGE_LEN];
+
+xSemaphoreGive(mutex);
+xQueueSend(http_evt_queue, &pg, 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](../etlas/).
+Verdict: Functional but limited. Led to [Etlas](../etlas/).
 
 Commit:
 [7f691c4](https://git.asciimx.com/esp32-e-reader/commit/?id=7f691c46093933b67aab466c0ca582ace8ab73d4)