Czy jeden wbudowany wyświetlacz może jednocześnie sterować innym?
W tym poradniku pokażemy, jak pojedynczy układ STM32H7 wbudowany w wyświetlacz Riverdi może jednocześnie:
- wyświetla własną GUI za pomocą TouchGFX oraz
- sterować drugim wyświetlaczem opartym na EVE4 przez RiBUS (SPI).
W rezultacie powstał przejrzysty i powtarzalny szablon dla systemów z dwoma wyświetlaczami, takich jak terminale POS, kioski i przemysłowe panele HMI.
Ten przykład jest celowo uproszczony. Skupia się na:
- prawidłowa kolejność inicjalizacji,
- jasny podział obowiązków,
- wspólny stan aplikacji, z którego korzystają dwie niezależne ścieżki renderowania.
Struktura ta została zaprojektowana jako praktyczna podstawa, którą można stopniowo rozbudowywać w ramach rzeczywistych projektów.
Przegląd sprzętu
Programowanie i debugowanie
- ST-LINK/V3 podłączony przez SWD do układu STM32H7 wbudowanego w wyświetlacz Riverdi
- Programowany jest tylko układ STM32H7
- Wyświetlacz EVE4 nigdy nie jest odświeżany i komunikuje się wyłącznie przez interfejs SPI
(RiBUS)
STM32 + EVE4 – Blog
Wyświetlacze
Wbudowany wyświetlacz Riverdi STM32 (urządzenie nadrzędne)
7-calowy wyświetlacz z wbudowanym układem STM32H7, obsługiwany przez TouchGFX.
Wyświetlacz Riverdi EVE4 (urządzenie podrzędne)
7-calowy wyświetlacz oparty na platformie EVE4, sterowany przez STM32H7 za pośrednictwem RiBUS.
Interfejsy
- SWD – programowanie i debugowanie
- SPI (RiBUS) – STM32H7 → interfejs poleceń EVE4
- Interfejsy dotykowe na obu wyświetlaczach
Stos programowy
Rozwój
- STM32CubeIDE
- HAL dla STM32
- FreeRTOS
Grafika i interfejs użytkownika
- TouchGFX – GUI oparte na buforze ramki na wbudowanym wyświetlaczu STM32H7
- EVE4 (BT81x) – renderowanie oparte na poleceniach za pomocą display list przez interfejs SPI
Warstwa aplikacji
- Jednolita logika aplikacji na STM32H7
- Oddzielne konteksty wykonania (zadania FreeRTOS)
- Wspólny stan aplikacji służący do synchronizacji obu wyświetlaczy
Koncepcja architektury — jedna logika, dwa moduły do renderowania
Główną zasadą architektury jest rozdzielenie logiki od renderowania.
- STM32H7 zarządza stanem aplikacji
- TouchGFX i EVE4 to niezależne silniki do renderowania
- Oba wyświetlacze reagują na ten sam wspólny stan
Model renderowania
TouchGFX
- Renderowanie oparte na buforze ramki
- Wszystko obsługuje STM32H7
EVE4
- Renderowanie oparte na poleceniach z wykorzystaniem display list
- Renderowanie wykonane przez procesor graficzny EVE
Chodzi nie o to, żeby porównywać te podejścia, tylko żeby pokazać, że oba mogą bez problemu współistnieć w jednym systemie sterowanym przez jeden mikrokontroler.
Scenariusz demonstracyjny – wspólny stan i dwukierunkowa interakcja
Ten przykład pokazuje niewielki wspólny stan aplikacji, który jest wymieniany między dwoma niezależnymi interfejsami użytkownika.
- Wyświetlacz TouchGFX (urządzenie nadrzędne) proponuje zmiany.
- Wyświetlacz EVE4 (urządzenie podrzędne) je potwierdza albo odrzuca.
Interakcja dotykowa na jednym wyświetlaczu bezpośrednio wpływa na działanie drugiego.
Wspólny stan aplikacji
typedef struct {
uint8_t master_proposedColor;
uint8_t master_requestPending;
uint8_t slave_currentColor;
uint8_t slave_lastResponse;
uint8_t slave_responseDirty;
} app_state_t;
volatile app_state_t gAppState = {
.master_proposedColor = COLOR_RED,
.master_requestPending = 0,
.slave_currentColor = COLOR_RED,
.slave_lastResponse = SLAVE_IDLE,
.slave_responseDirty = 0
};
Stan jest inicjowany w sposób deterministyczny, więc oba wyświetlacze zaczynają działać zsynchronizowane.Od tego momentu:
- TouchGFX aktualizuje zmienną ` master_proposedColor ` i ustawia ` master_requestPending`.
- EVE4 akceptuje lub odrzuca żądanie oraz aktualizuje zmienne ` slave_currentColor ` i ` slave_lastResponse`.
Obie ścieżki renderowania na bieżąco odczytują stan gAppState i odpowiednio aktualizują swój interfejs użytkownika.
Dzięki temu przebieg interakcji jest przejrzysty, łatwy do śledzenia i w pełni oparty na wspólnej logice aplikacji typu „
”, a nie na bezpośredniej komunikacji między wyświetlaczami.
Ten model interakcji jest celowo prosty i stanowi przejrzysty wzór dla prawdziwych projektów typu „
”, w których dwa wyświetlacze muszą ze sobą współpracować, pozostając jednocześnie niezależnymi pod względem architektury.
Kolejność inicjalizacji
Tutaj pokazano tylko prawidłową sekwencję.
- Inicjalizacja MCU i zegary
HAL_Init() → SystemClock_Config() → PeriphCommonClock_Config() - Inicjalizacja urządzeń peryferyjnych
GPIO, LTDC/DSI, DMA2D/MDMA, SPI, timery, pamięć zewnętrzna (SDRAM/QSPI) - Inicjalizacja TouchGFX
MX_TouchGFX_Init() → MX_TouchGFX_PreOSInit() - Inicjalizacja SPI dla RiBUS
MX_SPI1_Init() (lub wybrana instancja) - Inicjalizacja EVE4
EVE4_RiBUS_Init(&eve)
EVE4_RiBUS_ConfigIPS70(&eve) - Uruchom FreeRTOS
osKernelInitialize() → MX_FREERTOS_Init() → osKernelStart()
Postępowanie zgodnie z tą sekwencją pozwala uniknąć subtelnych problemów przy uruchamianiu i gwarantuje, że obie ścieżki renderowania zostaną poprawnie zainicjowane. TouchGFX uruchamia się z w pełni skonfigurowanym potokiem wyświetlania, a EVE4 jest gotowy do renderowania, gdy tylko zadanie FreeRTOS zacznie działać.
Struktura projektu
W tym projekcie interfejs użytkownika TouchGFX i integracja z EVE4 są wyraźnie oddzielone.
- CM7/Core/
Uruchamianie MCU i inicjalizacja urządzeń peryferyjnych (main.c, *_init.c)
Konfiguracja systemu i uruchomienie płytki - CM7/TouchGFX/
– aplikacja TouchGFX (ekrany, widżety, zasoby)
– główna logika interfejsu użytkownika (wyświetlacz główny)
- Application/User/Core/
app_state.c / app_state.h – wspólny stan aplikacji dla urządzeń nadrzędnych i podrzędnych (gAppState)
eve4_ribus.c / eve4_ribus.h – sterownik niskopoziomowy EVE4 (SPI + dostęp do rejestrów + funkcje pomocnicze display list)
eve_task.c – zadanie EVE w systemie FreeRTOS (pętla renderowania + obsługa dotykowa na wyświetlaczu urządzenia podrzędnego) - Application/User/gui/ (warstwa użytkownika TouchGFX)
np. Screen1View.cpp/.hpp – główna logika interfejsu użytkownika (proponowanie koloru, odzwierciedlanie stanu urządzenia podrzędnego)
Model czasu wykonania (TouchGFX + zadanie EVE)
Aplikacja działa pod kontrolą systemu FreeRTOS i korzysta z dwóch niezależnych kontekstów wykonawczych:
Zadanie TouchGFX (wyświetlacz główny)
Odpowiada za renderowanie głównego interfejsu użytkownika oraz obsługę interakcji dotykowych na wyświetlaczu opartym na mikrokontrolerze STM32.
Działania użytkownika aktualizują stan współdzielony (gAppState).
Zadanie EVE (wyświetlacz urządzenia podrzędnego)
Tworzy i zamienia display lists EVE oraz przeprowadza przetwarzanie danych dotykowych na wyświetlaczu EVE4. Decyzje (akceptacja/odrzucenie) aktualizują stan gAppState i są odzwierciedlane w głównym interfejsie użytkownika. Obie ścieżki renderowania reagują na ten sam, wspólny stan aplikacji, dzięki czemu architektura pozostaje prosta, a obowiązki są wyraźnie rozdzielone.
Podsumowanie renderowania EVE
Wyświetlacz EVE4 jest aktualizowany za pomocą standardowej sekwencji display list wykonywanej przez
Karta graficzna EVE:
CLEAR_COLOR_RGB() – ustawia kolor tła
CLEAR() – wyczyść bufory rysowania
polecenia rysowania
DISPLAY() – zakończ display list
Flush_DL_Buffer() – skopiuj polecenia do RAM_DL
DLSWAP_FRAME – spraw, by nowa ramka stała się widoczna
Ten niskoopoziomowy przebieg renderowania jest celowo prosty i niezmienny, co daje
pełną kontrolę nad tym, jak i kiedy EVE4 aktualizuje swój wyświetlacz.
Wynik
Przy takim ustawieniu:
- oba wyświetlacze działają jednocześnie,
- oba wyświetlacze reagują na dotyk,
- Wszystko, co robisz na jednym ekranie, odbija się też na drugim.
W rezultacie powstała przejrzysta i skalowalna architektura z dwoma wyświetlaczami, sterowana przez jeden układ STM32H7, w której jedna aplikacja kontroluje dwie niezależne ścieżki renderowania o wyraźnie rozdzielonych zadaniach.
Podsumowanie i kolejne kroki
Ten szablon stanowi punkt wyjścia dla systemów, w których jeden mikrokontroler steruje dwoma wyświetlaczami, wykorzystującymi różne modele renderowania, ale oparte na wspólnej logice aplikacji.
Można to w naturalny sposób rozszerzyć:
- rozszerz stan współdzielony,
- wprowadzić zaawansowane funkcje graficzne w EVE,
- dostosować model interakcji do bardziej złożonych procesów roboczych,
- przejść na nowsze generacje EVE.
Pełny projekt referencyjny jest dostępny na GitHubie:
https://github.com/riverdi/STM32H7-EVE4
Ten projekt ma stanowić praktyczną podstawę dla skalowalnych systemów z dwoma wyświetlaczami opartych na układach STM32 i EVE.
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.
