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