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.
Zakładam, że to błąd. Można to obejść edytując wygenerowany main.c (co
i tak zostanie nadpisane przy najbliższej zmianie w CubeMX) lub konfigurując
port jeszcze raz, już po tej konfiguracji z main.c. Czy jest bardziej
elegancki sposób? Może edycja pliku .ioc? Jest tekstowy i widzę w nim:

PA0-WKUP.GPIOParameters=GPIO_Label
PA0-WKUP.GPIO_Label=KEY
PA0-WKUP.Locked=true
PA0-WKUP.Signal=GPIO_Input

Może tu coś można dopisać?

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

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.

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?

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?

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.

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.

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.

Chyba na razie tyle z pytań...

Pozdr.

--
- Dlaczego słoń nie może mieć dzieci z zebrą?
- Bo nie potrafi z niej zdjąć tej cholernej piżamy w paski!

do góry

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/

do góry

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.

do góry

Arnold Ziffel <a...@h...invalid> wrote:
> 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.
<snip>
> 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.
>
> 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?

Chyba duzo ludzi uzywa HAL-a. Czesc uzywa interfejs low level.
Ja zaczelem od biblioteki 'libopencm3', z tym ze sporo rzeczy
robilem bezposrednio.

Co do szybkiego przelaczania: mysle ze filozofia wielu programow
zaklada konfiguracje na starcie a potem brak zmian. W STM32
konfiguracja moze byc dosc "ciezka": na starcie wiekszosc urzadzen
jest wylaczona (dla oszczednosci energii), zeby je uaktywnic
trzeba w paru miejscach zrobic odpowiednie ustawienia. Np.
dla GPIO jest lock register: mozesz zablokowac zmiany konfiguracji
az do nastepnego resetu.

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

Normalnie chcesz zeby zapis pin(ow) to byla 1-3 instrukcje
maszynowe: w ogolnej wersji jedna umieszcza adres portu
w rejestrze procesora, druga umieszcza wartosc w rejestrze
procesora, trzecia presyla wartosc z rejestru procka do
portu. W wielu sytuacjach potrzebne sa juz w rejestrach
procesora, wtedy wystarczy pojedyncza instrukcja. Jak
masz odpowiednie makra (czy funkcje inline) to tak bedzie
(nie wiem czy HAL to robi). Negacje mozesz wrzucic w
miare prosta makrologia, ale to moze (nie musi) dodac
dodatkowe instrukcje wiec nie jest dobre jako defaultowy
ficzer.

> 7. Pytanie bardziej o sam mikrokontroler. W jakim stanie b?d? piny, gdy
> procesor wejdzie w stan resetu

W datasheet jest stan rejestrow po resecie. We wszystkich modelach
STM32 ktore widzialem normaly stan po resecie to bylo "input floating".

> (bo np. b?d? wrzuca? nowy program przez
> programator)?

Ja uzywalem STlink (sprzet) z opensourcowym programem stlink.
On _nie_ resetowal procka do programowania. Jak byla jakas
dziwna konfiguracja urzadzen to zostawala po programowaniu

Tak a propo: duzo modeli ma bootloader. Jak odpowiednio
ustawisz piny (i ewentualnie flagi konfiguracji) to
bootloader startuje po resecie. Niezaleznie od tego czy
bootloader wystatartowal mozesz programowac przez STlink
(SWD). Ale stan procka sie rozni: bootloader konfiguruje
niektore urzadzenia.

--
Waldek Hebisch

do góry

On Mon, 25 Jul 2022 18:11:59 +0200, "Grzegorz Niemirowski"
<g...@g...net> wrote:
> 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

Ale jest coś takiego jak rejestry SET/CLR/INV (w pic32/mips), dzięki
którym za pomocą jednej operacji atomowej można ustawić, skasować lub
przestawić dowolny bit na porcie czy rejestrze?
Np. PORTESET=16 ustawi bit na 4 pinie portu E albo TRISEINV=16
przestawi bit kierunku na pinie 4 portu E.

--
Marek

do góry

W dniu 2022-07-26 o 08:14, Marek pisze:
> On Mon, 25 Jul 2022 18:11:59 +0200, "Grzegorz Niemirowski"
> <g...@g...net> wrote:
>> 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
>
> Ale jest coś takiego jak rejestry SET/CLR/INV (w pic32/mips), dzięki
> którym za pomocą jednej operacji atomowej można ustawić, skasować lub
> przestawić dowolny bit na porcie czy rejestrze?
> Np. PORTESET=16 ustawi bit na 4 pinie portu E albo TRISEINV=16 przestawi
> bit kierunku na pinie 4 portu E.
>
W nowych avr-ach (mega 0) też to już jest. Nawet toggle można atomowo robić.

--
Janusz

do góry

Marek <f...@f...com> napisał(a):
> Ale jest coś takiego jak rejestry SET/CLR/INV (w pic32/mips), dzięki
> którym za pomocą jednej operacji atomowej można ustawić, skasować lub
> przestawić dowolny bit na porcie czy rejestrze?
> Np. PORTESET=16 ustawi bit na 4 pinie portu E albo TRISEINV=16 przestawi
> bit kierunku na pinie 4 portu E.

Jest takie coś, nazywa się bitbanding.

#include "stm32f4xx.h"

#define BITBAND_PERI_REF 0x40000000
#define BITBAND_PERI_BASE 0x42000000
#define BITBAND_PERI(a,b) ((BITBAND_PERI_BASE + (a-BITBAND_PERI_REF)*32 +
(b*4)))

#define GPIOA_ODR ((unsigned int)&(GPIOA->ODR))

#define GPIOA_ODR5 *((volatile unsigned char *) (BITBAND_PERI(GPIOA_ODR,
5)))
#define GPIOA_ODR6 *((volatile unsigned char *) (BITBAND_PERI(GPIOA_ODR,
6)))

void main(void) {
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; //włącz GPIOA
GPIOA->MODER |= GPIO_MODER_MODER5_0; //LED1 - output
GPIOA->MODER |= GPIO_MODER_MODER6_0; //LED2 - output
GPIOA->PUPDR |= GPIO_PUPDR_PUPDR7_0; //przycisk - pull up
while(1) {
if (GPIOA->IDR & GPIO_IDR_IDR_7) { //przycisk puszczony
GPIOA_ODR5 = 1;
GPIOA_ODR6 = 0;
} else { //naciśnięty
GPIOA_ODR5 = 0;
GPIOA_ODR6 = 1;
}
}
}


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

do góry

>> 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
>
Kiedyś było nieco inaczej - przy generowaniu kodu zaklikiwało
się checkboksy HAL i/lub LL.

Teraz w Project Manager, Advanced Settings w panelu Driver Selector
dla każdego peryferia wybierasz, czy chcesz mieć HAL, czy LL.
Nie można wybrać obu, ale jak testowo wybrałem dla czegoś
tam HAL, a dla czegoś innego LL, to pojawiły się pliki *hal* i *ll*.

Szczegółów nie podam, ja z tych programujących na rejestrach.
Kiedyś, w czasach przed HAL i LL była Standard Pheriperal Library
- w licencji było, że służy tylko jako przewodnik dla klientów
i nie należy jej stosować we własnych projektach.
Nie żałuję - jak ktoś już pisał, rejestry w STM32 są całkiem
sensowne. HAL i LL traktuję jak SPL kiedyś - jako przewodnik.

Pozdrowienia,
MKi

do góry

Arnold Ziffel <a...@h...invalid> napisał(a):
> Hmm, nie mam nic takiego.
> https://ibb.co/MBsK0f7

To może być kwestia ustawień opcji generowania kodu. Zobacz sobie folder
rezpozytorium Cube:
C:\Users\Arnold\STM32Cube\Repository\STM32Cube_FW_F4
_V1.27.0\Drivers\STM32F4xx_HAL_Driver\Src

Miganie LED-em low level:
http://grzegorz.net/stm32/src/LED_blink_LL.txt

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

HAL prawie nic nie trzyma z wyjątkiem zmiennej uwTick od liczenia ticków 1
ms oraz aktualnego taktowania rdzenia w zmiennej SystemCoreClock. Do tego w
strukturach peryferiów trzyma sobie np. lock. Ogólnie można mieszać. Ja np.
w aktualnym projekcie używam HAL-a ale jak chciałem ustawić wartość PWM, to
napisałem zwyczajnie:
TIM1->CCR4 = value;
zamiast:
__HAL_TIM_SET_COMPARE(&tim1, TIM_CHANNEL_4, value);

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

Tutaj nie ma czegoś takiego. HAL ma po prostu ukrywać rejestry i dawać
przenośność kodu. Dla mnie główna wartość leży w gotowych sterownikach
peryferiów, np. jest gotowa funkcja HAL_I2C_Mem_Read().

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

Ja akurat używam Cube jako dodatkowe narzędzie. Wypluwa mi kod w innym
miejscu i przeklejam interesujące fragmenty do projektu.

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

Tutaj mogło mi się pomylić. Sprawdziłem teraz na STM32CubeProgrammer i tam
kliknięcie Connect powoduje wyłączenie PWM niezależnie od wyboru jednego z
trzech trybów resetu. Natomiast jeśli w Eclipse zatrzymam program, to PWM
działa dalej.

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

do góry

Marek wrote:

> On Mon, 25 Jul 2022 18:11:59 +0200, "Grzegorz Niemirowski"
> <g...@g...net> wrote:
>> 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
>
> Ale jest coś takiego jak rejestry SET/CLR/INV (w pic32/mips), dzięki
> którym za pomocą jednej operacji atomowej można ustawić, skasować lub
> przestawić dowolny bit na porcie czy rejestrze?
> Np. PORTESET=16 ustawi bit na 4 pinie portu E albo TRISEINV=16
> przestawi bit kierunku na pinie 4 portu E.
>

Są rejestry, BRR i BSRR, do ustawiania pojedyńczych bitów na porcie.




--
jp

www.flowservice.pl
www.flowsystem.pl

do góry