What Does It Mean to Migrate from LVGL to Sparklet?

Running LVGL and Sparklet simultaneously in the same firmware image is not recommended — both frameworks manage a display framebuffer and would conflict at the rendering and tick levels. The recommended migration approach is to complete the full UI migration screen-group by screen-group in a separate development branch, then cut over. The Windows PC simulator makes it possible to develop and test the Sparklet UI completely before touching target hardware, so parallel operation on the embedded target is not necessary.

Not directly — the function signatures are different. However, the event-driven pattern is the same: a widget fires an event, a callback function is called with event data. Your event handler logic — what happens when a button is pressed, how a slider value update is processed, what data updates a meter reading — can be moved to Sparklet callbacks with minimal changes to the business logic inside the handler. The main changes are to the callback registration syntax, the event parameter structure, and widget handle types. The logic itself does not change.

Migrating from LVGL to Sparklet is significantly easier than migrating between two frameworks with fundamentally different rendering models. Both LVGL and Sparklet are C-based, both use a widget tree model, both have analogous display driver architectures, and both use event-driven programming. The primary differences are: the design tool (Flint Designer instead of SquareLine Studio) and function naming conventions. For a team with LVGL experience, the Sparklet learning curve is days, not weeks. The GUI design recreation in Flint is typically the most time-consuming step, but also the most transformative — the result is a sustainable design workflow that LVGL's code-only approach never provides.

Yes. Embien's engineering services team offers structured migration engagements covering design reconstruction in Flint Designer, API mapping, platform HAL porting, and validation. Service scope ranges from advisory support — Embien reviews and advises while the customer's team does the work — to full migration delivery where Embien leads the entire migration effort. Contact the services team with your project details — screen count, target platform, RTOS, and timeline — to get a scoped engagement proposal.

Three scenarios drive the most migrations: (1) Safety-driven migration — a compliance requirement emerges mid-project (automotive OEM demands ISO 26262, medical certification is initiated), and LVGL's non-MISRA-C codebase cannot satisfy it without significant formal exclusion effort. (2) Tooling-driven migration — the team has exhausted SquareLine Studio's capabilities on a complex UI and is spending too many engineering hours on GUI code instead of product features. Flint Designer's productivity advantage changes this equation measurably. (3) Silicon change migration — the product moves to a platform (Renesas RA8D1, NXP i.MX RT1170) where Sparklet's native hardware acceleration delivers frame rate and UI quality advantages that community-ported LVGL acceleration cannot match.

LVGL uses a CSS-like style object system (lv_style_t) applied to widgets. Sparklet uses direct property setters on widget handles — individual API calls for colour, font, border, and background properties. In practice, Flint Designer handles the majority of visual property assignment through its visual editor, generating the correct Sparklet API calls automatically. For dynamically styled widgets — where colours or properties change at runtime based on data or state — the LVGL style selector pattern maps to Sparklet's direct property setter called from within an event handler or state machine action.