Posługując się świetnym opisem z http://sunduino.elektroda.eu/wordpress/ ... rm-part-1/ zainstalowałem (mam nadzieję) dokładnie tak samo jak kolega SunRiver całe środowisko (opis z I części) i dokładnie ten sam mini projekcik utworzyłem - w wyniku otrzymałem skompilowany jeden projekt ale z jednym "warningiem", co widać na obrazku. Widzę że autor też miał jakiś problem ale nie wiem czy ten sam. Co z tym fantem należy zrobić?


------------------------ [ Dodano po: 15 minutach ]

No tak pewnie może to było spowodowane tym ze po instalacji toolchaina i konfiguracji eclipse powinienem przeładować system a może też tym że należało najpierw zrobić "clean" i dopiero "zbudować" projekt? Tak czy tak po przeładowaniu systemu, uruchomieniu clean i ponownym uruchomieniu "build" wszystko przebiegło poprawnie bez uwag i błędów. Zabieram się więc do odcinka drugiego. Aha wszystko to uruchamiam na systemie Win 8.1 64 bit. Proponuje tutaj dyskutować na temat Eclipse dla ARM instalowanym z paczki SunRivera. Całkiem możliwe że sobie będę raz pracował na eclipse a raz na crossworks i zobaczę co mi bardziej pasuje.

dokładnie ten warning jest sobie , ale po cleaningu znika ... cieszę się że ci zadziałało ... jeszcze nad tym pracuję , ale w przypadku frdmki ładnie działa łacznie z debugowaniem , dziś się zajme stlinkiem do kompletu

Kolejne pytanie tym razem dotyczy dodawania debugera, zainstalowałem poprawnie oprogramowanie co sprawdziłem podłączając swojego j-linka ale konfiguracja nie zrobiła mi się jak w poradniku Suna co widać na obrazku poniżej, po lewej moja konfiguracja po prawej referencyjna.


------------------------ [ Dodano po: 5 minutach ]

A dobra, chyba do końca nie zrozumiałem, u mnie z automatu nadała się nazwa "test_blink Debug" (bo taki miałem projekt otwarty) i to po prostu albo można tak zostawić ale lepiej zmienić na przyjazną nazwę?

Ale jest też różnica w zakładce debug w pozycji Executable w referencyjnym obrazku jest pełna ścieżka a u mnie wygląda to nieco inaczej ale zakładam że to też jest ok?

I pytanie dla konfiguracja JLink-OpenSDA mówisz o porcie 2231 a na obrazku jest 2331, gdzie błąd?

---------------------edit---------------
Ścieżkę jednak musiałem zmienić na "pełną" pokazującą dokładnie lokalizację.
I jeszcze jedno pytanie o co chodzi z tą uwagą? co trzeba zmienić aby zniknęła?


Kurcze nikt więcej nie ma pytań, czy ja po prostu za głupi jestem ?

-------edit-----------
No i super pod CrossWorks FRDM-KL25Z zmieniona pod eclipse na JLink-OpenSDA jest też widoczna jako Segger J-Link i ładnie pracuje w trybie Debug

no więc tak port oczywiście 2331 poprawię w tekście
zaś ta uwaga to :

w Confirm perspetive dajesz zapamiętaj decyzję i klikasz na YES
natomiast w przypadku SWO trzeba wyłaczyć je bo twój J-Link SWO nie obsługuje

o tu :



a nazwę konfiga po prostu sobie zmieniasz

i ustaw sobie szybkość na 4000Khz domyslnie jest 1000 trochę wolnawo



jak dopracuję kilka szczegółów to zrobię jakis instalator z autokonfigiem ... ale bez instalowania softu do J-Linka wiadomo licence i takie tam .,..

O dzięki, nie zauważyłem tego w startup, a co do zapamiętania przełączenia widoku to było jasne dla mnie. Co ciekawe dałem port na 2231 jak było w tekście i nie zauważyłem problemów. No ale zmieniłem teraz z powrotem na 2331. 4000kHz oczywiście załączyłem.

spokojnie też się naszukałem bo sie doczepił do czegoś tam ... i marudził

Sun - nie naskrobał być w trzech zdaniach jak zaprogramować fizycznie Kinetis-a korzystając z zestawu FRDM.
Przejrzałem na szybko całą książeczkę, ale wydaje mi się że nie ma tam opisu jak programuje się te uC we własnych urządzeniach.

Wiesz książka dotyczyła FRDM z CW poprzez OpenSDA takie były wytyczne ... i sta czesć materiału nie znalazła
się w książce niestety ....

ale w pozostałych przypadkach można używać zarówno OpenSDA na FRDM do programowania innych Kinetisów ,
jak też używając J-Linka np zresztą będę kontynuował temat na stronce co powoli już się zaczyna dziać wiec wystarczy śledzić.. chwilowo nie używam kinetisów poza FRDM i Kwikstickiem .... no ale widzisz FRDM ma OpenSDA , a kwikstick licencjonowanego Saggera J-Linka

To z niecierpliwością czekam na opis jak za pomocą OpenSDA programować te potworki na własnych płytkach.
Dzięki za info.

na stronie już znajdziesz opis jak sobie zrobić J-Linka z SDA
a SWD masz na J6 na Fredomie

A już mi się wydawało, że jest ok.
Zrobiłem dokładnie taką samą instalację na drugim komputerze (laptopie) z identycznym systemem operacyjnym, dla pewności żebym czegoś nie pominął robiłem po kolei wedle poradnika no i niestety na pierwszym sprawdzeniu czy to kompilacji czy czyszczenia projektu otrzymuję błąd jak na obrazku poniżej, hmm posprawdzałem wszystko jeszcze raz porównując z obrazkami i instalacją na komputerze stacjonarnym i nie widzę różnic a błąd jest. Jest jakiś pomysł co może być źle?

zainstaluj ponownie Gcc z uprawnieniami administratora

Hmm mam nawyk żeby robić z takimi uprawnieniami - sprawdze jeszcze raz to.

czasem coś się źle instaluje tez tak miałem na innym kompie ponowna instalka pomogła , możliwe że jakieś zależności sprzetowo programowe , czegoś nie ma -- wiesz to jednak windows jest ,...

No niestety mimo różnych prób nie udało mi się odpalić na laptopie Eclipse dla ARM, a że potrzebuję na obu kompach tych samych aplikacji pracujących na zmianę na tych samych "projektach" to jednak to IDE u mnie odpada i pozostaje mi CrossWorks, który bez problemu działa na obu komputerach współdzieląc "projekty". Ale była to budująca lekcja i czegoś nowego się nauczyłem, nie będę jednak walczył z oporną materią.

--------------------edit-------------------------
Jeszcze próbuje naprawić system, może to pomoże, ale widać ze to narzędzie w postaci eclipse i toolchaina dla arm bardzo "czułe" jest na jakieś błędy systemowe które nie robią wrażenia na innych aplikacjach

Pytanie czy w konfiguracji jak na obrazku http://sunduino.elektroda.eu/wordpress/ ... anie81.jpg musi być na końcu ${PATH} to powoduje że we właściwościach projektu do ścieżki do toolchaina dokleja mi się cała reszta ścieżki ze zmiennych środowiskowych i to daje błąd (pewnie z powodu winavr) jak wyrzucę ${PATH} to kompilacja idzie bez błędu.

Nie może być, bo byłoby to bez sensu Zmienna wskazywała by samą siebie? Taka rekurencja?


MXST4

Nie jestem znawcą wszystkich ustawień systemowych więc dlatego pytam - dobrze zrozumiałem że nie powinno być tam wpisu ${PATH} ?

co prawda znawcą nie jestem ale w czasach gdy królował DOS (starsze osoby pamiętają ) to ścieżki ustawiało się tak

set PATH=C:\mybin;%PATH%

gdzie %PATH% przedstawiał nam obecne ustawienie ścieżek systemowych i jak sądzę w tym przypadku będzie podobnie, czyli że zmienna PATH ma wskazywać na katalog przez nas wybrany oraz to co przedstawia system...

_________________
ATMEL-ICE+ATXmega256A3BU oraz dużo samozaparcia

wystarczy zerknąć do enviroment ... co podstawiłem do zmiennej PATH ....
i sprawa jest jasna Dokładnie chodzi o Cross Tools czyli polecenia make, rm ... bo ich najzwyczajniej niema w toolchainie

Heh poczekajcie , chyba jestem jednak trochę tępy , bo się gubię, SunRiver pokaż to na zrzucie jeśli możesz. Pisałem Ci że miałem problem na lapku i dopiero zauważyłem że we właściwościach projektu doklaiła mi się cała ścieżka z zmiennych środowiskowych. Jak to skasowałem i skasowałem również ${PATH} to dopiero wszystko ruszyło. Bezpośrednim powodem prawdopodobnie była jedna z bibliotek WinAVR bo to się też dokleiło do ścieżki, na PCcie tego nie miałem problemu bo i nie było WinAVR.

Czy ma być tak jak na obrazku poniżej ? Jak tak wpisałem to mi się cała ścieżka ze zmiennych środowiskowych dopisała (jak oglądnąłem to we właściwościach projektu)


U mnie jest w tej chwili tak, po usunięciu ${PATH} z konfiguracji jak na obrazku wyżej:


A we właściwościach projektu tak: