Commander1024/ESP32_Serial_Swiss_Army_Knife
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document Phase 7 display hardware and implementation plan

Browse Source
This commit is contained in:
Commander1024
2026-08-27 16:46:08 +02:00
parent fa339a3dfa
commit bb04e0ba79
2 changed files with 125 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/phase7_display_mockup.svg
+87
View File
@@ -0,0 +1,87 @@
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="620" viewBox="0 0 960 620" role="img" aria-labelledby="title description">
<title id="title">Phase 7 dual-color OLED overview-screen mockup</title>
<desc id="description">An enlarged mockup of the proposed 128 by 64 pixel local status display. The upper sixteen rows are yellow and show service, Wi-Fi, client, writer, and alert status. The lower forty-eight rows are blue and show IP address, RS-232 configuration, modem signals, traffic counters, and page navigation. Three buttons below are labeled previous, OK, and next.</desc>
<defs>
<filter id="yellowGlow" x="-20%" y="-40%" width="140%" height="180%">
<feGaussianBlur stdDeviation="1.7" result="blur"/>
<feMerge><feMergeNode in="blur"/><feMergeNode in="SourceGraphic"/></feMerge>
</filter>
<filter id="blueGlow" x="-20%" y="-40%" width="140%" height="180%">
<feGaussianBlur stdDeviation="1.5" result="blur"/>
<feMerge><feMergeNode in="blur"/><feMergeNode in="SourceGraphic"/></feMerge>
</filter>
<linearGradient id="bezel" x1="0" y1="0" x2="0" y2="1">
<stop offset="0" stop-color="#253747"/>
<stop offset="0.5" stop-color="#14212c"/>
<stop offset="1" stop-color="#091017"/>
</linearGradient>
<radialGradient id="button" cx="42%" cy="35%" r="70%">
<stop offset="0" stop-color="#566777"/>
<stop offset="0.65" stop-color="#273440"/>
<stop offset="1" stop-color="#111920"/>
</radialGradient>
<pattern id="pixels" width="5" height="5" patternUnits="userSpaceOnUse">
<path d="M5 0H0V5" fill="none" stroke="#ffffff" stroke-opacity="0.022" stroke-width="0.45"/>
</pattern>
</defs>
<rect width="960" height="620" fill="#0b1118"/>
<text x="480" y="35" fill="#d7e3ed" font-family="sans-serif" font-size="20" font-weight="600" text-anchor="middle">Phase 7 — 128×64 local status display</text>
<rect x="55" y="55" width="850" height="470" rx="25" fill="url(#bezel)" stroke="#456074" stroke-width="3"/>
<circle cx="82" cy="82" r="9" fill="#081016" stroke="#667b8b" stroke-width="2"/>
<circle cx="878" cy="82" r="9" fill="#081016" stroke="#667b8b" stroke-width="2"/>
<circle cx="82" cy="498" r="9" fill="#081016" stroke="#667b8b" stroke-width="2"/>
<circle cx="878" cy="498" r="9" fill="#081016" stroke="#667b8b" stroke-width="2"/>
<!-- The screen is exactly 2:1. Its 320-pixel height represents 64 rows at 5x scale. -->
<rect x="160" y="95" width="640" height="320" rx="3" fill="#010406" stroke="#718696" stroke-width="2"/>
<rect x="160" y="95" width="640" height="80" fill="#1a1600"/>
<rect x="160" y="175" width="640" height="240" fill="#00121a"/>
<rect x="160" y="95" width="640" height="320" fill="url(#pixels)"/>
<line x1="160" y1="175" x2="800" y2="175" stroke="#77848c" stroke-opacity="0.38"/>
<g font-family="DejaVu Sans Mono, Liberation Mono, Consolas, monospace" font-size="27" font-weight="600" letter-spacing="0.2">
<g fill="#ffd52e" filter="url(#yellowGlow)">
<text x="177" y="131">SER● WIFI▮▮▮ U1 W1 S1</text>
<text x="177" y="168">WR:SSH CLIENTS:3 !:0</text>
</g>
<g fill="#20c9ff" filter="url(#blueGlow)">
<text x="177" y="211">IP 192.168.122.42</text>
<text x="177" y="251">RS232 230400 8N1</text>
<text x="177" y="291">FLOW:NONE VLD:1</text>
<text x="177" y="331">DCD0 DSR1 CTS1 RI0</text>
<text x="177" y="371">RX:1.23M TX:633</text>
<text x="177" y="408">‹ OVERVIEW 1/4 ›</text>
</g>
</g>
<g font-family="sans-serif" font-size="14" fill="#9fb0bd">
<text x="812" y="112">row 0</text>
<text x="812" y="171">row 15</text>
<text x="812" y="190">row 16</text>
<text x="812" y="414">row 63</text>
<text x="148" y="445" text-anchor="end">128 px</text>
<text x="480" y="445" text-anchor="middle">Expected split: yellow rows 0–15 · blue rows 16–63</text>
</g>
<g>
<circle cx="325" cy="493" r="37" fill="url(#button)" stroke="#728898" stroke-width="2"/>
<circle cx="480" cy="493" r="37" fill="url(#button)" stroke="#728898" stroke-width="2"/>
<circle cx="635" cy="493" r="37" fill="url(#button)" stroke="#728898" stroke-width="2"/>
<g fill="#d7e3ed" font-family="sans-serif" font-size="25" font-weight="700" text-anchor="middle">
<text x="325" y="502">◀</text>
<text x="480" y="501" font-size="18">OK</text>
<text x="635" y="502">▶</text>
</g>
<g fill="#91a4b2" font-family="sans-serif" font-size="14" text-anchor="middle">
<text x="325" y="551">previous / hold: back</text>
<text x="480" y="551">select / hold: confirm</text>
<text x="635" y="551">next</text>
</g>
</g>
<text x="480" y="593" fill="#718594" font-family="sans-serif" font-size="13" text-anchor="middle">Mockup only — final glyph metrics and the physical color boundary will be verified on hardware.</text>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 4.9 KiB

docs/roadmap.md
+38 -11
View File
@@ -181,20 +181,47 @@ The order below is the current plan. Detailed requirements should be finalized a
### Phase 7 — Local display and buttons
Add a standalone local status/control interface without making it a dependency of the serial core.
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. Its expected SSD1306-compatible command set, I²C address, orientation, column mapping, and physical color boundary must be confirmed on the actual modules before the UI layout becomes fixed.
Planned work:
#### Hardware baseline
- Select the actual display, button arrangement, electrical interface, and remaining GPIO assignment before implementation.
- Add a board-profile abstraction where required instead of scattering new pin assumptions.
- Show concise serial, Wi-Fi, service, client-count, and writer-owner status.
- Provide safe button actions for navigation and common lifecycle or writer-control operations.
- Require deliberate confirmation for destructive or security-sensitive actions.
- Avoid displaying passwords or private-key material during ordinary operation.
- Keep UART0 fully functional as the authoritative recovery interface if the display or buttons fail.
- Bound display refresh and event processing so they cannot interfere with UART or network transport timing.
- Power the OLED from 3.3 V so any module-mounted I²C pull-ups remain ESP32-safe.
- Use GPIO11 for SDA and GPIO12 for SCL. These pins are currently unused and sit in the available GPIO10–14 block on the DevKit header.
- Use three active-low buttons with pull-ups: GPIO10 for previous/back, GPIO13 for select/confirm, and GPIO14 for next.
- Use short left/right presses for page or item navigation, short select for entry, a long left press for back/home, and an explicit select hold for disruptive confirmation.
- Verify whether the module provides suitable SDA/SCL pull-ups; add external pull-ups to 3.3 V if needed.
- Expect yellow rows 0–15 and blue rows 16–63, but determine the exact split with a movable one-pixel row test instead of relying on seller descriptions.
- Keep assignments centralized in the board profile rather than scattering display or button GPIO assumptions through UI code.
Completion requires electrical validation, operation with all current transports, and documented recovery behavior.
![Proposed Phase 7 overview display](phase7_display_mockup.svg)
The persistent yellow strip is reserved for serial-service state, Wi-Fi strength, active USB/Web/SSH counts, current writer, total clients, and an alert indicator. The blue area rotates through overview, RS-232, broker-client, and network/service pages. No password, Wi-Fi secret, private-key material, or routine credential data may appear on the display.
#### Implementation sequence
1. **Phase 7A — Electrical bring-up and diagnostics**
- Add bounded low-level display and button diagnostics under the existing `debug` submenu.
- Probe only the expected `0x3C` and `0x3D` addresses, then validate geometry, orientation, row/column addressing, contrast, inversion, and the yellow/blue row boundary.
- Validate each active-low button, pull-up behavior, debounce interval, short press, long press, and stuck-button handling.
2. **Phase 7B — Display driver**
- 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.
3. **Phase 7C — Read-only status UI**
- 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.
- Refresh at a bounded low rate, initially about 4 Hz, from a low-priority owner task. Never hold a service lock across an I²C transaction.
4. **Phase 7D — Local controls**
- Add a shallow menu for safe serial, Wi-Fi, HTTPS, SSH, writer-release, display, and reboot actions through direct service APIs.
- Require a visible confirmation screen and a timed select hold before stopping active services, revoking a writer, rebooting, or performing another disruptive action.
- A local display is not a serial broker client and cannot silently acquire the writer lease.
5. **Phase 7E — Reliability, persistence, and documentation**
- Add contrast and optional dim/blank timeout settings to limit OLED burn-in without making the display necessary for recovery.
- Validate display removal, I²C NACK/timeouts, stuck buttons, queue saturation, and repeated actions.
- Re-run concurrent USB CDC, WebSocket, and SSH traffic while the UI refreshes and confirm UART0 remains responsive.
- Update wiring, electrical-test, command-reference, and recovery documentation.
Completion requires electrical validation on the selected module, correct operation with all current transports, bounded display/button failure behavior, safe action confirmation, no unexplained serial or broker loss, and documented UART0 recovery.
### Phase 8 — Security and production hardening