Add Panel-Aware Local OLED Display Service
This commit is contained in:
+8
-6
@@ -37,7 +37,7 @@ These constraints apply across all phases:
|
||||
| 5A | Authenticated HTTPS administration foundation | **Complete** |
|
||||
| 5B | Offline xterm.js WebSocket serial terminal | **Complete** |
|
||||
| 6 | Authenticated SSH serial transport | **Complete** |
|
||||
| 7 | Local display and button interface | **In progress (7B)** |
|
||||
| 7 | Local display and button interface | **In progress (7C)** |
|
||||
| 8 | Security and production hardening | **Planned** |
|
||||
| 9 | Authenticated, rollback-capable OTA | **Planned** |
|
||||
| 10 | BLE serial transport and provisioning evaluation | **Planned** |
|
||||
@@ -184,7 +184,7 @@ The order below is the current plan. Phase 7 is in progress; later phases remain
|
||||
|
||||
Add a standalone local status/control interface without making it a dependency of the serial core. The planning baseline uses a 128×64 dual-color monochrome I²C OLED sold with an SSD1315 controller. Phase 7A confirmed SSD1306-compatible operation, 7-bit I²C address `0x3c`, orientation, column mapping, contrast/inversion behavior, button inputs, and the physical color geometry on the selected hardware.
|
||||
|
||||
Phase 7A diagnostics and target-hardware electrical validation are complete. Phase 7 overall remains in progress with Phase 7B next; Phases 7B through 7E are not complete.
|
||||
Phase 7A diagnostics and target-hardware electrical validation are complete. Phase 7B display-driver validation is complete; Phase 7 overall remains in progress (7C). Phases 7C through 7E are not complete.
|
||||
|
||||
#### Hardware baseline
|
||||
|
||||
@@ -206,10 +206,12 @@ The persistent yellow strip is reserved for serial-service state, Wi-Fi strength
|
||||
- Bounded low-level display and button diagnostics are available under the existing `debug` submenu.
|
||||
- The selected module acknowledged at 7-bit `0x3c` (8-bit `0x78` write / `0x79` read). A guarded full scan is retained for the dedicated local-UI bus; an absent display remains nonfatal and does not make the serial core dependent on the OLED.
|
||||
- Hardware validation passed for geometry, orientation, row/column addressing, contrast, inversion, button pull-ups/debounce/short-press/long-press/stuck behavior, and the color geometry: yellow rows 0–15, blue rows 16–63, with a physical black separator between the regions.
|
||||
2. **Phase 7B — Display driver — Planned**
|
||||
- Place the SSD1315 behind a small local panel interface and use ESP-IDF's SSD1306-compatible support if hardware testing confirms compatibility.
|
||||
- Use a bounded 1 KiB 128×64 framebuffer, a compact 5×7 font, and a small project-owned status-icon set; do not add LVGL for this fixed monochrome UI.
|
||||
- Prefer dirty 8-pixel-page updates, bounded I²C transaction timeouts, and nonfatal recovery after a missing or unresponsive display.
|
||||
2. **Phase 7B — Display driver — Complete**
|
||||
- The `local_display` service owns the local I²C bus, SSD1315-compatible panel, and framebuffer. It uses a static 1 KiB 128×64 framebuffer, a compact 5×7 uppercase/digit/punctuation renderer, and an internal mutex; do not add LVGL for this fixed monochrome UI.
|
||||
- Rendering treats the yellow 128×16 status panel (rows 0–15) and blue 128×48 content panel (rows 16–63) as separate panels so the physical divider remains clear.
|
||||
- Frame commits refresh only dirty 8-pixel pages. I²C runs at 100 kHz with bounded transactions.
|
||||
- The display bus initializes at boot; a known display is automatically initialized and cleared. A missing or unresponsive display is nonfatal and does not make the serial core dependent on it.
|
||||
- Target-hardware validation passed for initialization, all display diagnostic patterns, the rendered panel layout and physical divider, row 15/16 boundary, contrast, inversion, display-off/reinitialization, and button diagnostics. Observed contrast control has a useful brightness range of 1–255.
|
||||
3. **Phase 7C — Read-only status UI — Planned**
|
||||
- Build display state from existing serial, Wi-Fi, broker, USB, WebSocket, HTTPS, and SSH snapshot APIs rather than parsing CLI output or reaching into transport internals.
|
||||
- Provide overview, RS-232/modem, broker-client/writer, and network/service pages.
|
||||
|
||||
Reference in New Issue
Block a user