Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek 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 06 Lis 2015 01:04 51891 131
  • #1 06 Lis 2015 01:04
    szczywronek
    Poziom 27  

    O popularności mikrokontrolerów STM32 wśród hobbystów i pasjonatów nikogo nie trzeba przekonywać. Firma ST taranem wbiła się w społeczność mikrokontrolerową rozdając płytki Discovery i Nucleo. Wraz z rosnącym zainteresowaniem STMami pojawiło się kilka (polskojęzycznych) książek oraz kursów/poradników na ich temat.

    Po co więc kolejny? Istniejące poradniki i książki, w większości, opierają się o biblioteki do obsługi układów peryferyjnych mikrokontrolera - np. kontrowersyjne SPL. Kursów poświęconych pracy z wykorzystaniem "gołych" rejestrów, w oparciu o dokumentację mikrokontrolera, jest niewiele. Do tego większość z nich omawia tylko najprostsze układy mikrokontrolera. Rzadko wykraczają poza podstawową obsługę portów I/O i przerwania zewnętrzne, by potem lekko "liznąwszy" temat liczników, znienacka się skończyć i pozostawić po sobie małą migającą diodę i duży niedosyt.

    Jako zagorzały zwolennik rejestrów (dodatkowo cierpiący na nieuleczalny syndrom NIH) kilka razy próbowałem zachęcić kogoś do zabawy bez bibliotek. Swego czasu, od pewnego kolegi z pewnego forum poświęconego głównie mikrokontrolerom AVR, dostałem odpowiedź na taką sugestię. Stwierdził on, że z chęcią spróbowałby programować bez SPL gdyby tylko spece od rejestrów się odrobinę poświęcili i zamiast wytykać wady biblioteki stworzyli poradnik dla początkujących, którzy (ponoć) są skazani na SPL bo wszystkie przykłady, kursy, tyle dokumentacji itd... Specem nie jestem, ale się staram :)

    Na Elektrodzie również, jakiś czas temu, pojawiły się głosy sugerujące zapotrzebowanie na taki poradnik lub chociaż na zbiór przykładowych programów konfigurujących różne peryferia mikrokontrolera za pomocą rejestrów. Np. temat STM32 [C] Eclipse - Kurs dla początkujących bez SPL Czy potrzebny ?. Jednak nic konkretnego się z tego nie wykluło (oczywiście jest strona kolegi Freddie Chopin, ale IMO trudno zaliczyć ją do kategorii poradników ;)).

    Stworzyłem więc swój Poradnik. Próbowałem przy tym postawić się w niełatwej roli kogoś, kto dopiero zaczyna przygodę z STMami. Przy tworzeniu Poradnika posiłkowałem się notatkami, które sporządziłem gdy sam poznawałem STMy (i w sumie ogólnie mikrokontrolery) od zera. Wiele z rzeczy, które wtedy uznałem za "odkrywcze", dziś wydaje się niewarte wspomnienia. Postanowiłem jednak wszystkie je opisać - być może dla kogoś będą one równie odkrywcze, jak kiedyś dla mnie.

    Co jest w Poradniku? Poradnik ma formę pojedynczego pliku pdf liczącego niecałe 500 stron. Zawiera głównie tekst i przykładowe kody, trochę tabel. Rysunków jest niewiele - wiem, można to uznać za wadę - jednak przygotowanie i obróbka obrazów zajmuje mnóstwo czasu. Wybrałem więc wersję leniwą i w razie potrzeby odwołuję się do konkretnego rysunku z oficjalnej dokumentacji mikrokontrolera. Dwa pierwsze rozdziały to wstęp - wprowadzenie i informacje niezbędne przed pójściem dalej (nuda!). Kolejne kilkanaście rozdziałów opisuje wybrane układy mikrokontrolerów STM32F103, STM32F334 i STM32F429. Dlaczego akurat te? Z prostej przyczyny - mam płytki startowe z nimi :) Rozdziały, w większości, zbudowane są podobnie. Zawierają opis danego układu peryferyjnego i jego możliwości oraz przykładowe zadania "domowe" z rozwiązaniami i komentarzem.





    Poradnik na pewno nie jest idealny. Tak jak napisałem w jednym ze wstępnych podrozdziałów - jestem tylko hobbystą i nie mam wykształcenia programistyczno-elektronicznego. Na pewno popełniłem mnóstwo błędów :roll: Liczę na odzew ze strony Czytelników. W miarę możliwości będę starał się poprawiać i rozwijać Poradnik uwzględniając "vox populi" (przynajmniej taki jest plan). Na koniec pozwolę sobie skopiować jeszcze kawałek ze wstępu:

    szczywronek napisał:
    Poradnik udostępniam nieodpłatnie każdemu zainteresowanemu, do osobistego użytku edukacyjnego only. Zezwalam na wszelkiej maści nieodpłatne rozpowszechnianie fragmentów tudzież publiczne odwoływanie się do nich pod warunkiem zachowania informacji o Autorze i pochodzeniu tych fragmentów. Za nic nie biorę odpowiedzialności itd. itd. Poradnik czytasz na własną odpowiedzialność.


    Starczy tego, bo zaraz cały wstęp zreferuję. Miłej lektury!

    Attention please! Ze względów technicznych załączniki zostały przeniesione do czwartego posta tegoż tematu.

    --------
    2015.11.06 Podwiesiłem temat jako ogłoszenie, bo wart tego :)
    Dondu

    63 29
  • Pomocny post
    #2 06 Lis 2015 09:34
    tmf
    Moderator Mikrokontrolery Projektowanie

    Gratuluję pomysłu i jego realizacji. Bardzo fajny poradnik, głównie dla przesiadkowiczów.
    Tylko drobna uwaga - to co piszesz o AVR dotyczy tylko ATTiny i ATMega, nie dotyczy AVR XMEGA. Warto byłoby zaznaczyć na początku, że pisząc o AVR myślisz tylko o tych dwóch rodzinach.

    1
  • Pomocny post
    #3 06 Lis 2015 10:11
    BlueDraco
    Specjalista - Mikrokontrolery

    W ciągu ostatnich dwóch lat w EP pojawił się cykl artykułów poświęconych programowaniu STM32 bez SPL z wieloma przykładami.

    A i ważna uwaga co do tekstu: w aktualnych, nowych wersjach plików nagłówkowych dla F4 już nie ma BSRRL i BSRRH, a jest BSRR (co powoduje, że programy napisane pół roku temu już się nie kompilują z nowymi plikami nagłówkowymi).

    Co do przerwań i wyjątków: przerwanie to jeden z trzech rodzajów wyjątków. Różni się od dwóch pozostałych głównie tym, że jego obsługa nie musi nastąpić natychmiast po zgłoszeniu i zależy od priorytetu procesora i priorytetu przerwania. W Cortex mamy przerwania od peryferiali i dwa zgłaszane przez rdzeń - SysTick i PendSV.

    3
  • #4 06 Lis 2015 13:03
    szczywronek
    Poziom 27  

    @tmf - dziękuję za miłe słowa :) Właśnie takie było założenie co do grupy "docelowej". Myślę, że jeszcze długo ATmegi i ATtiny będą punktem startowym dla hobbystów ze względu na nawał informacji w Internecie i mocno zakorzeniony pogląd jakoby wszystko inne było drogie/trudne itd.
    W sumie chciałem, żeby w poradniku było trochę więcej nawiązań do AVR - żeby cały czas mieć w zasięgu wzroku "znany" punkt odniesienia. Ale jakoś tak "samo z siebie" to nie wyszło, a nie chciałem wciskać "wydumanych" analogii na siłę.

    Faktycznie nie pomyślałem o Xmegach! Dopisuję do listy poprawek do wydania II :) Dziękuję za zwrócenie uwagi.

    @BlueDraco - no, uprzedzili mnie :] Nie śledzę EP na bieżąco. Jakiś czas temu trafiłem na artykuł o STMach (nie wiem czy pochodził z kursu o którym mówisz) - ale... wstyd się przyznać - odstraszyła mnie wtedy konfiguracja peryferiów z wykorzystaniem tablicy z wartościami wszystkich konfigurowanych rejestrów. To było dla mnie za dużo nowości i za szybko.

    Zdaję sobie sprawę, że mój poradnik pojawił się dosyć późno. Nie tak dawno nie było tygodnia, aby na forum nie pojawiało się kilka pytań związanych z peryferiami STMów. Teraz jakoś ucichło. Rozważałem opublikowanie poradnika wcześniej (w krótszej wersji, może w "odcinkach"). Priorytetem jednak było, aby nie skończyć jak spora część amatorskich poradników - na miganiu diodą i niedosycie. Aby mieć pewność że tak się nie stanie, zdecydowałem jednak napisać ile się da i dopiero wrzucać do sieci.

    Dziękuję za uwagę o nagłówku F4 - odnotowane do poprawki!

    Trzy rodzaje wyjątków? Hm: przerwania, faulty i "pozostałe"? Im więcej czytam tym bardziej mi się to kićka. Np. w ARMv7-M Architecture Reference Manual jest rozdział pt. "Exceptions, faults and interrupts" - no i się gubię - niby są trzy rodzaje (wyjątki, błędy, przerwania) tylko czy wyjątki są jednym z rodzajów wyjątków? To się masło maślane robi.

    Później jest tylko gorzej bo znienacka robią się już cztery kategorie:

    ARMv7-M Architecture Reference Manual napisał:
    ARMv7-M defines the following exception categories:
    Reset
    Supervisor call (SVCall)
    Fault
    Interrupt

    BlueDraco napisał:
    jego [przerwania] obsługa nie musi nastąpić natychmiast po zgłoszeniu i zależy od priorytetu procesora i priorytetu przerwania
    A co z NMI? Robi za wyjątek (w sensie wyjątek od zacytowanej reguły, nie wyjątek = exception) czy też ma w nazwie Interrupt tylko dla zmyłki?

    --------
    Załączniki są TUTAJ :)

    Spis treści Poradnika:
    Spoiler:
    1. Wstęp formalny
    1.1. Co to właściwie jest? („Quo vadis Domine?”)
    1.2. Ja („Quicquid Latine dictum sit, altum videtur”)
    1.3. Ty („Bene tibi!”)
    1.4. Uwagi końcowe („Cogitationis poenam nemo patitur”)
    2. Wstęp techniczny
    2.1. Od przybytku głowa (nie) boli („Divitiae non sunt bonum")
    2.2. O co chodzi z tym rdzeniem? („Nil mirari, nil indignari, sed intellegere”)
    2.3. Hardware („Nemo sine vitiis est!”)
    2.4. Piśmiennictwo („Littera docet, littera nocet.”)
    2.5. Software („Ex malis eligere minima oportet”)
    2.6. Słowo o bibliotekach („Relata refero”)
    2.7. Wskazówki przed startowe („Ave, Caesar, morituri te salutant”)
    3. Porty I/O („Ardua prima via est”)
    3.1. Ogarnąć nóżki w F103 (F103)
    3.2. Nieśmiertelnie Blinkający Hell of World (F103)
    3.3. Atomowo macham nogą i nie tylko
    3.4. Cortex-M4 wybieram Cię! (F334 i F429)
    3.5. Wybór funkcji alternatywnej (F334 i F429)
    3.6. Remapping funkcji alternatywnych (F103)
    3.7. Elektryczna strona medalu
    3.8. Skompensuj mi celę (F429)
    4. Bit banding („Gemma gemmarum”)
    4.1. Ale o co chodzi?
    4.2. Jak to działa?
    4.3. Jasne i proste jak cała matematyka
    4.4. Makro do bit bandingu
    4.5. Kiedy stosować bit banding
    4.6. A gdzie jest haczyk?
    5. Wyjątki („Macte animo, iuvenis!”)
    5.1. Trochę zbędnej teorii o trybach pracy rdzenia
    5.2. Poznajmy wyjątki w Cortexie
    5.3. Mechanika działania wyjątków
    5.4. Priorytety i wywłaszczanie
    5.5. Funkcje pomocnicze
    5.6. Priorytety przykład praktyczny
    6. Licznik systemowy SysTick („Magnum opus”)
    6.1. Blink me baby one more time
    7. Blok EXTI i przerwania zewnętrzne („Facta sunt verbis difficilora”)
    7.1. EXTI (F103)
    7.2. EXTI (F429)
    7.3. EXTI (F334)
    8. Liczniki („Festina lente!”)
    8.1. Wstęp
    8.2. Blok zliczający, prosty timer
    8.3. Update Event (UEV), buforowanie rejestrów i One Pulse Mode
    8.4. Schemat blokowy licznika
    8.5. Licznik pędzony z zewnątrz
    8.6. Filtrowanie sygnałów zewnętrznych
    8.7. Tryb enkodera
    8.8. Taktowanie licznika innym licznikiem
    8.9. Podsumowanie źródeł taktowania
    8.10. Blok porównujący - PWM
    8.11. Blok porównujący - przerwania
    8.12. Blok porównujący - podsumowanie
    8.13. Blok przechwytujący - Input Capture
    8.14. Synchronizacja sygnałem zewnętrznym
    8.15. PWM Input Mode
    8.16. Synchronizacja kilku liczników
    8.17. Liczniki ogólnego przeznaczenia i podstawowe
    8.18. Luźne uwagi na koniec
    8.19. Różnice między F103 i F429 (F103 i F429)
    8.20. Licznikowe indywiduum (F334)
    9. Battery Backup Domain (“Non omnis moriar”)
    9.1. Wstęp
    9.2. Backup Registers (F103)
    9.3. RTC (F103)
    9.4. Backup Registers (F429)
    9.5. Backup SRAM (F429)
    9.6. RTC (F429)
    9.7. Backup Registers i RTC (F334)
    10. Układy watchdog („Duo cum faciunt idem, non est idem”)
    10.1. Watchdog niezależny IWDG
    10.2. Watchdog okienkowy WWDG
    10.3. Porównanie układów watchdog
    10.4. Układy watchdog w mikrokontrolerze F334 (F334)
    11. Reset, zasilanie i tryby oszczędzania energii („Difficilis in otio quies”)
    11.1. Reset
    11.2. Zasilanie (F103)
    11.3. Zasilanie (F429)
    11.4. Zasilanie (F334)
    11.5. Debugowanie a tryby uśpienia
    11.6. Tryby obniżonego poboru mocy (F103)
    11.7. Tryby obniżonego poboru mocy (F429)
    11.8. Tryby obniżonego poboru mocy (F334)
    12. Mechanizm DMA („Annuntio vobis gaudium magnum: habemus DMA”)
    12.1. Z czym to się je?
    12.2. DMA (F103)
    12.3. DMA (F429)
    12.4. DMA (F334)
    13. Przetwornik ADC („Superflua non nocent”)
    13.1. ADC wstęp (F103)
    13.2. Tryby pracy pojedynczego przetwornika ADC (F103)
    13.3. Czas próbkowania (F103)
    13.4. Tryby pracy dwóch przetworników ADC (F103)
    13.5. Bajery (F103)
    13.6. Ogólne spojrzenie na tryby pracy przetwornika ADC (F103 i F429)
    13.7. Różnice w STM32F429 (F429)
    13.8. Różnice w STM32F334 (F334)
    13.9. Końcowe uwagi
    14. Przetwornik DAC („Omne ignotum pro magnifico”)
    14.1. Wstęp (parametry i tryby pracy)
    14.2. Zadania praktyczne (F103)
    14.3. Zadania praktyczne (F429)
    14.4. Odrobina odmiany (F334)
    14.5. Uwagi końcowe
    15. Interfejs USART („Volenti nihil difficile”)
    15.1. USART (F103)
    15.2. USART (F429)
    15.3. USART (F334)
    16. Pamięć Flash i bootowanie („Variatio delectat”)
    16.1. Pamięć Flash
    16.2. Tryby uruchamiania i bootloader
    16.3. Bajty konfiguracyjne (F103)
    16.4. Bajty konfiguracyjne (F429)
    16.5. Bajty konfiguracyjne (F334)
    16.6. Kod w pamięci SRAM - po co?
    16.7. Funkcja w pamięci sram - jak?
    16.8. Cały program w pamięci sram - jak?
    17. System zegarowy („Finita est comoedia”)
    17.1. Wstęp
    17.2. System zegarowy (F103)
    17.3. System zegarowy (F429)
    17.4. System zegarowy (F334)
    18. Hashing randomly encrypted CRC (“Contra facta non valent argumenta”)
    18.1. Wstęp z niespodzianką
    18.2. Nic nie dzieje się przypadkiem (F429)
    18.3. Suma kontrolna CRC32 (F103 i F429)
    18.4. Sprzętowe CRC8, CRC16 i dowolny wielomian (F103 i F429)
    18.5. Suma kontrolna CRC (F334)
    19. Interfejs SPI (“Potius sero quam numquam”)
    19.1. Wstęp (F103 i F429)
    19.2. Master ŚPI (F103 i F429)
    19.3. Master i Slave w jednym SP(al)I domu (F103 i F429)
    19.4. Pół-puplex na dwa mikrokontrolery (F103 i F429)
    19.5. CRC w SPI (F103 i F429)
    19.6. Outsider (F334)
    Dodatek 1: Funkcja konfigurująca porty (F103)
    Dodatek 2: Funkcja konfigurująca porty (F429)
    Dodatek 3: Makro do bit bandingu
    Dodatek 4: To bit band or not to bit band
    Dodatek 5: Atrybut interrupt (F103, GCC)
    Dodatek 6: Przerwanie widmo
    Dodatek 7: Gwałt na Nucleo w dwóch aktach
    20. Errata i changelog („Hominis est errare, insipientis in errore perseverare”)
    20.1. Błędy zauważone w wersji 1.0 Poradnika
    20.2. Błędy zauważone w wersji 1.1 Poradnika
    20.3. Błędy zauważone w wersji 1.2 Poradnika
    20.4. Błędy zauważone w wersji 1.3 Poradnika
    20.5. Zmiany dokonane w wersji 1.4 Poradnika
    20.6. Zmiany dokonane w wersji 1.5 Poradnika
    20.7. Zmiany dokonane w wersji 1.6 Poradnika
    20.8. Zmiany dokonane w wersji 1.7 Poradnika

    Poradnik w najnowszej wersji uwzględniającej wszystkie poprawki z erraty. Errata, zawierająca wszystkie zmiany od pierwszego wydania (wersji 1.0), znajduje się zarówno na końcu Poradnika jak i w formie osobnego pdfa (do pobrania bez prowizji). Przyjemnej lektury!

    60
  • Pomocny post
    #5 06 Lis 2015 13:48
    BlueDraco
    Specjalista - Mikrokontrolery

    Trzy rodzaje wyjątków: przerwania, pułapki, błędy - używając w miarę spójnej terminologii z jakimiś sensownymi definicjami pojęć. Niestety producenci ne stosują tutaj spójnej terminologii. Przerwania są asynchroniczne, pozostałe - synchroniczne. Przy pułapce instrukcja się kończy, przy błędach - nie.
    W architekturach RISC granica pomiędzy pułapkami i błędami niekoniecznie jest ostra. W co gorszych architekturach zdarza się, że przy błędzie instrukcja też się kończy, co uniemożliwia np. wirtualizację pamięci. Nie wgłębiałem się w tym zakresie szczegółowo w ARM, wiem tylko, że Cortex-M0 ma błędy dość uproszczone.

    NMI jest niewątpliwie przerwaniem, bo w przyzwoitych architekturach zgłoszenie NMI w czasie obsługi NMI nie przerywa obsługi NMI. W nieprzyzwoitych różnie z tym bywa.

    Reset można na ogół traktować jako błąd, którego obsługa nie powoduje składowania kontekstu. Poza tym szczegółem nie ma w RESET nic szczególnego. ;)

    0
  • Pomocny post
    #6 06 Lis 2015 16:38
    dondu
    Moderator Mikrokontrolery Projektowanie

    Podwiesiłem temat jako ogłoszenie, bo jest tego wart :)

    szczywronek napisał:
    (tak jestem egoistą i zbieram na pendrive'a).

    Ile punktów Ci brakuje ? Z chęcią podzielimy się swoimi za udostępnienie tych materiałów :)

    0
  • #7 06 Lis 2015 20:55
    M. S.
    Poziom 34  

    Dzięki szczywronek. Otwarłem dziś rano elektrodę, a tu niespodzianka. Pobrałem poradnik, zapisałem na dysku i poszedłem do roboty. Teraz otworzyłem, nieco poczytałem i już wiem, że z tym poradnikiem nie zginę w STM'ach. Przede wszystkim nie będę musiał się wpatrywać tak często w angielskie teksty, od których czacha mi dymi. Po krótkiej lekturze już wiem, co oznaczają nielogiczne dla mnie rejestry do ustawiania i kasowania bitów na porcie (BSRR) i prawie kompatybilny rejestr kasowania tych bitów na tym samym porcie (BRR), przy braku oczekiwanego przeze mnie logicznego rejestru BSR (zamiast BSRR).
    Jeszcze raz dzięki!

    P. S. Koledzy superbiegli w temacie, jak widzę, rzucili się już z pomocą przy wyjaśnianiu zawiłości, co w krótkim czasie powinno udoskonalić opracowanie, a później do druku, do druku, i na półkę w księgarni - chętnie kupię.

    0
  • #8 06 Lis 2015 22:19
    szczywronek
    Poziom 27  

    @BlueDraco - im głębiej w las tym... pojęcie pułapki to dla mnie całkowita nowość. Brakuje mi fundamentów z ogólnej wiedzy o procesorach :/ A co z SVC - to nie będzie czasem synchroniczne przerwanie programowe?

    Czyli, w uproszczeniu, na przykładzie Cortexowym:
    - przerwanie: układy peryferyjne µC, SysTick i PendSV
    - błąd (ew. pułapka): wszystko z fault w nazwie + Reset

    No to jeszcze coś mi nie pasuje:

    BlueDraco napisał:
    przerwanie [...] Różni się od dwóch pozostałych [typów wyjątków] głównie tym, że jego obsługa [...] zależy od priorytetu procesora i priorytetu przerwania.
    Przecież Cortexowe Faulty mają konfigurowalny priorytet - więc to czy zostaną obsłużone też jest uwarunkowane priorytetem, gdzie się zgubiłem?

    A propos Resetu, przy okazji zwróciłem uwagę na:
    ARMv7-M Architecture Reference Manual napisał:
    Reset is a special form of exception that, when asserted, terminates current execution in a potentially unrecoverable way.
    Coś ciekawego kryje się pod tym "potentially unrecoverable way"?

    @dondu - dziękuję ślicznie za wyróżnienie tematu :D

    Jak na złość nie ma pendrajwerów w sklepiku :> Liczyłem też że będę miał bardziej kolorowo pod emblematem, ale teraz się przypatrzyłem i licznik punktów jako jedyny nie ma swojego "paska postępu"... jak pech to pech :(

    @M. S. - bardzo się cieszę, że się podoba :) Mam nadzieję, że kolejne rozdziały okażą się równie pomocne. Jak coś to wiadomo - wszelkie uwagi mile widziane.

    Co do druku. Hm. Powiem szczerze - chodziło mi to po głowie. Zdaję sobie jednak sprawę, że za mało wiem żeby samemu napisać książkę i wziąć odpowiedzialność za jej treść. Wygrała pokora i postanowiłem zadowolić się punktami, chwałą i splendorem na forum ;) Może się mylę, ale wydaje mi się, że teraz to już "po ptokach". Z sieci nic nie znika. Trzeba by mocno podrasować i wzbogacić Poradnik, żeby to nie był tylko "poprawiony darmowy pdf". Sam nie wiem... Może gdyby znalazł się ktoś "superbiegły", kto nie ma co z wolnym czasem zrobić :roll: Gdzieś to już pewnie pisałem: ja jestem otwarty na wszelkie sugestie i propozycje :wink:

    0
  • Pomocny post
    #9 07 Lis 2015 09:22
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie ma "przerwań synchronicznych", jest tylko błędna terminologia. SVC to jest właśnie pułapka, podobnie jak SYSCALL w innych procesorach, TRAP w jeszcze innych i INT w x86.
    Błąd to coś ciut innego - wszystkie Fault w ARM to właśnie błędy.

    Obsługa błędów ani pułapek nie zależy od priorytetu procesora. Ten "konfigurowalny priorytet" dla pułapek i błędów w Cortex-M jest to priorytet procesora, jaki zostanie ustawiony w chwili wejścia w obsługę wyjątku, co skutkuje automatyczną blokadą przerwań do tego priorytetu włącznie.
    Dawno nie zaglądałem do dokumentów ARM, ale było tam coś o tym, co się dzieje, gdy priorytet pułapki czy błędu jest niższy od priorytetu kodu, który je spowodował - takie coś nie powinno się zdarzyć i jakoś procesor na to reaguje - jest to dokładnie opisane.

    Akurat tym "potentially" bym się nie przejmował. Chodzi po prostu o to, że po RESET do nikąd nie będziemy wracać, tylko zaczynać od nowa, chociaż i na to są sposoby. Od dawna w PC podczas pracy oprogramowania był wywoływany RESET niezbędny do pewnych dziwnych działań systemowych, po czym aplikacja była kontynuowana. Ja np. na Cortexach używam RESET do wywołania bootloadera z kodu aplikacji, która wcześniej została uruchomiona przez bootloader.

    0
  • #10 07 Lis 2015 10:17
    tmf
    Moderator Mikrokontrolery Projektowanie

    BlueDraco napisał:

    Akurat tym "potentially" bym się nie przejmował. Chodzi po prostu o to, że po RESET do nikąd nie będziemy wracać, tylko zaczynać od nowa, chociaż i na to są sposoby. Od dawna w PC podczas pracy oprogramowania był wywoływany RESET niezbędny do pewnych dziwnych działań systemowych, po czym aplikacja była kontynuowana. Ja np. na Cortexach używam RESET do wywołania bootloadera z kodu aplikacji, która wcześniej została uruchomiona przez bootloader.


    Na PC RESET był wykorzystywany do wyprowadzenia procka z trybu chronionego w tryb przeczywisty x86. To się stosowało na 286.

    0
  • #11 08 Lis 2015 22:47
    szczywronek
    Poziom 27  

    BlueDraco napisał:
    Nie ma "przerwań synchronicznych", jest tylko błędna terminologia.
    O! I to lubię - jasno, konkretnie i bezkompromisowo :) Informację o tym, że SVC to "software interrupt" znalazłem na stronie ARMa. Denerwujący jest ten bałagan :/ Od jutra biorę się za lekturę i zgłębianie tematu ;)

    Kurczę... wychodzi na to, że priorytet błędów to już w ogóle błędnie rozumiałem :roll: Przy braku możliwości obsługi błędu to, z tego co pamiętam, następowała "eskalacja błędu" albo procesor wpadał w coś o wdzięcznej nazwie "lockup". Jak nie zapomnę to wrzucę opis z dokumentacji. Może komuś się przyda.

    Nie zapomniałem:
    Cortex-M3 Generic User Guide
    napisał:
    In some situations, a fault with configurable priority is treated as a HardFault. This is called priority escalation, and the fault is described as escalated to HardFault. Escalation to HardFault occurs when:
    • A fault handler causes the same kind of fault as the one it is servicing. This escalation to HardFault occurs because a fault handler cannot preempt itself because it must have the same priority as the current priority level.
    • A fault handler causes a fault with the same or lower priority as the fault it is servicing. This is because the handler for the new fault cannot preempt the currently executing fault handler.
    • An exception handler causes a fault for which the priority is the same as or lower than the currently executing exception.
    • A fault occurs and the handler for that fault is not enabled.

    The processor enters a lockup state if a fault occurs when executing the NMI or HardFault handlers. When the processor is in lockup state it does not execute any instructions.

    0
  • #12 09 Lis 2015 09:00
    BlueDraco
    Specjalista - Mikrokontrolery

    Dawniej to się nazywało w ARM SWI, a jakiś czas temu zmienili nazwę na SVC (supervisor call) - i słusznie. PendSV to jest właśnie "software interrupt".

    0
  • #13 09 Lis 2015 12:42
    szczywronek
    Poziom 27  

    W pierwszym poście dodałem nowy załącznik - pseudo-erratę do Poradnika, uwzględniającą wszystkie zgłoszone błędy.

    Cofam to: priorytet błędów to już w ogóle błędnie rozumiałem. To nie z priorytetami mam problem tylko ogólnie z błędami i pułapkami. Dziękuję za wskazanie właściwej drogi :) Poczytam, pobawię się na żywym organizmie i jakby co to będę pytał.

    BlueDraco napisał:
    w aktualnych, nowych wersjach plików nagłówkowych dla F4 już nie ma BSRRL i BSRRH
    Nie do końca, jest jeszcze śmieszniej:
    - plik nagłówkowy z paczki STM32F4 DSP and SPL: stm32f4xx.h, wersja V1.6.1, data 21-10-2015: są osobne definicje połówek
    - plik nagłówkowy z paczki STM32 Cube FW F4: stm32f429xx.h, wersja V2.4.1, data 09-10-2015: jest jeden rejestr 32bitowy

    0
  • #14 09 Lis 2015 13:12
    tadzik85
    Poziom 38  

    szczywronek napisał:


    BlueDraco napisał:
    w aktualnych, nowych wersjach plików nagłówkowych dla F4 już nie ma BSRRL i BSRRH
    Nie do końca, jest jeszcze śmieszniej:
    - plik nagłówkowy z paczki STM32F4 DSP and SPL: stm32f4xx.h, wersja V1.6.1, data 21-10-2015: są osobne definicje połówek
    - plik nagłówkowy z paczki STM32 Cube FW F4: stm32f429xx.h, wersja V2.4.1, data 09-10-2015: jest jeden rejestr 32bitowy


    Wynika z poprawnej zmiany wszystkich rejestrów na 32-bitowe.
    (jak się przyjrzycie nigdzie nie spotkanie reserved dopełniającego do 32-bitów)

    0
  • #15 12 Lis 2015 11:58
    szczywronek
    Poziom 27  

    Mały update :) Errata w pierwszym poście podmieniona na ładniejszą wersję.

    @tadzik85 - to po co w nagłówku z SPL, ST uparcie trzyma się dwóch 16 bitowych połówek? Funkcje "biblioteczne" i tak pewnie nie korzystają z rejestrów BSRR/BRR, a z kolei użytkownicy biblioteki (z założenia) rzadko korzystają bezpośrednio z nagłówka :] Więc większość nie zauważyłaby różnicy.

    0
  • Pomocny post
    #16 12 Lis 2015 12:00
    tadzik85
    Poziom 38  

    szczywronek napisał:
    Mały update :) Errata w pierwszym poście podmieniona na ładniejszą wersję.

    @tadzik85 - to po co w nagłówku z SPL, ST uparcie trzyma się dwóch 16 bitowych połówek? Funkcje "biblioteczne" i tak pewnie nie korzystają z rejestrów BSRR/BRR, a z kolei użytkownicy biblioteki (z założenia) rzadko korzystają bezpośrednio z nagłówka :] Więc większość nie zauważyłaby różnicy.


    Bo SPL is dead, jest tylko utrzymywany nie rozwijany. A zmiana wynika (tak mi się wydaje) z problemami z dostępem do rejestrów krótszych niż 32b. A w przypadku rejestru o którym mowa niemożliwość zerowania i ustawienia rożnych bitów w jednym kroku).

    Dlatego twój poradnik powinien operować na plikach z Cube nie SPL (brak SPL dla F7 i L0).

    0
  • #17 12 Lis 2015 16:35
    BlueDraco
    Specjalista - Mikrokontrolery

    Z Erraty:
    "po wejściu do handlera wyjątku (np. ISR) wyjątki (w szczególności przerwania) nie są blokowane jak w AVR"

    No to akurat nie jest prawdą. Przerwania są blokowane dokładnie tak samo, jak w AVR, czyli blokowane są przerwania o priorytetach nie wyższych niż bieżący. AVR ma tylko dwa poziomy priorytetowe (wątku i przerwania), więc wszystkie przerwania maskowalne mają poziom nie wyższy niż jedyny dostępny poziom przerwań. ;)

    Różnica pomiędzy ATmega i Cortex leży wyłącznie w liczbie poziomów priorytetowych, a nie w działaniu mechanizmu zmiany priorytetu procesora, które jest takie samo praktycznie we wszystkich procesorach.

    0
  • #18 12 Lis 2015 17:32
    szczywronek
    Poziom 27  

    @tadzik85 - jak dla mnie SPLa mogłoby by w ogóle nie być :} Niemniej jednak wydaje mi się to dziwaczne, że pliki nagłówkowe z nazwami rejestrów - dla tego samego mikrokontrolera - są różne, w różnych bibliotekach...
    Jak zaczynałem z STMami to wszędzie królował SPL. Trochę mi się nie uśmiecha zabawa w porównywanie plików nagłówkowych... ale coś czuję, że mnie to nie ominie.

    @BlueDraco - dobrze wiedzieć, że ktoś to w ogóle czyta :D A to mnie Kolega zaskoczył. Spróbuję obronić to co napisałem - tzn. nie to że się upieram że mam rację, tylko coś mi się to znowu przestaje kleić do kupy:

    AVR Datasheet napisał:
    When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled. The user software can write logic one to the I-bit to enable nested interrupts. All enabled interrupts can then interrupt the current interrupt routine. The I-bit is automatically set when a Return from Interrupt instruction – RETI – is executed.

    Atmel pisze, że automatycznie zostają zablokowane wszystkie przerwania - czyli rozumiem, że to jest wejście na "wyższy poziom"? No dobra jesteśmy w ISR, na wyższym poziomie (poziomie przerwań), ale po odblokowaniu przerwań możliwe jest ich zagnieżdżanie. I tu mi się wali: skoro wszystkie przerwania mają ten sam priorytet (no bo są tylko dwa poziomy priorytetów), to czemu nagle jedno przerwanie może przerwać inne? Czy odblokowanie przerwań w przerwaniu powoduje, że przerwanie "schodzi" poziom niżej? Do poziomu "wątku"? Bez sensu :)

    0
  • #19 12 Lis 2015 17:40
    tadzik85
    Poziom 38  

    szczywronek napisał:
    @tadzik85 - jak dla mnie SPLa mogłoby by w ogóle nie być :} Niemniej jednak wydaje mi się to dziwaczne, że pliki nagłówkowe z nazwami rejestrów - dla tego samego mikrokontrolera - są różne, w różnych bibliotekach...
    Jak zaczynałem z STMami to wszędzie królował SPL. Trochę mi się nie uśmiecha zabawa w porównywanie plików nagłówkowych... ale coś czuję, że mnie to nie ominie.
    :)


    32-bity na każdy rejestr oraz rozbicie na większą ilość plików (np F417 i F415 to inne pliki) to jedyne tak naprawdę różnice. dotyczy to również definicji nazw przerwań.

    Reszta bez zmian.

    Dodano po 1 [minuty]:

    szczywronek napisał:
    Atmel pisze, że automatycznie zostają zablokowane wszystkie przerwania - czyli rozumiem, że to jest wejście na "wyższy poziom"? No dobra jesteśmy w ISR, na wyższym poziomie (poziomie przerwań), ale po odblokowaniu przerwań możliwe jest ich zagnieżdżanie. I tu mi się wali: skoro wszystkie przerwania mają ten sam priorytet (no bo są tylko dwa poziomy priorytetów), to czemu nagle jedno przerwanie może przerwać inne? Czy odblokowanie przerwań w przerwaniu powoduje, że przerwanie "schodzi" poziom niżej? Do poziomu "wątku"? Bez sensu :)


    Bo to nie jest jakieś wymyślne blokowanie a automatyczne wyzerowanie odpowiedniego bitu który można ponownie ręcznie ustawić.

    0
  • #20 12 Lis 2015 19:37
    BlueDraco
    Specjalista - Mikrokontrolery

    Dokładnie tak właśnie jest. W Cortex też możesz programowo obniżyć priorytet procesora w obsłudze przerwania, tylko nikt normalny tego nie robi. Ani na AVR ani na Cortex nie ma to sensu i jest bardzo dobrym źródłem błędów w oprogramowaniu, ale wielu "guru" zachęca do do odblokowywania przerwań w obsłudze przerwania na AVR. Na szczęście na Cortex już nie mają takich pomysłów.

    0
  • #21 13 Lis 2015 13:50
    szczywronek
    Poziom 27  

    @tadzik85 - dziękuję za skrót różnic między nagłówkami :)

    Ale... no bez jaj. Czyli bit "Global Interrupt Enable" (czy jak on się tam zwał) w AVR, decyduje o tym na jakim poziomie pracuje procesor? ISR z "odblokowanymi" przerwaniami to poziom wątku, a "main" z "wyłączonymi" przerwaniami to poziom przerwań? A całe to "włączanie/wyłączanie" przerwań to taki... skrót myślowy!?

    0
  • #22 13 Lis 2015 15:36
    tadzik85
    Poziom 38  

    szczywronek napisał:
    @tadzik85 - dziękuję za skrót różnic między nagłówkami :)

    Ale... no bez jaj. Czyli bit "Global Interrupt Enable" (czy jak on się tam zwał) w AVR, decyduje o tym na jakim poziomie pracuje procesor? ISR z "odblokowanymi" przerwaniami to poziom wątku, a "main" z "wyłączonymi" przerwaniami to poziom przerwań? A całe to "włączanie/wyłączanie" przerwań to taki... skrót myślowy!?


    Trochę za daleko posunięta uwaga ze main z wyłączonymi przerwaniami to poziom przerwań. Ale mniej więcej tak jest. w przerwaniu zrobisz cli() i przerwanie (nawet to samo może znów się wywołać. Natomiast w Cortexie jak zrobisz enable_interrupts (ustawione domyślnie) to tak jest zawsze. Po drodze masz NVIC i to on decyduje o priorytetach. A włączanie i wyłączanie przerwań (NVIC czy global w przerwaniu niczego nie zmieni) w zakresie priorytetów.

    Wszelkie dywagacje i poradniki radzę robić na podstawie Cube czy też plików z niego zaczerpniętych. SPL niezyje już od roku.

    Co do poradnika. nie czytałem kropka w kropkę ale w przykładach zauważyłem niekonsekwentne stosowanie __DSB().

    W dodatku zabrakło informacji o poprawnym wyłączaniu przerwań. CO do testu BB masz rację. Jednak jasno powinieneś zaznaczyć ze jest to test wykonywania prędkości zapisu pod obszar BB a nie jego wykorzystania. RMW pewnie da bardzo zbliżona szybkość.

    PS. ST po 3 latach znajomości z nimi przyznało otwarcie nasze biblioteki są nieoptymalne. W dodatku zauważają drastycznie mniejsze ich wykorzystanie.

    0
  • #23 13 Lis 2015 20:49
    BlueDraco
    Specjalista - Mikrokontrolery

    W prawie każdym procesorze kwestia priorytetów przerwań i ich blokowania wygląda tak samo. Jest coś takiego jak priorytet procesora i priorytet przerwania, niezależnie od tego, jak to nazwał producent. jeśli przez chwilę zapomnimy o NMI, to w większości 8-bitowców mamy dwa priorytety procesora (poziom wątku i poziom przerwania) i jeden priorytet przerwań.

    W Cortex M0 mamy z grubsza 5 priorytetów procesora - poziom wątku i 4 poziomy przerwań. Priorytet w CM0 można zmienić na 2 sposoby - przez modyfikację pola priorytetu lub ustawienie bitu PRIBOOST (to właśnie robi __disable_irq()). Ustawienie PRIBOOST wymusza priorytet 0 (najwyższy), niezależnie od wartości ustawionej w polu priorytetu - w te sposób procesor przestaje reagować na przerwania. W CM3 i CM4 na ogół mamy 9 poziomów (8 poziomów przerwań).
    Poziomy "ujemne" są z grubsza równoważne poziomowi 0 i służą tylko do arbitrażu wyjątków.

    Priorytet w AVR (starych) można zmienić programowo na jeden sposób - przez ustawienie bitu "maski przerwań".

    Ogólnie należy unikać programowych zmian priorytetów, a zwłaszcza obniżania priorytetu - z tego mogą wyniknąć paskudne błędy w działaniu oprogramowania. Praktycznie jedyna bezpieczna operacja na priorytecie to podbicie go i późniejsze przywrócenie (czyli np. zablokowanie przerwań na czas wykonania sekcji krytycznej).

    0
  • #24 14 Lis 2015 00:40
    szczywronek
    Poziom 27  

    tadzik85 napisał:
    SPL niezyje już od roku.
    Dopisuję do listy "poprawek" wymianę nagłówka. Swoją drogą ST mogłoby to ładnie na czerwono napisać na swojej stronie, a nie "Marketing status: Active".

    Co do DSB. Nie wiem co rozumiesz przez "niekonsekwentne stosowanie". Instrukcję barierową stosowałem praktycznie tylko w przykładach dla F4 przy okazji włączania zegara dla peryferiów, tak jak ST sugeruje w erracie.

    tadzik85 napisał:
    jest to test wykonywania prędkości zapisu pod obszar BB a nie jego wykorzystania
    Nie rozumiem tego fragmentu. Co Kolega ma na myśli mówiąc o "wykorzystaniu"? Chodzi o to, że testuję jedynie prędkość zapisu do aliasu BB a nie prędkość "użytecznych" operacji z wykorzystaniem BB?

    @BlueDraco - mam wrażenie, że m.in. bałagan z "jak to nazwał producent" powoduje, że potem mam (i pewnie nie tylko ja) sieczkę w głowie. Przeszukałem przed chwilą (przyznaję, dosyć pobieżnie) Internet pod kątem "AVR + priorytety" i... cisza. Atmel wszędzie pisze o "Interrupt Enable", w pierwszej książce o AVRach z jakiej się uczyłem jest podobnie:

    J. Doliński, Mikrokontrolery AVR w praktyce napisał:
    Można także włączyć lub wyłączyć cały system przerwań ustawiając lub zerując bit...

    Przez kilka lat to "wyłączanie systemu przerwań" solidnie mi się zakorzeniło, więc gdy Kolega zwrócił uwagę że blokowanie w AVR działa tak samo jak w Cortexie, to trochę zdurniałem :roll:
    Ale jest sukces - Wasze wypowiedzi na temat priorytetów w coraz mniejszym stopniu mnie zaskakują**. Szczególnie te Cortexowe, bo tu przynajmniej od początku wiedziałem o istnieniu priorytetów.

    --------
    ** No może z wyjątkiem tej o "z grubsza równoważności" poziomów niedodatnich... z tym muszę się przespać ;)

    0
  • #25 14 Lis 2015 14:59
    tadzik85
    Poziom 38  

    Co do DSB(). W przykładach stosowałeś go ale nie wszędzie. A należy go stosować zawsze po włączeniu zegara, jeśli natychmiast dokonujesz zapisu pod włączane peryferium. W każdym rdzeniu Cortexa. Ja stosuje zawsze po włączeniu przez to nigdy o tym nie zapominam - taki nawyk. Tak samo należy go zastosować np po wyczyszczeniu flagi jeśli od razu masz zamiar ja sprawdzać.

    DSB i ISB stosuje się po włączeniu i wyłączeniu przerwania czy to globalnie czy też nie jeśli już następna instrukcja jest od tego zależna.


    Co to BB test prędkości zapisów pod obszar SRAM lub SRAM_BB daje jakieś wyniki.
    Ale sensowniejszym jest test porównujący zerowanie (ustawienie) bitu jedną i drugą metodą. W klasycznej przecież dochodzi maskowanie bitów i odczyt. To jest porównanie praktyczne. Jak sam zauważyłeś bezsensownym jest ciągle pisanie pod adres.

    0
  • #26 14 Lis 2015 17:28
    szczywronek
    Poziom 27  

    tadzik85 napisał:
    Co do DSB(). [...] W każdym rdzeniu Cortexa.
    Rozumiem. Bardzo cenna uwaga (i ta następna o DSB+ISB też!), dziękuję. Swoją drogą, skoro bariera powinna być stosowana niezależnie od układu, to ST bez sensu zamieściło taką informację w erracie do F4 (w F1 cisza).

    Ad BB: masz rację, test porównujący dwie metody kasowania/ustawiania byłby ciekawszy z praktycznego punktu widzenia. Tylko nie wiem czy jest sens się w to bawić? Ten eksperyment z "dodatku" wrzuciłem głównie dlatego, że uznałem to za interesującą ciekawostkę, no i szkoda było mi wyrzucać wyniki :) Cytując poradnik: "Co z tego wynika w praktyce? Absolutnie nic. Sztuka dla sztuki".

    Tak przy okazji. Trochę mnie niepokoi mały odzew ze strony początkujących STMowców. Zakładam, że wciągnęła ich zabawa i męczą się z przykładowymi zadaniami ;)

    0
  • #27 14 Lis 2015 17:36
    tadzik85
    Poziom 38  

    szczywronek napisał:
    tadzik85 napisał:
    Co do DSB(). [...] W każdym rdzeniu Cortexa.
    Rozumiem. Bardzo cenna uwaga (i ta następna o DSB+ISB też!), dziękuję. Swoją drogą, skoro bariera powinna być stosowana niezależnie od układu, to ST bez sensu zamieściło taką informację w erracie do F4 (w F1 cisza).

    Ad BB: masz rację, test porównujący dwie metody kasowania/ustawiania byłby ciekawszy z praktycznego punktu widzenia. Tylko nie wiem czy jest sens się w to bawić? Ten eksperyment z "dodatku" wrzuciłem głównie dlatego, że uznałem to za interesującą ciekawostkę, no i szkoda było mi wyrzucać wyniki :) Cytując poradnik: "Co z tego wynika w praktyce? Absolutnie nic. Sztuka dla sztuki".

    Tak przy okazji. Trochę mnie niepokoi mały odzew ze strony początkujących STMowców. Zakładam, że wciągnęła ich zabawa i męczą się z przykładowymi zadaniami ;)


    STM32F0 snippets. Zwracam uwagę. Oraz na fakt w np w RM do L0 na końcu w załączniku są przykłady właśnie na rejestrach.

    Co do dokumentacji F1, zauważyłem że w porównaniu z RM do F4 jest dość wybrakowana.

    0
  • #28 15 Lis 2015 16:43
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie należy przesadzać z barierami - one są potrzebne tylko w nielicznych przypadkach. Po pierwsze - nie używamy barier przy dostępach do obszarów, w których obowiązuje ścisła kolejność operacji ("strong ordering"). Dwa zapisy do takiego obszaru zawsze następują we właściwej kolejności. Problemem może być odczyt następujący bezpośrednio po zapisie, gdy obszar nie gwarantuje "strong ordering" dla wszystkich dostępów, a jedynie dla samych zapisów i samych odczytów oddzielnie - dlatego, że odczyt może wtedy wyprzedzić zapis.

    Ciekawostka: ja w moich projektach na Cortexach (łącznie będzie ich min. z 50) ani razu nie miałem potrzeby użycia instrukcji bariery.

    Bywały kiedyś takie uC (Luminary Micro), na których i bariera nie pomagała po włączeniu zegara peryferiala - trzeba było programowo odczekać kilka cykli, bo problem nie leżał bynajmniej w kolejności zapisów a w odstępie czasowym pomiędzy zapisem i zadziałaniem modułu. Z kolei na STM32F nie zauważyłem w ogóle takiego opóźnienia (ale nigdy nie robiłem nic na F1, a tam być może ono jest).

    Co do filozofii wyjątków: o Cortex też można napisać, że "zmieniając stan bitu PRIBOOST możemy całkowicie zablokować/odblokować przerwania" - i będzie to prawda, chociaż zupełnie nie tłumaczy to, o co naprawdę chodzi. Posługując się pojęciem priorytetu procesora i wyjątku możemy jednolicie wyjaśnić działanie dowolnego systemu przerwań na dowolnym procesorze, małym i dużym, 8- i 64-bitowym, z jednym i z szesnastoma poziomami priorytetów przerwań.

    0
  • #29 15 Lis 2015 17:05
    tadzik85
    Poziom 38  

    BlueDraco napisał:
    Nie należy przesadzać z barierami - one są potrzebne tylko w nielicznych przypadkach. Po pierwsze - nie używamy barier przy dostępach do obszarów, w których obowiązuje ścisła kolejność operacji ("strong ordering"). Dwa zapisy do takiego obszaru zawsze następują we właściwej kolejności. Problemem może być odczyt następujący bezpośrednio po zapisie, gdy obszar nie gwarantuje "strong ordering" dla wszystkich dostępów, a jedynie dla samych zapisów i samych odczytów oddzielnie - dlatego, że odczyt może wtedy wyprzedzić zapis.

    Ciekawostka: ja w moich projektach na Cortexach (łącznie będzie ich min. z 50) ani razu nie miałem potrzeby użycia instrukcji bariery.
    Czyli erraty i dokumentacji nie znamy?

    Przyjrzyj się dowolnej erracie do STM i problemie włączenia zegara.

    Po przejrzeniu paru errat zapytam ich o ten brak konsekwencji.

    0
  • #30 15 Lis 2015 18:45
    szczywronek
    Poziom 27  

    No to się porobiło... A ja staram się przekonać Czytelników, że to wszystko jest proste :)

    @tadzik85 - przejrzałem "snippetsy" dla F0 (kilka przykładów) i nigdzie nie mogę znaleźć tam instrukcji barierowych. Podobnie w przykładowych kodach z RM do L0 i erracie do F1 (stąd zresztą było moje zdziwienie gdy zwróciłeś uwagę na potrzebę stosowania).

    BlueDraco napisał:
    Z kolei na STM32F nie zauważyłem w ogóle takiego opóźnienia (ale nigdy nie robiłem nic na F1, a tam być może ono jest).
    Hm. Akurat w erracie do F4 jest info żeby wstawić opóźnienie po włączeniu zegara. Pochwalę się: program (F4) wykorzystujący kontroler FMC (dodatkowy ram na płytce discovery) nie chciał działać bez DSB po włączeniu zegara dla kontrolera. Przy F1 nigdy nic podobnego mnie nie spotkało.

    Ad priorytety: łapię :) To są dwie strony tego samego medalu - "wyłączenie przerwań" to po prostu wywindowanie priorytetu procesora tak żeby żadne z przerwań nie mogło zostać obsłużone. A że w małych AVR są tylko dwa poziomy to całość można uprościć do "zablokowane/odblokowane przerwania".

    Na koniec zagadka około-barierowa dla chętnych - gdy program utknie w pętli nieskończonej to dioda się będzie świecić czy też nie? [optymalizacja Os; program przetestowany na F1 i F4, w obu wypadkach rezultat ten sam]
    Kod: c
    Zaloguj się, aby zobaczyć kod

    0