Sparklet's software architecture is organised into 7 clearly separated layers, each with a defined responsibility and a defined interface to adjacent layers. This strict layered structure is not organisational preference — it is the architectural decision that enables two of Sparklet’s key properties: platform portability (the same application code runs on STM32, Renesas, NXP, Windows simulator, and Linux SDL2) and minimal memory footprint (each layer is independently optimisable and independently configurable for a specific target). Understanding the 7-layer architecture helps engineers correctly integrate Sparklet into their project and know exactly which layer to modify for any given customisation need.
The 7 Layers — Bottom to Top
Layer 1 — HAL: Hardware Abstraction Layer
Responsibility: All platform-specific code lives in the HAL. Display pixel transfer, touch controller read, millisecond tick timer, hardware accelerator (DMA2D, PXP, D/AVE2D) invocation, and VSYNC synchronisation. The HAL is the only layer that contains MCU-specific register writes and SDK/HAL calls.
Interface: The HAL exposes a fixed function table to the layer above (UTIL). Application code never calls HAL functions directly — it accesses hardware capabilities through the layers above the HAL. This indirection is what makes the rest of the stack platform-agnostic.
Porting scope: Implementing a new platform port means implementing the HAL function table for that platform — typically 8–15 functions. All layers above the HAL are unchanged for a new platform port.
Layer 2 — UTIL: Utilities
Responsibility: Platform-agnostic utility functions that the upper layers consume: PNG and JPEG image decode, mathematical functions (trigonometry for gauge needle rotation, interpolation for animations), memory pool management, and string utilities. UTIL calls HAL for any hardware-specific operation (e.g., accelerated memcpy via DMA2D is called through HAL from UTIL).
Why a dedicated UTIL layer: Image decode (libpng, libjpeg ports) and trigonometry (CORDIC or lookup table implementations) are reusable components that multiple upper layers consume. Centralising them in UTIL prevents duplication and allows a single optimised implementation to serve all callers.
Layer 3 — RS_MIN: RapidSea Minimal
Responsibility: The embedded system infrastructure layer — Hierarchical State Machine (HSM) engine, data guard evaluation, event dispatch, and inter-module communication primitives. RS_MIN is a minimal subset of Embien’s RapidSea embedded framework, included in Sparklet to provide formal state machine execution for screen navigation and widget behaviour.
Why HSM in an embedded GUI: Screen navigation in a real HMI application is a state machine — transitions between screens are conditional (only navigate from the home screen to the alarm screen if an alarm is active), states have entry/exit actions (run an animation on screen entry, reset data on screen exit), and sub-states exist (a settings screen has sub-screens for each settings category). A formal HSM engine manages this complexity reliably; ad-hoc if/else navigation logic in application code is error-prone at scale.
Layer 4 — EXEC: Execution Engine
Responsibility: Screen lifecycle management — creating and destroying screen widget trees, managing the screen stack (navigate forward, navigate back, replace), dispatching events from the touch controller and data layer to the active screen’s widget tree, and driving the render cycle (decide which widgets are dirty, trigger their render functions, manage the dirty region accumulator).
The EXEC layer is the heart of the GUI framework’s runtime operation. It owns the main GUI loop logic: process events → update widget states → collect dirty regions → dispatch to GDI for rendering. Application code interacts with EXEC via the screen lifecycle API (SGUI_LoadScreen(), SGUI_Task(), SGUI_Render()).
Layer 5 — GDI: Graphics Device Interface
Responsibility: The rendering engine. GDI implements all drawing primitives: filled and outlined rectangles, circles, arcs, lines, alpha-blended image blit, anti-aliased text rendering, gradient fills, and hardware layer management. GDI calls UTIL for image decode and HAL for hardware-accelerated drawing operations (DMA2D fill, PXP blend).
GDI abstracts hardware acceleration: Application code (and the WID layer above GDI) calls abstract GDI operations like SGDI_FillRect() or SGDI_BlitImage(). GDI internally routes these to the hardware accelerator if available, or falls back to software implementation if not — transparently. This is why the same GDI call delivers hardware-accelerated performance on STM32H7 (DMA2D) and software-rendered correctness on the Windows simulator (no GPU).
Layer 6 — WID: Widget Layer
Responsibility: The 36+ built-in widget implementations. Each widget type (Button, Meter, Graph, Slider, etc.) is a WID module that implements: widget creation/deletion, property setters and getters, event handling (touch events mapped to widget callbacks), and render function (calls GDI to draw the widget based on its current properties and state).
Widget isolation: Each widget module is independent — adding a new widget type requires implementing only the WID module for that widget. No changes to GDI, EXEC, or lower layers. This is the extension point for custom widget development.
Layer 7 — APP: Application Layer
Responsibility: User application code and Flint-generated screen definitions. The APP layer calls the Sparklet API (SGUI_* functions) to load screens, bind data to widgets, respond to widget events, and trigger screen transitions. Flint UI Designer generates the screen definition files (sparklet_screens.c) at this layer — they are pure application-layer code, not part of the framework itself.
The APP layer is the only layer that changes between different products built on Sparklet. All 6 layers below the APP layer are the same across every Sparklet deployment on the same hardware platform. This is the architectural foundation of Sparklet’s development efficiency claim.
Memory Footprint: How the Architecture Enables 16 KB RAM
The layered architecture enables the 16 KB minimum RAM claim through selective layer configuration:
- Only the widget types used in the application are included at compile time (dead code elimination + conditional compilation in WID)
- UTIL image decode (PNG/JPEG) is optional — applications using only pre-decoded bitmap assets exclude the decode library entirely
- RS_MIN HSM depth is configurable — a simple linear screen flow requires a shallow state machine with minimal memory
- GDI framebuffer size is the dominant RAM cost and is configured to match the actual display resolution and colour depth
Explore the full Sparklet feature set, understand how hardware acceleration integrates at the GDI layer, or compare against alternatives at Why Choose Sparklet. Request the evaluation package to begin.