[STM32][C] - Poradnik dla początkujących (bez bibliotek)

Boulious napisał:

Chciałbym podzielić się swoim tworem...

Kod: c

Zaloguj się, aby zobaczyć kod

Każde uwagi, nawet te najbardziej krytyczne ale konstruktywne mile widziane.

Ja jestem głęboko uczulony na zasłanianie standardowych identyfikatorów.
Trochę to bronisz 'static', ale to nie jest dobra praktyka.

Piotrus_999 napisał:

marcin w napisał:

Gotowej raczej nie znajdziesz w środowisku programistycznym.

Specyjalista znaczy. O rand/srand słyszał?

A niektóre te czipy od STM-a to nawet krzemowe mają.

To funkcje języka C, posłużą do stworzenia funkcji "losującej" wybrany pin, jednak same w sobie nie operują na pinach.
Pisząc odpowiedź miałem na myśli że można sobie napisać własną funkcję "losującą" piny. To w jaki sposób będzie losowało zasugerowałem że można podejrzeć w arduino.

marcin w napisał:

Piotrus_999 napisał:

marcin w napisał:

Gotowej raczej nie znajdziesz w środowisku programistycznym.

Specyjalista znaczy. O rand/srand słyszał?

A niektóre te czipy od STM-a to nawet krzemowe mają.

To funkcje języka C, posłużą do stworzenia funkcji "losującej" wybrany pin, jednak same w sobie nie operują na pinach.
Pisząc odpowiedź miałem na myśli że można sobie napisać własną funkcję "losującą" piny. To w jaki sposób będzie losowało zasugerowałem że można podejrzeć w arduino.

Biblioteczna funkcja do migania losowym pinem ??? To ma coś z voo-doo.

Można by tu wykorzystać odpowiednio długi LFSR czyli o rejestr przesuwny ze sprzężeniem zwrotnym, ale tak czy inaczej potrzebujemy losowego ziarna do zasiana rejestru. F103 mają RTC i można by spróbować użyć czasu do zasiania generatora czyli ustawienia jego stanu początkowego.

Poradnik jest bardzo fajny i pomocny. Wielkie dzięki za opracowanie.
A piszę, bo chciałem zgłosić, jak mi się wydaje, subtelny błąd. Mianowicie w części o ADC, zadanie nr 13.3 wiersz 22 - pętla oczekująca na zakończenie konwersji. Wcześniej piszesz, że po zakończeniu konwersji wszystkich kanałów regularnych ustawiana jest flaga EOC. Ale jednocześnie, jak jeszcze wcześniej piszesz, flaga ta jest zerowana przez odczyt rejestru ADC->DR. W tym zadaniu DMA odczytuje wyniki konwersji zerując jednocześnie flagę EOC, w efekcie pętla nigdy się nie zakończy. Jako warunek sprawdzający koniec konwersji, wydaje mi się, odpowiedni byłby raczej test flagi DMA Channel transfer complete:

Przydatne MACRA do zarządzania wieloma bitami naraz:


wersja uproszczona powyższego makra ( https://stackoverflow.com/questions/4421681/h...s-passed-to-a-function-that-accepts-a-variabl ):


Nie wolno używać tych makr, jeśli nie wiesz jak działają!
Post Scriptum: tylko do użytku garażowego!

Kierowany ciekawością weryfikowałem poradnikową wydajność egzekucji programu z obszaru pamięci Flash, jak i RAM. Faktycznie kod z RAM przy bazowych częstotliwościach wykonuje się wolniej ( przy wyższych częstotliwościach jest szybszy jeśli pamięć Flash nie posiada kontrolera z pamięcić podręczną ). Dodatkowo po przeanalizowaniu budowy konkretnej implementacji rdzenia w danym MCU, łatwo zauważyć że różnią się szerokości szyny danych ( zdarza się, że szyna od pamięci do MCU ma inną szerokość, niż od MCU do pamięci ).
Post Scriptum: pobór prądu w 32b. MCU może być mniejszy w 8b. MCU ( w tym serii low power ).

Dziękuję super poradnik.

Jako początkujący miałem problem, aby poprawnie ustawić np. 5 środkowych bitów w rejestrze. Wrzucam trywialne macra - może komuś się przydadzą:

podstawowe operacje:

czytanie / zapis:

rzutowanie adresu funkcji, czy literału łańcuchowego:

ustawienie np 5 bitów ( bit nr: 7 równy "1", 8 równy "1", 9 równy "0", 10 równy "1", 11 równy "1", ) , ( GCC: rmw5b( addr, 0b11011, 7 ); IAR: rmw5b( addr, 0x1B, 7 ); ):

symetryczne ustawianie i zerowanie bitu:

czekanie na wystawienie/zerowanie flagi:

wstawka asemblerowa:

odwzorowanie bitowe peryferiów mikrokontrolera z poprawnym użyciem:

opóźnienie do uzyskania poprawnej funkcjonalności:

uzyskiwanie rozmiaru tablicy - zabronione w C++

większość tych makr narusza reguły jak (w miarę) bezpiecznie pisać makra.

Podaję taki przykład do medytacji.


Ciekawe, że nie wszystkie, pochodzą spod innych palców???

1) Nie wiem, nie znam się - mi zazwyczaj działa

JacekCz napisał:

większość tych makr narusza reguły jak (w miarę) bezpiecznie pisać makra.

2) makra pisałem samopalczaście,

JacekCz napisał:

Ciekawe, że nie wszystkie, pochodzą spod innych palców???

3) część jest przeznaczona do specyficznego użycia, jak np. uzyskiwanie numeru sectoru w dwubankowej pamięci Flash ( np. stm32H750 po 16zł )

Dodatek 6. Przerwanie widmo:
Jakim cudem przerwanie Phantom_IRQHandler jest wywołane jeśli nie ma stosownego wpisu w tabeli wektorów przerwań? #define PHANTOM_IRQn 91 to chyba trochę za mało?

ex-or napisał:

jeśli nie ma stosownego wpisu w tabeli wektorów przerwań?

No dobra, wpis w tabeli jest ale jest o tym napisane tak małymi literkami że mi umknęło
Technika jednakowoż nie jest, wydaje mi się, tylko ciekawostką, można ją uznać za przydatną np. w programowaniu zdarzeniowym. Innym mi znanym przykładem jest RTOS QP/C gdzie handlery przerwań tzw. kernel unaware nie mogą wywoływać funkcji systemowych i muszą to robić za pośrednictwem przerwań tzw.kernel aware.
Sam pomysł zresztą nie jest specjalnie nowatorski, w pozycji Joseph Yiu "The Definitive Guide to the ARM Cortex-M3" jest nawet o tym mowa. Z tym, że tam sugeruje się użycie handlerów przerwań niewykorzystywanych przez peryferia. Ale to, zdaje się, nie ma większego znacznia, tyle że można oszczędzić na pamięci zajętej przez tablicę wektorów.

Witaj Kolego Szczywronek!

Oczywiście, mam nadzieję, że wiele razy już czytałeś jak piękną robotę odwaliłeś pisząc swój poradnik. Myślę, iż słowo poradnik jest nieadekwatne do tej książki, którą wydałeś w domenie PUBLIC DOMAIN. Wielki szacunek i wielkie podziękowania, za włożony trud!

Nie mniej jednak w rozdziale 1.4 (uwagi końcowe) dałeś przyzwolenie na zgłaszanie uwag, ciekawych pomysłów do rozszerzeń poradnika.

Postanowiłem skorzystać z tej możliwości i proponuję, sugeruję, by do opisu licznika zaawansowanego w sekcji opisującej PWM dodać opis licznika powtórzeń.

Myślę, że jest to dość ważny rejestr. Przechodzę obecnie podobną drogę, jaką i Ty opisałeś AVR -> STM32. Przy czym w AVRach czuję się dość dobrze. Połknąłem wszystkie książki kolegi Francuza i stworzyłem już dziesiątki projektów.

Do póki nie sięgnąłem po STM32, myślałem, że XMEGI zaprojektowano z pomocą sił nadprzyrodzonych, zaprzedano dusze Diabłu czy coś, taki to jest skok jakościowy w stosunku do rodziny ATMEGA. Mam wrażenie, że w XMEGI wsadzono zawansowane peryferia z 32bitowych braci i wsadzono stary dobry rdzeń AVR8. Ale nawet tam nie uświadczyłem takiego bajeru jak rejestr powtórzeń. Cudo jakieś, na które sam bym nigdy nie wpadł (nie wiedziałbym nawet, że jest mi to tak bardzo potrzebne, gdybym o tym nie przeczytał).

O ile dobrze zrozumiałem RM, rejestr powtórzeń działa w ten sposób, że zdarzenie UEV, generowane jest tylko przy zerowej wartości tego licznika. To znaczy, następuje przepisanie rejestru przeładowania i ewentualne zerowanie licznika, gdy ten liczy w górę, ale samo zdarzenie nie jest generowane. Nie sprawdziłem jeszcze empirycznie czy konieczność zerowej wartości licznika powtórzeń wpływa także na zadziałanie bitu ONE PULSE MODE. To znaczy czy przy każdym wyzerowaniu / osiągnięciu wartości ARR licznik jest zatrzymywany, czy tylko, gdy rejestr powtórzeń ma wartość zero?

Co do genialności wnoszonej funkcjonalności na szybko wyobraziłem sobie takie oto zadanie:

Spowodować całkowicie sprzętowe wygenerowanie 5 impulsów o czasie trwania 1ms z przewami 10ms.

Gdyby nie rejestr powtórzeń, to kombinowałbym odliczanie ilości impulsów w przerwaniu od UEV i tam wyłączenie licznika po wygenerowaniu odpowiedniej liczby impulsów / przerwań.

Pozdrawiam!