Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

szczywronek 23 Mar 2018 18:15 57540 134
  • #121
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • PCBway
  • #122
    JacekCz
    Poziom 37  
    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.
  • PCBway
  • #123
    marcin w
    Poziom 22  
    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.
  • #124
    JacekCz
    Poziom 37  
    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.
  • #125
    piotrek0207
    Poziom 14  
    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.
  • #126
    ex-or
    Poziom 20  
    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:
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • #128
    PiotrLenarczyk
    Poziom 8  
    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
    Poziom 8  
    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ą:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    podstawowe operacje:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    czytanie / zapis:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    rzutowanie adresu funkcji, czy literału łańcuchowego:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    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 ); ):
    Kod: c
    Zaloguj się, aby zobaczyć kod

    symetryczne ustawianie i zerowanie bitu:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    czekanie na wystawienie/zerowanie flagi:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    wstawka asemblerowa:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    odwzorowanie bitowe peryferiów mikrokontrolera z poprawnym użyciem:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    opóźnienie do uzyskania poprawnej funkcjonalności:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    uzyskiwanie rozmiaru tablicy - zabronione w C++:)
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • #131
    JacekCz
    Poziom 37  
    większość tych makr narusza reguły jak (w miarę) bezpiecznie pisać makra.

    Podaję taki przykład do medytacji.

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Ciekawe, że nie wszystkie, pochodzą spod innych palców???
  • #132
    PiotrLenarczyk
    Poziom 8  
    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ł )
    Kod: c
    Zaloguj się, aby zobaczyć kod
  • #133
    ex-or
    Poziom 20  
    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
    Poziom 20  
    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.
  • #135
    czarusgg
    Poziom 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!