REAL-TIME OPERATIVNI SISTEMI ZA MALE EMBEDDED SISTEME - seminarski rad - Mentor: prof. dr Mile K. Stojčev Student: Dejan Barać, SAF 85/06 UNIVERZITET U.

Παρουσίαση με θέμα: "REAL-TIME OPERATIVNI SISTEMI ZA MALE EMBEDDED SISTEME - seminarski rad - Mentor: prof. dr Mile K. Stojčev Student: Dejan Barać, SAF 85/06 UNIVERZITET U."— Μεταγράφημα παρουσίασης:

1 REAL-TIME OPERATIVNI SISTEMI ZA MALE EMBEDDED SISTEME - seminarski rad - Mentor: prof. dr Mile K. Stojčev Student: Dejan Barać, SAF 85/06 UNIVERZITET U NIŠU ELEKTRONSKI FAKULTET Katedra za elektroniku

2 Uvod u embedded sisteme i real-time operativne sisteme

3 Vremenska raspodela rada procesora mikrokontrolera

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

5 Karakteristike RTOS za embedded sisteme Predvidljivost (predictability), Predvidljivost (predictability), Pouzdanost, Pouzdanost, Performanse, Performanse, Hardverska nezavisnost, Hardverska nezavisnost, Skalabilnost, Skalabilnost, Kompaktnost, Kompaktnost, Konkurentnost. 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 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. 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, 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). 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čitih modu - 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. 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). 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. 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

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 instrukcija i izvrš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 zadatak aplikacije, kroz prekidnu rutinu, ili kroz prekidnu rutinu, ili kroz kernel. 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 (cooperative scheduling), Kooperativno raspoređivanje (cooperative scheduling), Prioritetno raspoređivanje sa „istiskivanjem“ (Preemptive priority-based scheduling). 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 obavlja odre- đ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). ISR može određenom zadatku da dodeli najviši priori- tet i da ga postavi u stanje ready, ali nakon svog za- vršetka ISR uvek 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 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. 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 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 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. 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 tokom time 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). 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. 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. 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. 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. 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. 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 (mutual exclusion), kontroliše pristup deljivom resursu (mutual exclusion), signalizira na pojavu događaja i signalizira na pojavu događaja i omogućava da 2 zadatka sinhronizuju svoje aktivnosti. omogućava da 2 zadatka 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, Kreiranje (create) ili brisanje (delete) semafora, Dodeljivanje (acquire) ili oslobađanje (release) sema- fora, Dodeljivanje (acquire) ili oslobađanje (release) sema- fora, Brisanje liste zadataka koji čekaju na dodelu (delete task-waiting list), Brisanje liste zadataka koji čekaju na dodelu (delete task-waiting list), Preuzimanje informacija o semaforu. 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 na slici.

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 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 defi- nisan sledećom relacijom: obim_aplikacionog_koda + obim_koda_kernela

41 Procenat korišćenja pojedinih RTOS od 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 prebacivanje zadatka (task switch time), vreme istiskivanja (preemption time) zadataka, vreme istiskivanja (preemption time) zadataka, latenciju prekida (interrupt latency time), latenciju prekida (interrupt latency time), vreme angažovanja (mešanja) semafora vreme angažovanja (mešanja) semafora (semaphore shuffling time), vreme prekida „mrtve petlje” (deadlock breaking time), vreme prekida „mrtve petlje” (deadlock breaking time), trajanje ciklusa datagrama (datagram throughput time) trajanje ciklusa datagrama (datagram throughput time)

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), odgovor na spoljašnje događaje – prekide (interrupts), sinhronizacija između zadataka (intertask synchroni- zation) i deljenje resursa (resource sharing), sinhronizacija između zadataka (intertask synchroni- zation) i deljenje resursa (resource sharing), razmena podataka/poruka (message passing) između zadataka. razmena podataka/poruka (message passing) između zadataka.

45 Kriterijumi za poređenje RTOS za male embedded sistema jezička podrška, jezička podrška, kompatibilnost s odgovarajućim softverskim alatima, kompatibilnost s odgovarajućim softverskim alatima, mogućnost korišćenja API interfejsa, mogućnost korišćenja API interfejsa, eksploatacija (iskorišćenje) RAM i ROM/flash memorije, eksploatacija (iskorišćenje) RAM i ROM/flash memorije, sveukupni učinak, sveukupni učinak, postojanje odgovarajućih drajvera, postojanje odgovarajućih drajvera, značaj operativnog sistema, značaj operativnog sistema, postojanje alata za debagovanje, postojanje alata za debagovanje, tehnička podrška, tehnička podrška, mogućnost licenciranja i mogućnost licenciranja i reputacija prodavca/isporučioca. reputacija prodavca/isporučioca.

46 Kriterijumi za poređenje RTOS za male embedded sistema

47 Uporedne karakteristike više RTOS za 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 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. 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. 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 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. 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. 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 RTOS za 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, Radna frekvencija 24 MHz, 512 KB ROM, 512 KB ROM, 31 KB RAM (bez keš memorije ili MMU (MCU) - jedinice za upravljanje memorijom), 31 KB RAM (bez keš memorije ili MMU (MCU) - jedinice za upravljanje memorijom), Sedmoslojna maska prekida, Sedmoslojna maska prekida, Renesas HEW kompajler (kompilator) sa verzijom 4.03.00.001 IDE okruženja, Renesas HEW kompajler (kompilator) sa verzijom 4.03.00.001 IDE okruženja, NC30 – verzija 5.43.00 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.

51 Implementacije sistemskih servisnih poziva i kritičnih sekcija

52 Poređenje benčmarka za četiri RTOS (eksploatacija memorije)

53 Vreme izvršenja benčmarka (u μs) za četiri RTOS

54 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, µ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. µ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, š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 pre- kidima (interrupt handler), a zatim ga slede µC-OS/II, µITRON i EmbOS. µTKernel poseduje najbolje vreme učinka (performance time), što se tiče aktiviranja zadatka iz manipulatora pre- kidima (interrupt handler), a zatim ga slede µC-OS/II, µITRON i EmbOS.

55 Zaključak U open-source kategoriji, µC-OS/II je veoma koristan kao mali RTOS sa kompaktnom ROM/flash memori- jom. Međutim, za širu podršku API interfejsima pre- poručuje se µTkernel, ali po cenu nešto veće eksplo- atacije (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 kon- kretnih zahteva aplikacije moguće je izabrati adekva- tan RTOS za male embedded sisteme.

56 Podaci o autoru