REAL-TIME OPERATIVNI SISTEMI ZA MALE EMBEDDED SISTEME

UNIVERZITET U NIŠU ELEKTRONSKI FAKULTET Katedra za elektroniku Smer: Elektronika i mikroračunarska tehnika Predmet: Projektovanje embedded sistema (do...
Author: Douglas Goodwin
39 downloads 1 Views 1MB Size
UNIVERZITET U NIŠU ELEKTRONSKI FAKULTET Katedra za elektroniku Smer: Elektronika i mikroračunarska tehnika Predmet: Projektovanje embedded sistema (doktorske studije)

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

Mentor: prof. dr Mile K. Stojčev Student: Dejan Barać, SAF 85/06 (MRT)

Niš, jun 2010.

Sadržaj

Uvodna reč.............................................................................................................................................................................................3 Uvod u embedded sisteme i real-time operativne sisteme .......................................................................4 Karakteristike RTOS......................................................................................................................................................................7 Podela RTOS........................................................................................................................................................................................9 Arhitektura RTOS za embedded sisteme.................................................................................................................. 10 Primeri RTOS...................................................................................................................................................................................... 33 Benčmark za RTOS....................................................................................................................................................................... 36 Zaključak.................................................................................................................................................................................................51 Reference............................................................................................................................................................................................... 52 O autoru.................................................................................................................................................................................................. 53

2

Uvodna reč Uloga ovog seminarskog rada je pružanje osnovnih pojmova o operativnim sistemima za rad u realnom vremenu (Real-Time Operating Systems, RTOS), njihovim tipovima i primenama kod malih embedded sistema. Prvi deo rada čine odeljci 1-5, koji prezentuju karakteristike, arhitektuturu, podelu i primere RTOS. Nije korišćena velika sloboda u prevođenju pojmova i davanja definicija koji se tiču RTOS, već su iskorišćeni pojmovi i definicije date u literaturi [1-3] U drugom delu rada (odeljak 6) su prezentovani kriterijumi (iz literature) za poređenje RTOS, rezultati testiranja performansi, benčmark kriterijumi za RTOS itd. Naglasak je stavljen na RTOS koji se koriste kod malih embedded sistema. Na kraju rada se nalazi spisak referenci, koje su ovom prilikom korišćene.

3

1. Uvod u embedded sisteme i real-time operativne sisteme (RTOS) Embedded (ugrađeni) sistemi imaju danas široku primenu: od mobilnih telefona, digitalnih fotoaparata, fiskalnih registar-kasa, računarske opreme, medicinskih uređaja – pa sve do upravljačkih sistema u automobilima, avionima i satelitima. Ovi sistemi su u protekle tri decenije, od jednostavnih kontrolera sa specifičnim softverom za određen upravljački zadatak prerasli u složene sisteme na kojima se izvršava mnoštvo aplikacija – od kritičnih upravljačkih aplikacija do grafičkog korisničkog interfejsa. Porast broja aplikacija koje se istovremeno izvršavaju neizbežno je postavio zahtev za operativnim sistemom u okviru embedded sistema, koji bi to omogućio – a da pri tome ne naruši stabilnost i odziv sistema za sve vremenski kritične zadatke. Za embedded sisteme sa relativno jednostavnim hardverom i/ili sa malim brojem jednostavnih funkcija najčešće nije potreban operativni sistem. S druge strane, sistemi na kojima se izvršavaju relativno složene aplikacije zahtevaju neku formu planera (sheduler) i samim tim zahtevaju operativni sistem. Sistemi za rad u realnom vremenu (Real Time System, RTS) predstavljaju mikroračunarski sistem koji upravlja i nadgleda fizičke procese. Ključni deo specifikacije RTS se odnosi na vreme odziva, koje je određeno prirodom fizičkog procesa. Korektnost rada RTS zavisi ne samo od logičke ispravnosti rezultata izračunavanja, već i od vremena za koje se ti rezultati generišu. Drugim rečima, da bi korektno obavio svoj zadatak (task), RTS mora svoju funkciju da izvrši u unapred zadatom vremenu. Ukoliko se zadato vreme odziva prekorači, može da dođe do otkaza sistema što može imati katastrofalne posledice. Isto tako, od RTS se zahteva visokopouzdani rad i predvidljivo ponašanje u svim okolnostima. U slučajevima kada se RTS ugrađuje u uređaje široke potrošnje, iz razloga ekonomičnosti, zahteva se minimalno korišćenje hardverskih resursa (8 ili 16 bitni CPU, mala količina memorije). Zbog svega navedenog, projektovanje RTS sistema predstavlja kompleksan zadatak. Dakle, svi embedded sistemi nisu ujedno i sistemi za rad u realnom vremenu (RTS), niti obrnuto. Međutim, veoma često RTS obično čine deo nekog većeg sistema ili uređaja i iz tog razloga se nazivaju ugrađeni (embedded) mikroračunarski sistemi za rad u realnom vremenu lil, kraće, embedded sistemi za rad u realnom vremenu (Real Time Embedded System). Operativni sistemi u realnom vremenu, ili real-time operativni sistemi, danas predstavljaju jedan od glavnih delova složenih embedded sistema, obezbeđujući softversku platformu na kojoj se izvšavaju različite aplikacije. Kod prvih mikroračunarskih sistema, razvojni softverski inženjeri su kreirali softverske aplikacije koje su koristile mašinski kôd za inicijalizaciju sistema i rad sa hardverom sistema. Ovakva uska veza između softvera i hardvera je rezultirala stvaranjem aplikacijama koje nisu portabilne (portabilnost – prenos softverske aplikacije na drugu hardversku platformu). Male promene u hardveru sistema su zahtevale značajna menjanja kôda aplikacije, pa su samim tim takvi sistemi bili komplikovani i skupi za održavanje. Sa razvojem softverske industrije, nastali su operativni sistemi koje su obezbeđivali osnovu za razvoj softvera i određeni nivo apstrakcije hardvera sistema sa stanovišta razvoja aplikativnog kôda. Kasnije sa razvojem operativnih sistema, omogućeno je da se umesto razvoja glomaznih, monolitnih aplikacija razvijaju modularne, međusobno povezane aplikacije koje su radile u okruženju operativnog sistema. Tokom godina razvijene su mnoge verzije operativnih sistema, od operativnih sistema opšte namene (GPOS - General purpose operating systems), kao što su UNIX i Microsoft Windows, do manjih kompaktnijih RTOS kao što je VxWorks. Tokom 60-tih i 70-tih godina prošlog veka, razvijen je UNIX OS sa namerom da podrži pristup i rad više korisnika na skupim i tada nedostupnim računarskim sistemima. Ovi korisnici su mogli da izvršavaju različite aplikacije koje su delile hardverske resurse istog računarskog sistema. Dok su jedni 4

korisnici mogli da vrše unos i obradu podataka, drugi korisnici su mogli da vrše štampanje teksta i slično. Tokom 80-tih godina prošlog veka, Microsoft je predstavio Windows OS – koji je bio namenjen kućnim i poslovnim korisnicima rad sa personalnim računarima preko grafičkog korisničkog interfejsa (Graphical User Interface). Kasnije, sa začetkom ubrzanog razvoja sistema, razvijeni su mnogi RTOS koji su bili prilagođeniji razvoju aplikacija za embedded sisteme u realnom vremenu. RTOS ima osiromašeniji korisnički interfejs u odnosu na GPOS, a osnovna prednost sastojala se u boljoj pouzdanosti izvršavanja aplikacija u kontekstu namenskih sistema, boljim performansama, smanjenim zahtevima za memorijskim resursima, pažljivo prilagođenoj tehnici planiranja redosleda izvšavanja zadataka (task-ova) koja je obezbeđivala podršku za rad u realnom vremenu, podršku namenskim sistemima koji se inicijalizuju i izvršavaju programski kôd iz EPROM ili RAM memorije i lakše portovanje razvijenih aplikacija na različitim hardverskim platformama. Razvojni softverski inženjeri sistema na bazi mikrokontrolera najčešće instinktivno koriste programske mehanizme da bi uspešno uskladili rad na više poslova u sistemu, bilo da su ti poslovi samostalni ili međusobno utiču jedni na druge. Na samom početku razvoja operativnih sistema za mikrokontrolere ovakvi intuitivni mehanizmi su pružali zadovoljavajuće rezultate. Razvoj industrije je nametnuo zahtev za standardizacijom i formalizacijom rada operativnih sistema (za mikrokontrolere). Raznovrsnost i složenost zadataka zahtevaju složeniji i bolje osmišljen softver. Od procesora se očekuje da brzo reaguje kako na spoljašnje, tako i na unutrašnje događaje. Obično je reakcija na događaj vremenski ograničena, odnosno postoji kritično vreme u kojem mora da se izvrši zadatak (task). Prilikom projektovanja real-time operativnih sistema (RTOS) sa jednim procesorom (CPU) treba imati na umu osnovnu činjenicu – u jednom trenutku može da se izvršava samo jedna procesorska naredba, a da broj različitih zadataka može da varira. To zapravo znači da zadaci moraju da dele procesorsko vreme. U takvim uslovima od najvećeg je značaja da se određeni vremenski intervali u kojima je procesor dodeljen određenom poslu raspodele tako da ceo sistem skladno funkcioniše.

Slika 1. Prikaz jednostavnog sistema na bazi mikrokontrolera sa RTOS 5

Na Slici 1 je prikazana blok šema sistema kojeg čine mikrokontroler (sa „upisanim” RTOS), dva motora, dva displeja i tastatura (keypad). Naravno, postoji komunikacija između mikrokontrolera i računara. sa programirnim RTOS. Na Slikama 2a i 2b ilustrovano je deljenje procesorskog vremena za podržavanje rada tastature, displeja1 i displeja2 (označeni kao 1 i 2), obradi rezultata merenja brzine obrtanja motora i komunikacije sa računarom. U prvom slučaju (Slika 2a) je prikazano deljenje procesorskog vremena kada nema komunikacije sa tastaturom ni sa računarom. Zadatak se sastoji u tome da se svakih 5 ms meri brzina dva motora (brojači 1 i 2), da se ulazne digitalne reči preračunaju u vrednosti brzine (broj obrtaja u minuti – Rotation Per Minute, RPM) koje se zatim ispisuju na displejima 1 i 2. Nema nepredviđenih događaja, a jedino je kritično da se unutar 5 ms obave navedeni zadaci. Prosečan mikrokontroler može obaviti navedene zadatke u zadatom vremenu.

Slika 2a. Vremenska raspodela rada procesora mikrokontrolera sa Slike 1

Slika 2b. Raspodela rada procesora kada postoji komunikacija sa računarom i tastaturom Međutim, situacija postaje složenija kada postoji veza sa tastaturom i mogućnost komunikacije sa računarom (Slika 2b). Na pritisak tastera na tastaturi, kôd tastera treba da se zapamti – a to zahteva da procesor obradi taj događaj. Ako od strane računara stiže poruka prema mikrokontroleru (ili mikrokontroler šalje poruku računaru), tada i ovom događaju mora da se posveti procesorsko vreme. Ova dva događaja su asinhroni, tj. mogu da se pojavljuju 6

nepredviđeno, i ne smeju da se ignorišu. Na izvestan način oni „kradu” procesorsko vreme i time „smetaju” ostalim poslovima tako da se dolazi u situaciju kada se postavlja pitanje da li se ceo posao može odraditi korektno. Posebna tema su principi na kojima se bazira programiranje u RTOS, da bi izvršenje celokupnog posla bilo što efikasnije. Neka to za sada ostane otvoreno pitanje za dalju diskusiju. Asembleri i kompajleri (kompilatori) za programske jezike C ili C++ se mogu da se nadograde skupovima funkcija koje podržavaju rad u realnom vremenu. Ove dodatne softverske biblioteke se mogu nabaviti nezavisno od asemblera i kompajlera i koštaju neretko i više nego sami jezici. Za upotrebu funkcija iz takve biblioteke nije neophodno razumevanje samog jezgra (kernela) RTOS. Njima treba pristupiti kao crnim kutijama za koje se zna šta se dobija na izlazu za poznati ulaz. Kada se savlada korišćenje funkcija koje su deo RTOS-a, tada postoje adekvatni uslovi da se raspoloživi mikrokontrolerski sistem maksimalno iskoristi.

2. Karakteristike RTOS RTOS treba da u što većoj meri „prikrije” hardversku složenost sistema od programera (detaljno poznavanje prekida, A/D konvertora, tajmera...), tj. da za pristup hardveru obezbedi standardizovane softverske procedure. Takođe, RTOS treba da obezbedi podršku za (biće definisan kasnije), komunikaciju i sinhronizaciju zadataka (task-ova), multitasking, kontrolu pristupa deljivim resursima… Na taj način, RTOS stvara privid „virtuelne” mašine, nezavisne od konkretne hardverske platoforme, što mogućava projektantu da se usredsredi na rešavanje konkretnog problema na višem nivou (identifikacija zadataka, komunikacija/sinhronizacija zadataka, obezbeđivanje zahtevanih performansi…) i da se u što većoj meri oslobodi implementacionih detalja niskog nivoa. Osnovne prednosti korišćenja RTOS-a su: 1. smanjena cena razvoja (skraćuje se vreme realizacije korisničke aplikacije), 2. povećana pouzdanost sistema, jer se smanjuje verovatnoća programerske greške prilikom programiranja mehanizama niskog nivoa, 3. olakšana portabilnost. Karakteristike RTOS su definisane zahtevima aplikacije, a kao osnovne ćemo izdvojiti sledećih sedam: 1. Predvidljivost (predictability) Obzirom da su mnogi embedded sistemi ujedno i sistemi u realnom vremenu, ispunjenje vremenskih zahteva je osnov za obezbeđivanje normalnog rada sistema. RTOS koji se u ovom slučaju koristi mora biti predvidljiv u određenom stepenu, čak i kada se broj zadataka uvećava. Pojam deterministički opisuje RTOS sa predvidljivim ponašanjem (deterministic behaviors), pri čemu se izvršavanje poziva operativnog sistema obavlja u poznatim vremenskim okvirima. Kao mera predvidljivosti (predictability) sistema može se uzeti vreme odziva sistema na svaki tip sistemskih poziva. Promena ovih vrednosti za različite tipove sistemskih poziva kod determinističkog sistema treba da bude veoma mala. Sve što je gorenavedeno čini suštinsku razliku između RTOS i operativnih sistema opšte namene (generic OS) – kod kojih sinhronizacija zadataka nije predvidljiva i kod kojih ne postoji sigurnost da će se pri uvećavanju broja zadataka, isti izvršiti u zadatim vremenskim okvirima. 7

2. Pouzdanost Embedded real-time sistem mora da bude pouzdan. Zavisno od primene, od sistema se u nekim slučajevima zahteva da radi u dužim vremenskim intervalima bez intervencije. Tokom rada, mogu da budu zahtevani različiti stepeni pouzdanosti sistema. Na primer, solarni kalkulator može da se resetuje u slučaju kada nema dovoljno osvetljenja za njegov rad. S druge strane, telefonska centrala ne sme da se resetuje tokom rada. U opštem slučaju, zadovoljavajući stepen stabilnosti podrazumeva da je sistem pouzdan kada nastavlja da obavlja predviđene funkcije, pruža servise i slično, tj. ako nije otkazao. Treba napomenuti da mera pouzdanosti sistema nije prevashodno vezana za pouzdanost RTOS, već i za pouzdanost hardvera, BSP (Board Support Package) i uslove primene sistema. 3. Performanse Zahtevi diktiraju neophodne performanse embedded sistema koji je potrebno da ispuni definisane funkcionalne i vremenske zahteve. U opštem slučaju, što su stroža vremenska ograničenja i što je veći broj taskova, rastu potrebe za procesorskom brzinom. Iako hardver sistema diktira mogućnosti procesiranja zahteva nekog sistema, softver sistema takođe doprinosi performansama sistema. Jedna od performansi sistema je throughput, koji se definiše kao brzina sa kojom sistem generiše svoje izlaze u zavisnosti od pristiglih ulaza. Throughput takođe označava količinu podataka (u Bps, KBps, MBps) koji se prenose u jedinici vremena. 4. Hardverska nezavisnost Jedna od osnovnih prednosti korišćenja RTOS je dostupnost tzv. drajvera uređaja (device drivers). To su softverske rutine koje obezbedjuju pristup i korišćenje različitih tipova istih hardverskih uređaja na standardizovan način. Drajveri uređaja (štampač, displej, tastatura, miš, tajmer, komunikacioni kontroleri, mrežni kontroleri, magistrale) „sakrivaju” detalje vezane za specifičnosti konkretnog tipa hardverskog uređaja, pružajući tako utisak programeru da radi sa standardnim uređajem. Samim tim, aplikativni deo softvera je nezavisan od konkretnog uređaja. Ukoliko je potrebno zameniti aktuelni displej sa novim, koji ima veću rezoluciju – dovoljno je instalirati odgovarajući drajver displeja. Konkretno, drajver dispeja obezbeđuje rutine kao što su: ispisivanje karaktera na zadatu poziciju, upravljanje kursorom, ispisivanje/brisanje linije displeja, brisanje celog displeja. 5. Skalabilnost Kako se RTOS koriste u različitim aplikacijama, oni moraju da poseduju mogućnost prilagođavanja specifičnim zahtevima aplikacija. Komponenete specifične za hardver i aplikacije moraju da se uklope u celinu, bez velikih memorijskih i procesorskih zahteva. U zavisnosti od zahtevane funkcionalnosti, RTOS mora da poseduje mogućnost dodavanja ili uklanjanja pojedinih modula sistema. Na ovaj način se štedi vreme projektanta, jer – daleko je brže i efikasnije prilagoditi postojeći kôd (dodavanjem/oduzimanjem modula), nego razvijati novi (kôd). 6. Kompaktnost Ograničenja prilikom projektovanja aplikacija i ograničenja troškova „pomažu" prilikom određivanja kompaktnosti embedded sistema. Na primer, mobilni telefon mora da bude prenosiv, male veličine i prihvatljive cene. Ova ograničenja limitiraju veličinu sistemske memorije, koja uzrokuje ograničenja u veličini aplikacija i operativnog sistema, pri čemu se mora voditi računa o statičkoj i dinamičkoj potrošnji memorijskih resursa sistema. 8

7. Konkurentnost Konkurentnost predstavlja mogućnost istovremenog izvršenja više zadataka. “Prava” konkurentnost može se ostvariti samo kod multiprocesorskih sistema, kod kojih se svaki zadatak izvršava na posebnom procesoru. Međutim, ovakvo rešenje je izrazito neekonomično, s obzriom da po pravilu važi da je u toku rada sistema većina zadatak najveći deo vremena neaktivna, a da se aktiviraju samo po potrebi (npr. unos podataka preko tastature). Iz navedenih razloga, većina savremenih RTS su jednoprocesorski sistemi, a konkurentnost (tačnije: privid konkurentnosti) se postiže alternativnim izvršavanjem aktivnih zadataka (tzv. kvazi-konkurentnost ili multitasking).

3. 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, i sistemi s raspodelom vremena (time-driven), gde se svaki zadatak izvršava neko vreme pre nego što se procesor prepusti drugom zadatak.

Slika 3. Ilustracija izvršenja zadataka kada su vođeni događajima i vemenom 9

Danas se, osim za slučaj najjednostavnijih sistema, koriste sistemi s raspodelom vremena, jer su skalabilni, a njihove performanse nisu značajno slabije nego li performanse sistema vođenih događajima. Operativni sistemi za rad u realnom vremenu (RTOS) se prema vremenu odziva 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; rezultati koji su izračunati posle krajnjeg roka smatraju se pogrešnim ili neupotrebljivim; 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), ali prekoračenje krajnjeg roka ne dovodi do otkaza sistema, već samo do degradacije nekih njegovih performansi sistema; dakle, prekoračenje krajnjeg roka nije poželjno, ali se može, do izvesne mere, tolerisati.

Treća podela RTOS je prema načinu raspoređivanja (planiranja) zadataka, o čemu će biti reči u narednom odeljku.

4. 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 (scalable), kako bi podržali različiti skup zahteva za različite primene. Na primer, u nekim aplikacijama RTOS sadrži samo glavni upravljački softver kernel, planiranje redosleda korišćenja resursa sistema i algoritme za upravljanje resursima. S druge strane, 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, što je ilustrovano na Slici 2. Kod arhitekture embedded sistema u realnom vremenu, koristi se linearni memorijski model, u kome su 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 operativnog sistema. (API – Application programming interface)

Slika 4. Uopštena arhitektura RTOS za embedded sisteme 10

U funkcije kernela spadaju planiranje izvršenja zadataka, upravljanje memorijom, zaštita deljivih resursa, obrada prekida, komunikacija i sinhronizacija zadataka. Kod standardne arhitekture operativnog sistema sa monolitnim kernelom postoji odvojen adresni prostor u kome se nalazi operativni sistem i odvojeno korisničke aplikacije. Kada je aplikacija startovana, ona ne može pristupiti direktno hardveru sistema, već pristup hardveru sistema ostvaruje preko sistemskih poziva objekata i servisa kernela. 4.1. BSP (Board Support Package) BSP (Board Support Package) predstavlja skup programa koji omogućavaju spregu između operativnog sistema i hrdvera. 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 – Real-Time Clock).

4.2. Fajl sistem (File system) 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 file system-a 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), vodeći računa o tome koji sektor pripada kojem fajlu i koji sektori nisu iskorišćeni. Većina sistema adresira podatke u fiksnim veličinama koji se nazivaju klasteri ili blokovi i koji sadrže određeni broj sektora. Ova veličina praktično predstavlja najmanju moguću količinu prostora koja se može rezervisati za čuvanje podataka u formi fajla. 4.3. Osnovne komponente kernela RTOS Već je napomenuto kako kernel čini osnovni deo, odnosno jezgro operativnog sistema. Njegove fundamentalne komponente (videti Sliku 5) su sledeće: • • •

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.

Predstava kernela RTOS prikazana na Slici 5 je uobičajena i pojednostavljena, što ne podrazumeva da se može primenti na svaki pojedinačni kernel. Sa stanovišta arhitekture samog RTOS, ilustrativna je Slika 6, koja pruža jasniju vezu između razvoja korisničkih aplikacija i hardvera embedded sistema. 11

Slika 5. Uobičajene i pojednostavljene komponente kernela RTOS

Slika 6. Pozicija OS i njegovih komponenti u odnosu na hardver i aplikativni softver 4.3.1. Planer

Planer (scheduler) predstavlja „srce” svakog kernela, zato što obezbeđuje algoritme potrebne za određivanje koji će se zadatak (task) 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). 12

4.3.2. Nit (thread) i zadatak (task)

Kod većine kernela računara opšte namene, niti (thread-ovi) su primeri rasporedljivih entiteta. Pod pojmom nit (thread) podrazumeva se jednostavni (lightweight) tok kontrole, koji deli resurse sistema sa ostalim nitima (thread-ovima) i procesima (heavyweight tokovi kontrole). Svaka nit (thread) je stacionirana u okviru nekog procesa i koristi resurse tog procesa. Kada su u pitanju embedded sistemi u realnom vremenu i prateći RTOS, pojam niti se poistovećuje se sa pojmom zadatak (task) i definiše se sledećim iskazom: Zadatak (task) predstavlja nezavisnu nit (thread) koja se sastoji od sekvence nezavisno rasporedljivih instrukcija i izvšava se na nekom sistemu. Uprkos semantičkim razlikama, pod pojmom zadatak podrazumevaće se bilo task, bilo proces. (Dodatne informacije o zadacima date su u delu odeljka 4.7) 4.3.3

Multitasking

Kernel RTOS-a može da ima višestruke zadatke (task-ove), čije je izvšavanje na procesoru raspoređuje. Pojam multitaskinga će se razmatrati u kontekstu jednoprocesorskog sistema, radi jednostavnosti pristupa i zbog toga što su većina savremenih embedded RTS sistema jednoprocesorski. Multitasking predstavlja privid konkurentnosti i ostvaruje se na nivou kernela alternativnim izvršavanjem aktivnih zadataka.

Slika 7. Multitasking uz pomoć promene (komutacije) konteksta RTOS autonomno planira redosled izvršenje zadatak i obezbeđuje mehanizme za kreiranje, startovanje i suspenziju zadataka. Sve ove aktivnosti, neophodne za obezbeđivanje multitaskinga, troše dodatno CPU vreme. Takođe, činjenica da više nezavisnih zadataka dele 13

iste hardverske resurse dovodi do pojave problema koji ne postoje kod „prave” konkurentnosti, kao što su otežano ostvarivanje zahteva koji se odnose na brzinu odziva, razrešavanja konflikta oko korišćenja deljivih resursa, upravljanje dodelom memorije pojedinačnim zadacima i sl. Na Slici 7 ilustrovan je primer multitaskinga, koji je ostvaren upotrebom promene konteksta (contex switch). Kernel izvšava zadatke task 1 i task 2, tako da izgleda da se više thread-ova izvšava „konkurentno“ (paralelno), međutim kernel operativnog sistema omogućava njihovo sekvencijalno izvršavanje na osnovu postojećeg algoritma raspoređivanja. Bitno je napomenuti da se izvšavanje zadataka obavlja prema algoritmu raspoređivanja kernela, dok se sa druge strane, prekidne rutine (Interrupt Service Routine - ISR) pokreću na osnovu hardverskog prekida i njihovih postavljenih prioriteta. Sa povećanjem broja zadataka čije je izvšavanje na sistemu potrebno rasporediti, povećavaju se zahtevi za performansama procesora. 4.3.4. Hardverski i softverski prekid

U bilo kojem embedded sistemu, postoje dva tipa prekida: • •

hardverski prekid – u pitanju je signal koji je generisan od strane periferijskog uređaja i koji je signaliziran CPU. Kao posledica, CPU izvršava prekidnu rutinu koja obavlja odgovarajuće akcije kao odgovor na prekid. softverski prekid – jedan softverski modul prebacuje kontrolu drugom.

Nezavisno od tipa prekida, kontekst ili relevantni podaci sistema vezani za izvšavanje prekinutog zadatka moraju da se sačuvaju – kako bi izvšavanje pomenutog zadatka moglo da bude nastavljeno nakon povratka iz prekidne rutine. Osnovna razlika između hardverskog i softverskog prekida je mehanizam iniciranja. Hardverski prekid inicira električni signal generisan od strane spoljašnjeg uređaja, dok je sa druge strane inicijator softverskog prekida izvršavanje određene mašinske instrukcije. 4.3.5. Promena (komutacija) konteksta (context swiching)

Uvek kada se izvršava novi zadatak (task), kernel takođe kreira pridruženi kontrolni blok zadatka (Task Control Block - TCB), koji sadrži strukture podataka sistema koje kernel koristi za održavanje potrebnih informacija vezanih za konkretni zadatak. Model sistema sa TCB-om je najpopularniji model, koji je implementiran u mnogo više korisničkih RTOS kod kojih broj zadataka može da varira. TCB praktično sadrži sve neophodne informacije o konkretnom zadatku, koje kernel operativnog sistema treba da „zna”. Prilikom izvšavanja određenog zadatka, sadržaj njegovog TCB se dinamički menja. Kada se zadatak (task) ne izvšava, njegov kontekst (informacije vezane za dati zadatak) nalazi se zapamćen unutar TCB, čekajući da bude ponovo aktiviran sledeći put kada se konkretni zadatak bude izvšavao. U opštem slučaju kontekst (context) nekog zadatka treba da sadrži minimalni skup informacija neophodan za sigurno nastavljanje izvšenja nekog zadatka, nakon što je prethodno njegovo izvšavanje prekinuto. U opštem slučaju, TCB sadrži: registre opšte namene, programski brojač, identifikacioni string ili broj, statusne registre, podatak o prioritetu zadatka itd. S druge strane, promena (komutacija) kontekstamože da podrazumeva čuvanje podataka vezanih za sadržaj registara koprocesora (memory page registar), kopije memorijski mapiranih I/O lokacija itd. Podatke vezane za TCB, operativni sistem čuva u formi jedne ili više struktura podataka (kao npr. lančana lista). 14

Uvek kada aplikacija obavlja sistemski poziv, planer (scheduler) odlučuje da li je potrebno izvšiti promenu konteksta (context switching). Vreme neophodno da planer prebaci nit izvršavanja sa jednog na drugi zadatak naziva se vreme promene (komutacije) konteksta. Prilikom projektovanja aplikacije se teži da njeno izvšavanje ne zahteva čestu promenu konteksta, da ne bi došlo do degradacije performansi sistema.

Slika 8. Prikaz tipične struktura TCB Sam čin promene konteksta vrši dispečer (dispatcher) – poseban modul planera. Primer standardne strukture podataka koja je sadržana u TCB prikazan je na Slici 8. Kada planer (scheduler) kernela odluči da zaustavi izvršavanje zadatka task 1 i pokrene izvršavanje zadatka task 2, preduzima sledeće korake: 1. Kernel „pamti“ potrebne informacije, tj. trenutni kontekst taska 1 unutar njegovog TCB. 2. Učitava prethodno „zapamćene” informacije o kontekstu taska 2 iz njegovog TCB, pri čemu task 2 postaje trenutna nit (thread) izvršavanja. 3. Kontekst taska 1 je zapamćen i „zamrznut” dok se task 2 izvšava; međutim, u slučaju kada planer odluči da nastavi izvšavanje taska 1, njegovo izvšavanje se nastavlja u identičnom okruženju koje je postojalo neopsredno pre prethodne promene konteksta.

4.4. Dispečer (dispatcher) 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 izvšavanja (tok kontrole) prolazi kroz jednu od tri moguće oblasti toka izvšavanja: kroz zadatak (task) aplikacije, kroz prekidnu rutinu ili kroz kernel. Kada zadatak ili prekidna rutina izvrši sistemski poziv, tok kontrole se prebacuje kernelu koji izvšava jednu od svojih sistemskih rutina. Kada je vreme da tok kontrole napusti kernel, dispečer je odgovoran za prosleđivanje kontrole jednom od zadataka korisničke aplikacije. U zavisnosti od toka kontrole neposredno pre sistemskog poziva, dispečer može da se ponaša različito. Kada je zadatak izvršio sistemski poziv, dispečer se koristi za prosleđivanje toka kontrole nakon zavšetka svakog sistemskog poziva. U ovom slučaju dispečer može koordinirati promenu stanja zadataka koju može prouzrokovati sistemski poziv, s obzirom da 15

jedan ili više taskova može postati spreman za izvšavanje. S druge strane, ukoliko prekidna rutina izvrši sistemski poziv, pozivanje dispečera se odlaže sve do potpunog završetka izvršavanja prekidne rutine bez obzira što je u međuvremenu oslobođen neki od blokiranih resursa sistema, što bi normalnim okolnostima proizvelo promenu (komutaciju) konteksta zadataka. Dakle, u ovom slučaju ne dolazi do promene konteksta obzirom da se prekidna rutina mora izvšavati bez prekida njenog izvšavanja od strane zadatka.

4.5 Foreground-Background sistemi Foreground-background (ili super-loops) sistemi predstavljaju nadogradnju interrupt-only sistema i primer uobičajene arhitekture aplikacija za današnje embedded sisteme. Najveći broj aktuelnih aplikacija baziranih na mikrokontrolerima (mobilni telefoni, GPS uređaji, mikrotalasne peći, igračke itd.) su projektovani kao foreground-background sistemi. Inače, u pitanju su mikroračunarski sistemi niske složenosti (small scale) i u opštem slučaju su projektovani tako da funkcionišu kako je prikazano na Slici 9.

Slika 9. Foreground-Background sistemi

16

Ovi sistemi uključuju zadatke kontrolisane prekidima, ili zadatke u realnom vremenu, koji predstavljaju foreground i zadatke koji nisu kontrolisani prekidima i koji predstavljaju background. Foreground zadaci se raspoređuju za izvršavanje prema različitim pravilima raspoređivanja izvršavanja, dok su background zadaci praktično nižeg prioriteta u odnosu na bilo koji foreground zadatak. Zbog toga background zadatke treba koristiti za operacije koje nisu vremenski kritične. Tipične operacije koje se obavljaju u okviru background zadataka su osvežavanja sadržaja displeja koja su niskog prioriteta, neke operacije rada sa štampačem, softverski watchdog tajmer za foreground procese itd. Uobičajeno, aplikaciju kod foreground-background sistema čini beskonačna petlja koja poziva module ili funkcije. Pri tome moduli obavljaju željene operacije u background režimu rada. Sa druge strane, ISR-ovi (Interrupt Service Routine) manipulišu asinhronim događajima u foreground režimu rada. Foreground se naziva interrupt-level, a background – task-level. Kritične operacije se obavljaju od strane ISR-ova, kako bi se pri tome zadovoljili zahtevi u pogledu vremena izvršenja. Informacija koja je potrebna background modulu priprema se od strane ISR-a. Background modul se neće izvršiti sve dok mu ne dođe red, tj. vreme za njegovo izvršenje (task-level response time). Najgore vreme izvršenja zavisi od vremena izvršenja background petlje. S obzirom da vreme izvršenja tipičnog programa kod foregroundbackground sistema nije konstantno, to znači da i vreme prolaska kroz sukcesivne iterativne prolaze u petlji neće biti determinističko. Štaviše, ako se promeni kôd, promeniće se i vreme prolaza kroz petlju. Kod mikrokontrolerskih aplikacija, prvenstveno sa aspekta potrošnje energije, efikasnije je u background režimu zaustaviti (halt) rad mikroprocesora (CPU), a celokupno procesiranje vršiti u okviru ISR-a. 4.6. Algoritmi raspoređivanja Kao što je napomenuto, planer (scheduler) određuje koji se zadatak (task) izvšava prema algoritmu/pravilu raspoređivanja. 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).

4.5.1. Koncept kooperativnog raspoređivanja

Kod kooperativnih (cooperative) 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 ISR nakon svog završetka uvek ponovo vraća pravo upravljanja nad CPU-om prekinutom zadatku. Zadatak sa najvišim prioritetom stiče pravo upravljanja nad CPU-om samo kada tekući zadatak preda CPU. Kooperativno raspoređivanje se drugačije naziva raspoređivanje bez „istiskivanja“ (nonpreemptive scheduling).

17

Slika 11. Kooperativni (cooperative ili non-preemptive) kernel Profil izvršenja kooperativnih kernela prikazan je na Slika 11 i opisuje se na sledeći način: 1) Prekida se zadatak koji se izvršava. 2) Ako su prekidi dozvoljeni, CPU prelazi (skače) na izvršenje ISR-a. 3) ISR obrađuje događaj i postavlja zadatak sa najvišim prioritetom u stanje ready, čime zadatak postaje spreman za izvršenje. 4) Nakon završetka ISR-a, izvršenjem naredbe Return From Interrupt, CPU se vraća na izvršenje prekinutog zadatka. 5) Izvršenje prekinutog zadatka se nastavlja sa lokacije koja je sledila nakon prekinute instrukcije. 6) Nakon završetka zadatka, poziva se kernel koji dodeljuje CPU drugom zadatku. 7) Kernel „vidi” koji ready zadatak ima najviši nivo prioriteta i obavlja prebacivanje (komutaciju) ka tom zadatku. Vreme izvršenja (task-level response time) kod kooperativnih kernela je znatno kraće u odnosu na ono kod foreground-background sistema, jer vreme izvršenja u najgorem slučaju zavisi od vremena izvršenja najdužeg zadatka, što znači da je ovo vreme nedeterminističko. Ozbiljan nedostatak kooperativnih kernela je nepredvidljivost odziva. Naime, zadatak koji je u stanju ready, a ima najviši nivo prioriteta, mora da čeka sve dok se tekući zadatak ne završi. To znači da je vreme izvršenja (task-level response time) nedeterminističko. 4.6.2. 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. 18

Inače, prioriteti mogu da budu: (1) statički (svakom procesu se pridružuje prioritet kada se učita u memoriju) i (2) dinamički (prioritet procesa se menja u toku izvršavanja). 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 (klasu biramo na osnovu prioriteta), a za izbor zadatka unutar klase koristimo Round-Robin algoritam (o kojem će biti reči kasnije).

Kao što je prikazano na Slici 12, zadatku koji je u stanju ready, a čiji je prioritet najviši, uvek se daje pravo upravljanja nad CPU-om. Naime, ako u toku izvršenja tekućeg zadatka egzistira zadatak u stanju ready, čiji je prioritet viši tekući zadatak se istiskuje (suspenduje), i zadatak, čiji je nivo prioriteta viši, dobija pravo upravljanja nad CPU-om. Kada ISR kreira ready zadatak sa višim nivoom prioriteta, nakon završetka ISR-a, prekinuti zadatak se suspenduje, a novi zadatak višeg prioriteta počinje da se izvršava. Real-time kerneli obično podržavaju 256 nivoa prioriteta, pri čemu je prioritet 0 najviši, a prioritet 255 – najniži. Doduše, postoje kerneli koji tumače prioritete u suprotnom redosledu. Dakle, prema prioritetnom raspoređivanju zadatak sa višim prioritetom, koji je spreman za izvršenje, ima prednost pri odlučivanju o dodeljivanju procesorskog vremena. Kada zadatak sa višim prioritetom postane spreman za izvršenje (ready), kernel odmah „pamti” kontekst zadatka koji se trenutno izvršava u njegovom TCB i prelazi na izvšavanje zadatka višeg prioriteta. Kao što je prikazano na Slici 12, izvšavanje zadatka task 1 je prekinuto na osnovu višeg prioriteta zadatka task 2, čije je izvšavanje zatim prekinuto od strane zadatka task 3 još višeg prioriteta. Nakon što je izvšavanje zadatka task 3 završeno, nastavljeno je izvšavanje zadatka task 2, a nakon zavšetka njegovog izvršavanja nastavljeno je izvršavanje zadatka task 1.

Slika 12. Primer prioritetnog raspoređivanja sa istiskivanjem izvršavanja zadataka Iako zadaci imaju dodeljene prioritete prilikom njihovog kreiranja, moguće je dinamički menjati prioritete pomoću sistemskih poziva kernela. Međutim, treba naglasiti kako pogrešna upotreba ove mogućnosti može dovesti do pojave inverzije prioriteta, mrtvih petlji (deadlocks) i eventualnog otkaza sistema. Kao nedostatak prioritetnog raspoređivanja javlja se sledeći problem: može da se dogodi da se zadaci nižeg prioriteta nikada ne pristupe mikroprocesoru (CPU) – ova pojava se zove „izgladnjivanje“ (starvation). Problem bismo mogli izbeći tako što ćemo prioritet procesa koji se trenutno izvršava prilikom svakog prekida hardverskog sata smanjiti za jedan. Ukoliko prioritete dinamički određuje RTOS, treba uzeti u obzir sledeće: 19

• •

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. 4.6.3. Koncept Round-Robin raspoređivanja

Round-robin je jedan od najstarijih i najjednostavnijih algoritama raspoređivanja, koji je preemptive i non-priority. Ovaj koncept raspoređivanja obezbeđuje da se svakom zadatku dodeli 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 (sledećem) zadatku. Ukoliko se zadatak ne završi tokom time slice-a (quantuma), isti će bit prekinut od strane operativnog sistema (OS) i dispečer bira sledeći zadatak za izvršavanje. Pošto dispečer ide redom po kružnoj listi, ovaj algoritam garantuje da svaki proces će dobiti šansu za izvršavanje. Ukoliko je n zadatak spremno u redu za čekanje i ako veličina time slice-a (quantum-a) iznosi q, svaki proces će u idelanom slučaju dobiti 1/n procesorskog vremena. Takođe, svaki zadatak neće čekati više od nq vremena do sledeće dodele procesorskog vremena. Tačnija formula je n(o+q), gde je o vreme potrebno za promenu (komutaciju) konteksta zadatka. Kao rezultat, ponašanje round-robin algoritama raspoređivanja značajno zavisi od veličine time slice-a. Ako time slice ima veliku vrednost round-robin algoritam je sličan algoritmu First_Come First_Served, dok ako time slice ima malu vrednost round-robin algoritam je sličan processor sharing-u. Dakle, Round-robin raspoređivanje izvšavanja zadataka ne omogućava ispunjenje zahteva sistema u realnom vremenu (RTS), s obzirom da su kod RTS zadaci različitog nivoa prioriteta, tj. različite važnosti. Kao rešenje, prioritetno raspoređivanje se može upotpuniti Round-robin algoritmom raspoređivanja, tako što se procesorsko vremena podjednako dodeljuje svim zadacima istog prioriteta, kao što je ilustrovano na Slici 13.

Slika 13. Kombinacija round-robin i prioritetnog raspoređivanja Dakle, svaki zadatak (task) se izvršava u definisanom vremenskom intervalu u okviru grupe zadataka istog prioriteta, koji se izvšavaju u okviru ciklusa (round-robin cycle). Brojač 20

vremena izvšavanja (run-time counter) prati vremenske intervale izvšavanja svakog zadatka i inkrementira run-time brojač zadataka. Kada se završi vremenski interval određen za izvršavanje nekog zadatka, brojač koji je pridružen tom posebnom zadatku se resetuje, i zadatak se stavlja na kraj grupe zadataka istog prioriteta. Novokreirani zadaci istog prioriteta postavljaju se na kraj grupe zadataka, pri čemu se njihovi brojači inicijalizuju na nulu. Ukoliko je izvšavanje zadatka u okviru round-robin ciklusa prekinuto od strane zadatka višeg prioriteta, njegov brojač vremena izvršavanja (run-time brojač) se „pamti“ i kasnije restaurira nakon što je prekinuti zadatak dobio ponovo dozvolu za izvršavanje. Prema Slici 12, izvršavanje zadatka task 1 je prekinuto od strane zadatka task 4, ali nakon zavšetka izvršavanja zadatka task 4, task 1 nastavlja sa izvšavanjem tamo gde je prekinut. Dakle, kod RTOS sa round-robin algoritmom raspoređivanja takt fiksne periode se koristi za iniciranje prekida u skladu sa vrednosti definisanog vremenskog intervala raspoređivanja. Zadatak kome je dodeljeno procesorsko vreme se izvšava do završetka njegovog izvšavanja ili dok ne istekne dodeljeni vremenski interval. Ukoliko zadatak nije završio svoje izvršavanje prilikom promene (komutacije) konteksta, njegov kontekst se „pamti” i zadatak se postavlja na kraj liste spremnih zadataka istog prioriteta. 4.6.4. Osnovni parametri zadatka (task-a)

• • • • • • • • •

Specifikacija redosleda izvršavanja – specifikacija da li neki zadatak treba da prethodi drugim zadacima. Vreme završetka ili stizanja rij – vreme završetka j-te instance zadatka ζi. Faza φi – vreme završetka prve instance zadatka ζi. Vreme odziva – vreme proteklo između aktivacije zadatka i završetka njegovog izvršavanja. Apsloutni krajnji rok di – vreme do kada izvršenje instance zadatka mora da bude završeno. Relativni krajnji rok Di – Maksimalno vreme odziva zadatka. Mera labavosti u izvršenju zadatka – Indikacija hitnosti ili zaostajanja u izvršavanju zadatka. Period pi – Minimalno trajanje vremenskog intervala između završetka dva uzastopna ista zadatka. Vreme izvršavanja ei – Maksimalno vreme potrebno za završetak izvšavanja zadatka, u slučaju da se isti samostalno izvšava i da poseduje kontrolu nad svim potrebnim resursima.

4.6.5. Koncept cikličnog raspoređivanja

Kod cikličnog izvršavanja odluke o raspoređivanju se vrše periodično u vremenskim intervalima nazvanim frejmovima. Ovaj koncept je veoma popularan, s obzirom da je jednostavan i generiše kompletan i predvidljiv način raspoređivanja. Uslovi cikličnog izvršavanja zadataka: 1. Odluka o raspoređivanju se donosi na početku svakog frejma. Glavni ciklus predstavlja minimalni period za izvšavanje svih zadataka u kome su zadovoljeni svi vremenski zahtevi i periode svih zadataka. Prema tome, glavni ciklus se određuje kao najmanji zajednički sadržalac (NZS) perioda svih zadataka: 21

NZS ( p i ) . 1≤ i ≤ n

2. Dužina frejma (f) mora da bude dovoljna kako bi svaki zadatak započeo i završio izvršavanje u okviru jednog frejma: f ≥ max ( e i ) 1≤ i ≤ n

3. Da bi dužina cikličnog raspoređivanja bila što je moguće kraća, veličina frejma mora da bude izabrana tako da glavna perioda sadrži ceo broj frejmova: ⎡ pi ⎢f ⎣

⎤ pi ⎥− f =0 ⎦

4. Kako bi se obezbedilo da se izvršavanje svakog zadatka završi pre krajnjeg roka za njegovo izvršavanje (deadline), frejmovi moraju da budu dovoljno kratki – tako da između trenutka raspoređivanja i krajnjeg roka za izvršenje zadatka, u najgorem slučaju, postoji jedan frejm: f − NZD( p i , f ) ≤ Di

U Tabeli 2 dat je primer određivanja veličine frejma kada su zadaci definisani karakterističnim parametrima.

Tabela 2. Parametri četiri zadatka koji se raspoređuju Na osnovu uslova cikličnog raspoređivanja određuju se: 1. dužinu glavnog ciklusa NZS ( p i ) = NZS (15,20,22) = 660 , 1≤ i ≤ 3

2. dužinu frejma (f) f ≥ max ( e i ) = 3 , 1≤ i ≤ 3

3. (potencijalni) broj frejmova u glavnom periodu ⎡ pi ⎢f ⎣

⎤ pi ⎥ − f = 0 ⇒ f = 2,3,4,5,10 ... , ⎦

4. dužinu frejma 22

f − NZD( p i , f ) ≤ Di ⇒ f = 2,3,4,5.

Na osnovu uslova (2-4) dobijamo da veličina frejma može imati jednu od sledeće tri vrednosti: 3,4 ili 5. 4.6.6. Koncept raspoređivanja sa fiksnim prioritetom

Kod ovog koncepta raspoređivanja, prioritet svakog periodičnog zadatka je fiksiran u odnosu na ostale zadatke. Ovaj pristup je opisan rate-monotonic (RM) algoritmom. To je optimalan algoritam sa statičkim prioritetima u kome se zadatku sa manjim periodom potrebnim za izvršavanje, dodeljuje veći prioritet u odnosu na zadatke sa dužim vremenom izvšavanja. Rate-monotonic teorema: Za dati skup periodičnih zadataka i prioritetni algoritam raspoređivanja, optimalan algoritam raspoređivanja se ostvaruje tako što zadaci (task-ovi) sa kraćim periodima imaju veći prioritet.

Tabela 3. Parametri 4 zadatka koji se raspoređuju prema RM teoremi Zadatak ζ1 ima najkraći period (p1) i prvi se izvršava. Jedan od mogućih rezultata izvršavanja zadataka, čiji su parametri dati u Tabeli 3 prikazana je na Slici 13.

Slika 13. Raspoređivanje zadataka prema RM teoremi Teorema o graničnom uslovu primenljivosti RM algoritma: Svaki skup periodičnih zadataka je rasporedljiv na procesoru, ukoliko iskorišćenost procesora nije veća od n ⋅ (21/ n − 1). Broj zadataka (n)

1

2

3

5

10

50

100



RMA bound

1

0,828

0,780

0,743

0,718

0,698

0,696

0,693

Tabela 5. Vrednost faktora iskorišćenosti CPU za primenljivost RT algoritma, za različite vrednosti broja zadataka spremnih na izvršenje (n) 23

Rezultat poslednje teoreme pruža odgovor na granične uslove upotrebljivosti RM algoritma. Granična vrednost u slučaju kada je veliki broj zadataka na sistemu spreman za izvršavanje određena je sledećim izrazom:

1⎫ 2X −1 ⎧ 1/ n = ln 2 = 0,693 lim n ⋅ (2 − 1) = ⎨ x = ⎬ = . lim n→∞ n ⎭ x →0 x ⎩ 4.6.7. Koncept raspoređivanja sa dinamičkim prioritetom

Kod koncepta raspoređivanja sa dinamičkim prioritetom, prioritet zadatka u odnosu na druge zadatke se menja u skladu sa početkom i završetkom izvršavanja (zadatka). U najpoznatije dinamičke algoritme spada EDF (Earliest Deadline First) algoritam, koji je baziran na deadline vrednostima, a ne na potrebnom vremenu za izvšenje zadatka. Kao rezultat algoritma zadatak koji je spreman za izvšavanje sa najskorijim rokom ima najviši prioritet u svakom trenutku vremena. Teorema o graničnim uslovima primenljivosti EDF algoritma raspoređivanja: Skup periodičnih zadataka, kod kojih je relativni deadline jednak njihovom periodu, može se na izvodljiv način rasporediti ako i samo ako je ispunjeno: n

e

∑ pi i =1

≤ 1.

i

Pomenuta teorema predstavlja granični slučaj primenljivosti EDF algoritma. Rezultat raspoređivanja izvršavanja zadataka prema konceptu raspoređivanja sa dinamičkim prioritetom (EDF algoritam), čiji su parametri dati u Tabeli 6, prikazan je na Slici 11.

Tabela 6. Parametri zadataka za EDF koncept raspoređivanja

Slika 11. Vremenska osa rasporeda izvršavanja zadataka kao rezultat EDF algoritma raspoređivanja zadataka, čiji su parametri dati u Tabeli 6 24

4.6.8. Poređenje EDF i RM koncepta raspoređivanja

EDF algoritam je fleksibilniji i postiže bolje iskorišćenje od RM algoritma. Međutim, vremensko ponašanje sistema kod kojeg se raspoređivanje izvršavanja zadataka vrši prema RM algoritmu je predvidljivije. U slučaju kada je sistem preopterećen, RM algoritam je stabilan u prisustvu neispunjenih krajnjih vremena (deadline-ova), s obzirom da će u ovom slučaju prioritet zadatka, koji nije izvšen u roku, biti nizak – tako da nema posledica prema zadacima visokog prioriteta. Nasuprot tome, sa EDF algoritmom je teško predvideti koji zadatak neće biti izvršen u roku. Isto tako, RM algoritam zahteva češće raspoređivanje u odnosu na EDF algoritam.

4.7. Najčešći objekti kernela • • •

Zadaci (task-ovi) – koji predstavljaju nezavisne i konkurentne niti izvšavanja, koje se “takmiče” za procesorsko vreme. 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.

Projektanti koji razvijaju aplikacije za embedded sistemime u realnom vremenu mogu kombinovati ove osnovne objekte kernela, kako bi rešili uobičajene probleme u razvoju aplikacija koje rade u realnom vremenu, kao što su: konkurentnost, aktivna sinhronizacija i razmena podataka.

Slika 14. Stanja zadatka 25

4.7.1. Zadaci

Zadatak (task) je jedinstvena programska celina koja vidi CPU kao svoju „privatnost”. Praksa je da se kod real-time aplikacija ukupan posao deli na veći broj zadataka, pri čemu je svaki od zadataka zadužen za rešavanje dela problema. Svakom zadatku je dodeljen nivo prioriteta, sopstveni skup mikroprocesorskih registara i sopstvena oblast u magacinu (stack). Tipično svaki zadatak predstavlja jednu beskonačnu programsku celinu (petlju). Inače, zadatak može da bude u jednom od sledećih pet stanja (Slika 14): • • • • •

dormant (zadatku koji se nalazi u memoriji, ali nije dostupan multitasking kernelu), ready (zadatak može da se izvrši, ali je njegov priroritet nižiu od tekućeg zadatka), running,(zadatak upravlja nad CPU-om) waiting (zadatak čeka na pojavu događaja), ISR (CPU opslužuje prekid).

4.7.2. Semafori

Semafor (ili 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 dva zadatka sinhronizuju svoje aktivnosti.

Postoje dva tipa semafora: (1) binarni i (2) brojački. Binarni semafor može da prima vrednosti: 0 (semafor je nedostupan ili prazan) ili 1 (semafor je dostupan ili pun); dok brojački semafor, zavisno da li je implementiran nad 8, 16 ili 32 bita, može da prima vrednosti: 255, 65.535 ili 4.294.967.295, respektivno. (Stvarni obim podatka sa kojim manipuliše semafor zavisi od kernela.) U uobičajene procedure pri radu sa semaforima spadaju: • • • •

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.

Kada je semafor kreiran, kernel RTOS mu dodeljuje SCB (Semaphore Control Block), jedinstven ID, pridruženu vrednost semafora (u binarnoj formi ili formi vrednosti brojača) i pridruženu listu čekanja zadataka (task-waiting list), što je prikazano na Slici 15. U principu, nad semaforom se obavljaju sledeće tri operacije: • • •

Initialize (Create), Wait (Pend) i Signal (Post).

Inicijalna vrednost semafora mora da se definiše u trenutku inicijalizacije semafora. Inicijalno, lista čekanja zadataka (task-waiting list) je prazna, a zadatak koji želi da pristupi semaforu obavlja operaciju Wait. Ako je semafor dostupan (vrednost semafora veća od 0), tada se vrednost semafora dekrementira, a zadatak koji je zahtevao semafor produžava sa izvr-

26

šenjem. Za slučaj da je vrednost semafora bila 0, tada zadatak obavlja operaciju Wait nad semaforom, a kernel smešta zadatak u listu čekanja. Najveći broj kernela omogućava da se specificira krajnje vreme (timeout). To znači da ako semafor nije bio dostupan u okviru određenog vremenskog perioda, tada zadatak koji je zahtevao pristup deljivom resursu prelazi u stanje run, a onom koji je izdao poziv (caller) signalizira da je došlo do greške (istekao je timeout).

Slika 15. Semafor objekat, njegova struktura i pridružene strukture podataka Zadatak koji oslobađa semafor obavlja operaciju Signal. Ako ne postoji zadatak koji čeka na semafor, vrednost semafora se inkrementira. Ako, pak, bilo koji zadatak čeka na semafor, tada jedan od zadataka prelazi u stanje run, vrednost semafora se ne inkrementira; tj, ključ se predaje jednom od zadataka koji na njega čeka. U zavisnosti od kernela, zadatak koji prima semafor može da bude: • •

zadatak sa najvišim prioritetom koji čeka na semafor, ili prvi zadatak koji je zahtevao semafor (FIFO koncept)

Neki od kernela poseduju mogućnost da u toku faze inicijalizacije biraju koji će od oba pristupa implementirati. Napomena: Mutex semafori pretstavljaju specijalnu verziju binarnih semafora koji podržavaju osobine vlasništva nad semaforom, rekurzivnog pristupa, zaštite od brisanja zadatka i jedan ili više protokola koji omogućavaju izbegavanje problema vezanih za međusobno isključenje. 4.7.3. 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. Pri tome, razmena informacije između zadataka se može ostvariti na jedan od sledeća dva načina: 27

• •

prenos preko globalno promenljivih podataka (global data) ili putem slanja poruka (sending messages).

Kada se za potrebe prenosa koriste globalne promenljive, tada svaki zadatak ili ISR mora da ostvari isključivo pravo pristupa nad tom promenljivom. Kada se koristi ISR, jedini način da se ostvari isključivo pravo pristupa promenljivoj koja se deli ostvaruje se putem zabrane rada prekidima. Sa druge strane, ako dva zadatka dele podatke, tada svaki od njih može da ima isključivo pravo pristupa nad tim podacima, bilo da se to postiže zabranom ili dozvolom rada prekidima, bilo putem korišćenja semafora. Naglasimo da zadatak jedino može da prenese informaciju ISR-u preko globalnih promenljivih. Pri tome zadatak nije „svestan” kada se globalna promenljiva promenila od strane ISR-a, osim ako ISR ne signalizira zadatku na tu promenu putem korišćenja semafora, ili ako zadatak tu promenu ne uoči putem čestog periodičnog testiranja sadržaja te promenljive. Da bi se na zadovoljavajući način otklonili pomenuti nedostaci, kernel obično koristi tehnike koje su bazirane na: (1) poštanskom sandučetu (message mailbox) ili (2) redu čekanja poruka (message queue). 4.7.3.1. Poštansko sanduče (Message mailbox)

Poruke mogu da se šalju zadatku preko servisa (usluga) koje pruža kernel. Message mailbox, alternativno nazvan message exchange, predstavlja promenljiva tipa pokazivač. Preko usluga koje pruža kernel, zadatak ili ISR može da postavi message (pokazivač) u mailbox-u. Na sličan način, jedan ili veći broj zadataka može da prima poruke (messages) preko usluga koje pruža kernel. Oba zadatka, i onaj koji prima i onaj koji predaje, moraju da se „slože” oko toga na šta, u suštini, pokazivač ukazuje. Lista čekanja (waiting list) se pridružuje svakom mailbox-u za slučaj da više od jednog zadatka želi da prima poruke preko mailbox-ova. Zadatak koji želi da prihvati podatak iz praznog mailbox-a se suspenduje i smešta u listu čekanja sve dok se ne primi poruka (message). Kerneli, obično, dodeljuju krajnje vreme (timeout) zadatku koji čeka na poruku. Ako se poruka ne primi pre isteka timeout-a, zadatak koji je izdao zahtev se postavlja u stanje ready za izvršenje, a kôd greške (ukazuje na to da je istekao timeout) se predaje tom zadatku sa ciljem da se ta informacija saopšti korisniku. U slučaju kada se poruka smesti u mailbox, njena predaja može, u zavisnosti od kernela, da bude: • •

zadatku sa najvišim prioritetom koji čeka na tu poruku (priority based) ili prvom zadatku koji je zahtevao datu poruku (FIFO pristup).

4.7.3.2. Red čekanja poruka (Message queue)

Kako bi obezbedio efikasan način za razmenu podataka između zadataka, kernel podržava rad sa objektom u formi redova sa porukama (message queues) i servisom za njihovim upravljanjem. Message queue obično se realizuje kao polje mailbox-ova. Od strane kernelovih servisa, zadatak ili ISR može da ostavi poruku u message queue. Na sličan način, jedan ili veći broj zadataka može da primi poruke preko servisa koje pruža kernel. Zadaci moraju da se „dogovore” oko toga na šta pokazivač u suštini ukazuje. U opštem slučaju, prva poruka koja se smešta u red čekanja je ujedno i prva koja se uzima iz reda čekanja (FIFO princip). Kao i kod mailbox-a, svakom message queue se pridružuje lista čekanja. Zadatak koji želi da primi poruku iz praznog reda čekanja se suspenduje i smešta u listu čekanja sve 28

dok sve dok primalac ne bude spreman da te iste poruke prihvati. Na ovaj način su zadaci (pošiljalac i primalac poruka) oslobođeni od potrebe da vrše simultano slanje i prijem poruka. Najčešće kernel dozvoljava zadatku da čeka na poruku za specificirani timeout. Ako se poruka ne primi pre isteka timeout-a, tada zadatak koji je izdao zahtev se postavlja u stanje ready, a kôd o grešci (ukazuje da je istekao timeout) se predaje tom zadatku. Kada se poruka nalazi u redu čekanja tada se ta poruka predaje zadatku čiji je prioritet najviši, ili prvom zadatku koji je čekao na tu poruku. Slično kao kod semafora, red sa porukama poseduje pridružene komponente koje kernel koristi za rad sa njim. Prilikom prvog kreiranja reda sa porukama njemu je dodeljen kontrolni blok reda QCB (Queue Control Block), naziv reda sa porukama, njegov ID, memorijski bafer, dužina reda i najveća dužina poruke, kao i lista sa jednim ili više zadataka koji čekaju. Ova struktura prikazana je na Slici 16.

Slika 16. Tipična struktura reda čekanja poruka Posao kernela uključuje dodelu jedinstvenog ID broja redu za čekanje, kreiranje QCB i liste zadataka koji čekaju. Takođe, kernel na osnovu dužine reda čekanja i maksimalne veličine poruke koju specificira projektant/programer, određuje veličinu memorije koja je potrebna za red čekanja. Nakon toga, kernel vrši alociranje memorije u oblasti sistemske memorije ili u nekom privatnom memorijskom prostoru. Sâm red poruka se sastoji od niza elemenata, od kojih svaki može da „čuva“ jednu poruku. Elementi reda čekanja koji sadrže prvu i poslednju poruku se nazivaju glava (head) i rep (tail). Neki elementi reda mogu da budu prazni, odnosno ne moraju da sadrže poruku. Bez 29

obzira da li su prazni ili ne, ukupni broj svih elemenata određuje ukupnu dužinu reda. Ova vrednost je specificirana prilikom kreiranja reda sa porukama od strane projektanta/programera. Kao što Slika 16 ilustruje, red sa porukama ima pridružene dve liste zadataka koji čekaju: zadaci koji čekaju na prijem poruke su sadržani u listi čekajućih zadataka u slučaju kada je red sa porukama prazan, dok su zadaci koji čekaju na slanje poruke sadržani u listi čekajućih zadatak a u slučaju kada je red sa porukama pun. Tipične operacije sa redom čekanja poruka uključuju operacije: • • •

kreiranje i brisanje reda sa porukama slanje i primanje poruka preuzimanje informacija o redu sa porukama.

4.8. Kritične sekcije kôda Kritična sekcija kôda (critical section) je kod koga 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.

4.9. 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). ISR procesira događaj i nakon završetka ISR-a, a izvršenje se vraća na: • • •

Background kod background-foreground sistema, prekinuti zadatak kod kooperativnih (cooperative ili non-preemtive) kernela, ili zadatak najvišeg prioriteta koji je ready za izvršenje kod preemtive kernela.

Prekidi omogućavaju mikroprocesoru da procesira događaje samo kada se oni jave, što obezbeđuje da mikroproceso izbegne kontinualno testiranje stanja na liniji kojom se signalizira pojava događaja (tzv. permanentno testiranje se izvodi tehnikom poolling-a ili looking at), a odnosi se na to da se ustanovi da li se događaj javio ili ne. Mikroprocesor ima mogućnost da zabrani ili dozvoli rad prekidima. Kod real-time sistema, prekidima treba zabraniti rad na što je moguće kraće vreme. Zabrana rada prekida ima uticaj na latenciju prekida (interrupt l atency), koja je definisana na sledeći način: IL = maksimalan_iznos_vremena_za_koji_su_prekidi_zabranjeni + vreme_potrebno_da_počne_izvršenje_prve_instrukcije_ISR-a.

Velika latencija prekida može da uzrokuje da se analiza nekih hitnih događaja propusti. Mikroprocesor, takođe, omogućava prekidima da se „gnezde”, što znači da kada se jedan prekid opslužuje, procesor može da prepozna i opsluži druge prekide.

30

4.10. Pipe objekat Pipe predstavlja objekat kernela koji omogućava nestrukturiranu razmenu podataka i sinhronizaciju između zadataka. Kod standardne implementacije, pipe je jednosmerni kanal za razmenu podataka, što je prikazano na Slici 17. Dva deskriptora na svakom kraju pipe-a (jedan na kraju za čitanje i jedan na kraju za upis) se vraćaju nakon kreiranja pipe-a. Podaci se upisuju preko jednog, a čitaju preko drugog deskriptora. Podaci ostaju u pipe-u u nestrukturiranom obliku stream-a podataka. Podaci se čitaju iz pipe-a u FIFO redosledu.

Slika 17. Tipična struktura pipe objekta Pipe omogućava jednostavni mehanizam za protok podataka, tako da zadatak koji čita podatke ostaje blokiran dok je pipe prazan; a zadatak koji šalje ili upisuje podatke, ostaje blokiran sve dok je pipe pun. Uobičajeno je da se pipe koristi za razmenu podataka između zadatka koji „proizvodi” podatke (data-producing task) i zadatka koji koristi podatke (dataconsuming task). Isto tako, omogućeno da postoji više zadataka koji vrše upis i više zadataka koji vrše čitanje iz pipe-a, što je ilustrovano na Slici 18.

Slika 18. Ilustracija uobičajenih operacija sa pipe-om Konceptualno gledano, pipe je sličan redu čekanja poruka. Međutim, za razliku od njega, pipe ne omogućava skladištenje više različitih poruka. Umesto toga, podaci koji su skladišteni u pipe-u nisu strukturirani već su u formi niza bajtova. Takođe, protok podataka u pipe-u je striktno FIFO tipa. Pored toga, pipe objekat omogućava select operaciju koja ne postoji kod 31

reda čekanja poruka i koja predstavlja jednu od osnovnih operacija koja se upotrebljava pri radu sa pipe objektom.

4.11. Zahtevi za memorijom Kod embedded sistema sa RTOS, za instaliranje kernela potreban je dodatni kodni (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

Kako se svaki zadatak izvršava nezavisno od drugog, neophodno je da se za svaki zadatak obezbedi sopstveni magacin tipa RAM. Zbog ovoga, projektant mora precizno da odredi zahteve u pogledu obima memorije koje postavlja svaki zadatak. Obim RAM-a, a samim tim i magacina, nije određen samo od strane broja lokalno promenljivih i poziva funkcije, nego i od broja dozvoljenih nivoa gnežđenja, tj. „pamćenja“ stanja CPU-ovih registara, ISR lokalno promenljivih itd. U zavisnosti od ciljnog procesora i korišćenog kernela, često kod nekih rešenja se koristi poseban magacin kojim se manipuliše svim interrupt-level kôdovima, čime se u značajnoj meri redukuju zahtevi za obim magacina. Takođe svim kernelima je potreban i dodatni RAM prostor za podršku rada interno promenljivim, strukturama podataka, redovima čekanja i dr. Ukupan prostor za slučaj da kernel ne podržava poseban magacin-za-prekid se određuje sledećom relacijom: zahtevi_za_aplikacioni_kod + prostor_za_podatke (tj. RAM) potreban_samom_kernelu + + suma (magacin_zadataka + MAX (gnežđenje_ISR-ova))

Za slučaj da kernel podržava rad sa posebnim magacinom za svaki prekid, tada ukupan obim ugrađenog RAM-a se određuje na sledeći način: zahtevi_za_aplikacioni_kod + prostor_za_podatke(tj. RAM)_potreban_samom_kernelu + + suma(magacina_zadataka) + MAX(gnežđenje_ISR-ova)

I u slučaju kada projektant ima na raspolaganju veliki iznos RAM-a, mora da vodi računa kako i na koji način se koristi prostor magacina. Kako bi se smanjio iznos potrebnog RAM-a koji je neophodan za aplikaciju, mora da se obrati pažnja kako se koristi magacin svakog zadatka. Navešćemo neka opšta pravila koja se odnose na uštedu RAM-a: • • • •

velika polja (1D ili 2D) i strukture podataka deklarisati lokalno u odnosu na funkcije i ISR-ove, redukovati gnežđenje, smanjiti korišćenje bibliotečkih funkcija i magacina, smanjiti broj poziva funkcija koje imaju veliki broj argumenata.

Kao zaključak bi mogli da istaknemo sledeće: multitasking sistem zahteva veći RAM i ROM prostor u odnosu na foreground/background sistem. Iznos ROM-a zavisi od obima kernela, a iznos RAM-a direktno zavisi od broja zadataka koji se izvršavaju od strane sistema. Nedostaci ugradnje real-time kernela se ogledaju u sledećem: povećava se cena sistema, veći je RAM i ROM prostor, režijsko vreme CPU-a se povećava za dodatnih 2-4 %. 32

4.12. Servisi kernela Zajedno sa objektima kernela, kernel obezbeđuje servise koji pomažu prilikom razvoja aplikacija za embedded sisteme u realnom vremenu. Ovi servisi se sastoje od skupa API funkcija koje se mogu koristiti za obavljanje operacija nad objektima kernela ili mogu da se koriste za upravljanje radom tajmera, procesiranje prekida, ulazno/izlazne operacija sa uređajima i upravljanje memorijom. Inače, aplikacioni programski interfejs (Application Programming Interface) predstavlja mikroračunarski interfejs koji definiše načine na koje aplikacioni program može da zahteva servise od biblioteka i/ili operativnih sistema. API definiše „rečnik" i konvencije pozivanja koje programer treba da primeni, kako bi koristio servise. To može da podrazumeva specifikacije za rutine, strukture podataka, objektne klase i protokole, koji se koriste za komunikaciju između softvera koji traži uslugu i biblioteke.

5. Primeri nekih RTOS RTOS može da bude (1) sa otvorenim kôdom (open-source tipa), (2) komercijalni i (3) namenjeni kućnoj (in-house) upotrebi, tj. „neprofesionalnim" korisnicima. RTOS za embedded sisteme se prevashodno koriste kod vrhunskih (high-end) mikroprocesora ili mikrokontrolera sa 32-bitnim mikroprocesorima. Medutim, rastući trend je primena RTOS kod embeddeed sistema srednje (mid-range) i male (small-scale) veličine. Na samom početku, navešćemo primer malog RTOS-a koji je razvijen na Berkliju (University of California, Berkeley) i naziva se TinyOS. On zauzima svega 178 bajta memorije, vrši promenu konteksta (contex switching) za isto vreme za koje iskopira 6 bajta memorije, i podržava dvo-nivoovsko planiranje (2-level scheduling). Dakle, poseduje podršku za niti (thread-ove), a takođe ima i efikasan mrežni interfejs. U pitanju je operativni sistem vođen događajima (event-based pristup), čime se dobija velika iskorišćenost procesora. Procesi se opslužuju bez blokiranja. Planer zadataka (task scheduler) ima jednostavnu FIFO strukturu. U zavisnosti od zahteva aplikacije, može koristiti više sofisticiran planer (scheduler), baziran ili na prioritetima, ili na deadline-u. Važno je da je planer (scheduler) „svestan” napajanja – prebacuje procesor u režima mirovanja (sleep mode), kada je red procesa prazan, ali ostavlja periferne uređaje operativnim, tako da bilo koji od njih može da „probudi” (wake-up) sistem. Ovakav pristup omogućava efikasno korišćenje baterije za napajanje. Kada je red spremnih procesa prazan, neki drugi proces može da se opsluži samo kao rezultat nekog događaja. Samim tim nema potrebe da se planer (scheduler) „probudi” sve dok se dogodi neki hardverski prekid (interrupt). U Tabeli 7 je prikazano vreme izvršavanja nekih operacija – korišćen je 8-bitni procesor (Harvard arhitektura) sa 16-bitnim adresiranjem. Procesor se napaja sa 3 V i poseduje 32 osmobitna registra (opšte namene) i radi na taktu od 4 MHz. Sistem ima i 8 KB flash memorije, i 512 B SRAM-a. U tradicionalne real-time operativne sisteme (RTOS) za embedded sisteme spadaju: VxWorks, WinCE, PalmOS i QNX. U Tabeli 8 su prikazane neke karakteristike ovih operativnih sistema. Mnogi od njih su bazirani na kernelu koji dopušta da se razne mogućnosti dodaju u zavisnosti od sistemskih potreba.

33

Cost (cycles)

Time (μs)

Byte copy

8

2

Normalized to byte copy 1

Post an event

10

2.5

1.25

Call a command

10

2.5

1.25

Post a task to scheduler

46

11.5

6

Context switch overhead

51

12.75

6

Interrupt (hardware cost)

9

2.25

1

Interrupt (software cost)

71

17.75

9

Operations

Tabela 7. Vreme izvršavanja primitivnih operacija u TinyOS

Name

Preemption

Protection

ROM size

Configurable

Targets

pOSEK

Tasks

No

2K

Static

Microcontrollers

pSOSystem

POSIX

Optional

Dynamic

PII→ ARM Thumb

VxWORKS

POSIX

Yes

≈286K

Dynamic

Pentium → Strong ARM

QNX NEUTRINO

POSIX

Yes

>100K

Dynamic

Pentium II → NEC chips

QNX REALTIME

POSIX

Yes

100K

Dynamic

Pentium II → 386’s

OS-9

Process

Yes

Dynamic

Pentium → SH4

CHORUS OS

POSIX

Optional

10K

Dynamic

Pentium → Strong ARM

ARIEL

Tasks

No

19K

Static

SH2, ARM Thumb

CREEM

Data-flow

No

560 bytes

Static

ATMEL 8051

Tabela 8. Poređenje karakteristika nekih embedded operativnih sistema Za nas su od interesa mali (small-scale) embedded sistemi, koji sadrže mikrokontrolere čija programska memorija (ROM, flash) ima kapacitet do 128 KB i čiji kapacitet RAM-a iznosi do 4 KB. Naravno, ova definicija nije striktna. RTOS nije neophodan, ali je poželjan kod malih (small-scale) embedded sistema – zbog svojih fundamentalnih prednosti i karakteristika koje su pobrojane u drugom poglavlju ovog rada. Ovde ćemo se osvrnuti i na njegove nedostatke: • • •

RTOS koristi memorijske resurse mikrokontrolera – i programsku (ROM, flash) i operativnu (RAM) memoriju; angažovani su resursi za obradu podataka unutar mikrokontrolera, čime se redukuju njegove performanse; povećana disipacija mikrokontrolera.

RTOS obezbeđuju bolju i bezbedniju sinhronizaciju. Naime, mali embedded sistemi bez RTOS često koriste globalne varijable za sinhronizaciju i komunikaciju između modula i funkcija. Međutim, korišćenje globalnih varijabli može da dovede pojave grešaka u izvršenju programa (bagova), što naročito je veoma izraženo kod sistema koji su vođeni prekidima (interrupt-driven systems). Iz razloga što funkcije pristupaju i dele pomenute varijable, ceo sis34

tem postaje veoma osetljiv („ranjiv”) na korupciju u toku izvršavanja programa (kôda). Kako program (kôd) počinje da raste, ove greške (bagovi) su „dublje" skrivene, a samim tim ih je teže otkriti. Kao posledica, vreme potrebno za razvoj kôda može značajno da se produži, čak i za veoma male embedded sisteme. Kod embedded sistema sa RTOS-om, zadaci mogu bezbedno da razmenjuju poruke (message passing) ili da sinhronizuju jedni druge, bez opasnosti od gorepomenute korupcije. Prilikom projektovanja malih embedded sistema kritičan parametar je cena hardvera, dok je vreme potrebno za razvoj najčešće veoma kratko. Zbog toga je značajno posedovati razvijen RTOS, koji je moguće, zahvaljujući skalabilnosti, prilagoditi za različite hardverske platforme uz manje modifikacije. Tabela 9 prikazuje rezultate istraživanja koji govore kako u okviru aktuelnih projekata (current project) komercijalni (commercial) RTOS imaju znatno veću primenu u odnosu na open-source (sa i bez komercijalne podrške) i „neprofesionalne" RTOS. Takav trend će se nastaviti i narednih godina tokom realizacije budućih projekata (upcoming project). Presudan razlog „leži" u tome što je za komercijalne RTOS postoji kvalitetna tehnička podrška.

Type of Operation System

Current project (%)

Upcoming project (%)

Commercial OS

51

47

Internally developed or in-house OS

21

17

Open source OS without commercial support

16

19

Commercial distribution of an open source OS

12

17

Tabela 9. Procenat korišćenja RTOS od strane projektanata (2006, istraživanje Embedded System Design-a)

35

6. Benčmark za RTOS Većina benčmark pristupa za testiranje operativnih sistema za rad u realnom vremenu (RTOS) zasnivaju se ili na (1) konkretnim aplikacijama, ili (2) na korišćenim sistemskim uslugama (fine-grained benchmarking). Budući da svaka aplikacija ima posebne zahteve, benčmark pristup, nasuprot generičkoj aplikaciji, neće prikazati (manifestovati) 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. Konkretno, Rhealstone benčmark meri sledeće: • • • • • •

vreme prebacivanje (komutacije) zadatka (task switch time), vreme raspoređivanja (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).

Ipak, u opštem slučaju, Rhealstone benčmark nije pogodan za testiranje RTOS iz nekoliko razloga. Prvo, mali broj RTOS mogu da prekinu „mrtvu petlju” (deadlock), o čemu će biti više reči kasnije. Datagram throughput time se zasniva na razmeni poruka (message passing), u kojoj RTOS kopira poruke u memorijsku oblast kojom upravlja operativni sistem. Međutim, ne koriste svi RTOS pristup razmene poruka. Neki RTOS samo razmenjuju pokazivač (pointer) memorije, tako da nije neophodno da se koristi poseban memorijski prostor kojim upravlja operativni sistem. Dakle, Rhealstone pristup je pogodan za male mikrokontrolere, koji nemaju dodatnu memoriju rezervisanu za operativni sistem. Latencija prekida (interrupt latency time) kod Rhealstone benčmarka nije određena samim RTOS-om, već isključivo zavisi od arhitekture mikroprocesora. Prema tome, Rhealsone benčmark može da se koristi za ad hoc testiranje i nije upotrebljiv u opštem slučaju. 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.

Merenje trajanja razmene podataka između zadataka je slična merenju trajanje ciklusa datagrama kod Rhealstone benčmarka. Kao odgovor na spoljašni testni prekid (interrupt test), manipulator prekida (interrupt handler) „budi" drugi zadatak preko semafora. U ovom slučaju, korišćenje semafora nije najbolji pristup. „Buđenje" zadatka direktnim korišćenjem sistemskog servisnog poziva (kao što su npr. sleep/wakeup servisni pozivi) predstavlja bolji pristup da se smanji prekomereno režijsko vreme (overhead). Drugi istraživači su predložili testove zasnovane na merenju vremena prenosa poruka (message transfer duration) i komunikacije kroz pipe, brzine sinhronizacije zadataka kroz proksi (proxy) i signal (signal – softverski prekid koji se generiše prilikom pojave nekog događaja), i trajanja prebacivanja (komutacije) zadatka. Međutim, ovi pokazatelji su zasnovani (bazirani) na nekim QNX-ovim RTOS platformama. Inače, pojedini koncepti, kao što su proksi i signal, ne postoje u najvećem broju RTOS. 36

6.1. Kriterijumi za poređenje Real-Time Operativnih Sistema (RTOS) Razvojni inženjerski timovi zasnivaju svoj izbor RTOS-a na različitim kriterijumima, među kojima se izdvajaju: • • • • • • • • • • •

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.

Pored toga, kao parametri se razmatraju i instalacija i konfigurisanje sistema, arhitektura samog RTOS-a, funkcionalnost i bogatstvo API interfejsa, nivo podrške za razne softverske alate i postojanje odgovarajuće dokumentacije. Kao što je ilustrovano na Slici 19, ankete koje je sproveo Embedded System Design tokom 2005-2007 na tržištu embedded sistema, pokazale su kako je sposobnost za rad u realnom vremenu (real-time capability) najvažniji kriterijum za izbor RTOS.

Slika 19. Uticaj pojedinih faktora prilikom izbora operativnog sistema (Istraživanja tržišta embedded sistema sprovedena od strane Embedded systems Design-a tokom 2005-7) 37

U narednim redovima utvrdićemo listu kriterijuma za poređenje RTOS-a – pri čemu će se razmatrati ograničen broj (kriterijuma). Naime, kriterijum kao što je reputacija prodavca/ isporučioca je subjektivan, krajnja cena zavisi od projekta i aplikacije, naknada za autorska prava (odnosno naknada za davanje licence) najčešće zavisi od kvantiteta – čak i ako isporučioci RTOS-a mogu da primene i druge modele za naplaćivanje usluga svojim korisnicima (na primer, naplata po aplikaciji, po proizvodu ili po mikrokontroleru), eksploatacija memorije zavisi od podešavanja kompajlera (kompilatora) i konfiguracije RTOS-a.

Ciljevi projektovanja. U petom poglavlju ovog rada je istaknuto kako RTOS može da bude (1) sa otvorenim kôdom, (2) komercijalni i (3) namenjen kućnoj upotrebi, odnosno za hobi entuzijaste (hobby-based). Projektanti bi trebalo da budu upoznati sa istorijom stvaranja RTOS-a i motivisanošću koja je dovela do njihovog stvaranja. „Neprofesionalni" (hobbybased) RTOS će najverovatnije biti manje stabilan nego popularni open-source ili komercijalni RTOS. Autor. Projektant bi trebalo da zna ko je idejni tvorac konkretnog RTOS – bila to jedna osoba ili čitava organizacija/kompanija. Šema planiranja (raspoređivanja). Važno je da se ispita pristup RTOS-a vremenskom planiranju, kako bi se utvrdilo da li koristi prioritetno raspoređivanje sa istiskivanjem (prioritybased preemptive scheduling) ili kooperativno raspoređivanje (cooperative scheduling). Sposobnost i učinak u realnom vremenu. Sposobnost sistema u stvari opisuje da li je sistem u stanju da ispuni zadate vremenske rokove. Upotrebom RTOS-a zauzimaju se ciklusi procesora, međutim RTOS-i svakako ne smeju da imaju nepredvidljivo (nedeterminističko) ponašanje. Broj zauzetih (korišćenih) ciklusa mikroprocesora (CPU ciklusi) i vreme utrošeno od strane RTOS-a bi trebalo da budu merljivi i vrednosti koja je prihvatljiva za projektante sistema. Informacije o sposobnosti i učinku u realnom vremenu nisu dostupne za pojedine RTOS. Čak i kad bi bile dostupne, postoji verovatnoća da nisu zasnovane na istoj hardverskoj platformi koju poseduje i koristi projektant. Eksploatacija memorije. Pored korišćenja CPU ciklusa, RTOS koriste i prostor RAM i ROM/flash memorije, što bi moglo da dovede do povećanja veličine navedenih memorija za celokupni sistem. Uvek postoji određena ravnoteža između eksploatacije (iskorišćenja) memorije i funkcionalnih zahteva RTOS-a. Snažniji i pouzdaniji API interfejsi uglavnom zahtevaju više linija kôda, dok jednostavniji API interfejsi zahtevaju samo minimalnu količinu kôda. Zbog toga bi trebalo da projektanti razumeju alate koje nude RTOS-i i potrebu za odgovarajućom eksploatacijom memorije. Jezička podrška. Programski jezik podržan od strane RTOS je još jedan važan kriterijum za razmatranje. Sistemski pozivi/Bogatstvo API interfejsa. Ovaj kriterijum određuje koliko su API interfejsi RTOS-a sadržajniji u odnosu na druge RTOS-e. Vrši se evidencija ukupnog broja sistemskih poziva za svaki RTOS. 6.2. Poređenje rezultata Podrška za debagovanje prilikom spoznaje OS-a. Ovim kriterijumom se određuje da li je RTOS podržan od strane IDE okruženja. Postojanjem podrške za debagovanje rad će biti olakšan, jer će korisnici moći da iskoriste interne informacije RTOS-a (kao što su stanje 38

tekućeg zadatka, stanje sistema...) koje obezbeđuje integrisano razvojno okruženje (Integrated Development Environment, skraćeno IDE). Table 10. Basic features comparasions of RTOSs for small microcontrollers Design objective

Scheduling scheme

Licence type

Documentation

System call/ API richness

Language support

OS awarness support in IDE

μITRON

Commercial

Priority based

Fee-based

Open specification, User manual

93

C

Renesas IDE

μTKernel

Commercial/ Educational/ Research

Priority based

Open specification, User manual

81

C

Renesas IDE

μC-OS/II

Commercial/ Educational/ Research

Priority based

Book

42

C

IAR

EmbOS

Commercial

Priority based

Fee-based

Online documentation

56

C

IAR

Hobby

Priority based

Free for educational and commercial

Online documentation

27

C

None

Salvo

Commercial

Cooperative

Fee-based

Online documentation

31

C

None

TinyOS

Educational/ Research

Cooperative

Free for educational and commercial

Tutorials

N/A

nesC

None

SharcOS

Commercial

Priority based

Fee-based

User manual

N/A

C

None

XMK

Educational/ Research

Priority based

Online documentation (incomplete)

N/A

C

None

Echidna

Educational/ Research

Priority based

Online documentation (incomplete)

18

C

None

eCOS

Commercial/ Educational/ Research

Priority based

Book, Online documentation

N/A

C

None

Erika

Educational/ Research

Priority based

Online documentation

19

C

None

Harlik

Educational/ Research

Priority based

Online documentation

33

C

Keil IDE

KeilOS

Commercial

N/A

C

None

PortOS

Research

N/A

C

None

RTOS

FreeRTOS

Priority based Priority based

Free for educational and commercial Free for educational and commercial

Free for educational and commercial Free for educational and commercial Free for educational and commercial Free for educational and commercial Free for educational and commercial Fee-based Fee-based

Online documentation Online documentation

Tabela 10. Poređenje osnovnih karakteristika RTOS za male mikrokontrolere 39

Tip licence. Ovo je kriterijum za određivanje načina na koji je izvršena distribucija RTOS-a: (1) da li su u pitanju besplatni, (2) oni koji se plaćaju ili (3) RTOS za posebne namene – koji se koriste u edukativne ili komercijalne svrhe. Dokumentacija. Fokus ovog kriterijuma je stavljen na tip dokumentacije dostupan za odgovarajući RTOS (detalji API interfejsa, jednostavno uputstvo, specifikacija ili knjiga). Tabela 10 prikazuje uporedne karakteristike više RTOS, pri čemu može da se uoči nekoliko značajnih sličnosti, ali i korišćenih pristupa: • • •





Većina RTOS-a koristi prioritetno raspoređivanje zadataka (priority-based preemptive scheduling). Samo dva RTOS-a (Salvo i TinyOS) koriste kooperativno raspoređivanje (cooperative scheduling). Većina RTOS-a podržava programski jezik C, koji predstavlja veoma popularan i opravdan izbor prilikom programiranja embedded sistema, a naročito prilikom projektovanja malih sistema. Svega nekoliko RTOS-a u IDE okruženju poseduje podršku za spoznaju sistema: µCOS/II i EmbOS imaju plug-in module za IAR kompajler; KeilOS podržava Keil kompajler; i µITRON i µTKernel podržavaju HEW (Renesas High-Performance Embedded Workshop) kompajler. eCOS RTOS zahteva bootloader (poznat i kao 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. Pojedini RTOS-i (KeilOS, PortOS i XMK) ne prikazuju detalje svojih API interfejsa (označeni su sa „N/A“ u „System call/API richness“ koloni). SharkOS je baziran na µCOS/II, tako da oni koriste iste API interfejse – pa zbog toga neće biti uzeti u obzir prilikom poređenja API interfejsa.

Na Slici 20 prikazano je poređenje broja dostupnih API interfejsa za svaki RTOS. Kategorizovani su, sa odgovarajućim primerima, prema sledećim funkcijama: • • • • • • • •

Upravljanje sistemom: inicijalizovanje operativnog sistema, startovanje i gašenje OS, zaključavanje i otključavanje procesora; Upravljanje prekidima: pristupanje određenoj funkciji i njeno napuštanje, otpočinjanje i završavanje kritične sekcije; Upravljanje zadacima: postavljanje zadatka (create task), brisanje zadatka (delete task), startovanje (start task) i obustavljanje zadatka (terminate task); Sinhronizacija koja zavisi od zadataka: stavljanje zadatka u stanje mirovanja (sleep task), vraćanje zadatka iz stanja mirovanja (wake-up task) i nastavljanje izvršenja zadatka (resume task); Komunikacija i sinhronizacija: semafor, podaci na čekanju (data queue), obeležavanje događaja (event flag), poštansko sanduče (mailbox), muteks (mutex, predstavlja process-wide lock mehanizam) i bafer za poruke (message buffer); Upravljanje memorijom: fiksna i promenjiva veličina memorije; Upravljanje vremenom: dobavljanje sistemskog vremena rada, tajmer operativnog sistema; Pronalaženje API interfejsa: povezati rutinu sa određenom RTOS funkcijom kao što je planer (scheduler).

40

Nekoliko RTOS-a prikazanih u ovom poređenju: µITRON, µTKernel, µC-OS/II i EmbOS – podržavaju unapređene API interfejse za ove kategorije. Većina komercijalnih RTOS-a su vrlo dobro implementirani, sa µITRON RTOS-om koji podržava sve kategorije izuzev funkcija praćenja (trace functions). EmbOS takođe podržava većinu kategorija izuzev funkcije praćenja, funkcije upravljanja sistemskim vremenom i samim sistemom, i memorijskog bafera. Za svaku kategoriju, broj API interfejsa kod navedena četiri RTOS-a dominira – iz razloga što su razvijeni, unapređivani i dugo prisutni na tržištu, za razliku od ostalih RTOS.

Slika 20. Broj API interfejsa za različite RTOS Većina open-source RTOS-a kao što su Free-RTOS, Echidna, Erika i Hartik, imaju minimalnu implementaciju. Ovi RTOS-i su pogodniji za manje sisteme. Međutim, µC-OS/II se izdvaja, jer poseduje veći broj raspoloživih API interfejsa. Ovaj RTOS je prvobitno bio opensource namenjen za ličnu upotrebu i u edukativne svrhe. Njegova stabilnost i popularnost doveli su do njegove komercijalizacije i veoma široke upotrebe. Pored µC-OS/II RTOS-a, µTKernel je sledeći po dostupnosti API interfejsa. Poseduje skoro isti broj API interfejsa kao i komercijalni µITRON RTOS, zato što je podržan od strane T-Engine foruma (http://www.tengine.org), kojeg predvodi Ken Sakamura, glavni projektant µITRON RTOS.

41

Iz navedenih razloga će se u narednim poređenjima i benčmark testiranjima naći samo ova četiri RTOS-a: µITRON, µTKernel , µC-OS/II i EmbOS. Kao dodatak funkcijama navedenim na Slici 20, pojedini RTOS-i podržavaju i sledeće: •

• •



Pojedini sistemski API interfejsi podržavaju timeout, tj. privremeno zaustavljanje toka izvršenja zadatka. Na primer, zadatak može čekati semafor maksimalni broj od n ms. RTOS-i kao što su µITRON i µTKernel poseduju mehanizme koji dopuštaju korisnicima da sami specificiraju vrednost timeout-a u apsolutnim vrednostima. Ostali RTOS-i kao što su µC-OS/II, FreeRTOS, Salvo i EmbOS dopuštaju svojim korisnicima da specificiraju vrednost timeout-a samo u broju ciklusa. Debagovanje API interfejsa dopušta korisničkim aplikacijama da povrate informacije upravljane od strane kernela. Trenutno samo µTKernel podržava ove API interfejse (npr. get task registar i set task registar). Ciklični manipulator (cyclic handler) upućuje RTOS na izvršenje funkcije u periodičnim vremenskim intervalima, dok manipulator alarma (alarm handler) dopušta RTOS-u izvršenje funkcije nakon određenog vremenskog intervala. Ovi API interfejsi su trenutno dostupni samo kod µTKernel i µITRON RTOS-a. „Randevu“ mehanizam omogućuje sinhronizaciju i komunikaciju između zadataka (slično Ada jeziku). I µTKernel i µITRON podržavaju ovaj mehanizam. Nekoliko API obezbeđuju bolju kontrolabilnost i fleksibilnost za µTKernel i µITRON. Table 11. User-controllable parameters for RTOS semaphore creation

μC-OS/II

EmbOS

μTKernel

μITRON

Name/information

Not supported

Not supported

Extended information

Semaphore name

Attributes

Not supported

Not supported

Tasks can be queued in FIFO or priority order

Tasks can be queued in FIFO or priority order

Initial semaphore count

Initial semaphore count

Either the first in the queue or the task with fewer recquests has precedence

Initial semaphore count

Not supported

Not supported

Not supported

Maximum value of semaphore count

Parameters

Initial count

Maximum count

Tabela 11. Parametri za formiranje semafora RTOS-a koje definiše korisnik (projektant, programer) Kao što je prikazano u Tabeli 11, zadaci u µC-OS/II i EmbOS su smešteni u red čekanja u FIFO baferu kada čekaju na semafor, dok projektanti možda i neće promeniti redosled. Međutim, kada se radi o µTKernel i µITRON RTOS-ima, projektanti mogu navesti da li će se zadaci izvršavati po FIFO režimu ili će redosled biti određen prioritetom. Ova fleksibilnost se ne odnosi samo na semafore već i na ostale API interfejse uključujući poštansko sanduče (mailbox), obeležavanje događaja itd. U cilju ostvarivanja ovih ciljeva, u µTKernel i µITRON RTOS-ima projektanti moraju da vrše određene kompenzacije nauštrb eksploatacije memorije i ukupnih performansi sistema. 42

6.3. Testiranje performansi i eksploatacije memorije Izvršen je benčmark program za 4 prethodno navedena RTOS-a, gde su za merenja vremena izvršenja korišćeni osciloskopi i logički analizatori u kombinaciji sa naizmeničnom promenom U/I portova, kako bi se postigla što veća tačnost – jer su vrednosti merenja reda µs. Portovi RTOS-a na M16C/62 platformi

Za ovu evaluaciju (procenjivanje) korišćena je Renesas platforma sa M16C/62P mikrokontrolerom, koja poseduje sledeće karakteristike: • • • • • •

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 16-bitni procesor sa CISC arhitekturom i ukupno dostupnom 91 instrukcijom. Većina instrukcija se izvršava za dva ili tri taktna intervala. Mikrokontroler (MCU jedinica) poseduje četvorostepeni bafer za instrukcije sličan pipeline sistemu uobičajenom kod 32-bitnih procesora. Kako bismo bili sigurni da svi RTOS-i rade na istoj platformi sa istom rezolucijom tajmera, korišćena su određena podešavanja. Prvo, uzeta je taktna rezolucija OS-a za sve RTOS-e iz tajmera A0 mikrokontrolera. Drugo, za kompajliranje (kompilaciju) radnog okruženja korišćena su podrazumevana podešavanja NC30 kompajlera (kompilatora). Zatim, iskorišćeno je originalno radno okruženje µC-OS/II RTOS-a i celokupni kôd sa Micrium-ovog web sajta (http://www.micrium.com). Tajmer A0 je konfigurisan za operativni sistem i izvršeno je ponovno kompajliranje radnog okruženja korišćenjem NC30 alata (verzija 5.43.00). Nakon ovoga su uzeti originalno radno okruženje µTKernel RTOS-a i celokupni kôd sa Renesas-ovog veb sajta (http://www.micrium.com). Tajmer A0 je konfigurisan na 10 ms. Identično je urađeno i u slučaju EmbOS originalnim radnim okruženjem, s tim što su sa Segger-ovog veb sajta (http://www.segger.com) preuzeti samo fajlovi tipa .lib, a ne celokupan kôd. Takođe je izvršeno konfigurisanje tajmera A0 i celokupnog radnog okruženja, s tim što nije uzeto u razmatranje da li su .lib fajlovi već bili kompajlirani pomoću ranije verzije NC30 alata ili koristeći drugačija podešavanja za optimizaciju. Ovo znači da se podešavanja kompajlera za EmbOS RTOS mogu razlikovati od onih za µTKernel i µC-OS/II RTOS-e. Nakon generisanja µITRON radnog okruženja, .lib fajlova i konfigurisanja tajmera A0, izvršeno je kompajliranje celokupnog radnog okruženja (izuzev .lib fajlova) koristeći NC30. Ovo je slično kao kod EmbOS RTOS-a jer je operativni sistem ditribuiran u vidu .lib fajlova. Dalje, podešavanja kompajlera prilikom generisanja .lib fajlova se mogu razlikovati od podešavanja kod µTKernel i µC-OS/II RTOS-a. Korišćen je isti obim magacinske (stack) memorije po zadatku za sve RTOS-e. Na kraju, ukoliko se određena funkcija RTOS-a ne koristi, onda biva onesposobljena. Međutim, u slučaju µITRON RTOS-a nekorišćene funkcije nisu isključene, jer se sistemski pozivi pobuđuju putem softverskih prekida. U Tabeli 12 su prikazane određene razlike u implementaciji sistemskih poziva servisa i kritičnih sekcija RTOS-a. 43

Kad god µC-OS/II i EmbOS izdaju sistemski poziv, oni pozivaju tu funkciju direktno iz korisničkog zadatka. Prednost se ogleda u tome što se funkcija izvršava skoro trenutno, a nedostatak je što poziv servisa za izvršenje koristi trenutni stack zadatka. Kada µITRON i µTKernel izdaju sistemski poziv, on podiže nemaskirani prekid (INT instrukcija kod M16C/62P). Dakle, trenutni cilj izvršenja je da se promeni kernel prostor, kako bi se izvršio sistemski poziv. Prednost korišćenja ovog pristupa je u tome što sistemski poziv neće da koristi magacin zadatka koji se trenutno izvršava, a nedostatak mu je što će sistemski poziv da izazove određeno vremensko kašnjenje. Tabela 12 takođe prikazuje različite metode za implementiranje kritične sekcije. Kako bi pokrenuo kritičnu sekciju, µC-OS/II onemogućuje sve prekide – tako da nijedan spoljni prekid neće biti prihvaćen. Ovime se omogućava bezbedno izvršenje kritične sekcije od početka do kraja bez ikakvih intervencija, ali i navodi da sistem neće biti u mogućnosti da prihvati ni neke prekide od veoma velike važnosti tokom ovog perioda. µITRON i µTKernel implementiraju kritični sekciju podizanjem nivoa maske prekida, tako da kritični prekid može da bude prihvaćen sve dok se manipulator prekidima ne umeša u interne promenjive RTOS-a. Što se EmbOS sistema tiče, on ne onemogućava niti podiže nivo maske prekida za kritičnu sekciju, tako da svaki prekid može da bude prihvaćen i njime se može upravljati tokom kritične sekcije. Međutim, EmbOS sistem zahteva i dodatni kôd za upravljanje internim promenjivima kritične sekcije. Table 12. System service call implementation and critical section implementation Call

μC-OS/II

μTKernel

EmbOS

μITRON

Service call

Direct call

Using software interrupt

Direct call

Using software interrupt

Critical section

Disable all interrupts

Raise interrupt mask level to level 4

Don't disable any interrupt (based on an internal variable)

Raise interrupt mask level to level 4

Tabela 12. Implementacije sistemskih servisnih poziva i kritičnih sekcija

6.4. Benčmark (benchmark) kriterijumi Jedan od ciljeva ovog benčmark (benchmark) kriterijuma je da budu kompatibilni sa različitim platformama. Za svaki kriterijum su prikupljeni podaci o vremenu izvršenja zadatka i eksploataciji memorije (RAM i ROM/flash).

Vreme prelaska (komutacije) između dva zadataka (Task switching time). Ovo je vreme potrebno RTOS-u da trenutni kontekst izvršenja (execution context) prebaci sa jednog zadatka na drugi. Na Slici 21a prikazan je metod merenja. Metod uključuje dva zadatka, zadatak 1 i zadatak 2, gde zadatak 1 ima viši prioritet. Svaki RTOS mora prvo izvršiti zadatak 1 koji posle prelazi u stanje mirovanja (sleep state) ili neaktivno stanje (inactive state). Kontekst izvršenja se nakon ovog prebacuje na zadatak 2. Zadatak 2 aktivira tj. podiže iz stanja mirovanja zadatak 1. Odmah po podizanju iz stanja mirovanja, kontekst izvršenja se prebacuje nazad na zadatak 1, jer on ima viši prioritet. Različiti RTOS-i koriste različite termine za opisivanje odgovarajućih stanja kao što su sleep, inactive and ready i active (npr. µC-OS/II i EmbOS sistemi koriste suspend i resume, dok µITRON i µTKernel koriste sleep i wake-up). Tabela 12 prikazuje sistemske pozive korišćene u svakom od pomenutih RTOS-a 44

Zadatak 1: (Viši prioritet)

Zadatak 2:

„Miruj” (Go to sleep) (B)

(A) Podizanje (Wake-up) Zadatka 1

Vreme za promenu zadatka: vreme od (A) do (B) (a)

Zadatak 1: (Viši prioritet)

Zadatak 2:

Zauzmi semafor (unesi u red čekanja) (B)

(A) Oslobodi semafor

Vreme prelaska semafora od Zadatka1 na Zadatak2: (A) do (B) (c)

Zadatak 1: (Viši prioritet)

Zadatak 2:

Povraćaj poruke iz reda čekanja

(A) Vraća poruku u red čekanja

(B) Vreme za prosleđivanje poruke sa Zad. 2 na Zad. 1: (A) do (B) (e)

Zadatak 1: (Viši prioritet)

Zadatak 2:

„Miruj”

Procesiranje

(B)

...

Zadatak 1: (A) Zauzmi semafor (Get semaphore) (B) Oslobodi semafor (Release semaphore) (C) Vreme za dobijanje semafora: (A) do (B) Vreme za oslobađanje semafora: (B) do (C) (b)

Zadatak 1: (A) Prosledi poruku u red čekanja (B) Povraćaj poruke iz istog reda čekanja (C) Vreme za smeštanje poruke u red čekanja: (A) do (B) Vreme za povraćaj poruke iz reda čekanja: (B) do (C) (d)

Zadatak 1: (A) Zahteva memorijski blok fiksne veličine (B) Oslobađa memorijski blok fiksne veličine (C) Vreme za dobijanje memorijskog bloka: (A) do (B) Vreme za oslobađanje memorijskog bloka: (B) do (C) (f)

Prekid (Interrupt) Procesiranje (A) Podizanje Zadatka 1

Procesiranje Vreme za koje manipulator prekidima izvrši buđenje zadatka iz stanja mirovanja: (A) do (B) (g)

Slika 21. Merenja benčmark kriterijuma: vreme prelaska između zadataka (a), upravljanje vremenom semafora (b), prelazno vreme semafora (c), vreme prosleđivanje/pretraživanje poruke (d), vreme za razmenu poruke (e), vreme za dobijanje/oslobađanje memorije fiksne veličine (f), aktiviranje zadatka u toku vremena za upravljanje prekidima (g) 45

Vreme zauzimanja/oslobađanja semafora (Get/release semaphore time). RTOS često koriste semafore za sinhronizaciju asemblerskih funkcija. Za testiranje performansi semafora meri se vreme potrebno za zauzimanje i oslobođanje semafora, kao i vreme potrebno za prelazak sa jednog zadatka na drugi. Na Slici 21b su rezultati ovih merenja. Ovde postoji samo jedan zadatak (zadatak 1) i jedan binarni semafor sa početnom vrednošću 1. Zadatak 1 dobija i nakon toga oslobađa semafor. Različiti RTOS-i koriste različite termine za opisivanje ovog procesa. Tabela 13 prikazuje spisak korišćenih API interfejsa od strane različitih RTOS-a. Table 13. APIs used for the task switch time benchmark Table 14. APIs used for get/release semaphore benchmark Table 15. APIs used for the message-passing benchmark

μC-OS/II

μTKernel

EmbOS

μITRON

Pass message

OSTask_Suspend()

tk_slp_tsk()

OS_Suspend()

slp_tsk()

Retrieve message

OSTask_Resume()

tk_wup_tsk()

OS_Resume()

wup_tsk()

Get semaphore

OSSemPend()

tk_wai_sem()

OS_WaitCSema()

wai_sem()

Release semaphore

OSSemPost()

tk_sig_sem()

OS_SignalCSema()

signal_sem()

Pass message API

OSQPost()

tk_snd_mbx()

OS_Q_Put()

snd_mbx()

Retrieve message API

OSQPend()

tk_rcv_mbx()

OS_Q_GetPtr()

rcv_mbx()

API

T13

T14

T15

Tabele 13-15. Korišćenje API interfejsa od strane različitih RTOS-a pri merenju: prelaznog vremena između zadataka (T13), vremena zauzimanja/oslobađanja semafora (T14), vremena za razmenu poruke (T15),

Prelazno vreme semafora (Semaphore-passing time). Kako bi se odredio učinak prelaska semafora koristi se metod prikazan na Slici 21b. Ovo merenje uključuje dva zadatka, zadatak 1 i zadatak 2, gde zadatak 1 ima viši prioritet, i jedan binarni semafor sa početnom vrednošću 0. Sistem izvršava zadatak 1, koji pokušava da zauzme semafor. Pošto je vrednost semafora 0, zadatak 1 ulazi u stanje mirovanja ili neaktivno stanje (sleep or inactive state) čekajući na oslobađanje semafora. Trenutni kontekst izvršenja se zatim prebacuje na zadatak 2, što oslobađa semafor. Jedanput kada je oslobođen, semafor podiže iz stanja mirovanja zadatak 1 i kontekst izvršenja se prebacuje nazad na zadatak 1. Vreme razmene/prijema poruke (Pass/Receive message time). Kao dodatak semaforima, razmena poruka (message passing) je postalo veoma popularno za sinhronizaciju. Ovo merenje koristi mehanizam za razmenu poruka (message passing mechanism) zasnovan na razmeni pokazivača (pointer-a) memorije. On ne kopira poruku unutar RTOS-a, jer ne podržavaju svi RTOS-i ovaj pristup. Način odvijanja ovog merenja prikazan je na Slici 21d. Merenje uključuje samo jedan zadatak (zadatak 1) koji najpre prosleđuje pokazivač memorije, a zatim vrši njegov povraćaj. U Tabeli 16 su prikazani API interfejsi upotrebljeni u svakom RTOS-u. 46

Vreme za razmenu poruka između zadataka (Intertask message-passing time). Na Slici 21e je ilustrovan način na koji se vrši merenje vremena za razmenu poruka između zadataka. I ovo merenje uključuje dva zadatka, zadatak 1 i zadatak 2, gde zadatak 1 ima viši prioritet. Najpre se izvršava zadatak 1 i onda pokušava da izvrši povraćaj pokazivača (pointer-a) memorije iz reda čekanja. Pošto još uvek nijedna poruka nije dostupna, zadatak 1 ulazi u stanje mirovanja ili neaktivno stanje, i čeka novu poruku. Trenutni kontekst izvršenja se prebacuje na zadatak 2, koji postavlja novu poruku u red čekanja čime se zadatak 1 podiže iz stanja mirovanja i kontekst izvršenja se prebacuje nazad na zadatak 1. Razlika između ovog testiranja i testiranja vremena za prosleđivanje/primanje poruka je u tome što ovaj metod uključuje vreme prekoračenja RTOS-a za procesiranje poruka iz reda čekanja i ponovno podizanje („buđenje”) zadatka iz stanja mirovanja. Vreme za dodeljivanje/oslobađanje memorije fiksne veličine. U RTOS-ima se po pravilu treba dodeljivati samo dinamička memorija fiksne veličine. Vreme dodeljivanja i oduzimanja memorijskog prostora mora biti tačno određeno. Slika 21f prikazuje način merenja vremena za dobijanje i oslobađanje memorijskog bloka fiksne veličine. Ovo merenje podrazumeva samo jedan zadatak. Zadatak 1 dobija memorijski blok veličine 128 B a zatim ga otpušta (oslobađa). Tabela 17 prikazuje API interfejse upotrebljene u ovom procesu. Table 16. APIs used for the fixed-size memory benchmark Table 17. APIs for the task activation from within interrupt handler benchmark

μC-OS/II

μTKernel

EmbOS

μITRON

Acquire fixed-size block API

OSMemGet()

tk_get_mpf()

OS_MEMF_Alloc()

get_mpf()

Release fixed-size block API

OSMemPut()

tk_rel_mpf()

OS_MEMF_Release()

rel_mpf()

Go to sleep API

OSTaskSuspend()

tk_slp_tsk()

OS_Suspend()

slp_tsk()

Resume from interrupt API

OSTaskResume ()

tk_wup_tsk()

OS_Resume()

iwup_tsk()

API

T16

T17

Tabele 16-17. Korišćenje API interfejsa od strane različitih RTOS-a pri merenju: vremena za dodeljivanje/oduzimanje memorije fiksne veličine (T16) i aktiviranja zadatka u toku perioda za manipulaciju prekidima (T17)

Aktiviranje zadatka u toku perioda za upravljanje (manipulaciju) prekidima. RTOS-i moraju da se izbore sa spoljnim prekidima, koji u bilo kom trenutku mogu da zahtevaju određenu verifikaciju (potvrdu). Ovo će obično da održava izvršenje manipulatora prekidima (interrupt handler) što je moguće kraćim kako bi se izbegli bilo kakvi uticaji na odziv sistema. U slučaju da prekid zahteva dugo procesiranje, manipulator prekidima može da aktivira drugi zadatak kako bi se izvršilo potrebno procesiranje. Vreme od trenutka kada manipulator (handler) nastavi sa izvršenjem zadatka do trenutka završetka izvršenja zadatka je od ključnog značaja za projektovanje sistema.

47

Slika 22. Poređenje benčmarka za četiri RTOS: veličina programskog kôda smeštenog u ROM/flash memoriji (a) i veličina operativnih podataka smeštenih u RAM memoriji (b) Slika 21g prikazuje merna podešavanja koja podrazumevaju dva zadatka, zadatak 1 i zadatak 2, gde zadatak 1 ima viši prioritet i jedan spoljni prekid sa odgovarajućim manipulatorom (handler-om). Najpre se izvršava zadatak 1, koji nakom pokretanja ulazi u stanje mirovanja ili neaktivno stanje, a trenutni kontekst izvršenja se prebacuje na zadatak 2. Zadatak 2 se odvija u kontinuitetu do pojave spoljnjeg prekida, kada manipulator prekidima nastavlja sa 48

izvršenjem zadatka 1. Kontekst izvršenja se prebacuje na zadatak 1. U Tabeli 17 su prikazani API interfejsi upotrebljeni u svakom od RTOS-a.

Rezultati benčmark programa. Za svaki kriterijum je sastavljen benčmark kôd i preuzeto iskorišćenje RAM i ROM/flash memorije iz toolchain izveštaja (toolchain – sistem alata). Uzimanjem u obzir informacije o ROM/flash memoriji iz svih kriterijuma testa, došlo se do optimalne veličine ROM/flash memorije. Na Slici 22a su prikazane veličine kôda za četiri RTOS-a pri primeni sedam benčmark testova. Kao što se vidi sa pomenute slike, µTKernel ima obimniju veličinu kôda, što je posledica njegove API fleksibilnosti i obimne podrške. Komercijalni µITRON i EmbOS nude relativno kompaktniju veličinu kôda. Uprkos svemu ovom sva četiri RTOS-a se veoma dobro uklapaju u mikrokontrolere sa ograničenom veličinom ROM/flash memorije. Slika 22b prikazuje informacije o RAM memoriji ova četiri RTOS-a. µITRON i µTKernel sistemi imaju relativno slabiju eksploataciju (korišćenje) RAM memorije, dok µC-OS/II i EmbOS imaju nešto izraženiju eksploataciju RAM memorije. Kako je i predviđeno benčmark testovima, postavljeni su isti broj zadataka, veličina magacinske (stack) memorije i broj objekata za sve RTOS-e. Količina RAM-a se razlikuje među RTOS u opsegu od 7 B do 10 B, što je posledica unutrašnjih implementacija ili pristupa projektovanja API interfejsa. Na kraju, može da se zaključi kako su ovi RTOS-i pogodni za male mikrokontrolere u pogledu eksploatacije RAM i ROM/flash memorije. Međutim, µITRON poseduje optimalni odnos između eksploatacije i RAM i ROM/flash memorije. Vreme izvršenja. Na Slici 23 je prikazano merenje vremena izvršenja kod RTOS-a sa različitim benčmark kriterijumima. Pošto je tajmer prekida jedina veličina u sistemu koja se menja, svaki benčmark test je izvršen najmanje dva puta kako bi dobijeni rezultati bili pouzdani mada je u normalnim uslovima dovoljno sve benčmark testove sprovesti samo jedanput. Za aktiviranje zadatka iz benčmarka za manipulator prekidima, spoljni prekid predstavlja još jednu dodatnu promenjivu. U toku ovog testiranja spoljni prekid može (ali i ne mora!) da zatraži potvrdu tokom kritčne sekcije sistema. Ukoliko dođe do potvrde, vreme odziva operativnog sistema (OS) će biti nešto duže od očekivanog. Dakle, ovo merenje možda i ne uključuje najgori slučaj. Kao što je prikazano na Slici 23, µTKernel ima najmanje vreme prebacivanja (komutacije) zadatka (task-switching time), a zatim ga slede µITRON, µC-OS/II i EmbOS. Takođe se sa iste slike vidi da µC-OS/II poseduje najbrža vremena za zauzimanje i otpuštanje semafora. Što se tiče memorije, uošava se da µC-OS/II poseduje najbolje vreme izvršenja, a slede ga EmbOS, µITRON i µTKernel RTOS-i. I na samom kraju, µ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. Kao što rezultati svih ovih testova prikazuju, svaki RTOS ima svoje prednosti i nedostatke. 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. S druge strane, ukoliko projektanti/programeri preferiraju komercijalni RTOS, preporučeno je da koriste µITRON ili EmbOS – gde µITRON poseduje nešto nižu eksploataciju RAM memorije. Predstavljeni testovi za ocenu performansi su bili veoma jednostavni i pokazali su kako svaki od RTOS poseduje određene prednosti i mane, tako da među njima ne postoji apsolutni pobednik. Međutim, na osnovu rezultata testiranje, potencijalni korisnici RTOS-a (projektanti, programeri) mogu u velikoj meri da pojednostave svoj izbor ispitivanjem određenih zahteva za pojedinim aplikacijama. 49

Slika 23. Vreme izvršenja benčmarka (u μs) za četiri RTOS-a

50

7. Zaključak Korišćenje RTOS u malim (small-scale) embedded sistemima ima izvesne nedostatke (angažuju se resursi mikrokontrolera i na taj način redukuju njegove performanse), ali i brojne prednosti. Konkretno, RTOS obezbeđuju kvalitetniju i bezbedniju sinhronizaciju, jer mali embedded sistemi bez RTOS često koriste globalne varijable za sinhronizaciju i komunikaciju između modula i funkcija. Međutim, korišćenje globalnih varijabli može da dovede pojave grešaka u izvršenju programa. Što je program obimniji, ove greške su „dublje" skrivene. Kod embedded sistema sa RTOS-om, zadaci mogu bezbedno da razmenjuju poruke (message passing) ili da sinhronizuju jedni druge, bez opasnosti od pomenute korupcije. Prilikom projektovanja malih embedded sistema kao kritičan parametar se izdvaja cena hardvera. Zbog toga je značajno imati razvijen RTOS, koji je prilagodljiv za različite hardverske platforme uz male modifikacije. Izbor RTOS za konkretnu aplikaciju može da se zasniva na različitim kriterijumima (jezička podrška, bogatstvo API interfejsa, eksploatacija RAM i ROM/flash memorije, tehnička podrška...), ali se kao kriterijum izdvaja sposobnost za rad u realnom vremenu (real-time capability). Sposobnost sistema u stvari opisuje da li je sistem u stanju da ispuni zadate vremenske rokove. Upotrebom RTOS-a zauzimaju se ciklusi procesora, međutim RTOS-i svakako ne smeju da imaju nepredvidljivo (nedeterminističko) ponašanje. Broj korišćenih ciklusa mikroprocesora (CPU) i vreme utrošeno od strane RTOS-a bi trebalo da budu merljivi i vrednosti koja je prihvatljiva za projektante sistema. Pored korišćenja CPU ciklusa, RTOS koriste i prostor RAM i ROM/flash memorije, što bi moglo da dovede do povećanja veličine navedenih memorija za celokupni sistem. Uvek postoji određena ravnoteža između eksploatacije (iskorišćenja) memorije i funkcionalnih zahteva RTOS-a. Moćniji i pouzdaniji API interfejsi uglavnom zahtevaju više linija kôda. 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 promene (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 RTOS-i, µ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.

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

51

Reference [1] „Embedded sistemi“ (on-line literatura), Prof. dr Mile K. Stojčev; Elektronski fakultet Niš, es.elfak.ni.ac.rs , [2] „Sistemi u realnom vremenu“ (on-line beleške sa predavanja), Doc. dr Ivan Popović, Elektrotehnički fakultet Beograd, http://tnt.etf.rs/~oe4srv/index.html [3] „Uvod u Real-time sisteme“ (on-line literatura), Prof. dr Branislav Petrović, Elektronski fakutet Niš, es.elfak.ni.ac.rs , [4] „Vezni igrač“ (on-line članak), Stevan Tošić, magazin Mikroelektronika, http://www.mikroe.com/sr/magazine/1broj/1broj9.htm [5] „Ugrađeni mrežni uređaji“ (on-line članak), Nikola Milanović, Goran Timotić, Marko Ribarić, CET, www.cet.rs/cetcitaliste/CitalisteTekstovi/352.pdf [6] „Real-Time Operating Systems for Small Microcontrollers“, Tran Nguyen, Bao Anh, Su-Lim Tan, IEEE Micro, September/October 2009, pp. 30–45 [7] „RTOS Acceleration Techniques – Review and Challenges“ (on-line članak), M. Sindhwani, T. F. Oliver, D. L. Maskell And T. Srikanthan, Centre for High Performance Embedded Systems Nanyang, Technological University, Singapore www.linuxfordevices.com/files/rtlws-2004/MohitSindhwani-Accel.pdf

52

Podaci o autoru

Ime Prezime Datum rođenja Adresa stanovanja E-mail adrese Obrazovanje Stepen stručne spreme Smer na doktorskim studijama Poznavanje jezika Poznavanje softvera Interesovanja Sposobnosti Radni odnos

Dejan Barać 6. januar 1978.g. Mkranjčeva 94/14, Niš [email protected], [email protected] dipl. ing. el. VII-1 Elektronika i mikroračunarska tehnika Engleski (dobro), Francuski (osnovno) PROTEL, mikroC, Java ME, CorelDRAW , ACDSee ... Programiranje, projektovanje PCB, projektovanje elek. sistema; beletristika... Istrajnost, samouverenost, komunikativnost ... Projektant hardvera u firmi „Ei Informatika“ iz Niša.

53