What Does Embedded GUI RTOS Support Mean?

Embedded GUI RTOS support means the GUI framework can operate within a real-time operating system's task model — running in a dedicated RTOS task alongside other application tasks such as sensor sampling, CAN or Ethernet communication, and control loops — without blocking those tasks, being blocked by them, or introducing unpredictable timing jitter. The GUI task runs at a defined priority, yields correctly between frames, and communicates with other tasks via message queues rather than shared memory with locking hazards.

Sparklet is designed for this model from the ground up. The Sparklet runtime executes entirely within a single dedicated task or thread. Input events from touch controllers, encoders, or buttons are queued from their interrupt service routines (ISRs) or driver tasks into the Sparklet event queue. Widget data updates from application tasks are submitted via Sparklet's thread-safe message queue API — the GUI task processes these updates on its next rendering pass. No mutex contention between the GUI and the application occurs in normal operation.

Sparklet supports: FreeRTOS, Azure RTOS (ThreadX), Zephyr, QNX, ITRON, Embedded Linux, Android AOSP, and bare metal. For platform-specific integration details, see the Supported Platforms page.

RTOS Integration — Environment by Environment

Detailed integration guidance for every supported RTOS and OS environment.

Running Sparklet on FreeRTOS

FreeRTOS is the most widely deployed RTOS in the embedded market and the most common environment for Sparklet. Create a dedicated FreeRTOS task with xTaskCreate(): 8–16 KB stack, medium priority (above communication drivers, below hard real-time ISR tasks). Call sgui_init() before starting the scheduler, then call sgui_execute() in the Sparklet task loop with a xQueueReceive() timeout of 16 ms for 60 fps frame pacing.

Touch controller input posts to a FreeRTOS queue from the ISR using xQueueSendFromISR(). Widget data updates from other tasks (CAN receive, sensor sampling) use Sparklet's sgui_post_update(widget_id, property, value) — non-blocking, lock-free, processed on the next render pass. On NXP i.MX RT1170 (dual Cortex-M7), use xTaskCreateAffinitySet() to pin the Sparklet task to a specific core for cache locality on framebuffer access. Validated on STM32, Renesas RA, and NXP i.MX RT platforms.

Running Sparklet on Azure RTOS ThreadX

Azure RTOS (ThreadX) is Microsoft's commercial-grade RTOS, widely used in industrial, medical, and automotive applications for deterministic scheduling, MISRA C compliance, and IEC 61508 safety certification. The Sparklet GUI task is created as a ThreadX thread with tx_thread_create(). Input events queue via TX_QUEUE; the event loop uses tx_queue_receive() with a timeout for blocking wait between frames. Widget updates from other threads use Sparklet's posted-update API, which uses a ThreadX queue internally.

Azure RTOS includes GUIX as its own GUI subsystem. Sparklet is an alternative for teams preferring Flint UI Designer's no-code workflow, Sparklet's royalty-free licensing, or richer 3D and animation capabilities. Sparklet is fully compatible with Azure RTOS USBX, NETX, and FileX middleware in the same firmware build — the GUI task does not interfere with those stacks.

Running Sparklet on Zephyr RTOS

Zephyr is a Linux Foundation open-source RTOS gaining adoption in industrial IoT, medical, and consumer embedded applications. Sparklet integrates as a standard Zephyr thread created with k_thread_create() or the K_THREAD_DEFINE macro. Display output uses either the Zephyr display API (display_write()) — which abstracts any Zephyr display driver (SPI, RGB, MIPI-DSI) — or a direct framebuffer write using the Zephyr DMA API for maximum performance.

Touch input on Zephyr uses the Zephyr input subsystem (Zephyr 3.3+) or a custom driver posting events to Sparklet's event queue via k_msgq_put(). The Zephyr port has been validated on Renesas RA, STM32, and NXP i.MX RT platforms. Sparklet's MISRA C compliance is maintained in the Zephyr build configuration.

Running Sparklet on QNX and ITRON

QNX Neutrino is a POSIX-compliant real-time microkernel OS used in automotive (ADAS, IVI), industrial, and medical applications. On QNX, Sparklet runs as a standard QNX process. Display output uses QNX Screen API (screen_post_window()) or maps to a framebuffer device via /dev/fb. Touch input arrives via QNX Screen events or the HID driver stack. Widget data updates from the application process use QNX message passing (MsgSend()) via Sparklet's IPC adapter — important in automotive HMI where ASIL requirements demand GUI process isolation from the safety-critical application process.

ITRON / μITRON is widely used in Japan across consumer electronics, automotive, and industrial equipment. Sparklet integrates with ITRON task and event flag primitives. The GUI task is created with cre_tsk(); input events use ITRON data queues (snd_dtq() from ISR). Validated on Renesas H8/SH and RA series MCUs.

Running Sparklet Without an RTOS

On ultra-constrained MCUs, or where RTOS overhead is unjustified, Sparklet runs in a bare metal super-loop. The application's main() initialises Sparklet and calls sgui_execute() in a while loop. Each call processes one frame: checks the input event queue, runs the state machine, executes due animation steps, and renders dirty regions to the framebuffer. Touch controller and encoder ISRs post events to Sparklet's self-contained ring buffer (no RTOS queue API required). A SysTick or timer interrupt provides the 1 ms tick for animation timing.

Application logic (sensor reading, communication polling) runs in the same loop — called before or after sgui_execute(). Bare metal deployment is the default for the Sparklet Windows simulator build, giving developers a working PC evaluation environment before any hardware is available. Memory footprint in bare metal configuration can be as low as 16 KB RAM — see the performance page for details.

RTOS Integration Comparison — Sparklet at a Glance

RTOS / Environment	Task Model	Input Queue Primitive	Integration Effort	Notes
FreeRTOS	xTaskCreate()	xQueueSendFromISR()	Low — pre-ported HAL	Most common Sparklet deployment
Azure RTOS (ThreadX)	tx_thread_create()	TX_QUEUE	Low — pre-ported HAL	MISRA C; works alongside USBX/NETX
Zephyr	k_thread_create()	k_msgq_put()	Low — display API abstraction	Validated on RA, STM32, i.MX RT
QNX Neutrino	QNX process (fork)	MsgSend() IPC	Medium — IPC adapter	Automotive ASIL process isolation
ITRON / μITRON	cre_tsk()	snd_dtq() from ISR	Low — pre-ported HAL	Common in Japanese OEM designs
Embedded Linux	pthread	evdev / POSIX queue	Low — framebuffer / DRM HAL	i.MX 8, RK3506G2, RZ/G
Bare Metal	while() super-loop	ISR ring buffer (self-contained)	Minimal — single HAL file	16 KB RAM minimum, quickest eval path

Thread Safety — The Single GUI Task Rule

Sparklet's thread-safety model is based on a single rule: all Sparklet API calls must be made from the GUI task or thread. This rule eliminates the need for mutexes around the widget tree, framebuffer, and rendering state — the most common source of GUI deadlocks and priority inversion in multi-threaded embedded applications.

How other tasks communicate with the GUI task:

Sparklet's posted-update API: Any task or ISR can call sgui_post_update(widget_id, property, value). This places the update onto Sparklet's lock-free ring-buffer queue without blocking. The GUI task reads and applies posted updates at the start of each frame. This is the recommended pattern for updating widget data (meter value, text string, image) from a sensor or communication task.
RTOS message queue (alternative): Teams can implement their own inter-task queue using native RTOS primitives (FreeRTOS queue, ThreadX TX_QUEUE, Zephyr k_msgq). The GUI task reads from this queue in its event loop and calls Sparklet widget APIs in response. Both approaches are correct; Sparklet's posted-update API reduces boilerplate.
Callback from GUI to application: Touch and input events trigger widget event callbacks in the GUI task context. If the callback needs to trigger an application task action (e.g., a button press starting a motor), post a message to the application task's queue rather than calling the motor driver directly from the GUI callback.

Contact Embien for integration guidance specific to your RTOS and application architecture. The embedded GUI features page provides an overview of the complete Sparklet capability set.

RTOS and OS Support at a Glance

Validated across the full range from bare metal Cortex-M0+ to Embedded Linux on MPU.

FreeRTOS Integration

Dedicated FreeRTOS task, xQueueSendFromISR for input, lock-free posted-update API for widget data. Validated on STM32, Renesas RA, NXP i.MX RT.

Azure RTOS ThreadX

Full MISRA C compliance maintained. Compatible with USBX, NETX, FileX in the same firmware. IEC 61508 safety-grade RTOS.

Zephyr Open-Source RTOS

Standard Zephyr thread, display API or direct DRM framebuffer. Input via Zephyr 3.3+ input subsystem. Open-source RTOS with growing MCU ecosystem.

Embedded Linux (MPU)

POSIX pthread on i.MX 8 and RK3506G2. Framebuffer or DRM/KMS display. GPU acceleration via EGL/OpenGL ES on Mali and other Linux GPU drivers.

Frequently Asked Questions

Which RTOS does Sparklet embedded GUI support?

Sparklet supports FreeRTOS, Azure RTOS (ThreadX), Zephyr, QNX Neutrino, ITRON and μITRON, Embedded Linux, Android AOSP, and bare metal (no RTOS). The same Sparklet UI codebase runs in all these environments — only the HAL layer (event queue primitives, display flush call) changes per environment. Sparklet ships with pre-ported HAL implementations for all listed environments.

How do you run embedded GUI on FreeRTOS?

Is Sparklet thread-safe for RTOS applications?

Can Sparklet run without an RTOS on bare metal?

How do I update a Sparklet widget from a different RTOS task?

Does Sparklet work with Azure RTOS on STM32?

Embedded GUI Across Every RTOS — and Bare Metal