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/