Dobry zestaw narzędzi może niesamowicie poprawić naszą produktywność. Należę do osób lubiących automatyzację i wspomaganie się toolami przy developmencie. Szczególnie zrzucanie na toole żmudnych i ciężkich do wyegzekwowania czynności jak na przykład formatowanie kodu, czy wysyłanie komend na terminalu.  W tym wpisie przedstawię kilka przydatnych narzędzi, głównie pod kątem embedded, C/C++ i STM32.

Kompilator ARM

Zacznę trochę zaskakująco – od kompilatora. Często wydaje nam się, że nie ma się nad czym zastanawiać, istnieje tylko jedna opcja. Jeżeli chodzi o ARMy tych opcji jest całkiem sporo. Mamy ARM GCC, Linaro, IAR, Keil, GreenHills. Mam małe doświadczenie z płatnymi kompilatorami. Słyszałem opinie, że są lepsze i faktycznie warto wydać na nie pieniądze, jeśli realizujemy jakiś poważny projekt. Dostajemy wtedy lepsze optymalizacje i dodatkowe funkcjonalności jak np. obliczanie CRC, czy statyczną analizę kodu. Płatne kompilatory często są sprzedawane razem z dedykowanym IDE np. IAR, Keil, czy GreenHills. Co ciekawe o ile kompilatory są dobre, to korzystanie z samego IDE jest koszmarem. Dlatego często kończy się na projekcie w Eclipse i makefile. Mogę za to śmiało polecić jeden z darmowych kompilatorów.

bleeding-edge-toolchain

Toolchain do armów od Freddie Chopina. Polecałem ostatnio również jego RTOS. Jest to raczej niezbyt popularny darmowy toolchain, którego używam już od dłuższego czasu do domowych projektów. Jest on buildowany na podstawie najnowszych repozytoriów gcc, gdb, binutils, biblioteki standardowej newlib. Często wychodzą aktualizacje, więc możemy łatwo korzystać z nowych funkcjonalności takich jak na przykład wsparcie C++17.

Systemy buildowania

Przez długi czas byłem zwolennikiem zwykłych skryptów makefile, które w dodatku w pełni pisałem samodzielnie bez żadnych autotools, czy generowania z IDE. Makefile generowane z IDE to zło. Zawsze polegną na tworzeniu wielu targetów dla jednego projektu np. kiedy robimy oddzielne buildy dla unit testów, albo kiedy chcemy dodać jakieś flagi nieprzewidziane w IDE. Dlatego wolałem zawsze robić wszystko ręcznie i mieć nad tym kontrolę. Ostatnio coraz bardziej przekonuję się do nowszych systemów buildowania. A opcji jest kilka.

CMake

Trochę się nim zdążyłem pobawić i bardzo mi się podoba. Najprawdopodobniej właśnie jego będę wykorzystywał do nowych projektów. Umożliwia generowanie skryptów buildowania dla projektu zawierającego różne targety na różne platformy, korzystające z innych kompilatorów. Umożliwia również generowanie headerów zawierających kod zależny od zmiennych wykorzystywanych w skrypcie takich jak na przykład timestamp, czy git commit id. Świetnym ficzerem wydaje się również generowanie na bazie konfiguracji projektów dla Eclipse i Visual Studio.

Meson

Nowszy od CMake i podobno lepszy, ale mniej popularny. Reklamuje się jako najszybszy dostępny system buildowania. Nie miałem z nim nigdy styczności, ale na pewno warto wziąć go pod uwagę.

Scons

Napisany w pythonie, skrypty buildowania również są pisane w pythonie. Dzięki temu możliwe jest łatwe integrowanie własnych programów robiących jakieś dodatkowe rzeczy. Minusem jest szybkość, a raczej powolność spowodowana brakiem cacheowania konfiguracji.

Ninja

System buildowania będący prostszą wersją make. Jest przeznaczony do współpracy z systemem buildowania wyższego poziomu np. CMake, który może generować skrypty Ninja zamiast make.

Statyczna analiza kodu

Każde narzędzie do statycznej analizy kodu specjalizuje się w wyłapywaniu pewnych typów błędów. Najlepiej korzystać z kilku narzędzi jednocześnie, aby zwiększyć szanse wyłapania potencjalnych problemów. Warunkiem wstępnym do analizy statycznej powinno być pozbycie się warningów kompilatora, które same w sobie również są formą statycznej analizy. Aktualnie w prywatnych projektach nie stosuję statycznej analizy, ale chcę zacząć. Skorzystam w tym celu z darmowych narzędzi – CppCheck i clang-tidy.

PC-Lint

Narzędzie płatne, wywoływane z konsoli, rozwijane od lat 80-tych. Wspiera zarówno C, jak i C++. Potrafi znaleźć wiele rodzajów błędów i grupuje je pod kątem ważności. Pozwala na definiowanie własnych skryptów zmieniających te priorytety i treść wiadomości o warningach. Dzięki temu powstały na przykład skrypty sprawdzające zgodność z MISRA. Aby używać PC-Lint, najlepiej go zintegrować z systemem buildowania. Pełna lista plików źródłowych powinna być przekazana jako argument linii komend razem z includami, definami i innymi flagami kompilacji. Program działa całkiem szybko.

CppCheck

Darmowe narzędzie, stworzone głównie z myślą o C++, ale może być używane również do C. Również można je konfigurować za pomocą skryptu i warto to zrobić, bo na domyślnych ustawieniach możemy zostać zaspamowani nieważnymi komunikatami. Na stronie projektu chwalą się, że dodali wsparcie dla MISRA, ale nie korzystałem z niego, więc nie wiem jak się sprawdza.

clang-tidy

Statyczny analizator C++ będący częścią kompilatora clang. Można go jednak używać niezależnie. Podobnie jak pozostałe narzędzia możliwa jest konfiguracja znajdowanych klas błędów. Ciekawą opcją jest możliwość automatycznego poprawiania znalezionych błędów. Oczywiście jak zwykle w przypadku takich gadżetów, warto później przejrzeć zmiany i zobaczyć, czy nie zrobił czegoś głupiego.

Formatowanie kodu

Toole do formatowania kodu wyłapują częste problemy ze spacjami na końcu linii, brak konsekwencji w używaniu tabów i spacji, czy nawiasów klamrowych. Możemy w tym zakresie korzystać z wsparcia IDE – w Eclipsie można zdefiniować styl, a następnie skrótem klawiszowym aplikować go na wskazanym fragmencie kodu. Jednak czasem przydają się narzędzia, które sprawdzą całą bazę kodu. Aktualnie w domowych projektach nie używam takich narzędzi, ale chcę zacząć. Moim wyborem najprawdopodobniej będzie clang-format, a jak będę chciał więcej opcji, użyję Uncrustify.

Vera++

Narzędzie o dosyć ograniczonych podstawowych możliwościach znajdowania i poprawiania błędów w stylu. Jego siłą jest możliwość pisania własnych skryptów w TCL mogących analizować i transformować kod.

clang-format

Podobnie jak clang-tidy jest częścią kompilatora clang, z której można korzystać niezależnie. Narzędzie automatycznie poprawia znalezione odstępstwa od zdefiniowanego stylu. Pożądany styl możemy zdefiniować jako jedną z wbudowanych opcji np. LLVM, Google, Mozilla, lub za pomocą pliku konfiguracyjnego. W internecie oczywiście krążą gotowe szablony dla popularnych stylów.

Uncruscify

To jest prawdziwy kombajn. Twórcy chwalą się, że można konfigurować ponad 600 opcji. Poza C i C++ wspiera również inne języki jak C# czy Java. Potrafi robić zaawansowane przekształcenia, jak dodawanie/usuwanie nawiasów i przeformatowywanie komentarzy. Wybór pożądanego stylu oczywiście odbywa się za pomocą pliku konfiguracyjnego.

Astyle

Kolejne bardziej rozbudowane narzędzie. Posiada wszystkie opcje, których oczekiwalibyśmy od formatera kodu. Podobnie jak inne programy z tej kategorii obsługuje pliki konfiguracyjne definiujące styl.

Pisanie skryptów

Czasem potrzebujemy skryptów do developmentu, albo buildowania. Mogą nam posłużyć do generowania kodu, czy automatyzacji jakiś czynności podczas buildowania, walidacji, czy parsowania logów. Część z tych zadań mogą za nas zrobić nawet systemy buildowania takie jak CMake. Jednak czasem napisanie nawet małego skryptu może niesamowicie ułatwić nam pracę. Mamy tutaj dwie możliwości:

• Skrypty konsolowe np. Bash, Powershell. Wadą jest uzależnienie od konkretnego systemu operacyjnego. Często zdarza się, że development odbywa się na maszynach z Windowsem, a serwer CI stoi na Linuxie. Powinniśmy dążyć do buildowania tym samym skryptem niezależnie od systemu. Lepsza zatem jest druga opcja.
• Język skryptowy np. Python, Ruby. Daje on duże możliwości tworzenia własnych skryptów i nie jesteśmy zależni od systemu operacyjnego. Jednak musimy pamiętać, że dodajemy w ten sposób zależności od wersji języka i wykorzystywanych bibliotek.

Terminale portów szeregowych

Terminal bray++

Narzędzie wygląda jak żywy przykład, dlaczego inżynierowie nie powinni tykać się interfejsów użytkownika. Ogromna ilość przycisków i opcji, w której ciężko się odnaleźć. Szybko jednak okazuje się, że jego możliwości są po prostu fenomenalne. Poza zwykłym terminalem obsługującym tryb ASCII i HEX, posiada również wiele zaawansowanych funkcji takich jak macra wysyłające całe wiadomości – idealne przy testowaniu komunikacji, czy nawet skrypty symulujące interakcje – wysyła konkretne odpowiedzi na zadane zapytania.

RS232 data logger

Programik zapisujący logi z portu szeregowego bezpośrednio do pliku. Mimo, że terminal bray też ma taką opcję, tak samo jak na przykład PuTTy, lubię używać właśnie tego programu.

Wizualizacja pracy procesora

Programy z tej kategorii pozwalają podejrzeć działanie procesora w formie graficznej. Może być to podgląd zmiennej w czasie, czy schemat komunikacji między wątkami. Patrząc na dema tych narzędzi wydaje się, że są takie super i niesamowicie przyspieszają dewelopment. W praktyce jednak okazuje, że bardzo rzadko są potrzebne i inne sposoby debugowania po prostu są efektywniejsze.

STM Studio

Programik pozwalający podglądać przez debugger zmienne w czasie działania programu. Wskazujemy adres w pamięci i program w czasie rzeczywistym rysuje nam zmienną na wykresie. Możemy również śledzić maksymalną i minimalną wartość lub zapisywać wartość z kolejnych chwil czasu do pliku.

FreeRTOS Tracealyzer

Płatny program wspomagający debugowanie we FreeRTOSie. Widziałem go kiedyś na targach Electronica 2012. Wtedy zrobił na mnie ogromne wrażenie. Można było zobaczyć sobie wszystkie taski, kolejki, mutexy, flow programu, czy logi. Można było prezentować dane na różnych wykresach. Wydawało się, że taki program jest w stanie znacznie ułatwić development. Korzystałem jednak z niego przez jakiś czas i okazało się, że w większości przypadków problemy rozwiązywałem konwencjonalnymi metodami, a z tych wykresów nie dowiadywałem się żadnych nowych rzeczy.