REAL-TIME OPERATIVNI SISTEMI ZA MALE EMBEDDED SISTEME - seminarski rad -

1. UNIVERZITET U NIŠUELEKTRONSKI FAKULTETKatedra 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

2. Uvod u embedded sisteme ireal-time operativne sisteme

3. Vremenska raspodela rada procesora mikrokontrolera

4. Osnovne prednosti korišćenja RTOS-a • smanjena cena razvoja, • povećana pouzdanost sistema, • olakšana portabilnost.

5. Karakteristike RTOS zaembedded sisteme • Predvidljivost (predictability), • Pouzdanost, • Performanse, • Hardverska nezavisnost, • Skalabilnost, • Kompaktnost, • Konkurentnost.

6. 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.

7. Prva podela RTOS

8. 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 ro-ka dovodi do delimičnog ili potpunog otkaza sistema, • soft RTOS, kod kojih sistem u većini slučajeva odgo-vara 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điva-nja (planiranja) zadataka.

9. 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 raz-likuje.Ovo je iz razloga što su svi kvalitetni RTOS ska-labilni,kako bi podržali različiti skup zahteva za različi-te primene. RTOS može da sadrži kombinaciju više različitihmodu-la: kernel (jezgro), fajl sistem (file system), podršku za mrežne protokole(npr.podršku za TCP/IP protokol) i druge komponente.

10. Arhitektura RTOS za embedded sisteme Ova arhitektura koristi linearni memorijski model, u kojem se sve aplikacije i RTOS nalaze u istom adres-nom prostoru, tako da nema aktivne zaštite deljenog memorijskog prostora. Pokrenuta aplikacija pristupa resursima sistema kroz API funkcije OS-a.

11. 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 ma-pe, sistemskih tajmera, kontrolera prekida, serijske komunikacije, magistrala, DMA kontrolera, podeša-vanje sata realnog vremena – RTC).

12. Fajl sistem Fajl sistem predstavlja skup apstraktnih tipova poda-taka koji je implementiran, kako bi obezbedio: pros-tor, hijerarhijsku organizaciju, pristup, obradu i preu-zimanje 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).

13. Osnovne komponente kernela RTOS • Planer (Scheduler) koji je sadržan u svakom kernelu i koji na osnovu skupa algoritama određuje koji se za-datak (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ču-ju 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 op-služivanje prekida i upravljanje resursima.

14. Osnovne komponente kernela RTOS

15. Osnovne komponente kernela RTOS

16. Planer Planer (scheduler) predstavlja „srce” svakog kernela, zato što obezbeđuje algoritme potrebne za određiva-nje 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).

17. Zadatak u RTOS Kada su u pitanju embedded sistemi u realnom vre-menu i prateći RTOS, pojam niti (thread) se poisto-većuje se sa pojmom zadatak (task) i definiše se sledećim iskazom: Zadatak predstavlja nezavisnu nit koja se sastoji od sekvence nezavisno rasporedljivih instrukcijaiizvršava se na nekom sistemu.

18. Multitasking Multitasking predstavlja privid konkurentnosti i ostva-ruje se na nivou kernela alternativnim izvršavanjem aktivnih zadataka.

19. 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.

20. Algoritmi raspoređivanja zadataka Većina današnjih kernela podržava dva uobičajena algoritma raspoređivanja ili neku njihovu kombinaciju: • Kooperativno raspoređivanje(cooperativescheduling), • Prioritetno raspoređivanje sa „istiskivanjem“ (Preemptive priority-based scheduling).

21. Kooperativno raspoređivanje Kooperativno raspoređivanje se drugačije naziva raspoređivanje bez „istiskivanja“ (non-preemptive scheduling). Kod kooperativnih kernela svaki zadatak obavljaodre-đenu aktivnost, kako bi stekao isključivo pravo uprav-ljanja 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). ISRmože određenom zadatku da dodeli najviši priori-tet i da ga postavi u stanje ready, ali nakon svog za-vršetka ISRuvek ponovo vraća pravo upravljanja nad CPU-om prekinutom zadatku.

22. Kooperativno raspoređivanje

23. Koncept prioritetnog raspoređivanja sa istiskivanjem Većina real-time kernela koristi prioritetno raspoređi-vanje sa istiskivanjem (preemptive priority-based scheduling) kao predefinisani algoritam raspoređiva-nja. 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 zadat-ka unutar klase koristimo Round-Robin algoritam.

24. Koncept prioritetnog raspoređivanja sa istiskivanjem

25. 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 inter-valima (česće su blokirani), • zadaci koji intenzivno koriste CPU i operativnu me-moriju 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) minimizi-rano.

26. Koncept Round-Robin raspoređivanja Round-robin je preemptive i non-priority koncept ras-poređ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 blo-kira 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 tokomtime slice-a,isti će bit prekinut od strane operativnog sistema (OS) i dis-pečer bira sledeći zadatak za izvršavanje.

27. Kombinacija Round-Robin i prioritetnog raspoređivanja

28. 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.

29. 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 mo-gu 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 čeka-nja poruka (message queue) – odgovaraju struktu-rama podataka u formi bafera, koje se mogu koristiti za sinhronizaciju, međusobno isključenje izvšavanja i/ili razmenu podataka između zadataka.

30. Stanja zadatka

31. 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 (mutualexclusion), • signalizira na pojavu događaja i • omogućava da2zadatka sinhronizuju svoje aktivnosti.

32. 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) sema-fora, • Brisanje liste zadataka koji čekaju na dodelu (delete task-waiting list), • Preuzimanje informacija o semaforu.

33. Semafori

34. 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 da-ta), 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).

35. Red čekanja poruka

36. Kritične sekcije koda Kritična sekcija kôda (critical section) je deo kôda ko-jeg 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.

37. Prekidi Prekid predstavlja hardverski mehanizam koji se ko-risti 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 maga-cin 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.

38. Pipe objekat Pipe predstavlja objekat kernela koji omogućava ne-strukturiranu razmenu podataka i sinhronizaciju izme-đu zadataka.

39. 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 ilustro-vano naslici.

40. Zahtevi za memorijom Kod embedded sistema sa RTOS, za instaliranje ker-nela 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 za8-bitniCPU 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 defi-nisan sledećom relacijom: obim_aplikacionog_koda + obim_koda_kernela

41. Procenat korišćenja pojedinih RTOSod strane projektanata

42. Benčmark za RTOS Većina benčmark (benchmark) pristupa za testiranje operativnih sistema za rad u realnom vremenu zasni-vaju 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 ko-risti benčmark metod zasnovan na najčešće korišće-nim sistemskim uslugama, koji uključuje Rhealstone benčmark.

43. 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), • vremeprekida„mrtve petlje”(deadlock breaking time), • trajanjeciklusadatagrama (datagramthroughputtime)

44. Benčmark za RTOS Garcia-Martinez i ostali su predložili merenje nekoliko pokazatelja zasnovanih na često korišćenim sistem-skim servisima: • odgovor na spoljašnje događaje–prekide (interrupts), • sinhronizacija između zadataka (intertask synchroni-zation) i deljenje resursa (resource sharing), • razmena podataka/poruka (message passing) između zadataka.

45. Kriterijumi za poređenje RTOSza 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.

46. Kriterijumi za poređenje RTOSza male embedded sistema

47. Uporedne karakteristike više RTOSza male embedded sistema Poređenjem RTOS mogu da se uoče nekoliko značaj-nih sličnosti: • Većina RTOS-a koristi prioritetno raspoređivanje za-dataka 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 po-drš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.

48. Uporedne karakteristike više RTOSza 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 najma-nje 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.

49. Dostupni API interfejsi kod RTOSza male embedded sistema

50. 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 ar-hitekturom i ukupno dostupnom 91 instrukcijom. Ve-ćina instrukcija se izvršava za 2 ili 3 taktna intervala.