docs: Add questions for the board owner to clarify hardware and feature requirements for mainline.py porting.
This commit is contained in:
@@ -134,3 +134,58 @@ Things that are plausibly relevant but entirely absent from the codebase:
|
||||
- **Deep sleep / low-power modes.** The firmware uses `millis()`-based timing and a display-off state, but never enters ESP32 deep sleep. Whether the hardware supports wake-on-touch or wake-on-WiFi is not explored.
|
||||
- **Audio hardware.** The Hosyond boards support external speakers per their datasheets, and the codebase has no audio code. The Waveshare board does not appear to have onboard audio.
|
||||
- **SD card.** The Waveshare board has a TF card slot (CS via CH422G EXIO4), and the Hosyond boards have TF card slots as well. The firmware does not use storage.
|
||||
|
||||
---
|
||||
|
||||
## Questions for board owner
|
||||
|
||||
I'm looking at porting [mainline.py](mainline.py) — a scrolling terminal news/poetry stream with OTF-font rendering, RSS feeds, ANSI gradients, and glitch effects — to run on one of these boards. To figure out the right approach I need a few things only you can answer:
|
||||
|
||||
### 1. Which board should I target?
|
||||
|
||||
The three boards have very different constraints:
|
||||
|
||||
| | Board 1 (2.8″) | Board 2 (4.0″) | Board 3 (4.3″) |
|
||||
|---|---|---|---|
|
||||
| Resolution | 320 × 240 | 320 × 480 | 800 × 480 |
|
||||
| Display bus | SPI (40 MHz) | SPI (40 MHz) | RGB parallel (14 MHz pclk) |
|
||||
| Flash | 4 MB | 4 MB | 16 MB |
|
||||
| PSRAM | unknown | unknown | 8 MB |
|
||||
| Full-screen redraw | ~60 ms+ | ~120 ms+ | near-instant (framebuffer) |
|
||||
|
||||
Board 3 is the only one with enough RAM and display bandwidth for smooth scrolling with many headlines buffered. Boards 1 & 2 would need aggressive feature cuts. **Which board do you want this on?**
|
||||
|
||||
### 2. PSRAM on your ESP32-32E boards
|
||||
|
||||
The build flags say `-DBOARD_HAS_PSRAM` but I can't tell the capacity. Can you check? Easiest way:
|
||||
|
||||
```
|
||||
// Add to setup() temporarily:
|
||||
Serial.printf("PSRAM size: %d bytes\n", ESP.getPsramSize());
|
||||
Serial.printf("Free PSRAM: %d bytes\n", ESP.getFreePsram());
|
||||
```
|
||||
|
||||
If PSRAM is 0 on Boards 1 or 2, those boards can only hold a handful of headlines in 520 KB SRAM (WiFi + TLS eat most of it).
|
||||
|
||||
### 3. Feature priorities
|
||||
|
||||
mainline.py does a lot of things that don't map directly to an ESP32 + TFT. Which of these matter to you?
|
||||
|
||||
- **RSS headline scrolling** — the core experience. How many feeds? All ~25, or a curated subset?
|
||||
- **OTF font rendering** — mainline uses Pillow to rasterize a custom `.otf` font into half-block characters. On ESP32 this would become either bitmap fonts or a pre-rendered glyph atlas baked into flash. Is the specific font important, or is the aesthetic (large, stylized text) what matters?
|
||||
- **Left-to-right color gradient** — the white-hot → green → black fade. Easy to replicate in RGB565 on the TFT. Keep?
|
||||
- **Glitch / noise effects** — the ░▒▓█ and katakana rain. Keep?
|
||||
- **Mic-reactive glitch intensity** — none of these boards have a microphone. Drop entirely, or substitute with something else (e.g. touch-reactive, or time-of-day reactive)?
|
||||
- **Auto-translation** — mainline translates headlines for region-specific sources via Google Translate. This requires HTTPS calls that are expensive on ESP32 (~40–50 KB RAM per TLS connection). Keep, pre-translate on a server, or drop?
|
||||
- **Poetry mode** — fetches full Gutenberg texts. These are large (100+ KB each). Cache to SD card, trim to a small set, or drop?
|
||||
- **Content filtering** — the sports/vapid regex filter. Trivial to keep.
|
||||
- **Boot sequence animation** — the typewriter-style boot log. Keep?
|
||||
|
||||
### 4. Network environment
|
||||
|
||||
- Will the board be on a WiFi network that can reach the public internet (RSS feeds, Google Translate, ntfy.sh)?
|
||||
- Is there a preferred SSID / network, or should it use the existing multi-network setup from the doorbell firmware?
|
||||
|
||||
### 5. SD card availability
|
||||
|
||||
All three boards have TF card slots but the doorbell firmware doesn't use them. A microSD card would be useful for caching fonts, pre-rendered glyph atlases, or translated headline buffers. **Is there an SD card in the board you'd want to target?**
|
||||
|
||||
Reference in New Issue
Block a user