Minęło już trochę czasu kiedy sporządziłem listę ośmiu najlepszych IDE dla STM32. W momencie pisania tamtego artykułu nikt publicznie jeszcze nie wiedział co się wydarzy. ST przejęło firmę Atollic zagarniając wraz z nimi ich IDE dla STM32, czyli TrueStudio. W efekcie tych zajść w końcu mamy coś, co “tworzy” ST, a mianowicie STM32CubeIDE. Zerknijmy zatem co mają do zaoferowania.

TrueStudio for STM32 + CubeMX = STM32CubeIDE

Te IDE jeszcze przed rebrandingiem zdobyło drugie miejsce w mojej ankiecie najczęściej używanych środowisk. Nie dziwi mnie ten fakt, bo posiadało ono naprawdę spore grono wyznawców. Aktualnie ST dorzuciło mu parę ciekawych rzeczy, które sprawiają, że to środowisko jest w zasadzie samowystarczalne. 

Jeszcze do niedawna istniała taka potrzeba, aby mieć STM32CubeMX oraz jakieś IDE. W CubeMX konfigurowałeś wszystko pod swoją platformę, generowałeś szkielet projektu wraz z kodami inicjalizacyjnymi a na końcu musiałeś zaimportować tenże projekt do IDE którego używasz. Z ankiety wynikało, że najczęściej jest to SW4STM32 lub TrueStudio.

Aktualnie CubeMX został wbudowany bezpośrednio w IDE. Co to oznacza? Wystarczy Ci teraz tylko jedno narzędzie i jest nim STM32CubeIDE.

Oczywiście nadal utrzymywany jest osobny byt w postaci STM32CubeMX po to, aby ktoś, kto korzysta z innego IDE lub “notatnika” mógł również generować swoje projekty.

Najnowsze STM32CubeIDE możesz pobrać bezpośrednio od ST >tutaj<.

Jak pracować z CubeIDE?

Od jakiegoś czasu korzystam tylko z STM32CubeIDE i muszę powiedzieć, że jestem zadowolony. Projekt generuje się szybciej, co jest dla mnie ważne tworząc dla Ciebie treści na bloga. Najnowsza wersja na dzień pisania posta to v1.1.0.

Środowisko dostępne jest na wszystkie “duże” OSy, czyli Windows, różne Linuksy oraz na macOS czego nie było w starym TrueStudio. Niestety na niczym innym niż Windows nie testowałem działania. Jestem smutnym użytkownikiem Windowsa 😉

Generowanie projektu

Prawdę mówiąc, tak jak do tej pory z CubeMX oraz np. Attoliciem. Po prostu teraz wszystko robisz w jednym miejscu. Generator projektu wygląda identycznie jak w “osobnym” Cube.

Pracę rozpoczynasz przez kliknięcie Start new STM32 project. Możesz też importować projekt, który był generowany dla SW4STM32 lub TrueStudio. Ale uważaj, bo to jednak nie zawsze działa poprawnie i może zniszczyć Ci projekt. Lepiej zrób jego kopię zapasową na wszelki wypadek. Ja się już tak nie raz uratowałem.

Po wybraniu nowego projektu zobaczysz dobrze znany Ci selektor MCU. Wybierasz swój mikrokontroler i jedziesz dalej.

IDE chwilę pomieli i w końcu Twoim oczom ukarzę się znany Ci widok z CubeMX.

Twórcy dodali do Eclipse’a perspektywę dedykowaną dla CubeMX. Z tego, co ja widzę, to rozsuwa wszystkie inne okna odsłaniając to, co najważniejsze przy konfiguracji, czyli widok Cube’a.

Przełączając się na plik projekti *.ioc, są one powiązane z perspektywą Cube’a i Eclipse podpowiada, aby przełączyć się na nią. To jest dobre.

Tworzenie kodu

Piszę się dokładnie tak samo, jak w każdym Eclipse. W każdej chwili możesz zmienić konfigurację we wbudowanym Cube i przegenerować projekt. Nie zdarzyło mi się jeszcze, aby moje pliki projektu zostały skasowane, czego nie mogę powiedzieć o CubeMX w wersji standalone. Jednak zawsze zalecam mieć backup – to nadal jest napisane w Javie 😉

Zauważyłem kilka różnic, które może być dla niektórych irytujące w zależności, jakie mają preferencje do pracy z IDE. W odróżnieniu od SW4STM32, którego używałem wcześniej podpowiadanie argumentów funkcji jest ustawione na ich uzupełnianie i zgadywanie.

Co to oznacza? Używając Ctrl+Space nie dość, że dopasuje Ci nazwę funkcji, to jeszcze wypełni argumenty. Wygląda to, jak poniżej.

Wpisałem “HAL_GPIO_W” i wcisnąłem Ctrl+Space. Nie dość, że zakończył za mnie nazwę funkcji, to jeszcze wpisał nazwy argumentów. Ustawił kursor pisania na pierwszy argument. Nie wiedział czym to wypełnić, więc nazwał argumenty tak, jak są nazwane w deklaracji funkcji.

Czasami faktycznie zgaduje to, co chciałbym tam wpisać i nawet jako tako daje to radę. Mając  z tym styczność po raz pierwszy czułem się niezręcznie. Jednak jestem na tyle leniwy, że nie chce mi się za każdym razem tego wyłączać i trochę z tym popracowałem. Ostatecznie śmiem stwierdzić, że nie jest to dla mnie na tyle uciążliwe, abym mocno marudził. Jednak ktoś, przesiadając się z SW4STM32 tak jak ja może czuć się początkowo nieswojo.

Więcej istotnych z mojego punktu różnic nie zauważyłem. Może Ty jakieś znasz? Podziel się w komentarzu.

Uruchamianie i debugowanie

Debugowanie działa w zasadzie tak samo. To jest Eclipse, więc jest wszędzie tak samo. Breakpointy działają dobrze, praca krokowa również.

Niestety, jeżeli chodzi o szybkie uruchamianie kodu, to tego tu nie uświadczysz. Przynajmniej nie bez drobnych zmian… Otóż znowu podam tutaj przykład z przesiadki z SW4STM32. Możesz nazwać mnie marudą, ale to prawda 🙂

System Workbench miał taką fajną ikonkę zielonego znaczka “Play” jak z magnetofonu. Powodowała ona, że skompilowany kod wysyłany był do mikrokontrolera i od razu uruchamiał się bez żadnego trybu debugowego.

Tak, ten sam efekt osiągnę wgrywając trybem debugowym i uruchamiając kod bez breakpointów jednak ma to dla mnie 3 różnice:

1. Binarka w debugu ładuje się znacznie dłużej na MCU
2. Wypadałoby przełączyć perspektywę na debugową
3. Jeżeli nie odznaczysz domyślnego breakpointa na mainie, to musisz startować program ręcznie

Jakie ma to konsekwencje? Czas! Nie wiem jak bardzo jesteś doświadczony i jak pracujesz z mikrokontrolerami, ale mi zdarza się robić setki drobnych zmian, które chcę jak najszybciej testować.

Jakaś drobna zmiana w princie na konsolę, przesunięcie pixela na wyświetlaczu czy inna rzecz , która jest szybko weryfikowalna wzrokiem bez debugera. Takie częste przełączanie się w tryb debugowy może zjeść na prawdę masę czasu.

Tutaj znowu moje lenistwo wzięło górę i póki co jestem z tym pogodzony. Wiem, że można taki przycisk dorobić. Próbowałem raz bezskutecznie, więc jeśli potrafisz coś takiego zrobić to będziesz miał specjalne miejsce w moim mikrokontrolerowym sercu <3

Czy warto?

Wymieniłem w zasadzie tylko wady, które zauważyłem podczas mojej krótkiej przygody z IDE. Czy to oznacza, że jest to złe IDE? Wręcz przeciwnie! Bardzo lubiłem pracować na SW4STM32, a STM32CubeIDE jest prawie identyczne w użytkowaniu. Możliwość korzystania z Cube’a wewnątrz IDE jest ogromnym ułatwieniem. 

Wiem, że można było dodać wtyczkę CubeMX do każdego Eclipse’a, ale tutaj mamy rozwiązanie out of the box i w dodatku z oficjalnym wsparciem tej integracji. Jest to o wiele lepsze rozwiązanie niż samodzielna instalacja i konfiguracja IDE.

Komu bym polecił STM32CubeIDE? Na pewno wszystkim początkującym, ale nie tylko. Ja używam cały czas, mimo że początkujący już nie jestem. Wiem, że sporo programistów po prostu nie lubi Eclipse’a. Nie będę Cię namawiał, jeśli do nich należysz.

Jeśli używasz już nowego IDE, podziel się odczuciami w komentarzu. Jestem ciekaw jak oceniasz nowy-stary twór od ST.

Na sam koniec aktualna ankieta z grupy STM32 Polska. Widać po niej, że nowe IDE ma wzięcie wśród programistów 🙂