W ramach rozruszania komórek mózgowych i utrwalenia wiedzy nabytej z ostatnio czytanej książki (http://helion.pl/ksiazki/wyklady-z-informatyki-z-przykladami-w-jezyku-c-alfred-v-aho-jeffrey-d-ullman,jezc.htm - gorąco polecam każdemu kto lubi różne algorytmiczne fiku-miku) postanowiłem napisać programik, coś jakby framework, do uruchamiania zadań w określonym przedziale czasowym oparty na timerze programowym. Sporą inspiracją był też ten wątek: http://forum.atnel.pl/topic3265.html, a konkretnie wynurzenia kolegi rolba.


Jak to działa? Wszystko co µC ma wykonać podzielone jest na niezależne zadania, niezależne od siebie i od pętli głównej (pętla główna nic "nie wie" o zadaniach, ile ich jest, czy w ogóle jakieś są). Ta część jest definiowalna przez użytkowanika frameworka. Zadania są umieszczone w kolejce według pewnego porządku (o tym później) i uruchamiane kolejno z pętli głównej - po upływie ustalonego dla danego zadania czasu od ostatniego uruchomienia. W międzyczasie (jeśli nie ma zadań do wykonania) wykonywane jest zadanie idle (czyli np. usypianie µC). Ta część jest zasadniczo niemodyfikowalna przez użytkownika.

Kod uruchamiający zadania jest bardzo prosty:



Cała "inteligencja" zaszyta jest w kolejce zadań. Do zadań przypisany jest atrybut nazwany priorytetem, który w rzeczywistości jest interwałem czasowym między wykonaniami zadania (liczonym w tyknięciach timera programowego). Im niższa liczba, tym krótszy czas - priortytet równy zero to wykonanie zadania przy każdym wywołaniu funkcji do_job (z powodu nadmiernej prostoty algorytmu obsługi kolejki takie zadanie może być najwyżej jedno). Zadania są uszeregowane w kolejce wg tego priorytetu, na początku kolejki jest zawsze zadanie o najwyższym priorytecie (czyli to którego wykonanie przypadnie w najbliższym czasie). Po każdym tyknięciu timera priorytety wszystkich zadań są pomniejszane o jeden (linie 5 i 6 listingu wyżej). W momencie gdy priorytet pierwszego zadania w kolejce osiągnie wartość zero (linia 9) zadanie zostanie zdjęte z kolejki (linia 17) i wykonane (linia 23). Przed wykonaniem zostanie ponownie wstawione do kolejki z pierwotnym priorytetem (linia 20). I tak w kółko.

Sama kolejka jest oparta na tzw. drzewie częściowo uporządkowanym. Proste wyjaśnienie cóż to jest można znaleźć w podanej wyżej książce :-> Ja powiem tylko, że ta struktura danych wpływa korzystnie na szybkość operacji wyszukiwania, wstawiania i kasowania elementów. Jej zalety widać zwłaszcza przy dużej ilości elementów bowiem średni czas operacji rośnie wraz z ilością w tempie logarytmicznym.

W załączniku program w formie archiwum Eclipse, jakby się kto chciał pobawić. Import do Eclipse: plik ściągnąć na dysk, potem File/Import... rozwinąć gałązkę General, wybrać Existing Projects into Workspace, baton Next> wybrać Select archive file:, baton Browse, znaleźć i wybrać mrugalka.zip, baton Finish.
Program wymaga avr-gcc w wersji co najmniej 4.7 (np. Atmel toolchain). Program jest na m168/m328.

Struktura projektu:
katalog SCHED - główna część. Definicje funkcji wstawiających i usuwających zadania z kolejki oraz wykonujących zadania.
katalog QU - implementacja kolejki priorytetowej. Pliki wykorzystywane przez funkcje z SCHED. Stała PQ_HEAPSIZE w pliku nagłówkowym definiuje wielkość kolejki.
Katalog TIMER - timer programowy. Stała ST_INTERVAL_MS w pliku nagłówkowym określa tick timera. Przeniesienie programu na inny µC może wymagać zmian nazw rejestrów w funkcji init_time oraz w procedurze obsługi przerwania ISR(TIMER0_COMPA_vect)
Katalog POWER - przykładowa implementacja zadania idle (funkcja sch_idle)- usypianie procka. Katalog można całkowicie usunąć, wtedy wykonywana jest defaultowa funkcja sch_idle (która nic nie robi ).
Katalog JOBS - definicje zadań oraz definicja struktury opisu zadań na potrzeby funkcji zarządzających zadaniami. Tutaj zdefiniowanych jest 10 zadań migających diodami na pinach PB1-PB5, PD2-PD5 oraz PD7, jedno zadanie wykorzystane przy testowaniu oraz jedno zadanie dekodujące komendy odbierane przez odbiornik IR.
katalog IR - driver czujnika IR w standardzie NEC wykorzystywany przez zadanie ir_handler. Dostosowanie do swojego pilota IR wymaga zmiany stałej IR_ID w pliku JOBS/ir_handlin.h (id pilota) oraz funkcji is_valid i get_id w pliku JOBS/ir_handlin.c (kody wykorzystanych klawiszy). Przeniesienie programu na inny µC może wymagać zmian nazw rejestrów w funkcji ir_init oraz ISR(TIMER1_CAPT_vect). Katalog ten oraz pliki ir_handlin.* w katalogu JOBS (oraz zadanie ir_handler z tablicy jobstable) można całkowicie wykasować, jeżeli nie korzysta się ze sterowania IR
katalog UART - wykorzystywane przez zadanie ir_handler.


Efekt działania:


Mając w miarę zręczne palce można wydusić jakieś efekty

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.