Kapitel 19 – ESP32 / Pico Architektur für LVGL Projekte

LVGL 9 mit MicroPython
Kapitel	19
Titel	ESP32 / Pico Architektur für LVGL Projekte
Voraussetzungen	Grundkenntnisse in MicroPython
Getestet mit	LVGL 9.x
Schwierigkeitsgrad	★★★★☆
Benötigte Zeit	60 Minuten
Status	in Arbeit

Kapitel 19 – ESP32 / Pico Architektur für LVGL Projekte

Lernziel

Nach diesem Kapitel kannst du

• LVGL-Projekte sauber strukturieren,
• UI und Hardware logisch trennen,
• typische Stabilitätsprobleme vermeiden,
• ESP32 / Pico Projekte skalierbar aufbauen.

Grundproblem

Viele LVGL-Projekte scheitern nicht an LVGL selbst,

sondern an schlechter Struktur:

• UI mischt sich mit Hardware-Code
• Sensoren blockieren die GUI
• Timer und Events werden chaotisch genutzt
• globale Variablen wachsen unkontrolliert

Zielstruktur

Ein stabiles System besteht aus drei Ebenen:

1. Hardware-Schicht

• Sensoren (I2C, SPI, ADC)
• GPIO
• WLAN / ESP-NOW
• IMU / QMI8658

2. Logik-Schicht

• Daten verarbeiten
• Filtern
• Skalieren
• Zustände verwalten

3. UI-Schicht (LVGL)

• Anzeigen
• Buttons
• Layout
• Events

Grundregel

Merke

LVGL darf niemals direkt Hardware lesen.

Datenfluss

Typisches Modell:

Hardware → Logik → UI

Nicht umgekehrt.

Beispiel Architektur

Hardware

def read_sensor():
    return 23.5

Logik

def process(value):
    return value * 1.1

UI

def update_ui(value):
    label.set_text(f"{value:.1f} °C")

Verbindung über Timer

def tick(t):
    raw = read_sensor()
    value = process(raw)
    update_ui(value)

lv.timer_create(tick, 500, None)

Warum Timer zentral ist

Der Timer ist die „Brücke“ zwischen:

• Hardware
• Logik
• UI

Er ersetzt keine Threads.

ESP32 / Pico Unterschiede

ESP32

• mehr RAM
• WLAN integriert
• gut für komplexe UI

Pico / RP2040

• stabil bei Echtzeit
• kein WLAN
• sehr deterministisch

MicroPython Einschränkungen

Achtung

MicroPython ist nicht echtzeitfähig.

Daher:

• keine langen Berechnungen im UI-Thread
• keine blockierenden Sensorzugriffe

Typische Fehler =

Achtung

• Sensorzugriff im Event-Handler
• lange while-Schleifen im UI
• globale Variablen ohne Struktur

Besseres Muster

Schlecht

def on_click(e):
    value = read_sensor()
    label.set_text(str(value))

Gut

latest_value = 0

def tick(t):
    global latest_value
    latest_value = read_sensor()

def update_ui(t):
    label.set_text(str(latest_value))

Vorteil dieser Trennung

• UI bleibt flüssig
• Sensoren blockieren nicht
• Code wird testbar
• Erweiterungen sind einfacher

Erweiterung: Zustandsmodell

Für größere Projekte:

• RUNNING
• STOPPED
• ERROR
• CONNECTED

Beispiel Zustand

state = "RUNNING"

def update_ui():
    if state == "RUNNING":
        label.set_text("Aktiv")
    elif state == "ERROR":
        label.set_text("Fehler")

Best Practice

Hinweis

Alles was Zeit kostet → in Timer oder Logik-Schicht

Alles was Darstellung ist → in UI-Schicht

Merke

Merke

Gute LVGL-Projekte sind streng in Schichten getrennt.

Zusammenfassung

• LVGL = UI-Schicht
• Hardware = Datenquelle
• Logik = Verarbeitung
• Timer verbindet alles
• keine direkten Hardware-Zugriffe im UI