Use this guide to select hardware, budget resources and port the BSP. Confirm the CPU, compiler ABI, FreeRTOS version, available internal/external RAM and Flash, then obtain a matching binary package.
Reference build footprint
Checked on 2026-10-11 against existing public ESP32-P4 builds using ESP-IDF 5.5.4 and SDK 1.0.0 / ABI 8 / package revision 14:
This is a historical revision 14 build sample, current r27 resources require separate measurement. Road-vector windows, asynchronous validation, audio sinks, playback queues, TLS 5006 and independent mirroring affect resource use; remeasure your target build with the required features enabled.
Values use 1 KB = 1024 bytes and are rounded to two decimal places.
| Item | Full P4 application | managed-terminal template |
|---|---|---|
Application .bin |
2,497.47 KB | 589.25 KB |
.dram0.data + .dram0.bss |
69.45 KB | 21.50 KB |
.iram0.text |
95.09 KB | 74.31 KB |
.tcm.text + .tcm.data |
0.10 KB | 0.38 KB |
The full application includes the 1024×600 display, wireless, video, HUD and board drivers. The template still needs BSP implementations. These are whole-application link-time values, not SDK-only overhead or a comparison of equivalent functionality. The .bin excludes the bootloader, partition table and persistent data; RAM rows exclude runtime heap, task stacks and peak PSRAM use. They do not establish that a device with 72 KB RAM can run the application.
Run idf.py size and idf.py size-components in your project. Record the application image size in bytes, SDK package metadata, sdkconfig and enabled features. With other toolchains, use their map/section reports. Archive file size is not firmware Flash usage.
Managed interface defaults
| Setting | Default | Allocation and adjustment |
|---|---|---|
task_stack |
ESP-IDF: 12,288 bytes; other FreeRTOS ports: 3,072 StackType_t elements |
Allocated when the SDK task starts; verify port units |
rx_slots |
16; up to 512 input bytes per item | Allocated at creation, range 1–128, plus queue/alignment overhead |
command_slots |
16 | Allocated at creation, range 1–64 |
event_slots |
8 | Allocated at creation using sizeof(moto_terminal_event), range 2–64 |
bulk_rx_slots |
8 | Additional allocation when bulk is enabled, range 1–128 |
task_priority |
5 | Must be below the target’s configMAX_PRIORITIES |
Start with moto_terminal_config_init; do not copy stack units from another platform. Smaller queues increase backpressure or session closure risk. Validate stack reductions using the busiest workload’s stack high-water mark. See threads and ownership for lifecycle, SDK callbacks and application tasks.
Budget video buffers separately
Video reassembly, decoding, presentation and UI buffers are separate from the managed queues. One visible 1024×600 RGB565 frame needs 1024 × 600 × 2 = 1,228,800 bytes; double buffering doubles that value. Decoder alignment, DMA, rotation and UI may require more.
The P4 MJPEG reference uses a 512 KiB frame limit and four reassembly slots: compressed frame data capacity alone is 2 MiB, plus FEC, indices and instance overhead. Resolution, frame rate, codec, frame limits and decoder implementation jointly determine the budget. Total PSRAM does not represent available internal DMA memory.
Measure runtime peaks
There is no published minimum RAM/Flash or CPU percentage that applies to every board. On the target, record minimum free heap, largest free block, each task’s minimum remaining stack and CPU load after startup, during TLS handshakes and first pairing, steady navigation video, concurrent notifications/video, and reconnection.
ESP-IDF provides heap_caps_get_free_size, heap_caps_get_minimum_free_size and heap_caps_get_largest_free_block; inspect internal RAM and PSRAM separately. Read stack high-water marks and runtime statistics using the target FreeRTOS port’s units and configuration. Record test duration, display settings and enabled features, then reserve capacity for peaks, fragmentation and future firmware. Mark unmeasured CPU/heap peaks as unmeasured; link results cannot replace them.
Porting beyond ESP32
- Supply the target CPU/instruction set, compiler/ABI, FreeRTOS version/configuration and crypto configuration to obtain matching headers and archives.
- Implement license loading, pairing persistence, secure randomness and a thread-safe monotonic millisecond clock.
- Implement the wireless AP, IP/DHCP and nonblocking
moto_network_portprimitives. With SDK networking enabled, the SDK owns listening, connections and backpressure; advance generation when the network changes. - Provide local PIN display and one managed instance/event consumer. Validate pairing, themes and reconnection after reboot first.
- Add vehicle, video and notification drivers separately. Independent mirroring and Wi-Fi audio can use Managed pre-start setup APIs. Follow the Core reference application for BLE companions, basemaps and same-owner connection handoff.
Common APIs and callback contracts apply to matching targets. ESP NVS, NimBLE, LCD and hardware decoder drivers do not directly port to other chips. Establish basic connectivity and measured resource usage before expanding features.