Robienie grafiki na mikrokontrolerach jest zawsze ogromnym wyzwaniem. Tym bardziej, jeśli ma być to ładna grafika. Od lat znamy proste biblioteki tzw. GFX, które pozwalają nam rysować bitmapy, czy różne czcionki. Jednak to jest za mało, bo często nasze GUI nadal wygląda jak z urządzeń lat 90, albo i gorzej. Z pomocą przychodzi nam TouchGFX!

TouchGFX na STM32

Czym jest ten tajemniczy TouchGFX? Według producenta jest to zaawansowany programowy framework graficzny zoptymalizowany pod STM32. To sformułowanie brzmi nieco skomplikowanie. Czym jest tak w prostych słowach?

Powiedziałbym, że TouchGFX jest wręcz silnikiem graficznym dla mikrokontrolerów. Wykorzystuje zasoby mikrokontrolerów STM32 takie akcelerator Chrom-ART™ do tego, aby efektywnie zarządzać tym, co się dzieje na wyświetlaczu.

TouchGFX zawiera TouchGFX Designer. Jest to oprogramowanie typu WYSIWYG (trudna, co?), które pozwala nam na zaprojektowanie całego wyglądu graficznego naszej aplikacji.

Nie tylko wyglądu, bo również animacji, przejść między ekranami, oraz zachowania przy dotyku panelu dotykowego, lub naciśnięciu zdefiniowanych przycisków.

W tym Designerze tworzymy całe GUI, które swoim wyglądem niczym nie odbiega od współczesnych tworów. Mówi się, że TouchGFX pozwala generować nam GUI podobne do smartfonowego. Zresztą sam zobacz.

Wygląda całkiem ładnie, co nie? Poczekaj aż zobaczysz jak to działa 🙂

O tym jak działa cały TouchGFX napiszę w kolejnych artykułach. Dzisiaj skupię się na tym, aby go uruchomić po raz pierwszy.

Platforma demonstracyjna

ST Microelectronics jak to oni – dostarczają gotowe i łatwe (to się okaże) do uruchomienia programy demonstracyjne. Tak jest też dla TouchGFX.

Demka można uruchomić na przykład na zestawach STM32 Discovery z wyświetlaczem. Jednak dzisiaj skorzystam z innej opcji. Niedawno ST wypuściło dedykowany shield TouchGFX dla płytek Nucleo-64.

Shield ten ma za zadanie pokazanie, że z TouchGFX można korzystać również na mniejszych mikrokontrolerach, które nie mają zbyt wiele zasobów jak np. pamięć RAM.

RAM przy wyświetlaczach jest bardzo potrzebny. To w nim odbywa się rysowanie wszystkich grafik z wykorzystaniem buforowania. Jeśli nie mamy wystarczająco RAMu, to co?

TouchGFX wspiera częściowe buforowanie i to właśnie wykorzystuje demo dla kombinacji NUCLEO-G071RB z shieldem X-NUCLEO-GFX01M1.

Gotowy zestaw kupisz u mnie sklepie. Razem wychodzi taniej.

Odpalmy program demonstracyjny

Przejdźmy więc do tego, aby po raz pierwszy obudzić do życia TouchGFX. Fajnie byłoby zobaczyć jak to żyje.

ST przygotowało tutaj łatwe do odpalenia (no… powiedzmy) przykładowe projekty. Jednak potrzebujemy mieć program TouchGFX Designer.

Od wersji 4.16.0 program ten nie występuje jako osobny byt. Został wciągnięty do rozszerzenia Cube’a X-CUBE-TOUCHGFX. Jest to taka jakby wtyczka do Cube ułatwiająca integrację projektu TouchGFX z projektem Cube’owym.

Możesz ją pobrać i rozpakować, a możesz też ją zainstalować przy pomocy samego Cube. Polecam zainstalowac z poziomu Cube, bo i tak jej tam będziesz potrzebował. Jednak musisz wiedzieć gdzie na swoim komputerze masz repozytorium bibliotek dla Cube.

Po zainstalowaniu to w nim będziesz musiał znaleźć instalkę TouchGFX Designera pod ścieżką (Windows) <Repozytorium>\Packs\STMicroelectronics\X-CUBE-TOUCHGFX\<version>\Utilities\PC_Software\TouchGFXDesigner

Strasznie skomplikowana ścieżka! Jakby nie mogli dalej udostępniać instalki osobno.

Tam jest instalator, więc zainstaluj program i przechodzimy dalej. Odpal zainstalowany TouchGFX Designer. Dostaniesz takie okienko powitalne.

To jest ekran tworzenia nowego projektu. Wybierasz szablon aplikacji (sprzęt na którym ma działać), oraz szablon UI, czyli wyglądu. Tym razem nie będziemy z tego korzystać. U góry masz taką zakładkę jak Olnine Applications. Tam są właśnie programy demonstracyjne dla evali ST, które pobierają się z Internetu. Wchodzimy w nie.

Masz teraz do wyboru tylko Online Application. Wejdź i znajdź odpowiednie demo. W wypadku NUCLEO-G071RB z shieldem X-NUCLEO-GFX01M1 będzie to tak, jak poniżej.

Kliknij Select. Musisz jeszcze podać nazwę aplikacji, oraz ścieżkę dla projektu. Tutaj masz dowolność 🙂 Nie polecałbym jednak polskich znaków, bo nie są dobrze trawione przez CubeIDE i kompilator

Gdy już wszystko masz, klikasz Create.

W tej chwili zaciągana jest z repozytorium ST nasza aplikacja demonstracyjna. Po tym zobaczysz ekran Designera.

 

Tym, co właśnie widzisz będziemy się zajmować kiedy indziej. Jest tutaj masa funkcji, o których nawet na dzień pisania tego artykułu nie mam pojęcia.

Możesz się porozglądać po tym programie. Znajdziesz tutaj na przykład wszystkie obrazy, które wykorzystuje demonstracyjne GUI jak i teksty. Głównym kombajnem jest jednak ten pierwszy ekran o nazwie Canvas.

To własnie w nim projektujesz cały wygląd swojej apliakcji. Będziemy to intensywnie poznawać. Sam nie mogę się doczekać 😉

No dobra, ale naszym celem jest zwykłe uruchomienie przykładu działania. Po prawej stronie u góry masz 3 przyciski.

1. Run Simulator – uruchamia symulator Twojego projektu TouchGFX. Możesz przetestować działanie GUI bez wgrywania tego na mikrokontroler. Ekstra sprawa. W naszym wypadku jest jeden problem. Do nawigacji używamy Joysticka na Shieldzie, więc nie mamy jak się poruszać w symulatorze. On się świetnie spisze w aplikacjach z panelem dotykowym.
2. Run Target – Nie udało mi się jeszcze tego uruchomić. To powinno działać tak, że uruchamiamy projekt bezpośrednio z TouchGFX Designera na naszym zestawie ewaluacyjnym.
3. Generate Code – To jest to, co nas w tej chwili interesuje. TouchGFX powinien wygenerować nam kompletny projekt dla CubeIDE, który później można zaimportować.

No to próbuję wygenerować. Powinien się na dole okna mienić błękitny pasek informujacy o generowaniu kodu. Jak zakończy – możesz otworzyć STM32CubeIDE. Tylko jakie? Niestety ciężko jest znaleźć dokument, w którym można znaleźć, jakie CubeIDE jest odpowiednie dla projektów z danej wersji TouchGFX Designera.

Ale, ale, ale! To dotyczy tego, jeśli instalujesz osobno te dwa narzędzia. Jeżeli instalowałeś TouchGFX Designer poprzez zaciągnięcie dodatku w CubeIDE to powinno to wszystko współgrać.

Ja mam zestaw STM32Cube IDE 1.6.0 + TouchGFX Designer 4.16.0. Odpalamy CubeIDE i jedziemy.

Jako Workspace wybierz te, które wpisałeś w TouchGFX Designer na samym początku. Później zaimportuj projekt, który wygenerował TouchGFX Designer.

Teraz ważna rzecz. Próbując uruchomić plik Cube’a nie aktualizuj bibliotek HAL! Daj Continue. Nie klikaj Migrate!

Dlaczego? Korzystamy z HALa dla STM32G0, bo takie mam Nucleo. Projekt był pisany na wersji HALa FW_G0 V1.3.0. Najnowsze V1.4.1 mają koszmarnego buga w definicjach rejestrów i trzeba dokleić kilka definicji do nagłówków…

Nie warto się gimnastykować 🙂 Poczekajmy, aż to naprawią.

Po zaimportowaniu i uruchomieniu Cube’a naszym oczom ukazuje się taki widok.

Po lewej stronie widzimy kilka dodatkowych elementów, których nie ma przy tworzeniu gołego projektu w CubeMX.

Po pierwsze widzimy takie foldery jak generated, gui, TouchGFX. Są to rzeczy wygenerowane przez TouchGFX Designera, oraz sama biblioteka TouchGFX.

W tych wygenerowanych rzeczach znajdują się nagłówki informujące o tym gdzie znajdują się obrazy, czcionki, a także jak wyglądają nasze ekrany w aplikacji.

Pod spodem jest jeszcze jeden fajny folder o tajemniczej nazwie MB1642B. Jest to kod Shieldu z wyświetlaczem. Folder ten zawiera driver wyświetlacza, pamięci Flash SPI i Joysticka.

Dojdziemy do tego później, ale w skrócie mówiąc dla silnika TouchGFX należy dostarczyć właśnie takie sterowniki. Silnik ten musi wiedzieć jak obcować z wyświetlaczem oraz pamięcią Flash, aby poprawnie pracować. W przyszłości będziemy próbowali taki sterownik napisać samodzielnie.

Zanim uruchomimy kod, mam jeszcze jedną uwagę. Zawsze powtarzam, aby zaznaczać w Cube ptaszek “Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”. Pozwala on zachować lepszą czytelność projektu.

Przy programach demonstracyjnych nie zaznaczamy go. Taki podział niestety psuje przykładowy kod pisany przez ST. Odwołują się oni do plików, które są tworzone dokładnie w taki sposób jak zastajemy po wygenerowaniu w TouchGFX Designer i lepiej tego nie ruszać.

Problem z generowaniem bitmap

Niestety borykam się dosyć sporym problemem. Jeśli tworzę któryś z kolei projekt w TouchGFX Designer na podstawie przykładu online – nie zostają stworzone nagłówki do obrazów.

Działa to fajnie za pierwszym razem, kiedy mam świeżą instalację. Z każdym kolejnym – mam taki oto błąd kompilacji wygenerowanego projektu.

Nie istnieją żadne definicje obrazków w projekcie. Błąd zgłosiłem do ST, ale nie potrafią go odtworzyć. Daj znać jeśli również masz takie problemy.

Może na innych projektach tego nie będzie…

Problem zgłoszony na forum TUTAJ

External Loader Flash SPI

Jeśli wszystko się udało, możesz zbudować projekt. Pewnie chciałbyś go wrzucić już na mikrokontroler, ale nie! To jeszcze nie zadziała.

TouchGFX korzysta z zewnętrznej pamięci Flash w której trzyma wszystkie obrazy. Do poprawnego działania programu te obrazy trzeba tam wrzucić.

Ale jak to zrobić? Przecież to jest pamięć na SPI podłączonym do mikrokontrolera?

Tutaj ST już jakiś czas temu opracowało coś takiego, co się nazywa External Loader. Podczas programowania mikrokontrolera możemy również zaprogramować pamięć Flash podłączoną po SPI.

Jest to mega rozwiązanie i z pewnością będę chciał to przetrenować na własnych przykładach. Problem jest taki, że taki pojedynczy loader dedykowany jest dla pojedynczego mikrokontrolera i konkretnej konfiguracji sprzętowej.

Jest to taki mały firmware, który pozwala przerzucić dane przychodzące z ST-Linka do Flash SPI (lub innej pamięci).

Trzeba powiedzieć skryptowi ładującemu nasz program, że musi korzystać z External Loadera.

Dla naszego przykładu znajduje się on w folderze projektu <Projekt>\gcc i jest to plik MX25L6433F_STM32G071B_NUCLEO.stldr

Musimy go skopiować do pluginów CubeIDE . U mnie znajduje się to pod ścieżką <zainstalowany CubeIDE>\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\tools\bin\ExternalLoader

Znowu nieludzka ścieżka, co? 🙂

Wklej ten plik w to miejsce i wróc do CubeIDE. Odpal konfigurację debugowania.

Musisz teraz wzskazać ten plik, który kopiowałeś. Wejdź w konfigurację debugu projektu, później zakładka Debugger i na samym dole masz sekcję Misc.

Zaznacz ptaszka przy External Loader (o ile już nie jest zaznaczony). Powinien pojawić Ci się jakiś plik, który był przypisany do projektu. Ten loader jest nieaktualny i musisz wybrać nowy, który kopiowałeś.

Wciśnij Scan i wybierz Twój plik. Poniżej na screenie masz zaznoczone wszystkie te elementy.

Zapisz konfigurację – poprzez Apply – i uruchom debug.

Działanie dema

Teraz powinien się wgrać program, oraz zawartość zewnętrznego Flash SPI. Zobaczysz podczas wgrywania iedy się wykonuje External Loader. Jest on dosych charakterystyczny.

Całe wgrywanie trwa dłuższą chwilę ze względu na zewnętrzny Flash.

Jednak gdy sie wszystko powiedzie, możesz uruchomić program. Zobaczysz piękne demo przygotowane dla naszego Shielda. Nagrałem krótki film prezentujący działanie programu.

Przyznaj, że jak na taki mały mikrokontroler – STM32G071RB – GUI chodzi świetnie. To jest właśnie TouchGFX. Ten silnik jest niesamowity i zapowiada się, że zostanie ze mną na dłużej!

Podsumowanie

Jak widzisz samo uruchomienie programu demonstracyjnego już może sprawić wiele problemów. Nie dziwi mnie to, że tak niewiele osób pracuje z TouchGFX skoro to jest tak skomplikowane.

Niestety martwi mnie również mała ilość materiałów na temat tego środowiska. Zwłaszcza takich, w których będzie pokazane jak zaimplementować swój sprzęt do działania z TouchGFX.

Fajnie jeśli są programy demonstracyjne, ale my potrzebujemy robić własne. Do tego będę dążył i pokazywał Ci jak to robię.

Jeśli artykuł Ci się spodobał, kup coś u mnie!  https://sklep.msalamon.pl/

Jeśli zauważyłeś jakiś błąd, nie zgadzasz się z czymś, chciałbyś coś dodać istotnego lub po prostu uważasz, że chciałbyś podyskutować na ten temat, napisz komentarz. Pamiętaj, że dyskusja ma być kulturalna i zgodna z zasadami języka polskiego.