Grzegorz Niemirowski <g...@g...net> wrote:

>> 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.

A widzisz, faktycznie :) Robiłem to z menu pojawiającego się po kliknięciu
pinu i tam nie było. Dzięki.

> 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.

Jednak się dało -- we wspomnianym w p. 1 menu. Wygenerował:

/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);

> 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.

Hmm, nie mam nic takiego.

https://ibb.co/MBsK0f7

> 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.

A można mieszać jedno z drugim, czy HAL trzyma jakiś swój stan, który się
rozjedzie, gdy zacznę mu pisać po rejestrach?

> GPIO_Pin to maska bitowa zawierająca listę pinów,

A, i to jest kluczowa informacja :)

> Swoją drogą to fajny ficzer STM32, że pinami portu możesz sterować
> atomowo, nie ma read-modify-write.

Właśnie widzę -- fajna rzecz, często pisząc na AVR musiałem wrzucać atomic
blocks właśnie przez nieatomowość prostego wystawienia stanu na porcie.

>> 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.

Hmm, chyba mentalnie umieściłem HAL wyżej, niż faktycznie jest.

Ja zwykle piszę sobie różne pomocnicze funkcje i np. moja funkcja "set
LED" ma zapalić diodę, a jak ta dioda jest podłączona i jaki stan trzeba
wystawić, to jest już zmartwienie tej funkcji. HAL widziałem mniej więcej
na tym poziomie.

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

I za każdym razem po przegenerowaniu kodu odpalasz astyle lub coś takiego?

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

Najzwyklejszy LCD bez wbudowanego kontrolera. One degradują się od DC.

Stąd zresztą potrzeba przełączania GPIO raz jako wejście, a raz jako
wyjście (chcę podłączyć do pinu rezystory, ustalające na nim połowę
napięcia zasilającego, gdy STM odłączy od niego swoje drivery). Taki
projekt badawczy, żeby zobaczyć, czy uda się uzyskać dostateczny kontrast
sterując w taki sposób LCD (mający 4 backplane'y). Jak się nie uda, to
spróbuję z PWM a jak i to się nie uda to trudno, mam już w koszyku
PCF8566.

> 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.

Hm, ciekawe. To co dokładnie dzieje się podczas wgrywania wsadu przez
ST-Link? Peryferia działają, ale program się zatrzymuje i I/O (o ile nie
jest sprzętowo kontrolowane np. przez timer z PWM) zatrzymuje się w takim
stanie, w jakim było?

--
Pacjent mówi do lekarza:
- Ugryzł mnie pies.
Lekarz odpowiada.
- Gdzie?
- Na rogu, koło szkoły.