Większość wymagań dotyczących interfejsu człowiek-maszyna (HMI) można technicznie spełnić za pomocą mikrokontrolera (MCU), kontrolera graficznego (GPU) albo mikroprocesora (MPU) z systemem Linux. To właśnie ta część jest pomijana w większości porównań. Prawdziwe pytanie nie brzmi „która architektura to potrafi” – chodzi o to, która pozwoli ci osiągnąć docelową wydajność przy najniższych całkowitych kosztach i najmniejszym ryzyku konieczności przeprojektowania po sześciu miesiącach. Jeśli podejmiesz złą decyzję, nie dowiesz się o tym podczas rozwoju. Dowiesz się o tym dopiero podczas walidacji, kiedy zmiana kursu oznacza przebudowę sprzętu i powtórzenie certyfikacji.
Krótka odpowiedź
Zanim się zdecydujesz, zwróć uwagę na te trzy sygnały:
- jak bardzo deterministyczny/działający w czasie rzeczywistym musi być twój interfejs,
- niezależnie od tego, czy rozbudowujesz istniejący produkt oparty na MCU,
- i czy już teraz potrzebne są rozwiązania sieciowe albo zaawansowane frameworki do tworzenia interfejsów użytkownika.
Jeśli żadna z tych opcji nie skłania cię ku GPU czy MPU, to zazwyczaj MCU jest bardziej efektywnym punktem wyjścia. Szczegóły i wyjątki znajdziesz poniżej.
MCU, GPU i MPU – krótkie porównanie
Jedyna różnica, która determinuje wszystko inne w tym artykule, polega na tym, który komponent odpowiada za renderowanie pikseli i w jakim stopniu musisz samodzielnie zarządzać systemem, żeby to osiągnąć.
MCU – mikrokontroler wykonuje renderowanie każdego pikselu (bufor ramki)
Mikrokontroler (MCU) obsługuje logikę aplikacji, komunikację i renderowanie interfejsu użytkownika na jednym układzie scalonym. Zazwyczaj oznacza to podejście oparte na buforze ramki: mikrokontroler oblicza i zapisuje każdy pojedynczy piksel na ekranie. Wraz ze wzrostem złożoności interfejsu użytkownika – więcej elementów, animacji, wyższa rozdzielczość – rośnie też obciążenie MCU, a tego nie da się w pełni naprawić później poprzez optymalizację. To strukturalne ograniczenie architektury, a nie błąd w twojej implementacji.
Typowa platforma: STM32 (szczegółowe informacje o poszczególnych rodzinach znajdziesz w sekcji poświęconej rozwiązaniom Riverdi).
GPU – MCU wysyła polecenia, a kontroler zajmuje się renderowaniem
W architekturze opartej na GPU mikrokontroler (MCU) nie zajmuje się już pikselami. Zamiast tego wysyła polecenia wysokiego poziomu – „narysuj przycisk”, „wyświetl obraz” – a dedykowany kontroler wyświetlacza (w przypadku Riverdi – z rodziny EVE firmy Bridgetek) zajmuje się faktycznym renderowaniem. To odciąża MCU od większości zadań graficznych, dlatego systemy oparte na GPU często określa się jako „ulepszony MCU”, a nie jako osobną kategorię: zachowujesz dotychczasową logikę aplikacji i filozofię sprzętową, po prostu przestajesz prosić MCU o rysowanie.
Typowa platforma: Bridgetek EVE (szczegółowe informacje o poszczególnych generacjach znajdziesz w sekcji poświęconej rozwiązaniom Riverdi).
MPU – pełny system operacyjny (Linux) i stos graficzny (Qt, web)
Jednostka mikroprocesorowa (MPU) obsługuje pełny system operacyjny, zazwyczaj Linuksa, a renderowanie odbywa się za pomocą kompletnego potoku graficznego – Qt, frameworków internetowych lub innych. Nie chodzi tu o „mocniejszy MCU”. To po prostu mały komputer. Nie zajmujesz się już pikselami ani nawet poleceniami rysowania; zarządzasz systemem operacyjnym, stosem sterowników i warstwą aplikacji, a wszystko to wymaga konfiguracji, zanim napiszesz choćby jedną linię kodu interfejsu użytkownika.
Typowa platforma: SoM/SBC obsługujące system Linux (konkretnych dostawców znajdziesz w sekcji poświęconej rozwiązaniom Riverdi).
Dlaczego tę decyzję trzeba podjąć jeszcze przed wyborem wyświetlacza
Co architektura określa raz na zawsze
Wybór architektury to nie tylko kwestia technicznych preferencji – to ograniczenie, w ramach którego funkcjonuje cała reszta projektu. To właśnie ona wyznacza górną granicę wydajności: system oparty na MCU już na samym początku ogranicza złożoność interfejsu użytkownika, rozdzielczość i możliwości animacji, zanim jeszcze napiszesz choćby jedną linię kodu, a tej granicy nie da się przesunąć nawet dzięki sprytnej optymalizacji w późniejszym etapie. Określa też harmonogram rozwoju i złożoność systemu – a to wiąże się z kosztami, głównie w postaci czasu inżynierów, a nie sprzętu.
Dlaczego zmiana w trakcie projektu wiąże się z koniecznością przeprojektowania sprzętu i ponownej walidacji
Cykl walidacji sprzętu i oprogramowania dla interfejsu HMI zazwyczaj przebiega następująco:
wymagania → wybór architektury → koncepcja interfejsu użytkownika → integracja sprzętu i wyświetlacza → prototypowanie i walidacja → iteracja → produkcja
Problemy rzadko pojawiają się na samym początku. Ujawniają się dopiero podczas walidacji – wydajność jest za mała, jakość obrazu nie spełnia oczekiwań albo okazuje się, że wymagania co do rozdzielczości są wyższe niż planowano. Jeśli architektura została dobrana prawidłowo, to po prostu kolejna iteracja. Jeśli nie, to trzeba wszystko przeprojektować: zmiana architektury w trakcie projektu zazwyczaj oznacza przepisanie oprogramowania, przeprojektowanie sprzętu i powtórzenie walidacji od zera. To zazwyczaj najdroższy rodzaj awarii w całym cyklu życia produktu. To też jedna z tych sytuacji, których najłatwiej uniknąć, bo wszystko rozstrzyga się już w pierwszym tygodniu.
W praktyce oznacza to, że warto wybrać architekturę pod kątem tego, czego produkt będzie potrzebował w ciągu najbliższych sześciu do dwunastu miesięcy, a nie tego, czego potrzebuje dzisiaj.
MCU vs GPU vs MPU – porównanie wydajności, złożoności, kosztów i zastosowań
Poniższa tabela przedstawia tendencje, a nie ostateczne wnioski. Dobrze zaprojektowany projekt oparty na MCU może okazać się bardziej opłacalny niż źle zaprojektowany projekt oparty na GPU; system oparty na GPU z nieodpowiednimi wymaganiami może po cichu stać się projektem opartym na MPU w przebraniu. Potraktuj to jako punkt wyjścia, a potem sprawdź to w oparciu o ramy decyzyjne z następnej sekcji.
| Czynnik | MCU | GPU | MPU |
| Renderowanie | Bufor ramki, renderowany na MCU | MCU wysyła polecenia wysokiego poziomu; kontroler zajmuje się renderowaniem | Pełny potok graficzny przez system operacyjny (Qt, frameworki internetowe) |
| Wydajność | Ograniczona; spada wraz ze wzrostem złożoności interfejsu użytkownika | Zoptymalizowane pod kątem typowych zadań związanych z interfejsem HMI/UI | Najwyższa – obsługuje wideo i zaawansowany, wielowarstwowy interfejs użytkownika |
| Złożoność | Prosty sprzęt, a złożoność oprogramowania rośnie w miarę zbliżania się do granicy wydajności | Prosty sprzęt, umiarkowana złożoność oprogramowania | Złożoność na poziomie systemu – pełny stos Linuksa do skonfigurowania i utrzymania |
| Koszt (sprzęt)* | Najniższy | Średni | Najwyższy |
| Ryzyko związane z przeprojektowaniem | Wysokie – sprzęt jest dostosowany do konkretnej aplikacji, co często wymaga całkowitej zmiany projektu, jeśli wymagania ulegną zmianie | Niższe – konstrukcja modułowa, co pozwala na częściowe przeprojektowanie | Niższe – konstrukcja modułowa, umożliwia częściowe przeprojektowanie |
| Czas tworzenia | Szybki w przypadku prostych interfejsów użytkownika, ale gwałtownie zwalnia, gdy zbliża się do granicy wydajności | Spójne i szybkie – ale wymaga opanowania sekwencji poleceń | Powolna konfiguracja początkowa (uruchomienie systemu), potem szybko się skaluje |
| Najlepszy przykład zastosowania | Systemy działające w czasie rzeczywistym, deterministyczne i wyposażone w dużą liczbę czujników | Dodanie nowoczesnego interfejsu użytkownika do istniejącego systemu opartego na MCU | Złożone, połączone systemy z zaawansowanym interfejsem użytkownika i funkcjami sieciowymi |
Uwaga dotycząca kosztów: sprzęt to najłatwiejsza pozycja do porównania różnych architektur, ale zazwyczaj nie to decyduje o całkowitym koszcie projektu. Czas pracy inżynierów i koszty związane z niewłaściwym wyborem architektury (ryzyko związane z koniecznością przeprojektowania) są trudniejsze do przewidzenia – a w praktyce to właśnie one częściej decydują o wyniku.
Kiedy każda architektura ma się jak najlepiej
- MCU to zazwyczaj oczywisty wybór do sterowania w czasie rzeczywistym i aplikacji opartych na czujnikach, gdzie deterministyczne zachowanie, szybkie uruchamianie i precyzyjna kontrola sprzętu są ważniejsze niż bogactwo interfejsu użytkownika – co często spotyka się w sprzęcie przemysłowym i medycznym.
- Systemy oparte na GPU sprawdzają się najlepiej, gdy masz już działający system oparty na MCU i chcesz dodać nowoczesny interfejs bez konieczności przeprojektowywania tego, co już działa. Zachowujesz dotychczasowe firmware i architekturę logiczną, a następnie podłączasz kontroler wyświetlacza – na przykład przez interfejs SPI – bez znaczącego zwiększania złożoności systemu. Jeden mikrokontroler może też sterować wieloma wyświetlaczami opartymi na procesorach graficznych, co ma znaczenie, jeśli standaryzujesz interfejs w kilku podpanelach.
- MPU to zazwyczaj jedyna architektura, która strukturalnie obsługuje sieci, złożone przetwarzanie danych czy zaawansowane frameworki interfejsów użytkownika, takie jak Qt, albo technologie internetowe. W takiej sytuacji rozwiązania oparte na MCU i GPU zazwyczaj tylko zwiększają koszty i złożoność, zamiast wyeliminować potrzebę stosowania MPU, a pozostaje już tylko zdecydować, która platforma MPU pozwoli ci osiągnąć cel w najbardziej efektywny sposób.
Gdzie każda architektura zawodzi
- MCU przestaje radzić sobie, gdy tylko złożoność interfejsu użytkownika przekroczy poziom, z którym podejście oparte na buforze ramki może sobie sprawnie poradzić – zaawansowana grafika, animacje czy wyższa rozdzielczość obniżają wydajność i utrudniają łatwość utrzymania systemu. Ograniczenia pamięci zazwyczaj ujawniają się dość wcześnie.
- Systemy oparte na GPU sprawdzają się w obsłudze interfejsu użytkownika, ale nie są przeznaczone do pełnienia zadań na poziomie systemowym. Traktowanie połączenia GPU i MCU jako zamiennika MPU – i oczekiwanie, że poradzi sobie z zaawansowanym przetwarzaniem, łącznością czy wszechstronnością – to częsty i kosztowny błąd w ocenie sytuacji.
- MPU rzadko zawodzi pod względem wydajności. Problem leży w złożoności: pełna konfiguracja systemu Linux, zestaw sterowników i długoterminowa konserwacja wymagają znacznie większej wiedzy specjalistycznej niż projekty oparte na MCU czy GPU, a początkowe uruchomienie systemu trwa zauważalnie dłużej.
Jak wybrać – prosta rama decyzyjna
Nie chodzi o to, „którą architekturę wolę” — chodzi o to, „czego faktycznie wymagają moje potrzeby”. W przypadku MPU ma to największe znaczenie: nie chodzi o to, „czy chcę mieć MPU”, tylko o to: „czy moje wymagania już wskazują, że jej potrzebuję”. Jeśli tak jest – na przykład w przypadku sieci, logiki aplikacji, aktualizacji OTA albo frameworków takich jak Qt czy stos webowy – to MPU zazwyczaj staje się jedyną architekturą, która jest w stanie to wszystko obsłużyć. MCU i GPU można dostosować do tych potrzeb, ale zazwyczaj wiąże się to z kosztami i złożonością, które przewyższają korzyści wynikające z rezygnacji z MPU. W tym momencie prawdziwą decyzją staje się wybór platformy MPU, modułu i poziomu integracji, które pozwolą ci osiągnąć cel przy najniższych kosztach i najmniejszym ryzyku.
Gdy MCU sam obsługuje interfejs MCU
Typowe sygnały: wymagane jest szybkie uruchamianie, zachowanie musi być deterministyczne, sterujesz czujnikami bezpośrednio, a niezawodność jest ważniejsza niż złożoność wizualna. W takich przypadkach MCU nie tylko się sprawdza – zazwyczaj jest to najbardziej efektywny wybór zarówno pod względem kosztów, jak i czasu rozwoju.
Dodanie nowoczesnego interfejsu użytkownika bez przeprojektowywania
Typowe sygnały: masz działający system, którego nie chcesz przeprojektowywać, chcesz pozostawić dotychczasowy mikrokontroler i firmware bez zmian, a potrzebujesz dodać wyświetlacz przy minimalnym nakładzie pracy związanym z integracją – często za pomocą jednej linii interfejsu (np. SPI). To też dobre rozwiązanie, gdy chcesz sterować kilkoma wyświetlaczami z jednego MCU.
Niech MPU wynika z wymagań, a nie z osobistych preferencji
Typowe sygnały: Twój system wymaga funkcji sieciowych, logiki aplikacji, aktualizacji bezprzewodowych albo frameworka interfejsu użytkownika, takiego jak Qt, albo stosu internetowego – innymi słowy, wyświetlacz jest tylko częścią większego, połączonego systemu, a nie jego głównym celem. Jeśli te wymagania już znajdują się na twojej liście, MPU nie jest „większym” rozwiązaniem, które warto rozważyć – to po prostu architektura, która strukturalnie je obsługuje, podczas gdy obejścia oparte na MCU czy procesorach graficznych (GPU) generują więcej kosztów i złożoności niż pozwalają zaoszczędzić.
Rozwiązania Riverdi dla każdej architektury
Riverdi nie opiera się na jednej architekturze – oferta platform odzwierciedla te trzy podejścia, więc zalecenie zależy od potrzeb danego projektu.
MCU – STM32 (U5, H7); trwają prace nad obsługą ESP32, Renesas, STM32N6 i NXP
Wbudowane wyświetlacze firmy Riverdi oparte na MCU wykorzystują układ STM32U5 w przypadku mniejszych rozmiarów wyświetlaczy oraz STM32H7 w przypadku większych – obie te zintegrowane platformy zostały zaprojektowane z myślą o aplikacjach działających w czasie rzeczywistym, skupionych na sterowaniu. Jeszcze w tym roku planowane jest wprowadzenie rozwiązań opartych na układach NXP, co pozwoli rozszerzyć tę linię produktów poza rodzinę STM32.
GPU – cała linia produktów Bridgetek EVE (EVE1–EVE5)
Riverdi obsługuje całą gamę kontrolerów Bridgetek EVE, od modelu EVE1 aż po niedawno wprowadzony na rynek EVE5. Są one powszechnie stosowane zarówno w wydajnych, specjalnie zaprojektowanych interfejsach HMI, jak i do modernizacji istniejących systemów opartych na MCU poprzez dodanie nowoczesnego interfejsu bez konieczności całkowitej przebudowy.
MPU – Toradex, SoMLabs, moduły obliczeniowe Raspberry Pi
W przypadku projektów opartych na procesorach MPU firma Riverdi współpracuje z Toradex, SoMLabs oraz modułami Raspberry Pi Compute Modules (CM4 i CM5), co pozwala tworzyć rozwiązania oparte na systemie Linux z zaawansowanym interfejsem użytkownika i możliwościami łączności.
Riverdi oferuje też wyświetlacze z interfejsem natywnym oraz rozwiązania typu „Plug and Play” (HDMI, USB-C) na wypadek, gdy wybór architektury zależy wyłącznie od klienta.
Podsumowanie
Wybór architektury w projekcie wbudowanego wyświetlacza nie polega na znalezieniu tej jednej „właściwej” opcji – chodzi o dopasowanie platformy do wymagań, które już teraz możesz określić z całą pewnością, bo koszt popełnienia błędu gwałtownie rośnie, gdy zacznie się walidacja. MCU, GPU i MPU dobrze radzą sobie z różnymi problemami; powyższy schemat ma pomóc ci zidentyfikować, z jakim problemem masz do czynienia, zanim sprzęt trafi do produkcji.
Większość z tych wymagań dałoby się technicznie narzucić na każdą z tych trzech architektur – w tym podejściu chodzi o to, która ścieżka pozwoli ci osiągnąć cel przy najniższych kosztach i najmniejszym ryzyku, a nie o to, która z nich jest „wymagana”.
FAQ
Czy muszę wybrać „idealną” architekturę, czy wystarczy taka, która jest po prostu wystarczająco dobra?
Żadne z nich do końca. MCU, GPU i MPU – każde z nich teoretycznie może spełnić większość wymagań na papierze – rzadko zdarza się, żeby istniała jedna „właściwa” odpowiedź, którą wystarczy znaleźć. Celem jest znalezienie rozwiązania, które pozwoli osiągnąć docelową wydajność przy najniższych kosztach i najmniejszym ryzyku konieczności przeprojektowania, biorąc pod uwagę potrzeby produktu w ciągu najbliższych 6–12 miesięcy. Dwa zespoły o tych samych wymaganiach mogą całkiem słusznie wybrać różne architektury, jeśli różnią się ich ograniczenia kosztowe, posiadany sprzęt lub poziom tolerancji ryzyka – i oba mogą mieć rację.
Czy MCU wystarczy do obsługi animowanego interfejsu?
To zależy od tego, jak dużo animacji i jakiej rozdzielczości potrzebujesz. Renderowanie z buforem ramki oparte na MCU radzi sobie z prostymi, lekkimi elementami interfejsu użytkownika, ale wydajność spada wraz ze wzrostem złożoności animacji i rozdzielczości – i to jest ograniczenie strukturalne, a nie coś, co da się później zoptymalizować. Jeśli animacja jest kluczowym wymaganiem, a nie tylko miłym dodatkiem, to zazwyczaj bardziej efektywnym punktem wyjścia jest GPU lub MPU.
Czy GPU to po prostu MPU z lżejszym systemem?
Nie. Kontroler wyświetlacza oparty na procesorze graficznym (GPU) odciąża mikrokontroler (MCU) od renderowania, ale nie obsługuje systemu operacyjnego ani nie zarządza zadaniami na poziomie systemowym. Działa to raczej jak ulepszony proces mikrokontrolera niż jak lekki procesor (MPU) – nie powinno się go używać jako zamiennika przetwarzania, łączności czy elastyczności na poziomie MPU.
Czy z jednego MCU można sterować wieloma wyświetlaczami opartymi na procesorach graficznych?
Tak. Ponieważ mikrokontroler wysyła polecenia rysowania na wysokim poziomie, zamiast sam renderować piksele, jeden mikrokontroler może sterować kilkoma wyświetlaczami opartymi na procesorach graficznych, co jest praktycznym rozwiązaniem przy ujednolicaniu interfejsu na wielu panelach w tym samym produkcie.
Na jakim etapie projektu faktycznie muszę już ustalić architekturę?
Zanim zacznie się praca nad koncepcją interfejsu użytkownika i integracja sprzętu – najlepiej zaraz po zdefiniowaniu wymagań. Decyzje dotyczące architektury wyznaczają górną granicę wydajności i złożoność systemu dla wszystkich kolejnych etapów, a po rozpoczęciu integracji i walidacji bardzo trudno to zmienić. Wybieraj na podstawie tego, czego produkt będzie potrzebował w ciągu najbliższych 6–12 miesięcy, a nie tylko na podstawie jego obecnego zakresu.
Czy mogę później przejść z jednej architektury na inną bez konieczności całkowitej przebudowy?
To zależy od tego, w którą stronę się przestawiasz. Sprzęt oparty na MCU jest ściśle dostosowany do konkretnej aplikacji, więc odejście od niego zazwyczaj oznacza całkowite przeprojektowanie sprzętu. Systemy oparte na procesorach graficznych (GPU) i procesorach wielozadaniowych (MPU) są bardziej modułowe i zazwyczaj pozwalają na częściowe przeprojektowanie zamiast całkowitej przebudowy – ale „częściowe” i tak oznacza realny nakład czasu inżynierów, a nie tylko zmianę konfiguracji.
Czy jest jakaś opcja, żeby stworzyć prototyp, nie decydując się jeszcze na konkretną architekturę?
Tak, w pewnym stopniu. Wyświetlacze z interfejsem natywnym i interfejsy typu „Plug and Play” (HDMI, USB-C) pozwalają przeprowadzić walidację koncepcji interfejsu użytkownika przed ostatecznym wyborem MCU, procesora graficznego czy procesora głównego. To rozwiązanie sprawdza się na wczesnym etapie prototypowania i walidacji koncepcji, ale nie eliminuje konieczności wyboru architektury przed integracją – po prostu odkłada tę decyzję o jedną fazę projektu.
Czy Riverdi promuje konkretną architekturę, czy raczej pomaga ocenić, która z nich będzie najlepsza?
Riverdi obsługuje wszystkie trzy rozwiązania – Wyświetlacze MCU oparte na STM32, pełną linię produktów Bridgetek EVE dla procesorów graficznych (GPU) oraz platformy MPU z obsługą systemu Linux, takie jak Toradex i moduły komputerowe Raspberry Pi. Wybór odpowiedniego rozwiązania zależy od wymagań projektu dotyczących wydajności, kosztów i złożoności.
Wciąż nie wiesz, która architektura będzie odpowiednia? To normalne – odpowiedź zazwyczaj zależy od ograniczeń, które stają się oczywiste dopiero wtedy, gdy porównasz je ze sobą. Powiedz nam, jakie wymagania musi spełniać produkt: wydajność, łączność, środowisko, harmonogram. Pokażemy ci, która z tych trzech opcji będzie najlepsza i na czym polegają kompromisy. Porozmawiaj z naszymi inżynierami.
ODKRYJ NASZĄ
Whitepaper
Osiągnij idealną interakcję użytkownika z wyświetlaczem dzięki odpowiedniemu czujnikowi Touch Sensor IC. Czy kiedykolwiek zmagałeś się z problemami związanymi z fantomowymi dotknięciami lub certyfikacją? Rozwiń swoje prace B+R jak profesjonalista dzięki naszemu Whitepaperowi!
Przejdź do naszego katalogu produktów i zobacz, jak możesz oszczędzać dzięki jakości, nie na jakości.
