Get the ESP32-P4 reference application. Application and board adapters are open source; the SDK core is supplied as matching headers and archives.
Choose one integration path
| Path | Suitable project | Your integration work |
|---|---|---|
| Repository root | JC1060P470C_I_W_Y, JD9165 1024×600, P4+C6; primary business, BLE notifications, video, maps and mirroring | Radio/display drivers supplied for this board; provision its license and replace simulated vehicle data/actuators for production |
examples/managed-terminal |
Port primary Wi-Fi, themes, controls, HUD and navigation video; alone it cannot complete first adding in the current App | BSP in main/board_driver.c, display and vehicle drivers |
These are separate firmware projects; do not insert the root main/terminal.c into Managed. Since revision 24, Managed supports independent mirroring and Wi-Fi audio through pre-start moto_terminal_set_mirror / moto_terminal_set_audio; see projection and audio. BLE companions, basemap storage and same-owner connection handoff still use Core. Proximity unlock also needs sampling, calibration storage and a real lock actuator.
Match versions and import the SDK
Read docs/VALIDATION.md at the selected repository revision and BUILD_INFO.json in the SDK package. Match CPU, ESP-IDF, FreeRTOS ABI and build configuration. A reference revision marked ABI 7 must not be mixed with ABI 8 headers/archives; request a matching pair. Importing a package does not migrate application source.
For the road-vector feature, select a commit containing main/route_vector_store.c and main/route_vector_view.c and requiring r25; older image-map examples must be upgraded. If the public default branch lacks that combination, obtain a matched project and binary package from the integration team before continuing.
This website documents SDK 1.0.0 / revision 27 / ABI 8. Use the package specified by the selected public-project commit; newly available SDK APIs do not mean the template already integrates them.
Commands below use ESP-IDF 5.5.4; follow the matched project for the actual toolchain. Import the original ZIP into the full project. The package’s examples/customer is a separate template with unimplemented BSP hooks; use SDK setup when porting that Managed template to your own board.
git clone https://github.com/oounet/moto-esp32p4-example.git
cd moto-esp32p4-example
# Select the repository revision matched to the delivered package first.
python3 tools/import_sdk.py /path/to/sdk-package.zip
. /path/to/esp-idf-v5.5.4/export.sh
The importer verifies and installs the package in vendor/moto-sdk. It does not issue a device license. Follow device provisioning to read hardware identity, configure trust, install the device license then follow the BLE first-add and Wi-Fi guidance sequence below. Collect the APP and console prerequisites from the setup checklist.
Root project: complete instrument application
From the repository root:
python3 tools/fetch_lvgl.py
idf.py build
| What to inspect | File relative to the repository root |
|---|---|
| Wi-Fi, BLE and mirror instances and event routing | main/terminal.c |
| License loading and factory provisioning | main/factory_license.c, main/factory_usb.c |
| Vehicle controls and telemetry | main/terminal_board.c |
| HUD, video decoding and display | main/hud_view.c, main/terminal_video.c |
| Map reception and rendering | main/route_map_*.c, main/route_vector_*.c; see Offline maps |
| Android notifications and iOS ANCS | main/notice_view.c, main/ancs_adapter.c |
Check the panel, wireless coprocessor, pins and partitions before porting drivers. These board settings are not defaults for every P4 board.
Validate the specified board in this order:
- Build, flash and provision its device license.
- Sign in, enable Bluetooth, discover the terminal, confirm the PIN and complete cloud binding.
- Follow Wi-Fi guidance, verify primary authentication and change the theme.
- Reboot and verify retained binding and reconnection.
The root application already wires BLE/ANCS, video and maps. Continue through the feature checklist; you do not need to invent a second SDK task. Read the thread and instance architecture before porting.
Managed project: primary business integration
From the repository root:
cd examples/managed-terminal
idf.py build
This project’s main/main.c starts the SDK and consumes events; implement your BSP in main/board_driver.c. The template does not read a real license or start a working radio/decoder by default. A successful build still requires board integration. The template lacks the independent BLE instance required for first adding in the current App; use the Core root project to validate the full phone flow.
API example relative to this project’s snippets/ |
Purpose |
|---|---|
quick_start.c, api.c |
Managed network startup, events and shutdown |
vehicle.c, faults.c |
Control completion, full state and fault reports |
video.c |
Video preparation, reassembly and presentation receipts |
optional_features.c |
Routes/positions, music and instrument selection |
advertising.c, ad_receipts.c, bulk.c |
Media ads, durable receipts and independent data transport |
ota.c |
OTA port usage; installation still needs board integration |
bluetooth.c |
Advanced external transport; do not combine with config.network |
Product integration boundaries
- Example telemetry is simulated; production requires a real CAN/UART controller.
- P4+C6 has no integrated HFP path; call audio requires suitable hardware and drivers.
- Advertising requires a player, safe-idle checks and durable receipts; the 64-entry receipt template is only an example limit.
- OTA demonstrates reception and validation without Flash writes or reboot. Real updates need signature checks, partitions, power-loss recovery and rollback.
Confirm board and partitions before flashing. See LICENSE and THIRD_PARTY.md for application and dependency licenses.