Sesja, sesja, sesja...

    A tu odkrycie roku: instalacja i użytkowanie Wine, od czasu gdy próbowałem po raz ostatni stała się naprawdę prosta. Powód odkrycia był równie trywialny: po przedstawieniu młodszemu bratu gry mej wciąż jeszcze trwającej młodości ( Fallout tactics ) odkryłem że nie będę mógł się od niej oderwać przez dłuższą chwile i nic, a zwłaszcza brak Falouta na linuxa nas nie rozdzieli. Psucie mojego biednego laptopa też jednak nie było opcją. Co gorsza pożyczałem grę młodszemu bratu...

→ Sudo apt-get install wine – wpisane w terminalu, po wpisaniu hasła, załatwiło w sposób

komfortowy instalację Wine.

→ Zgranie płyt do postaci .iso na dysk twardy było obowiązkowe. Na to sposobów jest wiele i nie będę się roztkliwiał – wystarczy wpisać „iso” w Centrum Oprogramowania Ubuntu, zainstalować pierwszy z brzegu program i kolejno zgrać płytki.

→ sudo mount /Sciezka do iso z gra/Fto2.iso /media/isoimage/ -o loop - Montuje nam naszą płytkę jako napęd w miejscu /media/isoimage/ Zamontowany napęd jest widoczny podczas przeglądania folderów. W moim przypadku jak widać jest to iso o pięknej nazwie Fto2.iso.

→ Przejście do zamontowanego iso Odbywa się poprzez przejście do katalogu isoimage widoczny jest on w tej samej kolumnie, jednak n elementów niżej.

→ Kliknięcie prawym klawiszem na plik exe który chcesz odpalić, następnie wybrane „Otwórz za pomocą → Wine windows („ … ”) daje ten sam efekt co dwukrotne kliknięcie na plik .exe w Windowsie.

→ Gdy podczas instalacji potrzebujesz zmienić płytkę to należy wpisać

sudo umount /media/isoimage/ i zamontować kolejną płytkę w tym samym miejscu. Czemu nie w innym? Bo większość gier wymaga płyty w napędzie i jak doczytałem się gdzieś w czeluściach internetu zamontowanie kilku płyt naraz może spowodować że będziesz musiała/musiał instalować gierkę jeszcze raz.

→ Osobiście pozwoliłem na stworzenie skrótu na pulpicie. I o dziwo skrót nie pojawił mi się w symulowanym Windowsowskim katalogu, a normalnie na pulpicie Ubuntu a co lepsze – normalnie działa.

→ Wiola – dwuklik i gramy ;]

Oczywiście Wine może służyć ważniejszym celom – np. instalacji Autodesk Inventora czy innych profesjonalnych programów, których wsparcia na linuxa nie ma. Osobiście optował bym jednak z użytkowaniem linuxowych, darmowych programów ile się da / gdzie się da. Np Free CAD moim zdaniem jest lepszy od zwykłego AutoCAD'a i mimo że do Inventora nie dorasta – to nie trzeba wydawać na niego ekwiwalentu małego auta :)

ps. Ciekawostka – szukając informacji „co i jak” z Wine, dowiedziałem się też że Gry na linuxie potrafią nie raz chodzić szybciej na dokładnie tym samym sprzęcie i tak poprawa dla Fallouta potrafi być nawet 1,5 krotna!

Mała, duża przyjemność.

Czasem małe rzeczy sprawiają dużą przyjemność.

Kupiłem (dokładniej - mój brat mi kupił) za 10zł chińskiego pilota do nikona D80. Okazuje się że pilot do tego aparatu to zwykły pilot na IR i kod już dawno został przez nich skopiowany. Sam pilot działa na guzik zwierający dwie nóżki scalaka o nieznanej mi nazwie, jako że została skrzętnie zmyta, szkoda bo z wiedzą jaki to scalak zabawa poszła by szybciej.

A zabawa była następująca - trzeba zrobić timer do timelaps'ów. Czemu zrobić, a nie kupić? Bo równie chiński timer jest odpowiednio droższy, a ja zawsze mam Atmegę8 pod ręką i... mam ochotę się pobawi :)

Od strony hardvare'u sytuacja wyglądała następująco:
→ Zasilanie 3V → Podczepiłem się od mojej płytki z zasilaniem 3.2V (Wahania
napięcia baterii są większe niż to.)
→ Zidentyfikowałem kierunek napięcia na nóżkach scalaka → Zdarłem soldermaskę → Wlutowałem p-mosfet. → Wyprowadziłem bramkę.
→ Zacisnąłem 3 konektorki - viola, mogę sterować tym ustrojstwem choćby attinym13.

By sprawdzić czy działa podpiąłem się do zasilania, załączyłem mosfeta i nakierowałem kamerę w komórce na diodę IR - okazuje się że kamera w telefonie spokojnie odbierze ten sygnał "na niebiesko".

Zostaje jeszcze kawałek softu. Odmierzanie czasu - zwykły _delay_ms(n) i wyświetlanie "Pstryk!" na ekranie - ot taki bajer ;] Naprawdę proste a cieszy, ustawienia jak widać są na zdjęcie co 1.5 min , w wolnym czasie dodam jeszcze potencjometr, do regulacji czasu (a wtedy same odmierzanie czasu będzie na timerze 1 lub 2. )

#include <avr/io.h>

#include <avr/interrupt.h>

#include <util/delay.h>

#include "ascii.h"

#include "spi.h"

#include "n5110.h"

#include "adc.h"

#define on(n) PORTC|=(1<<n)

#define off(n) PORTC&=~(1<<n)

int main()

{

  DDRC|=(1<<PC5);

  PORTC&=~(1<<PC5);

  spi_init();

  lcd_init();

  lcd_place(0,0);

   while(1)

   {

     lcd_clear();

     lcd_place(0,3);

     lcd_string("Pstryk! ");

     on(PC5);

     _delay_ms(200);

     off(PC5);

     lcd_clear();

    _delay_ms(900);

     _delay_ms(400);

  }

}

Zadziwiające jest to że nie znalazłem w necie nikogo kto zrobił by to wcześniej i się pochwalił. Nawet za pomocą arduino i przekaźnika :P

ARM-GCC a ARM-G++

Po udanych kompilacjach i blinkaniu diodką z eclips'owego debuggera zachciało mi się więcej. Jak to mówią głód rośnie w miarę jedzenia, tak więc stwierdziłem że przydało by się napisać coś w C++ a nie w C.
Zrobiłem nowy projekt, klasę etc. wszystko pięknie dopóki... nie załączyłem wszystkiego w main'ie. Skracając moją przydługawą przygodę z googlem, gdzie nie dowiedziałem się nic ciekawego, odkrywczo wpadłem na to że eclipse by default stworzył plik main.c, nie main.cpp skąd interpretował go jako plik w c.

Krótki wniosek - trzeba pamiętać by pliki korzystające z C++ były z rozszerzeniem .cpp ...

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.