Espressif Boards

[中文]

Board Name	Parameters / Features	Product Link	Supported Interfaces
esp32_s3_korvo2_v3	ESP32-S3 Wi-Fi Flash 16MB PSRAM 8MB	ESP32-S3-Korvo-2 V3	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp_box_3	ESP32-S3 Wi-Fi Flash 16MB PSRAM 16MB	ESP-BOX-3	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp_vocat_board_v1_0	ESP32-S3 Wi-Fi Flash 32MB PSRAM 16MB	ESP-VoCat V1.0	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp_vocat_board_v1_2	ESP32-S3 Wi-Fi Flash 32MB PSRAM 16MB	ESP-VoCat V1.2	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp32_p4_function_ev	ESP32-P4 Wi-Fi Flash 16MB PSRAM 32MB	ESP32-P4-Function-EV-Board	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp32_p4x_function_ev	ESP32-P4 Wi-Fi Flash 16MB PSRAM 32MB	ESP32-P4X Function-EV Board	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp32_s31_korvo1	ESP32-S31 Wi-Fi Flash 16MB PSRAM 16MB	ESP32-S31 Korvo1	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight StorageFs StorageKv WifiBasic WifiSta WifiSoftAp
esp_mosaico_v1_0	ESP32-S31 Wi-Fi Flash 16MB PSRAM 16MB Expansion slots	Official User Guide Brookesia Adaptation Guide	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight PowerBattery StorageFs StorageKv ExpansionModuleManager Camera (optional module) WifiBasic WifiSta WifiSoftAp
esp_mosaico_v1_2	ESP32-S31 Wi-Fi Flash 16MB PSRAM 16MB Expansion slots Partially validated; see guide	Public BSP revision Brookesia Adaptation Guide	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch DisplayBacklight PowerBattery StorageFs StorageKv ExpansionModuleManager Camera (optional module) WifiBasic WifiSta WifiSoftAp
esp_sensair_shuttle	ESP32-C5 Wi-Fi Flash 16MB PSRAM 8MB	ESP Sensair Shuttle	AudioCodecPlayer AudioCodecRecorder DisplayPanel DisplayTouch StorageFs StorageKv WifiBasic WifiSta WifiSoftAp

ESP-Mosaico V1.0 Adaptation Guide

esp_mosaico_v1_0 supports Wi-Fi, a 480 x 480 display with touch, audio playback and recording, battery voltage queries, LittleFS/NVS, and NAND FATFS on the ESP-Mosaico V1.0 CoreBoard. A camera is available through an optional expansion module. Missing or unsupported modules do not prevent the core board from starting.

Configuration and Usage

Generate the board configuration and build from the example project directory. For the general workflow, see Getting Started - How to Use Example Projects.

idf.py gen-bmgr-config -b esp_mosaico_v1_0
idf.py --preview set-target esp32s31
idf.py build

The board defaults include the following settings:

• Expansion modules: Enable CONFIG_BROOKESIA_HAL_ADAPTOR_ENABLE_EXPANSION_MODULES together with the Camera, DVP, OV3640, and SC101IOT drivers.

• Camera release: Set CONFIG_BROOKESIA_HAL_ADAPTOR_VIDEO_KEEP_DEVICE_INITIALIZED_ON_RELEASE=n to release the camera device when the last session closes.

• Device registration capacity: Set CONFIG_VFS_MAX_COUNT=12 to accommodate the console, networking, filesystems, and video devices.

• USB console: Enable TinyUSB CDC and automatic download; disable the USB Serial/JTAG secondary console, USB Service auto-registration, and the System Core USB file-transfer bridge.

• NAND: Enable FATFS at /nand with CONFIG_BROOKESIA_HAL_ADAPTOR_STORAGE_FILE_SYSTEM_FATFS_NAND_FORMAT_IF_MOUNT_FAILED=n to keep automatic formatting disabled on mount failure.

Note

An existing project's sdkconfig takes precedence over board defaults. After updating the board configuration, check the relevant options in idf.py menuconfig. With Board Manager 0.5.x and a non-default SDKCONFIG path, include components/gen_bmgr_codes/board_manager.defaults in SDKCONFIG_DEFAULTS.

Expansion Modules

Mosaico scans available slots every 300 ms and updates module state after three consecutive matching results. Scanning identifies modules; functional hardware is initialized when the corresponding HAL interface is opened.

Module	Slot	Support
OV3640 camera	Left	RGB565, 640 x 480, 7 fps; capture through the Camera HAL and Video interfaces.
SC101IOT camera	Left	YUV422, 640 x 480, 15 fps; capture through the Camera HAL and Video interfaces.
Camera module	Right	Reports Unsupported without initializing a driver.
Other valid modules	Any	Identifies the module and reports Unsupported.

Use Expansion:ModuleManager:0 to query and subscribe to slot state. Applications can also use the Device Service's GetExpansionModuleInfos and ExpansionModuleChanged. For state definitions and asynchronous callback behavior, see Expansion Module Support.

Usage Notes

• Shared pins: Both slots stop scanning while the camera is open. After the camera closes successfully and the shared pins are restored, scanning restarts and periodic detection resumes.

• Module removal: Close the camera before unplugging it. Removing a module while streaming is not supported.

• USB channels: GPIO33 is shared by DVP D2 and USB Serial/JTAG, so Serial/JTAG cannot operate with the camera. The onboard TinyUSB CDC console uses a separate channel; USB Service does not yet support file transfers over this channel. Recoverable console initialization failures fall back to UART; an unrecoverable standard-stream switch requires a manual restart.

• Application storage: NAND is accessible through HAL/Storage Service. System Core does not yet include /nand automatically in the application storage list. App Store displays the capacity of the partition containing its current cache directory.

• Error recovery: Check the error logs if camera cleanup fails; Encoder HAL close() has no return value. Scanning resumes only after camera resources and shared pins are restored. An uncertain peripheral release requires a manual restart; see Lifecycle and Error Handling.

hal/brookesia_hal_adaptor/test_apps provides repeated camera lifecycle, expansion scanning recovery, and NAND file read/write tests, selectable through the onboard USB console. examples/system/super runs the complete system example.

Implementation and Dependencies

The Mosaico board code handles slot identification, pin sharing, and peripheral configuration. Upper layers use the generic HAL and Service interfaces. For dependency compatibility, see Dependency Patches.

Both Mosaico revisions select shared components from hal/brookesia_hal_boards/components/mosaico/: brookesia_hal_custom, esp_lcd_co5300, and esp_mosaico_usb_console. Each revision directory retains setup_device.c, board_devices.cpp, three board YAML files, sdkconfig.defaults.board, and SOURCE.md. The registration code in board_devices.cpp translates generated board configuration into explicit shared-device parameters; lifecycle implementations reside in brookesia_hal_custom/src/board/ with interfaces under include/brookesia/hal_custom/board/. Neither revision includes source files from the other.

setup_device.c keeps the revision's touch factory and passes its LCD clock GPIO to the shared panel factory. The shared audio_codec.c exposes power-enable and readiness APIs: V1.0 registers the former for its codec GPIO, while V1.2 registers the latter for the settling delay without a dedicated GPIO.

Hardware configuration and parts of the initialization code are adapted from the Apache-2.0-licensed ESP-Mosaico BSP. Shared provenance is recorded in hal/brookesia_hal_boards/components/mosaico/SOURCE.md; revision-specific references remain in each board's SOURCE.md. All code required to build the boards is included in the Brookesia repository. Previously recorded hardware results predate this source-layout refactor and do not validate the reorganized layout.

ESP-Mosaico V1.2 Adaptation Guide

esp_mosaico_v1_2 provides an initial adaptation of the V1.2 CoreBoard for existing HAL and service capabilities: Wi-Fi, the 480 x 480 display and touch, audio playback and recording, battery voltage queries, LittleFS/NVS, NAND FATFS, and optional camera modules.

Important

V1.2 hardware validation is partial; the verified scope is listed below. TinyUSB CDC console menu interaction works. Automatic download caused the current sample to disconnect from USB without re-enumerating, so the board defaults disable it with CONFIG_BSP_USB_AUTO_DOWNLOAD=n. Enter ROM download mode manually with BOOT before flashing.

Configuration and Revision Differences

Select the board revision explicitly from the example project directory. This adaptation does not select a board automatically from eFuse data. Use esp_mosaico_v1_0 for a V1.0 CoreBoard and esp_mosaico_v1_2 for a V1.2 CoreBoard.

idf.py gen-bmgr-config -b esp_mosaico_v1_2
idf.py --preview set-target esp32s31
idf.py build

Compared with the V1.0 configuration:

• I2C buses: Onboard devices and expansion modules use separate I2C peripherals; the camera and module manager use the expansion bus.

• Display: LCD clock/reset assignments follow V1.2, and touch uses the CST9220 driver.

• Codec power: V1.2 does not use the V1.0 dedicated codec power GPIO; a board dependency retains the 10 ms power-settling delay before audio initialization.

• Board services: NAND FATFS and optional camera integration retain the existing interfaces and lifecycle handling. Expansion modules remain optional for System Super startup.

V1.2 uses the shared component layout described in the Mosaico implementation notes. Its setup_device.c, board_devices.cpp, and configuration files remain independent of the V1.0 board directory. The hardware results below were recorded before this source-layout refactor; build and hardware validation of the reorganized layout are separate checks.

V1.2 keeps CONFIG_BSP_USB_CONSOLE=y and CONFIG_TINYUSB_CDC_ENABLED=y, but sets CONFIG_BSP_USB_AUTO_DOWNLOAD=n and CONFIG_ESPTOOLPY_BEFORE_NORESET=y to avoid another reset after manual ROM entry. The sdkconfig precedence note also applies; update both settings in an existing sdkconfig. The adaptation stays on the Board Manager 0.5.15 dependency line with the existing compatibility patches; a full dependency upgrade is separate work.

V1.2 also sets CONFIG_MBEDTLS_HARDWARE_SHA=n and CONFIG_MBEDTLS_HARDWARE_AES=n so the mbedTLS/PSA SHA/AES used by HTTP/TLS runs in software, supporting LCD, NAND, camera, and HTTPS coexistence. Update both options in an existing V1.2 sdkconfig. This retains TLS and signature verification and may increase CPU work; the overhead has not been measured.

These settings do not disable direct hardware crypto calls. Media SAL AES-CBC calls esp_aes_crypt_cbc directly and is not controlled by these two options. Encrypted-media coexistence with the camera remains unverified.

Scope and Validation

The current sample has exercised LCD/CST9220 initialization and brightness control, ES8311 initialization/deinitialization, BQ27220 voltage queries (approximately 3.9 V), LittleFS/NVS, and SC101IOT discovery, initialization, and release. System Super startup reached === System Example Completed ===; desktop display, basic touch interaction, and brightness-slider dragging were manually confirmed. My Device information and nearby Wi-Fi access-point scanning were also confirmed; runtime logs show successful network time synchronization.

NAND mounted successfully after formatting and reported a total capacity of 119,746,560 bytes. File write/fsync/seek/read/close/remove operations and unmount/remount tests passed. File data persistence across power loss remains unverified.

SC101IOT passed 50 start/stop and frame-capture cycles, returning 614,400 bytes per frame with native YUV422 at 640 x 480. The configuration requests 15 fps; actual frame rate and image quality have not been verified.

Camera application preview worked after a cold start but failed to reopen after App Store HTTPS activity. Hardware tracing confirmed that LCD and NAND each held an AXI GDMA RX channel, while hardware cryptography retained the remaining channel after HTTPS and blocked DVP allocation. The user manually confirmed normal Camera preview with the fixed firmware using the revised mbedTLS/PSA defaults. This visual confirmation is separate from the HAL capture checks above; the final serial capture did not record this interaction. A repeat after an actual application download and installation has not been separately recorded.

Audio playback/recording quality remains unverified.

NAND is configured to mount at /nand through HAL/Storage Service, with automatic formatting disabled on mount failure. System Core does not yet list NAND as an application installation location. IMU and motor service integration are outside this adaptation.

The optional modules retain the configured support scope and operating restrictions described in the V1.0 guide, including camera close before removal and shared-pin recovery before scanning resumes. Validation beyond the SC101IOT checks above remains pending on V1.2. USB Service file transfer over the onboard TinyUSB CDC channel is not enabled.

Both hal/brookesia_hal_adaptor/test_apps and examples/system/super provide sdkconfig.ci.board.esp_mosaico_v1_2 for build selection. The existing ESP32-S31 build matrix discovers these files; no V1.2 hardware runner is configured in the target-test matrix. Use the HAL test app for the remaining device and lifecycle checks; additional application workflows require separate validation. Hold BOOT while powering on or resetting the board to enter ROM download mode before flashing; the running firmware's CDC console remains available for test-menu interaction.

Revision-specific configuration follows the Apache-2.0-licensed public ESP-Mosaico BSP at commit 4a6c22b5. All code required to build the adaptation is included in the Brookesia repository.