sustav za ispitivanje odziva na - bib.irb.hr · isprojektirati da bude pouzdaniji. primjeri ovakvih...
TRANSCRIPT
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
Zagreb, lipanj 2018.
DIPLOMSKI RAD br. 1649
SUSTAV ZA ISPITIVANJE ODZIVA NA
VANJSKI DOGAĐAJ ZA OPERACIJSKE
SUSTAVE NAMIJENJENE UGRADBENIM
RAČUNALIMA
Roko Lisica
Diplomski rad je izrađen u okviru suradnje Sveučilišta u Zagrebu, Fakulteta
elektrotehnike i računarstva i Ericsson Nikole Tesle d.d. na istraživačko-razvojnom
projektu „Poboljšanje karakteristika rada LTE radio pristupnih uređaja“
(Improvements for LTE radio access equipment – ILTERA)
i
SADRŽAJ
1. Uvod .......................................................................................................... 1
2. Sustavi za rad u stvarnom vremenu ...................................................... 2
2.1. Operacijski sustav Linux na ugradbenim računalima ......................... 3
2.2. Operacijski sustavi za rad u stvarnom vremenu ................................ 5
3. Mjerni i ispitivani sustav ......................................................................... 6
3.1. Opis ispitivanog sustava .................................................................... 6
3.2. Opis mjernog sustava ........................................................................ 9
3.2.1. Osnovno mjerenje ..............................................................................10
3.2.2. Mjerenje s oznakom događaja ............................................................13
3.3. Metodologija mjerenja ...................................................................... 17
3.4. Verifikacija mjernog sustava ............................................................ 17
4. Značajni parametri ispitivanog sustava i rezultati mjerenja .............. 21
4.1. Različite izvedbe u korisničkom načinu rada ................................... 21
4.2. Jezgreni način rada ......................................................................... 26
4.3. Postavke jezgre ............................................................................... 30
4.4. Vanjski dodaci za operacijski sustav ................................................ 32
4.5. Različite frekvencije rada jezgre ...................................................... 34
4.6. Različiti operacijski sustav ............................................................... 35
5. Zaključak ................................................................................................ 42
Literatura......................................................................................................... 43
Sažetak ............................................................................................................ 45
Summary ......................................................................................................... 46
PRIVITAK A: Tablice svih mjerenja .............................................................. 47
1
1. UVOD
Porastom broja ugradbenih računala u profesionalnoj i osobnoj upotrebi, sve više
se raspravlja o tome kako razvoj programske potpore za takva računala učinitim
što jednostavnijim. Raspberry Pi i njegov operacijski sustav Raspbian temeljen
na Linux jezgri programeru pružaju poznato okruženje za razvoj i testiranje, s
velikom postojećom kodnom bazom. Međutim, treba se zapitati koje su granice
takvog sustava, dodaje li Linux trošak resursa koji može biti ograničavajući faktor
na moguće primjene sustava.
Zanimljiva stavka je rad u stvarnom vremenu. Linux ekosustav se dugo pokušava
prilagoditi potrebama te primjene, i po nekima, taj cilj je već dostignut. Ovaj rad
ispituje istinitost te tvrdnje sa stanovišta kašnjenja odziva računalnog sustava na
vanjsku pobudu. Ta kašnjenja mogu biti ocjena projektantu je li računalni sustav
primjeren za rad u stvarnom vremenu u kojem su radnje okinute vanjskim
događajima.
U prvom poglavlju razrade dan je uvod o problematici sustava za rad u stvarnom
vremenu te operacijskih sustava koji se koriste za tu primjenu. Nakon toga dan
je detaljan opis ispitnog sustava, koje veličine se mjere i na koji način. Kad je
mjerni sustav definiran može se početi s mjerenjem. U sljedećem poglavlju
definirani su određeni parametri sustav čiji nas utjecaj zanima, dana su
predviđanja utjecaja tih parametara, rezultati mjerenja te zaključci o rezultatima.
Kao sklopovska platforma ispitivanog sustava koristio se isključivo Raspberry Pi,
dok su se s programske strane koristili operacijski sustavi Linux i FreeRTOS.
2
2. SUSTAVI ZA RAD U STVARNOM VREMENU
Sustavi za rad u stvarnom vremenu (eng. real-time systems), najopćenitije
definirano, su „sustavi kod kojih je osim logičke ispravnosti još bitnija vremenska
ispravnost“ (Jelenković, 2016.)[1]. Drugačije rečeno, to su sustavi kod kojih se
razlika između ispravnog, degradiranog i neispravnog rada može svoditi na male
razlike u kašnjenju neke radnje koju sustav mora obaviti. Sustavi za rad u
stvarnom vremenu (SRSV) imaju definirana najveća dopuštena kašnjenja koja
smiju imati njihove radnje, a da se pritom smatra da sustav radi ispravno. Radnje
sustava mogu biti okidane vanjskim događajima (engl. event triggered systems)
ili okidane protokom vremena (engl. time triggered systems). Ovisno o tome
kakve su posljedice kad se dopuštena kašnjenja prekorače, SRSV-i najčešće se
dijele na stroge (engl. hard real-time) i blage (engl. soft real-time).
Kod strogih SRSV-a prekoračenje dopuštenog kašnjenja dovodi do potpuno
neispravnog ponašanja te uzrokuje štetu od koje nema oporavka. Šteta može biti
materijalna, kao kod požara ili poplave proizvodnog postrojenja. U najgorem
slučaju, vremenska neispravnost sustava može biti i štetna po zdravlje ili dovesti
ljude u životnu opasnost. Kod takvih sustava nužno je da se vremenska
ispravnost ispoštuje pod svaku cijenu. Ako se pri verifikaciji utvrdi i najmanja
mogućnost vremenske neispravnosti, sustav nije spreman za rad i mora se
isprojektirati da bude pouzdaniji. Primjeri ovakvih sustava bi bili elektrostimulator
srca (pacemaker) i kontrola motora u motornim vozilima.
U suprotnosti sa strogima, blagi SRSV-i su oni kod kojih kašnjenje veće od
definiranog ne uzrokuje prestanak rada sustava ni nepopravljivu grešku već
degradira kvalitetu sustava. Preveliko kašnjenje uzrokuje štetu koja je njemu
razmjerna i treba ga izbjegavati, ali ta šteta nije nedopustiva. Šteta u ovom
slučaju može biti materijalna, ali može biti i takva da ne uzrokuje trenutne
materijalne posljedice. Primjeri ovakvih sustava bili bi sustav koji minimizira
potrošnju električne energije ili uređaj za reprodukciju video sadržaja. Slika 2.1
pokazuje odnos kašnjenja radnje i njezine korisnosti kod strogih i blagih SRSV-
a, pri čemu je tKZ unaprijed određeno dopušteno kašnjenje te radnje.
3
Slika 2.1 Usporedba strogih i blagih (ublaženih) SRSV-a [1]
Uz strogi i blage, u literaturi se spominju i čvrsti SRSV-i (engl. firm real-time) kod
kojih je dopušten određen broj prekoračenja, ali prečesta prekoračenja mogu
uzrokovati neoporavljivu grešku [1].
Kako bi se projektirali sustavi koji zadovoljavaju određena vremenska svojstva,
potrebno je detaljno ispitati i verificirati pojedine dijelove sustava, kao i sustav u
cijelosti. Idealni slučaj za neku radnju je kad je njeno kašnjenje determinističko,
tj. ne ovisi o stohastičkim, nepredvidivim faktorima. Ako je opterećenje sustava
uzrokovano brojem zadataka koji su mu došli na obradu, a oni dolaze u
nasumičnim vremenskim trenucima, tada je nemoguće predvidjeti koliko će
opterećenje sustava biti u svakom trenutku rada. Stoga je kašnjenje pod
utjecajem opterećenja sustava nedeterminističko. Kad radnje imaju
nedeterminističko kašnjenje, potrebno je utvrditi najgore i prosječne očekivane
slučajeve. Kod strogih SRSV-a od najveće važnosti su najgori slučajevi. Ako neki
element sustava ne zadovoljava vremenske kriterije za najgori očekivani slučaj,
onda uopće nije spreman za rad unutar sustava. Primjerice, tu se bilježe najveće
kašnjenje, najduža obrada informacije, najveći broj propuštenih očitanja i slično.
Kod blagih SRSV-a, rijetki najgori slučajevi možda manje utječu na kvalitetu
sustava nego „normalni“ učestali slučajevi pa tu mogu biti zanimljive i neke
prosječne vrijednosti, odstupanja od tih vrijednosti te učestalost suboptimalnih
slučajeva.
2.1. Operacijski sustav Linux na ugradbenim računalima
Linux je operacijski sustav opće namjene nazvan po istoimenoj jezgri koju koristi.
Osim jezgre, operacijski sustav uključuje velik broj biblioteka i alata razvijenih u
4
sklopu GNU projekta, pa se ponekad naziva i GNU/Linux. Napravljen je po uzoru
na stariji operacijski sustav UNIX. Iako je izvorno zamišljen za upotrebu na
osobnim računalima, danas je GNU/Linux vodeći poslužiteljski operacijski sustav
[2], kao i jedan od vodećih operacijskih sustava za ugradbena računala [3]. Jedan
od većih u tom području je i operacijski sustav Android, koji također koristi Linux
jezgru.
Popularnost Linuxa u području ugradbenih računala potaknuta je nizom faktora
koji uključuju: podršku velikog broja sklopovskih platformi, besplatno korištenje,
javno dostupan izvorni kod, visoku razinu prilagodbe te raširenost u drugim
segmentima tržišta. Linux se u tom području najčešće koristi u kombinaciji s ARM
procesorom, a uz upotrebu brojnih njegovih upravljačkih programa mogu se
pokriti vrlo raznolike kombinacije perifernih uređaja. Jedna od prednosti Linuxa u
odnosu na neki operacijski sustav koji je specijaliziran za rad na ugradbenim
računalima je njegova postojeća kodna baza. Naime, računalo s Linuxom može
koristiti većinu postojećih programa, i uz pomoć njih, obavljati puno složenije
zadatke bez potrebe za ponovnim razvojem tih funkcionalnosti.
Unatoč širokoj upotrebi Linuxa za ugradbena računala, dugo se nije smatrao kao
operacijski sustav primjeren za rad u stvarnom vremenu. Glavni njegov problem
bio je nemogućnost prekidanja rada sustava dok se on nalazi unutar jezgrine
funkcije, zbog čega se obrada vanjskog događaja može naći na čekanju. To
čekanje unosi kašnjenje pri odgovaranju na vanjsku pobudu. Uz pretpostavku
normalnog rada Linuxa, pojavljivanje kašnjenja je nepredvidivo, kao i njegova
duljina. Zbog svega toga može biti teško na takav sustav postaviti neke stroge
vremenske kriterije. Veliki napredak napravljen je 2011. godine, kad je iz jezgre
uklonjen tzv. veliki jezgreni monitor (engl. big kernel lock) koji je sprječavao
istovremeno izvršavanje bilo kojih jezgrinih funkcija. Umjesto toga, uvedeni su
manji, finiji monitori, koji dopuštaju veću razinu paralelizma.
Osim napretka kod službene Linux jezgre, pojavilo se rješenje u vidu vanjskih
dodatka za jezgru koji omogućuju rad u stvarnom vremenu. PREEMPT_RT
dodatak ima za cilj upravo to, ima velik broj korisnika, a mnoge njegove promjene
uključene su i u glavnu jezgru.
5
2.2. Operacijski sustavi za rad u stvarnom vremenu
Neki operacijski sustavi posebno su namijenjeni i dizajnirani za rad u stvarnom
vremenu. Njihova primjena pokriva slučajeve kada postoje zahtjevi za
višezadaćnost u sustavu, a operacijski sustavi opće namjene nisu u stanju
pouzdano zadovoljiti vremenske kriterije. Ovakvi operacijski sustavi imaju
posebno dizajnirane jezgrine mehanizme takve da se minimizira kašnjenje i
maksimizira determinizam pri njihovom korištenju. Minimiziranje kašnjenja često
dolazi na štetu propusnosti, odnosno količine posla kojeg je sustav u stanju
obaviti u jedinici vremena. U pravilu, ovi operacijski sustavi imaju manji
memorijski trošak i jednostavniji su, a programi koji se razvijaju za njih imaju
izravniju interakciju sa sklopovljem.
Neki od najčešće korištenih operacijskih sustava za rad u stvarnom vremenu su
FreeRTOS, VxWorks, QNX i eCos. FreeRTOS i eCos su besplatni za korištenje,
te imaju javno dostupan kod, dok su VxWorks i QNX komercijalni sa zatvorenim
kodom. Kod FreeRTOS je dijeljen uz najblaže restrikcije, pa je popularan za
akademske svrhe i privatnu upotrebu.
FreeRTOS je operacijski sustav s izrazito malom jezgrom izveden većinom u
programskom jeziku C. Većina funkcionalnosti jezgre tiču se raspoređivanja i
međusobnog isključivanja dretvi. Jezgra ima mnoštvo opcija koje se mogu
konfigurirati pri prevođenju. S obzirom da se većinom koristi na procesorima koji
nemaju funkcionalnost odvajanja jezgrine i korisničke memorije, FreeRTOS radi
puno manju distinkciju između jezgrinog i korisničkog načina rada. Također,
nema ugrađenu funkcionalnost za dinamičko učitavanje korisničkih programa već
se oni prevode zajedno s jezgrom.
6
3. MJERNI I ISPITIVANI SUSTAV
U sklopu ovog rada mjereno je koliko vremena prođe od trenutka kad računalni
sustav primi logičku nulu ili jedinicu na jedan od svojih ulaznih pinova, do trenutka
kad isti sustav odgovori jednakom logičkom vrijednošću na jednom od svojih
izlaznih pinova. Koristi se nekoliko načina detekcije i odgovora na pobudu, uz
različite konfiguracije sustava te se uspoređuju njihova vremenska svojstva.
3.1. Opis ispitivanog sustava
Računalni sustav koji se ispituje mora pokretati operacijski sustav Linux, imati
pinove za višestruke namjene (engl. general purpose input/output, GPIO) za
primanje pobude i davanje odgovora, a treba moći pokrenuti i neki operacijski
sustav za rad u stvarnom vremenu s kojim se Linux može usporediti. Na tržištu
postoji cijelo mnoštvo razvojnih pločica/računala koji dolaze s predinstaliranim
Linuxom. Većina tih razvojnih pločica bazirana je na ARM procesorima. Neke od
popularnijih serija pločica su npr. Raspberry Pi, Odriod, BeagleBone i
PandaBoard, svaki od kojih ima više modela s različitim perifernim sklopovljem i
procesorima. Raspberry Pi je najpopularniji po mnogim metrikama. Osim nekih
dijelova pločice koje proizvode vanjski proizvođači, dizajn sklopovlja je javno
dostupan. Uz to, Raspberry Pi ima nisku cijenu za svoje performanse, ima
opsežnu dokumentaciju te velik broj korisnika koji pridonose njegovom
ekosustavu. Ta platforma se koristila i u ovom radu. Preciznije, koristio se model
3B Raspberry Pija.
Kako bi se Linux usporedio s nekim operacijskim sustavom za rad u stvarnom
vremenu koristila se neslužbena varijanta FreeRTOS-a za Raspberry Pi,
stvorena od strane korisnika [8]. Raspberry Pi još nije podržan od strane
službenih FreeRTOS održavatelja.
Na Raspberry Pi bit će učitane različite inačice programa koji čitaju vrijednost s
jednog GPIO pina, te tu vrijednost šalju na drugi GPIO pin. Kao ulazni i izlazni
pin mogu se koristiti bilo koji GPIO pinovi, bitno je samo da je su točno definirani
u kodu. Prijašnja istraživanja pokazuju da je 22 MHz najveća frekvencija rada
7
koju podržava GPIO na Raspberry Piju [9], što će biti dovoljno za potrebe ovog
rada.
Reakcija na događaj na jednom pinu preko drugog pina može biti ostvarenja na
razne načine. Također, okolina u kojoj se to izvodi može biti u različitim stanjima,
odnosno, pripremljena na različite načine. U radu je jedan od ciljeva ispitati
upravo utjecaj svih tih načina odziva i postavki sustava na kašnjenje.
Svako ispitivanje sustava obavljeno je barem dvaput, s i bez dodatnog
opterećenja na procesoru. Za opterećenje procesora na operacijskom sustavu
Linux koristio se alat stress-ng. Taj alat se pokreće iz naredbenog retka te se
može pozvati uz razne opcije. Za potrebe ovog rada koristila se opcija „-c 16“
koja stvara 16 procesa radnika. Radnici izvršavaju nasumično odabrane
procesorski zahtjevne zadatke.
Kako bi radnici dobili „pravedan“ dio procesorskog vremena, potrebno je isključiti
autogroup funkcionalnost jezgre. Ako je ta funkcionalnost uključena,
raspoređivač dretvi će procese pokrenute iz iste terminalske sjednice tretirati kao
jednu grupu, te će cijeloj grupi dodijeliti onoliko procesorskog vremena koliko bi
inače dodijelio cijelom procesu. Slika 3.1 prikazuje procese koji u nekom trenutku
u sustavu troše najviše procesorskog vremena, manje zahtjevni procesi se ne
vide. Korisnički proces „loop“, pokrenut je iz jedne sjednice, dok su procesi radnici
„stress-ng-cpu“ pokrenuti iz druge terminalske sjednice uz uključeno grupiranje.
Slika 3.2 prikazuje istu situaciju uz isključeno grupiranje. Može se vidjeti da je u
prvom slučaju proces „loop“ uspio pridobiti cijelu jednu jezgru procesora za sebe,
dok u drugom mora dijeliti jezgru relativno ravnopravno s drugim procesima.
Autogroup funkcionalnost se može u potpunosti ukloniti pri prevođenju jezgre
Linuxa, postavljanjem opcije jezgre CONFIG_SCHED_AUTOGROUP u vrijednost
„n“, ili dinamički isključiti upisivanjem broja „0“ u datoteku
sched_autogroup_enabled na odgovarajućoj lokaciji u datotečnom sustavu [11].
8
Slika 3.1 Korisnički proces i procesi radnici uz uključeni autogroup na sustavu s 4
procesorske jezgre
Slika 3.2 Korisnički proces i procesi radnici uz isključeni autogroup na sustavu s 4
procesorske jezgre
Za opterećenje na operacijskom sustavu FreeRTOS pokreće se 16 dretvi
srednjeg prioriteta. Sve dretve izvršavaju jednostavno povećanje varijable u
beskonačnoj petlji. Pola od njih imaju odgodu izvođenja od 10 ms nakon svake
iteracije, dok druga polovica nema nikakvu odgodu.
9
3.2. Opis mjernog sustava
U sklopu rada razvijena su dva tipa mjerenja za ispitivanje kašnjenja odziva. Oba
kao osnovu koriste sustav kojeg su razvili Ivan Mandić i Andrej Kljajo Petković
[12] u sklopu svojih diplomskih radova.
Kao mjerna oprema koristio se STM32 mikroupravljač iz serije F4.
STM32 je porodica mikroupravljača koju proizvodi tvrtka STMicroelectronics. Ti
mikroupravljači su bazirani na ARM Cortex-M porodici procesora. Jedna od
odlika STM32 mikroupravljača je velik broj perifernog sklopovlja koje se nalazi na
pločici. Od posebnog interesa za primjene mjernog sustava su brojila i
komunikacijska periferija. STM32F4 nudi čak 14 brojila, od čega su dva 32-bitna,
a ostali 16-bitni, pri čemu se svako od njih može koristiti kao izvor pulsno-širinsko
moduliranog signala. Što se tiče komunikacije, STM32F4 na sebi ima više
sklopova za asinkronu serijsku komunikaciju, što mu dopušta da komunicira s
računalom i s drugim mikroupravljačem bez potrebe za prespajanjem kablova ili
gašenjem uređaja.
Mjerni sustav sačinjavaju dva STM32 mikroupravljača koji su u međusobnoj
komunikaciji. Jedan od njih ima ulogu „mjeritelja“, a drugi „generatora signala“.
Generator ima izlazni pin SIG_OUT na kojeg šalje generirani signal. Taj signal
osluškuje mjeritelj na pinu SIG_REF te ispitivani sustav na pinu SIG_IN. Ispitivani
sustav tada mora što brže preslikati signal na svoj izlazni pin RES_OUT, na kojeg
je spojen mjeritelj pinom RES_IN (Slika 3.3). Mjeritelj koristi ulazni signal na pinu
SIG_REF kao referencu s kojom uspoređuje preslikani signal dobiven od
ispitivanog sustava na RES_IN.
Mjeritelj je jednom serijskom vezom spojen s osobnim računalom, a drugom s
generatorom signala. Mjeritelj od računala prima poruku koja slovom S označava
početak rada, a nakon njega šalje i dodatni parametar tako da prvo pošalje broj
bajtova koje još treba poslati, a nakon toga parametar kao cijeli broj. Na primjer,
za parametar 32 šalje se „S232“, a za parametar 256 šalje se „S3256“. Nakon
primitka poruke, mjeritelj ju prosljeđuje generatoru. Kad primi poruku, generator
pokrene generiranje pravokutnog signala na izlaznom pinu SIG_OUT. Pravokutni
signal izveden je preko pulsno-širinske modulacije s radnim ciklusom od 50%.
10
Slika 3.3 Shema spajanja mjernog i ispitivanog sustava
3.2.1. Osnovno mjerenje
Na rastući brid referentnog signala, mjeritelj postavlja svoje interno 16-bitno
brojilo na 0. Na padajući brid referentnog, te oba brida preslikanog signala,
mjeritelj bilježi trenutnu vrijednost brojila. Jednim uzorkom se smatra zapis koji
sadrži:
• t1, vrijeme dolaska rastućeg brida na RES_IN
• t2, vrijeme dolaska padajućeg brida na SIG_REF
• t3, vrijeme dolaska padajućeg brida na RES_IN
Vrijeme dolaska rastućeg brida na SIG_REF (t0) se ne bilježi s obzirom da se u
tom trenutku brojilo inicijalizira na 0, pa bi takvo vrijeme uvijek bilo 0. Kad napuni
20000 takvih uzoraka od tri zabilježena vremena, mjeritelj ih šalje serijskom
vezom natrag na računalo na daljnju analizu. Slika 3.4 vizualno prikazuje opisani
način mjerenja.
11
Slika 3.4 Vizualni prikaz osnovnog mjerenja
Parametar koji se od osobnog računala prima preko serijske veze označava
vrijednost djelitelja frekvencije za brojila u mjeritelju i generatoru. Manjom
frekvencijom postiže se veće vrijeme između bridova generiranog pravokutnog
signala. Time se dobiva duže mjerenje, te duže maksimalno kašnjenje koje
sustav može izmjeriti, a pritom se gubi razlučivost mjerenja i povećava minimalno
mjerljivo vrijeme.
Isječak koda 3.1 i Isječak koda 3.2 prikazuju pseudokod izvedbe mjeritelja
odnosno generatora signala.
main() {
initUART()
initGPIO()
initInterrupts()
disableInterrupts()
recflag = true
while(1) {
if (recflag && UART1.available() && UART1.read(1) == 'S') {
bytes = int(UART1.read(1))
prescale = int(UART1.read(bytes))
init16bTimer(prescale)
i = 0
recflag = false
UART2.send("S" + bytes + prescale)
12
enableInterrupts()
}
}
}
interruptSIG_REF() {
if (SIG_REF.read() == 1) {
TIMER.count = 0
times[i].t1 = 0
times[i].t2 = 0
} else {
times[i].t2 = TIMER.count
}
}
interruptRES_IN() {
if (RES_IN.read() == 1) {
times[i].t1 = TIMER.count
} else {
times[i].t3 = TIMER.count
i++
if (i == times.size) {
disableInterrupts()
UART1.send(times)
recflag = true
}
}
}
Isječak koda 3.1 Pseudokod izvedbe mjeritelja za osnovno mjerenje
main() {
initUART()
initGPIO()
initPWM()
while(1) {
if (UART1.available() && UART1.read(1) == 'S') {
bytes = int(UART1.read(1))
prescale = int(UART1.read(bytes))
duty_cycle = 50
initPWM(prescale, duty_cycle)
}
}
}
Isječak koda 3.2 Pseudokod izvedbe generatora signala
13
Osnovno mjerenje je manja prilagodba preuzetog mjernog sustava. Zbog malih
razlika, implementacija je bila brža pa se koristio u ranijim fazama rada, da se
dobije općeniti dojam utjecaja određenih parametara na kašnjenje. Zbog
određenih primijećenih problema, implementirana je druga varijanta mjerenja
„mjerenje s oznakom događaja“. Sva mjerenja su kasnije ponovljena koristeći to
mjerenje jer ono daje preciznije rezultate.
3.2.2. Mjerenje s oznakom događaja
Velika mana primijećena u radu s gore navedenim mjernim sustavom je
nemogućnost rada s propuštenim odzivima. Osnovni mjerni sustav pretpostavlja
da neće biti propuštenih odziva, to jest, da će odziv uvijek doći u poluperiodi koja
slijedi podražaj. Najbolje što takav sustav može napraviti je provjeriti jesu li
izmjerene vrijednosti „smislene“. Na primjer, može provjeriti jesu li za svaki
uzorak sva tri vremena postavljena na nešto različito od početne vrijednosti, i ako
za neki nisu, zaključiti da se tu dogodio propušten odziv. Osim indikacije da je
bar jedan odziv propušten, ne može se napraviti neka bolja analiza propuštenih
događaja.
U svrhu boljeg proučavanja propuštenih odziva, te maksimalne frekvencije rada
pri kojoj se takvi propusti neće događati, implementirana je i druga programska
podrška mjeritelja koja će se u radu nazivati „mjerenje s oznakom događaja“.
Umjesto da svaki uzorak ima fiksna tri vremena koja bilježi, vrijeme svakog
događaja se tretira individualno.
Vrijednost brojila se postavlja u nulu samo jednom, na početku cjelokupnog
mjerenja. Da bi ovo uopće bilo moguće, koristi se 32-bitno brojilo umjesto 16-
bitnog. Svaki od četiri moguća događaja (uključujući, znači, i rastući brid na
SIG_REF) ima oznaku koja ga identificira i koja se bilježi zajedno s vremenom
dolaska (Slika 3.5). Po oznakama događaja može se provjeriti točno kad je neki
odziv na podražaj propušten, a robusniji sustav praćenja događaja dopušta
analiziranje situacija kad odziv zakasni za poluperiodu, ali i dalje dođe prije
sljedećeg odziva iste vrste. Odziv se smatra propuštenim ako se zabilježe dva
događaja iste vrste na pobudi, između kojih nije bilo odgovarajućeg odziva (Slika
3.6).
14
Slika 3.5 Vizualni prikaz mjerenja s oznakom događaja
Slika 3.6 Vizualni prikaz detekcije propuštenog odziva kod mjerenja s oznakom događaja
Zbog 32-bitne vrijednosti brojila, dodatnih oznaka događaja i zapisa rastućeg
brida pobude, ovaj mjerni sustav može u memoriju mikroupravljača spremiti puno
manje uzoraka nego osnovni, prije nego što se ona prepuni. On može izmjeriti
15
najviše 24000 zasebnih događaja, što je ekvivalentno 6000 uzoraka u osnovnom
mjerenju. Zbog toga, ovakav mjerni sustav prikladniji je za ponavljana mjerenja
između kojih je pauza. Za vrijeme te pauze sustav može poslati rezultate mjerenja
i time osloboditi memoriju za daljnji rad.
Parametar koji se šalje preko serijske veze sad određuje samo vrijednost djelitelja
frekvencije u generatoru signala, dok je vrijednost djelitelja u mjeritelju fiksno
postavljena na 8. Ova vrijednost daje razlučivost brojila od 95 nanosekundi, što
je dovoljno dobro za potrebe rada. Pritom dopušta da jedno neprekinuto mjerenje
traje do 409 sekundi (6 minuta i 49 sekundi) bez preljeva brojila mjeritelja. Stvarna
duljina mjerenja definirana je frekvencijom generatora signala (Tablica 3.1) jer će
završiti tek nakon 24000 „događaja“, ali 409 sekundi je gornja granica koliko ona
najviše smije trajati.
Tablica 3.1 Ovisnost frekvencije generatora signala o duljni pojedinačnog mjerenja
Vrijednost preddjelila frekvencije generatora
signala
Frekvencija generatora signala (MHz)
Duljina pojedinačnog mjerenja (s)
1 84 4.68
2 42 9.36
4 21 18.72
8 10.5 37.45
32 2.625 149.79
... ... ...
Isječak koda 3.3 prikazuje novu izvedbu mjeritelja. Izvedba generatora signala
ostaje ista kao i za osnovno mjerenje.
main() {
initUART()
initGPIO()
initInterrupts()
disableInterrupts()
recflag = true
prescale = 8
while(1) {
if (recflag && UART1.available() && UART1.read(1) == 'S') {
bytes = int(UART1.read(1))
16
prescale_gs = int(UART1.read(bytes))
init32bTimer(prescale)
TIMER.count = 0
i = 0
recflag = false
UART2.send("S" + bytes + prescale_gs)
enableInterrupts()
}
}
}
interruptSIG_REF() {
if (SIG_REF.read() == 1) {
times[i].event_mark = 1
} else {
times[i].event_mark = 3
}
times[i].time = TIMER.count
i++
}
interruptRES_IN() {
if (RES_IN.read() == 1) {
times[i].event_mark = 2
} else {
times[i].event_mark = 4
}
times[i].time = TIMER.count
i++
if (i == times.size) {
disableInterrupts()
UART1.send(times)
recflag = true
}
}
Isječak koda 3.3 Pseudokod izvedbe mjeritelja za mjerenje s oznakom događaja
17
3.3. Metodologija mjerenja
Sustav koji koristi Linux u različitim trenucima može biti različito opterećen zbog
raznih servisa i procesa koji se izvršavaju kao dio Raspbian distribucije. Kako bi
se dobilo mjerenje koje vjerno predstavlja računalni sustav koji koristi Linux,
potrebno da ono pokriva veći vremenski raspon.
Osnovna mjerenja korištena su samo u ranijim fazama rada. Svi rezultati u radu
dobiveni su korištenjem mjerenja s oznakom događaja, osim gdje je drukčije
napomenuto.
Mjerenje s oznakom događaja odrađeno je uz 10 pojedinačnih mjerenja između
kojih su pauze. Pauze su namještene tako da ukupno mjerenje pokriva raspon
od 40 minuta. Pojedinačno mjerenje koristi varijabilne vrijednosti dijelila pa mu je
i duljina varijabilna. Sva mjerenja odrađena su prvo s vrijednosti dijelila 1, tj. uz
frekvenciju signala 1293 Hz. Ta frekvencija generira brid svakih 387 μs. Ona će
se u ostatku teksta nazivati „bazna frekvencija“. Za to mjerenje zabilježen je broj
propuštenih odziva. Propušteni odzivi iskrivljuju sliku o prosječnim kašnjenjima
jer se ne može odrediti koji odziv je okinula koja pobuda. „Pomak“ u odzivima,
npr. da je 1. odziv nakon 2. pobude i 3. odziv nakon 2. pobude, može dati nisko
prosječno vrijeme koje nije vjeran prikaz sustava. Ako je propuštenih odziva bilo,
mjerenja su odrađena ponovno uz niže frekvencije signala kako bi se što točnije
ustanovila prosječna kašnjenja. Rezultati dani u nastavku prikazuju stanje za
najveću frekvenciju signala pri kojoj se nisu javili propušteni odzivi, osim ako nije
navedeno drukčije. Ispod svake tablice zapisano je i koliko je propuštenih odziva
bilo uz baznu frekvenciju.
3.4. Verifikacija mjernog sustava
Mjerni sustav je verificiran na dva načina. Prvo, koristio se verifikacijski program
na zasebnom, trećem STM mikroupravljaču. Taj mikroupravljač oponaša
ispitivani sustav te se spaja umjesto Raspberry Pi uređaja. Verifikacijski program
odgovara na pobudu koju mikroupravljač primi na jednom od svojih pinova, no to
čini uz umjetno generirano kašnjenje. Duljina kašnjenja odgovara unaprijed
izračunatim uzorcima funkcije sinus. Ideja je da se pri iscrtavanju uzoraka
kašnjenja vidi prepoznatljivi oblik sinusoide (Slika 3.7 i Slika 3.8). Ako sinusoida
18
izlazi van očekivanih vrijednosti ili ima smetnje, treba provjeriti ispravnosti
mjernog sustava.
Slika 3.7 Grafička verifikacija osnovnog mjernog sustava uz pomoć kašnjenja koje
simulira sinus
19
Slika 3.8 Grafička verifikacija mjernog sustava s oznakom događaja (crvene linije
označavaju pauze u mjerenju)
Sustav se može verificirati i simuliranim kašnjenjem na Raspberry Piju. Unutar
prekida ili asinkrone funkcije stavlja se poziv funkcije za odgodu izvršavanja.
Isječak koda 3.4 prikazuje dio pseudokoda izvedbe takve simulacije. Tablica 3.2
prikazuje rezultate jednog mjerenja sa simuliranim kašnjenjem. Iz nje se može
vidjeti da poziv funkcije dodaje određeno fiksno vrijeme na kašnjenje sustava, no
promjena duljine odgode se linearno preslikava na kašnjenje. Najveće
odstupanje od očekivane vrijednosti iznosi oko 31 ns, što je dovoljno dobro za
mjerenja koja će se raditi u ovom radu.
prekidni_potprogram() {
razina = procitaj_gpio(ulazni_prikljucak)
cekaj_n_mikrosekundi(neki_broj)
pisi_gpio(izlazni_prikljucak)
}
Isječak koda 3.4 Pseudokod simuliranja kašnjenja
20
Tablica 3.2 Rezultati jednakog mjerenja s različitim simuliranim kašnjenjima
Mjerenje Prosječno kašnjenje (μs)
Bez poziva odgode 4.7208
Odgoda od 3 μs 7.9672
Odgoda od 4 μs 8.9364
Odgoda od 5 μs 9.9655
Odgoda od 15 μs 19.998
21
4. ZNAČAJNI PARAMETRI ISPITIVANOG SUSTAVA I
REZULTATI MJERENJA
Na kašnjenje odziva ispitivanog sustava uvelike utječe način na koji je
implementirana programska potpora koja se na njemu izvršava. U ovom poglavlju
će se proći kroz različite izvedbe i usporediti njihove rezultate mjerenja.
Svi navedeni rezultati dobiveni su mjernim sustavom s oznakom događaja
koristeći metodologiju opisanu u poglavlju 3.3.
4.1. Različite izvedbe u korisničkom načinu rada
Najjednostavnije izvedbe odziva na vanjski događaj su one koje koriste biblioteku
za rad s GPIO pinovima. Za ovaj rad odabrana je biblioteka „pigpio“, no slične
funkcionalnosti mogu se naći u mnoštvu drugih biblioteka. Rješenje izvedeno
pomoću GPIO biblioteke izvodi se kao obični korisnički proces. Za stvaranje
izvršne datoteke potrebno je prevoditelju ili povezivaču dati argumente „-lrt“ i „-
lpigpio“, a osim toga nije potrebna nikakva posebna priprema. Ova biblioteka u
pozadini radi s datotečnim sučeljem prema GPIO pinovima koje pruža operacijski
sustav Linux.
Program koji preslikava ulazni GPIO pin na izlazni može biti izveden na više
načina. Tu će biti razmotrene razlike između dvije specifične izvedbe. Prva
izvedba ima beskonačnu petlju radilicu unutar koje se očitava vrijednost na
jednom pinu i zapisivati tu vrijednost na drugi, bez ikakvih dodatnih operacija.
Druga izvedba je asinkrona, na detektirani događaj na ulaznom pinu se očitava
vrijednost i upisuje na izlaz. Biblioteka pigpio pruža mogućnost detektiranja
događaja na pinovima te asinkronog izvršavanja koda okinutog tim događajima,
nalik prekidnim potprogramima. Treba međutim primijetiti da se sav asinkroni kod
i dalje izvršava u korisničkom načinu rada, a ne u prekidnom, unatoč
konceptualnim sličnostima. Asinkrono okidanje koda u ovoj biblioteci interno je
izvedeno kreiranjem nove dretve koja u petlji poziva poll sustavski poziv nad
datotekom zaduženom za vrijednost danog GPIO pina. Ta funkcija će blokirati
dretvu dok dana datoteka ne bude spremna za čitanje, odnosno dok se ne
22
promjeni stanje na GPIO pinu. Nakon što se dretva odblokira, ona poziva
registriranu asinkronu funkciju te se ponovno blokira.
while (1) {
int level = gpioRead(IN_PIN);
gpioWrite(OUT_PIN, level);
}
Isječak koda 4.1 GPIO petlja radilica
void callback(int event, int level, uint32_t tick) {
gpioWrite(OUT_PIN, level);
}
int main(void) {
//inicijalizacije
...
if ((ret = gpioSetISRFunc(IN_PIN,
EITHER_EDGE,
-1,
callback)) != 0) {
printf("gpioSetISRFunc returned: %d\n", ret);
return 2;
}
...
}
Isječak koda 4.2 Izvedba s asinkronom funkcijom
Petlja radilica trebala bi dati jako dobre rezultate s obzirom da instrukcije petlje
(uvjetno i bezuvjetno grananje) ne troše skoro ništa vremena, a ne gubi vrijeme
ni na asinkrone pozive. Ova izvedba međutim troši čitavo procesorsko vrijeme
jedne njegove jezgre te time nije vrlo skalabilna. U slučaju četverojezgrenog
procesora kakvog ima Raspberry Pi 3, sustav bi mogao raditi s najviše tri ovakva
procesa prije nego bi oni ili zagušili cijeli ostatak sustava ili počeli gubiti na
vremenskim performansama. Također, utjecaj opterećenja sustava na ovakvu
izvedbu trebala bi drastično smanjiti njene performanse, pogoršavajući prosječan
slučaj barem za red veličine, te najgori slučaj za nekoliko redova veličine.
Asinkrona izvedba trebala bi biti dovoljno dobra za većinu primjena, a da pritom
nema ove negativne učinke na ostatak sustava. Upitno je samo koliko se
vremena ipak izgubi kroz te asinkrone pozive. Ova izvedba trebala bi biti mnogo
23
otpornija na opterećenost sustava, no određeni utjecaj bi ipak trebao biti vidljiv s
obzirom da veći broj dretvi koje se bore za procesorsko vrijeme, što može
odgoditi početak rada korisničke dretve. Očekuje se povećanje kašnjenja za
manje nego dvostruko za prosječan slučaj, te unutar reda veličine za najgori
slučaj.
Tablica 4.1 Rezultati mjerenja u korisničkom načinu rada
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Asinkrona izvedba
Normalno 31.42 42.60 48.29 55.49 122.0
Opterećeno 30.76 102.26 261.3 631.3 1493
Izvedba s petljom
radilicom
Normalno 0.5714 0.6619 0.6667 0.6667 213.2
Opterećeno 0.5714 30 994 104 570 427 730 935 390
Obje izvedbe su neopterećeno mjerenje obavile bez propuštenih odziva uz baznu
frekvenciju. Za opterećeno mjerenje asinkrona izvedba je na baznoj frekvenciji
propustila 1554 od 120091 odziva (1.29%). Rezultati iz tablice dobiveni su za
frekvenciju od 143.7 Hz. Petlju radilicu uz opterećenje uopće nije bilo moguće
mjeriti na baznoj frekvenciji jer je prečesto propuštala odzive. Dani rezultati su
izmjereni na frekvenciji od 40.41 Hz pri čemu je i dalje propustila 92259 od
165974 odziva (55.59%).
Iz rezultata mjerenja vide se opisani učinci. Maksimalna kašnjenja te utjecaj
opterećenja asinkrone izvedbe su nešto veći od očekivanih. Na usporedbi
dijagrama od opterećenog mjerenja i neopterećenog mjerenja može se vidjeti
nekoliko stvari (Slika 4.1). Skokovi u kašnjenju pri opterećenom sustavu su
naizgled periodički i ponavljaju se u sličnom uzorku otprilike svakih 2 sekunde.
Periodičnost je vjerojatno posljedica unutarnje izvedbe stress-ng alata. Skokovi
imaju veće minimalno kašnjenje, što se vidi po bijelim „brežuljcima“, a imaju i veći
raspon kašnjenja što se vidi po plavim „šiljcima“.
24
Slika 4.1 Usporedba kašnjenja asinkrone izvedbe bez opterećenja (gore) i s opterećenjem
(dolje)
Mjerenja nad petljom radilicom otprilike odgovaraju očekivanjima. Na dijagramu
uzoraka jasno se vide trenutci kad je petlja dobila ekskluzivno pravo na izvođenje
te trenutci kad je procesorsko vrijeme dijelila s drugim procesima (Slika 4.2).
25
Slika 4.2 Grafički prikaz rezultata mjerenja za izvedbu s petljom radilicom uz opterećenje
procesora
Vide se i učinci na zauzeće procesorskog vremena. Petlja radilica zauzima čitavo
procesorsko vrijeme jedne jezgre, ako joj je ono dostupno, dok asinkrona izvedba
zauzima oko 10 posto, ovisno o frekvenciji promjene stanja na GPIO ulazu (Slika
4.3 i Slika 4.4).
Slika 4.3 Zauzeće procesora petlje radilice
Slika 4.4 Zauzeće procesora asinkrone funkcije
26
4.2. Jezgreni način rada
Većina operacijskih sustava, pogotovo općenamjenskih, raspoznaje osnovni,
korisnički način rada i povlašteni, jezgreni način rada. U korisničkom načinu rada,
kod koji se izvršava nema izravan pristup svom sklopovlju ni funkcionalnostima
jezgre. Svaka dretva u korisničkom načinu rada mora biti dio procesa te može
pristupati samo radnoj memoriji dodijeljenoj tom procesu. Preko sustavskih
poziva mogu se neizravno koristiti funkcionalnosti jezgre i sklopovlja. Sustavski
pozivi delegiraju kontrolu jezgrenim funkcijama koje se izvršavaju u jezgrenom
načinu rada. U tom načinu rada, sva memorija je na raspolaganju te je dopušteno
pozvati bilo koju instrukciju procesora. Jezgra nema potrebu za procesima jer
nema segmentiranu memoriju, ali također može imati više dretvi izvođenja. To je
slučaj kod Linux jezgre. Jezgrene dretve imaju veći maksimalni prioritet nego
korisničke te nemaju ograničenja na izvođenje koda.
Jednostavniji procesori često nemaju sklopovsku potporu za odvajanje ovih
načina rada. Operacijski sustavi koji se koriste uz te procesore ili nemaju
odvojene načine rada ili imaju načine rada koji nemaju ograničenja na
funkcionalnost i memorijski pristup. U drugom slučaju, distinkcija načina rada se
koristi samo kako bi se odvojili jezgreni i korisnički stog i slično. ARM Cortex-A
arhitektura koju koristi Raspberry Pi ima sklopovsku potporu za osnovne i
povlaštene načine rada. Linux jezgra se u svojoj implementaciji oslanja na tu
funkcionalnost.
Korisnički kod može se učitati u Linux jezgru kao jezgreni modul (engl. loadable
kernel module). Kod se mora prevesti uz posebne opcije koje ga pripremaju za
rad u jezgri, nakon čega se dobiveni modul s .ko nastavkom može učitati
naredbom insmod. Modul se može ukloniti naredbom rmmod, a lista učitanih
modula nalazi se u datoteci /proc/modules. Programski kod jezgrenog modula
mora imati označenu inicijalizacijsku funkciju, koja se poziva kad se modul učita,
te uklanjačku funkciju, koja se poziva kad se modul ukloni iz jezgre. Unutar
inicijalizacijske funkcije se mogu postaviti prekidni potprogrami koji će aktivirati
modul u trenucima kada je on potreban.
U stvarnim primjenama, prekidi se najčešće obrađuju prekidnim potprogramom
koji prvo obavlja brzi i hitni dio obrade, a potom budi jezgrenu dretvu koja može
27
raditi neku sporiju obradu nakon završetka potprograma. Razlog tome je to što
jedan prekid onemogućuje sve druge bez mogućnosti prioritiziranja, čime bi duga
obrada prekida mogla zagušiti sustav. Za razliku od njih, jezgrene dretve se mogu
izvršavati u paraleli te imaju prioritete što daje bitnijim zadacima mogućnost da
oduzmu prednost manje bitnih zadataka koji su ranije došli u sustav.
Jednokratno čitanje i pisanje na GPIO pinove u stvarnom sustavu trebalo bi se
raditi unutar prekidnog potprograma jer kratko traje i obično treba biti obavljeno
što prije. To je prva izvedba ispitnog programa u jezgrenom načinu rada. Ipak,
kako bi se ispitalo kašnjenje dobiveno buđenjem dretve i završetkom prekidnog
potprograma, dana je i druga izvedba kod koje se operacije nad GPIO-om rade
unutar jezgrene dretve buđene na prekid. Toj dretvi je dan maksimalni prioritet
kako bi se ispitalo koliko se zapravo može eliminirati utjecaj opterećenja sustava
na kašnjenje najbitnijeg zadatka.
Prekidni potprogram registrira se funkcijom request_irq, dok se funkcijom
request_threaded_irq može registrirati i prekidni potprogram i dretva koju
će on probuditi. Ako se request_threaded_irq funkciji kao referenca na
potprogram dade NULL, te IRQF_ONESHOT kao zastavica, Linux će koristiti
pretpostavljeni prekidni potprogram koji samo probudi zadanu dretvu i završava.
Također, zbog IRQF_ONESHOT zastavice, sustav će isključiti prekide s tog izvora
dok dretva ne završi s radom. Ovo je nužno kako bi bilo sigurno da će sustav
odgovoriti na jedan prekid prije nego krene obrađivati sljedeći, međutim može
dovesti do nepredviđenog problema. Naime, ako obrada potraje i jezgrena dretva
ne uspije završiti s radom prije nego dođe sljedeći brid, prekid će još uvijek biti
isključen. Operacijski sustav će zaključiti da se pojavio neobradivi prekid. Linux
jezgra onda, kao mjeru opreza, trajno isključuje prekide s tog izvora. Kako bi se
ovo izbjeglo, treba dodati „noirqdebug“ zastavicu u parametre za pokretanje
operacijskog sustava (cmdline.txt datoteka u Raspberry Pi „boot“ datotečnom
sustavu). Uz tu zastavicu, jezgra će jednostavno ignorirati prekide koji su trenutno
neobradivi, te će oni biti obrađeni kad se ponovno uključe prekidi s tog izvora.
static void irq_handler(int irq, void* dev_id,
struct pt_regs *regs)
{
int val = gpio_get_value(IN_PIN);
gpio_set_value(OUT_PIN, val);
28
}
int init_module(void)
{
//inicijalizacije
...
int irqNum = gpio_to_irq(IN_PIN);
int result = request_irq(
irqNum,
(irq_handler_t) irq_handler,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
IRQ_DEV_ID,
NULL
);
...
}
Isječak koda 4.3 Izvedba s prekidnim potprogramom
static void gpio_handler_thread(int irq, void* dev_id,
struct pt_regs *regs)
{
int val = gpio_get_value(IN_PIN);
gpio_set_value(OUT_PIN, val);
}
int init_module(void)
{
//inicijalizacije
...
int irqNum = gpio_to_irq(IN_PIN);
int result = request_threaded_irq(
irqNum,
NULL,
(irq_handler_t) gpio_handler_thread,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
IRQ_DEV_ID,
NULL
);
...
}
Isječak koda 4.4 Izvedba s jezgrenom dretvom
Izvedba koja koristi prekidni potprogram trebala bi u prosječnom slučaju biti
barem za red veličine brža od asinkrone izvedbe iz prethodnog poglavlja, dok bi
ona koja koristi jezgrenu dretvu trebala po kašnjenju biti između te dvije. Obje bi
trebale biti sporije od petlje radilice iz prethodnog poglavlja u prosječnom slučaju.
Izvedba s potprogramom trebala bi biti praktički otporna na opterećenje
29
procesora, očekuje se povećanje kašnjenja za manje od dvostruko i kod
prosječnog i kod maksimalnog vremena. Izvedba s jezgrenom dretvom trebala bi
imati nešto veći utjecaj opterećenja, ali mnogo manji nego izvedbe iz prošlog
poglavlja.
Tablica 4.2 Rezultati mjerenja u jezgrenom načinu rada
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Prekidni potprogram
Normalno 2.476 4.627 6.952 9.238 18.19
Opterećeno 1.238 5.202 13.62 63.01 279.8
Jezgrena dretva
Normalno 11.71 16.82 19.14 22.76 61.91
Opterećeno 8.381 17.86 39.14 133.3 647.3
Tablica 4.3 Podaci o propuštenim odzivima za jezgreni način rada
Mjerenje Udio propuštenih odziva
na baznoj frekvenciji Frekvencija bez
propuštenih odziva (Hz)
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0.005% 647
Jezgrena dretva Normalno 0% 1293
Opterećeno 0.08% 647
Rezultati pokazuju puno bolja maksimalna vremena nego izvedbe iz prošlog
potpoglavlja, međutim utjecaj opterećenja na njih je mnogo veći nego što je
očekivano. To je pogotovo neobično za izvedbu s prekidnim potprogramom, koji
bi trebao moći prekinuti rad i jezgrenih i korisničkih funkcija. Linux se trudi posao
u sustavu optimalno raspodijeliti među procesorskim jezgrama, pa je jedno
potencijalno objašnjenje da veći broj zadataka uzrokuje veći broj promjena
konteksta na svakoj od procesorskih jezgara. Promjena konteksta vjerojatno
isključuje prekide u nekom trenutku i time može odgoditi obradu.
Iz dijagrama za opterećena mjerenja se više ne vide periodični skokovi (Slika
4.5). Iz toga se može zaključiti da sami zadaci koje generira stress-ng imaju manji
utjecaj nego izmjenjivanje tih zadataka i „kućanski poslovi“ koji iz toga proizlaze.
30
Slika 4.5 Kašnjenja uz opterećeni sustav za izvedbu s prekidnim potprogramom (gore) i
izvedbu s jezgrenom dretvom (dolje)
4.3. Postavke jezgre
Linux jezgra nudi mnoštvo opcija koje se mogu konfigurirati pri prevođenju. Te
opcije specificiraju se u .config datoteci u vršnom direktoriju izvornog koda jezgre.
Opcije su statičke, tj. ne mogu se mijenjati jednom kad je jezgra prevedena i
pokrenuta, iako neke od njih otključavaju druge mogućnosti koje se mogu
mijenjati unutar samog operacijskog sustava.
Neke opcije vezane su za međusobnu interakciju zadataka u jezgri. Konkretnije,
Linux jezgra dopušta nekoliko politika prekidanja jezgrenih funkcija. Dugo
vremena, većina jezgrenih funkcija Linuxa su bile neprekidne. To je značilo da se
nikakav drugi zadatak ne može izvršiti dok traje izvršavanje jezgrene funkcije,
već mora čekati na njen završetak. U novijim verzijama Linux jezgre, u svrhu
smanjenja kašnjenja ključnih zadataka u sustavu, uvedena je finija granulacija
neprekidnih dijelova. Finija granulacija i izmjenjivanje aktivnih zadataka,
međutim, smanjuje propusnost sustava i možda nije primjerena za neke
primjene, kao npr. poslužiteljska računala. Politike prekidanja uvedene su kao
način na koji si korisnik jezgre može konfigurirati sustav, ovisno o tome želi li veću
propusnost ili manje kašnjenje.
31
Linux jezgra u verziji 4.17 nudi na izbor tri politike prekidanja: PREEMPT_NONE,
PREEMPT_VOLUNTARY i PREEMPT. PREEMPT_NONE u potpunosti
isključuje prekidanje jezgrenih funkcija. PREEMPT_VOLUNTARY uključuje
eksplicitne točke prekidanja, dijelove koda unutar jezgrene funkcije koji će
prekinuti njeno izvršavanje ako postoji prioritetniji zadatak u sustavu. Treća
opcija, PREEMPT, dopušta prekidanje jezgre u bilo kojem trenutku, osim u
kritičnim odsječcima. Distribucija Raspbian, kao i većina drugih, koristi
PREEMPT_VOLUNTARY opciju. S obzirom da PREEMPT opcija nudi veću
mogućnost prekidanja jezgre, njeno korištenje trebalo bi smanjiti kašnjenje
odgovora kod dretvenog prekida. Ne bi trebalo biti utjecaja na izvedbu s
odgovorom u prekidnom potprogramu, s obzirom da prekidi ionako mogu
prekinuti izvođenje jezgre.
Izvedbe iz prethodnog potpoglavlja ispitane su i s PREEMPT opcijom upaljenom.
Trebalo bi se vidjeti poboljšanje kod dretvene izvedbe, a ne bi trebalo biti veće
razlike kod izvedbe s potprogramom.
Tablica 4.4 Rezultati mjerenja u jezgrenom načinu rada s PREEMPT politikom prekidanja
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Prekidni potprogram
Neopterećeno 3.048 6.000 9.143 11.62 37.24
Opterećeno 1.810 6.272 14.19 59.17 257.9
Jezgrena dretva
Neopterećeno 16.48 22.81 26.19 30.29 64.57
Opterećeno 12.00 24.995 57.05 150.5 710.1
Tablica 4.5 Podaci o propuštenim odzivima za jezgreni način rada s PREEMPT politikom
prekidanja
Mjerenje Udio propuštenih odziva
na baznoj frekvenciji Frekvencija bez
propuštenih odziva (Hz)
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Jezgrena dretva Normalno 0% 1293
Opterećeno 0.01% 431
32
U usporedbi s tablicom 4.2 vidi se pogoršanje u gotovo svim segmentima.
Pogoršanje kod prekidne izvedbe može se objasniti time što ova politika prekida
možda unosi potrebu za novim „kućanskim poslovima“ pri ulazu u prekide, a
možda ima i više kritičnih odsječaka unutar kojih se prekid ne može obraditi.
Rezultati dretvene izvedbe su, međutim, vrlo iznenađujući. Jedno potencijalno
objašnjenje je da ova politika omogućuje i da neka druga jezgrena dretva prekine
dretvu koja obrađuje prekid no to je vrlo malo vjerojatno s obzirom da joj je
prioritet postavljen na maksimalni. Ako pomoću naredbe „ps“ pregledamo
jezgrene dretve u sustavu, možemo vidjeti da osim GPIO dretve čije se kašnjenje
mjeri, postoje i „migration“ dretve koje također imaju maksimalni prioritet (Slika
4.6). Njihov posao je optimiranje raspodijele posla po procesorskim jezgrama.
Moguće je da uz ovu politiku prekidanja te dretve ponekad malo odgode
izvršavanje dretve za obradu prekida.
Slika 4.6 Ispis naredbe "ps" kad se pretražuju dretve maksimalnog prioriteta
4.4. Vanjski dodaci za operacijski sustav
PREEMPT_RT dodatak, poznat još pod imenom „linux-rt“ počeo se razvijati dok
je Linux jezgra još bila neprekidiva. Taj dodatak je uveo finiju granulaciju
jezgrenih funkcija te izmjenu mehanizama za međusobno isključivanje. Cilj
dodatka je smanjenje kašnjenja u raspoređivanju zadataka u jezgri, i time Linux
učiniti prihvatljivijim za primjene u stvarnom vremenu.
Neke izmjene napravljene u ovom dodatku su dodane i u službeni kod u novijim
verzijama Linux jezgre, zbog čega njegovo uključivanje ima manji utjecaj nego
što je imalo u starijim verzijama. Unatoč tome, dodatak se i dalje održava.
Dodatak se može skinuti kao patch datoteka koja se koristi uz Linux „patch“
naredbu nad izvornim kodom jezgre. Naredba patch će primjeniti promjene u
33
izvornom kodu. Nakon toga, u .config datoteci se mogu definirati opcije koje
dodaje dodatak.
Dodatak nudi dvije nove politike prekidanja: PREEMPT_RT_BASE i
PREEMPT_RT_FULL. U ovom radu, razmatrana je samo PREEMPT_RT_FULL
jer ona unosi najveće promjene. Kako bi se odabrala ta politika prekidanja
potrebno je i opcije PREEMPT, PREEMPT_RT_BASE i PREEMPT_RT_FULL
sve postaviti u „y“.
Uz ovu opciju, jezgra će prekidni potprogram registriran funkcijom request_irq
registrirati kao dretvu koja se budi na prekid, dakle ono što je u običnoj jezgri
radila funkcija request_threaded_irq. Ako stvarno želimo registrirati čisti
prekidni potprogram, trebamo uz već dane zastavice dati i IRQF_NO_THREAD
zastavicu pri pozivu request_irq funkcije.
Teško je odrediti hoće li ova politika poboljšati ili pogoršati stanje, s obzirom da
djeluje na sličan način kao i PREEMPT iz prošlog potpoglavlja.
Tablica 4.6 Rezultati mjerenja u jezgrenom načinu rada s PREEMPT_RT_FULL politikom
prekidanja
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Prekidni potprogram
Neopterećeno 2.857 5.627 12.86 19.52 59.81
Opterećeno 2.571 16.46 50.29 167.5 509.4
Jezgrena dretva
Neopterećeno 12.67 19.03 28.67 41.05 62.10
Opterećeno 9.523 28.22 66.48 147.3 425.2
34
Tablica 4.7 Podaci o propuštenim odzivima za jezgreni način rada s PREEMPT_RT_FULL
politikom prekidanja
Mjerenje Udio propuštenih odziva
na baznoj frekvenciji Frekvencija bez
propuštenih odziva (Hz)
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0.012% 431
Jezgrena dretva Normalno 0% 1293
Opterećeno 0.015% 431
Ova mjerenja pokazuju nešto bolja prosječna vremena nego kod PREEMPT
politike, međutim pokazuju još gora maksimalna kašnjenja. Također, sva
kašnjenja su lošija nego za PREEMPT_VOLUNTARY politiku. Potencijalna
objašnjenja zašto je to tako su jednaka kao i za PREEMPT politiku.
4.5. Različite frekvencije rada jezgre
Jezgra operacijskog sustava ima zadanu frekvenciju koja definira najmanji kvant
vremena vidljiv raspoređivaču zadataka. Na svaki istek tog kvantnog vremena,
raspoređivač provjerava treba li na neki način ažurirati stanje u sustavu. Ta
frekvencija zbog toga može utjecati na kašnjenje izvršavanja zadataka u sustavu,
međutim ne bi trebala puno utjecati na kašnjenje zadataka okinutih prekidom jer
se preraspoređivanje dretvi ionako događa nakon svakog prekida.
Linux jezgra nudi mogućnost odabira nekoliko predefiniranih vrijednosti između
100 i 1000 Hz za frekvenciju rada. Različite distribucije Linuxa koriste različite
vrijednosti, ali se za rad u stvarnom vremenu preporučuje 1000 Hz. Distribucija
Raspbian koristi 100 Hz, pa se može ispitati kako povećanje frekvencije utječe
na kašnjenje prekida. Mjerenja su rađena s nepromijenjenom Linux jezgrom uz
PREEMPT_VOLUNTARY politiku.
35
Tablica 4.8 Rezultati mjerenja u jezgrenom načinu rada uz radnu frekvenciju jezgre od
1000 Hz
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Prekidni potprogram
Neopterećeno 2.476 4.807 6.952 11.43 29.91
Opterećeno 1.238 6.268 18.19 66.72 273.2
Jezgrena dretva
Neopterećeno 11.71 17.77 20.86 36.095 47.24
Opterećeno 9.714 22.74 57.24 158.4 400.4
Tablica 4.9 Podaci o propuštenim odzivima za jezgreni način rada uz radnu frekvenciju
jezgre od 1000 Hz
Mjerenje Udio propuštenih odziva
na baznoj frekvenciji Frekvencija bez
propuštenih odziva (Hz)
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Jezgrena dretva Normalno 0% 1293
Opterećeno 0.018% 431
Vidi se malo pogoršanje prosječnih kašnjenja, no znatno poboljšanje
maksimalnog za dretvenu izvedbu. Pogoršanje prosječnih kašnjenja je
neočekivano, a može se možda pripisati većem broju promjena konteksta koje
odgađaju izvršavanje prekidnog potprograma.
4.6. Različiti operacijski sustav
Konačno, može se izmjeriti kako se u danim situacijama ponaša operacijski
sustav FreeRTOS. FreeRTOS nema službenu inačicu za Raspberry Pi, međutim
na stranici GitHub postoji neslužbena koja je dovoljno stabilna za rad. Korisnički
kod se piše u Demo/main.c datoteku, nakon čega se operacijski sustav prevodi
zajedno s tim kodom. Prevođenje koda stvara datoteku kernel7.img koja se
stavlja na SD karticu umjesto slike Linux jezgre.
FreeRTOS također ima statičke opcije koje se konfiguriraju u FreeRTOSConfig.h
datoteci. Te vrijednosti su već na početku namještene za rad u stvarnom vremenu
pa se neće mijenjati za ova mjerenja.
36
U FreeRTOS odgovor na pobudu izveden je unutar prekidnog potprograma i
unutar dretve koju budi prekidni potprogram, analogno izvedbama u jezgrenom
načinu rada Linuxa. Izvedba s prekidnim potprogramom ne bi trebala pokazivati
značajne razlike u odnosu na onu u operacijskom sustavu Linux. Izvedba s
dretvom trebala bi imati nešto manje kašnjenje i puno veću otpornost na
opterećenost procesora.
Kao mehanizam buđenja i zaustavljanja dretve koristi se semafor. Za buđenje
neke konkretne dretve bolje je koristiti mehanizam FreeRTOS-a koji se zove
izravne obavijesti (engl. direct notification). Taj mehanizam je nešto brži i troši
manje memorije, ali može obavještavati samo jednu dretvu odjednom. On se ne
koristi u ovoj izvedbi jer je uveden tek od verzije 8.2.0 FreeRTOS-a, koja nije
dostupna za Raspberry Pi.
void interruptHandler(int irqn, void* pParam) {
int lvl = ReadGpio(IN_PIN);
SetGpio(OUT_PIN, lvl);
ClearGpioInterrupt(IN_PIN);
}
int main(void) {
...
EnableGpioDetect(IN_PIN, DETECT_RISING);
EnableGpioDetect(IN_PIN, DETECT_FALLING);
RegisterInterrupt(BCM2835_IRQ_ID_GPIO_0,
interruptHandler,
NULL);
EnableInterrupt(BCM2835_IRQ_ID_GPIO_0);
...
}
Isječak koda 4.5 Izvedba s prekidnim potprogramom (FreeRTOS)
void interruptHandler(int irqn, void* pParam) {
xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(semaphore,
&xHigherPriorityTaskWoken);
if (xHigherPriorityTaskWoken == pdTRUE) {
portYIELD_FROM_ISR();
}
37
ClearGpioInterrupt(IN_PIN);
}
void gpioHandler() {
xSemaphoreTake(semaphore, 0);
while (1) {
xSemaphoreTake(semaphore, portMAX_DELAY);
int lvl = ReadGpio(IN_PIN);
SetGpio(OUT_PIN, lvl);
}
}
int main(void) {
...
EnableGpioDetect(IN_PIN, DETECT_RISING);
EnableGpioDetect(IN_PIN, DETECT_FALLING);
RegisterInterrupt(BCM2835_IRQ_ID_GPIO_0,
interruptHandler,
NULL);
EnableInterrupt(BCM2835_IRQ_ID_GPIO_0);
...
xTaskCreate(gpioHandler, "GPIO_HANDLER", 128, NULL, 4,
NULL);
...
}
Isječak koda 4.6 Izvedba s dretvom koja se budi semaforom (FreeRTOS)
Tablica 4.10 Rezultati mjerenja za FreeRTOS
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
95 percentil
99.7 percentil
Maksimalno kašnjenje
(μs)
Prekidni potprogram
Neopterećeno 6.762 7.231 7.333 18.95 19.91
Opterećeno 6.857 7.565 7.333 62.095 114.67
Dretva Neopterećeno 48.47 50.06 60.48 61.81 62.29
Opterećeno 48.67 51.31 61.52 110.95 134.1
38
Tablica 4.11 Podaci o propuštenim odzivima za FreeRTOS
Mjerenje Udio propuštenih odziva
na baznoj frekvenciji Frekvencija bez
propuštenih odziva (Hz)
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Dretva Normalno 0.003% 108
Opterećeno 0% 1293
Kašnjenje prekidnog potprograma nešto je veće nego isto to kašnjenje
operacijskog sustava Linux. S obzirom da je ova verzija FreeRTOS-a
neslužbena, moguće je da suboptimalno iskorištava sklopovlje za rad s prekidima
te zbog toga stvara veća kašnjenja. Rezultati dretvene izvedbe su značajno lošiji,
osim u maksimalnim vremenima. Treba napomenuti da usporedba nije baš
najpravednija s obzirom da se na Linuxu koristio mehanizam koji dretvu budi
izravno, dok se u ovom slučaju, dretva budi preko semafora. Pravednija
usporedba bi bila kada bi se umjesto semafora koristile izravne obavijesti.
Dijagrami za ova mjerenja su vrlo geometrijski pravilni i imaju interesantne oblike
(Slika 4.7, Slika 4.8, Slika 4.9 i Slika 4.10). Razlog tome je što FreeRTOS izvršava
samo kod jezgre i korisnički kod koji mu je eksplicitno dan. Osim navedenog,
nema drugih zadataka koji se izvršavaju kao na Linuxu pa u sustavu ima manje
stohastičkih faktora. Sustav se ponaša vrlo periodički i gotovo da nema razlike
između stanja sustavu u nekom trenutku t i stanja sustava u trenutku
pomaknutom za period t + T. Neka mjerenja imaju elemente koji naizgled rastu
linearno. Ovaj fenomen se može objasniti time što su i ispitivani i mjerni sustav
periodički sustavi, koji nisu usklađeni svojima periodima. Npr. recimo da ispitivani
sustav ima određeni zadatak koji se ne smije prekidati, javlja se svakih 10 ms i
traje 500 μs. Recimo da mjerni sustav šalje bridove koje treba obraditi svakih 490
μs. Prvi brid će doći u 490-oj μs dok traje neprekidivi zadatak te će morati čekati
do 500-te μs, dakle 10 μs. 103. brid će doći u 50470-oj μs te će morati čekati do
50500-te μs, dakle 30 μs. 205. brid će čekati 50 μs, 307. će čekati 70 μs itd. Ako
se iscrta graf kašnjenja ovih bridova, svaki 102. brid će linearno rasti i dobit ćemo
nešto nalik dijagramu kojeg smo dobili mjerenjem.
39
Zanimljivo je i što je mjerenje za izvedbu s prekidnim potprogramom uz
opterećenje sustava jedino mjerenje za koje je prosječno kašnjenje veće nego
95. percentil. Razlog tome su relativno česta visoka kašnjenja (Slika 4.8), koja
povećavaju prosjek, ali su ipak rjeđi od 1 u 20 slučajeva, pa ne utječu na taj
percentil.
Slika 4.7 Kašnjenje za izvedbu s prekidnim potprogramom bez opterećenja sustava
(FreeRTOS)
Slika 4.8 Kašnjenje za izvedbu s prekidnim potprogramom uz opterećenje sustava
(FreeRTOS)
40
Slika 4.9 Kašnjenje za izvedbu s dretvom bez opterećenja sustava (FreeRTOS)
Slika 4.10 Kašnjenje za izvedbu s dretvom uz opterećenje sustava (FreeRTOS)
Još jedna zanimljivost u ovim mjerenju izvedbe s dretvom su nasumični
propušteni odzivi kod dretvene izvedbe. Naime, pri mjerenju su se pojavljivali
propušteni odzivi, ali smanjenje frekvencije generiranja bridova nije u svakom
slučaju rezultiralo njihovim manjim brojem (Tablica 4.12). Također, isto mjerenje
ponovljeno uz opterećenje nije imalo propuštene odzive, iako opterećenje jest
povećalo kašnjenje. Zaključak je da i to, barem jednim dijelom, proizlazi od
nepouzdane verzije operacijskog sustava.
41
Tablica 4.12 Broj propuštenih bridova u ovisnosti o vrijednosti preddjelila frekvencije
generiranja bridova
Vrijednost preddjelila frekvencije Broj propuštenih bridova
1 4
2 74
6 25
8 14
12 0
42
5. ZAKLJUČAK
Iz danih mjerenja može se zaključiti da su i Linux i FreeRTOS primjereni za blage
sustave za rad u stvarnom vremenu koji imaju vremenske zahtjeve u redovima
veličine od 1 ms, uz pretpostavku da je programska podrška ispravno izvedena.
Podrška za sustave za rad u stvarnom vremenu na operacijskom sustavu Linux
trebala bi biti izvedena unutar jezgrenog načina rada, inače su joj vremenska
svojstva značajno narušena. Optimiranje jezgre Linux za rad u stvarnom
vremenu nije značajno utjecalo na performanse, često je utjecalo negativno, te
se smatra od veće koristi za sustave okidane protokom vremena nego za sustave
okidane vanjskim događajima.
Verzija FreeRTOS-a za Raspberry Pi se nije pokazala dovoljno stabilnom da bi
bila korisna u stvarnoj upotrebi. U najmanju ruku, treba otkriti uzrok propuštenih
odziva prije nego bi se on mogao pouzdano koristiti.
Kako bi se utvrdilo mogu li se ovi sustavi koristiti u strogim sustavima za rad u
stvarnom vremenu, potrebno bi bilo izvršiti duža, temeljitija i raznovrsnija
mjerenja. Maksimalna vremena izračunata u ovom radu mogu ipak poslužiti kao
početna procjena za sustave sa strogim vremenskim ograničenjima.
43
LITERATURA
1. Jelenković L., Skripta iz predmeta „Sustavi za rad u stvarnom vremenu“,
http://www.zemris.fer.hr/~leonardo/srsv/skripta/SRSV-skripta.pdf, lipanj
2018.
2. Usage statistics and market share of Unix for websites,
https://w3techs.com/technologies/details/os-unix/all/all, lipanj 2018.
3. 2017 Embedded Markets Study, travanj 2017.
https://m.eet.com/media/1246048/2017-embedded-market-study.pdf,
pristupljeno lipanj 2018.
4. http://www.embeddedcraft.org/listrtos.html, lipanj 2018.
5. https://freertos.org, lipanj 2018.
6. https://www.slant.co/topics/1629/~single-board-computers, lipanj 2018.
7. Raspberry Pi 3 Model B, https://www.raspberrypi.org/products/raspberry-
pi-3-model-b/, lipanj 2018.
8. https://github.com/Forty-Tw0/RaspberryPi-FreeRTOS, lipanj 2018.
9. Benchmarking Raspberry Pi GPIO Speed, 2015.
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-
speed/, pristupljeno lipanj 2018.
10. Stress-ng, http://kernel.ubuntu.com/~cking/stress-ng/, lipanj 2018.
11. RFC: documentation of the autogroup feature, studeni 2016.
http://lkml.iu.edu/hypermail/linux/kernel/1611.3/00766.html, lipanj 2018.
12. Kljajo Petković A., Sustav za ispitivanje odziva ugradbenih računalnih
sustava za rad u stvarnom vremenu, diplomski rad, Fakultet
elektrotehnike i računarstva, Sveučilište u Zagrebu, 2017.
13. Reference manual: STM32F405/415, STM32F407/417, STM32F427/437
and STM32F429/439 advanced Arm®-based 32-bit MCUs,
https://www.st.com/content/ccc/resource/technical/document/reference_
manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf
/jcr:content/translations/en.DM00031020.pdf, lipanj 2018.
14. pigpio C Interface, http://abyz.me.uk/rpi/pigpio/cif.html, lipanj 2018.
15. Linux Loadable Kernel Module HOWTO, http://tldp.org/HOWTO/Module-
HOWTO/, lipanj 2018.
44
16. ARM®Cortex®-A53 MPCore Processor: Technical Reference Manual,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DDI0500D_c
ortex_a53_r0p2_trm.pdf, lipanj 2018.
17. Basic Linux from a Real-Time Perspective,
http://linuxrealtime.org/index.php/Basic_Linux_from_a_Real-
Time_Perspective, lipanj 2018.
18. A realtime preemption overview, kolovoz 2005.,
https://lwn.net/Articles/146861, pristupljeno lipanj 2018.
Slike:
• Slika 2.1 Usporedba strogih i blagih (ublaženih) SRSV-a,
Jelenković L., Skripta iz predmeta „Sustavi za rad u stvarnom vremenu“,
http://www.zemris.fer.hr/~leonardo/srsv/skripta/SRSV-skripta.pdf, lipanj
2018.
45
SAŽETAK
Naslov: Sustav za ispitivanje odziva na vanjski događaj za operacijske sustave
namijenjene ugradbenim računalima
Operacijski sustav Linux je popularan za primjenu na ugradbenim računalima, ali
se dugo nije smatrao dovoljno pouzdanim za rad u stvarnom vremenu. Novije
verzije su napravile veliki napredak u tom području. U ovom radu je ispitano u
kolikoj mjeri je Linux sada spreman za rad u stvarnom vremenu, koji faktori utječu
na njegova vremenska svojstva te kakva su ona u usporedbi s operacijskim
sustavom FreeRTOS.
Mjerena veličina je kašnjenje između rastućeg ili padajućeg brida na ulaznom
GPIO pinu i istog brida na izlaznom pinu. Kašnjenje se mjerilo na posebno
razvijenom mjernom sustavu koji se sastoji od dva STM mikroupravljača.
Rezultati pokazuju da je Linux na Raspberry Pi sklopovskoj platformi dovoljno
dobar za blage sustave za rad u stvarnom vremenu, ako se kod na njemu izvodi
u jezgrenom načinu rada.
Ključne riječi: Raspberry Pi, Linux, FreeRTOS, rad u stvarnom vremenu, odziv,
kašnjenje, jezgra, operacijski sustav, ugradbeni sustavi
46
SUMMARY
Title: External Event Response Time Measurement System for Operating
Systems Used in Embedded Devices
The Linux operating system is popular for embedded computing, but, for a long
time, was not considered reliable enough for real-time applications. More recent
versions demonstrate a major improvement in this regard. Within this thesis,
testing was performed to determine to what extent is Linux ready for real-time
applications, which factors affect its time characteristics and how they compare
with FreeRTOS.
Measured quantity is the delay between a rising or a falling edge on an input
GPIO pin and the same edge on an output pin. The delay was measured using a
specially developed measurement system consisting of two STM
microcontrollers.
The results demonstrate that Linux run on a Raspberry Pi hardware platform is
good enough for soft real-time applications, if the code on it is run in kernel mode.
Keywords: Raspberry Pi, Linux, FreeRTOS, real-time, response, delay, kernel,
operating system, embedded systems
47
PRIVITAK A: TABLICE SVIH MJERENJA
Tablica 5.1 Kašnjenja za sva mjerenja
Mjerenje Minimalno kašnjenje
(μs)
Prosječno kašnjenje
(μs)
Maksimalno kašnjenje (μs)
Korisnički način rada
Asinkrona izvedba
Normalno 31.42 42.60 122.0
Opterećeno 30.76 102.26 1493
Izvedba s petljom
radilicom
Normalno 0.5714 0.6619 213.2
Opterećeno 0.5714 30 994 935 390
Jezgreni način rada
Prekidni potprogram
Normalno 2.476 4.627 18.19
Opterećeno 1.238 5.202 279.8
Jezgrena dretva
Normalno 11.71 16.82 61.91
Opterećeno 8.381 17.86 647.3
Jezgreni način rada uz PREEMPT politiku
Prekidni potprogram
Normalno 3.048 6.000 37.24
Opterećeno 1.810 6.272 257.9
Jezgrena dretva
Normalno 16.48 22.81 64.57
Opterećeno 12.00 24.995 710.1
Jezgreni način rada uz
PREEMPT_RT_FULL politiku
Prekidni potprogram
Normalno 2.857 5.627 59.81
Opterećeno 2.571 16.46 509.4
Jezgrena dretva
Normalno 12.67 19.03 62.10
Opterećeno 9.523 28.22 425.2
Jezgreni način rada uz radnu frekvenciju jezgre od 1000 Hz
Prekidni potprogram
Normalno 2.476 4.807 29.91
Opterećeno 1.238 6.268 273.2
Jezgrena dretva
Normalno 11.71 17.77 47.24
Opterećeno 9.714 22.74 400.4
FreeRTOS
Prekidni potprogram
Normalno 6.762 7.231 19.91
Opterećeno 6.857 7.565 114.67
Dretva Normalno 48.47 50.06 62.29
Opterećeno 48.67 51.31 134.1
48
Tablica 5.2 Propušteni odzivi za sva mjerenja
Mjerenje
Udio propuštenih odziva na
baznoj frekvenciji
Frekvencija bez
propuštenih odziva (Hz)
Korisnički način rada
Asinkrona izvedba
Normalno 0 1293
Opterećeno 1.29% 143.7
Izvedba s petljom
radilicom
Normalno 0 1293
Opterećeno - -
Jezgreni način rada
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0.005% 647
Jezgrena dretva
Normalno 0% 1293
Opterećeno 0.08% 647
Jezgreni način rada uz PREEMPT politiku
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Jezgrena dretva
Normalno 0% 1293
Opterećeno 0.01% 431
Jezgreni način rada uz PREEMPT_RT_FULL
politiku
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0.012% 431
Jezgrena dretva
Normalno 0% 1293
Opterećeno 0.015% 431
Jezgreni način rada uz radnu frekvenciju jezgre
od 1000 Hz
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Jezgrena dretva
Normalno 0% 1293
Opterećeno 0.018% 431
FreeRTOS
Prekidni potprogram
Normalno 0% 1293
Opterećeno 0% 1293
Dretva Normalno 0.003% 108
Opterećeno 0% 1293