Three Legacy HMI Migration Paths
Which migration scenario applies to your product — and how Sparklet handles each case.
From Segmented Display to Full-Colour Touch TFT
The most dramatic visual upgrade. Products using seven-segment LED displays, vacuum fluorescent displays (VFD), or simple indicator LEDs are moved to a full-colour IPS capacitive touch panel. The machine control MCU is retained unchanged; a dedicated display MCU (STM32H7 or NXP i.MX RT1170) is added to the PCB or display module. Sparklet runs on the display MCU and communicates with the machine MCU over UART or CAN bus. The machine MCU broadcasts its state — temperatures, speeds, alarms, mode flags — at a regular interval. The display MCU receives this and renders a graphical representation in Sparklet. Consumers and operators immediately notice the quality upgrade; the machine team does not need to touch the validated control firmware at all.
Flint UI Designer accelerates the design phase significantly: the UX team creates the new graphical panel layout in Flint's WYSIWYG environment — meter widgets, progress bars, status icons — and Flint generates the C code automatically. The firmware engineer integrates the generated code on the display MCU alongside the UART/CAN receive handler.
From Text-Based UI to Full Graphical Interface
Many legacy embedded products use a character LCD with a custom menu system — line-by-line text navigation, numeric parameter entry, alarm codes displayed as error numbers. The product uses a menu-driven interface that was practical in the 1990s but falls below current user expectations for any product in a competitive market.
This scenario typically retains the existing MCU and display hardware (a graphical TFT replaces the character LCD without changing the MCU board) but replaces the entire display software stack. The character LCD menu tree is reconstructed as a graphical navigation structure in Flint UI Designer — list views, dialogue boxes, and parameter sliders replace text menus and numeric entry screens. Sparklet's ListBox, TextEdit, Dialog, and Slider widgets map directly to the original interface concepts, but rendered at modern graphical quality.
The machine application code — the parameter read/write API, the alarm management logic, the communication protocol handler — is preserved and called by the new Sparklet UI event callbacks instead of by the old character LCD menu handler. The change is contained to the presentation layer.
From Desktop-Ported Framework to Embedded-Native GUI
Some legacy embedded products use a GUI framework that was originally designed for desktop or high-end Linux — Qt Embedded, wxWidgets, GTK, or similar — ported to run on an embedded Linux board. The framework was chosen for its features and design tool support, but it brings an oversized memory and CPU footprint, unpredictable render latency, and dependencies on a full Linux userspace stack that complicate security updates and boottime.
Moving to Sparklet — a purpose-built embedded GUI framework in pure C — eliminates the desktop-framework overhead. Sparklet's 16 KB minimum RAM footprint and deterministic render path fit bare-metal and RTOS targets that a desktop-ported framework cannot reach. For Linux MPU targets (Rockchip RK3506G2, NXP i.MX 8), Sparklet runs as a single-process display application with direct framebuffer access — no display server, no graphics stack dependencies.
The migration path involves reconstructing the existing screens in Flint UI Designer (preserving the visual design and UX) and re-implementing the data binding from the application backend to Sparklet widget properties. Flint's WYSIWYG environment allows the original visual design to be matched precisely before any C code is written.
