Problem już dawno został zdiagnozowany i przedstawione rozwiązanie.
Szkoda czasu na tłumaczenie po 10 razy komuś, kto wogole tego nie czyta i robi po omacku po swojemu nie mając pojęcia co robi i jeszcze się rzuca i przezywa.
Ten typ nie zasługuje na jakąkolwiek pomoc!

tuxcnc pisze: ↑

02 cze 2025, 16:04

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.

Przecież dostałeś taka odpowiedź na samym początku, o tu:

atom1477 pisze: ↑

01 cze 2025, 22:41

A wywaliłeś HALa? Bo ten błąd wskazuje że HAL jest i gdzieś w sobie już ma zadeklarowaną funkcję obsługi przerwania.

Oraz tu:

drzasiek90 pisze: ↑

01 cze 2025, 22:41

To znaczy, że HardwareTimer (z biblioteki STM32Duino) już ma własną wersję obsługi tego przerwania, i Twój kod ją duplikuje.

Ale byłeś tak zajęty wyzywaniem nas od debili że zignorowałes wszystkie odpowiedzi.
Jesteś kretyn do potęgi i tyle.
Nie dość, że nie za bardzo wiesz co robisz to jeszcze nie słuchasz podpowiedzi.
Tyle w temacie.

Jakbyś odpowiadał na pytania i sprawdzał to co masz zasugerowane to byś już miał problem rozwiązany.
Wystarczy odnaleźć gdzie masz w kodzie procedurę obsługi tego przerwania (bo ją masz, tak zgłasza twój kompilator przy próbie dodania jej drugi raz).
Ale wolisz rżnąć głupa dalej.

tuxcnc pisze: ↑

01 cze 2025, 23:32

A teraz mi tłumaczysz, że to ja jestem kretynem...

Jesteś, bo zamiast przeanalizować co ci ktoś podpowiada, to jesteś przekonany o swojej nieomylności i jeszcze obrażasz innych.
NIE ZASŁUGUJESZ NA POMOC I POWINIENEŚ SOBIE RADZIĆ SAM, SKORO NIE POTRAFISZ ZAPANOWAĆ NAD WŁASNYM CHAMSTWEM.

tuxcnc pisze: ↑

01 cze 2025, 23:32

Znaczy to dokładnie tyle, że NVIC_EnableIRQ(TIM1_UP_IRQn) nie działa tak, jak można oczekiwać.

NIE!
To może oznaczać bardzo wiele, np to, że nie masz w programie procedury obsługi przerwania (po informacji kompilatora wiemy, że już jest), albo jest ona nieprawidłowa. Nie pokazałeś programu tylko skrawek więc zgadnąć trudno. A sam nie chcesz sprawdzić.
Dopisując kod który ci podałem, kompilator CI WYRAŹNIE PODPOWIEDZIAŁ, ŻE TAKA PROCEDURA JUŻ W TWOIM PROGRAMIE JEST!
Więc albo ją odszukaj i sprawdź co tam nie gra albo ją usuń z programu i używaj własnej!
Skoro nie używasz HALA i bibliotek to po prostu je usuń z projektu - pewnie inkludujesz coś bezmyślnie do projektu.
Procedura obsługi przerwania w twoim kodzie najprwdopodobniej jest "pusta" i nie ma kasowania flagi przerwania od przepełnienia licznika, dlatego po pierwszym przepełnieniu przerwanie wykonuje się cały czas, stąd program się "wiesza".

Nie masz przypadkiem w twoim ulepionym programie takiej linii?
#include <HardwareTimer.h>
lub nie używasz jakiejś innej biblioteki która korzysta z HardwareTimer?

Tobie naprawdę nie warto pomagać.
To ty sobie nie radzisz z tak prostym problemem, nie ja.
Nie mój kod wywala błąd tylko Twój projekt do którego bezmyślnie dodałeś kawałek mojego kodu, bo nie rozumiesz co się dzieje.
Nie pokazałeś całego projektu tylko fragment kodu więc nie wiadomo co dodajesz i gdzie.
Ale już zostało wszystko wyjaśnione gdzie jest problem i co powinieneś zrobić aby mieć obsługę przerwania i aby nie było błędu!
Jeśli tego nie rozumiesz to jesteś po prosru miernym programistą i naprawdę powinieneś rozważyć aby zająć się czymś innym.
Temat jest wyczerpany i średnio ogarnięty programista na podstawie tych informacji będzie wiedział co zrobić.
A ty rżnij głupa dalej bo na "dziękuję za pomoc" jesteś za słaby.
Więc lepiej odwrócić kota ogonem i jeszcze obrażać tych co ci pomogli.
Jesteś niemożliwe wkurzający i irytujący.

tuxcnc pisze: ↑

01 cze 2025, 22:45

Przecież to Ty utworzyłeś własny TIM1_UP_IRQHandler używając extern "C"...

Czytasz czasem jakie głupoty piszesz?
Nie przeanalizowałes sam co ci wyrzucił kompilator więc dostałeś ode mnie informację gdzie i w czym jest błąd.
Podałem ci dwie możliwe opcje.
Do obsługi przerwania musisz mieć jego obsługę.
Więc albo utwórz swoją (pokazałem ci jak bo nie wiesz jak, ale wtedy nie używaj biblioteki która już to samo implementuje) albo nie twórz swojej i skorzystaj z tej którą już masz w bibliotece.

A jak nie potrafisz takich prostych rzeczy to zajmij się malowaniem albo jaka inna sztuką - ty byś zapewne takiej rady udzielił.
Ale i tak tego nie zrozumiesz.

To znaczy, że HardwareTimer (z biblioteki STM32Duino) już ma własną wersję obsługi tego przerwania, i Twój kod ją duplikuje.

Opcja 1: Nie używaj HardwareTimer
Opcja 2: Nie twórz własnego TIM1_UP_IRQHandler

atom1477 pisze: ↑

01 cze 2025, 19:26

Ja uważam że są coraz gorsi, bo nie muszą robić rzeczy jakie musieli robić kiedyś.

Ale jaki to ma związek?
Nie robią tego co kiedyś, bo technologia się zmieniła.
Ale sytuację można odwrócić, kiedyś programiści też nie musieli robić tego co robią obecni.
Czy możemy powiedzieć, że aktualnie chirurdzy są gorsi niż kiedyś? Też dostali masę sprzętu i technologii ułatwiającej pracę.

atom1477 pisze: ↑

01 cze 2025, 19:26

A że programiści są gorsi to wnioskuję z prób znalezienia wykonawców do określonych prac.

Ale to nie jest dowód na to, że programiści są gorsi.
To jest dowód na to, że dobrych programistów ciężko znaleźć, albo że jest ich mało, albo że dobrzy programiści zarabiają na tyle dobrze na etacie że nie szukają dodatkowej fuchy.

Zgodzę się co do jednego.
Aktualnie dostępne technologie pozwalają na to, że programować mogą nawet średniaki.
Stąd jest całkiem sporo kiepskich programistów.
Ale to nie jest jednoznaczne z tym, że ci dobrzy aktualni są gorsi od tych dobrych kiedyś.

Podtrzymuje, że programiści są coraz lepsi.
Takie jest moje zdanie, wy możecie mieć inne

Ja uważam, że jest dokładnie odwrotnie.
Jest zapotrzebowanie na coraz lepszych programistów i programiści są coraz lepsi.
Oczywiście, że są i gorsi. Kiedyś też byli lepsi i gorsi.
Ale porównujemy najlepszych z kiedyś
do najlepszych obecnie.
I dlatego uważam, że są coraz lepsi.
Zmieniła się tylko charakterystyka pracy inżyniera, więc i sposób działania inny.

Zaś co do kowali to racja - jest ich coraz mniej bo nie ma zapotrzebowania.
Gdyby było, kowale byłoby coraz lepsi i lepsi niż kiedyś - bo mieliby lepsze narzędzia.

Bo jakość to połączenie wiedzy, umiejętności i narzędzi.