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:
[syntax=c]/* scheduler.c */
void do_job()
{
//zaktualizuj kolejkę zadań na podstawie timera programowego
if(timer_tick)
aktualizuj_kolejkę_zadań;
//pobierz id następnego zadania do wykonania
if(priorytet_pierwszego_zdania != 0)
{
//nie ma nic do roboty, wykonaj coś: posprzątaj, uśpij procka albo jeszcze co tam chcesz
idle();
return;
}
//zdejmij zadanie z początku kolejki
callback = get_job();
//ponownie wstaw zadanie do kolejki w odpowiednie miejsce
insert_job(callback);
//i w końcu wykonanie zadania
(*callback)();
}
...
/* main.c */
int main()
{
/* jakieś inicjalizacje */
while(1)
{
do_job();
}
}[/syntax]
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:
iframe
Mając w miarę zręczne palce można wydusić jakieś efekty
iframe
Statystyki: Napisane przez xor — 22 sie 2015, o 23:13
]]>