Choosing an embedded GUI stack on a small MCU

A small microcontroller with a display is a specific machine. Flash is counted in hundreds of kilobytes or a few megabytes. RAM is the number that actually decides the design. There is no GPU in the sense a phone has one. There may be a pixel pipeline, a chrom-art block, or nothing but a SPI panel and a CPU that also runs the product. The GUI is not a separate computer. It shares the part with audio, radios, sensors, and the update path.

Three stacks show up in that conversation often enough to deserve a written comparison: LVGL, Qt for MCUs, and ST’s TouchGFX. They are not interchangeable skins. They encode different bets about memory, vendor lock, and who is allowed to edit a screen. This note is a set of criteria. It is not a hit piece, and it is not a recommendation to rip out a stack that is already shipping.

What “small” means here

If you have a Linux SoC and a full framebuffer, you are not in this note. You are choosing between a toolkit on a real OS. The interesting case is the MCU that must own the screen and the product at once. Typical tells: the framebuffer may not fit in RAM at full color depth; fonts are a flash budget; animations compete with a radio ISR; a second language can break the image.

Write the budget down before you write the screen list. Flash for code and assets. RAM for buffers, widgets, and the worst screen. CPU for the refresh you actually need, not the refresh the datasheet advertises. Input: capacitive touch, a few buttons, an encoder, or a remote protocol. Those numbers do more work than a feature matrix copied from a vendor page.

The three stacks, as they actually present

LVGL

LVGL is an open widget tree you compile into the firmware. You own the port: display flush, input read, tick, and the heap you give it. That ownership is the point. You can run it on parts that will never have a first-party designer. You can read the code. You can strip what you do not use. You also own the unglamorous work — the flush that meets this panel, the partial refresh that meets this RAM, the font pipeline that meets this language list.

LVGL is a good default when the MCU is not from a single vendor’s GUI program, when the team is firmware-first, and when you need the same tree on more than one silicon family. It is a worse default when the organization expects a designer to own every pixel without touching C, and nobody has budgeted the port.

Qt for MCUs

Qt for MCUs is a QML-shaped runtime aimed at microcontrollers, not a shrink of desktop Qt. You buy into a toolchain, a license, and a way of writing UI that designers and some application engineers already know. On a part that the port supports, that can be faster than growing a widget tree by hand. On a part it does not support, it is not a candidate. The commercial relationship is a criterion, not a moral failing. Some teams need it. Some teams cannot carry it.

Use Qt for MCUs as a serious option when QML is already a team skill, when the MCU is on the supported list, and when the license is acceptable for the life of the product. Do not pick it to “look modern.” Do not pick it if the only person who can rebuild the UI leaves in six months and the license server is someone else’s problem.

STM32 TouchGFX

TouchGFX is ST’s answer for ST parts: a designer, a generated tree, and a story that assumes STM32. If you are already on STM32 and the designer matches how the product team wants to work, it can be the shortest path from a picture to a screen that flushes. The lock is honest. You are not taking TouchGFX to a foreign MCU as a portable engine. You are taking ST’s GUI stack on ST’s silicon.

That is a valid bet when the MCU family is settled and you want the vendor’s designer in the loop. It is a poor bet when the next product might leave the family, or when the firmware team refuses to own generated code they cannot read in a week.

Criteria that actually decide

Ignore slogans. Score the project on the following, in writing, with the numbers you have.

• RAM at the worst screen, including the buffer strategy you can afford (full, partial, double).
• Flash for code plus fonts plus bitmaps, with a second language included.
• Whether the MCU vendor ships a first-party GUI you would be foolish to ignore.
• Who edits a screen: firmware engineers, a designer in a tool, or both.
• Input and animation load versus the CPU that also runs the product.
• License and long-term rebuild: can a new engineer produce the same binary in a year.
• Portability across a family versus depth on one vendor.
• How you will test a screen without a photograph of a bench.

A stack that loses on three of those is not “wrong.” It is wrong for this product. A stack that wins on designer workflow and loses on RAM is still a fail if the part cannot hold the framebuffer. Be boring. Write the fail down.

A working order of decision

First, freeze the panel interface and the color depth you will actually ship. Then freeze RAM and flash with a margin, not a hope. Then list the screens and the one animation you cannot cut. Then ask whether the MCU vendor has a GUI program you would have to justify leaving. Then ask who will change a string in November. Only then pick a stack.

If the part is not STM32 and you do not already live in QML, LVGL is usually the stack you can defend. If the part is STM32 and a designer will own the look, TouchGFX is usually the stack you can defend. If QML is already how the organization writes UI and the MCU is supported, Qt for MCUs is usually the stack you can defend. Those sentences are priors, not conclusions. The budget can invert any of them.

Do not run a three-way bake-off as theatre. A bake-off is useful when two stacks are still plausible after the budget is written, and you need one screen implemented both ways to see flush time and flash. It is waste when the RAM number already eliminated two of them. If you do run one, write the scoring sheet first. Otherwise you will pick the demo that looked nicest on a development kit.

What to hand another engineer

The decision is not done when the first screen paints. Hand over the budget, the port points (flush, input, tick), the font pipeline, the screen map, and the reason the other two stacks lost. That last page saves a rewrite in the next revision. It also keeps a future argument honest.

ASHNAY SOFTWARE will take this class of work as firmware. We do not design the panel. We will read the datasheet and the schematic to drive what you already fitted. The principal has done display firmware and embedded GUI work on shipping products; that record is his, and it is described without product names on the Work pages. This note is the public selection method.