9ba8687743
ePaper panels rendered rotated/misaligned on AVR and RP2040 (e.g. the 2.13"
Pico clock came out sideways and clipped). The ESP32 worker decoder was just
taught to compose in the controller's native RAM geometry and rotate to the
display orientation, but the browser-side SSD168xDecoder (used by AVR/RP2040)
still composed at display dims with no rotation, so the two diverged.
- SSD168xDecoder.ts: port the worker's native-window compose + rotation.
* Size RAM to the longer side both ways so a rotated native layout
(128x296 behind a 296x128 panel) isn't truncated.
* Compose in the active RAM window, then rotate via the inverse of
Adafruit_GFX setRotation(1). Detect orientation by BYTE width so a
non-multiple-of-8 native width (the 2.13" panel is 122 px) is handled.
* Track the UNION of windows per frame: paged drivers (GxEPD2 page height
< panel) set one partial window per page, so compose must use the full
native area, not just the last page's strip. Fixes the all-white render
on paged panels (1.54" Uno, 4.2" Pico, 7.5" ESP32).
* Add an isBwr option: B/W panels treat 0x26 as a 2nd mono plane (white
only if both planes white), tri-colour panels keep red-wins.
* Default the active window to display geometry; the firmware overrides it.
- EPaperPart.ts: pass isBwr = cfg.palette === 'bwr' to the decoder.
- esp32_spi_slaves.py / esp32_worker.py: mirror the byte-aware rotation +
window-union in the worker, and derive is_bwr from panel_kind on the
runtime sensor_attach path too (fixes the tri-colour ESP32 alert badge).
- test_epaper/ssd168x_decoder.py: re-port the golden reference to match
(keeps the 3-way TS/Python/worker identity invariant). Tests updated to
construct tri-colour cases with is_bwr/palette='bwr'.
- examples-displays-epaper.ts: the Pico VCC wire referenced '3V3(OUT)',
which the velxio-pi-pico-w element doesn't expose (it has '3V3'), so the
wire snapped to the board corner. Use '3V3'.
|
||
|---|---|---|
| .. | ||
| autosearch | ||
| sketches | ||
| README.md | ||
| __init__.py | ||
| ssd168x_decoder.py | ||
| test_compile_helloworld.py | ||
| test_ssd168x_protocol.py | ||
| test_uc8159c_protocol.py | ||
README.md
test_epaper — ePaper / e-Ink display emulation
Workspace for adding ePaper (electrophoretic) display support to Velxio.
Built off the ILI9341 / SSD1306 patterns already living in
frontend/src/simulation/parts/ComplexParts.ts
and frontend/src/simulation/parts/ProtocolParts.ts.
Layout
test_epaper/
├── README.md ← this file
├── autosearch/ ← research dossier (markdown only)
│ ├── 00_overview.md ← what ePaper is + why emulation differs
│ ├── 01_seeed_models.md ← target panels from seeedstudio.com
│ ├── 02_controllers.md ← SSD1675 / SSD1681 / UC8159 / IT8951 …
│ ├── 03_spi_protocol.md ← command/data framing, BUSY pin, refresh sequence
│ ├── 04_arduino_libraries.md ← GxEPD2, Adafruit_EPD, Pervasive matrix
│ ├── 05_velxio_existing.md ← how SSD1306 + ILI9341 are wired today
│ ├── 06_svg_layouts.md ← physical dimensions for the SVG components
│ └── 07_emulation_plan.md ← phased implementation plan
├── datasheets/ ← controller PDFs (gitignored — fetched on demand)
├── sketches/ ← Arduino sketches used by the E2E tests
└── test_*.py / test_*.ts ← actual tests (TBD)
Status
- Research phase: read
autosearch/to see what's been investigated. - Tests phase: pytest tests verify SPI protocol decoding without QEMU; sketch tests verify cross-board compilation; E2E pixel-buffer tests come last (blocked on emulator scaffold).
How to run (when tests exist)
# Pure Python protocol decoder tests (no backend, no QEMU)
pytest test/test_epaper/ -v
# Cross-board sketch compile (requires backend on :8765)
VELXIO_BACKEND_URL=http://127.0.0.1:8765 pytest test/test_epaper/test_compile_*.py -v