Płytka jest bardzo prosta i nie zawiera praktycznie żadnych dodatkowych (prócz mikrokontrolera) układów zewnętrznych. Znajdziemy na niej mikrokontroler, złącze JTAG, rezonatory 8MHz i 32kHz, przycisk reset i odpowiednie kondensatory filtrujące. Dodatkowo na płytce umieściłem zestaw zworek które pozwalają w pewnym stopniu konfigurować układ. LSE i HSE odpowiedzialne są za podłączanie i odłączanie rezonatorów do i od procesora, zworki BOOT0 i BOOT1 odpowiadają za wybór trybu bootowania. Nie będę tu opisywał tych trybów, gdyż opis taki można znaleźć w datasheet’cie. Przewidziałem także dwie zworki, które umożliwiają podłączanie i odłączanie napięcia zasilającego z pin’ów VCC i VBAT. Pozwala to na testowanie układów z podtrzymaniem bateryjnym.

Dokumentacja do projektu:

Schemat ideowy

Schemat montażowy

TOP i BOTTOM – 1200 DPI (do transferu, albo metody fotochemicznej – UWAGA!!! warstwa TOP – lustrzane odbicie)

Lista komponentów

Nie wiem, czy dla kogokolwiek będzie interesujący taki moduł, ale może akurat :)

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

Ogólnie o STM32F

Szerokie portfolio sprawia, że naprawdę jest z czego wybierać. Oferowane mikrokontrolery posiadają na pokładzie rdzeń Cortex-M3 taktowany z częstotliwością aż do 72MHz, do 64kB pamięci SRAM, do 512kB pamięci FLASH, oraz są zasilane napięciem 2.0-3.6V (wejścia 5V tolerant), kompatybilne Pin-to-Pin i posiadają wiele peryferiów.  Układy dostępne są w wielu typach obudów takich jak: QFN, LQFP, oraz BGA.

Na cztery sposoby…

Cała oferta podzielona jest na 4 linie w zależności od przeznaczenia układu w którym ma pracować mikrokontroler. Poniżej przedstawiam tabelkę przygotowaną przez ST Microelectronics. Jak nietrudno zauważyć wszystkie układy są bardzo dobrze wyposażone i porażają możliwościami, tym bardziej jeżeli wziąć pod uwagę fakt, że ich cena jest niewiele wyższa niż cena dość popularnych w naszym kraju mikrokontrolerów AVR.

Access line – STM32F101

Najprostsza i najmniej wyposażona linia produktów. Przeznaczona przede wszystkim do prostych rozwiązań i stosowania w większości urządzeń. Posiada rdzeń taktowany z maksymalną częstotliwością 36MHz i jeden 12-bitowy przetwornik ADC (pomijając oczywiście resztę peryferiów które posiadają wszystkie mikrokontrolery z rodziny STM32F).

USB Access line -STM32F102

Linia podobna do poprzedniej z tym, że dodatkowo wyposażona w peryferia umożliwiające implementację protokołu USB – Full Speed 12Mbs, oraz możliwość generowania wymaganego sygnału zegarowego 48MHz wykorzystując wewnętrzną pętlę PLL.

Performance line – STM32F103

Linia o największych możliwościach. Dedykowana przede wszystkim do zastosowań przemysłowych i motoryzacyjnych. Przeznaczona do wymagających aplikacji, takich jak sterowniki silników, regulatory, układy przetwarzające dźwięk i obraz. Mikrokontrolery z tej linii taktowane są z częstotliwości aż do 72MHz, oraz posiadają na pokładzie peryferia takie jak: generatory PWM, sprzętowe sterowniki magistrali I2S, oraz CAN.

Connectivity line – STM32F105/STM32F107

Linia o możliwościach podobnych do Performance line. Główna różnica to brak generatorów PWM. W zamian za to posiadają USB OTG, a  niektóre z układów (te których nazwa zaczyna się od STM32F107)  posiadają peryferia obsługujące Ethernet MAC z dedykowanym kontrolerem DMA.  Przeznaczone są także do zastosowań w przemyśle, ale również do obsługi paneli sterujących, oraz prostych urządzeń audio.

A co w środku?!?

Mikrokontrolery rodziny STM32 są bardzo dobrze wyposażone w peryferia, dzięki czemu można je stosować w wielu aplikacjach. Uważam, że warto pokrótce opisać przynajmniej część z nich, tym bardziej, że posiadają one duże możliwości . Podczas opisu skupię się przede wszystkim na peryferiach układów z linii Performance.

Nested vectored interrupt controller (NVIC)

Nowy kontroler przerwań obsługuje:

• aż do 43 maskowalnych przerwań o 16 poziomach priorytetów
• bardzo krótkie i przewidywalne czasy obsługi przerwań
• wywłaszczanie przerwań
• obsługa przerwań o wyższym priorytecie w trybie late arrival (gdy przerwanie o wyższym priorytecie przyjdzie w momencie rozpoczynania obsługi przerwania o niższym priorytecie, rozpoczynanie obsługi przerwania o mniejszym priorytecie zostaje wstrzymane i obsługiwane jest przerwanie o wyższym priorytecie)
• wsparcie dla tail-chaining (ciągłe obsługiwanie zakolejkowanych przerwań, ze skróceniem czasu ich podejmowania – ilość cykli wymaganych do podjęcia kolejnych przerwań, jest mniejsza niż w przypadku podjęcia jednego przerwania)
• automatyczne zachowywanie i odtwarzanie kontekstu, przy wchodzeniu i wychodzeniu z procedury obsługi przerwania
• dużo łatwiejsza programowa implementacja wektora funkcji obsługi przerwań

External interrupt/event constroller (EXTI)

Kontroler zdarzeń i przerwań zewnętrznych posiadający 19 linii reagujących na zbocze. Każda linia może być niezależnie konfigurowana (wyzwalanie zboczem rosnącym/opadającym/oba), oraz niezależnie maskowana. Do 16 linii kontrolera można podłączyć aż do 80 zewnętrznych portów wejścia/wyjścia (GPIO).

Boot modes

Dostępne sa 3 tryby bootowania:

• z pamięci FLASH użytkownika
• z pamięci systemu (System Memory)
• z wewnętrznej pamięci SRAM

Program bootloader umieszczony jest w pamięci systemu i umożliwia programowanie pamięci FLASH poprzez interfejs USART1.

Power supply supervisor

Mikrokontrolery STM32F posiadają wbudowany układ power-on reset (POR)/power-down reset (PDR), który odpowiada za poprawne wystartowanie procesora przy napięciach już od 2V. Zapewnia także utrzymywanie mikrokontrolera w trybie Reset gdy napięcie zasilające jest niższe niż wyznaczony próg, dzięki temu nie jest wymagany zewnętrzny układ resetu. Układ posiada także programowalny układ detekcji napięcia (PVD), który nieustannie monitoruje napięcie zasilania i może generować przerwania kiedy napięcie spadnie poniżej ustalonego poziomu. Pozwala to na podjęcie odpowiednich działań, lub wygenerowanie ostrzeżenia.

Low-power modes

Linia Performance obsługuje 3 tryby obniżonego poboru mocy, co pozwala osiągnąć bardzo dobry kompromis między niskim poborem mocy, a krótkim czasem wybudzania.

• Sleep mode – w tym trybie procesor jest uśpiony, ale wszystkie peryferia działają i są w stanie wybudzić procesor, gdy tylko nadejdzie przerwanie
• Stop mode – ten tryb charakteryzuje się prawie najmniejszym poborem mocy. Wyłączony jest wówczas zarówno procesor, jak i większość peryferiów, łącznie z tymi generującymi sygnały zegarowe – PLL, HSI, HSE. Podtrzymywana jest tylko zawartość pamięci SRAM. Wybudzić procesor z tego trybu może przerwanie od RTC, USB (Wake Up), lub przerwanie z linii zewnętrznej.
• Standby mode -  najmniejszy z możliwych pobór mocy. Powyłączane są wszystkie te układy, co w trybie Stop, a dodatkowo wyłączana jest pamięć SRAM i zachowywana jest tylko zawartość rejestrów Backup

DMA

Konfigurowalny kontroler DMA umożliwia transfer danych: pamięć-pamięć, peryferia-pamięć, oraz pamięć-peryferia. Może pracować w trybie bufora cyklicznego, bo pozwala uniknąć generowania przerwania w momencie dojścia do końca bufora. Możliwe jest zdefiniowanie aż do 7 kanałów transferu, między wybranymi obszarami pamięci, bądź peryferiami i niezależne ich wyzwalanie. Kontroler DMA może być używany z peryferiami takimi jak: SPI, I2C, USART, Timery, oraz przetwornik ADC.

RTC (real-time clock) and backup registers

Zarówno RTC, jaki i rejestry backup są zasilane poprzez przełącznik, który przełącza napięcie zasilania albo pobierając je z głównego portu zasilania albo z linii zasilania bateryjnego. Rejestry backup to 10 16-bitowych rejestrów które umożliwiają przechowywanie 20 bajtów danych przy braku zasilania.

RTC jest zestawem liczników obsługiwanych programowo i taktowanych z zewnętrznego oscylatora kwarcowego 32.768kHz, albo wewnętrznego oscylatora RC (40kHz). RTC może być wykorzystany do implementacji zegara lub kalendarza, a także do generowania przerwania co określony czas. Dodatkowo do dyspozycji mamy także 20-bitowy preskaler głównego sygnału zegarowego który domyślnie ustawiony jest tak, by przerwanie generowane było co 1 sekundę.

Timers & Watchdogs

Mikrokontrolery linii Performance wyposażone są w jeden zaawansowany timer, trzy timery ogólnego przeznaczenia, dwa timery watchdog, oraz timer SysTick używany w systemach operacyjnych.

Advanced-control timer (TIM1)

Jest to najbardziej zaawansowany 16-bitowy timer w całym układzie. Może on pracować jako trójfazowy generator PWM multiplexowany na 6 kanałów. Posiada komplementarne wyjścia z programowanym czasem martwym (dead-time). Może także działać jako timer ogólnego przeznaczenia, którego funkcje opisuję poniżej.

Genereal-purpose timers (TIMx)

Mikrokontrolery z linii Performance posiadają do 3 timerów ogólnego przeznaczenia. Wszystkie są oparte o 16-bitowy licznik zliczający w dół, lub w górę z funkcją automatycznego przeładowywania. Posiadają także 16-bitowy preskaler i 4 niezależne kanały dla input capture/output compare, PWM i trybu one-pulse. Timery te mogą także pracować razem w trybie zaawansowanym dzięki funkcji Time Link. Mogą również  obierać sygnały wprost z czujników halla i enkoderów.

Independent watchdog

Jest to watchdog oparty o 12-bitowy licznik zliczający w dół z preskalerem 8-bitowym. Taktowany jest on 40kHz wewnętrznym generatorem RC i działa niezależnie od głównego zegara. Pracuje także w trybach obniżonego poboru mocy Stop mode i Standby mode. Może być uzywany jako watchdog do resetowania mikrokontrolera, gdy pojawi się jakiś problem, albo jako swego rodzaju timer używany w aplikacji. Jest on w pełni software’owo konfigurowalny.

Window watchdog

Realizowany jako 7-bitowy licznik zliczający w dół. Może wywoływać reset gdy nie zostanie odświeżony w zadanym oknie czasowym.

I2c Bus

Układy posiadają do dwóch kontrolerów interfejsu I2C. Mogą one pracować w trybach multimaster, oraz slave. Obsługują transmisje z szybkością standard i fast. Układy slave mogą być adresowane w dwóch trybach – 7-bitowym, oraz 7/10-bitowym. Dodatkowo kontroler sam dba o generowanie i weryfikację sumy CRC podczas transmisji. Kontrolery I2C mogą być obsługiwane przez DMA.

USART

Jeden z USARTów może pracować z szybkością do 4.5Mbit/s, natomiast pozostałe do 2.25Mbit/s. Sprzętowo obsługiwane są sygnały RTS i CTS. Kontroler USART może być obsługiwany przez DMA.

SPI

Interfejsy SPI mogą pracować zarówno w trybie slave, jak i master z prędkością do 18Mbit/s. Obsługiwane są tryby full- i half-duplex. 3-bitowy preskaler umożliwia wybranie jednej z ośmiu prędkości. Długość ramki danych jest konfigurowalna i może wynosić 8 lub 16 bit. Suma CRC jest generowana i weryfikowana sprzętowo, co ułatwia obsługę kart SD i MMC.

USB

Wbudowany kontroler USB może pracować nawet z prędkości 12Mbit/s. Jako zegar wykorzystywany jest wtedy sygnał z pętli PLL (źródłem sygnału dla pętli musi być zewnętrzny kwarc – ze względu na stabilność).

GPIO

Porty wejścia/wyjścia mogą byś programowo konfigurowane do pracy w trybach: push-pull lub open drain (wyjście) i push-up lub push-down (wejście). Większość nich ma także dodatkowe funkcje. Podłączone są one do magistrali APB2 co zapewnia prędkość zmian wyjścia do 18MHz.

ADC

Układy wyposażone są w jeden lub dwa (performance line) 12-bitowe przetworniki ADC o czasie konwersji równym 1us. Posiadają one wiele trybów pracy, których wymienianie tutaj nie ma sensu, więc odsyłam do dokumentacji. Ich wejścia mogą być multipleksowane na 18 sygnałów, z czego 16 jest zewnętrznych, a pozostałe dwa, to wewnętrzny reference voltage i wewnętrzny termometr.

Podsumowując

Mam nadzieje, że udało mi się Was przekonać, jaka moc drzemie w mikrokontrolerach STM32F. Ogólnie możliwości mikrokontrolerów z rdzeniami 32-bitowymi są nieporównywalne z możliwościami 8-bitowców. Ceny STM32 zaczynają się już od około 15zł, co jest porównywalne z cenami lepszych ATMeg, dlatego warto się zastanowić, czy czasem nie pora by poznać nową rodzinę mikrokontolerów…

Źródła

• http://www.st.com/stm32

Rodzina Cortex

Rodzina Cortex jest najnowszym opracowaniem firmy ARM. W jej skład wchodzą 3 rodzaje rdzeni (wszystkie oparte na tej samej architekturze – ARMv7):

• Cortex-A – przeznaczone do aplikacji wykorzystujących systemy operacyjne, posiadają MMU (Cortex-A5, Cortex-A8, Cortex-A9)
• Cortex-R – przeznaczone do stosowania w systemach czasu rzeczywistego (Cortex-R4, Cortex-R4F)
• Cortex-M – zoptymalizowane cenowo i przeznaczone do szerokiego stosowania w mikrokontrolerach i typowych aplikacjach (Cortex-M0, Cortex-M1, Cortex-M3)

Wszystkie rdzenie obsługują nowy zestaw instrukcji Thumb-2, który umożliwia osiąganie dużych wydajności, przy  niskiej objętości kodu programu. Łączy on w sobie zalety zestawu ARM i Thumb. Kod zajmuję do 31% mniej niż w przypadku zestawu ARM i jest wykonywany do 38% szybciej niż zapisany w Thumb.

Rdzenie Cortex-M

Linia Cortex-M została stworzona do typowych zastosowań w motoryzacji, medycynie, komunikacji bezprzewodowej (ZigBee, Bluetooth), oraz przemyśle. W jej skład wchodzą obecnie 3 rdzenie:

• Cortex-M3 – do stosowania w mikrokontrolerach
• Cortex-M1 – rdzeń miękki zaprojektowany specjalnie do implementacji w FPGA
• Cortex-M0 – rdzeń o bardzo niskim poborze energii – najmniejszy z zaprojektowanych przez firmę ARM

Wszystkie te rdzenie są kompatybilne, co umożliwia łatwe przenoszenie kodu z jednego na drugi. Firma ARM opracowała, we współpracy z producentami półprzewodników, specjalny standard CMSIS (Cortex Microcontroller Software Interface Standard), który ma być warstwą między sprzętem, a programem użytkownika. Umożliwi to łatwe przenoszenie aplikacji na inne rdzenie i skróci czas potrzebny na poznawanie nowych rodzin, oraz czas projektowania nowych urządzeń.

Główny bohater artykułu – Cortex-M3

Budowa rdzenia Cortex-M3

Zaskakująco dobry stosunek możliwości do ceny uzyskano w rdzeniach Cortex-M3 dzięki wielu zaawansowanym rozwiązaniom. Najważniejsze z nich to: 3-poziomowe kolejkowanie instrukcji z mechanizmem przewidywania rozgałęzień, skrócony czas wykonywania większości operacji do jednego cyklu, oraz zastosowanie nowego zestawu instrukcji Thumb-2.  Inne, te bardzie istotne, przedstawiam poniżej (tłumaczenie danych ze strony producenta z własnymi komentarzami):

• hierarchiczna struktura z dobrze dopasowanymi peryferiami
  • CM3Core
    • architektura Harvardzka – oddzielne magistrale programu i danych
    • Nested Vectored Interrupt Controller (NVIC) – poprawiony  kontroler przerwań którego obsługa jest dużo prostsza w stosunku do ARM7
    • do 240 programowanych przerwań; do 256 poziomów priorytetów
    • małe opóźnienia obsługi przerwań dzięki zastosowaniu mechanizmów tail chaining i late arrivals
    • wywłaszczanie przerwań o niższym priorytecie
  • Memory Protection Unit (MPU)
  • Debug Port ( SW-DP or SWJ-DP )
    • możliwość debugowania przez Serial Wire lub JTAG
• mnożenie w jednym cyklu i sprzętowe dzielenie
• 4GB przestrzeń adresowa
• predefiniowane adresy dla pamięci programu, pamięci danych, urządzeń zewnętrznych i peryferiów
• możliwość operowania na pojedynczych bitach dzięki technice bit banding
• dostęp do pamięci programu w jednym cyklu
• zintegrowane tryby obniżonego poboru energii

Porównanie Cortex-M3 z ARM7TDMI

Rdzeń Cortex-M3 jest następcą popularnego do tej pory ARM7TDMI. Inżynierzy z ARM Holdings podczas projektowania uwzględnili uwagi użytkowników, przede wszystkim dotyczące dość trudnego w obsłudze kontrolera przerwań. W nowym rdzeniu wprowadzono wiele poprawek, które sprawiają, że Cortex-M3 jest rdzeniem nowej generacji. Nowy zestaw instrukcji, poprawiony kontroler przerwań, krótkie i deterministyczne czasy obsługi przerwań, oraz zintegrowane peryferia pozwalają osiągnąć dużą wydajność, przy małym poborze mocy. Poniżej przedstawiam tabelkę porównawczą przygotowaną przez firmę ARM:

Jeszcze jestem winny małe sprostowanie… Miało być o rodzinie STM32, a było o Cortex’ach… Po prostu doszedłem do wniosku, że trzeba zacząć od początku :P Następny wpis będzie już na pewno o STM32.

Źródła:

• http://www.arm.com/products/CPUs/families/CortexFamily.html
• http://www.arm.com/products/CPUs/ARM_Cortex-M3.html