Stawianie pierwszego programu V1.19.0 vs V2.0.0.oraz BSP cz. 3

STM32CubeIDE v.2.0.0

Trzecią ścieżką pracy jest model wprowadzony wraz z STM32CubeIDE w wersji 2.0. To istotna zmiana w sposobie organizacji środowiska, która pojawiła się pod koniec 2025 roku i wpłynęła na dotychczasowy workflow wielu użytkowników.

Najważniejszą różnicą jest rozdzielenie STM32CubeMX od STM32CubeIDE. Konfigurator nie jest już wbudowany bezpośrednio w IDE, lecz funkcjonuje jako osobne narzędzie instalowane i aktualizowane niezależnie. Projekt konfiguruje się w STM32CubeMX, a następnie importuje do STM32CubeIDE w celu kompilacji, debugowania i dalszego rozwoju kodu.

Główne zmiany z perspektywy użytkownika

W serii 1.x STM32CubeMX był ściśle zintegrowany ze środowiskiem STM32CubeIDE. Otwierając plik .ioc, użytkownik pracował bezpośrednio w jednym oknie IDE, a generowanie kodu odbywało się w ramach tej samej aplikacji.

W wersji 2.0 model ten uległ zmianie. STM32CubeMX funkcjonuje jako niezależne narzędzie, a integracja z IDE opiera się na plikach .ioc oraz mechanizmie importu projektu. Konfiguracja sprzętowa i generowanie kodu realizowane są w CubeMX, natomiast STM32CubeIDE pełni rolę środowiska do edycji, kompilacji i debugowania.

Takie rozdzielenie upraszcza architekturę narzędzi i eliminuje ścisłe powiązanie obu komponentów w jednej aplikacji.

Niezależne wersjonowanie i aktualizacje

W modelu 1.x aktualizacja STM32CubeIDE była jednoznacznie powiązana z wersją wbudowanego konfiguratora STM32CubeMX. Przec zo aktualizacja samego STM32CubeMX wymuszała aktualizację całego IDE.

W wersji 2.0 możliwe jest niezależne aktualizowanie obu narzędzi. Użytkownik może pracować z wybraną wersją CubeMX oraz wybraną wersją IDE, co zwiększa elastyczność środowiska i ułatwia wsparcie dla nowych rodzin mikrokontrolerów bez konieczności częstych aktualizacji całego IDE.

Nowa architektura oznacza przejście od ścisłej integracji do modelu opartego na interoperacyjności. Pliki projektu są generowane w CubeMX, a następnie importowane do IDE, które odpowiada za dalszy rozwój aplikacji.

Z perspektywy użytkownika oznacza to nieco inny workflow niż w serii 1.x. Wymaga on większej świadomości zależności pomiędzy narzędziami, ale jednocześnie zapewnia większą elastyczność oraz skalowalność całego ekosystemu STM32Cube.

Przejdźmy teraz do praktycznego przykładu pracy w modelu opartym o STM32CubeIDE v2.0. W przeciwieństwie do wcześniejszych scenariuszy konfigurację rozpoczniemy bezpośrednio w aplikacji STM32CubeMX, a następnie zaimportujemy wygenerowany projekt do IDE.

Sam proces konfiguracji będzie bardzo zbliżony do tego, który poznaliśmy wcześniej w przypadku wbudowanego CubeMX w wersji 1.x. Różnica polega przede wszystkim na rozdzieleniu narzędzi i kolejności wykonywanych kroków.

W tym przykładzie ograniczymy się do jednego wariantu – utworzenia projektu w trybie „Start from MCU”, aby skupić się na nowym workflow, a nie na różnicach wynikających z użycia BSP.

Po wybraniu opcji utworzenia nowego projektu w STM32CubeMX pojawi się znany już widok MCU Selector. Interfejs ten działa identycznie jak w przypadku wersji zintegrowanej z STM32CubeIDE 1.x, dlatego nie będziemy ponownie szczegółowo omawiać całej procedury.

W tym przykładzie wybieramy mikrokontroler STM32G474RET6, czyli układ zastosowany na płytce NUCLEO-G474RE.

Po zatwierdzeniu wyboru mikrokontrolera przechodzimy do właściwej konfiguracji projektu. Choć interfejs STM32CubeMX w wersji zewnętrznej różni się wizualnie od tego wbudowanego w STM32CubeIDE 1.x, sama logika pracy z narzędziem pozostaje taka sama.

Jeśli STM32CubeMX jest uruchamiany po raz pierwszy, warto na początku sprawdzić i ewentualnie skonfigurować lokalizację repozytorium pakietów firmware (STM32Cube MCU Packages). Analogicznie jak w STM32CubeIDE, ustawienie wspólnego katalogu pozwala uniknąć wielokrotnego pobierania tych samych bibliotek dla różnych narzędzi.

Opcję tę można znaleźć w menu Help > Connection & Updates, gdzie dostępne są ustawienia dotyczące aktualizacji oraz lokalizacji pakietów firmware.

W tym momencie może się okazać, że zmiana lokalizacji repozytorium nie jest możliwa. Dzieje się tak dlatego, że STM32CubeMX nie pozwala modyfikować tej ścieżki, gdy projekt jest już otwarty. Analogiczne ograniczenie występuje w STM32CubeIDE – ustawienia globalne związane z pakietami firmware można zmieniać wyłącznie przy zamkniętym projekcie.

Aby wprowadzić zmianę, należy zamknąć bieżący projekt lub całkowicie zakończyć działanie STM32CubeMX, uruchomić narzędzie ponownie, skonfigurować właściwą ścieżkę repozytorium, a następnie utworzyć projekt jeszcze raz.

Warto podkreślić, że konfigurację lokalizacji pakietów firmware wykonuje się zazwyczaj tylko raz dla danej instalacji STM32CubeMX lub STM32CubeIDE. Po jej ustawieniu kolejne projekty będą korzystać z tego samego repozytorium. Po ponownym utworzeniu projektu użytkownik zobaczy znany już interfejs konfiguratora z widokiem mikrokontrolera i drzewa peryferiów.

W kolejnym kroku przypisz pin PA5 jako wyjście GPIO, analogicznie jak w poprzednim przykładzie realizowanym w STM32CubeIDE v1.19.0. W przypadku płytki NUCLEO-G474RE pin ten odpowiada diodzie LD2, dlatego taka konfiguracja będzie wystarczająca do weryfikacji poprawności całego procesu generowania i importu projektu.

Przed ostatecznym wygenerowaniem projektu nie zapomnij o ptaszku do rozdzielenia plików peryferiów.

W modelu pracy opartym o STM32CubeMX jako narzędzie zewnętrzne wszystkie ustawienia dotyczące projektu konfigurowane są bezpośrednio w zakładce Project Manager.

To właśnie w tym miejscu definiujemy nazwę projektu, lokalizację katalogu, typ toolchaina/IDE oraz dodatkowe opcje związane ze strukturą generowanego kodu. W przeciwieństwie do wersji 1.x, gdzie część parametrów była ustawiana bezpośrednio w kreatorze projektu w STM32CubeIDE, w wersji 2.0 pełna konfiguracja projektu odbywa się po stronie CubeMX przed wygenerowaniem kodu.

W zakładce Project Manager należy nadać projektowi nazwę oraz wskazać katalog, w którym zostanie on utworzony. Lokalizacja ta będzie zawierała pełną strukturę wygenerowanych plików oraz konfigurację projektu.

W przedstawionym przykładzie jako katalog docelowy wybrany został folder, który jednocześnie pełni rolę workspace dla STM32CubeIDE v2.0. Takie podejście upraszcza organizację pracy. W praktyce warto rozważyć stosowanie oddzielnych workspace dla różnych wersji IDE, co pozwala uniknąć potencjalnych konfliktów konfiguracji oraz niejednoznacznych skojarzeń plików projektowych.

Konieczne jest również ustawienie pola Toolchain / IDE na STM32CubeIDE, aby wygenerowany projekt był poprawnie przygotowany do importu i dalszej pracy właśnie w tym środowisku.

Warto zwrócić uwagę, że STM32CubeMX umożliwia wygenerowanie projektu dostosowanego do różnych toolchainów oraz środowisk programistycznych. Oprócz STM32CubeIDE dostępne są konfiguracje dla innych IDE oraz systemów budowania, w tym projektów opartych o CMake.

Takie podejście zwiększa elastyczność pracy i pozwala dopasować środowisko do preferencji zespołu projektowego. Coraz więcej programistów korzysta z edytorów takich jak Visual Studio Code w połączeniu z CMake, a STM32CubeMX pozwala wygenerować strukturę projektu zgodną z tym workflow bez konieczności ręcznej konfiguracji od podstaw.

Po uzupełnieniu wszystkich ustawień w zakładce Project Manager można wygenerować projekt, wybierając opcję GENERATE CODE.

Po chwili mamy komunikat o gotowym projekcie.

Jeśli wybierzesz opcję Open Project, STM32CubeMX spróbuje otworzyć (zaimportować) wygenerowany projekt bezpośrednio w STM32CubeIDE. Warto jednak pamiętać, że zostanie użyta domyślna aplikacja skojarzona w systemie z plikami projektu (np. .cproject / .project).

Jeżeli na danym komputerze jako domyślne środowisko jest ustawione STM32CubeIDE v1.19.0, projekt może zostać otwarty właśnie w tej wersji, nawet jeśli celem było użycie STM32CubeIDE v2.0.0.

W wielu przypadkach na pierwszy rzut oka wszystko będzie wyglądało poprawnie – projekt może się kompilować i dać się zaprogramować na płytkę. Różnice pojawiają się w momencie pracy z konfiguracją .ioc. W środowisku 1.x plik .ioc jest obsługiwany przez wbudowany STM32CubeMX, natomiast w tym scenariuszu konfiguracja została przygotowana w zewnętrznym CubeMX, który może być nowszy niż wersja zintegrowana w IDE 1.x. W efekcie edycja konfiguracji i regeneracja kodu z poziomu IDE 1.x może być ograniczona lub niezgodna z użytym workflow.

Choć projekt może zostać otwarty w starszej wersji IDE, naszym celem jest praca w modelu opartym o STM32CubeIDE v2.0.0, zgodnie z nową koncepcją
rozdzielenia narzędzi.

Uruchom zatem STM32CubeIDE v2.0.0, wskazując jako workspace wcześniej przygotowany katalog. W jego strukturze znajduje się projekt wygenerowany przed chwilą w STM32CubeMX. Dzięki temu IDE będzie pracować bezpośrednio na właściwej lokalizacji projektu, bez konieczności jego przenoszenia czy duplikowania.

Po uruchomieniu STM32CubeIDE v2.0.0 środowisko może wyświetlić komunikat z pytaniem, czy pliki projektowe Eclipse (np. .project, .cproject) powinny zostać skojarzone właśnie z tą wersją IDE. W oknie dialogowym widoczna jest również informacja, która aplikacja jest obecnie domyślnie powiązana z tymi plikami – na przykład STM32CubeIDE v1.19.0.

Decyzja o zmianie skojarzenia zależy od przyjętego sposobu pracy i liczby równolegle używanych wersji środowiska. Ustaw zgodnie z Twoimi preferencjami.

Aby otworzyć projekt wygenerowany w STM32CubeMX w STM32CubeIDE v2.0.0, należy skorzystać z opcji Import i wskazać katalog, w którym został on utworzony. Dzięki temu projekt zostanie poprawnie dodany do aktualnego workspace i będzie gotowy do kompilacji oraz debugowania w nowej wersji IDE.

Na tym etapie dostępna jest również opcja utworzenia nowego projektu bezpośrednio z poziomu STM32CubeIDE. Należy jednak pamiętać, że taki projekt będzie miał charakter podstawowy – nie będzie zawierał wygenerowanej konfiguracji z STM32CubeMX ani dołączonych pakietów HAL odpowiadających wcześniej wybranej rodzinie mikrokontrolerów. W praktyce oznacza to rozpoczęcie pracy od całkowicie pustej struktury projektu.

W omawianym scenariuszu chcemy pracować na projekcie wygenerowanym w STM32CubeMX, dlatego należy wybrać opcję Import. W kolejnym kroku wskazujemy katalog, w którym znajduje się wygenerowany projekt, aby dodać go do bieżącego workspace i kontynuować pracę w STM32CubeIDE v2.0.

W kolejnym kroku należy zaznaczyć projekt, który ma zostać dodany do bieżącego workspace, a następnie zatwierdzić wybór przyciskiem Finish.

Po zakończeniu importu projekt wygenerowany w zewnętrznym STM32CubeMX będzie widoczny w strukturze STM32CubeIDE v2.0. Od tego momentu można go kompilować, debugować oraz rozwijać w identyczny sposób jak projekty tworzone bezpośrednio w środowisku IDE, z tą różnicą, że konfiguracja sprzętowa pozostaje obsługiwana przez osobne narzędzie
STM32CubeMX.

Po zaimportowaniu projektu warto otworzyć plik .ioc. W modelu pracy opartym o STM32CubeIDE v2.0 jego otwarcie spowoduje uruchomienie zewnętrznego narzędzia STM32CubeMX, w którym można wprowadzać zmiany w konfiguracji mikrokontrolera oraz generować zaktualizowany kod. Mechanizm ten zastępuje znaną z wersji 1.x integrację konfiguratora bezpośrednio w IDE.

Sama praca z kodem w STM32CubeIDE v2.0 – edycja plików źródłowych, kompilacja, debugowanie oraz programowanie mikrokontrolera – przebiega w taki sam sposób jak wcześniej. Różnica polega wyłącznie na tym, że generator konfiguracji sprzętowej nie jest już częścią IDE, lecz działa jako osobna aplikacja współpracująca z projektem poprzez plik .ioc.

Najwygodniejszą i najbardziej „edukacyjną” drogą dla początkujących jest według mnie wariant z CubeIDE v1.x.x „z MCU”, czyli start od gołego mikrokontrolera bez BSP i bez „magii” płytki. W tym podejściu najszybciej uczysz się zarówno samego sprzętu (pinów, peryferiów, zegarów), jak i narzędzia, a projekty są najczystsze i najmniej „zaczarowane” kodem wygenerowanym pod konkretną płytkę.

Tryb v1.x.x „z Nucleo” jest wygodny, ale dobry raczej jako kolejny krok: gdy już rozumiesz, co robi HAL i podstawowa konfiguracja, możesz docenić, jak BSP i start od płytki skracają czas uruchomienia LED-a, przycisku czy czujnika – jednocześnie świadomie widzisz, co jest naprawdę potrzebne, a co jest tylko ułatwieniem dodanym przez narzędzie. Dzięki temu nie wpadasz w pułapkę kopiowania kodu BSP bez zrozumienia.

Sytuację komplikuje fakt, że linia v1.x (np. 1.19.0) nie dostaje już wsparcia dla nowszych wersji konfiguratora i nowych rodzin STM32, więc prędzej czy później i tak trzeba będzie sięgnąć po zewnętrzny CubeMX i import projektów do CubeIDE 2.0 albo po inne środowisko do edycji kodu. W tym sensie trzeci wariant – v2.0.0 z importem – to dobra droga „na przyszłość”, ale bardziej dla osób, które mają już podstawy i chcą jednocześnie korzystać z nowych układów oraz mieć świadomie ogarnięty proces: osobny konfigurator, osobny edytor/IDE, jasny podział odpowiedzialności narzędzi.

Możemy to w skrócie podsumować następująco:

• dla nauki i pierwszych projektów – v1.x.x z MCU,
• dla wygody na Nucleo, gdy już masz już solidne podstawy – v1.x.x z Nucleo i BSP,
• dla nowych rodzin mikrokontrolerów STM32 i długoterminowo – model „zewnętrzny CubeMX + CubeIDE 2.0 (lub inne IDE)” z pełną świadomością, że konfigurator jest osobnym narzędziem.

Mateusz Salamon

https://msalamon.pl

https://kursstm32.pl