AT91SAM7XC256 - [Eclipse+openocd+GDB+GNU ARM Eclipse Plugin] konfiguracja

Question

Witam,Mam zbudowane środowisko jak w temacie, ale nie mogę poradzić sobie z konfiguracją wtyczki GNU ARM Eclipse. Ogólnie całość już mi działała na i...

mickpr · Answer

Oto przykład zmodyfikowanego projektu z płyty z OLIMEX-u( zmodyfikowany do CS). Nie pamiętam czy poprawnie działa (ma już trochę czasu), ale raczej tak.Importować przez "Import"

B0BI · Answer

Dzięki za Twój projekt, niestety część ustawień znajduje się w katalogu workspace/.metadata i po zaimportowaniu Twojego projektu ciągle jest ten sam problem. Zapomniałem jeszcze dodać, że całe środowisko stoi na linuxie. Dodatkowo znalazłem dosyć dokładny opis konfiguracji na stronie Link
ale to też w zasadzie nie pomogło.

Freddie Chopin · Answer

Lepiej więc olać tą wtyczkę i użyć normalnego Makefile (; Na pewno zadziała [;4\/3!!

mickpr · Answer

Wadą Eclipse jest to, że czasem przy machlojkach z konfiguracjami (zwłaszcza zmianą toolchain'u) projekt przestaje działać.Wtedy lepiej stworzyć go od nowa, zwłaszcza, że nie jest to trudne.Nie wiem czy makefile jest prostsze - myślę, że to kwestia gustu.

B0BI · Answer

Jak budowałem środowisko po raz pierwszy próbowałem właśnie na zwykłym Makefile i też miałem z tym kupę problemów, nie mam bladego pojęcia jak się tworzy ten plik, a z tą wtyczką jakoś mi się wtedy udało całość odpalić.
Co do tworzenia projektu od nowa, też już próbowałem, importowałem same pliki kodu i ręcznie zmieniałem ustawienia ale właśnie brakuje mi konkretniejszych informacji jak to poustawiać, więc też nic z tego nie wyszło.

mickpr · Answer

Czego konkretnie nie wiesz?Najważniejszy jest wybór architektury MCU oraz ustawienie Linker script'u.

B0BI · Answer

No i tylko to wiem jak ustawić, a w przypadku pozostałych checkboxów, definicji symboli, czy dodawanych ścieżek to już metodą prób i błędów oraz szczątkowych informacji znalezionych w sieci.

Jeśli to nie kłopot to prosił bym kolegę mickpr o screen okna "Project settings->C/C++ Build->Tool chain editor"

Freddie Chopin · Answer

Na pewno trochę bardziej uniwersalne. (;Odpowiedź jest podchwytliwa - nie tworzy się go, tylko bierze się działający szablon i już. (;4\/3!!

mickpr · Answer

Proszę Dodano po 3 [minuty]: Ale wymagające więcej "zachodu". Osobiście znam metodologię tworzenia Makefile, ale o wiele szybciej stworzę projekt klikając niektóre opcje (wszak od tego jest IDE), niż kopiując/poprawiając właściwy makefile.To jest na prawdę prostsze.

Freddie Chopin · Answer

No nie mogę się zgodzić... Wyłączając rzeczy które trzeba zrobić niezależnie od "platformy" (startup, przygotowanie skryptu linkera, tablicy wektorów itd.) w dobrym szablonie Makefile (wiadomo o którym piszę) jedyne co trzeba zrobić to... hmm... nic. No dobra - trzeba wpisać nazwę skryptu linkera (jak we wtyczce), nazwę projektu (jak we wtyczce), wybrać typ układu (jak we wtyczce), wpisać potrzebne dla niego opcje - include paths, defines (jak we wtyczce). Jeśli nie tworzymy projektu od zera tylko mamy już gotowy zestaw z kodem który ma jakieś foldery, to w Makefile trzeba je wypisać i wszystko na ten temat...Tymczasem ja znam tą wtyczkę i wiem, że aby w niej zrobić nowy projekt to trzeba tam wklikać jakieś milion opcji które trzeba pamiętać, w przeciwieństwie do Makefile, który jest już gotowy ze wszystkimi opcjami [; Ta wtyczka definitywnie nie jest rozwiązaniem typu "nowy projekt w 3 kliknięcia" - bardziej tak 33 i kilkadziesiąt "kliknięć" po klawiaturze...Zysk stosowania "gołego" Makefile (bo wtyczka też oczywiście tworzy Makefile) jest taki, że do jakiejkolwiek (sensownej) modyfikacji projektu NIE jest potrzebny "projekt" w Eclipse ani nawet samo Eclipse - gdy za 2 lata będziemy chcieli go przekompilować z jakąś inną opcją to ja zmieniam w Makefile opcje i kompiluję, a przy użyciu wtyczki czeka mnie conajmniej import projektu, a potem zastanawianie się co się zepsuło przy okazji nowej wersji wszystkiego... Można oczywiście instalować starą wersję i kombinować, tym samym operacja która przy użyciu Makefile zajmuje 3s zamienia się w kilkugodzinną batalię z nowymi wersjami oprogramowania (; A że nowe wersje nie są kompatybilne wstecz to chyba wynika wprost z tego wątku...Nikogo nie chcę zmuszać czy specjalnie namawiać, prostuję tylko pewne fakty, ponieważ niedługo Makefile to będzie taki sam kosmos jak "pisanie na rejestrach" (jak wiadomo dobry program da się napisać tylko korzystając z bibliotek producenta układu, bo inne podejścia to anachronizm, ewentualnie czarna magia dla h4x0rów).4\/3!!

mickpr · Answer

@Freddie ChopinSam używałem Makefile nie raz, nie dwa (głównie pod Linux'em).Potem ujrzałem cuda w stylu "Programmers Notepad" w AVR Studio - gdzie w magiczny (tragikomiczny) sposób tworzyło się projekt robiąc własny makefile.To nie ma nic wspólnego z używaniem IDE. Ja to nazywam "sztukowaniem".Dla mnie IDE, to IDE. Skoro używam Eclipse, to sens stosowania Makefile, jest dla mnie żaden. Jeśli używam Eclipse jako koloryzatora składni - to zapewniam - znajdzie się coś "bardziej lekkiego".

Freddie Chopin · Answer

Poza kolorowaniem składni jest jeszcze wiele innych rzeczy do których nie znajdziesz czegoś "bardziej lekkiego":- debugger- statyczna analiza kodu (nie mylić z kolorowaniem) (code analysis)- automatyczne kompletowanie kodu (code assist)Zmiana opcji projektu to przecież jednorazowa sprawa - nie róbmy z tego głównego celu stosowania IDE...4\/3!!

mickpr · Answer

Dlatego używam Eclipse.Niewykorzystanie opcji IDE i plugina, jest jak "budyń śliwkowy bez śliwek".Ale może i masz rację...

B0BI · Answer

Freddie w takim razie skąd mogę wziąć dobry szablon pliku Makefile i jak go przerobić pod swój projekt i procesor? Może faktycznie te problemy, które mam teraz wynikają z różnic wersji oprogramowania.

Freddie Chopin · Answer

Zapewne z mojej strony (; Rozpocznij od szablonu o nazwie lpc2103_blink_ledMyślę że wiele zmian nie będzie potrzebnych [; Wystarczy jak przejrzysz początek tego pliku i podasz wszystkie niezbędne definicje, dodasz foldery, ustawisz to co trzeba tam ustawić (np. rozszerzenia plików jeśli są inne niż "typowe"). Jak coś to pytaj (;4\/3!!

mickpr · Answer

Nie żebym mówił "a nie mówiłem?", bo znam i szanuję wysoki poziom wiedzy kolegi.. ale niestety wyszło na moje Przepraszam

Freddie Chopin · Answer

Na co wyszło? W sensie że będzie tam dużo grzebania czy co? Bo nie rozumiem o co chodzi? Wszystko co trzeba tam ustawić trzeba też ustawić w normalnym projekcie - czasem coś dodatkowego, za to NIE trzeba ustawiać setek opcji wtyczki, więc jak dla mnie i tak jest lepiej...

Konkrety - co niby jest nie tak?

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

mickpr · Answer

Odpowiem konkretnie, choć trochę pokrętnie. Właśnie przyjechał mój brat i pokazał mi debugowanie z JTAG ULINK2 pod Keil uVision 4. Dotychczas widziałem Keil'a, nawet parę razy testowałem, ale bez debugger'a.Ręce mi opadły w stosunku do tego, co trzeba wykonać, aby uruchomić debugowanie OpenOCD pod Eclipse. Uruchomił Keil, podłączył ULINK'a, wczytał projekt.. i działa... (debugowanie).W dodatku zapewnione jest np. sterowanie portami i inne "zabawki".Choć środowisko Keil - nie do końca przypadło mi do gustu (kwestia przyzwyczajenia), to zdałem sobie sprawę, że miałem złe pojęcie o "debugowaniu ARM'ów".Konkretnie - zamiast grzebać w plikach tekstowych wolę (wolno mi - prawda?) wyklikać sobie opcje w Eclipse.Zamiast (jak kolega) zastanawiać się skąd wziąść Makefile i jak go ustawić pod konkretny MCU wolę przelecieć się po opcjach konfiguracji (ładnie opisanych zresztą).Poza tym - oprócz opcji kompilacji trzeba jeszcze ustawić debugowanie, zrobić programowanie flash i generowanie odpowiednich plików (np. hex) - ale to już zawsze, i przy Makefile i przy użyciu plugina).

Freddie Chopin · Answer

Cóż za stronniczość... O czym to niby świadczy? Czy ja tu widzę porównanie TWORZENIA I KONFIGURACJI PROJEKTU oraz KONFIGURACJI ŚRODOWISKA w Eclipse do WŁĄCZENIA DEBUGGOWANIA w Keilu... No sorry, ale ja Ci też mogę pokazać jak się uruchamia debuggowanie z OpenOCD i GDB w Eclipse - zajmuje to dokładnie DWA kliknięcia i trwa jakieś 0.5s. Gdzie problem? Projekt oczywiście też da się zaimportować <;W Eclipse też, z odpowiednią wtyczką (;Myślę, że powinieneś też sprawdzić cenę rocznej licencji Keila, to wtedy będziesz miał pełne pojęcie <;Oczywiście. Każdy może lubić/woleć rzeczy które nie mają specjalnego sensu <;No ale tam nie musisz go ustawiać "pod konkretny MCU"... Może przejdźmy do konkretów. Tak wygląda fragment Makefile którym trzeba się zająć (reszta jest nieistotna):Code: textLog in, to see the codeOpcje te można podzielić na 2 grupy:1. Takie które i tak trzeba ustawić przy użyciu Eclipse i wtyczki - nazwa projektu, rdzeń, definicje, include paths2. Opcje których nie trzeba ustawiać w Eclipse - foldery ze źródłami, rozszerzenia plikówTych pierwszych jest definitywnie więcej.Ale można też podzielić inaczej:1. Opcje które trzeba faktycznie zmienić (a we wtyczce i tak trzeba je ustawić)2. Opcje których nie ma co zmieniać, bo wartość jaka tam jest wpisana zapewne jest już dobra.Tych pierwszych jest definitywnie mniej.Jak dla mnie JEDYNĄ opcją jaką tam trzeba ustawić, a której NIE trzeba ustawić we wtyczce jest lista folderów z kodem. Jeśli projekt jest "czysty" (zaczynamy go dopiero pisać) lub "prosty" (wszystko w folderze głównym lub w jednym folderze) to nic tam nie trzeba wpisywać.Ewentualnie jeśli ktoś uważa, że dla plików C, C++ i assemblera są fajniejsze rozszerzenia niż (odpowiednio) c, cpp i S to też może sobie zmienić.Pozatym zapominasz o jednym szczególe - nawet jeśli by to miało trwać kilkanaście minut, to jest to "inwestycja jednorazowa", bo po dostosowaniu do własnych preferencji taki plik jest już plug&play i w nowym projekcie jego modyfikacja zajmuje jakieś 5s. A z wtyczką sobie zawsze musisz wyklikać ten milion opcji (może i dobrze opisanych, ale i tak trzeba wiedzieć co one niby robią i po co by niby miały być).Takie jest moje zdanie (; Jak dla mnie ta wtyczka tylko zamienia "wpisywanie" opcji "wybieraniem" opcji, a dodatkowo zmusza mnie do wybierania ich za każdym nowym projektem (a jest tych opcji trochę...). Skoro "wybieranie" jest fajniejsze niż "wpisywanie", to czemu programy wciąż piszemy przy użyciu klawiatury, a nie czegoś bardziej "fikuśnego"?4\/3!!

mickpr · Answer

Samo kliknięcie tak... Przygotowanie trwa nieco dłużej>Chętnie się dowiem o tym, jeśli możesz to napisać Tutaj się zgodzę. masz rację. Wiedza jest konieczna i tu i tu, zgadzam się.Przecież raz stworzony projekt w Eclipse można wyeksportować (jako swój "szablon") i zaimportować kiedy dusza zapragnie.Może dlatego, że odpowiednio skonstruowany Makefile (czytaj: którego stworzenie trochę trwało) teoretycznie nie ma takich ograniczeń, jak "plugin-klikaniec". Tutaj się zgodzę, ale dalej uważam, że klikanie jest prostsze

Freddie Chopin · Answer

No ale przecież projekt (i debuggowanie) w Keilu też się sam nie konfiguruje, no nie? (;Wtyczka nazywa się Embedded Systems Register View (embsysregview). Jej ustawienie jest nieco nieporęczne (w sensie opcje są schowane GŁEBOKO w opcjach Eclipse, wtyczka nie trzyma ustawień w projekcie, tylko są globalne, a włączenie zakładki tej wtyczki też jest schowane dosyć głęboko), ale działa całkiem dobrze i ma bardzo fajne opcje (np. interpretacje wartości pól bitowych).http://embsysregview.sourceforge.net/Przecież w tym temacie własnie jest mowa o problemie z takim czymś [; Stosując Makefile eliminujesz kilka niewiadomych z procesu kompilacji (Eclipse, wtyczki, ...) zostawiając tylko kompilator, make i shella...4\/3!!

mickpr · Answer

Zdając się na twój dobry gust - warto nią używać, czy się np. potrafi wykrzaczyć?Nie ma moich Cortex M0 z NXP

Freddie Chopin · Answer

U mnie nigdy się nic nie wykrzaczyło przez nią - jak mam potrzebę patrzeć co jest w rejestrach to wtyczka jak znalazł (choć w sumie rzadko mam taką potrzebę). Tak więc spokojnie można używać (;No nie ma, ale nic nie stoi na przeszkodzie żebyś dodał (;EDIT:Z tego co rozumiem do programu można teraz dodawać plik typu SVD (cokolwiek to jest) i na tej stronce http://www.lpcware.com/gfiles/all?tid_1%5B%5D=58 takie pliki SVD dla układów z rodziny LPC11xx są do pobrania [;4\/3!!

B0BI · Answer

Wszystko jest fajnie, o ile posiada się stosowną wiedzę. Dopiero dzisiaj miałem czas żeby zabrać się za przerobienie pliku Makefile Freddiego, ale napotykam te same problemy co przy konfiguracji wtyczki. Pierwsza sprawa, sekcja "toolchain configuration", tu akurat na szczęście wiedziałem, że pod linuksem opcję RM trzeba zmienić z "cs-rm -r" na "rm -f" ale, o ile dobrze pamiętam, to nie wiedziałem o tym przy pierwszej konfiguracji i możliwe, że to był powód zainstalowania wtyczki. Kolejna rzecz, to dodawanie ścieżek. Jeśli projekt jest prosty, faktycznie nie ma problemu, ale ja mam dwa podkatalogi ze źródłami i nagłówkami i teraz nie wiem, czy powinienem je wpisać w opcji "INC_DIRS", "LIB_DIRS", "LIBS" czy "SRCS_DIRS". W zasadzie, metodą prób i błędów można by było łatwo do tego dojść, ale trzeba także wiedzieć jak dodać ścieżki, tzn czy przed nazwą "katalog" należy wstawić /katalog czy ./katalog czy ../katalog czy po prostu katalog, oraz jak oddzielać różne katalogi. Następny problem to definicje "C_DEFS" też zastanawiałem się nad tym przy konfiguracji wtyczki, czy powinienem coś tam wpisywać, czy nie. W linku który podałem kilka postów wyżej, według instrukcji autora należało wpisać tam jakieś opcje, ale też nie wiem czy są one konieczne bo i tak, tamta instrukcja mi nie pomogła.
Podsumowując, dla kogoś kto posiada wiedzę potrzebną w zasadzie tylko do skonfigurowania tak rozbitego na różne podprogramy środowiska, nie będzie stanowiło problemu jego uruchomienie w ciągu kilku godzin, łącznie z postawieniem sytemu i ściągnięciem oprogramowania, oraz bez względu czy jest to wtyczka, czy gotowy Makefile. Tylko kwestia osobistych preferencji. Ja niestety nie znalazłem szczegółowych informacji zgromadzonych w jednym miejscu, a zwłaszcza pod swój procesor i dlatego grzebię się z tym już od paru miesięcy z mniejszymi bądź większymi przerwami i co chwilę napotykam nowe problemy.

mickpr · Answer

Odpowiem tak. Kolega Freddie Chopin ma rację, licencja Keila na rok kosztuje ponad 16 tysięcy. Bazując na środowisku darmowym, będziesz miał trochę do nauczenia. Wszystko da się zrobić.Co do przykładów, ściągnij sobie przykłady (środowisko też) płyty OLIMEX-u z tym mikrokontrolerem. https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/Jest co prawda oparte o stary toolchain i stare Eclipse - ale instalujesz i działa (Windows).Włącznie z debugowaniem.

B0BI · Answer

W profesjonalnym zastosowaniu i w większej firmie, gdzie naprawdę liczy się czas i zabawa z konfiguracją tak rozbitego środowiska była by totalnym nieporozumieniem, zdecydowanie jestem zwolennikiem gotowych środowisk typu Keil czy IAR. Aktualnie nie jestem w stanie sobie pozwolić na taki koszt, dlatego bazuję na środowisku darmowym, pomimo poświęconego czasu.

A wracając do tematu, o dziwo udało mi się skompilować program z plikiem Makefile Freddiego, co prawda sypie błędami typu: "Type 'uint8_t' could not be resolved", czy "Unresolved inclusion: <stdlib.h>", ale o dziwo działa. Przypuszczam, że trzeba poprawić Makefile ale jeszcze nie wiem jak. Tak czy inaczej poszło zdecydowanie szybciej niż z tą wtyczką.

Freddie Chopin · Answer

Powiem tak - ja odpowiem na KAŻDE Twoje pytanie i pomogę Ci rozwiązać KAŻDY problem na jaki napotkasz (w ramach mojej wiedzy oczywiście), jedyne co musisz wykazać to trochę bardziej optymistyczne nastawienie (; Bo wymieniać problemy wielu rozwiązań to każdy może długo (;Po pierwsze nie jest to prawdą - wiele firm używa rozwiązań opartych na GCC. Po drugie zaś, firma może być duza, zastosowanie profesjonalne, ale jeśli za sam kompilator na rok, na jedno stanowisko masz wydać 4000€, to raczej musi być mowa o naprawdę DUŻEJ firmie, żeby mogła sobie pozwolić na wywalenie takiej kasy bo pracownik nie jest w stanie ogarnąć konfiguracji która zajmuje (z ręką na sercu!) jakieś 15 minut... Ja osobiście liczę sobie to tak - 4000€ to ~3 miesięczna pensja pracownika (wliczam koszty pracodawcy). Jakoś nie widzi mi się, aby ten program w ciągu 12 miesięcy był w stanie zaoszczędzić mi 3 miesięcy (1/4) pracy...told you (;To nie są błędy kompilatora tylko błędy wykrywane przez statyczną analizę kodu w Eclipse. Nie wiem jak podszedłeś do całej sprawy, ale coś mi się wydaje, że nie zaimportowałeś mojego projektu, a to najlepszy sposób aby mieć ustawione wszystkie opcje... Jak coś to moge Ci opisać jak to ustawić, ale prościej będzie jak sobie ten projekt zaimportujesz (choćby jako inny projekt) i zobaczysz jak jest ustawiony (+ opis z mojej strony).4\/3!!

B0BI · Answer

Serdecznie dziękuję, niestety ja już tak mam, że zanim kogoś poproszę o pomoc walczę z problemem nawet miesiącami, ale chyba najwyższy czas to zmienić.Z całą pewnością. Tylko czy licencja Eclipse, GNU i opencocd pozwala na jego wykorzystywanie komercyjne? Osobiście znam firmy, które używają scracowanego Keil-a, czy IAR, no ale takie rzeczy (prawie) tylko w Polsce. Szczerze powiedziawszy wolał bym tego nie robić, bo chcę uruchomić swój projekt i właśnie jego zaimportowałem, tyle że wcześniej usunąłem z niego pliki utworzone przez poprzednio skonfigurowane środowisko, tj. pliki .project i .cproject oraz katalog "Debug"

Freddie Chopin · Answer

Możliwe - z pomocą innych pójdzie szybciej. A jak już "zaskoczysz" to wszystko wyda Ci się banalnie proste.Oczywiście - dopóki nie sprzedajesz jako swojej pracy fragmentów kodu gcc, Eclipse czy OpenOCD (nie udostępniając źródeł) (; Wszystkich tych narzędzi możesz używać do tworzenia komercyjnych i zamkniętych projektów bez żadnych ograniczeń.No właśnie kluczem do tego abyś miał wszystkie ustawienia "gotowe" jest import projektu LUB konfiguracja wg opisu z tutoriala (kilkanaście kliknięć) - problem na który napotkałeś wymaga ustawienia opcji Discovery LUB "nowszej wersji discovery" - do pierwsze jest w szablonach i opisie na stronie, to drugie jeszcze nigdzie (bo to nowość od aktualnej wersji Eclipse).4\/3!!