Platform Architecture
ESP32-P4 Connected Services
The physically proven, board-profile-owned Wi-Fi, TLS and HTTPS architecture for the stock Waveshare ESP32-P4 7B.
Physically proven connected path
ESP32-P4 application
→ 4-bit SDIO streaming transport
→ stock ESP32-C6 companion
→ ESP-Hosted / esp_wifi_remote
→ DNS → TCP 443 → verified TLS → HTTPS serviceAuthoritative versions and transport
| Setting | Proven value |
|---|---|
| ESP-IDF | 5.5.4 |
| ESP-Hosted host | 1.4.7 |
| esp_wifi_remote | 0.14.5 |
| SDIO mode | Streaming, 4-bit, 40 MHz |
| Queues | TX 20 / RX 20 |
| Board-owned pins | GPIO14–19 SDIO, GPIO54 reset, GPIO6 auxiliary |
Compatible manifest ranges are board-profile/export inputs; the resolved lockfile remains authoritative for an individual build. The superseded 2.9.x packet-mode experiment is not active guidance.
Required initialization order
- 01Initialize NVS, event loop and the default STA esp_netif.
- 02Register Wi-Fi/IP event handlers before starting the remote Wi-Fi driver.
- 03Call esp_wifi_init(), set STA mode and configuration, then esp_wifi_start().
- 04Connect explicitly from the start path and let events establish association and DHCP state.
- 05Start connected services only after the cached IP-connected state is true.
Display-safe memory and verified TLS
- —32 KiB internal reserve leaves room for the LVGL rotation buffer while preserving network headroom.
- —Software AES is the proven path; hardware AES remains disabled.
- —Dynamic TLS buffers and the default PSRAM-aware mbedTLS allocator move eligible TLS allocations from scarce internal/DMA memory.
- —Certificate verification uses the ESP-IDF certificate bundle.
- —Connected services start only with at least 8192 bytes DMA free and a 4096-byte largest DMA block.
Physical proof completed the full 4086-byte server certificate record, certificate validation, key exchange, TLS Finished, HTTP 200 and bounded response consumption without reboot or SDIO assertion.
Hardware Example 04 — Online Services — Live Weather
| Scope | Status |
|---|---|
| Association, DHCP, DNS, TCP 443, verified TLS and HTTPS | PHYSICALLY PROVEN |
| Current conditions, forecast, network time, generated Fi icons and dynamic local backgrounds | PHYSICALLY PROVEN |
| Location | Tauranga example configuration; automatic geolocation is not claimed |
Example 04 is a normal editable Weather Dashboard plus developer-owned connected-service code. It does not introduce private weather LVGL objects or a second Wi-Fi flow.
Reusable architecture, not invented features
The same board-owned connectivity foundation is suitable for future REST clients, MQTT, telemetry, authenticated cloud services and network time. These are architecture applications, not claims that each service is already implemented.