eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaSTM32 i HAL -- pierwsze podejście, pierwsze pytaniaRe: STM32 i HAL -- pierwsze podejście, pierwsze pytania
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!1.us.feeder.erj
    e.net!feeder.erje.net!news.uzoreto.com!usenet.blueworldhosting.com!feed1.usenet
    .blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!peer03.ams4!peer.a
    m4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-0
    1.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!news.neostrada.pl.POSTED!not
    -for-mail
    From: "Grzegorz Niemirowski" <g...@g...net>
    Newsgroups: pl.misc.elektronika
    References: <1...@h...invalid>
    Subject: Re: STM32 i HAL -- pierwsze podejście, pierwsze pytania
    Date: Mon, 25 Jul 2022 18:11:59 +0200
    MIME-Version: 1.0
    Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
    Content-Transfer-Encoding: 8bit
    X-Priority: 3
    X-MSMail-Priority: Normal
    X-Newsreader: OE PowerTool 4.5.5
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7681
    X-WWW: https://www.grzegorz.net/
    Lines: 113
    Message-ID: <62dec0ce$0$560$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 89.65.244.230
    X-Trace: 1658765518 unt-rea-b-01.news.neostrada.pl 560 89.65.244.230:65518
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 6358
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:773470
    [ ukryj nagłówki ]

    Arnold Ziffel <a...@h...invalid> napisał(a):
    > Hej,
    > Tak jak pisałem -- zacząłem trochę rzeźbić w STM32. Programator jeszcze
    > nie przyszedł (zdecydowałem, że jednak nie użyję płytki Nucleo tylko od
    > razu wrzucę MCU w projektowany układ), ale zacząłem pisać kod na sucho.
    > I tu pojawia się kilka pytań / problemów.
    > 1. STM32CubeMX nie umożliwia ustawienia pull-upa na wejściowym pinie.

    Umożliwia. System Core -> GPIO. Klikamy w pin i w dolnej tabelce można
    wyklikać pull-up lub pull-down.

    > 2. Podobnie jest z pinami wyjściowymi -- nie widzę nigdzie możliwości
    > ustawienia ich domyślnego stanu. HAL konfiguruje je jako wyjścia i tyle.
    > W jakim stanie te wyjścia będą zaraz po konfiguracji i czy można to
    > zmienić? Znów, fragment pliku .ioc:
    > PC13-ANTI_TAMP.GPIOParameters=GPIO_Label
    > PC13-ANTI_TAMP.GPIO_Label=LED
    > PC13-ANTI_TAMP.Locked=true
    > PC13-ANTI_TAMP.Signal=GPIO_Output

    Wydaje mi się, że nie ma możliwości wyklikania tego i trzeba ręcznie.
    Ponieważ stan rejestrów wyjściowych nie jest modyfikowany, piny będą w
    stanie niskim.

    > 3. Czy ja dobrze widzę, że HAL nie udostępnia możliwości szybkiego
    > przełączania pinu między wejściem i wyjściem? Tak się składa, że w
    > pierwszym projekcie, do którego chcę użyć STM32, potrzebuję trzech stanów
    > (niski, wysoki i wysokiej impedancji). Akurat tutaj nie potrzebuję tego
    > szybko (co 4 ms), więc sztuczka z wywoływaniem (stosunkowo ciężkiej)
    > funkcji HAL_GPIO_Init() się uda, ale nie wyobrażam sobie tego w bardziej
    > krytycznych czasowo sytuacjach.

    HAL słynie ze swoich ciężkich struktur i funkcji konfigurujących. W pewnym
    momencie ST zorientowało się, że coś jest nie tak i udostępniło obok HAL-a
    sterowniki Low Level. W wygenerowanym kodzie, w katalogu HAL-a, oprócz
    plików stm32*_hal_* są też pliki stm32*_ll_*. Obejrzyj sobie jakie funkcje
    zawierają. Są właśnie taką lekką alternatywą. Poza tym te ciężkie funkcje
    inicjalizują dużo rzeczy naraz i nie pozwalają zmienić tylko jednej bez
    ruszania innych.

    > A może w ogóle obsługa GPIO przez HAL to zabawka dla początkujących i
    > nikt, kto programuje na serio, nie korzysta z tego, tylko pisze
    > bezpośrednio do portów?

    Są ludzie gardzący HAL-em, można ich spotkać na Elektrodzie. Jak zwykle
    trochę słusznie a trochę nie. Ja używam HAL-a, ale trzeba rozumieć jak
    działa i jaka jest filozofia jego twórców. W każdym razie HAL jest popularny
    i moim zdaniem nie trzeba go unikać. Z drugiej strony rejestry STM32 nie są
    jakoś dużo bardziej skomplikowane od AVR i można też jechać bezpośrednio na
    rejestrach.

    > 4. Czy ja dobrze widzę, że HAL nie umożliwia agregowania pinów? Chciałbym
    > jednocześnie zmienić stan konkretnych pinów w porcie -- czy da się to
    > zrobić przez HAL, czy trzeba pisać bezpośrednio do portu?

    W przypadku GPIO HAL jest bardzo prostą nakładką i masz to samo jak przy
    pisaniu bezpośrednio:

    void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState
    PinState)
    {
    if (PinState != GPIO_PIN_RESET)
    {
    GPIOx->BSRR = (uint32_t)GPIO_Pin;
    }
    else
    {
    GPIOx->BRR = (uint32_t)GPIO_Pin;
    }
    }

    W zależności od tego, czy na pinie ma być stan wysoki czy niski, jedynka
    jest zapisywana do rejestru ustawiającego lub zerującego bit w rejestrze
    wyjściowym. GPIO_Pin to maska bitowa zawierająca listę pinów, na których
    operujesz. Tak więc agregacja jest, możesz ustawić/wyzerować w jednej
    linijce wszystkie piny portu. Przy czym ta agregacja jest taka naprawdę
    sprzętowa, HAL jedynie daje proste opakowanie. Swoją drogą to fajny ficzer
    STM32, że pinami portu możesz sterować atomowo, nie ma read-modify-write.

    > 5. Mamy piękny enum GPIO_PinState, a w nim wartości GPIO_PIN_SET oraz
    > GPIO_PIN_RESET. Czy HAL umożliwia takie skonfigurowanie portu, żeby port
    > był zanegowany (czyli np. pisząc PIN_SET chcemy tak naprawdę ustawić tam
    > stan niski, i tak samo odczytując)? Nie widzę nic takiego, a skoro już
    > wprowadzili HAL, to wydaje mi się to rozsądne i logiczne.

    O ile wiem, to nie ma czegoś takiego. Te funkcje do operowania na GPIO to
    prawie jakbyś pisał bezpośrednio do rejestrów.

    > 6. Szablon generowany przez CubeMX jest wyindentowany dwiema spacjami. Ja
    > mam inny styl pisania. Czy jest możliwość zmiany indentacji
    > wygenerowanego kodu w taki sposób, żeby kolejna generacja kodu mi tego
    > nie przywróciła? Na razie poradziłem sobie tak, że po prostu
    > przeniosłem swój kod do osobnego pliku i wołam go z wygenerowanego
    > main.c, ale burzy mi to poczucie estetyki.

    Też chciałbym wiedzieć, na razie przerabiam ręcznie.

    > 7. Pytanie bardziej o sam mikrokontroler. W jakim stanie będą piny, gdy
    > procesor wejdzie w stan resetu (bo np. będę wrzucał nowy program przez
    > programator)? Piny zostaną tak, jak są, czy przejdą w stan wysokiej
    > impedancji? Może można jakoś wymusić ich konkretny stan przed samym
    > programowaniem? Mam do pinów podłączony LCD, więc z oczywistych powodów
    > nie chcę na nich DC.

    To jakiś specjalny LCD, że napięcie stałe mu szkodzi?

    Jeśli mikrokontroler wejdzie w programowy reset, to peryferia działają
    dalej, np. PWM. Przy czym ST-Link może resetować uC programowo i sprzętowo.

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: