Gotta catch 'em all! Zaczynam zabawę z STM32!

Już wiem że pisanie raz na tydzień jest nie realne – tak więc trzeba zmienić cel naraz na miesiąc! Może teraz się uda :P

Zawalony wszystkimi możliwymi rzeczami ogólno uczelnianymi (sesja, obrona, jeszcze więcej sesji, formalności i inne) Nie miałem czasu nawet się podrapać. Tak więc w ramach relaksu, postanowiłem postawić IDE pod ARM'y, a dokładniej STM32, a najdokładniej pod płytkę STM32F429 discovery.

Różnica pomiędzy mikroprocesorami 8 bitowymi którymi bawiłem się wcześniej, a 32 bitowymi, którymi zaczynam się zajmować w wolnych chwilach, jest jak między starym fiatem, a odrzutowcem. Starym fiatem jeszcze jakoś pojedziesz, ale już nie polecisz :P Zafascynowany tym że taka moc jest na wyciągnięcie ręki (literalnie – bo pierwszego SMT32 widziałem w ręce u kolegi) tak jak pewnie wielu przede mną pomyślałem „Muszę ją mieć!”. Dobrze że moja krzemowa wybranka jest na tyle tania że stać na nią przeciętnego studenta.

Sama płytka to piękna rzecz, dotykowy wyświetlacz + wyjście USB + mnóstwo pinów. Na płytce wbudowany programator JTAG St-link/v2. Po podłączeniu miga soft producenta. Szkoda że od strony darmowego oprogramowania wygląda to odrobinę mniej różowo. (Przynajmniej dla mnie i przynajmniej jak na razie ;) )

Na wstępie powiem że uruchomienie IDE zajęło mi dobry weekend.

Do jego uruchomienia potrzebne były:

1) Dużo cierpliwości

2) Najnowszy eclipse

3) ARM-GCC

4) OpenOCD

5) Zylin

6) Dokumentacja i soft producenta.

Ad. 1 Cierpliwość:

 

Odsiewanie ziaren od plew było żmudnym zajęciem, nie znalazłem żadnego dobrego tutorialu how it's made. Ja też planuję napisać jak to było zrobione u mnie, a nie jak to dokładnie zrobić. Informacje będą jednak świeżutkie, oraz stricte pod Linuxa – co moim zdaniem może być na wagę złota. W zakładkach nadal mam 21 linków które uważałem za cenne we wstępnej analizie. Co ciekawe nie ma w nich tutorialu Freddiego Chopina, nie dlatego że nie jest dobry – tego nie wiem, nie czytałem, ponieważ nie jestem odbiorcą docelowym –tutorial jest napisany pod Windowsa.

Ad. 2 Eclipse

 

Najnowszy eclipse (czytaj: Kepler) jest wymogiem niezbędnym z 2 powodów. Pierwszy jest taki że zwyczajnie nie szło zainstalować nakładek pod arm-gcc na mojej starszej wersji. Drugi jest taki że ponoć bezpieczniej jest mieć oddzielnego eclipse pod STM32 a innego pod 8 bitowe AVR.

Niezbędną nakładką jest GNU ARM eclipse plugin. Który btw dostarcza już szablonowy projekt pod discoverego, dzięki czemu nie musimy a) bawić się w edycje wszystkich możliwych ustawień, których dla 32 bitowców jest trochę b) szukać gotowca w necie, który na dodatek może nie chcieć działać z naszym kompilatorem. Mi standardowy template odpalił za pierwszym kompilowaniem /*Przez arm gcc*/ i chwała mu za to.

Ad. 3 ARM GCC

Jak chyba każdemu wiadomo, bez kompilatora niczego się nie napisze (a przynajmniej nie w C/C++ pod mikroprocesory) tu następuje wielka dezinformacja. Gro ludzi doradza wybrać Code Sourcery w wersji darmowej i za jego pomocą radzić sobie dalej. Tak więc idąc za głosem większości i ja tak zrobiłem. Koniec był taki że: sporo zachodu, mnóstwo zabawy żeby coś zaczęło chodzić, a i tak gówno mi z tego wyszło. Skoro tak trzeba było dorwać ARM GCC, najlepiej tak żeby nie trzeba było bawić się z PATHs ani niczym innym.

Anglojęzycznym polecam przeczytanie: http://embeddedprogrammer.blogspot.com/2012/09/stm32f4discovery-development-with-gcc.html , do momentu gdy będzie mowa o Zylinie. Oraz: http://fab.cba.mit.edu/classes/863.13/tutorials/EmbeddedProgramming/stm32.html do momentu „Install Stlink”.

sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded

sudo apt-get update

sudo apt-get install gcc-arm-none-eabi

Załatwiają sprawę. Na debianie trzeba jeszcze trochę z tym pokombinować, ale jako szczęśliwy posiadacz ubuntu te problemy mnie ominęły. Dla nie zorientowanych: tak, na ARMy można pisać w C++ (na 8 bitowce ponoć też) a na dodatek jest to całkowicie normalne!

Ad. 4 OpenOCD

Nie wiem jak poradził bym sobie przed Wrześniem 2012 roku, to ponoć od tego czasu dostępne jest programowanie i debugowanie przez OpenOCD.

Strona OpenOCD: http://openocd.sourceforge.net/ - tu znajdziemy dokumentację, choć mogła by być bardziej newebie friendly.

OpenOCD download: http://sourceforge.net/projects/openocd/files/openocd/0.7.0/

Jak skompilować OpenOCD? http://www.tincantools.com/wiki/Compiling_OpenOCD_v07_Linux rozpakowujemy ściągniętą paczkę, najlepiej do katalogu home. Wchodzimy w terminal i wklepujemy/kopiujemy zawarte 4 komendy pod „Compiling OpenOCD” Wiola. Używając Linuksa, ściągnąłem s'tar'owaną paczkę. Po rozpakowaniu i skompilowaniu ukrywamy folder. /* by ukryć folder dodajemy kropkę przed nazwą czyli np. by ukryć folder „różowe_landrynki” zmieniamy nazwę na „ . różowe_landrynki ”, by pokazać ukryte foldery klikamy ctrl + h */.

Teraz można już podłączyć naszą płytkę do komputera i sprawdzić czy możemy się z nią połączyć. Warto zapisać sobie komendę do łączenia z płytką – przed każdym programowaniem/debugowaniem z eclipsa, będziemy najpierw musieli podłączyć się do płytki przez terminal. U mnie komenda wygląda tak:

openocd -f ./.openocd-0.7.0/tcl/board/stm32f4discovery.cfg

Jeśli schowałeś katalog tak jak mówiłem, to Twoja komenda jest identyczna. Przy czym nie masz jeszcze dodanych reguł dla programatora, stąd musisz odpalić ją z sudo na początku. By dodać regułę do programatora st-link v2 należy wpisać:

cd //

cd etc/udev/rules.d

sudo nano 99-St-link.rules

→ Tu pojawia się okno edytora tekstu gdzie trzeba wpisać/skopiować:

#ST-link_v2

SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="0666", GROUP="plugdev"

→ Zapisujemy plik:

sudo udev reload

I można cieszyć się użytkowaniem programatora bez roota.

Ad. 5 Zylin

Nie wiem czemu, ale zmarnowałem przy próbach współpracy z Zylinem sporo czasu, prawdę mówiąc prawie zupełnie nie potrzebnie. Prawie, bo jednak testowanie różnych ustawień to pewnie też jakaś nauka poleceń do OpenOCD. Po pierwszym s'flash'owaniu płytki, pierwszym lepszym softem dostarczonym przez producenta wraz z całą dokumentacją, dałem sobie spokój z Zylinem – nadal nie mam pojęcia czemu mi nie działa.

Zamiast bawić się z Zylinem, lepiej, przynajmniej mi współpracuje się z GDB hardware debuging.

W zakładce Debbuger należy jedynie wklepać:

→ W oknie GDB command:

arm-none-eabi-gdb

→ Remote target:

zaznaczyć

→ JTAG device:

OpenOCD

→ GDB connection string :

localhost:3333

I to właściwie koniec, ustawień. Tyle wystarczy by włączyć pierwszą sesję debuggera.

Patrząc na to z perspektywy – brzmi niezbyt ciężko. Szkoda że po drodze ciężko było na to wszystko wpaść :)

Ad. 6 Dokumentacja

Ten punkt jest dosyć oczywisty – by zapalić diodkę, trzeba najpierw wiedzieć gdzie się ona znajduje. W całej dużej paczce do płytki discovery znajdziemy też przykładowe, skompilowane programy, co idealnie nadaje się do przetestowania czy na pewno dobrze działa nam OpenOCD.

Do wrzucenia programu testowego na Discoverego użyłem następującej komendy:

openocd -f ./.openocd-0.7.0/tcl/board/stm32f4discovery.cfg -c "program /home/pholat/Pulpit/STM32/STM32F429I-Discovery_FW_V1.0.1/Projects/Demonstration/Binary/STM32F429I-DISCOVERY_Demo_V1.0.1.hex verify reset"

Ad 007. Gotowe.

Ostatecznie – czego jeszcze nie zdążyłem sprawdzić ;] Trzeba dodać breakpointy w programie. By nie przechodzić całej inicjalizacji etc.. Jest to dosyć proste – w widoku „Debug” klika się dwa razy na pasek naprzeciwko scrolla od przewijania programu. W tym momencie pojawia się kropka oznaczająca breakpoint. By ją usunąć klikamy ją raz jeszcze. By do niej dojść na pasku na górze klikamy symbol play. Tyle na dziś. Następnym razem jak będę miał wolny czas może dodam tu screeny.