Render live camera feeds, object-detection overlays, proximity warnings, and lane-departure alerts on a single embedded display — with hardware-accelerated composition and MISRA C compliance. Sparklet delivers the low-latency, multi-layer ADAS display stack your safety system requires.
An ADAS embedded display GUI is the software layer that renders Advanced Driver Assistance System information directly on a vehicle display — compositing live camera feeds from rear-view, front-facing, or surround-view cameras with graphical overlays that communicate object proximity, lane position, collision risk, and parking distance to the driver in real time. Unlike a conventional HMI that renders static icons and dynamic text, an ADAS display must overlay vector graphics onto a live decoded video frame at 30 fps or higher, with end-to-end latency from camera capture to display under 50 ms.
Sparklet provides the hardware-accelerated compositing pipeline that makes this possible on automotive-grade MCUs and MPUs. Its multi-layer rendering engine treats the camera feed and the GUI overlay as independent hardware layers composited by the GPU or 2D accelerator — keeping the CPU free for object-detection logic and CAN data processing. Explore the full automotive HMI demo gallery to see camera-integrated cluster and ADAS demos running on real hardware.
Sparklet accepts a decoded camera frame buffer from the platform ISP and assigns it to a dedicated hardware rendering layer. On NXP i.MX 8 with Vivante GPU and on Renesas RA8D1 with Mali-Limav, compositing is performed entirely in hardware — zero CPU involvement in the pixel blend. Parking guidelines, proximity warning bars, object detection bounding boxes, and lane departure indicators are rendered as vector elements in the overlay layer, updated at 60 fps even when the camera feed runs at 30 fps. The overlay layer is configured in Flint UI Designer and exported as standard C code.

Sparklet's multi-layer rendering engine composites the camera feed layer, the GUI overlay layer, and the safety warning layer independently — each on dedicated hardware planes. On platforms with a hardware compositor (i.MX 8, RA8D1, RH850 D/AVE2D), GPU blending replaces all software compositing. This architecture means the camera feed and the warning overlay are never rendered in the same software pass — a safety warning icon can be drawn to its layer by a priority interrupt handler without waiting for the camera frame decode to complete. See the hardware acceleration page for GPU layer details.

Hardware layer compositing on NXP i.MX 8 Vivante GPU and Renesas RA8D1 Mali GPU achieves sub-50 ms end-to-end camera-to-overlay latency — keeping object detection annotations accurately aligned with moving objects. Sparklet's compositing step itself adds less than one display frame (under 16 ms at 60 fps refresh) to the total pipeline latency. For surround-view systems, Sparklet's 3DView widget renders a real-time 3D bowl projection of four camera feeds around a vehicle model on i.MX 8 — updated frame-synchronously with camera capture. See the 3D graphics page for pipeline details.

ISO 26262 programs classify the display stack as a software component under the safety architecture. Every line of Sparklet source code is written to MISRA C guidelines throughout. The GUI library can be included in an ISO 26262 software component review as a QM or ASIL-decomposed component without introducing MISRA deviations that require waivers. This is a significant audit benefit on safety-critical ADAS display programs — the library does not become an exception in an otherwise compliant codebase.
Sparklet's Dialog and MsgBox widgets provide a top-layer rendering mechanism for safety-critical warning display. When a collision warning or emergency braking alert is triggered, the warning element is placed on the topmost render layer and rendered with priority over all other display content — ensuring safety-critical information is always visible regardless of the current screen state. This priority mechanism operates within Sparklet's normal render cycle without requiring a separate rendering thread or OS-level priority inversion.
The Renesas RH850 (with D/AVE2D 2D accelerator) supports camera-integrated cluster displays with rear-view overlay — a configuration Embien has shipped in production. The Renesas RA8D1 (Mali-Limav GPU) extends this to surround-view capability with hardware-accelerated 3D projection. Platform details are available on the Renesas platform page and the NXP platform page.
| ADAS Requirement | Threshold | Sparklet Capability |
|---|---|---|
| Camera-to-Display Latency | < 50 ms | Sub-50 ms with HW layer; < 16 ms compositing step |
| Camera Feed Integration | YUV / RGB frame buffer | Hardware layer; no software pixel copy; ISP-direct |
| Overlay Vector Rendering | 60 fps independent of camera | Separate GPU layer; overlay at 60 fps / camera at 30 fps |
| Safety Warning Priority | Immediate top-layer render | Dialog/MsgBox on topmost layer; priority in render cycle |
| Surround-View 3D Projection | 4-camera bowl projection | 3DView widget on i.MX 8 / RA8D1; frame-synchronous |
| MISRA C Compliance | Required for ISO 26262 | Full MISRA C source; no deviations or waivers |
| Multi-Camera Sources | 4+ camera feed instances | Multiple concurrent camera layer instances supported |
| Multi-Display Output | Cluster + ADAS panel | Independent pipelines on i.MX 8 multi-display configs |

Camera frames assigned to dedicated hardware rendering layers — no software pixel copy, no CPU involvement, and frame-synchronous composition with vector overlays.

Hardware compositing on i.MX 8 Vivante GPU and RA8D1 Mali GPU keeps object-detection annotations accurately aligned with moving objects at speed.

Collision and braking warnings are placed on the topmost render layer and rendered with priority — always visible regardless of current screen state or active overlay.

Full MISRA C source enables clean integration into ISO 26262 software component reviews without waivers or deviations — reducing safety audit effort on every ADAS display program.
Sparklet accepts a decoded camera frame buffer from the platform ISP and assigns it to a hardware rendering layer. On platforms with a hardware compositor (NXP i.MX 8 Vivante GPU, Renesas RA8D1 Mali GPU), the camera layer and the GUI overlay layer are composited in hardware — no software pixel blending, no CPU overhead. The camera feed appears as a background or composited layer with vector overlay elements (parking lines, warning boxes) drawn on top in the same render pass.
Evaluate Sparklet on NXP i.MX 8 or Renesas RA8D1 with the ADAS camera overlay demo project. See live camera compositing and warning overlay rendering on real hardware within a day.