[STM32]Film/Poradnik o programowaniu STM32 - prośba o opinie.

Cześć.

Chciałbym zaprezentować na forum film/poradnik, który wykonałem. Dotyczy on konfiguracji niezbędnych narzędzi, umożliwiających programowanie mikrokontrolerów STM32. Materiał przygotowałem w dwóch wersjach: polskiej oraz angielskiej.

Celem tego tematu jest zebranie krytycznych opinii na temat omawianego filmu. Chciałbym, aby koledzy, po obejrzeniu materiału, odnieśli się do:
1. Czy przy pomocy filmu udało się stworzyć działające narzędzie?
2. Które momenty w filmie były nieczytelne/za szybkie?
3. Czy film jest kohernetny - czy są miejsca, które odbiegają tematycznie od tematu?
4. Jakie błędy techniczne popełniłem podczas nagrywania (dźwięk, jakość wideo, zrzuty ekranu, wyskakujące okna)?
5. Czy dobrałem dobrą terminologię, jeśli chodzi o nazwy programów?
6. Czy są etapy w filmie, które można pominąć? Czy są takie, które należy dodać?
7. Czy argumenty używane do konfiguracji openocd/gdb są właściwe? Czy można użyć lepszych?
8. Jakie jest ogóle wrażenie, po zapoznaniu się z filmem.

Już teraz dziękuję za wszystkie odpowiedzi. Wierzę, że przyczynią się one do polepszenia tego materiału.

Link do wersji angielskiej
Link do wersji polskiej

Witam "Przedwczesny wytrysk" mnie rozbawił, ale wróćmy do tematu.
1. Mówisz: "Usuń stare archiwum" - jakie stare? Dopiero co pobrane!
2. Wtyczkę GNU ARM lepiej pobierać z poziomu samego Eclipse. Inaczej mogą być problemy z kompatybilnością pobranej wtyczki do wersji Eclipse, a tak - Eclipse sam o to zadba, żebyśmy pobrali prawidłową wersję.
3. Uwaga o instalacji Eclipse - nieco ciszej i widać - że "wklejone".
4. Stwórz nowy projekt "Ce"... chyba powinno się mówić "Si".
5. Ograniczenie się do jednej konfiguracji (Debug) jest IMHO błędem - chyba, że jedynym celem tworzenia projektu jest nauka (a nie stworzenie czegoś "gotowego do produkcji").
6. Mówisz o Bleeding Edge, a wybierasz Yagarto - wytłumacz - dlaczego?
Ja np. używam GNU Tools for ARM Embedded Processors - co jest IMHO - "ładniejszym wyborem". Nieprawdaż?
7. Brak konsekwencji w lokalizacji plików - Wszystko leci na pulpit, a np. Coreutils - na C:\.
8. Parametry debugger'a wytrzasnąłeś nieco z kapelusza - napisz skąd można się dowiedzieć , skąd wziąć przykładowe. Wiem, że konfiguracja OpenOCD i debugger'a nieco wykracza poza ramy tego filmu, ale dobrze by było zasygnalizować - gdzie znaleźć informację o tych dwóch elementach.
9. Dobrze byłoby wspomnieć o linker skryptach - i znów - skierowanie na help od LD, oraz na przykłady.

Tyle na szybko.
A poza tym? Dobry punkt zaczepienia dla początkujących.
Pozdrawiam

Cześć.

Dziekuję za opinię uzytkownika mickpr dotyczącą poradnika. Część uwag wziąłem do serca i wdrożyłem w drugiej wersji filmu.

angielski: How to prepare IDE for STM32?


polski: Jak skonfigurować środowisko programistyczne dla STM32?


Ponawiam prośbę, znajdującą się w pierwszym poście, dotyczącą uwag o poradniku. Na pewno znajdą koledzy wiele błędów lub sugestii - zachęcam do podzielenia się spostrzeżeniami, również natury ogólno-filozoficznej tworzenia poradników internetowych. Dzięki temu wszyscy zyskamy.

Czy można używać kompilatora Keila, a pisać kod programu w Eclipse? Ktoś używa takiego rozwiązania?

mgiro wrote:

Czy można używać kompilatora Keila, a pisać kod programu w Eclipse?

Można ( http://www.keil.com/support/man/docs/ecluv/ ), tylko po co? Jaki tego cel i sens?
Jeśli ktoś ma licencję na KEIL'a, to po co mu pakować się w Eclipse? Dla samego edytora?
Linker skrypty (niestandardowe dodajmy) też będziesz sam "dziergał" w Eclipse?
Keil naprawdę się poprawił (od wersji 4.5x) w tym względzie - a debugger'em bije Eclipse o łeb.
Żeby nie było - że jestem fanem Keil'a - nie jestem.
Nadal uważam, że Eclipse jest bardziej rozwojowe, jedyne co mi brakuje - to dobry debugger (w stylu klik - i działa, a nie wieczne męczarnie z OpenOCD).
Poza tym wybierając Eclipse - toolchain możesz podstawić sobie taki - jaki chcesz, że darmowy - już nawet nie wspomnę.
No i żaden żandarm nie zgarnie cię za to, że nie masz licencji na środowisko, w którym napisałeś sobie amatorsko aplikację.

Tak, właśnie dla samego edytora. Kompilator Keila daje lepiej skopilowany kod. Jak się używa małych procków to jaki jest problem?

mickpr Co masz na myśli mówiąc o Linkerach i skryptach oraz "dziergniu"?

mgiro wrote:

Co masz na myśli mówiąc o Linkerach i skryptach oraz "dziergniu"?

Sam sposób tworzenia konfiguracji projektu i skryptów linker'a jest odmienny, niż ten stosowany w pozostałych toolchainach. Będziesz musiał zagłębić się w dokumentację zamkniętego, komercyjnego Keil'a, która nie udzieli ci odpowiedzi na wszystkie pytania (bo jest "zamknięta").
Tutaj zacznie się twoje "dzierganie", czyli wymyślanie - dlaczego coś, co bez problemu można stworzyć, skonfigurować, skompilować i wgrać w KEIL., w Eclipse+Keil nie wygląda już tak różowo.

Co do kodu generowanego przez Keil powiem tyle, że co prawda Keil sponsorowany jest przez ARM więc wydawać by się mogło, że jest "naj naj" ... koniec i kropka.
Na szczęście tylko "wydawać by się mogło". Większość "zamkniętych" rozwiązań musi gonić te "gorsze darmowe" nie tylko jakością kodu, ale przede wszystkim jakością "pomocy".
Mimo pięknej dokumentacji, niewiele osób będzie w stanie ci pomóc w konkretnych problemach (w porównaniu do istniejących toolchainów opartych na gcc) - gdyż po prostu niewielu stać na Keil'a.
Większość (chciało by się powiedzieć "znakomita większość") używa darmowych rozwiązań - również w firmach, które czasem piracą na Keil-u, piracą na IAR-rze, itd... Ale porównaj ilość projektów w tych środowiskach, do tych stworzonych w Eclipse ( i wszelkiej maści klonach Eclipse jak LPC Xpresso/CooCox itd) i odpowiedź nasunie się sama

Używałem Keil do niezbyt dużych projektów - głównie STM32W108, LPC1112/4. Miałem pokusę przeniesienia trochę większego (LPC1768) projektu na to środowisko (głównie ze względu na debugger'a), ale na szczęście mi "przeszło".

Uważam (ale jest to moje wyłącznie zdanie), że gdyby Eclipse dostał taki interfejs debugger'a jak KEIL, to popyt na tego drugiego zmalał by niemal do zera.

Czasem toczą się podobne dyskusje w kwestii AVR-ów (Atmel Studio vs Eclipse) i tam sytuacja wygląda moim zdaniem identycznie (chodzi głównie o debugger).
Ale oczywiście każdy może mieć własne zdanie i "każda myszka swój ogonek chwali".

dużo roboty na Windowsie z tym jest. w ubuntu mogło to by być tak


Tylko że eclipse w repo jest w wersji 3,8 i nie bardzo da się plugin gnu-arm zainstalować (zostaje poczekać tydzień lub dwa albo pobrać ręcznie tak jak to się robi na windows)

Tak czy siak czy w windows czy w ubuntu plugin Gnu-arm trzeba ręcznie instalować.

http://gnuarmeclipse.livius.net/blog/plugins-install/

Do kursu tylko jedna uwaga. Prawie całą konfigurację gdb masz domyślnie zrobioną w zakładce wyżej



I właściwie jedyne co trzeba wpisać to ścieżkę do konfiguracji openocd. Dla płytki discovery wpis wygląda tak.


W zakładce gdb >> startup masz już load image zaznaczone (odfajkowane) co oznacza, że podczas startu gdb flash mikrokontrolera zaprogramuje się jeszcze raz.
Więc na upartego, konfiguracja external tools jest można powiedzieć zbędna.
Aczkolwiek czasami przydaje się tylko zaprogramować mikrokontroler bez uruchomienia gdb. To już tam każdy dopasuje do swojej wygody