Selecting an embedded GUI library is a decision with a long tail — the framework you choose on day one shapes development tooling, certification strategy, hardware platform flexibility, and licensing economics across the product's entire lifecycle. A poorly-evaluated framework decision is expensive to reverse: UI code, HAL integrations, and toolchain dependencies all become coupled to the framework over time. This guide provides a structured evaluation process covering the eight criteria that most consistently determine production success, with specific questions to ask of any framework vendor or community before committing.
Step 1: Define Your Project Requirements Before Evaluating Any Framework
Framework evaluation without a clear requirements baseline produces comparisons that miss what actually matters for your project. Before opening any framework documentation, document:
- Target hardware: MCU family, RAM and flash budget, display resolution and interface (MIPI DSI, RGB parallel, SPI), touch controller type
- OS/RTOS: Bare metal, FreeRTOS, Azure RTOS, Zephyr, QNX, embedded Linux — or multiple targets
- Safety requirements: Is the application safety-critical? What standard applies — ISO 26262 (ASIL A–D), IEC 62304 (Class A/B/C), IEC 61508 (SIL 1–4)?
- UI complexity: Number of screens, animation requirements, state machine complexity, data binding needs, multi-language support
- Team profile: Embedded software engineers only, or also UX designers? Design tool requirement?
- Production volume: Units per year — determines whether per-unit royalty cost is material
- Platform roadmap: Single silicon vendor committed, or multi-vendor strategy? Hardware change risk?
With these requirements documented, each subsequent evaluation criterion can be scored against actual project needs — not against a generic feature matrix.
Step 2: Evaluate the Licensing Model
Embedded GUI frameworks use several licensing models, each with different risk and cost profiles:
- MIT Open Source : No acquisition cost. No restrictions on commercial use. No per-unit royalty. Community support only. No SLA.
- Per-unit royalty : Commercial license with per-device fee on every unit shipped. Cost scales indefinitely with production volume.
- Royalty-free per seat : Fixed cost per developer using the framework during development. Zero per-unit fee regardless of production volume. Includes professional support.
- Vendor-bundled free : Free on specific hardware, proprietary on others. No per-unit fee on supported hardware, but platform portability is restricted.
Questions to ask: What is the per-unit cost at your expected 3-year production volume? What happens to licensing if the framework vendor is acquired or discontinues the product? Is source code available for audit, or binary only?
Step 3: Assess Safety Compliance Requirements
If your application is safety-critical, determine the compliance requirements before evaluating features. MISRA C compliance of the GUI library has direct certification impact:
- A non-MISRA-compliant library requires a gap analysis (static analysis + deviation documentation) before it can be used in a safety assessment
- Gap analysis consumes safety engineering time — typically the most expensive and constrained resource on a safety-critical project
- Deviation documentation must be maintained through every library version update used in production
Questions to ask: Is the library MISRA C:2012 compliant? Which rules — mandatory only, or mandatory + required? Is a deviation list and static analysis report available? Is compliance maintained across all production releases?
Filter frameworks that cannot answer these questions credibly before evaluating any other feature. See the Sparklet feature overview for our MISRA C compliance approach.
Step 4: Evaluate Design Tooling
The design tool is where embedded UI development time is actually spent. Framework performance benchmarks and widget counts matter, but if the development workflow is slow, the project is slow. Evaluate:
- WYSIWYG design: Can screens be designed visually and previewed without compiling? Can a UX designer participate without writing C code?
- State machine support: Does the tool support visual state machine design, or does all state logic need to be hand-coded?
- Code generation: Does the tool generate production-ready, platform-agnostic code, or scaffold code that requires significant manual editing?
- Animation timeline: Can animations and transitions be designed visually and previewed in the tool?
- Asset import: Can Figma, PNG, JPG, and font files be imported directly? Are assets optimised automatically for target memory constraints?
Try the tool on a representative screen from your actual project — not a demo. Time how long it takes to implement a screen with three widgets, two navigation states, and an animated transition. This is the most direct indicator of whether the tooling will help or hinder your project. Learn about Flint UI Designer's capabilities.
Step 5: Test Hardware Acceleration on Your Target Platform
Hardware acceleration benchmarks should be run on your actual target hardware with your actual display — not on reference boards with reference displays. The relevant measurement is frames per second (fps) for a representative screen at your target resolution, with all layers active (background, widgets, animations). Specifically:
- What fps does the framework achieve with software rendering only?
- What fps does it achieve with hardware acceleration enabled?
- Which operations are accelerated — pixel fill only, or also alpha blending, image blit, affine transform?
- Is the acceleration integration validated by the vendor on your specific MCU variant and display interface?
A framework that claims hardware acceleration but only accelerates basic pixel fill while leaving alpha blending and compositing on the CPU will not deliver the frame rate its benchmarks suggest. Ask for validation data on your specific platform. See Sparklet performance benchmarks and supported platform hardware acceleration details.
Step 6: Measure Memory Footprint on Your Constraints
Framework documentation typically quotes minimum RAM in ideal conditions. The relevant measure is the RAM required for your specific UI — number of active screens, widget count, framebuffer allocation, and asset memory. Request or build a representative test application and measure:
- Code (flash) footprint of the framework with your feature set enabled
- RAM footprint at runtime with your target screen layout active
- Framebuffer RAM requirements for your display resolution and colour depth
- Asset RAM requirements for your fonts and images
The sum of these values must fit within your MCU's available flash and RAM after your application firmware is accounted for. Leave 20–30% headroom for future UI additions. Sparklet's minimum RAM of 16 KB and configurable feature inclusion keeps it viable on cost-optimised MCUs where other frameworks cannot fit.
Step 7: Evaluate Platform Support and Portability
Document the platforms the framework officially supports — not claimed ports, but vendor-validated, hardware-accelerated, documented integrations. Then evaluate:
- Is your current target hardware in the officially supported list?
- Are the other MCU platforms in your organisation's hardware roadmap supported?
- If you need to move to a new silicon vendor in 18 months, what porting effort does the framework require?
- Is the HAL architecture clean enough that a porting engagement is well-defined and bounded in scope?
A framework with one supported platform is a liability if hardware flexibility matters. A framework where porting requires more than HAL modifications — where rendering logic, display list management, or acceleration integration is platform-specific — creates lock-in risk that is hard to quantify until it becomes a crisis. See Sparklet's supported platforms.
Step 8: Assess Support Quality
The support model determines how quickly blocking issues get resolved in production. Evaluate by actually testing the support channel:
- Post a non-trivial technical question (HAL integration question for a specific MCU, rendering timing question) to the community forum or support channel. Measure response time and answer quality.
- Ask whether the support team has direct access to the framework source code — or whether they are themselves relying on documentation.
- Ask for a reference customer contact who has used the framework in production. Ask them about their support experience during integration and after launch.
Community support is not equivalent to engineering support. For production products where blocked engineering time has a daily cost, the support model is a business continuity consideration — not just a convenience.
Evaluation Scorecard: Summary Questions
Run each candidate framework through this scorecard before making a selection decision:
- Does it meet MISRA C:2012 requirements with documentation? (Yes/No — filter criterion for safety projects)
- Is the licensing model royalty-free at production volume, with a known fixed cost?
- Does the design tool allow visual WYSIWYG design, state machine editing, and code generation without manual editing?
- Does hardware acceleration cover alpha blending, image blit, and compositing — not just pixel fill?
- Does it run your representative UI within your RAM/flash budget with 20% headroom?
- Is your target MCU in the officially supported and validated platform list?
- Can the UI codebase move to a new silicon platform with HAL-only changes?
- Is direct engineering support available with a defined response commitment?
Evaluate Sparklet Against Your Requirements
Sparklet is available for evaluation free of charge — Flint UI Designer and platform binaries for all supported hardware, including the Windows simulator for rapid UI prototyping without target hardware. Run the scorecard above against Sparklet with your actual requirements and your actual target hardware. Request the evaluation package here.