Qt for MCUs on ESP32-P4.
Crossware ports and optimises Qt for MCUs on ESP32-P4 for FreeRTOS on ESP-IDF, taking advantage of the part's pixel-processing accelerator and hardware JPEG decode rather than falling back to a software rendering path.
The same constraints, solved across compact devices.
Related Crossware work in MCU graphics, touchscreen products and resource-conscious embedded platform integration.
Qt for MCUs device port
Display, touch, rendering and board integration for a compact production-oriented device.
Read case study → Related case studyEmbedded platform demonstrators
Reusable demonstrators that expose graphics performance and platform capability early.
Read case study → Related case studyEnergy-management touch HMI
A focused embedded interface combining live system data with clear touch interaction.
Read case study →Hardware acceleration and hardware JPEG, on the drawing path.
The Qt for MCUs hardware acceleration backend is integrated against ESP32-P4's pixel-processing accelerator, with hardware JPEG decode brought directly into the drawing path for camera and map frames.
Pixel-processing accelerator backend
Scale, rotate and blend operations offloaded to the PPA through the Qt for MCUs hardware acceleration backend.
Camera and map frame decode
Hardware JPEG decode integrated into the drawing path, so camera and map frames reach the screen without a software decode stall.
MIPI-DSI, touch, and Vsync-based double buffering.
Display integrations for MIPI-DSI panels, with touch input and Vsync-based double buffer configurations so the panel never shows a frame mid-composition.
Where framebuffers and assets actually live.
Frequently asked questions
Which ESP32 part does Crossware's Qt for MCUs work target?
ESP32-P4, running FreeRTOS on ESP-IDF.
Does rendering fall back to software, or use the chip's hardware?
Crossware integrates the Qt for MCUs hardware acceleration backend directly with ESP32-P4's pixel-processing accelerator (PPA) for scale, rotate and blend, rather than falling back to software rendering.
How are camera or map images decoded without stalling the UI?
Hardware JPEG decode is integrated directly into the drawing path, so camera and map frames reach the screen without a software decode stall.
Where do framebuffers and UI assets live given the chip's limited internal memory?
Framebuffers are optimised for external PSRAM, and UI assets are placed flash-resident with image compression to fit constrained storage and bandwidth.
What kind of display can be driven?
MIPI-DSI panels, with touch input and Vsync-based double buffering so the panel never shows a frame mid-composition.
Building a UI on ESP32-P4?
Rendering, display pipeline or the memory budget behind either, Crossware's Qt for MCUs team can take it on.