Dokąd zmierza świat?

Tak. Że autor wątku który twierdzi że HAL jest dla debili a porządni programiści robią na rejestrach, uruchomił program na HALu ale nie potrafi tego zrobić na rejestrach.

atom1477 pisze: ↑

02 cze 2025, 14:33

Tak. Że autor wątku który twierdzi że HAL jest dla debili a porządni programiści robią na rejestrach, uruchomił program na HALu ale nie potrafi tego zrobić na rejestrach.

A to jakiś wstyd nie umieć czegoś, co nigdy wcześniej nie było potrzebne?
Wiem, że są sposoby żeby podłożyć funkcji adres w pamięci od którego ma się uruchomić, ale teraz nie chodzi mi o to żeby zaczęło działać, tylko żeby się dowiedzieć dlaczego nie działa, bo to bardzo cenna wiedza.

tuxcnc pisze: ↑

02 cze 2025, 14:30

I nie pieprzcie, że NVIC_EnableIRQ ustawia DIER, bo gówno prawda.

Ok, pomyliłem się.
Zezwala na obsługę w rejestrze NVIC->ISER a nie DIER.
Nie mniej jednak nie jest to konfigurowanie przerwania, tylko zezwalanie na jego obsługę.
W szczególności, ta funkcja nie przypisuje adresu funkcji przerwania (a zdaje się że myślisz że to robi).
Fakt, w Arduino mogli coś popierniczyć, ale nazwa się nie zgadza z nazwą funkcji przerwania, więc sądzę że jest tak jak było w normalnym programowaniu STMa.

tuxcnc pisze: ↑

02 cze 2025, 14:30

ale teraz nie chodzi mi o to żeby zaczęło działać, tylko żeby się dowiedzieć dlaczego nie działa, bo to bardzo cenna wiedza.

Uparcie nie chcesz się tego dowiedzieć. Dałbyś w przerwaniu zapalanie LEDa, i już byś wiedział o wiele więcej.
Nie zapala się: procek chodzi w inną funkcję przerwania. A tam zastaje na przykład while(1).
Zapala się: procek wchodzi do Twojej funkcji, ale np. nie kasuje bitu przerwania (przez co wchodzi w to przerwanie w kółko).
LED to skrót myślowy. Nie misi tam być fizycznego LEDa, tylko wystarczy multimetrem czy oscyloskopem sprawdzić napięcie na pinie.

atom1477 pisze: ↑

02 cze 2025, 14:40

Uparcie nie chcesz się tego dowiedzieć. Dałbyś w przerwaniu zapalanie LEDa, i już byś wiedział o wiele więcej.
Nie zapala się: procek chodzi w inną funkcję przerwania. A tam zastaje na przykład while(1).
Zapala się: procek wchodzi do Twojej funkcji, ale np. nie kasuje bitu przerwania (przez co wchodzi w to przerwanie w kółko).
LED to skrót myślowy. Nie misi tam być fizycznego LEDa, tylko wystarczy multimetrem czy oscyloskopem sprawdzić napięcie na pinie.

Ale Ty dalej nie czytasz tego co piszę, tylko dyskutujesz z tym, co sam wymyśliłeś...
Jak mam zapalić LED-a, kiedy procesor jest martwy a program w ogóle się nie uruchamia?
Zresztą to nie o to chodzi.
Kiedy włączysz przerwania bitem DIER, to procek działa. Zapewne (bo tak powinno być) tablica przerwań jest zapisana rozkazami powrotu z przerwania. Dzięki temu można wywołać przerwanie, które nie ma napisanej obsługi i po prostu dzieje się nic.
Użycie NVIC_EnableIRQ zapewne robi taki burdel w systemie, że dzieją się cuda...
Coś znalazłem https://www.stm32duino.com/viewtopic.php?t=1923
To trochę nie na temat, ale w okolicy.
Wynika z tego, że HAL tak się rozpanoszył, że uniemożliwia korzystanie z funkcji, które były wcześniej dostępne.
W skrócie, jak się chce korzystać ze starego kodu, to trzeba HAL wyłączyć.
Na razie nic mi się nie udało z tym zrobić, ale brzmi to rozsądnie i pasuje do problemu.

tuxcnc pisze: ↑

02 cze 2025, 16:04

Ale Ty dalej nie czytasz tego co piszę, tylko dyskutujesz z tym, co sam wymyśliłeś...
Jak mam zapalić LED-a, kiedy procesor jest martwy a program w ogóle się nie uruchamia?

A gdzie ja napisałem że masz zapalić LEDa?
Napisałem żebyś dodał kod zapalający LEDa! A czy procek łaskawie tego LEDa zapali czy nie, to już on zdecyduje. I na podstawie tego co zrobi, będziesz mógł dojść do odpowiednich wniosków. Tak trudno to zrozumieć?

Poza tym nigdzie nie pisałeś że procek jest martwy. Napisałeś:

tuxcnc pisze: ↑

02 cze 2025, 12:58

Przecież napisałem wyraźnie, że po przepełnieniu licznika procek się wiesza

Więc naprawdę zaczynam myśleć żeś tępy...

tuxcnc pisze: ↑

02 cze 2025, 16:04

Cholera wie gdzie wchodzi i co robi, bo nie ma jak tego sprawdzić.

No tosz właśnie LEDem byś to sprawdził...

atom1477 pisze: ↑

02 cze 2025, 16:11

Poza tym nigdzie nie pisałeś że procek jest martwy.

Uparcie odpowiadasz na posty, których nie czytałeś.

tuxcnc pisze: ↑

02 cze 2025, 14:30

Jeśli obie linie są odkomentowane, to konwerter serial<>USB jest martwy i niczego więcej sprawdzić się nie da.
(Poprzednio (TIM1 i USB) procek się wieszał dopiero przy przerwaniu, tutaj układ się w ogóle nie daje uruchomić.)

A może on wchodzi do przerwania tuż po starcie? Czyli nie jest "martwy" od samego początku, tylko od wejścia do przerwania?
Poza tym masz ST-Linka. To nie możesz zatrzymać rdzenia i zobaczyć adresu w rejestrze PC?

atom1477 pisze: ↑

02 cze 2025, 16:24

Poza tym masz ST-Linka. To nie możesz zatrzymać rdzenia i zobaczyć adresu w rejestrze PC?

Ale co mi to da?
Ja szukam kodu który robi problem, a Ty mi każesz dłubać w procesorze...
Jeśli Arduino na STM32 nie da się używać bez HAL, no to się nie da i nie ma sensu tego robić, bo za co się nie zabierzesz, to będzie droga przez mękę...

tuxcnc pisze: ↑

02 cze 2025, 16:49

Ja szukam kodu który robi problem, a Ty mi każesz dłubać w procesorze...

Ręce opadają.
A radź se sam.