STM32 Jak programować stm32 w LL

[Protektor28]

Cześć

 

Chciałbym dowiedzieć się jak programować stm32 w LL. Jak do tego podejść? 

[FlyingDutch]

Cześć,

może ujawnisz rąbka tajemnicy czym jest LL? Czy chodzi Ci o biblioteki "Low level"?

Jakiego IDE i kompilatora chcesz użyć? Jest wiele  rodzin STM32 - różnią się typem procesora, której z nich dotyczy twoje pytanie?

Pozdrawiam

Edytowano Wrzesień 11, 2018 przez FlyingDutch

[Elvis]

A ja zapytam nie co inaczej - a po co używać biblioteki LL? W sumie używanie rejestrów lub CMSIS jak na nie niektórzy mówią jest tak samo skomplikowane, a chociaż kod efektywniejszy no i nie trzeba czytać dwóch dokumentacji, bo wystarczy nota mikrokontrolera...

[Protektor28]

Dziękuję Wam za szybką odpowiedź 

 

Jestem początkujący, przepraszam za zbyt ogólne pytanie. Elvis , zdaje się, że masz racje. 

Mam problem z tym, jak czytać dokumentacje techniczną STM32. Nie wiem jak się za to zabrać, 

na przykład jak skonfigurować zegar uC oraz peryferia. Wcześniej wszystko robiłem w HALu, 

lecz projekty generowane w HALu, za dużo ważą, stąd chciałbym przejść na LL, a najbardziej pisać na samych rejestrach.

 

Czy jest jakiś odtwórczy schemat pracy na stm32? Moja wersja to STM32L452RE-P. Potrzebuje jakiś 

wskazówek na co patrzeć by uruchomić na przykład USART. Nie mam też czasu na to by czytać cały

reference manual, dlatego prosiłbym Was o pomoc, jak korzystać z dokumentacji STM i jak ją rozumieć.

 

 

[Elvis]

Czytanie całej dokumentacji ma pewną wadę - ciężko zapamiętać prawie 2000 stron :) Moim zdaniem lepiej czytać po jednym rozdziale - np. wybierasz sobie rozdział o GPIO na początek, piszesz programy i sprawdzasz jak działają kolejne rejestry. Później np. przechodzisz do zegara i mając GPIO opanowane możesz przetestować czy faktycznie wszystko działa tak jak oczekiwałeś. I tak rozdział po rozdziale, moduł po module można poznać uC.

Niestety zajmuje to trochę czasu. Warto przy okazji wspomnieć o zaletach HAL - nawet jeśli nie używamy samej biblioteki to warto zobaczyć jak napisany jest jej kod. To pozwala na łatwiejsze zrozumienie danego modułu oraz uniknięcie niepotrzebnych błędów.

[Zealota]

8 godzin temu, Protektor28 napisał:

Dziękuję Wam za szybką odpowiedź 

Jestem początkujący, przepraszam za zbyt ogólne pytanie. Elvis , zdaje się, że masz racje. 

Mam problem z tym, jak czytać dokumentacje techniczną STM32. Nie wiem jak się za to zabrać, 

na przykład jak skonfigurować zegar uC oraz peryferia. Wcześniej wszystko robiłem w HALu, 

lecz projekty generowane w HALu, za dużo ważą, stąd chciałbym przejść na LL, a najbardziej pisać na samych rejestrach.

Czy jest jakiś odtwórczy schemat pracy na stm32? Moja wersja to STM32L452RE-P. Potrzebuje jakiś 

wskazówek na co patrzeć by uruchomić na przykład USART. Nie mam też czasu na to by czytać cały

reference manual, dlatego prosiłbym Was o pomoc, jak korzystać z dokumentacji STM i jak ją rozumieć.

Jeśli chodzi o programowanie "na rejestrach", to wg mnie nie obejdziesz się bez tzw "poradnika Szczywronka":

https://www.elektroda.pl/rtvforum/topic3111562.html

Jest to potężna lektura, dla polskojęzycznych, głównie początkujących programistów STM32, to trochę jak taka biblia, głównie dlatego, że właściwie to nie ma żadnej alternatywy.

Poradnik ten jest oparty na 3 prockach STM32F103, F332 oraz F429. Wyjaśnione są niuanse, jest mnóstwo przykładów, a sam poradnik prowadzi za rączkę. Oczywiście temat jest na tyle obszerny, że wszystkiego nie wyczerpano, ale właściwie to chyba nie masz wyboru  Jest pisany co prawda w osobliwym stylu i nie każdemu może się to podobać.

Jest kilka artykułów w elektronice praktycznej: "32 bity jak najprościej –STM32F0"- znajdziesz w wyszukiwarkach.

Do tego dorzuciłbym RM od STM32f0, głównie dlatego, że z tych popularnych rodzin ze stajni ST,  chyba tylko ten RM posiada w sobie dużą bazę gotowych przykładów napisanych na rejestrach:

https://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf

Ja na swojej drodze przeszedłem od SPL poprzez HAL, aż do pisania na rejestrach. Przy każdej z opcji okropnie się męczyłem, może nawet na rejestrach się męczę najwięcej, ale w ten sposób bardziej poznajemy sprzęt. Definicje rejestrów flag itp, zawarte w nagłówkach CMSIS, to wg mnie wielka robota. W połączeniu z niektórymi funkcjami Eclipse (Ctrl +LeftClick) daje to dużą swobodę w programowaniu, czasami nawet nie trzeba zaglądać do RM. Całość opisana jest z głową i dużą konsekwencją. 

Swoją konsekwencję również mają SPL i HAL, ale to jest jak dla mnie zbyt duża abstrakcja, a dokumentacja jakaś taka "nieokreślona"  

Przy programowaniu na rejestrach warto mieć kontakt z CubeMX, ja często stamtąd generuję projekty, usuwam hala itp, a potem działam dalej. Najczęściej korzystam ze schematu blokowego zegarów - konsekwencja CMSIS pozwala dość sprawnie przeskakiwać z tego schematu do kodu. Oczywiście takie schematy również są w RM, ale tak jest jakoś łatwiej 

Niestety żeby poznać dobrze sprzęt z STM32 trzeba mieć  już pewne doświadczenie w technice cyfrowej głównie. Jeśli ktoś oczekuje, że w parę wieczorów ogarnie jakiś skomplikowany projekt, to może się rozczarować. Czasami rozkminienie jakiegoś "peryfera" to nie jest dzień, wieczór czy weekend. Tylko tydzień jak nie więcej. Warto o tym pamiętać.

Kiedyś nie ogarniałem RM od Atmega8, a teraz 1200 stron od STMF303 nie robi już na mnie wrażenia, co nie oznacza oczywiście, że wszystko wiem, wręcz przeciwnie  Oto chodzi, że z każdą przeczytaną stroną człowiek czuje się coraz lepiej w tym ekosystemie. Oczywiście RM nie można "czytać",  je trzeba "studiować" - nie każdy czuję tę subtelną różnicę. Jak coś nie wiem dziś, zaglądam do dokumentacji jutro. Najważniejsze to przemóc się i pisać powoli najprostsze kody, później stopniowo je komplikować, tak właśnie jest napisany poradnik Szczywronka. Jak to mówił Bear Grylls - wszystko małymi kroczkami  Z czasem wszystko będzie się układało w logiczną całość.

A jak się uczyć? Ćwiczyć, ćwiczyć i jeszcze raz ćwiczyć, do tego nie poddawać się i nie poddawać

"  Nie mam też czasu na to by czytać cały reference manual "

Takie podejście niestety jest sprzeczne z metodyką pracy z tymi mikro-kontrolerami,. Tutaj nie można iść na skróty. Taką drogą na skróty, to wg mnie, jest właśnie HAL, jeśli Tobie nie podszedł bo "za duży kod" to możesz nie mieć innej alternatywy. Niemniej jednak zaglądnij do poradnika, może akurat  będzie przydatny.

 

 

 

 

 

[Luuke]

Dla mnie używanie LL to jak pisanie na rejestrach tylko bardziej czytelne i łatwiejsze w zrozumieniu. Oba wymagają takiego samego zapoznania się z RM.

Dla przykładu poniższe linijki robiące dokładnie to samo:

SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk;
LL_SYSTICK_EnableIT();

Zaglądamy co robi funkcja:

/**
  * @brief  Enable SysTick exception request
  * @rmtoll STK_CTRL     TICKINT       LL_SYSTICK_EnableIT
  * @retval None
  */
__STATIC_INLINE void LL_SYSTICK_EnableIT(void)
{
  SET_BIT(SysTick->CTRL, SysTick_CTRL_TICKINT_Msk);
}

I jeszcze:

#define SET_BIT(REG, BIT)     ((REG) |= (BIT))

 

[Zealota]

 

11 godzin temu, Luuke napisał:

Dla mnie używanie LL to jak pisanie na rejestrach tylko bardziej czytelne i łatwiejsze w zrozumieniu. Oba wymagają takiego samego zapoznania się z RM.

Rozumiem takie podejście, ale uważam, że to podwójna robota, a co do czytelności to sprawa dyskusyjna - etykiety  w CMSIS są pisane z RM i właściwie więcej nie potrzeba.. 

I tak należy zaglądać do RM, a potem szukać metod w LL, a tu jest największy kłopot - błądzenie po omacku, szczególnie na początku, trzeba metodą prób i błędów "odkopywać". Brak jakiejkolwiek dokumentacji - no chyba, że jest inaczej i jej nie poznałem. Znajdziemy trochę przykładów w Cube, ale już nie na wszystkie procki. Jak człowiek się zakręci to właściwie nie ma gdzie szukać pomocy. Wg mnie "pisanie w LL" to martwa uliczka, aczkolwiek podglądanie przykładów może być również przydatne, tylko że szkoda czasu na szukanie.

Gdyby był taki poradnik do LL, jak do "rejestrów", to może zmieniłbym zdanie, a tak to już chyba lepiej z HALa korzystać, bo jednak materiałów na ten temat jest bardzo dużo.

Oczywiście każdy wybierze co mu pasuje...

[Luuke]

Po krótkim czasie można lecieć z pamięci (tak samo jak z każdą inną biblioteką), szczególnie jeśli nie zmieniamy rodziny procka.

Czasem warto nawet zainwestować podwójną robotę. Pisanie na rejestrach wrednie się mści gdy pracujemy w zespole i ktoś inny musi przeczytać to co napisaliśmy. Dlatego często i tak pisze się wrappery do tego typu kodu. Problem pojawi się też gdy sami chcemy przeczytać własny kod po upływie dłuższego czasu. Zrozumienie co dany bit robi w danym rejestrze będzie wymagało ponownego zajrzenia do RM.

Low Level jak najbardziej ma pełną dokumentację, która jest generowana na podstawie komentarzy w kodzie.

 

W jednym się zgadzamy, do RM zajrzeć trzeba :)

 

[Zealota]

Problem z własnym kodem zawsze będzie jeśli będzie kiepski, "goły" i niespójny.

Jeśli zrobię coś takiego:

adcDmaChannel->CPAR = (uint32_t)&ADC1->DR;				// DMA channel x peripheral address register
adcDmaChannel->CMAR = (uint32_t)AdcBuffer;				// DMA channel x memory address register
adcDmaChannel->CNDTR = SAMPLES;							// DMA channel x number of data register
adcDmaChannel->CCR = DMA_CCR_MSIZE_0 | DMA_CCR_PSIZE_1	// PSIZE[1:0] bits (Peripheral size)
					|DMA_CCR_MINC						// Memory increment mode
					|DMA_CCR_EN							// Channel enable
					|DMA_CCR_TCIE						// Transfer complete interrupt enable
					|DMA_CCR_PL_1						// PL[1:0] bits(Channel Priority level)
															// 0b10 high priority level
						;

to nie ma siły, że nie da się tego odczytać, ale kosztem jest dodatkowa robota (komentowanie) - ponieważ to konieczność w programowaniu (komentarz lub samokomentujące się funkcje) - więc i tak nie można tego pominąć.

Komentowanie, z np Eclipse, ma tę zaletę, że poprzez Ctrl+LClick możemy ją zrobić bardzo szybko i przepisać "pomoc" z nagłówków CMSIS, tak jak w powyższym kodzie. Jeśli będzie podobny komentarz, to ktoś kompetentny z zespołu, nie może mieć kłopotów ze zrozumieniem kodu, a jeśli również korzysta z Eclipse lub innego środowiska, które to wspiera podobne usprawnienia, bez komentarza można podglądnąć opis etykiet, który jak już pisałem wyżej jest bardzo spójny i przepisany właściwie z RM. Oczywiście to pewien sposób pracy, jeśli ktoś "tylko klepie linijki" i później liczy na to, że zespół to zrozumie no to nic nie poradzimy .

Pisałeś, o tej samej rodzinie procków, a wg mnie LL po to właśnie wymyślono, żeby można było łatwo skakać z rodziny do rodziny. Funkcje te same, a w środku etykiety od rejestrów właściwych dla danego procesora. Bardzo często nagłówki z CMSIS powielają się, jak choćby rodziny F0 i F3 - obsługę takiego RTC z F303 można właściwie przepisać bezpośrednio do F051.

 

"Low Level jak najbardziej ma pełną dokumentację, która jest generowana na podstawie komentarzy w kodzie"

Wytłumacz proszę, o co tu chodzi, chyba mam jakieś braki, z chęcią uzupełnię - chyba nie tworzy się taki RM z funkcji LL?  Póki co podtrzymuję, że LL w stosunku do HAL, SPL, czy RM jest najsłabsza, ale z chęcią zmienię zdanie.

 

Co do zgadzania się, to trochę jak powiedzenia o świętach  aczkolwiek wytrwała praca, z każdym narzędziem, nawet najsłabszym musi wreszcie przynieść jakieś korzyści, ważne by nie tracić niepotrzebnie czasu.

[Luuke]

10 godzin temu, Zealota napisał:

Pisałeś, o tej samej rodzinie procków, a wg mnie LL po to właśnie wymyślono, żeby można było łatwo skakać z rodziny do rodziny. Funkcje te same, a w środku etykiety od rejestrów właściwych dla danego procesora. Bardzo często nagłówki z CMSIS powielają się, jak choćby rodziny F0 i F3 - obsługę takiego RTC z F303 można właściwie przepisać bezpośrednio do F051.

Owszem, podstawowe funkcjonalności się pokrywają, ale problem pojawia się, gdy zaczniemy się zagłębiać w bardziej zaawansowane elementy. LL ma lepszą optymalizację kosztem m.in. przenoszalności. Do skakania między rodzinami bardziej przydatny jest HAL.

10 godzin temu, Zealota napisał:

Wytłumacz proszę, o co tu chodzi, chyba mam jakieś braki, z chęcią uzupełnię - chyba nie tworzy się taki RM z funkcji LL?  Póki co podtrzymuję, że LL w stosunku do HAL, SPL, czy RM jest najsłabsza, ale z chęcią zmienię zdanie.

Oczywiście, że nie!  Istnieje dokumentacja do procka (DS, PM i RM) oraz dokumentacja do bibliotek (HAL, LL, SPL), obie generowane niezależnie.