Nie tak dawno temu opisywałem szablon projektu na STM32F4, którego używam. Dzisiaj omówię konfigurację środowiska Eclipse do pracy z projektem pod Windowsem. Aby uruchomić projekt, będziemy potrzebować:

• kompilator ARM
• debugger – OpenOCD
• MinGW
• Środowisko Eclipse C/C++

Kompilator ARM i debugger

Kompilator ARM i OpenOCD polecam ściągnąć ze strony www.freddiechopin.info. W momencie pisania tego artykułu najnowsza wersja kompilatora to 6.3 dostępna na stronie: link, a OpenOCD to 0.10.0: link. Ściągnięte pliki należy rozpakować na dysku. Ścieżkę <folder gdzie wypakowaliśmy kompilator>\arm-none-eabi-gcc-6.3.0-170107\bin należy dodać do zmiennej środowiskowej PATH. Jeżeli operacja przebiegła pomyślnie, po otwarciu konsoli i wpisaniu

 arm-none-eabi-gcc --version

Powinien wyświetlić się tekst:

arm-none-eabi-gcc (bleeding-edge-toolchain) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

MinGW

MinGW to zestaw narzędzi tworzących środowisko programistyczne dla Windowsa. Z tego pakietu będą nas interesować dwa narzędzia: kompilator gcc na PC, którego będziemy używać do kompilacji unit testów, oraz pakiet msys zapewniający zestaw komend linuxowych takich jak mkdir czy make. Po uruchomieniu instalatora należy wybrać odpowiednie pakiety i zainstalować je. Po instalacji należy sprawdzić, czy ścieżki do <ścieżka instalacji>\MinGW\bin i <ścieżka instalacji>\MinGW\msys\1.0\bin są dodane do zmiennej środowiskowej PATH.

Eclipse

Środowisko Eclipse będzie służyło nam jako edytor tekstu. Tak naprawdę mając narzędzia do kompilacji, które opisałem w poprzednich rozdziałach możemy użyć jakiegokolwiek edytora tekstu. Eclipse jednak ma kilka zalet:

• Wbudowany analizator kodu podkreśli nam błędy składniowe i podpowie nazwy funkcji czy zmiennych.
• Jeżeli chcemy zmienić nazwę funkcji, Eclipse podmienia ją we wszystkich plikach w projekcie.
• Kompilację projektu możemy uruchomić wewnątrz Eclipse, a miejsca wystąpienia warningów i errorów zostaną zaznaczone.
• Środowisko posiada również wsparcie dla debuggera gdb.

Tutaj ważna uwaga – nie ściągamy najnowszej wersji Eclipse Neon, zamiast tego starszą wersję Eclipse Mars 2. W nowszej wersji nie działa plugin do podglądania rejestrów peryferiów, którego konfigurację tutaj opiszę. Jest za to alternatywne rozwiązanie – GNU ARM Eclipse. Bawiłem się nim przez chwilę i na razie nie przypadło mi do gustu, może opiszę to dokładniej w osobnym wpisie.

Ustawienia projektu

Kiedy mamy już działające środowisko, możemy założyć nowy projekt i skopiować do niego szablon. W tym celu wybieramy polecenie File->New->C Project, a w otwartym oknie wybieramy Makefile project i nadajemy nazwę projektu i klikamy Finish. Kroki te zostały przedstawione na poniższych screenach.

Kiedy mamy już utworzony nowy projekt, kopiujemy tam pliki szablonu na STM32 dostępnego pod linkiem. Następnie musimy pogrzebać trochę w ustawieniach konfiguracyjnych. W tym celu klikamy prawym przyciskiem na projekt i wybieramy opcję Properties. Pierwszą rzeczą jaką zrobimy jest dodanie nowej konfiguracji builda. Domyślnie Eclipse utworzyło konfigurację wywołującą polecenie make all do builda i make clean do cleana. Dodamy nową konfigurację, która wykona build targetu main_program. Jeżeli chcemy z Eclipse uruchamiać kompilację innych targetów np. unit testów albo testów hw musimy powtórzyć tą operację dla każdego targetu.

Dodawanie nowego targeta kompilacji

W oknie Properties wybieramy z lewej strony C/C++ Build i klikamy przycisk Manage Configurations… w nowym oknie wybieramy nazwę naszego targetu. Następnie w liście rozwijanej Configuration wybieramy nowo utworzony target i przechodzimy do zakładki Behavior. Tam na dole w polu Build wpisujemy nazwę targetu kompilacji dla make, w tym przypadku będzie to main_program. Możemy tam dodać jeszcze dodatkowe parametry dla komendy make. W polu Clean wpisujemy analogicznie nazwę targeta clean dla naszego builda.

Konfiguracja Binary Parser

Następnie po lewej stronie w grupie C/C++ Build wybieramy pole Settings i w zakładce Binary Parsers zaznaczamy opcję GNU Elf Parser. Na dole w polach addr2line Command i c++filt Command dodajemy ścieżki do narzędzi o tych samych nazwach w plikach binarnych naszego kompilatora. Pliki te powinny znajdować się w folderze <ścieżka kompilatora>\arm-none-eabi-gcc-6.3.0-170107\bin. Dzięki skonfigurowaniu tej opcji, Eclipse będzie potrafił czytać plik wynikowy kompilacji .elf i będzie potrafił między innymi wskazywać adresy w pamięci dla funkcji i zmiennych.

Konfiguracja ścieżek do includów

Ostatnią rzeczą, jaką należy skonfigurować, są ścieżki do includów. Dzięki temu Eclipse będzie wiedział, gdzie szukać plików bibliotecznych zarówno projektowych, jak i domyślnych bibliotek kompilatora. Aby skonfigurować ścieżki, wybieramy po lewej stronie grupę C/C++ General, a tam Paths and Symbols. Wybieramy tam zakładkę Includes i po lewej stronie GNU C. Następnie klikamy przycisk Add… i dodajemy nasze ścieżki includów. Warto zaznaczyć opcję Add to all configurations, żeby nie trzeba było tej samej operacji powtarzać dla każdej konfiguracji. Dla ścieżek kompilatora klikamy przycisk File system… ścieżki, które należy dodać to: <ścieżka kompilatora>\arm-none-eabi-gcc-6.3.0-170107\arm-none-eabi\include oraz <ścieżka kompilatora>\arm-none-eabi-gcc-6.3.0-170107\lib\gcc\arm-none-eabi\6.3.0\include. Dla ścieżek lokalnych dla projektu, wybieramy przycisk Workspace…

To już cała konfiguracja projektu. Jeżeli wszystko przebiegło pomyślnie, możemy wybrać konfigurację main_program i wykonać build oraz clean z poziomu Eclipse. Poza tym jeżeli klikniemy CTRL + LPM na jakiś include w kodzie, powinien otworzyć się odpowiedni plik. Powinniśmy móc w ten sposób podejrzeć zarówno includy wewnątrz projektu, jak i biblioteki standardowe np. string.h.

Debugger

Jako debuggera będziemy używali OpenOCD.  Jest to program obsługujący wiele różnych sprzętowych debuggerów za pomocą tego samego interfejsu zgodnego z GDB. Eclipse zawiera obsługę debuggera GDB, który z kolei jest jednym z narzędzi kompilatorów GCC. Aby korzystać w Eclipse z dobrodziejstw sprzętowego debuggera takiego jak na przykład ST-Link należy sprawić, żeby komendy GDB z wtyczki w Eclipsie trafiły do OpenOCD, który będzie mógł odpowiednio sterować sprzętowym debuggerem. Będziemy mieli więc proces OpenOCD, który będzie działał sobie w tle i kiedy uruchomimy debug w Eclipse, GDB będzie się komunikowało z tym procesem pozwalając nam na debugowanie programu.

Pierwszym krokiem, jaki należy zrobić, jest ściągnięcie wtyczki C/C++ GDB Hardware Debugging będącej opcjonalną częścią pakietu CDT, czyli narzędzi C/C++ do Eclipse. W tym celu wybieramy opcję Help->Install New Software i obok pola Work with wybieramy Add… i dodajemy URL repozytorium CDT: http://download.eclipse.org/tools/cdt/releases/8.8.1

Po chwili powinna nam się załadować lista dostępnych dodatków, z której wybieramy C/C++ GDB Hardware Debugging, wybieramy Next i przechodzimy proces instalacji.

Konfiguracja OpenOCD

Kolejny krok to skonfigurowanie procesu OpenOCD. W tym celu otwieramy okno External Tools Configurations… i tworzymy nową konfigurację. Wybieramy nazwę dla naszej konfiguracji, klikamy przycisk Browse File System… i wybieramy tam ścieżkę do openocd.exe. Na dole w polu arguments podajemy ścieżki do plików konfiguracyjnych dla sprzętowego debuggera i wykorzystywanego procesora. Dla ST-LINK v2 i STM32F4 będą to:

-f interface/stlink-v2.cfg -f target/stm32f4x.cfg

Jeżeli korzystamy z innego procesora lub debuggera, należy wprowadzić ścieżkę do odpowiadającego mu skryptu konfiguracyjnego. Skrypty można znaleźć w katalogu <ścieżka do openocd>/openocd-0.10.0/scripts. W folderze interface są configi dla debuggerów, a w folderze target dla procesorów.

Jeżeli poprawnie skonfigurowaliśmy OpenOCD, po podłączeniu debuggera i odpaleniu procesu, w okienku Console powinien pojawić się tekst podobny jak poniżej.

Konfiguracja GDB

Przed konfiguracją GDB należy zainstalować plugin C/C++ GDB Hardware Debugging, co opisałem wyżej. Następnie wchodzimy do okna Debug Configurations…, wybieramy nową konfigurację GDB Hardware Debugging i uzupełniamy opcje. Najpierw wybieramy nazwę naszej konfiguracji w polu tekstowym na górze. Następnie przechodzimy do zakładki Main, gdzie wybieramy projekt i plik .elf. Warto tutaj też zaznaczyć opcję Disable Auto Build, żeby projekt nie kompilował się za każdym razem, gdy chcemy uruchomić debugger. W zakładce Debugger wybieramy ścieżkę do gdb dla naszego kompilatora i ustawiamy port, na którym GDB będzie komunikował się z OpenOCD. Domyślnie jest to port 3333. W zakładce Startup wybieramy komendy, które mają się wykonać po uruchomieniu GDB. Tutaj każemy GDB zresetować procesor, wgrać program na procesor i skoczyć do funkcji main. Dokładne opcje, które należy wpisać bądź wyklikać zostały przedstawione na screenie.

Nadeszła pora na uruchomienie debuggera. Najpierw musi być uruchomiony proces OpenOCD. Następnie uruchamiamy proces GDB. Powinien uruchomić nam się debugger i zatrzymać na pierwszej instrukcji w funkcji main.

Podgląd rejestrów procesora

Do podglądu rejestrów peryferiów procesora używam pluginu EmbSysRegView. Aby go zainstalować należy wejść do Help->Install new software… i wybrać plugina ze strony http://embsysregview.sourceforge.net/update, instalacja jest analogiczna jak opisana wcześniej instalacja wtyczki C/C++ GDB Hardware Debugging.

Po zainstalowaniu wtyczki, należy ją skonfigurować. W tym celu otwieramy Window->Preferences i dalej C/C++->Debug->EmbSys Register View. W tej zakładce wybieramy procesor, dla którego chcemy mieć podgląd rejestrów.

Następnie mając otwartą perspektywę Debug należy dodać zakładkę z widokiem rejestrów. W tym celu wchodzimy do Window->Show view->Other… i wybieramy Debug->EmbSys Registers. Wtedy powinien nam się dodać widok rejestrów. Domyślnie podgląd wszystkich rejestrów jest wyłączony. Aby włączyć konkretny rejestr, należy go wybrać z drzewa „folderów” i kliknąć 2 razy, żeby jego ikonka zmieniła się na zieloną.

Tutaj kolejna ważna uwaga – wtyczka nie rozpoznaje sama jaki procesor jest debugowany! Czyli jeżeli mamy wtyczkę ustawioną na STM32F4, a debugujemy STM32F1, będą nam się pokazywały wartości zmapowane na rejestry F4, czyli bzdury. Dlatego jeżeli przesiadamy się na projekt z innym procesorem, trzeba za każdym razem zmieniać ustawienia wtyczki.

Podsumowanie

Mam już w posługiwaniu się Eclipse pewną wprawę, dlatego ta konfiguracja wydaje mi się prosta i robię ją dosyć szybko. Jednak jak miałem ją opisać uświadomiłem sobie, że jest dosyć skomplikowana. Dlatego tak jak pisałem w artykule o szablonie projektu – nie polecam tego rozwiązania początkującym. Lepiej najpierw się nauczyć na jakimś IDE co robi wszystko za nas. Jeśli jednak piszemy więcej na STMy, warto wypróbować tę konfigurację, bo mamy kontrolę nad wszystkimi elementami.