STM32 Cortex-M3: jakie IDE i czy zaczynać od rejestrów czy HAL/LL?

Cześć wszystkim,
Pracuję nad projektem opartym na mikrokontrolerze ARM (rdzeń Cortex-M3). Chcę zacząć od podstawowych funkcji, takich jak konfiguracja zegara, GPIO, USART i prosty pętlowy pomiar sygnałów. Próbowałem już kilku przykładów, ale mam kilka pytań:
1. Środowisko programistyczne:
Jakie IDE / narzędzie polecacie do pracy z STM32 (np. STM32CubeIDE, Keil, Makefile GCC)? Co daje najwięcej kontroli nad kodem i debugowaniem?
2. Biblioteki vs. „rejestry ręczne”:
Rozważam programowanie „po rejestrach”, bez gotowych abstrakcji. Czy warto zaczynać od bibliotek HAL/LPL, czy od razu ręcznie konfigurować rejestry? Z jakimi pułapkami powinienem się liczyć?
3. Optymalizacja kodu:
W przyszłości planuję szybkie pętle ADC / Timery / przerwania - jakie praktyki są ważne przy pracy z Cortex-M3, aby uniknąć opóźnień i błędów w czasie rzeczywistym?
4. Zasilanie i zegary:
Jakie podstawowe błędy w konfiguracji zegarów / napięć mogą powodować nietypowe zachowania CPU (np. wolniejsze taktowanie niż oczekiwane)?

Opiszę krótko, co już próbowałem i jakie wyniki uzyskałem, ale szukam ogólnych wskazówek i dobrych praktyk, zanim zagłębię się w szczegóły implementacji.

Z góry dzięki za pomoc!

Cześć. Samodzielne korzystam z książki i jestem zadowolony. Tam jest wszystko ładnie wytlumaczone.
Mikrokontrolery STM32 dla początkujących - sklep Kamami https://share.google/SpiJAjkoMxs38qRNg

>>21878629 >>21878629

Dzięki za polecenie! 🙂
Słyszałem już wcześniej o tej książce i faktycznie wiele osób ją chwali za przystępne wprowadzenie do STM32.

Na ten moment uczę się głównie przez praktykę - mam prostą płytkę z STM32F103C8T6 (Cortex-M3) i próbuję ogarnąć konfigurację GPIO, timerów i UART. Zauważyłem jednak, że bez solidnych podstaw (zwłaszcza jeśli chodzi o rejestry i zegary) łatwo się pogubić, więc chyba faktycznie warto podeprzeć się dobrą książką.

Jeśli chodzi o sprzęt, używam czegoś w tym stylu:
STM32F103C8T6 ARM Development Board Sprawdź to
- popularna płytka do nauki, ale czasami mam wrażenie, że dokumentacja i przykłady są trochę rozproszone.

Masz może doświadczenie, czy ta książka dobrze tłumaczy pracę „na rejestrach”, czy raczej skupia się na HAL/wyższych bibliotekach?

poszukaj stmcubeIIDE - to jest od stm i nie baw sie w zadne DIY środowiska

Zacznij od przeczytania tego poradnika:
https://www.elektroda.pl/rtvforum/topic3111562.html

Moja książka skupia się na HAL. Pod nią jest specjalna płytka rozwojowa https://kamami.pl/zestawy-uruchomieniowe-stm3...krokontrolerem-stm32f411ce-5906623433308.html

Danieldsouza napisał:

łatwo się pogubić, więc chyba faktycznie warto podeprzeć się dobrą książką.

Dlatego polecam zaopatrzyć się jeszcze w pozycję Carmine Noviello - Mastering STM32 (Second edition).
Ale nie czarujmy się, żadna książka nie zastąpi Reference Manuala...

Danieldsouza napisał:

Jakie IDE / narzędzie polecacie do pracy z STM32 (np. STM32CubeIDE, Keil, Makefile GCC)?

To zależy od wielu czynników. Jak chcesz szybko zacząć z HAL/LL to CubeIDE+CubeMX. Jak chcesz większą kontrolę i rejestry to raczej Keil MDK, ale pamiętaj o ograniczeniach wersji darmowej. GCC+Makefile+VSCode - tylko jak potrafisz to poprawnie skonfigurować.

Danieldsouza napisał:

Rozważam programowanie „po rejestrach”, bez gotowych abstrakcji.

To skorzystaj z bibliotek LL. Chyba, że lubisz liczyć bity i "magiczne liczby" w kodzie...

Danieldsouza napisał:

W przyszłości planuję szybkie pętle ADC / Timery / przerwania - jakie praktyki są ważne przy pracy z Cortex-M3, aby uniknąć opóźnień i błędów w czasie rzeczywistym?

Trzeba dobrze zrozumieć system NVIC (system przerwań), bo jest nieco bardziej rozbudowany, oraz podpierać się gdzie tylko możliwe DMA. Potem tak pisać aplikację by się nie zatrzymywała w martwych pętlach.

Danieldsouza napisał:

Jakie podstawowe błędy w konfiguracji zegarów / napięć mogą powodować nietypowe zachowania CPU (np. wolniejsze taktowanie niż oczekiwane)?

Przede wszystkim trzeba nauczyć się kontrolować podsystem RCC by reagować na jego błędy w trakcie konfiguracji jak i podczas późniejszego działania, i nie zakładać, że za każdym razem np. generator zewnętrzny się uruchomi, pętla PLL się ustabilizuje, itp.

ZbeeGin napisał:

Jak chcesz większą kontrolę i rejestry to raczej Keil MDK

Zdradź mi tajemnicę w jaki sposób STMCubeIDE ogranicza Twoje programowanie na rejestrach? Ta porada to nonsense - no chyba że ktoś zamierza kupić ro narzędzie. Zresztą Keil tak samo dobrze nadaje się pracy z HAL-em jako że HAL do tylko dodatkowe pliki do projektu - nic więcej.

Dodatkowo Keil (IDE) ma parszywy edytor, który zatrzymał się 30 lat temu i jak ktoś się przyzwyczaił do nowych to będzie tylko przeklinał. Debugger jeżeli chodzi o funkcjonalność też jakoś tak pod wzgledem wygody jakieś 20 lat do tyłu w stosunku do czegokolwiek innego (zresztą inne płatne narządzia podobnie, w pracy mam IAR i to świństwo o seggera (ale debuggery mają najlepsze) ). Kompilator jest dobry - ale osobiście wolę gcc - pewnie przyzwyczajenie

oscil1 napisał:

Zdradź mi tajemnicę w jaki sposób STMCubeIDE ogranicza Twoje programowanie na rejestrach?

Nigdzie nie napisałem, że coś "ogranicza". CubeIDE oraz CubeMX tworzą zestaw (Obecnie znów zostały rozdzielone w v2.0). I to zestaw nakierunkowany głównie na biblioteki HAL, bo tak chce to widzieć ST Microelectronics...

@Danieldsouza
Użyj CubeMX, żeby zorientować się w konfiguracji gpio, peryferiów i zegarów. Zobaczysz, jakie funkcje ma dane gpio czy timer. Czy jakieś ustawienie nie koliduje z innym.
Szczególnie przydatna jest graficzna konfiguracja domeny zegarów.

HAL/LL/rejestry. Jeśli zabierasz się za to na poważnie, chcesz mieć kontrolę nad kodem i deterministyczne zachowanie, zacznij od LL. Rejestry, i jak to wszystko działa warto w takim przypadku poznać. Dla Stm jest bardzo dobra dokumentacja. Podstawa to datasheet i reference manual danego układu.
Żadnych magicznych liczb nie trzeba się bać. CMSIS zapewni wszystkie definicje rejestrów.

Danieldsouza napisał:

Rozważam programowanie „po rejestrach”, bez gotowych abstrakcji. Czy warto zaczynać od bibliotek HAL/LPL, czy od razu ręcznie konfigurować rejestry?

Moim osobistym zdaniem, jest tu pewne błędne założenie. HAL i LL wcale nie wyklucza podejścia "rejestrowego" kiedy to staje się niezbędne, np. optymalizacja prędkości, czy jakieś szczególne potrzeby. Ale nie ma większego praktycznego sensu rozważanie że czysto rejestrowe podejście (czyli siedzenie z nosem w RM i szukanie bitów, które trzeba ruszyć) jest jakieś lepsze. Jest żmudniejsze i łatwiej w nim o błąd. Owszem, czasami trzeba coś "uszyć" całkowicie ręcznie pod jakieś szczególne wymaganie. Ale sporo jest spraw gdzie nieporównywalnie szybko i łatwo załatwi "wyklikanie" programu w CubeMX. Na przykład kwestie zegara czy ustawienie uartu pod konkretne parametry oraz inicjalizacja większości innych peryferii. Tu właśnie CubeMX z HAlem jest znakomity. A po zbudowaniu programu, nie ma żadnych przeszkód by w miejscach na kod użytkownika stosować podejście czysto rejestrowe dla pewnych spraw.
Co do samego HAL to trzeba mieć na uwadze fakt że jest to biblioteka uniwersalna, nie zajmująca się pewnymi rzadko występującymi niuansami. Konkretnie rzecz w tym że w pewnych peryferiach są jakieś bity, które zwykle się pomija w obsłudze. I HAL przykładowo nie zawiera w argumentach swoich funkcji takich opcji i ustawia wartości domyślne. Czyli i tak może być potrzeba czy to zrobienia wpisu do rejestru, czy użycia funkcji LL po wywołaniu HAL.
Ale tu jest istotna sprawa by wiedzieć co HAL robi a czego nie. I tu moim zdaniem, bardzo pożyteczne jest zaglądanie do źródeł HAL. Dlatego warto też wybrać takie IDE, w którym jest wsparcie dla szybkiego wyszukiwania symboli, definicji funkcji itp. bo można podglądnąć co ten HAL wpisuje do rejestrów. Co prawda źródła HAL są dość złożone bo funkcje zawierają np. sprawdzanie poprawności parametrów wywołania i parę innych funkcjonalności, ale po pewnej wprawie widać jakie konkretnie wpisy do rejestrów robi HAL. Jest tu jeszcze inna zaleta zaglądania do źródeł HAL, że w przypadku pewnych złożonych peryferii widzimy gdzie, w jakiej kolejności są rejestry ruszane i nie jest to wiedza, którą da się prosto wyczytać z RM a bardziej doświadczenie programistów z STM.

Tak że aby już nie przynudzać, nie znam Twojej determinacji i umiejętności, ale tak czy inaczej, sugeruję jako platformę edukacyjną CubeMX, jako szybki i wygodny system do pisania testów. I proponuję nie traktować programowania "rejestrowego" jako alternatywy w stosunku do HAL, bo można te podejścia bez przeszkód harmonijnie połączyć.

Z tego, co pamiętam, nie dało się połączyć używania USB z maksymalną szybkością ADC - zegary mają część wspólną, i żeby podać odpowiedni zegar dla USB, trzeba użyć nieco wolniejszego do ADC. Warto poszukać w nocie katalogowej schematu generowania sygnałów zegarowych i zobaczyć, co i jak da się ustawić, i jakie są ograniczenia.

_jta_ napisał:

Z tego, co pamiętam, nie dało się połączyć używania USB z maksymalną szybkością ADC - zegary mają część wspólną,

Nie pisz takich rzeczy jako prawdy objawione. Pewnie w jakimś budżetowym modelu tak jest bo zrobili prosty układ zegara. W wiekszości są oddzielne drzewa a nawet wiele ma oddzieny wewn zegar do USB tylko.

Ja mam na myśli STM32F103C8T6 "Blue pill", i mam wrażenie, że o takim tu mowa. I polecam sprawdzić w nocie katalogowej - nawet dla tego układu mogłem ja się pomylić, mogło się coś zmienić...

I miałbym uwagę co do HAL - z założenia HAL (Hardware Abstraction Layer) jest po to, by nie trzeba było myśleć o sprzęcie. Ale przez to nie zauważa się ograniczeń wynikających z konstrukcji, a one nadal są.