Qt for MCUs on NXP i.MX RT.
Crossware ports and optimises Qt for MCUs across the i.MX RT crossover family, RT1064, RT1170 and RT700, on both FreeRTOS and Zephyr, taking full advantage of whichever rendering block each part actually carries rather than treating the family as one interchangeable target.
MCU graphics proven in real product interfaces.
Examples of Crossware's rendering, display and platform work around the i.MX RT family and comparable constrained MCU environments.
Digital cockpit on RT1176
A production-oriented digital cockpit combining real-time vehicle data with a responsive embedded HMI.
Read case study → Platform case studyQt for MCUs on RT1170
Hardware-accelerated graphics, display integration and memory-aware application architecture.
Read case study → Related case studyOffline maps on an MCU
Map rendering and navigation designed for the memory and performance limits of an MCU platform.
Read case study →Hardware-accelerated rendering, matched to the silicon.
Accelerate UI rendering using NXP hardware blocks such as PXP, VGLite and OpenVG, each part class gets the backend its rendering hardware actually supports, not a lowest-common-denominator path.
PXP backend
Blits, alpha blending and multi-format pixel conversion across RGB565, ARGB and RGB888.
VGLite backend
Transforms, rounded rects, images and alpha maps, vector paths, and a rotation preprocess cache.
OpenVG / VGPU backend
GPU blends and transforms, native path stroke/fill, with CPU fallback when the GPU path isn't available.
LCDIF and LCDIFv2, double-buffered and VBlank-synchronised.
Integrate display pipelines on LCDIF and LCDIFv2 with double buffering and VBlank synchronisation, so the panel never shows a frame mid-composition.
Double buffering
VSync and frame-done synchronisation between the render buffer and the panel.
LCDIFv2 multi-layer composition
Alpha modes, shadow-load register updates, and layer offsets composited at scan-out.
Where shared buffers and image decode actually cause problems.
Frequently asked questions
Does the same rendering backend work across all i.MX RT parts?
No. Each part gets the backend its hardware actually supports: PXP for the RT106x class, VGLite for RT1170, and OpenVG/VGPU for RT700, rather than one lowest-common-denominator path.
Is Zephyr supported, or only FreeRTOS?
Both. Crossware ports and optimises Qt for MCUs on i.MX RT under either FreeRTOS or Zephyr.
Can RT1170 drive more than one display layer?
Yes. LCDIFv2 multi-layer composition is supported, with alpha modes, shadow-load register updates and layer offsets composited at scan-out.
What causes shared-buffer corruption on these parts, and is it handled?
D-cache and MPU coherency issues between the CPU and the rendering hardware (PXP, VGLite or OpenVG) are a known failure mode that Crossware resolves as part of the integration.
Can RT700 decode camera or image data in hardware?
Yes. Hardware JPEG decode is integrated on RT700 for runtime image loading.
Tell us which i.MX RT and which rendering budget.
RT1064, RT1170 or RT700, the right backend and buffering strategy depends on which rendering hardware the part actually carries.