Przerwania
– Informacje wstępne
Przerwanie to bardzo użyteczna funkcja w bardziej zaawansowanych programach na Arduino. Działanie polega na dosłownym przerwaniu na krótką chwilę wykonywania programu głównego. W tej krótkiej chwili zostaje wykonany niewielki program zapisany w funkcji przerwania. Przerwanie zawsze aktywuje się po zdefiniowanym wcześniej zdarzeniu.
W arduino są trzy typy przerwań możliwe do zdefiniowania:
– Przerwania zegara (wewnętrzne)
Przerwanie wyzwalane jest cyklicznie przy użyciu zegara mikrokontrolera z zadaną wcześniej częstotliwością. Arduino może w tym czasie wykonywać dodatkowe zadania (wątki) poza programem głównym. Wskazaniem do zastosowania przerwań tego typu są ważne do zrealizowania zadania, które nie mogą czekać na swoją kolej w programie głównym oraz muszą być wykonywane cyklicznie.
Podstawowym parametrem charakteryzującym przerwanie zegara jest częstotliwość wywoływania wątku. Czas wykonywania zadania w przerwaniu nie powinien trwać dłużej niż czas liczony między dwoma przerwaniami. W przeciwnym wypadku mikrokontroler nie zdąży wykonać zadania przed kolejnym wywołaniem, co skutkować będzie zawieszeniem mikrokontrolera lub niestabilną pracą.
– Przerwania zewnętrzne
– Przerwania zmiany stanu pinu (PCINT)
Przerwania zewnętrzne
- watchdog
- alternatywa funkcji delay()
- progmem
Pamięć SRAM w Arduino
W przypadku, gdy skończy nam się pamięć flash w naszym Arduino, kompilator wyraźnie to komunikuje, uniemożliwiając wgranie programu do mikrokontrolera. W przypadku pamięci SRAM problemy mogą pojawić się w trakcie wykonywania poprawnie załadowanego programu.
SRAM (skrót od “Static Random Access Memory”) pełni podobną funkcję w mikrokontrolerze jak pamięć RAM w komputerze PC, tz. przechowują ulotne dane, które zarządzane są poprzez realizowany w Arduino program. W najbardziej popularnej płytce Arduino Uno mamy do dyspozycji 2kB pamięci SRAM.
Optymalizacja pamięci SRAM:
Gdy w mikrokontrolerze zaczyna brakować nam pamięci dynamicznej SRAM, należy albo zmienić model mikrokontrolera, na taki, który zapewniać będzie większą ilość pamięci SRAM (np. zamiana Arduino Uno na Arduino Mega) lub wykonać proces optymalizacji napisanego już programu.
Co należy zrobić:
- Usunąć nieużywane zmienne z kodu programu (niestety standardowe oprogramowanie Arduino IDE nie wskazuje, które zmienne są nieużywane – w tym przypadku często należy po kolei sprawdzać każdą zmienną np. komentując deklarację zmiennej i sprawdzając czy kompilator nie zgłosił błędu).
- Przemyśleć, czy wszystkie zmienne są odpowiedniego typu. Np. jeśli deklarujemy zmienną typu INT, która podczas działania programu przyjmuje tylko wartości “0” lub “1” – to niepotrzebna strata miejsca pamięci SRAM. W tym przypadku należy użyć zmiennej typu BOOLEAN. Zmianę taką wprowadzamy tylko i wyłącznie, gdy jesteśmy w 100% pewni, że dana wartość nie przekroczy deklarowanego zakresu.
- Statyczne zmienne typu string umieścić w funkcji F(), która umieszcza je w PROGMEM.
(…)
Na co warto zwrócić uwagę:
- Warto nie zapełniać pamięci SRAM do 100% – Arduino sygnalizuję kończące się miejsce oraz sygnalizuje o potencjalnych problemach.
- Czy w programie nie występują błędy rekurencji:
Nadzór pamięci SRAM:
(…)
Pętle w programie
Dobrym nawykiem programowania Arduino jest unikanie dodatkowych pętli wewnątrz programu głównego. Chodzi tu głównie o pętle “while”, “do – while”. Program wewnątrz sekcji “loop { … }” wykonywany jest cykliczne – ta główna pętla programu powinna nam wystarczyć. Zazwyczaj unikanie pętli w programie głównym jest czasochłonne – jednak przy większych i bardziej skomplikowanych programach trud ten nie pójdzie na marne. Nad takim programem łatwiej będzie nam zapanować i uniknąć wielu błędów. Dodatkowym ryzykiem stosowania pętli są źle postawione warunki wyjścia z pętli. W takim przypadku program nigdy nie opuście wadliwej części programu.
Przykład unikania pętli opisany był wcześniej w podrozdziale “alternatywa funkcji delay(…)”. Funkcja “delay(…)” jest pewnego rodzaju pętlą, która nic nie wykonuje w zdefiniowanym czasie.
Nie oznacza to jednak, że za wszelką cenę należy całkowicie rezygnować z używania pętli w swoich programach. Jeżeli już zostaje ona użyta, powinna być możliwie krótka oraz zawierać przejrzyste warunki wyjścia (najlepiej z dodatkowym warunkiem zabezpieczającym). Pętle typu “for” są bezpieczniejsze do stosowania, lecz również należy unikać zbyt długiego czasu utknięcia programu w takiej pętli.