Przerwania pozwalają mikrokontrolerowi reagować natychmiast na zdarzenie, zamiast bez końca sprawdzać stan pinu w pętli głównej. W projektach z przyciskami, enkoderami, czujnikami impulsów czy precyzyjnym pomiarem czasu to często różnica między stabilnym działaniem a gubieniem sygnałów. Poniżej pokazuję, jak działa obsługa przerwań w Arduino, kiedy naprawdę ma sens, jak napisać bezpieczny handler i czego unikać, żeby układ nie zachowywał się losowo.
Najkrótsza droga do poprawnych przerwań w Arduino
- Przerwanie warto stosować wtedy, gdy zdarzenie jest krótkie, ważne i może pojawić się w dowolnym momencie.
- W ISR rób tylko minimum: ustaw flagę, zwiększ licznik, odnotuj czas.
- Do przypisywania pinu używaj
digitalPinToInterrupt(), bo mapowanie różni się między płytkami. - Zmiennych współdzielonych przez ISR i
loop()pilnuj przezvolatileoraz, gdy trzeba, krótkie sekcje krytyczne. - Przyciskom zwykle trzeba dodać debounce, najczęściej w zakresie 20–50 ms.
- Jeśli projekt ma działać na różnych płytkach, sprawdzaj dokumentację konkretnej rodziny, a nie zakładaj tych samych pinów wszędzie.
Kiedy przerwanie wygrywa z pollingiem
Najprościej mówiąc, polling polega na ciągłym sprawdzaniu stanu pinu w loop(), a przerwanie przekazuje procesorowi informację: „zajmij się tym teraz”. W prostych projektach polling wystarcza, ale gdy pętla robi coś cięższego, na przykład obsługuje ekran, komunikację szeregową albo logikę sterowania, opóźnienie reakcji szybko rośnie. Jeśli wstawisz do pętli choćby delay(10), to już sam ten fragment ustawia ci dolny limit reakcji na około 10 ms.
| Sytuacja | Polling | Przerwanie |
|---|---|---|
| Rzadki przycisk menu | Wystarcza | Zwykle zbędne |
| Enkoder obrotowy | Łatwo gubi impulsy | Najczęściej lepsze rozwiązanie |
| Czujnik przepływu lub obrotów | Ryzyko utraty impulsów | Duża przewaga |
| Prosty automat czasowy | Wygodne i czytelne | Nie zawsze potrzebne |
Ja zwykle zaczynam od pytania, czy zdarzenie może pojawić się szybciej, niż pętla zdąży je zauważyć. Jeśli odpowiedź brzmi „tak”, przerwanie przestaje być dodatkiem, a staje się podstawowym mechanizmem obsługi. Skoro to już jasne, przechodzę do samego wywołania i tego, jak wygląda ono w praktyce.
Jak działa attachInterrupt w praktyce
W Arduino najczęściej korzysta się z attachInterrupt(), które podpina funkcję obsługi przerwania, czyli ISR, do wybranego pinu i określonego warunku. Dokumentacja Arduino pokazuje tu trzy rzeczy, o których warto pamiętać od początku: numer pinu najlepiej podawać przez digitalPinToInterrupt(), ISR nie przyjmuje parametrów, a tryb wyzwalania trzeba dobrać do sygnału. Najczęściej używa się RISING, FALLING, CHANGE albo LOW; na części płytek dostępny jest też tryb HIGH.
const byte buttonPin = 2;
volatile bool buttonEvent = false;
void setup() {
pinMode(buttonPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(buttonPin), onButtonPress, FALLING);
}
void loop() {
if (buttonEvent) {
buttonEvent = false;
// tutaj robisz właściwą obsługę zdarzenia
}
}
void onButtonPress() {
buttonEvent = true;
}Ten wzorzec działa dobrze, bo ISR niczego nie liczy i niczego nie blokuje. Zapisuje tylko fakt, że zdarzenie nastąpiło, a cała cięższa logika wraca do loop(), gdzie kod jest bezpieczniejszy i łatwiejszy do utrzymania. Właśnie w tym miejscu zaczyna się różnica między kodem, który „działa na stole”, a kodem, który działa stabilnie także po kilku godzinach pracy.
Warto też pamiętać, że na klasycznych płytkach z ATmega328P, takich jak Uno czy Nano, zewnętrzne przerwania są zwykle związane z pinami 2 i 3, natomiast na innych rodzinach mapowanie jest inne. Z tego powodu digitalPinToInterrupt() jest praktyczniejsze niż wpisywanie numeru pinu na sztywno. Gdy mechanizm jest już podłączony, najważniejsze staje się to, co dzieje się wewnątrz samego handlera.
Jak pisać ISR, które nie psuje reszty programu
Najważniejsza zasada jest prosta: ISR ma być krótka. W praktyce oznacza to kilka instrukcji, a nie mały program w programie. Jeśli w handlerze uruchomisz długie obliczenia, wypisywanie na port szeregowy albo opóźnienia czasowe, to zaczniesz blokować inne przerwania i rozjeżdżać timing całego układu.
- Ustawiaj flagę lub licznik, zamiast wykonywać pełną logikę.
-
Oznacz zmienne współdzielone jako
volatile, żeby kompilator nie przechowywał ich tylko w rejestrach. - Jeśli odczytujesz zmienną wielobajtową, kopiuj ją atomowo, na krótko wyłączając przerwania.
-
Nie używaj
delay()ani ciężkiegoSerial.print()wewnątrz ISR. - Debounce przycisku rób poza ISR albo sprzętowo, zwykle w oknie 20–50 ms.
volatile unsigned long pulses = 0;
void onPulse() {
pulses++;
}
void loop() {
noInterrupts();
unsigned long localPulses = pulses;
interrupts();
// dalej liczysz prędkość, filtrujesz wynik, wysyłasz dane
}Ten drugi przykład pokazuje istotny detal: unsigned long ma więcej niż jeden bajt, więc na mikrokontrolerze 8-bitowym jego odczyt może zostać przerwany w połowie. Krótka sekcja z noInterrupts() i interrupts() chroni taki odczyt, ale trzeba jej używać oszczędnie, bo każde wyłączenie przerwań wydłuża czas reakcji całego systemu. Gdy ten fundament masz pod kontrolą, pozostaje dobrać właściwy pin i właściwą płytkę.
Które piny i płytki faktycznie obsługują przerwania
Tu najłatwiej o błąd, bo różne płytki Arduino mają różne mapowanie. W dokumentacji Arduino dla klasycznych płytek z ATmega328P przerwania zewnętrzne są zwykle dostępne na pinach 2 i 3, a na Mega 2560 lista jest szersza. Z kolei na nowszych rodzinach, takich jak Uno WiFi Rev2, wsparcie bywa szersze niż w starych klasykach, dlatego nie warto polegać na pamięci albo na jednym uniwersalnym schemacie.
| Płytka | Co warto zapamiętać |
|---|---|
| Uno, Nano, Mini i inne z ATmega328P | Najczęściej przerwania zewnętrzne są na D2 i D3. |
| Mega 2560, Mega ADK | Obsługa obejmuje m.in. D2, D3, D18, D19, D20 i D21; piny 20 i 21 współdzielą się z I2C. |
| Micro, Leonardo i inne z ATmega32u4 | Mapowanie jest inne niż w Uno, więc najlepiej sprawdzać je przez digitalPinToInterrupt(). |
| Uno WiFi Rev2 i część nowszych płytek | Zakres dostępnych pinów jest szerszy, ale szczegóły zależą od konkretnej rodziny. |
W praktyce ja nie uczę się tych wartości na pamięć dla każdej płytki, tylko traktuję je jako punkt wyjścia. Najbezpieczniej jest sprawdzić dokumentację danej płytki i dalej budować kod tak, żeby numer pinu był odseparowany od logiki aplikacji. To szczególnie ważne, gdy projekt ma przejść z jednego modelu na drugi bez przepisywania połowy programu.
Jeśli na klasycznym AVR potrzebujesz reagować na większą liczbę wejść niż pozwalają dwa dedykowane przerwania, wchodzą w grę przerwania zmiany stanu pinu, czyli pin change interrupts. To już wariant bardziej zaawansowany, ale bywa bardzo przydatny w enkoderach, licznikach impulsów i projektach, w których liczy się każdy kanał wejściowy. Po wyborze płytki dobrze też wiedzieć, gdzie przerwania robią największą różnicę w samych zastosowaniach.
Gdzie przerwania naprawdę pomagają w projektach
Najwięcej zysku dają tam, gdzie zdarzenie jest krótkie, a jego utrata psuje całą logikę systemu. W swoich projektach najczęściej widzę cztery takie scenariusze.
- Przyciski funkcyjne i wejścia użytkownika - dobre do wykrywania krótkich, nagłych zdarzeń, choć przycisk nadal wymaga debouncu.
- Enkodery obrotowe - tutaj przerwania bardzo pomagają, bo impulsy potrafią pojawiać się szybko i nieregularnie.
- Czujniki przepływu, obrotów i prędkości - każdy impuls ma znaczenie, więc polling bywa zbyt wolny.
- Wybudzanie z uśpienia - mikrokontroler może spać i reagować dopiero na zdarzenie z zewnątrz, co pomaga oszczędzać energię.
Jeśli projekt ma jeszcze wysyłać dane do minikomputera, na przykład przez UART, SPI albo I2C, to mikrokontroler bardzo często powinien odpowiadać za sam pomiar i zliczanie impulsów, a minikomputer za analizę, zapis lub interfejs. To ważne rozróżnienie: Arduino i podobne mikrokontrolery reagują deterministycznie, natomiast minikomputer z systemem operacyjnym ma większy narzut i zwykle większy jitter czasowy. Dla prostego sterowania to nie problem, ale dla precyzyjnego zliczania impulsów albo bardzo szybkiej reakcji mikrokontroler nadal wygrywa.
W praktyce taki podział ról daje najlepszy efekt: Arduino przechwytuje zdarzenie, a większy komputer robi to, co wymaga więcej pamięci, sieci lub wygodnego interfejsu. Dzięki temu nie próbujesz zmuszać jednego urządzenia do wszystkiego naraz, co w projektach elektronicznych zwykle kończy się niepotrzebnym chaosem. Zanim jednak zamkniesz temat, warto przejść przez krótką listę kontroli.
Przed pierwszym testem zrób ten krótki przegląd
Jeśli projekt nie działa od razu, zwykle winny jest jeden z kilku powtarzalnych błędów, a nie sama idea przerwań. Ja sprawdzam je w tej kolejności:
- Czy ISR robi wyłącznie minimum i nie zawiera logiki, która może poczekać?
- Czy wszystkie współdzielone zmienne mają
volatile? - Czy wybrany pin rzeczywiście obsługuje przerwanie na tej konkretnej płytce?
- Czy przycisk lub czujnik ma obsłużony debounce albo stabilny sygnał wejściowy?
- Czy odczyt licznika jest chroniony, jeśli zmienna ma więcej niż jeden bajt?
- Czy nic nie koliduje z I2C, SPI albo UART na wybranych pinach?
- Czy testujesz układ także bez monitora szeregowego i bez dodatkowych opóźnień w pętli?
Jeśli zaczniesz od prostego wzorca: krótki ISR, flaga w loop(), właściwy pin i debounce tam, gdzie trzeba, przerwania przestają być źródłem problemów, a stają się jednym z najpewniejszych narzędzi w pracy z Arduino. To właśnie ten moment odróżnia działający prototyp od stabilnego projektu, który można bez stresu rozwijać dalej.
