Narzędzia i podejścia do tworzenia graficznych interfejsów użytkownika w systemach wbudowanych

Spis treści

Wprowadzenie

Wbudowany graficzny interfejs użytkownika często postrzega się po prostu jako „grafikę na wyświetlaczu”. W praktyce to jednak znacznie więcej. Wbudowany GUI to połączenie architektury oprogramowania, strategii renderowania, obsługi wejścia oraz możliwości sprzętowych, które wspólnie działają, by przedstawiać informacje i przyjmować interakcje użytkownika w niezawodny i przewidywalny sposób.

W przeciwieństwie do aplikacji stacjonarnych czy mobilnych, wbudowane interfejsy graficzne działają w ramach ścisłych ograniczeń. Ograniczona wydajność procesora, ograniczona pamięć, wymagania dotyczące pracy w czasie rzeczywistym oraz długi cykl życia produktu – to wszystko wpływa na to, jak projektuje się i wdraża interfejs użytkownika. W rezultacie rozwiązania w zakresie wbudowanych interfejsów graficznych obejmują zarówno lekkie interfejsy działające na małych mikrokontrolerach, jak i zaawansowane aplikacje graficzne działające na systemach opartych na Linuksie.

Z powodu tej różnorodności termin „wbudowany interfejs graficzny” nie odnosi się do jednej konkretnej technologii ani procesu. Obejmuje on raczej szerokie spektrum rozwiązań, które różnią się między sobą tym, gdzie odbywa się renderowanie, jak ściśle interfejs graficzny jest powiązany z platformą sprzętową oraz jak dużą elastyczność zapewniają one pod kątem przyszłego rozwoju systemu.

Trzy praktyczne kategorie wbudowanych rozwiązań GUI

Z perspektywy systemowej większość rozwiązań w zakresie wbudowanych interfejsów GUI można podzielić na trzy praktyczne kategorie. Ta klasyfikacja nie opiera się na konkretnych produktach ani dostawcach, ale na tym, jak interfejs GUI jest zintegrowany z ogólną architekturą systemu.

1. GUI powiązane z jednym ekosystemem sprzętowym

W tej kategorii framework GUI i narzędzia są zaprojektowane specjalnie pod kątem jednej rodziny procesorów lub jednego producenta układów scalonych. Interfejs użytkownika staje się naturalnym przedłużeniem ekosystemu sprzętowego, z ściśle zintegrowanymi narzędziami i zalecanymi procedurami pracy.

2. Wieloplatformowe frameworki i biblioteki GUI

W tym przypadku framework GUI jest w dużej mierze niezależny od sprzętu, na którym działa. Ten sam kod interfejsu użytkownika można wykorzystać na różnych mikrokontrolerach lub procesorach, o ile dostępne są odpowiednie sterowniki wyświetlacza i urządzeń wejściowych.

3. GUI z renderowaniem przeniesionym na zewnętrzne kontrolery graficzne

W tym podejściu główny procesor nie renderuje interfejsu graficznego bezpośrednio. Zamiast tego renderowaniem zajmuje się dedykowany zewnętrzny kontroler graficzny, podczas gdy główny procesor skupia się na logice aplikacji i sterowaniu systemem.

Ten model oparty na trzech kategoriach to jasny i praktyczny sposób na zrozumienie świata wbudowanych GUI. Ułatwia też określenie miejsca poszczególnych narzędzi i frameworków w oparciu o wybory architektoniczne, a nie tylko listy kontrolne.

W kolejnych sekcjach każda kategoria została opisana bardziej szczegółowo, wraz z konkretnymi przykładami pokazującymi, jak te podejścia są wykorzystywane w prawdziwych systemach wbudowanych.

GUI powiązana z jednym ekosystemem sprzętowym

W tej kategorii graficzny interfejs użytkownika jest ściśle powiązany z konkretną platformą sprzętową lub producentem układów. Framework GUI, narzędzia programistyczne i zalecane procesy pracy są zaprojektowane tak, by współdziałać jako część jednego spójnego ekosystemu.

Takie podejście zazwyczaj zapewnia wysoki poziom integracji między GUI a sprzętem. Sterowniki wyświetlaczy, kontrolery dotyku, akceleracja grafiki i wykorzystanie pamięci są dostosowane do możliwości konkretnej rodziny MCU lub SoC. Dzięki temu krzywa uczenia często przebiega płynniej, zwłaszcza dla zespołów, które znają już środowisko programistyczne danego dostawcy.

Rozwiązania GUI z tej kategorii są zazwyczaj wybierane do projektów, w których:

• platforma sprzętowa jest ustalana na wczesnym etapie projektowania,
• oczekuje się długoterminowego wsparcia w ramach jednego ekosystemu,
• Ważne są tempo rozwoju i spójność toolchain.

Zamiast skupiać się na przenośności między platformami, rozwiązania te kładą nacisk na ścisłe powiązania i optymalizację w ramach jednego środowiska.

TouchGFX dla STM32

TouchGFX to framework graficznego interfejsu użytkownika stworzony specjalnie dla mikrokontrolerów STM32. Jest ściśle zintegrowany z ekosystemem STM32 i stanowi naturalne rozszerzenie procesu programowania firmy ST.

Z punktu widzenia programisty TouchGFX łączy wizualne narzędzie do projektowania interfejsu użytkownika z frameworkiem C++ zoptymalizowanym pod kątem sprzętu STM32. Ekrany interfejsu, animacje i interakcje tworzy się w edytorze, a logika aplikacji i konfiguracja sprzętu są obsługiwane przez STM32CubeMX i powiązane narzędzia programistyczne.

Ta ścisła integracja pozwala projektować GUI z pełną świadomością dostępnych zasobów MCU, interfejsów wyświetlacza i funkcji akceleracji grafiki.

Typowe cechy

• Framework GUI zaprojektowany specjalnie dla STM32
• Projektant graficznego interfejsu użytkownika w połączeniu z kodem w języku C++ dla systemów wbudowanych
• Proces pracy dostosowany do narzędzi STM32Cube

TouchGFX – narzędzie do wyboru płytki

Jeśli chcesz dowiedzieć się więcej o TouchGFX, więcej informacji znajdziesz na stronie internetowej firmy ST.

NXP GUI Guider

NXP GUI Guider to nieco inne podejście, ale wciąż skupione na konkretnym dostawcy. Chociaż wykorzystuje LVGL jako podstawową bibliotekę graficzną, ogólny przebieg pracy pozostaje mocno powiązany z ekosystemem NXP.

GUI Guider oferuje interfejs typu „przeciągnij i upuść” do tworzenia ekranów i definiowania zachowania interfejsu użytkownika. Narzędzie generuje kod źródłowy oparty na LVGL, który jest następnie integrowany i kompilowany w środowisku MCUXpresso SDK. Z punktu widzenia użytkownika interfejs graficzny jest tworzony i zarządzany w ramach jednego zestawu narzędzi dostarczonego przez producenta.

Chociaż sam LVGL jest wieloplatformowy, sposób, w jaki go tu wykorzystujemy, odzwierciedla proces pracy specyficzny dla danej platformy, zoptymalizowany pod kątem mikrokontrolerów NXP i zalecanego przez nich stosu programowego.

Typowe cechy

• Tworzenie graficznego interfejsu użytkownika za pomocą narzędzia dostarczonego przez dostawcę
• Jako silnik do renderowania wykorzystano LVGL
• Ścisła integracja z pakietem MCUXpresso SDK i platformami NXP

NXP GUI Guider – Okno nowego projektu

Więcej informacji o NXP GUI Guider znajdziesz na stronie internetowej NXP.

Inne podejścia specyficzne dla poszczególnych dostawców

Podobne rozwiązania można spotkać w całej branży systemów wbudowanych. Wielu producentów układów oferuje narzędzia GUI lub frameworki, które są zaprojektowane tak, by najlepiej działać w ramach ich własnych ekosystemów sprzętowych i programowych.

Chociaż konkretne narzędzia się różnią, ogólna idea pozostaje ta sama:

• GUI jest traktowany jako integralna część platformy sprzętowej,
• narzędzia i przykłady są dostosowane do konkretnej rodziny MCU lub SoC,
• optymalizacja i łatwość obsługi w jednym środowisku mają pierwszeństwo przed przenośnością.

Ta kategoria wciąż stanowi świetny wybór dla projektów, w których ujednolicenie rozwiązań jednego dostawcy ułatwia tworzenie oprogramowania i długoterminową konserwację.

Frameworky wieloplatformowe i biblioteki do tworzenia GUI

Framework wieloplatformowy GUI działa inaczej niż rozwiązania specyficzne dla konkretnych dostawców. Zamiast być ściśle powiązane z jednym ekosystemem sprzętowym, jest zaprojektowany tak, by działać na wielu platformach przy minimalnych zmianach w kodzie interfejsu użytkownika lub bez nich.

W tym modelu GUI staje się odrębną warstwą programową, która znajduje się powyżej abstrakcji sprzętowej. Jeśli tylko zapewnione są odpowiednie sterowniki wyświetlacza, urządzeń wejściowych i synchronizacji, tę samą platformę można wykorzystywać na różnych mikrokontrolerach, procesorach, systemach operacyjnych, a nawet w różnych generacjach produktów.

Tę kategorię zazwyczaj wybiera się, gdy:

• platformy sprzętowe mogą się z czasem zmieniać,
• wiele wariantów produktu ma ten sam interfejs użytkownika,
• Długoterminowa łatwość utrzymania i przenoszenia to ważne cele projektowe.

Zamiast dostosowywać się do jednego konkretnego MCU, frameworki wieloplatformowe stawiają na spójność i możliwość ponownego wykorzystania kodu w różnych środowiskach.

LVGL jako wieloplatformowy framework GUI dla systemów wbudowanych

LVGL to jeden z najczęściej używanych wieloplatformowych frameworków GUI w świecie systemów wbudowanych. Został zaprojektowany tak, by działać na szerokiej gamie systemów – od małych mikrokontrolerów o ograniczonych zasobach po platformy oparte na procesorach MPU z systemem Linux.

Z architektonicznego punktu widzenia LVGL zapewnia:

• ujednolicony model obiektowy dla ekranów, widżetów i stylów,
• elastyczny potok wyświetlania, który można dostosować do różnych sterowników karty graficznej,
• obsługa zarówno systemów typu „bare-metal”, jak i tych opartych na systemie operacyjnym.

Ponieważ LVGL nie jest uzależniony od żadnego konkretnego producenta układów krzemowych, pozwala zespołom programistycznym zachować tę samą logikę GUI przy zmianie platformy sprzętowej. To sprawia, że jest szczególnie atrakcyjny dla produktów, które z czasem ewoluują lub występują w wielu konfiguracjach sprzętowych.

Typowe cechy

• Jednolity framework GUI dla systemów z MCU i procesorami
• Przenośny kod napisany w języku C
• Szeroki wybór obsługiwanych wyświetlaczy, kontrolerów dotyku i platform

Jeśli chcesz dowiedzieć się więcej, przeczytaj artykuł „Pierwsze kroki z LVGL” lub zajrzyj do dokumentacji na stronie docs.lvgl.io

Qt i Qt Quick w systemach wbudowanych

Qt to zaawansowane podejście do tworzenia wbudowanych interfejsów GUI i najczęściej wykorzystuje się je w systemach opartych na procesorach MPU z systemem Linux. W tym środowisku interfejs użytkownika traktuje się jako pełnoprawną warstwę aplikacji, a nie jako proste rozszerzenie firmware.

Sercem nowoczesnych wbudowanych GUI opartych na Qt jest Qt Quick – framework zbudowany w oparciu o QML, czyli deklaratywny język służący do opisywania interfejsów użytkownika. Qt Quick oddziela strukturę wizualną, animacje i logikę interakcji od kodu aplikacji, dzięki czemu interfejs użytkownika może ewoluować niezależnie od funkcjonalności systemu.

Takie podejście pozwala na:

• elastyczne układy i dynamiczne skalowanie w zależności od rozmiaru wyświetlacza,
• płynne animacje i przejścia,
• renderowanie z przyspieszeniem sprzętowym z wykorzystaniem nowoczesnych potoków graficznych,
• wyraźne rozdzielenie projektowania interfejsu użytkownika od logiki aplikacji.

Qt Quick jest więc główną technologią odpowiedzialną za to, co jest renderowane na ekranie we współczesnych systemach wbudowanych opartych na Qt.

Tworzenie graficznego interfejsu użytkownika za pomocą Qt Design Studio

Istotną częścią procesu tworzenia GUI w Qt Embedded jest Qt Design Studio, które służy jako główne narzędzie do wizualnego projektowania GUI i prototypowania.

Qt Design Studio pozwala projektantom i programistom tworzyć interfejsy użytkownika w sposób wizualny, definiować animacje i stany oraz przeglądać interakcje bez konieczności zagłębiania się w niski poziom kodu aplikacji. Narzędzie to generuje zasoby QML, które można bezpośrednio zintegrować z aplikacją wbudowaną.

Jeśli chodzi o proces pracy, Qt Design Studio pozwala na:

• układ graficzny ekranów i elementów,
• projektowanie animacji oparte na osi czasu,
• szybkie wprowadzanie zmian w wyglądzie i stylu,
• ścisła współpraca między zespołami projektowymi i programistycznymi.

Qt Design Studio

W projektach wbudowanych Qt Design Studio pełni rolę podobną do specyficznych dla poszczególnych producentów narzędzi do projektowania GUI, które można znaleźć w ekosystemach MCU, ale jest dostosowane do potrzeb systemów klasy Linux z bardziej zaawansowanymi możliwościami graficznymi. Więcej szczegółów na temat tego środowiska znajdziesz na stronie Qt.

Kontekst integracji i wdrożenia

Aplikacje wbudowane oparte na Qt są zazwyczaj tworzone i integrowane za pomocą Qt Creatora, który pełni rolę głównego środowiska IDE do zarządzania plikami QML, kodem C++ oraz konfiguracjami kompilacji. Chociaż sam Qt Creator nie jest narzędziem do projektowania interfejsów GUI, zapewnia środowisko, w którym elementy interfejsu użytkownika utworzone w Qt Design Studio są łączone z logiką aplikacji.

W komercyjnych produktach wbudowanych Qt jest często dostarczane za pomocą Qt for Device Creation, które zapewnia obsługiwane środowisko uruchomieniowe, toolchain oraz infrastrukturę aktualizacji dla urządzeń z systemem Linux embedded. Takie rozwiązanie upraszcza wdrożenie i długoterminową konserwację, ale nie wpływa bezpośrednio na sposób projektowania GUI.

Kiedy Qt to dobry wybór

Interfejsy graficzne oparte na Qt są często wybierane, gdy:

• architektura systemu obejmuje już procesor MPU i system Linux,
• interfejs użytkownika to kluczowy element wrażeń związanych z produktem,
• potrzebne są nowoczesne wzorce interakcji i bogata oprawa wizualna,
• Projektowanie i tworzenie oprogramowania przebiegają równolegle.

Chociaż Qt wymaga wydajniejszego sprzętu niż frameworki przeznaczone dla MCU, połączenie Qt Quick i Qt Design Studio zapewnia dojrzałe i skalowalne środowisko do tworzenia zaawansowanych wbudowanych interfejsów użytkownika.

Inne technologie przenośnych GUI

Oprócz LVGL i Qt w projektach wbudowanych stosuje się też inne przenośne rozwiązania, w zależności od wymagań systemu i wiedzy zespołu.

Oto niektóre z nich:

• interfejsy użytkownika oparte na sieci WWW, stworzone przy użyciu HTML, CSS i JavaScript oraz wyświetlane za pomocą wbudowanej przeglądarki,
• inne otwarte lub starsze biblioteki GUI używane w produktach o długim cyklu życia,
• frameworki na zamówienie stworzone z myślą o spełnieniu bardzo konkretnych wymagań.

Chociaż rozwiązania te różnią się pod względem implementacji, łączy je ta sama zasada:
interfejs graficzny (GUI) jest traktowany jako warstwa niezależna od platformy, a szczegóły związane ze sprzętem są ukryte na niższym poziomie.

GUI z renderowaniem przeniesionym na zewnętrzne kontrolery graficzne

Trzecia kategoria wbudowanych rozwiązań GUI opiera się na innym założeniu architektonicznym niż zarówno frameworki specyficzne dla danego dostawcy, jak i frameworki wieloplatformowe. W tym podejściu renderowanie grafiki nie odbywa się w głównym MCU ani procesorze (MPU), ale jest przekazywane do dedykowanego, zewnętrznego kontrolera graficznego.

Główny procesor komunikuje się z kontrolerem graficznym za pomocą poleceń wysokopoziomowych, a sam kontroler odpowiada za generowanie obrazu na wyświetlaczu i obsługę wejścia dotykowego. Dzięki temu logika aplikacji jest oddzielona od części prezentacyjnej i nie trzeba utrzymywać bufora ramki w głównej pamięci systemowej.

Takie architektury wybiera się zazwyczaj, gdy:

• Zasoby procesora MCU są ograniczone lub zarezerwowane dla zadań wykonywanych w czasie rzeczywistym,
• wymagane jest przewidywalne i deterministyczne zachowanie podczas renderowania,
• trzeba ściśle kontrolować złożoność systemu.

Zamiast przeprowadzać skalowanie wydajności poprzez podnoszenie mocy obliczeniowej procesora czy pamięci, ta kategoria opiera się na sprzętowym odciążaniu obciążenia graficznego.

Interfejsy HMI firmy Bridgetek oparte na platformie EVE

Seria EVE firmy Bridgetek to typowy przykład takiego podejścia. Urządzenia EVE działają jako dedykowane kontrolery wyświetlacza, graficznego i ekranu dotykowego, obsługując wewnętrznie renderowanie, synchronizację wyświetlania oraz przetwarzanie dotyków.

W systemie opartym na EVE:

• MCU hosta wysyła polecenia rysowania i sterowania,
• Kontroler EVE tworzy i wykonuje display list,
• dane dotykowe są przetwarzane bezpośrednio przez urządzenie EVE,
• Ostateczny sygnał wideo jest generowany bezpośrednio przez kontroler EVE.

Ta architektura pozwala nawet stosunkowo niewielkim mikrokontrolerom obsługiwać złożone interfejsy graficzne i reagować na działania użytkownika bez konieczności zarządzania buforami pikseli, wdrażania algorytmów dotykowych czy wykonywania operacji renderowania w czasie rzeczywistym.

Do typowych cech interfejsów człowiek-maszyna (HMI) opartych na technologii EVE należą:

• brak bufora ramki w pamięci MCU,
• wbudowana obsługa dotykowa (dotyk rezystancyjny lub pojemnościowy, w zależności od wersji EVE),
• stała wydajność renderowania niezależna od obciążenia aplikacji,
• wyraźne rozdzielenie między wyglądem interfejsu użytkownika, przetwarzaniem dotykowym a logiką aplikacji.

Dzięki temu EVE świetnie sprawdza się w klasycznych przemysłowych interfejsach HMI, panelach sterowania i urządzeniach, w których kluczowe znaczenie mają niezawodna obsługa dotykowa, deterministyczne działanie i prostota systemu.

EVE Screen Designer jako kluczowy element procesu pracy w EVE

Kluczowym elementem ekosystemu Bridgetek EVE jest narzędzie EVE Screen Designer (ESE), które odgrywa kluczową rolę w tworzeniu interfejsów użytkownika opartych na platformie EVE.

EVE Screen Designer to wizualne, niezależne od sprzętu narzędzie służące do projektowania kompletnych ekranów interfejsu użytkownika i interakcji bez konieczności dostępu do docelowego sprzętu. Ekrany tworzy się za pomocą elementów graficznych i widżetów, które są bezpośrednio powiązane z poleceniami display list EVE.

Z punktu widzenia procesu tworzenia aplikacji EVE Screen Designer pozwala na:

• kompozycja wizualna ekranów interfejsu użytkownika i przebieg nawigacji,
• określenie interakcji dotykowych i zachowania ekranu,
• podgląd i walidacja logiki interfejsu użytkownika przed wdrożeniem firmware’u,
• tworzenie elementów interfejsu użytkownika, które są potem sterowane przez kod aplikacji.

Ponieważ ESE odzwierciedla podstawowy model renderowania EVE, deweloperzy działają w ramach jasno określonych ograniczeń, co pomaga zapewnić przewidywalną wydajność i pozwala uniknąć problemów z optymalizacją na późnych etapach.

EVE Screen Designer

LVGL działające na EVE – podejście hybrydowe

Ciekawym rozszerzeniem koncepcji EVE jest projekt referencyjny, znany powszechnie jako „LVGL działający na EVE”. W tym podejściu hybrydowym LVGL służy jako framework GUI wysokiego poziomu, a za rzeczywiste renderowanie odpowiada kontroler EVE.

Koncepcję tę można zobaczyć w publicznym repozytorium referencyjnym, gdzie LVGL zostało dostosowane do współpracy z urządzeniami Bridgetek EVE.

Z architektonicznego punktu widzenia:

• LVGL oferuje przenośny i znany model interfejsu użytkownika,
• EVE pełni rolę silnika do renderowania i interfejsu dla wyświetlacza,
• MCU hosta koordynuje logikę aplikacji i aktualizacje interfejsu użytkownika.

Ten model hybrydowy pokazuje, że trzy kategorie GUI opisane w tym artykule to nie sztywne granice, tylko elementy bazowe architektury, które można łączyć, gdy wymagają tego potrzeby projektu.

Jedna platforma wyświetlacza, różne podejścia do GUI

Jeśli chodzi o wyświetlacz, opisane dotychczas różnice architektoniczne niekoniecznie wymagają innego wyświetlacza.

Tę samą fizyczną platformę wyświetlacza można wykorzystać z:

• rozwiązania GUI oparte na MCU poszczególnych producentów,
• framework wieloplatformowy działający na mikrokontrolerach (MCU) lub procesorach (MPU),
• systemy z zewnętrznymi kontrolerami graficznymi,
• Platformy oparte na systemie Linux z interfejsami użytkownika Qt lub internetowymi.

O ile interfejs wyświetlacza i parametry elektryczne są zgodne, wybór technologii GUI pozostaje decyzją na poziomie systemu, a nie ograniczeniem wynikającym z wyświetlacza.

Ta elastyczność jest szczególnie cenna w przypadku produktów o długim cyklu życia oraz rodzin produktów, które z czasem ulegają zmianom.

Jak Riverdi wpisuje się w ten krajobraz

Riverdi skupia się na dostarczaniu Display Solutions, które płynnie integrują się z szeroką gamą architektur systemów wbudowanych.

Zamiast ograniczać się do jednego frameworka GUI czy jednej metody renderowania, wyświetlacze Riverdi zostały zaprojektowane tak, by obsługiwać:

• Systemy oparte na MCU, wykorzystujące frameworki GUI specyficzne dla danego producenta lub wieloplatformowe,
• Architektury oparte na EVE z odciążonym renderowaniem,
• Platformy oparte na MPU i Linuksie, wykorzystujące Qt lub technologie internetowe.

Dzięki temu zespoły programistyczne mogą wybierać lub zmieniać podejście do GUI, zachowując jednocześnie spójność platformy wyświetlacza w różnych projektach i generacjach produktów.

Wniosek – wybór architektury, a nie ograniczenie

Tworzenie wbudowanych interfejsów GUI nie sprowadza się do jednego narzędzia czy frameworka, ale do zestawu wyborów architektonicznych, które zapewniają równowagę między wydajnością, złożonością i długoterminową elastycznością.

Rozwiązania od konkretnych dostawców zapewniają ścisłą integrację i szybkie wdrożenie.
Framework wieloplatformowy zapewnia przenośność i możliwość ponownego wykorzystania.
Zewnętrzne kontrolery graficzne oferują przewidywalną wydajność przy minimalnym obciążeniu MCU.

Dzięki dobrze dobranej platformie wyświetlacza te podejścia mogą współistnieć i ewoluować z czasem, pozwalając zespołom skupić się na architekturze systemu i doświadczeniu użytkownika, a nie na ograniczeniach technicznych.