QR codes have become a ubiquitous way to encode and share information, URLs, contact details, configuration parameters, and more. With LVGL, embedding a QR code into your embedded UI is straightforward. In this post, we’ll explore how to use QR codes in LVGL, discuss the limits of QR code sizing on embedded displays, and take a step back to reflect on the design philosophy behind these clever square patterns.

Using QR Codes in LVGL

Starting from LVGL v8, the library includes a built-in widget for generating and displaying QR codes.

Here's a simple example:

int main(lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");) {
  return 0;
}

lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");
}

int main(lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");) {
  return 0;
}

lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");
}

This snippet creates a 100x100 pixel QR code in black on a white background. The lv_qrcode_update function encodes the string into the QR pattern.

Display Limitations and Scaling

The size of your QR code is constrained by:

• The screen resolution
• The desired readability (especially when using a camera)
• The error correction level and data complexity

LVGL supports scaling the QR pattern with pixel-perfect precision. However, embedded displays often have limited resolution. For example, on a 128x128 screen, you might only fit a version 2 QR code (~25x25 modules) cleanly, assuming each module is 4-5 pixels.

⚠️ Rule of thumb: Always scale each module (square) to at least 3x3 pixels for reliable scanning.

A Word on QR Code Structure

QR codes are built using a defined standard (ISO/IEC 18004), consisting of:

• Finder patterns: the large corner squares
• Alignment patterns: help correct distortion
• Timing patterns: guide scanning across rows/columns
• Error correction: allows reading even if damaged

The LVGL QR widget internally uses a compact QR generation algorithm, based on qrcodegen, optimized for embedded use. You won’t need to implement these patterns yourself, but understanding them helps debug issues (e.g., too much data, unreadable codes).

Philosophy: More Than a Matrix

What makes QR codes elegant is their balance between redundancy and compression. They:

• Handle data loss gracefully with Reed-Solomon error correction
• Encode multiple formats (text, binary, etc.)
• Remain visually consistent while encoding vastly different content

In an embedded system, this philosophy matches our priorities: reliability, compactness, and clarity. With LVGL, you can embed this visual language into your UI effortlessly.

LVGL QR Code Integration Limitations

While the QR code widget in LVGL provides a convenient interface for rendering QR codes, it’s important to be aware of its design constraints and lack of configurability, especially if you need finer control for production-level applications.

🔚Conclusion

LVGL’s QR code integration is simple, efficient, and well-suited for many embedded use cases, especially where memory and performance matter.

It gets the job done when you need to display a basic QR code, and it integrates cleanly into the LVGL object model using lv_canvas. However, it stops short of offering full control. Features like error correction level, mask pattern selection, quiet zone size, and detailed error feedback are fixed or not exposed. For most developers, this may not be an issue, but for those needing fine-tuned QR generation (e.g., for branding, versioning, or resilience), the current implementation feels limiting.

That said… who knows? Maybe a patch is on the way to bring these missing features to LVGL. Stay tuned 😉

Hard realtime systems is the third axis of competences we have at EDGEMTech.

It concerns all aspects (development, tuning and optimization, porting, debugging, etc.) related to hard realtime systems (mainly x86 and ARM Linux-based systems).

Do not hesitate to contact our expert Daniel Rossier for any advice.

Have you ever thought that x86 would gradually leave the world of embedded systems?

The Sapphire Edge+ VPR-4616-MB is a Mini-ITX motherboard that includes the AMD Versal AI Edge VE2302 device plus an AMD Ryzen Embedded R2314 processor, along with a flexible I/O interface to connect to various peripherals and sensors.

Our Engineers are on hand to give you the necessary expertises in hard realtime systems based on Linux for your new development, if you envisage to start a new product or to port an existing realtime sy

If your embedded system requires real-time constraints, don't worry! The Linux operating system remains a top choice. With significant advancements in the upstream RT-PREEMPT extension over the past three years, you can now run applications on isolated CPU cores with minimal latency and jitter.

However, some specific use cases—particularly those requiring hard real-time performance in user-space applications—can be tricky. Combining RT and non-RT tasks in the same environment may lead to interference, and implementing non-GPL closed-source code within the kernel only adds to the complexity.

For these challenges, the EVL (Xenomai 4) extension is a powerful alternative to RT-PREEMPT. Here’s why

:

• Out-of-Band (OOB) Functions: Guarantee hard real-time conditions across execution paths, ensuring deterministic behavior for critical tasks.
• Clean RT/Non-RT Separation: Isolates the real-time domain from standard Linux tasks, minimizing interference.
• Scalable Architecture: Works seamlessly on popular ARM-based SoCs, such as Raspberry Pi, NXP, TI platforms, making it versatile for various embedded projects.
• Hard Real-Time User-Space Applications: Ideal for scenarios where real-time functionality must remain closed-source without relying on kernel modifications.

Whether you're tackling hard real-time constraints, maintaining user-space applications, or working with ARM-based systems, EVL offers an innovative and reliable solution.

It's definitely worth considering for your next project!

se of Linux RT-Preempt Kernel 6.12 marks another significant step in enhancing real-time performance for critical applications. This version introduces improved low-latency scheduling, deterministic behavior, and better IRQ handling, providing a more stable foundation for industrial automation, robotics, and other real-time workloads.

With enhanced IRQ threading, latency spikes are significantly reduced, even under high-load scenarios. The improved preemptibility ensures consistent response times for real-time applications, making the system more predictable. CPU isolation techniques have also been refined, minimizing jitter and improving determinism.

Additionally, real-time scheduling policies have been optimized, increasing efficiency for time-sensitive operations.

However, some areas in the kernel still pose potential risks for latency spikes during real-time operations. For instance, the seccomp() syscall triggers a call to the tlb_flush_all() function, which invalides all TLBs on all CPUs.

On an x86 machine with an SMP configuration, this function relies on a special APIC mechanism to broadcast IPIs to all CPUs in a single instruction. The problem? There’s no check against an isolated CPU, which should not be disturbed especially if an RT application is performing constant read/write operations. The IPI results in a CPU interrupt, introducing a latency spike.

Here's a excerpt of function call path:

tlb_flush_all(void) -> ... -> x2apic_send_IPI_allbutself() -> .. -> __wrmsr()

tlb_flush_all(void) -> ... -> x2apic_send_IPI_allbutself() -> .. -> __wrmsr()

At the end, there is only one instruction doing the work:

static __always_inline void __wrmsr(unsigned int msr, u32 low, u32 high)
{
	asm volatile("1: wrmsr\n"
		     "2:\n"
		     _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR)
		     : : "c" (msr), "a"(low), "d" (high) : "memory");
}

static __always_inline void __wrmsr(unsigned int msr, u32 low, u32 high)
{
	asm volatile("1: wrmsr\n"
		     "2:\n"
		     _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR)
		     : : "c" (msr), "a"(low), "d" (high) : "memory");
}

Fortunately, there's a workaround: pass the no_ipi_broadcast=1 argument to the kernel command line. A simple fix, but not an obvious one! This problem became apparent when we noticed unexpected high latency spikes when performing basic operations such as ssh'ing to the remote machine running an RT application.

.

Looking Ahead

Beyond these considerations, Linux RT-Preempt 6.12 continues to push the boundaries of real-time performance, making it an excellent choice for embedded systems and time-critical applications. As adoption grows, its impact will likely extend further into robotics, telecommunications, and automotive systems.

Looking forward to sharing insights and experiences on its implementation in various real-time environments!

ndustrial automation, robotics, and CNC systems, achieving hard real-time determinism is crucial for safety, precision, and performance. Many systems rely on costly proprietary solutions to meet those demands—but OpenCN offers an open, modular alternative specifically built for embedded motion control with microsecond-level timing precision. Released under the GPLv2 license, OpenCN promotes transparency, adaptability, and long-term sustainability—making it an excellent foundation for building reliable, real-time automation systems without vendor lock-in.

OpenCN is ideal for developers and integrators looking for affordable, real-time, and production-grade control systems that don't compromise on timing guarantees or long-term maintainability.

OpenCN originates from the well-known LinuxCNC project, whose architecture has powered machine tools and motion platforms for decades. However, traditional LinuxCNC relies on either soft real-time or hybrid userspace/hard real-time setups, often with considerable complexity or overhead.

🧠 Real-Time Core: Xenomai/Cobalt, Streamlined and Evolved

At the foundation of OpenCN lies a customized hard real-time core based on Xenomai/Cobalt. Unlike traditional implementations, OpenCN’s version removes the I-Pipe layer—a legacy abstraction once required to enable real-time co-kernels within Linux. This results in a lighter, cleaner, and more maintainable integration with the Linux kernel.

This architecture not only reduces latency and jitter but aligns with the forward-looking design principles of Xenomai 4 / EVL—while retaining the mature and proven scheduling and interrupt management features of Cobalt.

Benefits include:

• Hard real-time determinism
• Reduced system overhead
• Compatibility with recent Linux kernels
• Customizability for embedded deployments

The overall picture below shows the general OpenCN environment.

OpenCN General Architecture

⚙️ Multicore Isolation for Determinism

OpenCN fully leverages asymmetric multicore processing, a key strategy for ensuring hard real-time behavior in modern multi-core systems. This allows:

• Time-critical control loops to run on dedicated CPU cores
• Background tasks such as networking, data logging, or user interfaces to be confined to separate cores
• A predictable and interference-free real-time environment

This isolation model is essential for systems where control loops must execute with fixed cycle times, regardless of system load.

💻 Runs on x86 and Raspberry Pi 4/5

OpenCN runs natively on both:

• x86 industrial PCs for performance-intensive applications
• ARM-based platforms, including Raspberry Pi 4 and 5, for compact and low-cost deployments

This range of support makes it well-suited for:

• Prototyping motion systems
• Retrofitting legacy equipment
• Deploying cost-sensitive automation solutions
• Educational and academic use cases

Despite its efficiency, OpenCN delivers the hard real-time behavior expected in high-end industrial controllers.

🔌 EtherCAT for Real-Time Industrial Communication

OpenCN includes native support for EtherCAT drivers, allowing deterministic, synchronized communication with:

• Servo and stepper motor drives
• I/O expansion modules
• Distributed sensors and actuators
•  

EtherCAT is the primary fieldbus supported, ensuring seamless integration into modern industrial automation ecosystems. This makes OpenCN particularly well-suited for motion control platforms, where high-speed field communication is critical.

📡 User Interface and System Monitoring

OpenCN includes a remote user interface, which can run on a separate PC or tablet. This interface allows users to:

• Configure the system
• Monitor machine operations in real time
• Visualize and log control signals
• Optimize control parameters based on process feedback

Such capabilities are essential for maintaining high precision and quality in automated machining and robotic workflows.

🛠 EDGEMTech: Your Partner for Real-Time Embedded Control

At EDGEMTech, we have deep experience with OpenCN—many of our engineers were directly involved in its development and deployment. We offer:

• Long-term support and maintenance
• Custom adaptations to specific hardware platforms or motor drive integrations
• Kernel and driver-level customization to meet hard real-time requirements
• Consulting on deploying OpenCN in production systems or as part of Industry 4.0 strategies

Whether you’re building a CNC machine, an advanced robot, or a precision automation line, EDGEMTech can provide the expertise and support to make OpenCN a stable, tailored, and sustainable solution.

🔧 Summary

OpenCN proves that hard real-time control, open-source freedom, and embedded efficiency can go hand in hand.With native EtherCAT support, deterministic execution, and lightweight architecture, it offers a powerful foundation for next-generation control systems.

🔗 Learn more about OpenCN

We invite you to share your experiences, ask technical questions, or explore OpenCN's capabilities with us here in the Realtime Systems section.

Let’s build deterministic systems—together.

mbedded virtualization is an innovative approach that significantly enhances the versatility of multi-core microcontroller units (MCUs) by enabling multiple execution environments on a single platform. This technique allows different operating systems and applications to coexist, offering a range of powerful use cases. Here’s a closer look at its potential and benefits.

Key Use Cases for Embedded Virtualization

1. Critical Systems: Running a real-time operating system (RTOS) alongside a general-purpose OS, like Linux, to manage time-sensitive tasks without sacrificing usability.
2. Secure Environments: Isolating secure applications with a dedicated OS while allowing non-secure apps to run separately.
3. Hardware Resource Partitioning: Efficiently dividing CPU cores, memory, and peripherals among different virtual environments.
4. Heterogeneous Environments: Managing different operating systems (e.g., Linux, Windows) on the same MCU.

Enhanced Device Management

Managing a large fleet of embedded devices becomes more streamlined with virtualization. During software upgrades, virtualization minimizes disruption, allowing seamless updates while maintaining service availability.

Improved Security and Resource Management

Virtualization significantly bolsters application security by isolating memory and dedicating CPU cores to specific tasks. A hypervisor, acting as a bare-metal software layer, manages the guest operating systems, coordinates interactions, and optimizes hardware utilization.

Hypervisors vs. Containers

It’s essential to distinguish between hypervisors and containerized environments:

• Hypervisors: Operate directly on the hardware, offering robust isolation and control. Suitable for lightweight guest OS environments, especially when resources are constrained.
• Containers: Managed by a daemon (e.g., Docker), tightly integrated with a host OS (like Linux). While ideal for scalability and performance, containers may consume significant RAM and CPU, making them less suitable for low-resource systems.

One promising combination is leveraging TorizonOS with Docker for scalable application management, while using a hypervisor with lightweight guest OS (such as SO3, developed by HEIG-VD) for data processing and analysis. This dual approach can optimize performance and security, particularly in constrained hardware environments.

EDGEMTech’s Vision

At EDGEMTech, we are actively exploring the synergy between containerized environments (via TorizonOS) and hypervisor-based lightweight OS approaches (like SO3). Our goal is to create robust, secure, and efficient solutions that maximize the potential of embedded systems, even within limited hardware constraints.

Join the discussion and share your thoughts on embedded virtualization. What challenges have you faced, and how have you addressed them in your projects?

In Debugging embedded applications — especially graphical ones — without hardware can be challenging.

Fortunately, emulated environments like QEMU offer an ideal solution for running and debugging cross-compiled ARM64 applications. Using QEMU with IDEs such as Eclipse or VSCode provides a powerful and flexible setup for developers.

Personally, after many years of experience with Eclipse + GDB, I still consider it among the best free solutions for graphical debugging. That said, VSCode has made significant strides recently, offering a smooth and efficient debugging experience.

Why QEMU for LVGL Development?

In this new series of articles, we will explore the fascinating world of QEMU emulation, with a focus on debugging LVGL applications — a library we actively deploy across various hardware platforms.

In this first post, we will cover the basics of how to set up a GDB debugging environment with QEMU (AArch64).

through source-level debugging of an LVGL application, all inside a QEMU/virt64 environment. No hardware needed — just a modern Linux host and developer tools

Today we’ll dive into the execution of an LVGL application and explore the LVGL library internals — all inside a QEMU/virt64 emulated environment. Yep: no hardware required. 🙂

What you’ll do

• Build the default Infrabase environment and QEMU.
• Enable debug symbols for your LVGL app and the LVGL library.
• Launch the emulated GUI and attach VS Code + gdb-multiarch.
• Inspect the call stack and step through the LVGL main loop.

1) Build the base system

From a fresh clone, bootstrap and build the default configuration:

$ source env.sh
$ build.sh -a

$ source env.sh
$ build.sh -a

The first build takes ~45 minutes (it compiles a Buildroot-based root filesystem).

Since we’re using an emulated target, build QEMU as well:

$ build.sh -q

$ build.sh -q

Start the graphical environment:

$ ./stg.sh

$ ./stg.sh

You should see the LVGL demo windows pop up in a desktop-like session.

Tip: stg.sh launches QEMU with a GDB server so your debugger can attach on localhost:1234.

The lvglsim application running in the QEMU/virt64 environment

2) Turn on debug symbols for the app and LVGL

We want source-level debugging with function names and line info.

Edit linux/usr/src/lvgl/lv_port_linux/CMakeLists.txt and set a debug build. If there’s a line that sets CMAKE_BUILD_TYPE to Debug, uncomment it (or add this if needed):

set(CMAKE_BUILD_TYPE Debug)

Uncomment the line to enable Debug (line 13)

Then clean the user build and rebuild with debug info:

$ cd linux/usr
$ rm -rf build/
$ ./build.sh
# or from repo root:
$ build.sh -u

$ cd linux/usr
$ rm -rf build/
$ ./build.sh
# or from repo root:
$ build.sh -u

This ensures your binaries are compiled with -g.

Heads-up: Make sure any stripping step is disabled for your debug build (don’t strip symbols).

3) VS Code debug configuration

Install the C/C++ extension (Microsoft) and ensure gdb-multiarch is available on your host (e.g., sudo apt install gdb-multiarch on Debian/Ubuntu).

Create or update .vscode/launch.json with:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) USR lvglsim",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/linux/usr/build/bin/lvglsim",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb-multiarch",
      "miDebuggerServerAddress": "localhost:1234",
      "setupCommands": 
    }
  ]
}

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) USR lvglsim",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/linux/usr/build/bin/lvglsim",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb-multiarch",
      "miDebuggerServerAddress": "localhost:1234",
      "setupCommands": 
    }
  ]
}

Why this works: When stg.sh starts QEMU, it exposes a GDB server on localhost:1234. VS Code’s cppdbg connects to it using gdb-multiarch, while program points to your local ELF with symbols so the debugger can resolve sources.

4) Attach, pause, and inspect the stack

• Launch the “(gdb) USR lvglsim” configuration in VS Code.
• It will auto-connect to QEMU (localhost:1234).
• Hit Pause to freeze the target and open the Call Stack.

You should land somewhere inside the LVGL driver/timer machinery.

Inspect the source code and stack trace of a running LVGL application

 Typical path:

main()
  → run_loop_fbdev()
     → lv_timer_handler()
        → lv_timer_exec()  // internal timer execution
           → … draw/invalidations …

main()
  → run_loop_fbdev()
     → lv_timer_handler()
        → lv_timer_exec()  // internal timer execution
           → … draw/invalidations …

LVGL runs a timer-driven event loop that triggers area invalidation and re-drawing. Stepping through this loop is incredibly useful for understanding rendering flow, timing, and where your app’s events slot in.

5) Handy breakpoints to try

• main() — entry point of your app.
• run_loop_fbdev() — where the frame-buffer loop hooks into LVGL.
• lv_timer_handler() — heart of LVGL’s scheduling.
• lv_refr_area() / lv_disp_refr_* — screen refresh paths.
• Your widget callbacks (e.g., event handlers) — to trace UI interaction flow.

Pro-tip: If you see an enormous stack, use stack filtering in VS Code and add function breakpoints for specific LVGL symbols to jump right where it matters.

6) Troubleshooting

• Can’t connect to localhost:1234?Make sure stg.sh/QEMU is running. If your setup uses a different port, update miDebuggerServerAddress.
• No source lines / function names?Confirm CMAKE_BUILD_TYPE=Debug is active and that you rebuilt after cleaning linux/usr/build/. Check your final binary with file linux/usr/build/bin/lvglsim (should mention “with debug_info”).
• Wrong architecture warnings in gdb?Use gdb-multiarch (not the host’s default gdb). The target is aarch64/virt64.

What you learn

• How LVGL’s timer engine orchestrates redraws.
• Where your app code participates in the event → draw pipeline.
• How to pause anywhere, read a precise call stack, and step through rendering.

That’s it — enjoy LVGL debugging with Infrabase!

If you haven’t read the intro to our BitBake/OpenEmbedded setup yet, start here.Questions or tips from your own sessions are very welcome in the thread!

and methods to create custom Linux-based systems.

Yocto offers unparalleled flexibility and control.

🔧 Why Yocto?

✔ Customizability: Tailor your Linux distribution to meet specific project needs.

✔ Scalability: Easily adapt to different hardware platforms.

✔ Community Support: Leverage a vibrant community for continuous improvement and innovation.

Incorporating Yocto into the workflow enables the dev team to streamline development,

reduce time-to-market, and maintain robust, secure systems.