Toolchain dla STM32 - różnice

[vp32]

Cześć Wszystkim.

Od pewnego czasu zacząłem interesować się i "bawić" ARMami, głownie STM32.

Jest to dla mnie pewna nowość i ostatnio nieźle się zamotałem w informacjach jakie znalazłem.

Jest chyba kilka kompilatorów dla ARMów.

Czym różną się WinARM,  arm-gcc, arm-eabi (gnuarm)

Jeśli cos  pomieszałem to przepraszam, ale właśnie   chciałbym sobie to uporządkować,

I jeszcze jedna ważna dla mnie sprawa. W AVRach lubiłem korzystać z symulatora pracy programu, głownie po to aby zobaczyć jak wykonują się na proste obliczenia.

Wiem że ARMy są bardziej złożone i symulacja jest  trudna bo rozbita, niemniej jest fajna, czy jest coś podobnego dla ARMów. Keil ma symulator ale wolę coś co nie ma ograniczeń.

z góry dzięki za wyrozumiałość dla "adepta"😃

 

Edytowano Luty 15, 2020 przez vp32

[Anonim]

Po co Ci symulator kiedy jest dbg server? Kompilujesz program i wgrywasz wsad co uruchamia jednocześnie debuger a tam masz już wszystko w osobnych okienkach - break pointy, zawartość zmiennych, stany bitów w rejestrach, wygenerowany kod asm, pracę krokową na kodzie c/c++ i wiele innych ciekawych rzeczy a do tego można dociągnąć dodatkowe funkcjonalności i oprogramowanie jak Percepio czy STMstudio. Mam tu rzecz jasna na myśli IDE oparte o eclipse które zazwyczaj korzystają z gcc. Różnica jest jak między modelami samochodów osobowych a wszystkie jeżdżą i nawet wyglądają podobnie więc dla celów hobbystycznych nie widzę sensu się w to zagłębiać. Jeśli jednak aż tak bardzo Cię nurtują te różnice to powinieneś przeczytać dokumentacje każdego z tych kompilatorów, dowiesz się wtedy jakie są różnice między nimi. Życzymy miłej lektury 😜

[vp32]

Lektura pewnie sroga. Chodzi mi w ogóle jaki są te kompilatory i ich nazwy, czy to to samo czy co innego? (np GNU = GCC?)

Z tym eclipse mam pewien problem, za nic nie potrafię tego debuggera rozgryźć, na razie próbuję go ogarnąć. Nie wiem skąd Wy się uczyliście jego?

[Anonim]

GNU to publiczna licencja a GCC to GNU Compiller Collection w odróżnieniu od komercyjnych aleternatyw.  Taka różnica jak linux i windows w skrócie.

17 minut temu, vp32 napisał:

Z tym eclipse mam pewien problem, za nic nie potrafię tego debuggera rozgryźć, na razie próbuję go ogarnąć. Nie wiem skąd Wy się uczyliście jego?

Samo się nie zrobi, żeby coś zrobić trzeba robić. Pytaj o to czego nie wiesz, ktoś na pewno odpowie.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[vp32]

Pozwoliłeś 😃

Ma nadzieję że nie zamęczę.

Na początek coś takiego. Czy można w STMCubeIDE wgrać do uC program bez uruchamiania debuggera? W tej chwili wygląda to tak, że po kompilacji muszę ikona degug wejść w tryb debug, nacisnąć start (ta strzałka czerwona). dopiero działa. jak dan stop (kwadrat) to staje. muszę albo reset nacisnąć w uC albo odłączyć od portu USB płytkę (to samo oczywiście co reset). Ale jak coś się zmieni w programie to aby wgrać raz jeszcze ręcznie muszę usunąć plik elf. inaczej nie wchodzi w tryb debug.

Jaki macie sposób na to?

[Anonim]

Osobiście nie używam STMCubeIDE tylko SW4STM32 ale zawsze możesz wgrać wsad do procka przez np STM32 ST-Link Utility tylko nie wiem jaki masz z wyłączeniem debugera problem.  Lepszym pytaniem byłoby raczej jak włączyć debuger nie ładując flasha ;)

Dziwne, że musisz ręcznie usuwać plik elf, po jakichkolwiek zmianach w plikach należy raz jeszcze skompilować program ale włączając debuger IDE powinno samo wykryć zmiany i zapytać o kompilację lub przeprowadzić ją z automatu. Może to zależeć od ustawień w opcjach. 

Najlepiej będzie jednak kiedy wypowie się ktoś, kto używa STMCubeIDE.

[Matthew11]

10 godzin temu, vp32 napisał:

Czy można w STMCubeIDE wgrać do uC program bez uruchamiania debuggera?

Na razie przycisk Run nie jest dostępny. Jest to znane ograniczenie w STMCubeIDE, tutaj przeczytamy: "The [Run] button is not yet implemented and has therefore been hidden from the toolbar menu and Run menu."

Edytowano Luty 18, 2020 przez Matthew11

[Zealota]

5 godzin temu, Matthew11 napisał:

15 godzin temu, vp32 napisał:

Czy można w STMCubeIDE wgrać do uC program bez uruchamiania debuggera?

Na razie przycisk Run nie jest dostępny. Jest to znane ograniczenie w STMCubeIDE

To "ograniczenie" dla niektórych to tylko pożądana cecha środowiska (pewnie tych "przyzwyczajonych"), bezpośrednio pochodzi już z Atollic True Studio. Osobiście ta filozofia również i mnie przeszkadzała od samego początku pracy z ATS, dlatego też wolałem pracować w System Workbench for STM32.

Niemniej jednak ma swoje pozytywne cechy jeśli skorzystamy z pewnego obejścia, modyfikacji skryptu GDB.  Należy skrypt tak zmodyfikować, żeby podczas debuggowania pomijać pierwszy breakpoint na funkcji main, co powoduje, że mamy efekt całkiem podobny do pracy z Run w SW, tzn. od razu mamy możliwość podglądu jak działa urządzenie - bo w końcu spojrzenie na urządzenia to najczęściej najlepsze debuggowanie 🙂

Takie rozwiązanie ma jedną istotną zaletę, w każdej chwili można włączyć breakpointy (ze skrótu lub myszki) i przejść do trybu debuggowania, a potem z niego wyjść jeśli jest taka konieczność. Inna istotna zaleta, że w dowolnej chwili pracy serwera GDB można jednym skrótem klawiszowym, bez zatrzymywania serwera - po modyfikacji kodu, "zresetartować" GDB i pracować po kolejnej kompilacji właściwie "bez przerwy". Praktyczny efekt u mnie wygląda tak, że sobie właściwie tylko naciskam F12 (debug) i modyfikuję kod niejako w "czasie rzeczywistym". Bardzo wygodna praca, dużo bardziej ergonomiczna niż kombinacja Run/Debug w System Workbench. Wg mnie warto wypróbować choć też jest jedna drobna wada - modyfikację skryptu należy tworzyć dla każdego nowego projektu.

[vp32]

Chyba muszę zacząć od początku. Ten STM32Cube mnie trochę przeraża bo jest tylko na 64bity i w domu już sobie nie poćwiczę.

Poinstalowałem MDK-ARM 5 tak do testów, oraz SW4STM32 a także Atolic TreStudio. I teraz zaczęły się schody. To były na razie testy tak na ślepo, a nóż zadziała.

Mam ST-Linka na płytce od KAMAMI, mam J-linka EDU (była tania). Na Keilu oba pracują i łącza się bez problemu, a SW4STM32 i Atolic raz że ciężko się połączyć z uC to jeszcze wystukają błędy.

Takie pytanie, dlaczego w SW4STM32 nie ma wyboru typu Debuggera tak jak w Atolic.? Zrzut ekranu mojego SW4STM32.

Chciałbym zacząć od początku bo się już gubię. Jak ustawić środowisko do pracy? A może spróbować z Eclipse?

Możecie mi powiedzieć z co Wy robicie aby się połączyć z uC, jaki sprzęt.

A... i jeszcze jedno, jaki program debuggera nie sprawia problemów, bo czytałem że jest OpenOCD i jakiś GDBServer. Bo zarówno Atollic jak i SW4STM32 mają u mnie problem z połączeniem to już ten debugger w STM32Cube z ST-Linkiem (tym samym) łączy się bez problemu.

 

[SOYER]

jak to czytam, to mi się odechciewa tych STM... 😉

[Zealota]

8 minut temu, SOYER napisał:

jak to czytam, to mi się odechciewa tych STM... 😉

No tak mnie też się już Ich odechciewa jak to czytam 🙂

@vp32, nie obraź się, ale Twój ostatni wpis to po prostu takie "błądzenie ślepego po ciemku", ale nie ma się co dziwić to normalna reakcja każdego kto chwyta się czegoś nowego, czego nie zna i nie rozumie. Następuje projekcja wyobrażeń, które nie mają logicznego uzasadnienia. Również i ja tak do tego podchodziłem

- dlaczego sądzisz, że Atollic i SW4STM32 muszą mieć takie same typy debuggera? Przecież to są różne programy, o różnych założeniach.

- czemu piszesz "może spróbować z Eclipse?" Przecież wszystkie te narzędzia, które wymieniłeś, oprócz MDK-ARM to właśnie Eclipse.

- po co zainstalowałeś 500 programów do "jednego procesora"

I tylko nie odpowiadaj na nie, bo w tej fazie to nie ma sensu - dlaczego, to napisałem w drugim akapicie 🙂

A teraz już merytorycznie.

SW4STM32 będzie działać od strzała na płytkach Nucleo i Discovery, bo jest przystosowany do oryginalnego ST-linka z wyprowadzonym resetem sprzętowym - z klonami ST-linka nie zadziała od razu, należy wyedytować plik .cfg, który jest konfiguratorem  OpenOCD - w tym screenie co rzuciłeś w ostatnim poście - należy wybrać "User Defined" i w pliku cfg, który po pierwszym uruchomieniu debuggera, dla każdego nowego projektu, zostanie utworzony w katalogu głównym projektu, zakomentować linię, którą wytłuściłem:

# STlink Debug clock frequency
set CLOCK_FREQ 8000

# use hardware reset, connect under reset
# connect_assert_srst needed if low power mode application running (WFI...)
#reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1

W ten sposób OpenOCD nie korzysta ze sprzętowego resetu, tylko programowego. 

To właściwie tyle, mamy działający SWSTM32 z klonami ST-linka. To wystarczy, do pracy z STM32. Skup się na jednym środowisku, zacznij je poznawać. Z każdą chwilą będziesz lepiej to ogarniał. Nie zbaczaj do innego środowiska, jak tylko pojawią się niejasności, pytaj, na pewno na Forbocie ktoś Ci pomoże.
 

[vp32]

7 minut temu, Zealota napisał:

No tak mnie też się już Ich odechciewa jak to czytam

Ale w sensie że mam głupie problemy, czy ze to takie proste as ja taki głupi i nie ogarniam, czy z tymi STMami tak zamotali ze mało kto wie o co chodzi?

Ktora wersja prawdziwa - wszystkie? Wiem ze ja potrzebuje odrobinę cierpliwości od Was - please o to 🥺

[Zealota]

4 minuty temu, vp32 napisał:

le w sensie że mam głupie problemy, czy ze to takie proste as ja taki głupi i

W żadnym z "tych sensów", jeszcze jestem na początku drogi z STM32, że bardzo dobrze pamiętam, iż miałem dokładnie takie same problemy, a mój wpis miał trochę wstrząsnąć i zmusić do intensywnej pracy. Najlepiej mieć dużo samozaparcia i intensywnie drążyć temat, oczywiście nie każdy ma tyle cierpliwości, czasu itp. ale to jedna z dróg. Druga to robić swoje, ale zarazem nie bać się pytać. Trzeba pamiętać, że programowanie to nie jest łatwy temat dla każdego, jak to przyszło się twierdzić przy okazji zjawiska zwanego "arduino". Swoje frycowe trzeba zapłacić 🙂 No dość już tego mędrkowania, a Kolega do roboty 🙂 

[vp32]

Dobra, dzięki za motywację. Mam nadzieję że jak piszesz do roboty to nie chodzi o "daj sobie spokój i nie pytaj" bo....

Zealota -> instalacja tych środowisk była spowodowana dość prostą sprawą, testem, chciałem zobaczyć jak każde środowisko wygląda i jak się z nim pracuje. Jak ni działał mi debugger to chciałem zobaczyć czy to wina jakiś ustawień programu czy sprzętu. CubeIDE mi się dość podoba, jest przyjazny, ale ma ta wadę która mnie zniechęca do tego - system 64bitowy. ja wiem, powiecie w dzisiejszych czasach 64bity to podstawa i nie warto instalować 32 bitowego sytemu. Może to kwestia przekonania się ale na razie musi zostać 32.

Tak wracając do tematu. Jak udało mi się połączyć poprzez ST-LINKa z płytką, debugger pracuje. tylko czy na pewno ja to dobrze rozumiem.

Coś tam na szybko skrobnąłem (odczyt pinu i wartość odczytana na inny pin) . Pytanie czy jak jest debugger włączony to wartości odczytane i zapisane na porcie powinny się pojawiać na żywo w rejestrach na zielono. w tych miejscach co się podświetlone na żółto .Wg mnie tak. lecz żadnej reakcji nie mam w oknach rejestrów. nawet ustawienie pułapki nic nie daje. Jeszcze nie wiem co jest nie tak.

Uprzedzając pytanie - nacisnąłem "zieloną strzałkę w prawo" Resume (F8)

 

 

[Anonim]

Dodam od siebie tylko, że najbardziej lubię Atolica mimo, że jest problem z klonami STM ale to zupełnie inny temat. Po kolei robię mniej więcej tak:

Włączam CubeMX i wyklikuję w nim konfigurację procka (koniecznie dbg wire trzeba włączyć ), w ustawieniach projektu MX wybieram ATOLIC i generuję projekt. Większość opcji w atolicu jest podobna do SW4 ale są drobne niuanse o części z nich napisałem nawet TOPIC o debugowaniu żeby było dla potomności albo dla mnie jak będę miał przerwę od elektroniki.

CubeMX sam ustawia projekt i generuje pliki inicjalizacyjne które wystarczy później dowolnie edytować w miejscach do tego przeznaczonych (pomiędzy komentarzami wygenerowanymi przez MX) dzięki czemu po zmianie konfiguracji procka i wygenerowaniu projektu ponownie kod napisany w tych miejscach nie jest usuwany.

Ogólnie nie mam żadnych problemów z debugowaniem i programowaniem, kwestia jedynie obycia ze środowiskiem, wszystko hula świetnie a w atolicu nawet lepiej niż w SW4 poza kwestią tych wspomnianych klonów.

 

Warto też nadpisać sobie funkcję io weak void _write dzięki czemu funkcja printf() wysyła tekst od razu na uart co dodatkowo ułatwie debugowanie.