ATNEL tech-forum
https://forum.atnel.pl/

Środowisko programistyczne pod ARM (STM32)
https://forum.atnel.pl/topic22853-30.html
Strona 2 z 2

Autor:  gizmo5418 [ 19 lut 2020, o 22:57 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Tworzysz projekt w istniejącej solucji, podając ścieżkę do niej.

Autor:  wat1970 [ 20 lut 2020, o 14:59 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Nic ci się nie kasuje, w każdym momencie możesz wrócić do starego Solution , on tylko znika z widoku przy utworzeniu nowego. Solution to kontener na wiele projektów . Tu masz fragment z dokumentacji o Solution :

Obrazek

Przy tworzeniu nowego projektu jesteś pytany czy ma być utworzony w nowym Solution czy dołączony do bieżącego Solution w widoku.

A poniżej masz dla przykładu kod (bez użycia HAL) migania LED-em bez delay-i, to dla M3 jaki mam na stole.

Obrazek

Życzę miłej zabawy.

Autor:  wat1970 [ 23 lut 2020, o 14:37 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Tu ciekawe info na temat IDE SEGGER https://mikrokontroler.pl/2020/02/21/segger-opublikowal-zoptymalizowany-kompilator-dla-ukladow-arm/
Moim zdaniem i tak bez tej tej optymalizacji kompilatora był on fenomenalny.

Autor:  Nef [ 24 lut 2020, o 14:25 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

wat1970 napisał(a):
Tu ciekawe info na temat IDE SEGGER https://mikrokontroler.pl/2020/02/21/segger-opublikowal-zoptymalizowany-kompilator-dla-ukladow-arm/
Moim zdaniem i tak bez tej tej optymalizacji kompilatora był on fenomenalny.



Jakie standardy C i C++ ten kompilator obsługuje? wiesz może?

Autor:  elvis [ 24 lut 2020, o 14:44 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Nef napisał(a):
wat1970 napisał(a):
Tu ciekawe info na temat IDE SEGGER https://mikrokontroler.pl/2020/02/21/segger-opublikowal-zoptymalizowany-kompilator-dla-ukladow-arm/
Moim zdaniem i tak bez tej tej optymalizacji kompilatora był on fenomenalny.



Jakie standardy C i C++ ten kompilator obsługuje? wiesz może?


Przecież to zwykły clang, segger "zoptymalizował" go trochę i próbuje zarabiać na naiwności programistów.

Autor:  Nef [ 24 lut 2020, o 15:37 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

elvis napisał(a):
Przecież to zwykły clang, segger "zoptymalizował" go trochę i próbuje zarabiać na naiwności programistów.


ja i tak chyba wolę gnu toolchain

Autor:  matteo9999111 [ 19 maja 2020, o 22:49 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Niestety po paru miesiącach użytkowania seggera z dnia na dzień coraz bardziej mnie denerwuje. Najprawdopodobniej jest to spowodowane moim przyzwyczajeniem do eclipsa. Stąd moje pytanie. Wie ktoś jak skonfigurować środowisko eclipse / SW4STM32 lub coś podobnego do pisania na rejestrach dla STM32?

Autor:  jez2000 [ 20 maja 2020, o 05:11 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

W SW4STM32 nie musisz nic konfigurowac

Autor:  mirekk36 [ 20 maja 2020, o 09:16 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

matteo9999111 napisał(a):
Niestety po paru miesiącach użytkowania seggera z dnia na dzień coraz bardziej mnie denerwuje. Najprawdopodobniej jest to spowodowane moim przyzwyczajeniem do eclipsa. Stąd moje pytanie. Wie ktoś jak skonfigurować środowisko eclipse / SW4STM32 lub coś podobnego do pisania na rejestrach dla STM32?

Atolic TrueStudio to w zasadzie Eclipse ;)

Autor:  matteo9999111 [ 20 maja 2020, o 14:13 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

jez2000 napisał(a):
W SW4STM32 nie musisz nic konfigurowac


Właśnie zainstalowałem sobie to środowisko tylko chyba nie do końca wiem jak dodać projekt pod rejestry. Spróbowałem iść tą drogą: new -> C project -> empty project , Ac6STM32 MCU GCC -> "wybieram uC" -> No firmware. Następnie skopiowałem prosty program działający w Segerze i zaskoczenie - wywala mi pełno błędów. Wygląda to tak jak na poniższym zdjęciu:
Obrazek

Autor:  jez2000 [ 20 maja 2020, o 15:01 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Brakuje ci plikow CMSIS. Utwórz projekt z std i z niego skopiuj ten katalog

Autor:  matteo9999111 [ 20 maja 2020, o 16:25 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Rejestry działają, program się wgrywa. Tylko systick wykonuje przerwanie tak na oko z 5 razy wieksza częstotliwością. Czy tutaj trzeba również ustawiać jakoś częstotoliwość w programie jak miało to miejsce w AVR?

Autor:  Zealota [ 20 maja 2020, o 17:17 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Seria STM32 została tworzona pod kątem oszczędności energii. Stąd m.in. tak rozbudowana topologia zegarów, która umożliwia zmianę zegarów w locie.
To zasadnicza różnica np w stosunku do AVR z serii ATmega czy ATtiny, zatem podejście musi być zupełnie inne. Jakikolwiek sens traci ustawianie na sztywno zegarów poprzez opcje kompilatora. Zatem porównanie do AVR czy też Eclipse-avr traci sens. Musisz zacząć uczyć się tego na nowo.

Dla początkującego istotny będzie CMSIS jako podstawowe API do zarządzania programowaniem. Oprócz nagłówków dot. rejestrów jest też wyższa warstwa abstrakcyjna, która warto znać i używać.
Dla łatwiejszego zrozumienia podam przykład dla serii STM32F0

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Konfigurację zegarów robię zwykle w 3 fazach.
1. Ustawienie rejestrów
2. Uaktualnienie zmiennych
3. Konfiguracja zegara Systick

Jak widać mamy tutaj dwie funkcje oraz jedną zmienną globalną SystemCoreClock.
To zupełnie inaczej niż w AVR. W tym przypadku nie ustawiamy flagi globalnej F_CPU, ale wartość zegara "trzymana" jest w zmiennej globalnej, która jest zdefiniowana poprzez API CMSIS. Pomińmy w tym momencie sprawę problemu zmiennych globalnych, można mieć moim zdaniem zaufanie do twórców CMSIS, że tak to wybrali. Jeśli komuś nie pasuje to zawsze można napisać funkcje/metody żeby wartość zegara obliczać z rejestrów.

Pisząc w skrócie, korzystając z CMSIS dostajemy szablony plików, m.in. funkcję SystemInit(), która wstępnie ustawia zegary na domyślny zgodny dla danej rodziny z zegarem HSI. Można to zawsze podglądnąć np. debugerze, sprawdzając wartość zmiennej globalnej SystemCoreClock. Jeśli ktoś nie lubi debugera, może sobie zegar wyprowadzić na pin i zmierzyć - ale po co się tak męczyć :)
Ja dodatkowo wprowadzam:
4. Faza czwarta (dodatkowa) - za pomocą Systick tworzę timer programowy o podstawie 1 ms i ustawiam miganie diodą na 1000 ms
To nie całkiem dokładna metoda, ale zgrubnie wystarcza.

Warto tez zasygnalizować, że w CMSIS są dostępne m.in takie etykiety:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

które są zdefiniowane dla każdej rodziny procesora.

I to tyle i aż tyle :)

A co do Twojego problemu - sprawdź jaką masz częstotliwość zegara - sposoby podałem wyżej.

Autor:  matteo9999111 [ 20 maja 2020, o 19:05 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Nie wiem dlaczego w tej chwili mam taktowanie 100MHz, czyli max. Jak robiłem w seggerze było 16 - czy to może być wina przestawienia się z J-linka? Jak na razie nie chcę zmieniać częstotliwości taktowania uC. Idę równo z "poradnikiem szczywronka" i pewnie do tego dojdę powoli, bo jak na razie nie jestem w stanie zrozumieć co napisałeś w "pierwszej fazie" i dlaczego ustawiać to tak a nie inaczej.

------------------------ [ Dodano po: 42 minutach ]

Najlepsze jest to że zmieniając programator na J-linka (Segger) uC jest taktowany 16MHz

Autor:  Zealota [ 20 maja 2020, o 20:38 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

matteo9999111 napisał(a):
Nie wiem dlaczego w tej chwili mam taktowanie 100MHz, czyli max. Jak robiłem w seggerze było 16 - czy to może być wina przestawienia się z J-linka?

Wg mnie nie. Masz pewnie pochrzanioną konfigurację.
Gdybym miał u siebie wątpliwości to skorzystałbym z CubeMX, skonfigurował zegary, wygenerował projekt w HAL i zobaczył jaki jest zegar.
Oprócz tego wrzuć konfigurację zegara do wątku - skoro twierdzisz ze maks 100 MHz to pewnie STM32F411 lub podobny - mogę twój konfig sprawdzić u siebie na kilku prockach F4 i zobaczyć jaki będzie zegar.

Autor:  matteo9999111 [ 20 maja 2020, o 22:07 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Działąm na STM32F411RET6. Po napisaniu migania diodą w CubeIDE wyświetlił po próbie debugingu mi się błąd połączenia z programatorem. Najciekawsze jest to że dioda zielona na programatorze cały czas świeci jakby się zawiesił czy coś. Wgrałem do niego sterowniki STSW-LINK009 niestety bez skutku. W SW4STM32 wszystko działą tak samo tz debuguje się tylko te taktowanie z kosmosu...
Obrazek
W jaki sposób zobaczyć konfgurację zegara?

Autor:  Zealota [ 20 maja 2020, o 22:30 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

matteo9999111 napisał(a):
W jaki sposób zobaczyć konfgurację zegara?

W pliku main.c powinieneś dostać funkcję void SystemClock_Config( void ), zresztą w moim przykładzie tez korzystam z tej funkcji, podebrałem deklaracje z HALa

matteo9999111 napisał(a):
Po napisaniu migania diodą w CubeIDE wyświetlił po próbie debugingu mi się

To sugeruje, że korzystasz z pinu tego samego gdzie debugger jest podłączony.

Mam wrażenie, że mocno błądzisz - komunikaty są niespójne :) Poczatki zawsze są trudne.
Wrzuć kod który napisałeś, pokaż na czym ćwiczysz, bo inaczej ta konwersacja nie ma sensu, tracimy czas na domysły :)

Autor:  matteo9999111 [ 20 maja 2020, o 22:58 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Cały projekt z SW4STM32

Autor:  Zealota [ 21 maja 2020, o 00:24 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Przeglądnąłem projekt, ale niestety widzę złą drogę jaką obrałeś. Chodzi o Std Periph Library. Oczywiście właściwie z tego nie korzystasz, ale szablony jakie zostały do tego dołączone z konfiguratora są bardzo stare i nie zawierają konfiguracji zegarów w funkcji SystemInit(). Musiałbyś zacząć od konfiguracji zegarów na własną rękę, ale jak bym tego nie robił.
Sprawdź najpierw czy masz aktualny SystemWorkbench - Help->Check for updates. Jeśli nie robiłeś updatów no to faktycznie staroć.
Jeśli zaktualizujesz program, to przy tworzeniu nowego projektu wybierz HAL, zostanie ściągnięty Cube firmware (nie CubeMX) dla danej rodzi procków ze wszystkimi potrzebnymi plikami, będzie tez HAL oraz CMSIS, ale HALa należy usunąć, jeśli chcesz na rejestrach działać, bo po co ten balast :)
W domyślnej konfiguracji procek będzie leciał na 16 MHz, bo taki jest HSI w F411.

W dotychczasowym projekcie, SystemInit był pusty, dlatego też SystemCoreClock pokazywał bzdury w debugerze. Dodatkowo źle ustawiałeś Systick, bo konstrukcja
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
jest zła, nie uwzględnia aktualnej częstotliwości zegara.

Autor:  matteo9999111 [ 21 maja 2020, o 10:27 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Zaktualizowałem SW. Po stworzeniu programu w halu (oczywiście usunąłem HAL_DRIVERS) pokazują mi się błędy kompilacji.
Obrazek

Autor:  Zealota [ 21 maja 2020, o 12:25 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Idzie wszystko do przodu.
Musisz opróżnić wszystko co związane z hal. Jak to zrobić znajdziesz tutaj:
https://www.elektroda.pl/rtvforum/viewt ... 2#17229822

Autor:  matteo9999111 [ 21 maja 2020, o 15:37 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Zrobiłem to trochę inaczej. Chyba z tym SW4STM32 za duzo kombinoania. Ściągnąłem atollica i wszystko działa poprawnie. Tylko czy atollic nie ma ograniczeń związanych z objęością kodu?

Autor:  Zealota [ 21 maja 2020, o 16:25 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Nie ma ograniczeń.
Skoro wszedłeś już w Atollica to CebeIDE powinien u Ciebie zagościć. w ten sposób mógłbyś zakończyc poszukiwanie środowiska do pracy.
Główną zaletą CubeIDE jest to że można zamiennie uzyc GDB oraz OpenOCD jako debuggera oraz, że jest przycisk do bezpośredniego programowania procka (bez debuggowania), tak jak w Eclipse AVR co ułatwia prace wg mnie. Zresztą do Atollica nie bedzie już wsparcia, więc zupełnie nie ma sensu zostawać przy Atollicu - w CubeIDE wcale nie trzeba skorzystać z CubeMX

Autor:  matteo9999111 [ 21 maja 2020, o 16:39 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Próbowałem zrobić w STM32CubeIde projekt na rejestrach, tylko że jeżeli usunę bibliotekę HAL to jest problem bo błędy wyskakują. Ogólnie CubeIDE jest dość ciekawie zrobiony tylko nwm jak mogę w nim pisać na rejestrach.

Autor:  Zealota [ 21 maja 2020, o 16:44 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Opis który podałem do usunięcia hala działa również na CubeIDE.
Spróbuj zrobić jakiś projekt, jak nie wyjdzie to wrzuć na wątek i będziemy poprawiać aż do skutku.

Autor:  matteo9999111 [ 21 maja 2020, o 19:03 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Dzięki za pomoc wszystko działa jak należy :D . Do czego służą pliki syscalls.h i sysmem.h?

Autor:  Zealota [ 21 maja 2020, o 19:05 ]
Tytuł:  Re: Środowisko programistyczne pod ARM (STM32)

Szczerze to nie wiem, zawsze je usuwam :) To pewnie jeszcze nie ten poziom, żeby było mi to potrzebne.

Strona 2 z 2 Strefa czasowa: UTC + 1
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/