ATNEL tech-forum

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T19:05:20+01:00

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

Statystyki: Napisane przez Zealota — 21 maja 2020, o 19:05

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T19:03:51+01:00

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

Statystyki: Napisane przez matteo9999111 — 21 maja 2020, o 19:03

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T16:44:24+01:00

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.

Statystyki: Napisane przez Zealota — 21 maja 2020, o 16:44

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T16:39:12+01:00

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.

Statystyki: Napisane przez matteo9999111 — 21 maja 2020, o 16:39

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T16:25:58+01:00

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

Statystyki: Napisane przez Zealota — 21 maja 2020, o 16:25

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T15:37:19+01:00

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?

Statystyki: Napisane przez matteo9999111 — 21 maja 2020, o 15:37

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T12:25:41+01:00

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

Statystyki: Napisane przez Zealota — 21 maja 2020, o 12:25

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T10:27:38+01:00

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

Statystyki: Napisane przez matteo9999111 — 21 maja 2020, o 10:27

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-21T00:24:57+01:00

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 [syntax=c]SysTick_Config( 1000 );[/syntax] jest zła, nie uwzględnia aktualnej częstotliwości zegara.

Statystyki: Napisane przez Zealota — 21 maja 2020, o 00:24

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T22:58:13+01:00

Cały projekt z SW4STM32

Statystyki: Napisane przez matteo9999111 — 20 maja 2020, o 22:58

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T22:30:17+01:00

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

Statystyki: Napisane przez Zealota — 20 maja 2020, o 22:30

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T22:07:44+01:00

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...

W jaki sposób zobaczyć konfgurację zegara?

Statystyki: Napisane przez matteo9999111 — 20 maja 2020, o 22:07

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T20:38:46+01:00

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.

Statystyki: Napisane przez Zealota — 20 maja 2020, o 20:38

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T19:05:16+01:00

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

Statystyki: Napisane przez matteo9999111 — 20 maja 2020, o 19:05

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T17:17:18+01:00

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

[syntax=c]void SystemClock_Config( void ) {
// Pierwsza faza
/* Enable Prefetch Buffer, Flash 1 wait state */
FLASH->ACR |=
FLASH_ACR_PRFTBE
|FLASH_ACR_LATENCY
;
RCC->CFGR |= RCC_CFGR_PLLMUL12;// PLLCLK = HSI/2 * 12 = 48 MHz

RCC->CR |= RCC_CR_PLLON;// Enable PLL
while( (RCC->CR & RCC_CR_PLLRDY) == 0 ){}// Wait till PLL is ready

RCC->CFGR |= RCC_CFGR_SW_PLL;// Select PLL as system clock source
while ( (RCC->CFGR & RCC_CFGR_SWS )
!= RCC_CFGR_SWS_PLL) {}// Wait till PLL is used as system clock source
// Druga faza
SystemCoreClockUpdate();
// Trzecia faza
SysTick_Config( SystemCoreClock / 1000 ); // Systick ustawiony na 1000 Hz (1 ms)
}[/syntax]

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:
[syntax=c]#define HSE_VALUE ((uint32_t)8000000)
#define HSI_VALUE ((uint32_t)8000000)[/syntax]
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.

Statystyki: Napisane przez Zealota — 20 maja 2020, o 17:17

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T16:25:55+01:00

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?

Statystyki: Napisane przez matteo9999111 — 20 maja 2020, o 16:25

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T15:01:11+01:00

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

Statystyki: Napisane przez jez2000 — 20 maja 2020, o 15:01

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T14:13:20+01:00

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:

Statystyki: Napisane przez matteo9999111 — 20 maja 2020, o 14:13

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T09:16:39+01:00

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

Statystyki: Napisane przez mirekk36 — 20 maja 2020, o 09:16

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-20T05:11:34+01:00

W SW4STM32 nie musisz nic konfigurowac

Statystyki: Napisane przez jez2000 — 20 maja 2020, o 05:11

Re: Środowisko programistyczne pod ARM (STM32)

2020-05-19T22:49:39+01:00

Statystyki: Napisane przez matteo9999111 — 19 maja 2020, o 22:49

Re: Środowisko programistyczne pod ARM (STM32)

2020-02-24T15:37:12+01:00

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

Statystyki: Napisane przez Nef — 24 lut 2020, o 15:37

Re: Środowisko programistyczne pod ARM (STM32)

2020-02-24T14:44:49+01:00

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.

Statystyki: Napisane przez elvis — 24 lut 2020, o 14:44

Re: Środowisko programistyczne pod ARM (STM32)

2020-02-24T14:25:00+01:00

wat1970 napisał(a):

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

Statystyki: Napisane przez Nef — 24 lut 2020, o 14:25

Re: Środowisko programistyczne pod ARM (STM32)

2020-02-23T14:37:44+01:00

Statystyki: Napisane przez wat1970 — 23 lut 2020, o 14:37