How we ship LVGL graphical interfaces on low-cost MCUs — memory budgets, frame-rate tuning, and when to choose LVGL over TouchGFX, drawn from three delivered products.
When a product needs a color screen but the bill of materials cannot justify an application processor, the graphics stack becomes one of the most consequential engineering decisions on the project. In our experience across handheld, instrumentation, and vehicle products, LVGL has become the default answer for low-cost microcontrollers: it is open source, written in C, requires no GPU, and ports across chip families with modest effort. That combination matters because cost-driven products frequently change silicon during development — a cheaper pin-compatible variant appears, a supplier offers better terms, and suddenly the GUI code must move. A framework tied to one vendor makes that move painful.
We have shipped LVGL on the Jieli AC79xx family, including the AC7911BB and AC7912AB controllers in a handheld game console and the AC7925A in a smart scale motherboard. In the same portfolio we have also shipped TouchGFX on an STM32-based vehicle dashboard. This article distills what those projects taught us about building LVGL interfaces on genuinely constrained hardware: how to budget memory before a single widget is drawn, how to keep animation smooth without a frame buffer the size of the screen, and how to decide honestly between LVGL and TouchGFX when both are on the table.
The single most common failure mode we see in LVGL projects is treating memory as an afterthought. A designer produces beautiful screens, developers implement them, and only during integration does anyone discover the heap is exhausted two screens deep. By then every fix is a compromise. Our rule is simple: the memory budget for the GUI is written down before the first screen is designed, and it is treated with the same seriousness as a power budget.
On the AC7911BB and AC7912AB handheld project — a handheld game console with a menu interface, pet raising, atmospheric lighting logic, charging management, and a boat simulation game — the GUI had to coexist with game logic, audio, and wireless stacks on the same chip. We approached this by separating concerns at the architecture level: LVGL owned the interface layer while SDL2 carried the cross-platform game logic, with CMake managing the build for both targets. Keeping the GUI framework and the game engine in distinct layers meant each could be budgeted, profiled, and optimized independently rather than fighting over one shared heap.
Several practices have proven their worth across our LVGL shipments:
The smart scale motherboard project reinforced the same discipline from a different angle. The AC7925A runs the LVGL interface while the AC792 SDK drives the weighing sensor, an AI server provides smart interaction, and a WeChat mini program handles remote management. Four subsystems share one chip, so the GUI budget was negotiated against sensor sampling, networking, and AI interface buffers from the start. When the GUI team knows exactly how much memory is theirs, interface design becomes a bounded creative problem instead of an open-ended risk.
Smooth animation on a constrained MCU is less about raw performance than about disciplined scheduling. LVGL redraws only what changes, and in our experience the products that feel fluid are the ones whose designers understood partial updates from the beginning. Every animated element should be small, bounded, and cheap to redraw. Full-screen transitions are used sparingly; small moving widgets, progress indicators, and state changes carry the sense of motion.
The handheld console project is our clearest example. The challenge was smooth game animation and a rich interactive experience on a small handheld screen — pet raising animations, atmospheric lighting effects, and a boat simulation game all had to feel alive. Our approach was systematic animation asset management: sequences were broken into discrete, reusable assets, each sized and budgeted in advance, so the animation system was a data problem with known costs rather than an open-ended rendering load. Reusable assets across the egg, character, snack, and background layers kept the total footprint predictable even as the content grew.
Equally important was the hardware iteration. The console hardware went through versions from V1.3 to V2, and each revision gave us measured feedback on what the display pipeline could actually sustain. In our experience, theoretical calculations about display bandwidth are no substitute for running the real animation set on the real panel. The multi-version iteration let us confirm frame pacing empirically and adjust asset complexity to match the hardware rather than the other way around.
A third lesson comes from the smart boat simulation and navigation system. There, SDL2 drove the boat dynamics simulation UI while LVGL provided the embedded GUI, with PID control handling precise heading. The challenge was real-time boat dynamics simulation plus precise heading control on an embedded platform while balancing low power consumption against real-time responsiveness. The takeaway for GUI work: the interface layer must never starve the control loop. We kept LVGL refresh work strictly bounded so that navigation control timing stayed deterministic — a principle that applies to any product where the screen shares a chip with time-critical work, from motor control to sensor sampling.
Measure the real pipeline on real hardware, early. The animation budget that survives contact with the panel is the only one that counts.
One more practice worth naming: prototype the interface on the desktop first. Because our handheld stack combined LVGL with SDL2 in a cross-platform framework, interface logic could be exercised on a PC long before the target hardware was stable. Animation timing, asset loading, and state machines were all validated in the desktop build, so bring-up on the MCU was about performance tuning rather than debugging logic. CMake made the dual-target build manageable, and the investment paid for itself many times over.
We are sometimes asked which framework to choose, and the honest answer is that we ship both — LVGL on the AC7911BB, AC7912AB, and AC7925A, and TouchGFX on the STM32-based e-bike dashboard. Having delivered production interfaces with each, here is how we think about the choice.
LVGL is our default for cost-driven products and for any project where the chip is not yet frozen. It is genuinely portable C with no vendor lock-in, which means the GUI investment survives a silicon change. On the Jieli AC79xx projects this was decisive: the interface code was decoupled from the chip vendor's SDK, and the team could reason about the GUI as its own layer. LVGL is also the natural fit when the product roadmap spans multiple chip families, or when the team already works in a CMake-based, cross-platform workflow with desktop simulation.
LVGL's open ecosystem is a practical advantage during development, not just a philosophical one. Community widgets, examples, and tooling shorten the path for common patterns, and because the source is open, the occasional deep bug in the rendering path can actually be investigated and fixed rather than worked around.
The e-bike dashboard ran on STM32 with TouchGFX, and it was the right call for that product. The challenge was clear information display plus smooth animations — boot sequence, gear indicator, compass — on a limited vehicle display resolution. TouchGFX's tight integration with the STM32Cube ecosystem meant the display driver, DMA configuration, and frame buffer setup were well-trodden paths rather than integration projects. The TouchGFX Designer workflow suited the product's needs: a dark theme UI, sequence-frame and MP4-style animations, and a systematic icon set, all iterated visually with interactive prototypes before a line of target code was written.
In our experience, TouchGFX earns its place when the silicon decision is already made and will not change, the team is invested in the STM32 toolchain, and the product benefits from a designer-driven workflow with visual iteration. The licensing and tooling costs are real, but for a stable STM32 platform they are typically outweighed by the integration speed.
Neither choice is universally better. The mistake is choosing on familiarity or marketing rather than on the product's actual constraints. We have seen projects struggle with LVGL on STM32 where TouchGFX would have integrated faster, and we have seen TouchGFX projects contort around a late silicon change that LVGL would have absorbed. Match the framework to the product, not the other way around.
Distilled from the three products above, here is the checklist we run through at the start of every LVGL engagement — part of our embedded development services practice:
Shipping LVGL on resource-constrained MCUs is not a heroic optimization exercise — it is a discipline exercise. Budget memory before designing, manage animation assets systematically, keep the GUI layer architecturally separate from time-critical work, and validate on real hardware early and often. The handheld console, the smart scale motherboard, and the boat navigation system each stressed different parts of that discipline: rich animation on a small screen, four subsystems sharing one chip, and a GUI that must never disturb a real-time control loop. The same practices held up in all three.
And when the product's constraints point elsewhere — a fixed STM32 platform, a designer-driven workflow, sequence-frame animation — we are equally comfortable shipping TouchGFX, as the e-bike dashboard demonstrated. The framework serves the product. If your team is weighing a graphical interface on a cost-sensitive MCU, that decision, and the memory budget behind it, is exactly where an experienced partner earns its keep.
Contact us for customized solutions and quotes