Jak podzielić zadania między przerwania a pętlę główną w STM32F411?

Uczę się programowania uC w C. Bazuję na STM32F411. Programy opieram na bibliotekach HAL.

Ostatnio sporo czasu poświęciłem na szukanie błędów w swoim kodzie. Okazało się że struktura mojego programu była nieprawidłowa. Dopiero po jakimś czasie przypomniało mi się że przerwania powinny być jak najkrótsze.

I teraz mam pytanie:
Co można dawać w przerwaniach,a co w głównej pętli programu.

Chodzi mi o obsługę takich peryferii, jak: silnik krokowy, wyświetlacz 16x2, przyciski ADC, SPI, I2C, USART/UART, wykonywanie skomplikowanych (długich) obliczeń.

Każdy problem rozwiązuje się inaczej. Nie ma złotej reguły co, gdzie i jak ma być zrealizowane. Projektowanie oprogramowania to jest już trochę trudniejszy temat a tematy hard real time jeszcze trudniejsze.

Musisz się nauczyć jak działa mikrokontroler, co tak naprawdę chcesz zrealizować i ile czasu na to potrzebujesz, ile możesz mieć opóźnienia itp.

Robiłem wiele systemów i nie ma złotego środka. Może być C lub C++ może być bare metal ale może być i system operacyjny. Po prostu musisz wiedzieć co robisz pisząc kod, a to niestety proste nie jest bo obejmuje wiele zagadnień jednak systematycznie ucząc się o toolchainie, języku programowania, architekturze układu na jakim pracujesz itp Będziesz w stanie dobrze zaprojektować oprogramowanie. A tak jak na razie to metoda prób i błędów oraz zadawaniu pytań na forum (tylko oby nie za ogólnych, bo ciężko odpowiadać na ogólne pytania tak jak w sumie to powyżej).

tadeusz12345 napisał:

Co można dawać w przerwaniach,a co w głównej pętli programu.

Jak już kol. @_lazor_ nie ma jedynie słusznych reguł. Wszystko zależy od okoliczności. Funkcje obsługi przerwań powinny być możliwie najkrótsze, ale bez przesady. Wiele osób popada w skrajności, ustawiając w ISR jakieś flagi, a potem dublując obsługę w reszcie programu. Szczególnie na MCU, na którym masz wielopoziomową obsługę ISR, przerwanie może być obsługiwane całkiem długo i nie ma z tym problemu. Po prostu przerwaniu istotniejszemu nadajesz wyższy poziom. Oczywiście z tą długością też nie należy przesadzać i wielopoziomowa obsługa wymaga zapewne większej sprawności w pisaniu i panowaniu nad kodem.
Obsługa wolnych interfejsów typu I2C, UART, wręcz prosi się o przerwania (lub alternatywnie DMA + przerwania). SPI to raczej DMA, przy dużych szybkościach transferu przerwania zajechałyby MCU, lub ich obsługa pochłonęłaby więcej czasu niż sam transfer. ADC - zależnie od szybkości próbkowania - DMA lub DMA + przerwania. Silnik krokowy - timer + przerwania, żadna pętla główna bo nici z sensownego sterowania. Wyświetlacz 16x2 to domyślam się że coś na HD - też przerwania się przydają. Robienie długich obliczeń - czemu nie. W sumie przy pomocy przerwań można je podzielić na bloki, wrzucenie tego w pętlę główną może stworzyć jeszcze większe problemy, np. z responsywnością interfejsu. Chociaż tu może już o jakiś RTOS warto by się pokusić.

tadeusz12345 napisał:

Dopiero po jakimś czasie przypomniało mi się że przerwania powinny być jak najkrótsze

Bardziej chodzi o to aby mieć świadomość jak przerwania i program główny wpływają na siebie wzajemnie. Można napisać program który 99% czasu będzie wisiał w przerwaniu a całość będzie działać prawidłowo.

Może być np. inicjowanie w maiin, a cała reszta w przerwaniach. Przy wielopoziomowym systemie przerwań niemal każdy projekt da się zrobić w taki sposób, ale oczywiście potrzeba do tego pewnej wiedzy i świadomości informatycznej. Bez tej wiedzy kończy się zwykle na magicznych zasadach typu "przerwania powinny być jak najkrótsze".