Add OLED and button diagnostics
This commit is contained in:
@@ -112,5 +112,16 @@ SSH listens on port 22 and uses the same `admin` credentials as HTTPS, but a sep
|
||||
| `debug uart-loopback <baud> [8N1|8E1|8O1|8N2|7E1|7O1] [bytes]` | Run a parameterized UART loopback test. |
|
||||
| `debug uart-suite` | Test supported baud rates and frame formats. |
|
||||
| `debug cts-flow-test` / `debug rts-flow-test` | Verify hardware transmit gating or receive backpressure. |
|
||||
| `debug display status` | Show the current display diagnostic state. |
|
||||
| `debug display probe` | Probe the expected OLED addresses 7-bit `0x3c` and `0x3d`, initially using 100 kHz I²C. The tested module responds at `0x3c`. |
|
||||
| `debug display scan --force` | Scan usable 7-bit addresses `0x08`–`0x77` at 100 kHz; use only on this dedicated local-UI bus. |
|
||||
| `debug display init [address]` | Initialize the OLED at 7-bit `0x3c`/`0x3d`, or their 8-bit write/read aliases: `0x78`/`0x79` and `0x7a`/`0x7b`. |
|
||||
| `debug display off` | Turn off the initialized OLED. |
|
||||
| `debug display pattern <clear|fill|checker|grid|corners>` | Draw a full-screen electrical and geometry test pattern. |
|
||||
| `debug display row <0..63>` | Draw the selected one-pixel display row for addressing and color-boundary checks. |
|
||||
| `debug display contrast <0..255>` | Set the OLED contrast to the specified bounded value. |
|
||||
| `debug display invert <on|off>` | Enable or disable OLED pixel inversion. |
|
||||
| `debug buttons status` | Show the current active-low state of previous/back GPIO10, select/confirm GPIO13, and next GPIO14. |
|
||||
| `debug buttons test [seconds]` | Run the bounded button event test for 1–30 seconds; the default is 10 seconds. |
|
||||
|
||||
Follow the exact wiring in [Electrical tests](electrical_tests.md) before invoking diagnostics. Diagnostics refuse to use UART1 until `serial stop` releases it. The RGB LED shows test state: blue idle, yellow/orange running, green passed, red failed.
|
||||
Follow the exact wiring in [Electrical tests](electrical_tests.md) before invoking diagnostics. The OLED must be powered from 3.3 V because module I²C pull-ups may connect to `VCC`; verify that all external pull-ups also terminate at 3.3 V. Display diagnostics probe the standard SSD1315-compatible 7-bit `0x3c`/`0x3d` addresses. The currently tested module acknowledges at `0x3c`, whose 8-bit write/read forms are `0x78`/`0x79`; an explicit `scan --force` is available only for the dedicated local-UI bus. Diagnostics initially run at 100 kHz and treat an absent display as nonfatal. RS-232 diagnostics that require UART1 refuse to use it until `serial stop` releases it. The RGB LED shows test state: blue idle, yellow/orange running, green passed, red failed.
|
||||
|
||||
+106
-2
@@ -1,8 +1,112 @@
|
||||
# Electrical tests
|
||||
|
||||
These procedures verify the MAX3243 breakout, UART1 data path, hardware flow control, and session broker. They are manual tests: the firmware never starts one automatically.
|
||||
These procedures verify the Phase 7A OLED and buttons, MAX3243 breakout, UART1 data path, hardware flow control, and session broker. They are manual tests: the firmware never starts one automatically.
|
||||
|
||||
> **Safety:** With power removed, install only the wiring required by the selected test. DE-9 pins 3 (`TX`), 4 (`DTR`), and 7 (`RTS`) are driven outputs. Never connect one of these outputs to another driven output. Keep temporary Dupont wiring short and secure.
|
||||
> **Safety:** With power removed, install only the wiring required by the selected test. DE-9 pins 3 (`TX`), 4 (`DTR`), and 7 (`RTS`) are driven outputs. Never connect one of these outputs to another driven output. Keep temporary Dupont wiring short and secure. Power the OLED only from 3.3 V because module-mounted I²C pull-ups may connect SDA and SCL to the OLED `VCC` rail.
|
||||
|
||||
## Phase 7A OLED and button bring-up
|
||||
|
||||
Use the exact OLED and button connections in [Hardware wiring](wiring.md). Display diagnostics initially operate I²C at 100 kHz and probe the standard 7-bit `0x3c` and `0x3d` addresses. The connected test module acknowledges at `0x3c`, whose 8-bit write/read forms are `0x78` and `0x79`. A missing or unresponsive display is nonfatal: diagnostics should report it without disrupting UART0 or the serial services.
|
||||
|
||||
### 1. Power-off wiring checks
|
||||
|
||||
Disconnect both USB connectors and every other power source before checking or changing wiring.
|
||||
|
||||
1. Confirm OLED `VCC` goes only to `3V3`, OLED `GND` goes to `GND`, SDA goes to GPIO11, and SCL goes to GPIO12.
|
||||
2. Check for an unintended short between `3V3` and `GND`, and verify ground continuity between the OLED and ESP32 board.
|
||||
3. Determine whether the OLED module has SDA/SCL pull-ups and verify that any module-mounted or external pull-ups terminate at 3.3 V, never 5 V. Add suitable external pull-ups to `3V3` only if the module does not provide them; account for parallel resistance if more than one set is fitted.
|
||||
4. Confirm each button is wired between its input and `GND`: previous/back GPIO10, select/confirm GPIO13, and next GPIO14. With a meter, each button should be open when released and near zero ohms to `GND` when pressed.
|
||||
5. Check that no button shorts two GPIOs together and that SDA and SCL are not swapped or shorted.
|
||||
|
||||
### 2. Powered idle checks and address probe
|
||||
|
||||
Apply power, but do not initialize the OLED yet.
|
||||
|
||||
1. Measure OLED `VCC` relative to `GND`; it should be approximately 3.3 V.
|
||||
2. Measure idle SDA on GPIO11 and idle SCL on GPIO12. Both should be near 3.3 V. Power down immediately if either bus line rises toward 5 V; correct the OLED supply or pull-up wiring before continuing.
|
||||
3. Run `debug display status` and record the diagnostic state.
|
||||
4. Run `debug display probe`. Confirm that it tests only 7-bit `0x3c` and `0x3d` at the initial 100 kHz bus rate. The tested module should acknowledge at `0x3c` (8-bit `0x78` write / `0x79` read).
|
||||
|
||||
If the expected address does not respond, treat the result as a nonfatal hardware finding. On this dedicated local-UI bus, `debug display scan --force` may identify an unexpected address before further investigation. Otherwise leave the serial core running, power down, and recheck 3.3 V power, common ground, SDA/SCL order, solder joints, and pull-ups. Do not scan a bus shared with unrelated I²C devices.
|
||||
|
||||
### 3. Initialization and display patterns
|
||||
|
||||
Initialize the address observed during the scan. The tested module uses 7-bit `0x3c`, equivalently 8-bit `0x78` (write) and `0x79` (read):
|
||||
|
||||
```text
|
||||
debug display init 0x3c
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
```text
|
||||
debug display pattern clear
|
||||
debug display pattern fill
|
||||
debug display pattern checker
|
||||
debug display pattern grid
|
||||
debug display pattern corners
|
||||
```
|
||||
|
||||
Confirm that clear and fill affect the full 128×64 area, checker and grid have regular spacing without shifted or wrapped columns, and all four corner markers are visible in the correct locations. Unexpected mirroring, rotation, clipping, or column offsets must be recorded before Phase 7B fixes the display-driver assumptions.
|
||||
|
||||
### 4. Row 15/16 color-boundary test
|
||||
|
||||
Clear the display, illuminate row 15, and record its physical color and position:
|
||||
|
||||
```text
|
||||
debug display pattern clear
|
||||
debug display row 15
|
||||
```
|
||||
|
||||
Repeat for row 16:
|
||||
|
||||
```text
|
||||
debug display pattern clear
|
||||
debug display row 16
|
||||
```
|
||||
|
||||
**Verified result:** row 15 is the last yellow addressable row and row 16 is the first blue addressable row. The two colored areas are separated by a narrow physical black divider, so later UI rendering must treat the 128×16 yellow and 128×48 blue regions as separate panels rather than one visually continuous canvas. Also test another endpoint row if needed with `debug display row <0..63>` to confirm row addressing and orientation.
|
||||
|
||||
### 5. Contrast, inversion, and display-off checks
|
||||
|
||||
With a visible pattern loaded, exercise the bounded contrast range and confirm that brightness changes without bus errors:
|
||||
|
||||
```text
|
||||
debug display contrast 0
|
||||
debug display contrast 64
|
||||
debug display contrast 128
|
||||
debug display contrast 255
|
||||
```
|
||||
|
||||
Then verify inversion toggles all displayed pixels and can be restored:
|
||||
|
||||
```text
|
||||
debug display invert on
|
||||
debug display invert off
|
||||
```
|
||||
|
||||
Finally run `debug display off` and confirm the panel turns off cleanly. Use `debug display status`, then `debug display init 0x3c` (or equivalently `0x78` or `0x79`) before further display tests.
|
||||
|
||||
### 6. Button checks
|
||||
|
||||
With all buttons released, run `debug buttons status`. Confirm previous/back GPIO10, select/confirm GPIO13, and next GPIO14 report released/high due to their internal pull-ups; each should report pressed/low while held to `GND`.
|
||||
|
||||
Run `debug buttons test` for the default 10-second interval. During the test, press and release each button separately with a deliberate short press, then repeat with a sustained long press. Confirm that the correct button and short/long classification are reported exactly once per intended action.
|
||||
|
||||
Repeat with an explicit duration, for example:
|
||||
|
||||
```text
|
||||
debug buttons test 30
|
||||
```
|
||||
|
||||
Use the longer run to check:
|
||||
|
||||
- **Debounce:** press with normal switch bounce and make several deliberately quick taps; one physical press must not produce a burst of duplicate press/release or short/long events.
|
||||
- **Long press:** hold each button long enough for the diagnostic to classify it as long, then release it; it must not also create an unintended short-press action.
|
||||
- **Stuck button:** hold one button before starting the test and keep it held. The input must remain identified as pressed/stuck without blocking checks of the other buttons, and the bounded diagnostic must still exit after the selected duration.
|
||||
- **Recovery:** release the held button and confirm `debug buttons status` returns to released/high without a reboot.
|
||||
|
||||
`debug buttons test [seconds]` accepts 1 through 30 seconds and defaults to 10 seconds when omitted. Record unexpected event duplication, missed transitions, incorrect GPIO mapping, false long presses, or a test that fails to terminate.
|
||||
|
||||
## Configuration A: data and handshake pairs
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
<?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>
|
||||
<desc id="description">An enlarged mockup of the verified 128 by 64 pixel local status display. The upper sixteen yellow rows and lower forty-eight blue rows are separate rendered panels, divided by a narrow physical black separator. The yellow panel shows service, Wi-Fi, client, writer, and alert status. The blue panel shows 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%">
|
||||
@@ -64,7 +64,7 @@
|
||||
<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>
|
||||
<text x="480" y="445" text-anchor="middle">Verified panels: yellow rows 0–15 · black divider · blue rows 16–63</text>
|
||||
</g>
|
||||
|
||||
<g>
|
||||
@@ -83,5 +83,5 @@
|
||||
</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>
|
||||
<text x="480" y="593" fill="#718594" font-family="sans-serif" font-size="13" text-anchor="middle">Mockup only — glyph metrics remain to be finalized; the physical color boundary is hardware-verified.</text>
|
||||
</svg>
|
||||
|
||||
|
Before Width: | Height: | Size: 4.9 KiB After Width: | Height: | Size: 5.0 KiB |
+21
-18
@@ -5,6 +5,7 @@ This document tracks the implementation and hardware-validation plan for the ESP
|
||||
## Status legend
|
||||
|
||||
- **Complete** — implemented and validated on the target hardware.
|
||||
- **In progress** — implementation or validation is actively underway, but the overall phase is not complete.
|
||||
- **Implemented; validation pending** — code is present and builds, but the current implementation still needs the listed hardware checks.
|
||||
- **Planned** — accepted project direction, not yet implemented.
|
||||
- **Under evaluation** — useful candidate whose feasibility, security, or resource cost must be measured before it becomes a commitment.
|
||||
@@ -36,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 | **Planned** |
|
||||
| 7 | Local display and button interface | **In progress (7B)** |
|
||||
| 8 | Security and production hardening | **Planned** |
|
||||
| 9 | Authenticated, rollback-capable OTA | **Planned** |
|
||||
| 10 | BLE serial transport and provisioning evaluation | **Planned** |
|
||||
@@ -175,47 +176,49 @@ The final target-hardware retest covered:
|
||||
|
||||
The software-crypto build no longer reproduces the HTTPD watchdog stall. This validates that the failure was a shared hardware-crypto/PSRAM DMA problem rather than heap exhaustion. Phase 6 is complete; these concurrent arrangements remain regression tests for future transport, TLS, memory-placement, and ESP-IDF changes.
|
||||
|
||||
## Planned phases
|
||||
## Current and planned phases
|
||||
|
||||
The order below is the current plan. Detailed requirements should be finalized at the start of each phase, and optional features must not weaken the completed serial and recovery paths.
|
||||
The order below is the current plan. Phase 7 is in progress; later phases remain planned or under evaluation. Detailed requirements should be finalized at the start of each phase, and optional features must not weaken the completed serial and recovery paths.
|
||||
|
||||
### Phase 7 — Local display and buttons
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
#### Hardware baseline
|
||||
|
||||
- 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.
|
||||
- Wire OLED `VCC` to `3V3` and OLED `GND` to `GND`. The OLED must use 3.3 V because module-mounted I²C pull-ups may connect SDA and SCL to `VCC`.
|
||||
- Wire OLED `SDA` to GPIO11 and OLED `SCL` to GPIO12. These pins are currently unused and sit in the available GPIO10–14 block on the DevKit header.
|
||||
- Wire three active-low buttons between their GPIO and `GND`, using the ESP32 internal 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.
|
||||
- Verify whether the module provides suitable SDA/SCL pull-ups and that every external pull-up is tied to 3.3 V, not 5 V; add external pull-ups to 3.3 V if the module does not provide them.
|
||||
- Hardware verification established yellow rows 0–15 and blue rows 16–63. A narrow physical black divider separates the two regions even though row 15 is the final yellow addressable row and row 16 the first blue addressable row.
|
||||
- Keep assignments centralized in the board profile rather than scattering display or button GPIO assumptions through UI code.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
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. Phase 7B must render it as a separate 128×16 status panel. The blue 128×48 content panel begins at row 16 and rotates through overview, RS-232, broker-client, and network/service pages; the physical black divider must remain visually clear. 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**
|
||||
1. **Phase 7A — Electrical bring-up and diagnostics — Complete**
|
||||
- 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.
|
||||
3. **Phase 7C — Read-only status UI**
|
||||
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.
|
||||
- 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**
|
||||
4. **Phase 7D — Local controls — Planned**
|
||||
- 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**
|
||||
5. **Phase 7E — Reliability, persistence, and documentation — Planned**
|
||||
- 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.
|
||||
|
||||
+32
-1
@@ -100,9 +100,40 @@ The USB-to-UART bridge's DTR/RTS controls serve automatic boot/reset and do not
|
||||
|
||||
Native USB CDC DTR controls the lifetime of the `usb-cdc` broker client but is not forwarded to physical DE-9 DTR. Physical DTR follows the `serial` configuration. CDC RTS is status information only; GPIO15/DE-9 RTS remains UART1 receive flow control when `flow=rts-cts` is enabled.
|
||||
|
||||
## Phase 7A OLED and button wiring
|
||||
|
||||
Phase 7A hardware validation used the following connections for the 128×64 I²C OLED and three local buttons. The selected module acknowledges at 7-bit I²C address `0x3c` (8-bit `0x78` write / `0x79` read) and has separate yellow rows 0–15 and blue rows 16–63, divided by a narrow physical black separator:
|
||||
|
||||
| Device connection | ESP32-S3 connection | Electrical behavior | Purpose |
|
||||
|---|---:|---|---|
|
||||
| OLED `VCC` | `3V3` | 3.3 V power only | OLED power and I²C pull-up rail |
|
||||
| OLED `GND` | `GND` | Common ground | OLED return and I²C reference |
|
||||
| OLED `SDA` | GPIO11 | I²C data | Display data |
|
||||
| OLED `SCL` | GPIO12 | I²C clock | Display clock |
|
||||
| Previous/back button | GPIO10 to `GND` | Active-low input with internal pull-up | Previous item or back |
|
||||
| Select/confirm button | GPIO13 to `GND` | Active-low input with internal pull-up | Select or confirm |
|
||||
| Next button | GPIO14 to `GND` | Active-low input with internal pull-up | Next item |
|
||||
|
||||
```text
|
||||
ESP32-S3-DevKitC-1 N16R8 128×64 I²C OLED
|
||||
──────────────────────── ────────────────
|
||||
3V3 ────────────> VCC
|
||||
GND ────────────> GND
|
||||
GPIO11 / SDA <───────────> SDA
|
||||
GPIO12 / SCL ────────────> SCL
|
||||
|
||||
GPIO10 ───── previous/back button ───── GND
|
||||
GPIO13 ───── select/confirm button ──── GND
|
||||
GPIO14 ───── next button ────────────── GND
|
||||
```
|
||||
|
||||
> **OLED voltage warning:** Power OLED `VCC` from `3V3`, not 5 V. Many OLED modules connect their SDA/SCL pull-up resistors directly to `VCC`; powering such a module from 5 V could expose the ESP32-S3 GPIOs to unsafe I²C levels.
|
||||
|
||||
Before applying power, verify whether the module already includes SDA and SCL pull-ups and where they terminate. Any module-mounted or external I²C pull-ups must go to 3.3 V. If pull-ups are absent, add suitable external pull-ups from SDA and SCL to `3V3`; if they are present, account for their parallel resistance before adding more. The buttons normally need no external pull-ups because firmware enables the ESP32 internal pull-ups.
|
||||
|
||||
## Electrical verification
|
||||
|
||||
See [Electrical tests](electrical_tests.md) for safe loopback wiring, polarity checks, UART flow-control verification, and session-broker loopback testing.
|
||||
See [Electrical tests](electrical_tests.md) for Phase 7A OLED/button bring-up, safe loopback wiring, polarity checks, UART flow-control verification, and session-broker loopback testing.
|
||||
|
||||
## Future hardware profiles
|
||||
|
||||
|
||||
Reference in New Issue
Block a user