Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

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

szczywronek 23 Mar 2018 18:15 85041 135
Computer Controls
  • #121
    User removed account
    User removed account  
  • Computer Controls
  • #122
    JacekCz
    Level 39  
    Boulious wrote:
    Chciałbym podzielić się swoim tworem...
    Code: c
    Log in, to see the code


    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.
  • #123
    marcin w
    Level 22  
    Piotrus_999 wrote:
    marcin w wrote:
    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.
  • #124
    JacekCz
    Level 39  
    marcin w wrote:
    Piotrus_999 wrote:
    marcin w wrote:
    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.
  • #125
    piotrek0207
    Level 20  
    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.
  • Computer Controls
  • #126
    ex-or
    Level 27  
    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:
    Code: c
    Log in, to see the code
  • #127
    PiotrLenarczyk
    Level 9  
    Przydatne MACRA do zarządzania wieloma bitami naraz:
    Code: c
    Log in, to see the code


    wersja uproszczona powyższego makra ( https://stackoverflow.com/questions/4421681/h...s-passed-to-a-function-that-accepts-a-variabl ):
    Code: c
    Log in, to see the code


    Nie wolno używać tych makr, jeśli nie wiesz jak działają!
    Post Scriptum: tylko do użytku garażowego!
  • #128
    PiotrLenarczyk
    Level 9  
    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 ).
  • #130
    PiotrLenarczyk
    Level 9  
    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ą:
    Code: c
    Log in, to see the code

    podstawowe operacje:
    Code: c
    Log in, to see the code

    czytanie / zapis:
    Code: c
    Log in, to see the code

    rzutowanie adresu funkcji, czy literału łańcuchowego:
    Code: c
    Log in, to see the code

    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 ); ):
    Code: c
    Log in, to see the code

    symetryczne ustawianie i zerowanie bitu:
    Code: c
    Log in, to see the code

    czekanie na wystawienie/zerowanie flagi:
    Code: c
    Log in, to see the code

    wstawka asemblerowa:
    Code: c
    Log in, to see the code

    odwzorowanie bitowe peryferiów mikrokontrolera z poprawnym użyciem:
    Code: c
    Log in, to see the code

    opóźnienie do uzyskania poprawnej funkcjonalności:
    Code: c
    Log in, to see the code

    uzyskiwanie rozmiaru tablicy - zabronione w C++:)
    Code: c
    Log in, to see the code
  • #131
    JacekCz
    Level 39  
    większość tych makr narusza reguły jak (w miarę) bezpiecznie pisać makra.

    Podaję taki przykład do medytacji.

    Code: c
    Log in, to see the code

    Ciekawe, że nie wszystkie, pochodzą spod innych palców???
  • #132
    PiotrLenarczyk
    Level 9  
    1) Nie wiem, nie znam się - mi zazwyczaj działa:)
    JacekCz wrote:
    większość tych makr narusza reguły jak (w miarę) bezpiecznie pisać makra.

    2) makra pisałem samopalczaście,
    JacekCz wrote:
    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ł )
    Code: c
    Log in, to see the code
  • #133
    ex-or
    Level 27  
    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?
  • #134
    ex-or
    Level 27  
    ex-or wrote:
    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.
  • #135
    czarusgg
    Level 12  
    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!