Dlaczego OpenOCD?!?

Na rynku istnieje wiele komercyjnych środowisk, niektóre nawet w darmowych wersjach. Jest tylko jeden problem… Mianowicie istnieją dwie możliwości… Pierwsza jest taka, że środowisko jest płatne i obsługuje większość JTAG’ów na rynku, a druga jest taka, że środowisko jest darmowe i obsługuje tylko jeden konkretny JTAG sprzedawany za ciężkie pieniądze przez twórców tego środowiska. Tak więc nie wygląda to zbyt kolorowo. Nie mniej jednak nie jest, aż tak źle. Tak samo, jak w przypadku kompilatorów i IDE (zapraszam do posta gościnnie napisanego przez mojego kolegę: Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3) trzeba będzie się trochę natrudzić i nie wszystko będzie podane na tacy, ale można mieć całkiem sprawny aparat do debugowania całkowicie za darmo. Jak zapewne się już domyślacie mowa tutaj o OpenOCD. No to zaczynamy :)

Cygwin

Podstawowy problem (a może raczej wyzwanie :P) z OpenOCD polega na tym, że trzeba je sobie skompilować :) Jako, że będziemy to robić pod windowsem, będziemy potrzebować cygwina, więc musimy sobie go najpierw ściągnąć (np. z oficjalnej strony: http://cygwin.com/, a dokładnie stąd) i zainstalować. Instalacja jest dość prosta, a po kolei wygląda to tak:

• uruchamiamy plik setup.exe
• wybieramy instalację z internetu
• wybieramy ścieżkę instalacji cygwina (najlepiej zostawić domyślną C:\cygwin), tutaj pragnę zwrócić uwagę na to, by przy instalowaniu wszelkiego rodzaju kompilatorów i narzędzi konsolowych raczej unikać ścieżek zawierających spacje, gdyż może to przysporzyć wielu problemów
• wybieramy katalog do którego instalator ściągnie sobie pliki
• wybieramy połączenie bezpośrednie, czyli „Direct Connection”
• wybieramy serwer z którego chcemy ściągnąć cygwina
• gdy otworzy nam się okno wyboru pakietów które chcemy zainstalować musimy dodatkowo zaznaczyć (warto skorzystać z „szukaczki”):
  • autoconf: Wrapper scripts for autoconf commands
  • automake: Wrapper scripts for automake and aclocals
  • gcc: C compiler upgrade helper
  • libtool: A shared library generation tool
  • make: The GNU version og the ‘make’ utility
• klikamy „Dalej” i następnie „Install”

Licencje i takie tam…

Jak mamy już zainstalowanego cygwina to zanim się weźmiemy do konkretnej roboty to jeszcze chciałem napisać parę słów co i jak. W tym artykule chcę opisać kompilowanie OpenOCD ze sterownikami JTAG’ów opartych o układy firmy FTDI. Generalnie istnieją dwie drogi. Jako, że OpenOCD jest na licencji GPL to każdy rozpowszechniany program, który korzysta z OpenOCD musi mieć całkiem otwarte źródła. Aby spełnić to wymaganie do kompilacji musimy użyć sterowników o otwartym kodzie. Jedyne znane mi sterowniki o otwartym kodzie obsługujące układy FTDI, to LibUSB (wersja win32: http://libusb-win32.sourceforge.net/) w połączeniu z biblioteką libftdi (http://www.intra2net.com/en/developer/libftdi/). Tak skompilowaną wersję można rozpowszechniać, bez żadnych problemów i możecie ją ściągnąć np z blogu Freddiego: http://www.freddiechopin.info/). Druga opcja to użycie oficjalnych sterowników i biblioteki firmy FTDI, czyli ftd2xx. Jedyny problem z tą biblioteką jest to, że producent udostępnia ją tylko w wersji skompilowanej, nie pokazując źródeł. Co pociąga za sobą fakt, że tak skompilowane OpenOCD nie spełnia warunku, że cały kod produktu musi być otwarty i udostępniony. Tak więc nie można rozpowszechniać tak skompilowanego programu. Nie oznacza to natomiast, że nie można sobie skompilować OpenOCD z taką biblioteką. Dlatego też opiszę dokładnie jak to zrobić, tak by każdy mógł sobie skompilować kod we własnym zakresie. No to na tyle ględzenia i lecimy dalej.

Instalujemy sterowniki do JTAG’a

Najpierw musimy ściągnąć i zainstalować sterowniki do urządzenia i dopiero później możemy kompilować bibliotekę. Trochę to dziwne, ale podczas konfiguracji biblioteki skrypty do tego stworzone testują jakoś tą bibliotekę i jeżeli nie ma w tej chwili zainstalowanych sterowników test się nie powiedzie i nie będzie można ukończyć kompilacji. Najdziwniejsze jest to, że przy kompilacji z bibliotekami libftdi nie ma żadnego testu tylko wszystko ładnie idzie :/ Sterowniki ściągamy z  ze strony producenta ukladów (http://www.ftdichip.com/, dokładnie stąd – obecnie jest to wersja 2.06.02). Musimy je teraz wypakować, ale żeby łatwiej było nam się później (przy kompilacji) dogadać co do ścieżek to proponuje stworzyć katalog „C:\tmp” do niego wypakować zawartość archiwum, a następnie zmienić nazwę wypakowanego katalogu z „CDM 2.06.00 WHQL Certified” na „ftd2xx”. Skoro już wzięliśmy się za ściąganie to odrazu proponuję pobrać źródła OpenOCD (stąd) w tym momencie najnowszą wersją jest: „openocd-0.4.0„, jest to co prawda wersja RC, ale działa całkiem sprawnie, więc nie widzę powodów by korzystać ze starszej (jeżeli jednak ktoś bardzo chce, może pobrać starszą wersję – cała procedura kompilacji wygląda dokładnie tak samo). No więc ściągamyOpenOCD i rozpakowujemy do naszego folderu „C:\tmp”. Dla jasności obok przedstawiam jak powinno wyglądać drzewo katalogów. Potrzebujemy jeszcze jednego małego programiku, do wygenerowania plików inf sterowników. Programik nazywa się FT_INF i możemy go pobrać ze stronki FTDI (http://www.ftdichip.com/Resources/Utilities.htm). Programik pobieramy, rozpakowujemy gdziekolwiek, instalujemy i uruchamiamy. Naszym oczom ukazuje się tajemnicze okno w którym nie wiemy co wpisać :P Ale spokojnie, zaraz będziemy wiedzieli. Jedyne co musimy wiedzieć to jakiego JTAG’a mamy, jeżeli wiemy to szukamy w katalogu „C:\tmp\openocd-0.4.0-rc2\tcl\interface” pliku *.cfg odpowiedniego dla naszego JTAG’a. W moim przypadku to „jtagkey.cfg” (Posiadam JTAG’a projektu Freddiego Choppina, opartego o Amontec JTAGkey). Otwieramy ten plik i patrzymy co  jest w nim popisane. U mnie wygląda to tak jak na rysunku. Teraz wystarczy przepisać odpowiednie informacje do okienka programu FT_INF. Jak to wygląda u mnie, możecie zobaczyć na screenie. Układ (pole chip) należy wybrać zgodnie ze screenem, Następnie wpisać odpowiednie dane w sekcji „Vendor ID / Product ID” zgodnie z plikiem *.cfg. Później klikamy „>>” aby dodać nasze urządzenie do list. Musimy jeszcze wskazać pliki „ftdibus.sys” oraz „ftser2k.sys” które znajdują się w katalogu ze sterownikami, a dokładnie: „C:\tmp\ftd2xx\i386″ (lub „C:\tmp\ftd2xx\amd64″ w zależności od architektury).

Ustawiamy także folder „Output” najlepiej na „C:\tmp\ftd2xx” i klikamy „Generate Files”. Program spyta czy nadpisać pliki *.ini, oczywiście się zgadzamy. Po tych operacjach mamy już gotowe sterowniki do swojego JTAG’a w katalogu „C:\tmp\ftd2xx”. Tak, więc podłączamy JTAG’a i instalujemy stworzone przed chwilą sterowniki. Jeżeli wszystko pójdzie dobrze możemy kontynuować. Kolejnym krokiem będzie już kompilacja.

Czas na kompilację

Ten etap wbrew pozorom jest chyba najprostszy :) Odpalamy więc konsole cygwina (przy instalacji na pewno wepchał nam jakiś skrót do menu start) i przechodzimy do naszego katalogu, a dokładnie do katalogu z OpenOCD wpisując komendę:

cd /cygdrive/c/tmp/openocd-0.4.0-rc2

po czym wywołujemy plik konfigurujący komendą:

./configure --enable-maintainer-mode --disable-werror --disable-shared
--enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/cygdrive/c/tmp/ftd2xx

chwile to potrwa, więc musimy być cierpliwi. Jeżeli w czasie konfigurowania dostaniemy komunikat taki jak na screenie,

oznacza to, że nie zainstalowaliśmy dobrze sterowników przed rozpoczęciem procesu konfigurowania (to muszą być dokładnie te same sterowniki – ta sama wersja biblioteki – te które instalujemy i te które używamy do kompilacji) Natomiast jeżeli wszystko poszło jak należy odpalamy komendę:

make

i znów czekamy :) … aż się skompiluje. Jeżeli wszystko się uda to w katalogu „C:\tmp\openocd-0.4.0-rc2\src” znajdziemy plik „openocd.exe”. Teraz wystarczy zebrać wszystko razem i mamy gotowe skompilowane OpenOCD. No więc do dzieła. Tworzymy sobie gdzieś katalog „OpenOCD0.4.0rc2″, w nim tworzymy katalog „bin” do którego kopiujemy plik „openocd.exe”, oraz pliki „cygwin1.dll”, oraz „cyggcc_s-1.dll” z katalogu „bin” cygwina (najczęściej C:\cygwin\bin), aby uniezależnić się od cygwina. Dodatkowo do katalogu „OpenOCD0.4.0rc2″ kopiujemy całą zawartość folderu „C:\tmp\openocd-0.4.0-rc2\tcl”. To wszystko. Katalog „OpenOCD0.4.0rc2″ zawiera teraz wszystko co jest potrzebne do działania OpenOCD. Wystarczy go przenieść w dowolne miejsce na dysku.

A teraz podpinamy do Eclipse

Zanim zaczniemy proponuję postawić sobie Eclipse’a i CodeSourcery zgodnie z opisem we wcześniejszym wpisie (Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3). Jeżeli mamy już postawione IDE z podpiętym kompilatorem, to możemy zabierać się za kolejny ważny element Toolchain’u, czyli Debugger.

Pierwszym krokiem jest instalacja odpowiednich wtyczek do Eclipse’a pozwalających używać debuggera sprzętowego i OpenOCD. Pierwsza z nich to Eclipse C/C++ GDB Hardware Debugging. Aby go zainstalować wybieramy Help->Install New Software.Możemy go pobrać z oficjalnego update site’u Eclipse’a. Aby to zrobić wpisujemy w pole „Work with” http://download.eclipse.org/tools/cdt/releases/galileo i zaznaczamy plugin, aby go zainstalować (znajduje się on w kategorii „CDT Optional Features”). Następnie postępujemy zgodnie ze wskazówkami, co praktycznie sprowadza się do klikania „Next”. Kolejny plugin to Zylin Embedded CDT .Update site tego plugina to: http://opensource.zylin.com/zylincdt. Zaznaczamy plugin i kontynuujemy instalacje. Oczywiście godzimy się na niepodpisane oprogramowanie i restartujemy eclipse zgodnie z sugestią.

Gdy mamy zainstalowane obie wtyczki możemy przystąpić do podpinania OpenOCD. Otwieramy sobie jakiś projekt (proponuję przykładowy z wpisu Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3), lub tworzymy nowy. Następnie klikamy w menu „Run->External Tools->External Tools Configuration…”. Wybieramy „New launch configuration”, by dodać nowe narzędzie. Następnie musimy wpisać nazwę narzędzia (np. OpenOCD), ścieżkę do pliku openocd.exe, oraz parametry z jakimi zostanie odpalony program. Jako parametry musimy przede wszystkim podać pliki konfiguracyjne, odpowiednie dla mikrokontrolera z którym się łączony, oraz JTAG’a. Wpisane przeze mnie parametry przedstawiam na screen’ie. Na pozostałych zakładkach nie musimy nic zmieniać. Gotowe :) Teraz podłączamy JTAG’a do komputera i do debugowanego układu i odpalamy narzędzie np. poprzez menu „Run->Configuration Tools”. Jeżeli wszystko się powiedzie powinniśmy w konsoli zobaczyć komunikat podobny jak na screen’ie.

Jeżeli OpenOCD już działa możemy się zabrać za stworzenie odpowiedniej konfiguracji do debugowania. Klikamy „Run->Debug configurations…”. Tworzymy nową konfigurację, podobnie jak poprzednio (ja nadałem jej nazwę gbd(flash)). Następnie ustawiamy odpowiednie parametry. Na zakładce „Main” wybieramy projekt, który chcemy debugować klikając „Browse…” obok pola „Project”. Przechodzimy do zakładki „Debugger”, gdzie musimy podać ścieżkę do gdb pochodzącego z Code Sourcery, oraz zmienić numer portu na 3333. Później ustawiamy odpowiednie opcje na zakładce „Startup” zgodnie ze screen’em.

Następnie tworzymy identyczną konfigurację tylko dopisujemy jeszcze komendę load na zakładce „Startup” w polu poniżej opcji „Halt”. Ta konfiguracja pozwoli nam załadować program do pamięci mikrokontrolera.

Aby debugować program musimy najpierw włączyć OpenOCD, robimy to jednorazowo. Później wybieramy odpowiednia konfigurację debugowania – samo debugowanie, lub debugowania z ładowaniem programu do pamięci. Samego debugowania w Eclipse nie będę opisywał, gdyż można znaleźć wiele informacji na ten temat w internecie.

Źródła:

• http://www.plugcomputer.org/plugwiki/index.php/Main_Page
• http://forum.sparkfun.com/viewtopic.php?t=11221&postdays=0&postorder=asc&start=0&sid=89cf3e590ac8185041bdbcc7ec2732e4

Wprowadzenie

Celem dzisiejszego wpisu jest prześledzenie i opisanie kroków potrzebnych do konfiguracji Środowiska Eclipse do współpracy z pakietem CodeSourcery Lite. Efektem tego połączenia jest w pełni darmowe (open-source) środowisko programistyczne.

Instalacja Code Sourcery Lite

Na stronie http://www.codesourcery.com/ znajdujemy wersję Lite pakietu.  Ponieważ nawigacja w poszukiwaniu pakietu w wersji darmowej jest jak zwykle „super łatwa” podaję bardziej bezpośredni link do pobierania: http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite

Po pobraniu i uruchomieniu aplikacji (w moim przypadku arm-2009q3-68-arm-none-eabi.exe) . W przypadku pakietu Lite wybór wersji (Typical/Custom etc.) jest bez znaczenia. Warto przy wybieraniu ścieżki unikać spacji – proponowane Program Files sprawia problemy w najmniej przewidywalnym momencie. Instalator proponuje nam również dodanie swojego katalogu binarek do zmiennej PATH – warto mu na to pozwolić, gdyż i tak konieczna będzie jego obecność w tej zmiennej. Alternatywa jest ręczna modyfikacja PATH za pomocą ustawień komputera, lub stworzenie pliku bat który modyfikuje PATH i uruchamia nasze środowisko. Biorąc pod uwagę iż pakiet CodeSourcery składa się z plików nie wprowadzających konfliktów nazw (np. cs-make, arm-none-eabi-gcc) zostawienie tego zadania instalatorowi to najlepsze wyjście. Program tworzy niezliczoną ilość ikon, więc najlepiej skierować te zapędy w stronę menu start :)

Instalacja Eclipse

Kolejny krok to pobranie Eclipse IDE ze zintegrowanymi narzędziami do programowania w C/C++. Dokładniejszy opis instalacji tego programu (m.in. instalacja wymaganej Javy, dotyczący użycia MinGW, a nie CodeSourcery) w środowisku Windows można znaleźć np. w tym wpisie: Eclipse CDT – środowisko C/C++ (nie należy się nim w tym przypadku dokładnie kierować, aczkolwiek pozwala poznać podstawowe informacje na temat konfiguracji wspomnianego IDE). W tym przypadku interesuje nas tylko środowisko, więc po prostu pobieramy i rozpakowujemy w wybrane miejsce. Po rozpakowaniu eclipse znalazł się w C:\eclipse, a skrót do eclipse.exe utworzyłem dla wygody na Pulpicie. Po uruchomieniu zostaniemy poproszeni o wybór Workspace – tradycyjnie przypominam o unikaniu spacji.

Wtyczka zarządzająca projektami

Za pomocą wymienionych wyżej narzędzi można już tworzyć projekty – jednak ręczna edycja plików makefile nie jest najwygodniejszym rozwiązaniem. Dlatego kolejnym etapem jest instalacja wtyczki która będzie je automatycznie tworzyć i zarządzać projektem.

Z pośród niewielu istniejących rozwiązań wybrałem GNU ARM Eclipse plugin. Aby go zainstalować wybieramy Help->Install New Software. Update site tego plugina to: http://gnuarmeclipse.sourceforge.net/updates, taki adres wklejamy w „Work with”. Należy zwrócić uwagę na odznaczenie „Group items by category”, ponieważ nasz plugin nie ma przypisanej kategorii. Zaznaczamy plugin  kontynuujemy instalacje. Oczywiście godzimy się na niepodpisane oprogramowanie i restartujemy eclipse zgodnie z sugestią.

Tworzenie pierwszego projektu

Projekty dla platformy ARM są typowymi projektami C/C++. Wybieramy więc File->New->C++ Project. Po wpisaniu dowolnej nazwy wybieramy typ projektu – ARM Cross Target Application->Empty Project. W polu Toolchains wybieramy nasze Sourcery G++ Lite. Kolejnym etapem jest wybranie dwóch możliwych wersji w których nasz program będzie kompilowany – debug, przystosowanej do pracy z JTAG i debugowania na platformie docelowej, i release, działającej z pełną wydajnością ale pozbawionej powyższych możliwości.

Kolejnym etapem jest zebra

nie podstawowych elementów potrzebnych do kompilacji i linkowania. W zależności od użytego mikrokontrolera mogą występować różnice w poniższych plikach. Te zostały przygotowane dla uC STM32F103RB.

• skryptu linkera (pliku o rozszerzeniu *.ld, zawierającym informacje jak „poskładać” kolejne pliki *.o z kompilatora w nasz plik wynikowy – czyli elf /hex)
  plik ten zawiera informacje o rozmieszczeniu danych w pamięci, oraz przede wszystkim informacje o samej pamięci – początek, koniec pamięci RAM, ROM etc.
  Obszerną dokumentacje możemy znaleźć w plikach zainstalowanych z CodeSourcery (./share/doc/arm-arm-none-eabi/pdf/ld.pdf)
• pliku startup (czyli pliku który po skompilowaniu będzie uruchamiany po zresetowaniu procesora. Jego zawartość to Reset_Handler, zajmujący się inicjalizacją zmiennych, kopiowaniem danych FLASH->RAM dla zmiennych zainicjalizowanych, oraz uruchomieniem konstruktorów obiektów globalnych (tylko C++), funkcji main, a na koniec destruktorów obiektów globalnych(tylko C++)).
  Z uwagi na złożoność asemblera procesorów Cortex-M3 warto skorzystać z gotowego pliku – np. zamieszczonego tutaj, stworzonego przez Freddiego Chopina.
• Informacje o położeniu głównego stosu i o wektorach przerwań
  Mikrokontroler  Cortex-M3 zaraz po uruchomieniu ładuje do rejestru MSP (Main Stack Pointer) wartość spod adresu 0×00000000.  Kolejna niezbędna informacja to adres funkcji inicjalizującej – Reset_Handler pochodzącej z naszego startup’u. Adres ten musi znaleźć się pod adresem 0×00000004. Pozostałe adresy w tym wektorze to procedury obsługi przerwań. W naszym przypadku wykorzystaliśmy plik vectors.c, również stworzony przez Freddiego. Poprawiono tylko nazwy metod – teraz są w pełni zgodne (-; z standardem CMSIS.

Przydatne są rownież biblioteki – przede wszystkim CMSIS zawierający define’y rejestrów naszego mikrokontrolera, oraz biblioteka peryferiów STM32F10x_StdPeriph_Lib

Wszystkie powyższe pliki można pobrać klikając tutaj – Podstawowe pliki projektu ARM Cortex-M3 STM32

W tym momencie zakładam, że w Eclipse wyświetla nam się projekt C++, pliki po pobraniu zostały rozpakowane i przeciągnięte do naszego projektu. W tej chwili okno mojego projektu wygląda tak jak na obrazkach po lewej. Oczywiście samo dodanie plików do projektu to zbyt mało aby móc zacząć pracować nad samym programem. W celu czysto doświadczalnym w tej chwili stwórzmy plik main.cpp (File->New->Source File, zwróćmy uwagę aby umieścić ten plik w głównym katalogu projektu). Jedynym plikiem związanym z naszymi bibliotekami jaki będziemy include’ować jest plik stm32f10x_conf.h, znajdujący się w głównym katalogu projektu. Za jego pośrednictwem uzyskamy dostęp do całej reszty biblioteki pobranej ze strony ST. Podsumowując, stworzony plik main cpp wygląda teraz tak:

/*
 * Podstawowy plik wykorzystujący biblioteki dla STM32
 */
#include
#include 

int main() {

	return 0;
}

Jego kompilacja generuje błędy, związane z includowaniem plików nie podając ich pełnych ścieżek. Na szczęście nazwy plików są na tyle jednoznaczne i unikalne ze można je bez obaw dodać do domyślnie w danym projekcie przeszukiwanych ścieżek (odpowiednik przełącznika -I przy kompilacji). Ponieważ przyszłe projekty chcemy stworzyć poprzez proste skopiowanie bieżącego „szablonu”, warto podać ścieżki w takiej formie aby nie nastręczało to trudności. W tym celu często będziemy korzystać z ręcznie wpisanych ścieżek, gdyż te uzyskane poprzez wybranie odpowiednich katalogów zawierają nazwę projektu.

Aby edytować wspomniane ścieżki oraz zmieniać ustawienia kompilatora/linkera należy kliknąć w Project->Properties, następnie wybrać C/C++ Build -> Settings. Na wstępie z bieżącej konfiguracji Debug warto przełączyć się w [ All configurations ], pozwoli to nie dublować opisanej niżej pracy.

• Ustawienia preprocesora C. W zakładce ARM Sourcery Windows GCC C Compiler->Preprocessor dodajemy symbole (plus przy opcjach -D): USE_STDPERIPH_DRIVER (jeśli chcemy używać bibliotek stm32) oraz STM32F10X_MD (obowiązkowo, definiujemy rodzaj mikrokontrolera – Medium Density Line w tym wypadku). Ustawienia które tu podajemy umożliwiaja nie edytowanie bibliotecznego pliku stm32f10x.h.
• Ustawienia kompilatora C. W zakładce ARM Sourcery Windows GCC C Compiler->Directories dodajemy (każdą osobno) następujace ścieżki:
  „${CWD}/../”, „${CWD}/../Libraries/CMSIS/Core/CM3″ oraz „${CWD}/../Libraries/STM32F10x_StdPeriph_Driver/inc”. Zmienna CWD czyli Current Working Directory to przy kompilacji zawsze katalog Debug/Release projektu, więc taka konstrukcja pozwala zawsze skorzystać z właściwego katalogu.
  Z kolei w zakładce ARM Sourcery Windows GCC C Compiler->Optimization zaznaczamy Function sections (-ffunction-sections) i Data Sections  (-fdata-sections). Moja wersja wtyczki posiada błąd – zamiast Data Sections powtórzono Function Sections.
• Powyższe kroki aplikujemy również dla kompilatora C++ (analogiczne zakładki w kategorii ARM Sourcery Windows GCC C++ Compiler)
• Skrypt linkera. Plik ten (stm32f103rb_rom.ld) znajduje się w katalogu Setup. Aby był używany  Po przełączeniu wybieramy ARM Sourcery Windows GCC C++ Linker -> General i w pole „Script file -T” wpisujemy wpisujemy „..\Setup\stm32f103rb_rom.ld”. Dodatkowo zaznaczamy „Remove unused sections (-XLinker –gc-sections)” (pozwoli to usunąć zbędne sekcje które powstają z każdej kompilowanej a nie używanej funkcji).

Po zastosowaniu powyższych ustawień będzie można budować obie wersje projektu. Tworzenie przy kompilacji sekcji dla każdej funkcji, i usuwanie zbędnych przy linkowaniu gwarantuje nam rozsądną wielkość pliku wynikowego, także w trybie Debug – dzięki temu bez problemu przeprowadzimy testy za pomocą JTAGa na docelowym układzie.

Po zastosowaniu powyższych ustawień budowanie projektu (Ctrl+B) powinno przebiec bez zakłóceń.

Pliki projektu wraz z ustawieniami, do użycia np. na innym komputerze można wyeksportować. Wybieramy File->Export.  Następnie zaznaczamy General->Archive File i przechodzimy dalej. Zgodnie z własnym uznaniem wybieramy nazwę i rodzaj tworzonego archiwum, po czym kończymy eksport.

Podsumowanie

Stworzyliśmy szablon projektu, integrując pliki dostarczone przez STMicroelectronic, z plikami z strony www.freddiechopin.info. Takie połączenie to solidna podstawa do budowania dowolnej wielkości aplikacji an platformę STM32. Gotowy szablon można pobrać stąd: Szablon projektu dla Cortex-M3 STM32 F103RB