Transcript ppt

UNIVERZITET U NIŠU
ELEKTRONSKI FAKULTET
Katedra za elektroniku
REAL-TIME OPERATIVNI SISTEMI
ZA MALE EMBEDDED SISTEME
- seminarski rad -
Mentor: prof. dr Mile K. Stojčev
Student: Dejan Barać, SAF 85/06
Uvod u embedded sisteme i
real-time operativne sisteme
Vremenska raspodela rada
procesora mikrokontrolera
Osnovne prednosti korišćenja RTOS-a



smanjena cena razvoja,
povećana pouzdanost sistema,
olakšana portabilnost.
Karakteristike RTOS za
embedded sisteme







Predvidljivost (predictability),
Pouzdanost,
Performanse,
Hardverska nezavisnost,
Skalabilnost,
Kompaktnost,
Konkurentnost.
Prva podela RTOS
Prva podela RTOS je prema strategiji po kojoj su
dizajnirani:


sistemi vođeni događajima (event-driven), gde se
prelazak između zadatak vrši samo kada je zadatak
višeg prioriteta prekida proces nižeg prioriteta,
sistemi s raspodelom vremena (time-driven), gde se
svaki zadatak izvršava neko vreme pre nego što se
procesor prepusti drugom zadatku.
Prva podela RTOS
Druga i treća podela RTOS
Prema vremenu odziva RTOS se dele na:


hard RTOS kod kojih se zadaci moraju da budu izvr-
šeni u unapred definisanom vremenu, tj. postoji fiksni
krajnji rok (hard deadline); prekoračenje krajnjeg roka dovodi do delimičnog ili potpunog otkaza sistema,
soft RTOS, kod kojih sistem u većini slučajeva odgovara u određenim vremenskim okvirima, ali se kašnjenja mogu tolerisati; zadacima u soft RTS, pridružen su „meki" krajnji rokovi (soft deadline).
Treća podela RTOS bi bila prema načinu raspoređivanja (planiranja) zadataka.
Arhitektura RTOS za embedded
sisteme
RTOS se projektuje tako da ima modularnu i slojevitu
strukturu (arhitekturu). Naravno, izgled programskog
kôda za embedded sisteme sa RTOS značajno se razlikuje. Ovo je iz razloga što su svi kvalitetni RTOS skalabilni, kako bi podržali različiti skup zahteva za različite primene.
RTOS može da sadrži kombinaciju više različitih modula: kernel (jezgro), fajl sistem (file system), podršku
za mrežne protokole (npr. podršku za TCP/IP protokol)
i druge komponente.
Arhitektura RTOS za embedded
sisteme
Ova arhitektura koristi linearni memorijski model, u
kojem se sve aplikacije i RTOS nalaze u istom adresnom prostoru, tako da nema aktivne zaštite deljenog
memorijskog prostora. Pokrenuta aplikacija pristupa
resursima sistema kroz API funkcije OS-a.
BSP (Board Support Package)
BSP predstavlja skup programa koji omogućavaju
spregu između OS-a i hardvera. BSP inicijalizacije
hardver i implementira specifične rutine za sistem,
koje mogu da koriste kernel i drajveri uređaja.
U osnovne komponente BSP-a se ubrajaju: podrška za
mikroprocesor (CPU) i specifične rutine za rad sa
sistemom (bootloader, inicijalizacija memorijske mape, sistemskih tajmera, kontrolera prekida, serijske
komunikacije, magistrala, DMA kontrolera, podešavanje sata realnog vremena – RTC).
Fajl sistem
Fajl sistem predstavlja skup apstraktnih tipova podataka koji je implementiran, kako bi obezbedio: prostor, hijerarhijsku organizaciju, pristup, obradu i preuzimanje podataka.
Prema organizaciji, fajl sistem se može klasifikovati
kao baza podataka specijalnog tipa. Većina poznatih
fajl sistema koristi neki od tipova uređaja za čuvanje
podataka koji omogućava pristup nizu blokova određene dužine, koji se nekad nazivaju i sektori.
Fajl sistem je odgovoran za organizaciju sektora u
fajlove i direktorijume (foldere).
Osnovne komponente kernela RTOS



Planer (Scheduler) koji je sadržan u svakom kernelu
i koji na osnovu skupa algoritama određuje koji se zadatak (task) u nekom trenutku izvršava.
Objekti – specijalne konstrukcije kernela koji pomažu
razvoju aplikacija za embedded sisteme koji rade u
realnom vremenu. Standardni objekti kernela uključuju podršku za zadatke (task-ove), semafore, redove
poruka (message queues).
Servisi – predstavljaju operacije koje kernel izvršava
nad objektima ili uobičajene operacije kao što su opsluživanje prekida i upravljanje resursima.
Osnovne komponente kernela RTOS
Osnovne komponente kernela RTOS
Planer
Planer (scheduler) predstavlja „srce” svakog kernela,
zato što obezbeđuje algoritme potrebne za određivanje koji će se zadatak izvšiti u datom trenutku.
Osnovni pojmovi neophodni za razumevanje principa
rada planera su: rasporedljivi entiteti (schedulable
entities), multitasking, hardverski i softverski prekidi,
promena (komutacija) konteksta (context switching),
dispečer (dispatcher) i algoritam raspoređivanja
(scheduling algorithm).
Zadatak u RTOS
Kada su u pitanju embedded sistemi u realnom vremenu i prateći RTOS, pojam niti (thread) se poistovećuje se sa pojmom zadatak (task) i definiše se
sledećim iskazom:
Zadatak predstavlja nezavisnu nit koja se sastoji od
sekvence nezavisno rasporedljivih instrukcija i izvršava
se na nekom sistemu.
Multitasking
Multitasking predstavlja privid konkurentnosti i ostvaruje se na nivou kernela alternativnim izvršavanjem
aktivnih zadataka.
Promena (komutacija) konteksta
Dispečer je modul planera (scheduler) koji obavlja
promenu (komutaciju) konteksta i promenu toka
(kontrole) izvšavanja. U svakom trenutku dok se
RTOS izvšava, tok izvršavanja (tok kontrole) prolazi
kroz jednu od tri moguće oblasti toka izvršavanja:



kroz zadatak aplikacije,
kroz prekidnu rutinu, ili
kroz kernel.
Algoritmi raspoređivanja zadataka
Većina današnjih kernela podržava dva uobičajena
algoritma raspoređivanja ili neku njihovu kombinaciju:


Kooperativno raspoređivanje (cooperative scheduling),
Prioritetno raspoređivanje sa „istiskivanjem“
(Preemptive priority-based scheduling).
Kooperativno raspoređivanje
Kooperativno raspoređivanje se drugačije naziva
raspoređivanje bez „istiskivanja“ (non-preemptive
scheduling).
Kod kooperativnih kernela svaki zadatak obavlja određenu aktivnost, kako bi stekao isključivo pravo upravljanja nad mikroprocesorom (CPU), pri čemu zadaci
međusobno „sarađuju” kako bi delili CPU. Asinhroni
događaji kod kooperativnih kernela se obrađuju od
strane ISR-ova (Interrupt Service Routine).
ISR može određenom zadatku da dodeli najviši prioritet i da ga postavi u stanje ready, ali nakon svog završetka ISR uvek ponovo vraća pravo upravljanja nad
CPU-om prekinutom zadatku.
Kooperativno raspoređivanje
Koncept prioritetnog raspoređivanja
sa istiskivanjem
Većina real-time kernela koristi prioritetno raspoređivanje sa istiskivanjem (preemptive priority-based
scheduling) kao predefinisani algoritam raspoređivanja. Preemptive kerneli se koriste tamo gde je odziv
sistema veoma važan.
Prioriteti mogu da budu: statički i dinamički.
Postoje dva pristupa:


zadaci se smeštaju u jednu listu prioriteta i uvek se
bira zadatak najvišeg prioriteta,
zadaci se grupiši u prioritetne klase, a za izbor zadatka unutar klase koristimo Round-Robin algoritam.
Koncept prioritetnog raspoređivanja
sa istiskivanjem
Koncept prioritetnog raspoređivanja
sa istiskivanjem
Ukoliko prioritete dinamički određuje RTOS, treba
uzeti u obzir sledeće:


zadaci koji intenzivno koriste I/O uređaje treba da
imaju viši prioritet, jer im CPU treba u kraćim intervalima (česće su blokirani),
zadaci koji intenzivno koriste CPU i operativnu memoriju treba da imaju niži prioritet.
Kod preemptive kernela vreme izvršenja zadatka čiji
je prioritet najviši je determinističko, što znači da je
vreme izvršenja (task-level response time) minimizirano.
Koncept Round-Robin raspoređivanja
Round-robin je preemptive i non-priority koncept raspoređivanja.
Svakom zadatku se dodeljuje podjednako procesorsko
vreme za njegovo izvšavanje (time slice ili quantum).
Novi zadaci, koji su spremni za izvršavanje, dodaju se
na kraj reda čekanja. Ako se izvršavanje zadatka blokira ili završi pre isteka time slice-a, zadatak oslobađa
procesor, a dispečer dodeljuje vreme novom zadatku.
Ukoliko se zadatak ne završi tokom time slice-a, isti će
bit prekinut od strane operativnog sistema (OS) i dispečer bira sledeći zadatak za izvršavanje.
Kombinacija Round-Robin i
prioritetnog raspoređivanja
Poređenje EDF i RM koncepta
raspoređivanja



Koncept raspoređivanja sa dinamičkim prioritetom
(EDF) je fleksibilnije i postiže bolje iskorišćenje od
koncepta raspoređivanja sa fiksnim prioritetom (RM).
RM algoritam zahteva češće raspoređivanje u odnosu
na EDF algoritam.
Vremensko ponašanje sistema kod kojeg se raspoređivanje izvršavanja zadataka vrši prema RM algoritmu
je predvidljivije.
Najčešći objekti kernela



Zadaci – koji predstavljaju nezavisne i konkurentne
niti izvšavanja, koje se “takmiče” za vreme CPU-a.
Semafori – to su signalni objekti kernela koji se mogu inkrementirati/dekrementirati od strane zadataka;
namenjeni su za njihovu međusobnu sinhronizaciju ili
međusobno isključivanje.
Poštansko sanduče (message mailbox) i red čekanja poruka (message queue) – odgovaraju strukturama podataka u formi bafera, koje se mogu koristiti
za sinhronizaciju, međusobno isključenje izvšavanja
i/ili razmenu podataka između zadataka.
Stanja zadatka
Semafori
Semafor (semaphor token) je objekat kernela koji može da bude dodeljen (acquire) ili oslobođen (release)
od strane jednog ili više zadataka.
Kod najvećeg broja multitasking kernela semafor ima
sledeće ciljeve:



kontroliše pristup deljivom resursu (mutual exclusion),
signalizira na pojavu događaja i
omogućava da 2 zadatka sinhronizuju svoje aktivnosti.
Semafori
Postoje dva tipa semafora: (1) binarni i (2) brojački.
Mutex semafori su specijalni binarni semafori.
Uobičajene procedure pri radu sa semaforima:




Kreiranje (create) ili brisanje (delete) semafora,
Dodeljivanje (acquire) ili oslobađanje (release) semafora,
Brisanje liste zadataka koji čekaju na dodelu (delete
task-waiting list),
Preuzimanje informacija o semaforu.
Semafori
Komunikacija između zadataka
Često se javlja potreba da zadatak ili ISR razmenjuje
informaciju sa drugim zadatkom. Ovakav tip prenosa
informacija se naziva intertask communication.
Razmena informacije između zadataka se obavlja ili
(1) preko globalno promenljivih podataka (global data), ili (2) putem slanja poruka (sending messages).
Kernel obično koristi tehnike koje su bazirane na: (1)
poštanskom sandučetu (message mailbox) ili (2) redu
čekanja poruka (message queue).
Red čekanja poruka
Kritične sekcije koda
Kritična sekcija kôda (critical section) je deo kôda kojeg treba tretirati kao celinu koja se ne može deliti.
Nakon što izvršenje kritične sekcije kôda počne njeno
izvršenje se ne može prekidati.
Obično se ovo ostvaruje na sledeći način: pre početka
izvršenja kritične sekcije zabrane se prekidi, a nakon
izvršenja njihov rad se ponovo dozvoljava.
Prekidi
Prekid predstavlja hardverski mehanizam koji se koristi da informiše CPU o tome da se javio asinhroni
događaj, koji zahteva pažnju i treba da se opsluži.
Kada se zahtev za prekid usvoji, CPU „pamti“ deo ili
ceo svoj kontekst (tj, stanje svojih registara) u magacin i prenosi pravo upravljanja procesora (skače) na
specijalni potprogram. Ovaj potprogram se naziva
prekidni program, tj, ISR (Interrupt Service Routine).
Prekidi omogućavaju mikroprocesoru da obrađuje
(procesira) događaje samo kada se oni jave.
Pipe objekat
Pipe predstavlja objekat kernela koji omogućava ne-
strukturiranu razmenu podataka i sinhronizaciju između zadataka.
Pipe objekat
Omogućeno je da postoji više zadataka koji vrše upis
više zadataka koji vrše čitanje iz pipe-a, što je ilustrovano na slici.
Zahtevi za memorijom
Kod embedded sistema sa RTOS, za instaliranje kernela potreban je dodatni kôdni (ROM/flash) prostor.
Veličina kernela zavisi od velikog broja faktora, a
obično je kapaciteta od 1 do 100 KB.
Minimalan kernel za 8-bitni CPU koji uključuje planer,
komutator konteksta, upravljanje semaforima, kašnjenja i timeout-e zahteva prostor od 1 do 3 KB.
Ukupan memorijski prostor kod ovog sistema je definisan sledećom relacijom:
obim_aplikacionog_koda + obim_koda_kernela
Procenat korišćenja pojedinih RTOS
od strane projektanata
Benčmark za RTOS
Većina benčmark (benchmark) pristupa za testiranje
operativnih sistema za rad u realnom vremenu zasnivaju se ili na (1) konkretnim aplikacijama, ili (2) na
korišćenim sistemskim uslugama.
Kako svaka aplikacija ima posebne zahteve, benčmark
pristup, nasuprot generičkoj aplikaciji, neće nprikazati
prednosti i slabosti RTOS. Zbog toga se najčešće koristi benčmark metod zasnovan na najčešće korišćenim sistemskim uslugama, koji uključuje Rhealstone
benčmark.
Benčmark za RTOS
Rhealstone benčmark meri sledeće:






vreme prebacivanje zadatka (task switch time),
vreme istiskivanja (preemption time) zadataka,
latenciju prekida (interrupt latency time),
vreme angažovanja (mešanja) semafora
(semaphore shuffling time),
vreme prekida „mrtve petlje” (deadlock breaking time),
trajanje ciklusa datagrama (datagram throughput time)
Benčmark za RTOS
Garcia-Martinez i ostali su predložili merenje nekoliko
pokazatelja zasnovanih na često korišćenim sistemskim servisima:



odgovor na spoljašnje događaje – prekide (interrupts),
sinhronizacija između zadataka (intertask synchronization) i deljenje resursa (resource sharing),
razmena podataka/poruka (message passing) između
zadataka.
Kriterijumi za poređenje RTOS
za male embedded sistema











jezička podrška,
kompatibilnost s odgovarajućim softverskim alatima,
mogućnost korišćenja API interfejsa,
eksploatacija (iskorišćenje) RAM i ROM/flash memorije,
sveukupni učinak,
postojanje odgovarajućih drajvera,
značaj operativnog sistema,
postojanje alata za debagovanje,
tehnička podrška,
mogućnost licenciranja i
reputacija prodavca/isporučioca.
Kriterijumi za poređenje RTOS
za male embedded sistema
Uporedne karakteristike više RTOS
za male embedded sistema
Poređenjem RTOS mogu da se uoče nekoliko značajnih sličnosti:



Većina RTOS-a koristi prioritetno raspoređivanje zadataka sa istiskivnjem. Samo dva RTOS-a (Salvo i
TinyOS) koriste kooperativno raspoređivanje.
Većina RTOS-a podržava programski jezik C.
Svega nekoliko RTOS-a u IDE okruženju poseduje podršku za spoznaju sistema: µC-OS/II i EmbOS imaju
plug-in module za IAR kompajler; KeilOS podržava
Keil kompajler; µITRON i µTKernel podržavaju HEW
kompajler.
Uporedne karakteristike više RTOS
za male embedded sistema


Pojedini RTOS-i (KeilOS, PortOS i XMK) ne prikazuju
detalje svojih API interfejsa. SharkOS je baziran na
µC-OS/II, tako da oni koriste iste API interfejse.
VCOS RTOS zahteva bootloader (Redboot) sa najmanje 64 KB ROM memorije. Redboot „butuje" i smešta
programe u RAM putem korisničkog terminala (najčešće preko serijskog porta). Otuda eCOS zahteva
znatno više ROM/flash i RAM memorijskog prostora.
Dostupni API interfejsi kod RTOS
za male embedded sistema
Testiranje performansi i
eksploatacije memorije
Za ovu evaluaciju korišćena je Renesas platforma sa
16-bitnim M16C/62P mikrokontrolerom:






Radna frekvencija 24 MHz,
512 KB ROM,
31 KB RAM (bez keš memorije ili MMU (MCU) jedinice za upravljanje memorijom),
Sedmoslojna maska prekida,
Renesas HEW kompajler (kompilator) sa verzijom
4.03.00.001 IDE okruženja,
NC30 – verzija 5.43.00
Mikrokontroler M16C/62P poseduje CPU sa CISC arhitekturom i ukupno dostupnom 91 instrukcijom. Većina instrukcija se izvršava za 2 ili 3 taktna intervala.
Implementacije sistemskih servisnih
poziva i kritičnih sekcija
Poređenje benčmarka za četiri RTOS
(eksploatacija memorije)
Vreme izvršenja benčmarka (u μs)
za četiri RTOS
Zaključak
Rezultati benčmark testova (iz literature) su pokazali
kako ne postoji apsolutni pobednik, tj. da svaki RTOS
ima svoje prednosti i nedostatke:




µTKernel ima najmanje vreme prebacivanja (komutacije)
zadatka (task-switching time), a zatim ga slede µITRON,
µC-OS/II i EmbOS.
µC-OS/II poseduje najbrža vremena za zauzimanje i
oslobađanje semafora.
što se tiče memorije, µC-OS/II poseduje najbolje vreme
izvršenja, a slede ga EmbOS, µITRON i µTKernel ,
µTKernel poseduje najbolje vreme učinka (performance
time), što se tiče aktiviranja zadatka iz manipulatora prekidima (interrupt handler), a zatim ga slede µC-OS/II,
µITRON i EmbOS.
Zaključak
U open-source kategoriji, µC-OS/II je veoma koristan
kao mali RTOS sa kompaktnom ROM/flash memorijom. Međutim, za širu podršku API interfejsima preporučuje se µTkernel, ali po cenu nešto veće eksploatacije (iskorišćenja) ROM/flash memorije.
Ukoliko korisnici imaju više poverenja u komercijalne
RTOS, preporučeno je da koriste µITRON ili EmbOS,
gde µITRON poseduje nešto nižu eksploataciju RAM
memorije.
Dakle, na osnovu rezultata benčmark testiranja i konkretnih zahteva aplikacije moguće je izabrati adekvatan RTOS za male embedded sisteme.
Podaci o autoru