Slovensk´
a technick´
a univerzita v Bratislave
Fakulta informatiky a informaˇ
cn´
ych technol´
ogi´ı
FIIT-13428-48035
Bc. Martin Vojtko
´
ˇ Y
´ SYSTEM
´
´
MODULARNY
OPERACN
PRE VNORENE
´
SYSTEMY
Diplomov´
a pr´
aca
ˇ
Studijn´
y program:
ˇ
Studijn´
y odbor:
Miesto vypracovania:
Ved´
uci pr´ace:
m´aj 2012
Poˇc´ıtaˇcov´e a komunikaˇcn´e syst´emy a siete
9.2.4 Poˇc´ıtaˇcov´e inˇzinierstvo
´
Ustav
poˇc´ıtaˇcov´
ych syst´emov a siet´ı, FIIT STU v Bratislave
doc. Ing. Tibor Krajˇcoviˇc PhD.
Zadanie diplomovej pr´
ace
Meno ˇstudenta: Bc. Martin Vojtko
ˇ
Studijn´
y program: Poˇc´ıtaˇcov´e a komunikaˇcn´e syst´emy a siete
ˇ
Studijn´
y odbor: Poˇc´ıtaˇcov´e inˇzinierstvo
N´azov pr´ace: Modul´
arny operaˇ
cn´
y syst´
em pre vnoren´
e syst´
emy
Samostatnou v´
yskumnou a v´
yvojovou ˇcinnost’ou v r´amci predmetov Diplomov´
y projekt I,
II, III vypracujte diplomov´
u pr´acu na t´emu, vyjadren´
u vyˇsˇsie uveden´
ym n´azvom tak, aby
ste dosiahli tieto ciele:
Vˇseobecn´y ciel’:
Vypracovan´ım diplomovej pr´ace preuk´aˇzte, ako ste si osvojili met´ody a postupy rieˇsenia relat´ıvne rozsiahlych projektov, schopnost’ samostatne a tvorivo rieˇsit’ zloˇzit´e u
´lohy aj v´
yskumn´eho charakteru v s´
ulade so s´
uˇcasn´
ymi met´odami a postupmi ˇstudovan´eho odboru vyuˇz´ıvan´
ymi v pr´ısluˇsnej oblasti a schopnost’ samostatne, tvorivo a kriticky pristupovat’ k anal´
yze
moˇzn´
ych rieˇsen´ı a k tvorbe modelov.
ˇ
Specifick´
y ciel’:
Vytvorte rieˇsenie, zodpoved´
uce n´avrhu textu zadania, ktor´
y je pr´ılohou tohto zadania. N´avrh
bliˇzˇsie opisuje t´emu vyjadren´
u n´azvom. Tento opis je z´av¨azn´
y, m´a vˇsak r´amcov´
y charakter,
aby vznikol dostatoˇcn´
y priestor pre Vaˇsu tvorivost’.
Riad’te sa pokynmi V´aˇsho ved´
uceho.
Pokial’ v priebehu rieˇsenia, opieraj´
uc sa o hlbˇsie poznanie s´
uˇcasn´eho stavu v pr´ısluˇsnej oblasti
alebo o priebeˇzn´e v´
ysledky V´aˇsho rieˇsenia alebo o in´e z´avaˇzn´e skutoˇcnosti, dospejete spoloˇcne
s Vaˇs´ım ved´
ucim k presvedˇceniu, ˇze nieˇco v texte zadania a/alebo v n´azve by sa malo zmenit’,
navrhnite zmenu. Zmena je spravidla moˇzn´a len pri dosiahnut´ı kontroln´eho bodu.
´
Miesto vypracovania: Ustav
poˇc´ıtaˇcov´
ych syst´emov a siet´ı, FIIT STU v Bratislave
Ved´
uci pr´ace: doc. Ing. Tibor Krajˇ
coviˇ
c, PhD.
Term´ıny odovzdania:
podl’a harmonogramu ˇst´
udia platn´eho pre semester, v ktorom m´ate pr´ısluˇsn´
y predmet (Diplomov´
y projekt I, II, III) absolvovat’ podl’a V´aˇsho ˇstudijn´eho pl´anu
Predmety odovzdania:
V kaˇzdom predmete dokument podl’a pokinov na www.fiit.stuba.sk v ˇcasti: home> Inform´acie o> ˇst´
udiu> organiz´acia ˇst´
udia> diplomov´
y projekt
V Bratislave dˇ
na 21. febru´ara 2011
ˇ ca´k, PhD.
doc. Ing. Pavel Ciˇ
poveren´
y veden´ım u
´stavu
IV
N´
avrh zadania diplomovej pr´
ace
Fin´alna verzia1
ˇ
Student:
Meno, Priezvisko, tituly:
ˇ
Studijn´
y program:
Kontakt:
Martin Vojtko, Bc.
Poˇc´ıtaˇcov´e a komunikaˇcn´e syst´emy a siete
[email protected]
Ved´
uci projektu:
Meno, Priezvisko, tituly:
Pracovisko, adresa:
Kontakt:
doc. Ing. Tibor Krajˇcoviˇc, PhD.
´
Ustav
poˇc´ıtaˇcov´
ych syst´emov a siet´ı FIIT STU,
Ilkoviˇcova 3, 842 16 Bratislava 4
[email protected]
Projekt:
N´
azov:
Miesto vypracovania:
Oblast’ problematiky:2
Modul´arny operaˇcn´
y syst´em pre vnoren´e syst´emy
´
Ustav poˇc´ıtaˇcov´
ych syst´emov a siet´ı FIIT STU,
Bratislava
Operaˇcn´e syst´emy pre vnoren´e syst´emy
Text zadania:
Navrhnite a implementujte vybran´e ˇcasti modul´arneho operaˇcn´eho syst´emu pre vnoren´e
syst´emy, ktor´
y bude spravovat’ nad n´ım spusten´e procesy.
Predmetom anal´
yzy bude spracovanie pr´ıstupov jednotliv´
ych ˇcast´ı jadra modul´arneho
operaˇcn´eho syst´emu a ich pouˇzitia v praxi, anal´
yza pouˇzitia ˇstatistick´
ych meran´ı v´
ykonnosti modulov. Anal´
yza s´
uˇcasn´
ych operaˇcn´
ych syst´emov pre vnoren´e syst´emy.
Predmetom n´avrhu bude n´avrh vybran´
ych ˇcast´ı modul´arneho operaˇcn´eho syst´emu, ktor´e
boli predmetom anal´
yzy a n´avrh ˇstatistick´eho modulu.
Predmetom implement´acie bude modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em a testovacia aplik´acia pre hostitel’sk´
y poˇc´ıtaˇc. Jednotliv´e ˇcasti operaˇcn´eho syst´emu implementujte viacer´
ymi pr´ıstupmi, tak aby tvorili moduly. Operaˇcn´
y syst´em bude modul´arne
rozˇs´ıritel’n´
y o ˇstatistick´e spracovanie, tak aby sa dali analyzovat’ jednotliv´e kombin´acie
modulov z hl’ad´ısk r´eˇzie jadra operaˇcn´eho syst´emu, dodrˇzania limitov procesov re´alneho
ˇcasu, f´erovosti sp´
uˇst’ania procesov, komunik´acie medzi procesmi. Porovnajte modul´arny
operaˇcn´
y syst´em s in´
ymi operaˇcn´
ymi syst´emami. Na otestovanie implementovan´eho modul´arneho operaˇcn´eho syst´emu pouˇzite vhodn´
u v´
yvojov´
u dosku.
150-200 slov, ktor´e opisuj´
u probl´em v kontexte s´
uˇcasn´eho stavu vr´
atane motiv´
acie a smerov rieˇsenia
Vel’kost’ jednotliv´
ych pol´ı pre vyp´lˇ
nanie nemoˇzno menit’. N´avrh zadania vytlaˇcit’ obojstranne na jeden
list papiera.
2
Identifik´
acia oblasti v r´
amci odboru ˇst´
udia, na ktor´
u sa projekt prim´arne viaˇze
1
Literat´
ura:
• Tanenbaum, A.S.: Modern Operating systems 2nd edition, Prentice Hall, 2001.
ISBN 0-13-031358-0
• Tanenbaum, A.S and Woodhull, A.S.: Operating systems, Design and Implementation 3nd edition, PrenticeHall, 2006. ISBN 0-13-142938-8
ˇ
• Stefanoviˇ
c, J.: Z´aklady operaˇcn´
ych syst´emov, STU, 2007. ISBN 978-80-227-2586-6
2-3 vedeck´e zdroje, kaˇzd´
y na samostatnom riadku a vo form´
ate zodpovedaj´
ucom bibliografick´
ym odkazom podl’a
normy STN ISO 690, ktor´e sa viaˇzu k t´eme zadania a preukazuj´
u v´
yskumn´
u povahu probl´emu a jeho aktu´
alnost’
(uved’te vˇsetky potrebn´e u
´daje na identifik´
aciu zdroja, priˇcom uprednostnite vedeck´e pr´ıspevky v ˇcasopisoch a medzin´
arodn´
ych konferenci´
ach)
Vyˇsˇsie je uveden´
y n´avrh diplomov´eho projektu, ktor´
y vypracoval Bc. Martin Vojtko, konzultoval a osvojil si ho doc. Ing. Tibor Krajˇcoviˇc, PhD. a s´
uhlas´ı, ˇze bude tak´
yto projekt viest’
v pr´ıpade, ˇze bude pridelen´
y tomuto ˇstudentovi.
V Bratislave dˇ
na 18.11.2010
Podpis ˇstudenta
Podpis ved´
uceho projektu
Vyjadrenie garanta predmetu Diplomov´
y projekt I, II, III
N´avrh zadania schv´alen´
y: a´no / nie3
Dˇ
na: 21.2.2011
Podpis garanta
3
Nehodiace sa preˇciarknite
´
ANOTACIA
Slovensk´a technick´a univerzita v Bratislave
ˇ YCH
´
´ ´I
FAKULTA INFORMATIKY A INFORMACN
TECHNOLOGI
ˇ
Studijn´
y program: Poˇc´ıtaˇcov´e a Komunikaˇcn´e Syst´emy a Siete
Autor: Bc. Martin Vojtko
Diplomov´a pr´aca: Modul´arny operaˇcn´
y syst´em pre vnoren´e syst´emy
Ved´
uci diplomovej pr´ace: doc. Ing. Tibor Krajˇcoviˇc PhD.
m´aj 2012
Predmetom tohto projektu bol n´avrh a implement´acia vybran´
ych konceptov operaˇcn´
ych
syst´emov pre vnoren´e syst´emy. V pr´aci sme analyzovali jednotliv´e koncepty operaˇcn´
ych syst´emov a uviedli sme v´
yber troch operaˇcn´
ych syst´emov z danej oblasti, ktor´e sme povaˇzovali
za najpodobnejˇsie naˇsej predstave o vnorenom operaˇcnom syst´eme.
Na z´aklade anal´
yzy sme ˇspecifikovali poˇziadavky na nov´
y operaˇcn´
y syst´em, ktor´
y sme
nazvali Modul´arny operaˇcn´y syst´em. S´
uˇcast’ou ˇspecifik´acie sa stal aj hrub´
y n´avrh jadra a
perif´erie operaˇcn´eho syst´emu.
Vych´adzaj´
uc zo ˇspecifik´acie sme navrhli jednotliv´e moduly OS. V n´avrhu sme sa venovali spr´ave pam¨ati, riadeniu procesov, pl´anovaniu procesov, komunik´aci´ı procesov, riadeniu
pr´ıstupu, riadeniu spotreby energie, riadeniu vstupov a v´
ystupov, ˇstatistike a perif´erii OS.
V implementaˇcnej f´aze projektu sem vybrali niektor´e ˇcasti operaˇcn´eho syst´emu, ktor´e
sme implementovali. V´
ysledkom je funguj´
uce jadro OS pozost´avaj´
uce zo Spr´avcu pam¨ate,
Spr´avcu procesov, Pl´anovania procesov, Riadenia pr´ıstupu a ˇstatistiky. Modul pl´anovania
procesov sme implementovali viacer´
ymi pr´ıstupmi. Siln´
ymi str´ankami implementovan´eho OS
sa stali modul´arnost’, konfigurovatel’nost’ a prenositel’nost’.
Na zbieranie ˇstatistick´
ych d´at sme implementovali aplik´aciu, ktor´a zbiera, spracuje a
zobrazuje inform´acie odosielan´e ˇstatistick´
ym modulom cez s´eriov´e rozhranie.
Operaˇcn´
y syst´em sme otestovali pomocou jednoduchej programovej ˇstrukt´
ury. V´
ysledkom testovania je aj porovnanie niektor´
ych konfigur´aci´ı operaˇcn´eho syst´emu a porovnanie s
analyzovan´
ym operaˇcn´
ym syst´emom.
ANNOTATION
Slovak University of Technology Bratislava
FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES
Degree Course: Computer and Communication Systems and Networks
Author: Bc. Martin Vojtko
Master’s Thesis: Modular Embedded Operating System
Supervisor: doc. Ing. Tibor Krajˇcoviˇc PhD.
2012, May
The objective of this project is a proposal and an implementation of parts of an embedded
operating system. Part of project was analysis of the operating systems concepts and an
analysis of chosen embedded operating systems.
In the work we specified requirements, based on the analysis, to new OS that we call
The Modular Operating System. In the specification is rough proposal, where we specifies a
kernel and peripheries.
From the specification we proposed modules of the OS. We proposed Memory Management Module, Task Management Module, Scheduler, Inter-process Communication Module,
Access Control Module, Power Management Module, statistical module, I/O Management
Module and peripheries of the OS.
In the implementation phase we chose some parts of the OS from the proposal that we
implemented. Results of the implementation are Memory Management Module, Task Management Module, Scheduler, Inter-process Communication Module, Access Control Module,
statistical module. We implemented the Scheduler by several approaches. Strengths of new
OS are modularity, portability and configurability.
We implemented an application witch catches, processes and displays information sent
by the OS through serial interface.
The operating system was tested in several configurations by simple program structure.
Result of the tests is comparison between several configurations of the OS.
X
Obsah
Zadanie diplomovej pr´
ace
III
N´
avrh zadania diplomovej pr´
ace
V
´
ANOTACIA
VII
ANNOTATION
IX
´
1 Uvod
1.1 Pojmy a skratky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Anal´
yza
2.1 OS ako rozˇs´ırenie hardv´eru a riadenie zdrojov
2.2 Koncepty OS . . . . . . . . . . . . . . . . . .
2.2.1 Proces . . . . . . . . . . . . . . . . . .
2.2.2 Uviaznutie . . . . . . . . . . . . . . . .
2.2.3 Spr´ava pam¨ate . . . . . . . . . . . . .
2.2.4 Spr´ava vstupov a v´
ystupov . . . . . . .
2.3 Triedenie OS . . . . . . . . . . . . . . . . . .
2.4 Jadro operaˇcn´eho syst´emu . . . . . . . . . . .
2.4.1 Riadenie procesov . . . . . . . . . . . .
2.4.2 Spr´ava pam¨ate . . . . . . . . . . . . .
2.4.3 Spr´ava vstupov a v´
ystupov . . . . . . .
ˇ
2.5 Statistick´
e merania . . . . . . . . . . . . . . .
2.6 Prehl’ad vnoren´
ych operaˇcn´
ych syst´emov . . .
2.6.1 AvrX . . . . . . . . . . . . . . . . . . .
2.6.2 FreeRTOS . . . . . . . . . . . . . . . .
2.6.3 TinyOS . . . . . . . . . . . . . . . . .
ˇ
3 Specifik´
acia
3.1 Poˇziadavky na OS . . . . . . . . . .
3.2 N´avrh ˇstrukt´
ury operaˇcn´eho syst´emu
3.3 Programov´
y a procesn´
y model . . . .
3.4 Riadenie procesov . . . . . . . . . . .
3.5 Spr´ava pam¨ate . . . . . . . . . . . .
3.6 Spr´avca V/V zariaden´ı . . . . . . . .
3.7 Riadenie spotreby energie . . . . . .
ˇ
3.8 Statistika
. . . . . . . . . . . . . . .
3.9 Perif´eria operaˇcn´eho syst´emu . . . .
XI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
8
9
9
10
11
12
12
13
14
14
14
15
18
.
.
.
.
.
.
.
.
.
21
21
21
23
25
26
26
26
27
27
4 N´
avrh
4.1 Riadenie procesov . . . . . . .
4.1.1 Program . . . . . . . .
4.1.2 Proces . . . . . . . . .
4.1.3 Manaˇz´er u
´loh . . . . .
4.1.4 Pl´anovaˇc u
´loh . . . . .
4.1.5 Riadenie komunik´acie .
4.2 Spr´avca pam¨ate . . . . . . . .
4.3 Spr´avca V/V zariaden´ı . . . .
4.4 Riadenie spotreby energie . .
4.5 Riadenie pr´ıstupu . . . . . . .
4.6 Perif´eria Operaˇcn´eho syst´emu
4.7 V´
yber platformy . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
31
32
33
35
36
36
37
37
38
5 Implement´
acia
ˇ
5.1 Strukt´
ura zdrojov´
ych k´odov MOS . . . . . .
5.2 D´atov´e ˇstrukt´
ury sp´ajan´
y zoznam a rad . . .
5.3 Spr´avca pam¨ate . . . . . . . . . . . . . . . .
5.4 Riadenie procesov . . . . . . . . . . . . . . .
5.4.1 Pl´anovaˇc . . . . . . . . . . . . . . . .
5.4.2 Manaˇz´er u
´loh . . . . . . . . . . . . .
5.4.3 Riadenie komunik´acie . . . . . . . . .
5.5 Riadenie Pr´ıstupu . . . . . . . . . . . . . . .
5.5.1 Ob´alka volania . . . . . . . . . . . .
ˇ
5.6 Statistick´
y modul . . . . . . . . . . . . . . .
5.6.1 S´eriov´a komunik´acia . . . . . . . . .
5.6.2 Odosielan´e d´ata . . . . . . . . . . . .
5.7 Platformovo z´avisl´e ˇcasti MOS . . . . . . . .
5.7.1 Prepnutie do chr´anen´eho reˇzimu . . .
5.7.2 Prepnutie kontextu . . . . . . . . . .
5.8 Podporn´a aplik´acia na hostitel’skom poˇc´ıtaˇci
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
44
44
45
50
51
51
52
52
52
53
53
54
56
6 Testovanie
6.1 Testovacia zostava . . . . . . . .
6.2 Testovan´a programov´a ˇstrukt´
ura .
6.3 Testovan´e konfigur´acie MOS . . .
6.3.1 Pl´anovanie Round-Robin .
6.3.2 Pl´anovanie s prioritou . .
6.4 Prepnutie u
´lohy . . . . . . . . . .
6.5 Vyuˇzitie pam¨ate d´at . . . . . . .
6.6 Vyuˇzitie pam¨ate programu . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
60
60
63
65
65
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Zhodnotenie
67
Literat´
ura
69
A Digit´
alne m´
edium
71
XII
B V´
yvoj´
arska pr´ıruˇ
cka
73
C Pouˇ
z´ıvatel’sk´
a pr´ıruˇ
cka
75
XIII
´
1. Uvod
´
1 Uvod
Operaˇcn´e syst´emy asi najlepˇsie pozn´ame z oblasti person´alnych poˇc´ıtaˇcov. Kaˇzd´
y person´alny
poˇc´ıtaˇc m´a nainˇstalovan´
y nejak´
y OS. Pravdaˇze person´alne poˇc´ıtaˇce nie s´
u jedinou dom´enou
operaˇcn´
ych syst´emov. Operaˇcn´e syst´emy sa pouˇz´ıvaj´
u aj v obrovsk´
ych s´alov´
ych poˇc´ıtaˇcoch,
v serveroch alebo aj v maliˇck´
ych platobn´
ych kart´ach a v neposlednom rade vo vnoren´
ych syst´emoch. Pr´ave vnoren´e operaˇcn´e syst´emy s´
u predmetom tejto pr´ace a jej ciel’om je navrhn´
ut’
a implementovat’ nov´
y vnoren´
y operaˇcn´
y syst´em s dˆorazom na jeho modul´arnost’. Vnoren´e
operaˇcn´e syst´emy s´
u v s´
uˇcastnosti na vzostupe a st´avaj´
u sa zauj´ımavou oblast’ou v´
yvoja.
V tejto s´
uvislosti sa moˇzno p´
ytat’: ”Preˇco by mali tak´e operaˇcn´e syst´emy pracovat’ aj vo
vnorenom syst´eme? Vˇsak to s ohl’adom na zloˇzitost’ hardv´eru vnoren´eho syst´emu nie je
potrebn´e!”. Dˆovodom preˇco zaviest’ operaˇcn´
y syst´em je napr´ıklad zv´
yˇsenie u
´rovne abstrakcie
n´avrhu programov, umoˇznenie paraleln´eho behu viacer´
ych procesov a najm¨a minimalizovanie spotreby energie. Nie je vˇzdy pravda, ˇze vnoren´
y syst´em je jednoduch´e zariadenie,
niektor´e syst´emy dosahuj´
u ba aj presahuj´
u v´
ykonov´e kapacity person´alnych poˇc´ıtaˇcov a v
tak´
ychto syst´emoch sa operaˇcn´
y syst´em urˇcite oplat´ı. Na trhu existuje mnoˇzstvo vnoren´
ych
operaˇcn´
ych syst´emov ˇci uˇz komerˇcn´
ych alebo vol’ne ˇs´ıritel’n´
ych. Preto sa ˇcitatel’ mˆoˇze p´
ytat’:
”Preˇco implementovat’ d’alˇs´ı?”. Dˆovod preˇco implementovat’ nov´
y operaˇcn´
y syst´em spoˇc´ıva
v moˇznosti k´
uskom prispiet’ k zlepˇseniu poznania nov´
ym pohl’adom a v poznan´ı a sk´
usenosˇ sia ot´azka, ktor´a si vyˇzaduje
tiach, ktor´e bud´
u nadobudnut´e poˇcas priebehu projektu. Dalˇ
odpoved’ vypl´
yva uˇz z n´azvu pr´ace ”Preˇco modul´arny?”. Odpoved’ je jednoduch´a, operaˇcn´e
syst´emy nie s´
u navrhovan´e s dˆorazom na modul´arnost’, a preto v pr´ıpade nasadenia na rˆozne
v´
ykonn´e syst´emy a architekt´
ury, vznikaj´
u probl´emy pri nasaden´ı. Modul´arny operaˇcn´
y syst´em bude navrhnut´
y tak, aby sa dal uˇsit’ na mieru ˇsirok´emu spektru architekt´
ur.
Dokument je ˇclenen´
y na ˇsest’ ˇcast´ı. V prvej ˇcasti, anal´
yze, sa venuje rozboru s´
uˇcastn´eho stavu v oblasti. V anal´
yze s´
u operaˇcn´e syst´emy rozobran´e vo vˇseobecnosti a osobitne
najm¨a pre vnoren´e operaˇcn´e syst´emy. V druhej ˇcasti, ˇspecifik´acii, je upriamen´
y pohl’ad na
vymedzenie vlastnost´ı, ktor´e bude modul´arny operaˇcn´
y syst´em sp´lˇ
nat’. Z´aroveˇ
n je v tejto
ˇcasti uveden´
y aj hrub´
y n´avrh architekt´
ury operaˇcn´eho syst´emu. Tretia ˇcast’ je venovan´a
n´avrhu Modul´arneho operaˇcn´eho syst´emu. V tejto ˇcasti sa na z´aklade anal´
yzy a ˇspecifik´aˇ
cie upresˇ
nuje fin´alna podoba MOS. Stvrt´
a ˇcast’, implement´acia, opisuje spˆosob realiz´acie
vybran´
ych ˇcast´ı MOS. Piata ˇcast’ pr´ace dokumentuje spˆosob ak´
ym bol MOS testovan´
y.
Posledn´a ˇcast’ fin´alne zhodnocuje pr´acu vykonan´
u poˇcas cel´eho obdobia a uv´adza n´apady
na d’alˇs´ı rozvoj MOS.
1
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
1.1
Pojmy a skratky
• Blokovan´
au
´ loha (Blocked task) - Je u
´loha, ktor´a pri pokuse o vstup do kritickej
oblasti je na urˇcen´
y ˇcasov´
y u
´sek nepl´anovan´a. Po uplynut´ı ˇcasov´eho u
´seku je znovu
pl´anovan´a.
• Pozastaven´
au
´ loha (Suspend task) - Je u
´loha, ktor´a pri pokuse o z´ıskanie respekt´ıve odoslanie d´at bola ne´
uspeˇsn´a z dˆovodu, ˇze odosielatel’ respekt´ıve prij´ımatel’ nie je
´
pripraven´
y. Uloha nie je pl´anovan´a k´
ym d´ata nie s´
u pripraven´e.
• Job - V oblasti mainframe operaˇcn´
ych syst´emov je job u
´loha alebo skupina u
´loh, ktor´e
sa vykon´avaj´
u na procesore v ˇcase v´
ypoˇctov´eho u
´tlmu u
´loh re´alneho ˇcasu. V kontexte
MOS je to u
´loha, ktor´a nebola re´alne vytvoren´a a pl´anovan´a (len odloˇzen´a) z dˆovodu
nedostatku v´
ypoˇctov´
ych alebo pam¨at’ov´
ych kapac´ıt.
• Kontroln´
y blok u
´ lohy TCB - (Task control Block) Z´aznam v tabul’ke spusten´
ych
ˇ
procesov. Casto
oznaˇcovan´
y aj ako Hlaviˇ
cka u
´ lohy.
• Kontroln´
y blok programu PCB -(Program control Block) Z´aznam v tabul’ke proˇ
gramov. Casto oznaˇcovan´
y aj ako Hlaviˇ
cka programu
• Modul´
arny operaˇ
cn´
y syst´
em (MOS) - Vnoren´
y operaˇcn´
y syst´em navrhnut´
y s
dˆorazom na modul´arnost’.
• Ob´
alka volania - Platformovo z´avisl´a funkcia zabezpeˇcuj´
uca bezpeˇcn´e a chr´anen´e
prepnutie procesora do chr´anen´eho reˇzimu a spustenie volania, ktor´e obal’uje.
• Orientovan´
y sled - Postupnost’ vrcholov a hr´an patriacich grafu G. Vrcholy sa v
slede striedaj´
u s hranami. Ak medzi dvoma vrcholmi v slede je hrana, tak t´ato hrana
je incidentn´a k obom vrcholom a plat´ı, ak je vrchol v slede pred hranou tak hrana z
vrcholu vych´adza a do vrcholu, ktor´
y je za n
ˇou, vch´adza.
• Procesn´
y graf - Graf reprezentuj´
uci stav procesov syst´emu v ˇcase, ktor´eho vrcholy
s´
u reprezentuj´
u procesy a hrany reprezentuj´
u vzt’ahy medzi procesmi.
• Programov´
y graf - Graf reprezentuj´
uci syst´em z hl’adiska vˇsetk´
ych moˇzn´
ych vzt’ahov
medzi procesmi programov.
´
´
• Uloha/proces
re´
alneho ˇ
casu, RT u
´ loha - (real-time task) Uloha,
ktorej dˆoleˇzit´
ym
faktorom spr´avneho vykon´avania je dodrˇzanie ˇcasov´
ych limitov vykon´avan´
ych oper´aci´ı.
• Vnoren´
y operaˇ
cn´
y syst´
em (VOS) - Operaˇcn´
y syst´em navrhnut´
y ˇspeci´alne pre
pr´acu na platform´ach vnoren´
ych syst´emov.
2
2. Anal´
yza
2 Anal´
yza
Vyvinutie operaˇcn´
ych syst´emov bolo prirodzenou reakciou na neust´ale narastaj´
ucu zloˇzitost’
v´
ypoˇctov´
ych syst´emov. K´od navrhnut´
y na riadenie vstupno/v´
ystupn´
ych zariaden´ı sa v minulosti neust´ale recykloval a vylepˇsoval. Tak´
yto k´od sa s´
ustred’oval do proced´
ur a kniˇzn´ıc, ktor´e
sa linkovali k hlavn´emu programu, aby sa zv´
yˇsila u
´roveˇ
n abstrakcie, a t´
ym aj zjednoduˇsilo
programovanie zariaden´ı. V´
ykonnost’ hardv´eru postupne r´astla a priˇsla potreba jeho efekt´ıvnejˇsieho vyuˇzitia. Jeden proces uˇz nestaˇcil efekt´ıvne pokryt’ v´
ypoˇctov´e kapacity zariaden´ı.
Viacej procesov na v´
ypoˇctovom syst´eme podmienilo vznik riadenia pr´ıstupu. Ak proces
nepotreboval moment´alne pracovat’, tak uvol’nil priestor in´emu. Prirodzen´
ym krokom v´
yvoja
bolo vytvorenie samostatn´eho procesu, ktor´
y prevzal riadenie pr´ıstupu ostatn´
ych procesov
k zariadeniu, prv´
y operaˇcn´
y syst´em.
2.1
OS ako rozˇ
s´ırenie hardv´
eru a riadenie zdrojov
Operaˇcn´
y syst´em rozˇsiruje a riadi pridruˇzen´
y hardv´er. Rozˇs´ırenie hardv´eru je potrebn´e vn´ımat’ ako zv´
yˇsenie abstrakcie pr´ıstupu k hardv´eru, nie ako pridanie novej funkcionality. Na
n´ızkej u
´rovni abstrakcie je program´ator prin´
uten´
y zaoberat’ sa zloˇzit´
ym ˇcasovan´ım zariadenia, registrami a riadiacimi sign´almi. Operaˇcn´
y syst´em t´
uto zloˇzitost’ zap´
uzdruje do formy
volan´ı proced´
ur s jednoduch´
ym komunikaˇcn´
ym rozhran´ım. To zloˇzit´e obstar´a operaˇcn´
y syst´em. Operaˇcn´
y syst´em tvor´ı spolu s hardv´erom virtu´alny stroj (obr. 2.1). [1, 2]
Obr. 2.1: Operaˇcn´
y syst´em ako rozˇs´ırenie hardv´eru
Riadenie zdrojov je dˆoleˇzitou u
´lohou operaˇcn´eho syst´emu. Hardv´erov´e zariadenia s´
u
´
komplexn´e jednotky obsahuj´
uce pam¨at’, zbernice, V/V rozhrania atd’. Ulohou
OS je poznat’ tieto zariadenia, poznat’ ich aktu´alny stav a riadit’ ich. Zariadenia s´
u pridel’ovan´e jednotliv´
ym procesom podl’a urˇcen´
ych pravidiel ˇcasov´eho a priestorov´eho multiplexu, pretoˇze
3
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
jedno zariadenie mˆoˇze byt’ pridelen´e v urˇcenom ˇcasovom u
´seku najviac jedn´emu procesu
(ˇcasov´
y multiplex). Pravidl´a priestorov´eho multiplexu sa zav´adzaj´
u v pr´ıpade, ˇze v syst´eme
existuje viacej zariaden´ı rovnak´eho typu, ku ktor´
ym chc´
u procesy prist´
upit’. [1]
Podmienkou ˇcasov´eho multiplexu je, ˇze v pridelenom ˇcasovom u
´seku smie byt’ zariadenie
pridelen´e pr´ave jedn´emu procesu. Po vyprˇsan´ı ˇcasu sa zariadenie odoberie procesu a pridel´ı sa
in´emu. Ak pridelen´e ˇcasov´e u
´seky s´
u tak mal´e, ˇze nie s´
u postrehnutel’n´e l’udsk´
ym vn´ıman´ım
vznik´a dojem, ˇze v jednom okamihu sa paralelne vykon´ava viacero procesov. Tak´
yto paralelizmus sa naz´
yva neprav´
y. Prav´
y paralelizmus je naopak skutoˇcn´e paraleln´e vykon´avanie
viacer´
ych procesov na viacer´
ych prostriedkoch. [3]
2.2
Koncepty OS
Najz´akladnejˇsie koncepty v oblasti n´avrhu a implement´acie OS s´
u v urˇcitej miere vlastn´e
kaˇzd´emu operaˇcn´emu syst´emu, nez´aleˇz´ı ˇci je OS navrhovan´
y pre person´alne poˇc´ıtaˇce alebo
vnoren´e aplik´acie. Najz´akladnejˇs´ımi konceptami, ktor´e s´
u vlastn´e skoro kaˇzd´emu OS s´
u [1]:
• Proces
• Uviaznutie
• Spr´ava pam¨ate
• Vstup a v´
ystup (V/V)
• S´
uborov´
y syst´em
• Bezpeˇcnost’
• Interpreter
Kaˇzd´
y operaˇcn´
y syst´em pozost´ava z jadra (kernel) a pridruˇzen´
ych vrstiev, ktor´e ho rozˇsiruj´
u.
Jadro ˇstandardn´eho vnoren´eho operaˇcn´eho syst´emu m´a za u
´lohu [4]:
• Riadit’ procesy
• Spravovat’ pam¨at’
• Spravovat’ Vstupno v´
ystupn´e zariadenia
Jadro pokr´
yva ˇstyri spom´ınan´e koncepty a to procesy, uviaznutia, spr´avu pam¨ate a V/V. Ostatn´e koncepty s´
u zahrnut´e do in´
ych vrstiev operaˇcn´eho syst´emu. Niektor´e jadr´a vnoren´
ych
operaˇcn´
ych syst´emov b´
yvaj´
u minimalizovan´e do takej miery, ˇze sa zaoberaj´
u len spr´avou
procesov a uviaznut´ı (obr. 2.2).
4
2. Anal´
yza
Obr. 2.2: Architekt´
ura OS
2.2.1
Proces
Objektom z´aujmu kaˇzd´eho operaˇcn´eho syst´emu je proces. Operaˇcn´
y syst´em spravuje procesy
a star´a sa, aby mal kaˇzd´
y proces moˇznost’ prist´
upit’ k hardv´erov´
ym prostriedkom.
Proces je program vykon´avan´
y na procesore. Jeden program smie byt’ reprezentovan´
y
v syst´eme viacer´
ymi procesmi na rˆoznych alebo rovnak´
ych etap´ach vykonania. Kaˇzd´
y proces m´a pridelen´
y priestor v pam¨ati, s ktor´
ym smie pracovat’. Pam¨at’ ˇstandardn´eho procesu
pozost´ava z ˇcasti uloˇzenej v hlavnej pam¨ati a ˇcasti uloˇzenej v registroch procesora. Obsah
hlavnej pam¨ati rozdel’ujeme na k´odov´
u ˇcast’ a d´atov´
u ˇcast’, ktor´a sa del´ı na statick´
u a dynamick´
u. V registroch s´
u ukladan´e inform´acie aktu´alneho stavu vykon´avania procesu, (programov´e poˇc´ıtadlo, pointer na vrchol z´asobn´ıka, registre, atd’.) ktor´
y spolu s hlaviˇckou procesu tvor´ı kontext procesu. Ak proces nie je pr´ave vykon´avan´
y tak jeho kontext sa nach´adza v
tabul’ke spusten´
ych procesov naz´
yvanej aj tabul’ka spusten´
ych u
´loh (obr. 2.3). Jeden z´aznam
v tabul’ke sa naz´
yva kontroln´
y blok u
´lohy (task control block, TCB)[1]
Obr. 2.3: Organiz´acia pam¨ate procesu
Kontext procesu zachyt´ava aktu´alny stav procesu. Poˇcas prepnutia u
´lohy je kontext procesu odkladan´
y do tabul’ky spusten´
ych u
´loh alebo do z´asobn´ıka dan´eho procesu. Odloˇzenie
z´avis´ı od implement´acie operaˇcn´eho syst´emu ale aj procesora. Niektor´e procesory maj´
u inˇstrukciu riadiacu odloˇzenie kontextu u
´lohy do z´asobn´ıka u
´lohy ˇco znaˇcne ur´
ychl’uje prepnutie
u
´lohy. Po sp¨atnom prepnut´ı u
´lohy sa proces znovu obnov´ı do pˆovodn´eho stavu preˇc´ıtan´ım
kontextu z TCB alebo zo z´asobn´ıka. Hlaviˇcka procesu obsahuje inform´acie o pr´ıstupov´
ych
pr´avach, priorite, ˇc´ısle procesu, pridelenej pam¨ati, rodiˇcovskom procese atd’. [3]
5
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Procesy tvoria hierarchiu rodiˇcov a det´ı. Tak´ato hierarchia sa s v´
yhodou reprezentuje
grafom. Pre potreby tejto pr´ace bola navrhnut´a konvencia zaloˇzen´a na te´ori´ı grafov, ktor´a
vhodne popisuje vzt’ahy medzi procesmi a bude pouˇzit´a pre opis procesn´eho a programov´eho
modelu Modul´arneho operaˇcn´eho syst´emu z hl’adiska riadenia procesov (obr. 3.2). Konvencia
ˇ
je podrobnejˇsie vysvetlen´a v ˇcasti Specifik´
acia.
Po inicializ´acii jadra vnoren´eho operaˇcn´eho syst´emu sa ˇstandardne spust´ı inicializaˇcn´
y
proces, ktor´
y sp´
uˇst’a svojich potomkov a potomkovia svojich potomkov. Na obr´azku 2.4 je
pr´ıklad grafu procesov, ktor´e s´
u spusten´e v syst´eme. Na vrchole ˇstrukt´
ury je inicializaˇcn´
y
proces, ktor´
y sp´
uˇst’a dve deti, tie sp´
uˇst’aj´
u svoje deti.
ˇ
Obr. 2.4: Strukt´
ura procesov, predok a potomok
Na to, aby sa proces mohol vykon´avat’ mus´ı byt’ najprv vytvoren´
y. Na vytvorenie procesu vo vnorenom syst´eme existuj´
u dva modely. Model fork/exec odvoden´
y zo ˇstandardu
IEEE/ISO POSIX 1003.1 a model spawn odvoden´
y z fork/exec modelu. Tieto modely s´
u
si vel’mi bl´ızke, pretoˇze jeden je odvoden´
y od druh´eho, ale existuj´
u v nich odliˇsnosti. Oba
modely maj´
u spoloˇcn´
u inicializaˇcn´
u ˇcast’ poˇcas, ktorej sa vytvor´ı kontext nov´eho procesu
a alokuje sa pam¨at’ov´
y priestor procesu. Modely sa l´ıˇsia v spˆosobe alokovania pam¨at’ov´eho
priestoru. Podl’a modelu fork/exec rodiˇcovsk´
y proces volan´ım fork() vytvor´ı k´opiu svojho
pam¨at’ov´eho priestoru pre dc´ersky proces. Exec() volanie n´asledne prep´ıˇse pˆovodn´
y obsah k´opie obsahom dc´erskeho procesu (obr. 2.5). V´
yhodou fork/exec modelu je moˇznost’
jednoduch´eho vloˇzenia inicializaˇcn´
ych d´at medzi volaniami fork() a exec(). Po volan´ı fork()
dc´ersky proces beˇz´ı eˇste v zdrojovom k´ode rodiˇcovsk´eho procesu. Pr´ıkladom je jednoduch´e
vytvorenie komunikaˇcn´eho vzt’ahu medzi procesmi. [4]
6
2. Anal´
yza
Obr. 2.5: Model fork/exec
Spawn model vytvor´ı nov´
y pam¨at’ov´
y priestor pre dc´ersky proces od zaˇciatku, ˇco umoˇzn´ı
aby dc´ersky proces bol okamˇzite pripraven´
y na vykon´avanie (obr. 2.6). V´
yhodou je r´
ychle
pripraven´a u
´loha ale napr´ıklad vytvorenie komunikaˇcn´eho vzt’ahu medzi dc´erskym a rodiˇcovsk´
ym procesom je komplikovanejˇsie. [4]
Obr. 2.6: Model spawn
Operaˇcn´
y syst´em ˇstandardne poskytuje pre procesy moˇznosti rˆoznych stavov spustenia.
Proces mˆoˇze byt’ vytvoren´y, pripraven´y, vykon´avan´y, pozastaven´y, blokovan´y a ukonˇcen´y
(obr. 2.7). Stav pozastaven´y sa s v´
yhodou pouˇz´ıva v pr´ıpade, ˇze proces ˇcak´a na d´ata z
extern´eho zdroja alebo od in´eho procesu. V pr´ıpade, ˇze je proces pozastaven´y nezarad’uje sa
do sp´
uˇst’acej rady a t´
ym nezaber´a prostriedky. Proces je zaraden´
y do sp´
uˇst’acej rady ked’ je
zdroj pripraven´
y. Stav blokovan´y je na rozdiel od stavu pozastaven´y zaraden´
y do sp´
uˇst’acej
rady po urˇcenom ˇcasovom u
´seku, napr´ıklad ak ˇcak´a proces na vstup do kritickej oblasti. V
stave vykon´avan´y mˆoˇze byt’ ˇstandardne pr´ave jeden proces. V stave pripraven´y s´
u procesy,
ktor´e maj´
u pripraven´e vˇsetky d´ata a ˇcakaj´
u len na pridelenie procesora.
Raden´ım pripraven´
ych procesov do poradia sp´
uˇst’ania sa zaober´a ˇspeci´alna ˇcast’ jadra
nazvan´a pl´anovaˇc procesov (scheduler). Podrobnejˇsie je pl´anovaˇc vysvetlen´
y v ˇcasti Jadro
OS.
7
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Obr. 2.7: Stavov´
y automat procesu
2.2.2
Uviaznutie
Uviaznutie (deadlock) nast´ava v pr´ıpadoch, ked’ procesy pristupuj´
u k rovnak´
ym prostriedkom ako je napr´ıklad miesto v pam¨ati alebo V/V zariadenie. Tieto prostriedky procesy
obsadzuj´
u a vz´ajomne si br´ania vo vykonan´ı. Uviaznutie vznik´a aj pri ˇcakan´ı na spr´avu od
in´eho procesu napr´ıklad chybn´
ym n´avrhom. [3]
Na to, aby uviaznutie mohlo vznikn´
ut’, mus´ı splnit’ podmienky uviaznutia [1]:
• Vz´
ajomn´
e vyl´
uˇ
cenie (mutual exclusion) - kaˇzd´
y zdroj je pridelen´
y pr´ave jedn´emu
procesu.
• Obsadenie a ˇ
cakanie - obsadenie jedn´eho zdroja a ˇcakanie na druh´
y.
• Nepreempcia - uvol’nenie prostriedku aˇz po skonˇcen´ı pr´ace s nim.
ˇ
• Cakanie
v kruhu - proces ˇcak´a na zdroj, ktor´
y obsadil druh´
y proces, ten ˇcak´a na
zdroj od tretieho procesu aˇz nakoniec posledn´
y proces ˇcak´a na zdroj, ktor´
y obsadil
prv´
y.
Probl´em uviaznutia sa mˆoˇze odstr´anit’ ak jedna z podmienok uviaznutia nie je splnen´a.
V praxi je ale obtiaˇzne dosiahnut’ nesplnenie ˇco i len jednej podmienky. Je potrebn´e zaviest’
moˇznost’ odstr´anenia uviaznutia v pr´ıpade jeho vzniku a predch´adzat’ uviaznutiu dodatoˇcn´
ym zabezpeˇcovac´ım mechanizmom.
Najjednoduchˇs´ım a ˇcasto aj najefekt´ıvnejˇs´ım rieˇsen´ım uviaznutia je pˇstros´ı algoritmus,
ktor´
y predpoklad´a, ˇze ˇziadne uviaznutie nemˆoˇze nastat’. Tak´
yto algoritmus je vinikaj´
uci z
hl’adiska r´eˇzie jadra, pretoˇze neprid´ava ˇziaden v´
ypoˇctov´
y ˇcas. V pr´ıpade vzniku uviaznutia
sa ale syst´em uˇz nedok´aˇze zotavit’. Pˇstros´ı algoritmus je vhodn´e pouˇz´ıvat’ len v pr´ıpade, ˇze
je ˇstrukt´
ura procesov navrhnut´a tak, aby k uviaznutiu nemohlo dˆojst’, teda nie je splnen´a
niektor´a z podmienok uviaznutia.
8
2. Anal´
yza
Odstr´anit’ uˇz vzniknut´e uviaznutie je moˇzn´e zruˇsen´ım jedn´eho z procesov, ktor´e tvoria
uviaznutie, na b´aze v´
yberu obete s krit´eriom ˇco najmenˇsej straty na syst´eme, odloˇzen´ım
procesu a odobran´ım jeho prostriedkov alebo zruˇsen´ım preempcie (obsadenia) prostriedku
procesu, ktor´
y ho obsadil.
In´
ym rieˇsen´ım je pouˇzitie metodiky predch´adzania vzniku uviaznutia. Pr´ıkladom je
riaden´
y pr´ıstup k prostriedkom cez vyhraden´
y proces. K prostriedku smie prist´
upit’ len
vyhraden´
y proces, s ktor´
ym komunikuj´
u procesy, ktor´e chc´
u pristupovat’ na prostriedok.
2.2.3
Spr´
ava pam¨
ate
Pam¨at’ je moˇzno najdˆoleˇzitejˇsie zariadenie vo v´
ypoˇctovom syst´eme. V pam¨ati je uloˇzen´
y
zdrojov´
y k´od a d´ata procesu. Pam¨at’ potrebuj´
u k svojej ˇcinnosti vˇsetky procesy ale i operaˇcn´
y syst´em. Pam¨at’ vo forme registrov alebo z´asobn´ıkov maj´
u vˇsetky V/V zariadenia a
aj samotn´
y procesor. Preto na spr´avu pam¨ate je kladen´
y vel’k´
y dˆoraz. Spr´ava pam¨ate je
potrebn´a z dˆovodu riadenia pridel’ovania pam¨ate procesom, ale aj z dˆovodu jej nedostatku.
Bolo by neefekt´ıvne ale najjednoduchˇsie mat’ tol’ko pam¨ate kol’ko potrebuj´
u vˇsetky procesy
spolu s operaˇcn´
ym syst´emom, ale s ohl’adom na plytvanie zdrojov a nemoˇznost’ predikcie
mnoˇzstva potrebnej pam¨ate to nie je moˇzn´e.
Ked’ p´ıˇseme o pam¨ati, mysl´ıme t´
ym hlavn´
u pam¨at’, teda pam¨at’, ktor´a je priamo alebo
prostredn´ıctvom cache pripojen´a k procesoru a o registroch patriacich k zariadeniam a procesoru. Pam¨at’ na u
´rovni u
´loˇz´ısk (pevn´
y disk) je uˇz predmetom s´
uborov´
ych syst´emov.
Rozliˇsujeme dve triedy spr´av pam¨ate. Met´ody z prvej triedy naˇc´ıtavaj´
u procesy z u
´loˇziska
(pevn´
y disk) a po ukonˇcen´ı ˇcinnosti odkladaj´
u proces do u
´loˇziska (str´ankovanie, swapovanie).
Met´ody druhej triedy maj´
u spr´avu pam¨ate jednoduchˇsiu.
Existuj´
u syst´emy, ktor´e maj´
u v jeden ˇcasov´
y okamih pr´ave jeden proces v pam¨ati. Poˇcas
prepnutia kontextu je u
´lohou spr´avy pam¨ate proces v pam¨ati odloˇzit’ a naˇc´ıtat’ nov´
y. Operaˇcn´e syst´emy s viacer´
ymi procesmi v hlavnej pam¨ati musia dbat’ na to, aby procesy nepresiahli svojimi pam¨at’ov´
ymi n´arokmi do priestoru in´eho procesu. Najvyˇsˇsiu u
´roveˇ
n dosahuj´
u
operaˇcn´e syst´emy s virtu´alnou pam¨at’ou. Virtu´alna pam¨at’ zabezpeˇcuje moˇznost’ vytvorenia
procesov aj mimo hlavnej pam¨ate. V pr´ıpade, ˇze s´
u tak´eto procesy potrebn´e s´
u premiestnen´e
str´ankovac´ım mechanizmom do hlavnej pam¨ate s v´
yberom obete.
2.2.4
Spr´
ava vstupov a v´
ystupov
Kaˇzd´
y v´
ypoˇctov´
y syst´em mus´ı mat’ rozhrania na interakciu so svojim okol´ım. V´
ypoˇctov´
y
syst´em zbiera d´ata a prij´ıma pr´ıkazy, ktor´e sprac´
uva a vracia sp¨at’ okoliu vo forme spr´av
´
alebo pr´ıkazov. Ulohou
operaˇcn´eho syst´emu je spravovat’ komunikaˇcn´e rozhrania. V prvom
rade riadi pr´ıstup k t´
ymto prostriedkom, pretoˇze jeden prostriedok mˆoˇze v ˇcasovom u
´seku
obsadit’ najviac jeden proces.
9
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Okrem spr´avy V/V rozhran´ı b´
yva operaˇcn´
y syst´em rozˇs´ıren´
y o ovl´adaˇce, ktor´e vedia pracovat’ s rozhran´ım a b´
yvaj´
u navrhnut´e tak, ˇze len tieto ovl´adaˇce vedia prist´
upit’ k rozhraniu,
ˇc´ım sa zabraˇ
nuje vznikom uviaznut´ı.
2.3
Triedenie OS
Podl’a vel’kosti v´
ypoˇctov´eho syst´emu del´ıme operaˇcn´e syst´emy na: [1]
• Mainframe - navrhnut´e na spr´avu obrovsk´eho poˇctu V/V a vykon´avanie vel’k´eho
poˇctu procesov naraz v jednom ˇcase.
• Serverov´
e - navrhnut´e na obstar´avanie vel’k´eho poˇctu pouˇz´ıvatel’ov.
• Multiprocesorov´
e - navrhnut´e na efekt´ıvne rozdelenie z´at’aˇze na viacero CPU.
• Person´
alne - navrhnut´e na pr´acu s jedn´
ym pouˇz´ıvatel’om.
• Real-Time - navrhnut´e s dˆorazom na dodrˇzanie ˇcasov´
ych limitov vykonania procesov.
ˇ
• Vnoren´
e - navrhnut´e na aplikovanie v mal´
ych v´
ypoˇctov´
ych syst´emoch. Casto
kr´at
spojen´
y s Real-Time poˇziadavkami.
• Smart Card - navrhnut´e na riadenie v extr´emne mal´
ych v´
ypoˇctov´
ych syst´emov ako
s´
u napr´ıklad platobn´e karty alebo mobiln´e SIM karty.
Podl’a riadenia procesov del´ıme operaˇcn´e syst´emy na: [4]
• Kooperat´ıvne - riadiace prep´ınanie procesov na z´aklade syst´emov´
ych volan´ı umiestnen´
ych v procese. V´
yhodou pr´ıstupu je bezpeˇcn´e ukonˇcenie z´apisu viac bajtov´
ych inˇ vykonania je z´avisl´
form´acii pretoˇze k prepnutiu dˆojde aˇz po ukonˇcen´ı z´apisu. Cas
y
od potrieb procesu, kontext procesu je mal´
y lebo staˇc´ı len poznat’ vrchol z´asobn´ıku.
Nev´
yhodou je nebezpeˇcenstvo uviaznutia, zacyklenia u
´lohy po chybe vykonania programu. V pr´ıpade, ˇze v procese nie je volanie, tak k prepnutiu dˆojde aˇz po ukonˇcen´ı
vykonania procesu.
• Preemt´ıvne - riadiace prep´ınanie procesov na z´aklade ˇcasovo riaden´eho preruˇsenia.
Proces smie byt’ vykon´avan´
y, k´
ym mu neuplynie ˇcas, potom je vyvolan´e prepnutie
procesov. V´
yhodou takejto realiz´acie je, ˇze nemˆoˇze dˆojst’ k uviaznutiu jedn´eho procesu
z dˆovodu chyby behu programu alebo z dˆovodu dlh´eho behu v´
ypoˇctu. Procesy sm´
u
byt’ line´arne programovan´e. Nev´
yhodou je nebezpeˇcenstvo nedokonˇcenia z´apisu alebo
prenosu viac bajtov´
ych inform´acii, ˇcas prepnutia nie je z´avisl´
y od potrieb procesu, operaˇcn´
y syst´em nevie, ktor´e premenn´e s´
u aktu´alne pouˇz´ıvan´e, preto musia byt’ odloˇzen´e
do kontextu procesu.
10
2. Anal´
yza
• Kombinovan´
e - prep´ınanie procesov je riaden´e ˇcasovo riaden´
ym preruˇsen´ım aj syst´emov´
ym volan´ım. Kombinuj´
u sa v´
yhody oboch met´od.
Podl’a ˇstrukt´
ury del´ıme operaˇcn´e syst´emy na: [1, 4]
• Monolitick´
e - navrhnut´e ako mnoˇzstvo proced´
ur bez ˇstrukt´
ury. Kaˇzd´a proced´
ura
vie volat’ ak´
ukol’vek in´
u proced´
uru. V´
yhodou takejto ˇstrukt´
ury je mal´a r´eˇzia syst´emu, pretoˇze prepojenie zariadenia s procesom je na u
´rovni volania jednej proced´
ury.
Nev´
yhodou tejto organiz´acie je vel’mi obtiaˇzne rozˇsirovanie funkcionality alebo zlepˇsovanie vlastnost´ı OS. Aj mal´
y z´asah do syst´emu spˆosob´ı vel’k´e zmeny.
• Monolitick´
e-modul´
arne - s´
u syst´emy rozvrhnut´e do monolitick´
ych modulov. (obr.
2.2) Koncept zjednoduˇsuje ladenie a u
´pravu syst´emu.
• Vrstvov´
e - syst´emy maj´
u ˇstrukt´
uru usporiadan´
u do vrstiev medzi ktor´
ymi je vytvoren´
y
syst´em rozhran´ı. Vrstva poskytuje sluˇzby vrstve nad n
ˇou samou a ˇziada sluˇzby od
vrstvy pod n
ˇou samou. V´
yhodou tak´ehoto konceptu je jednoduch´a u
´prava syst´emu.
Nev´
yhodou je prib´
udaj´
uca r´eˇzia na kaˇzdej vrstve syst´emu, ktor´a mˆoˇze vo vnoren´
ych
syst´emoch byt’ kl’´
uˇcov´a.
• microkernel - n´avrh OS s ˇco najjednoduchˇs´ım jadrom spravuj´
ucim len procesy a
pam¨at’. (obr. 2.8) Podtriedou mikrokernel operaˇcn´
ych syst´emov s´
u nanokernel syst´emy,
ktor´e maj´
u v jadre implementovan´e len riadenie procesov.
Obr. 2.8: Architekt´
ura OS
2.4
Jadro operaˇ
cn´
eho syst´
emu
ˇ
Standardn´
e jadro vnoren´eho operaˇcn´eho syst´emu m´a za u
´lohu riadit’ procesy, spravovat’
pam¨at’ a V/V. Okrem t´
ychto u
´loh mˆoˇze byt’ jadro rozˇs´ıren´e o d’alˇsie u
´lohy v z´avislosti od
11
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
potrieb pouˇz´ıvatel’a. V tejto sekcii bud´
u pop´ısan´e len tie najz´akladnejˇsie.
2.4.1
Riadenie procesov
Riadenie procesov zah´rn
ˇa prep´ınanie procesov a ich zorad’ovanie podl’a urˇcit´
ych krit´eri´ı. V
s´
uˇcastnosti m´a vel’k´e percento procesorov hardv´erov´e prep´ınanie procesov, a t´
ym sa operaˇcn´e syst´emy s´
ustredia na implementovanie ˇco najefekt´ıvnejˇsieho algoritmu na zorad’ovanie
procesov podl’a krit´eri´ı. Krit´eriami zorad’ovania mˆoˇzu byt’ priorita procesu, pr´ava procesu,
ˇcas str´aven´
y na procesore, poˇcet potomkov, atd’. Podl’a krit´eri´ı moˇzno identifikovat’ met´ody
zorad’ovania procesov [3]:
• Pl´
anovania podl’a poradia (round Robin) - radiaca procesy v porad´ı v akom bol
uloˇzen´
y do tabul’ky pripraven´
ych procesov. V´
yhodou tejto met´ody je f´erovost’, pretoˇze
zaruˇcuje, ˇze kaˇzd´
y proces bude obsl´
uˇzen´
y a nebude predbehnut´
y in´
ymi procesmi. V
pr´ıpade existencie procesov, ktor´e potrebuj´
u byt’ vykonan´e ˇco najr´
ychlejˇsie, to ale mˆoˇze
spˆosobovat’ probl´emy so sp´lˇ
nan´ım ˇcasov´
ych limitov.
• Pl´
anovania podl’a krit´
eria - riadiaca procesy podl’a nejak´eho krit´eria, napr´ıklad
priority. V´
yhodou met´ody je r´
ychlejˇsie vykon´avanie dˆoleˇzitejˇs´ıch procesov. Nev´
yhodou
je n´arast r´eˇzie potrebnej na v´
ypoˇcet poradia u
´lohy.
• Kombin´
acie - predch´adzaj´
ucich dvoch met´od. Pr´ıkladom mˆoˇze byt’ zarad’ovanie u
´loh
podl’a priority do viacer´
ych radov, ktor´e s´
u n´asledne raden´e met´odou round Robin.
2.4.2
Spr´
ava pam¨
ate
Spr´ava pam¨ate m´a za u
´lohu pridel’ovat’ pam¨at’ nov´
ym procesom a zabezpeˇcovat’ aby tieto nezasahovali do pam¨ate in´
ych procesov. Pam¨at’ mˆoˇze byt’ pridelen´a staticky alebo dynamicky. Spr´ava pam¨ate si pam¨at´a priestor, ktor´
y je eˇste vol’n´
y, a pridel’uje ho procesom
nasleduj´
ucimi algoritmami [3]:
• prv´
y vyhovuj´
uci (first fit) - procesu sa pridel´ı prv´
yu
´sek rovnak´
y alebo v¨aˇcˇs´ı ako
poˇzadovan´a vel’kost’.
• nasleduj´
uci vyhovuj´
uci (next fit) - rovnako ako prv´y vyhovuj´
uci len sa hl’ad´a od
miesta posledn´eho vloˇzenia.
• najlepˇ
sie vyhovuj´
uci (best fit) - procesu sa n´ajde u
´sek, ktor´
y najlepˇsie vyhovuje
poˇzadovanej vel’kosti.
• najhorˇ
sie vyhovuj´
uci (worst fit) - opak najlepˇsie vyhovuj´
uceho.
12
2. Anal´
yza
• r´
ychlo vyhovuj´
uci (quick fit) - u
´seky raden´e do viacer´
ych radov podl’a vel’kosti.
Vyber´a sa prv´
yu
´sek z rady, ktor´a vyhovuje.
• Buddy algoritmus - zaloˇzen´
y na b´aze delenia u
´sekov na polovice k´
ym dan´
y u
´sek
najlepˇsie nepasuje.
Z hl’adiska rozdelenia pam¨ate pozn´ame [3]:
• pevn´
e rozdelenie - pam¨at’ je rozdelen´a na rovnak´e u
´seky, ktor´e s´
u pridelen´e procesom. Ked’ˇze proces nem´a vˇzdy rovnak´
u vel’kost’ str´anka nie je vˇzdy vyuˇzit´a a vznik´a
intern´a fragment´acia.
• variabiln´
e rozdelenie - pam¨at’ je pridelen´a podl’a potrieb procesu. Medzi procesmi
vznikaj´
u u
´seky, ktor´e s´
u mal´e na to, aby sa tam zmestil d’alˇs´ı proces a vznik´a extern´a fragment´acia. t´
uto fragment´aciu je moˇzn´e odstr´anit’ defragment´aciou (zreorganizovan´ım procesov v pam¨ati).
• Str´
ankovanie - pam¨at’ je rozdelen´a na rovnako vel’k´e u
´seky, str´anky. Procesu s´
u
pridelen´e str´anky podl’a potreby. V´
yhoda oproti pevn´emu rozdeleniu je menˇsia u
´roveˇ
n
internej fragment´acie.
• segmentovanie - pam¨at’ rozdelen´a do segmentov, tak ˇze segment mˆoˇze obsahovat’
len jeden druh inform´aci´ı procesu (inˇstrukcie, statick´e d´ata, dynamick´e d´ata, priv´atne
d´ata...).
2.4.3
Spr´
ava vstupov a v´
ystupov
´
Spr´ava V/V je dˆoleˇzit´
ym elementom jadra operaˇcn´eho syst´emu. Ulohou
spr´avy syst´emu je
riadit’ pristupovanie zariaden´ı a v´
ymenu d´at medzi zariaden´ım a procesom. Vieme definovat’
tri typy komunik´acie z´avisl´e od n´avrhu komunikaˇcn´eho protokolu zariadenia a okolia. [4]:
• Synchr´
onna komunik´
acia - prebiehaj´
uca na b´aze presnej, ˇcasovanej komunik´acie.
Druh komunik´acie v´
yhodn´
y najm¨a z hl’adiska u
´spor energie, pretoˇze zariadenie sa mˆoˇze
vyp´ınat’, k´
ym nepr´ıde synchronizaˇcn´
y sign´al z intern´
ych hod´ın procesora.
• Semisynchr´
onna komunik´
acia - prebiehaj´
uca na b´aze v´
ymeny synchronizaˇcn´
ych
sign´alov. Zariadenie nevie kedy presne zaˇcne komunik´acia ale vie, ˇze zaˇciatok komunik´acie je determinovan´
y synchronizaˇcn´
ym sign´alom, preruˇsen´ım. T´ato met´oda m´a
rovnak´e v´
yhody ako synchr´onna naviac sa nevyˇzaduje presn´e ˇcasovanie, t´
ym sa mˆoˇzu
vypn´
ut’ intern´e hodiny procesora ˇc´ım klesne spotreba.
• Asynchr´
onna komunik´
acia - prebiehaj´
uca na b´aze v´
ymeny synchronizaˇcn´
ych znakov.
Zariadenie poˇcu
´va pridelen´
u linku a hl’ad´a na nej synchronizaˇcn´
y znak. Met´oda nev´
yhodn´a najm¨a z dˆovodu, ˇze zariadenie mus´ı byt’ neust´ale akt´ıvne.
13
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
2.5
ˇ
Statistick´
e merania
´
Jedn´
ym zo stanoven´
ych ciel’ov je implementovanie ˇstatistick´eho modulu. Ulohou
tohto moˇ
dulu je vytv´arat’ obraz o efektivite a zlepˇsen´ı MOS voˇci s´
uˇcasn´
ym VOS. Statistick´
y modul by
mal byt’ schopn´
y merat’ priepustnost’ operaˇcn´eho syst´emu, ˇcasu vykon´avania jednotliv´
ych
procesov, ˇcasu akt´ıvneho vykon´avania procesov, r´eˇziu jadra, d´lˇzka akt´ıvnosti hardv´erov´
ych
prostriedkov, poˇcty spusten´
ych procesov, dodrˇzania limitov procesov re´alneho ˇcasu, analyzovanie poradia sp´
uˇst’ania procesov, komunik´acie medzi procesmi.
ˇ
Statistick´
y modul bude mat’ v jadre v´
yrazn´
y vplyv na r´eˇziu jadra, pretoˇze bude merat’
vel’k´e mnoˇzstvo inform´aci´ı. Dˆoleˇzit´e je, aby jadro bolo schopn´e merat’ tak, aby do ˇstatist´ık
nezanieslo nejak´
u inform´aciu o sebe, ˇco nebude tak´e jednoduch´e, pretoˇze jeho r´eˇzia ovplyvn´ı
napr´ıklad komunik´aciu s okol´ım. Preto bude vhodn´e navrhn´
ut’ ˇstatistick´
y modul tak, ˇze
poˇcas jedn´eho merania sa bude sledovat’ len nejak´a podmnoˇzina z mnoˇziny veliˇc´ın.
2.6
Prehl’ad vnoren´
ych operaˇ
cn´
ych syst´
emov
Pre u
´ˇcely porovn´avania s MOS boli zvolen´e operaˇcn´e syst´emy FreeRTOS, AvrX a TinyOS.
2.6.1
AvrX
V´
yber tohto operaˇcn´eho syst´emu ovplyvnila predch´adzaj´
uca sk´
usenost’. Nev´
yhodou tohto
operaˇcn´eho syst´emu je jeho neprehl’adn´a dokument´acia. Operaˇcn´
y syst´em je navrhnut´
y
v´
yluˇcne pre procesory Atmel AVR. V´
yhodou a z´aroveˇ
n aj nev´
yhodou je, ˇze jadro je implementovan´e v jazyku symbolick´
ych inˇstrukci´ı, a teda moˇzno predpokladat’ vel’k´
u hustotu
k´odu ale prenositel’nost’ na in´e procesory je znaˇcne komplikovan´a. AvrX m´a v z´avislosti od
konfigur´acie 500-700 slov k´odu a je navrhnut´e ako kniˇznica rut´ın.[5]
AvrX je preemt´ıvny a prioritne riaden´
y operaˇcn´
y syst´em. Pl´anovaˇc u
´loh je realizovan´
y
ˇsestn´ast’-´
urovˇ
nov´
ym radom. Kaˇzd´
y rad obsahuje u
´lohy s rovnakou prioritou. Kaˇzd´a u
´loha
je pritom do svojho radu vloˇzen´a na jeho koniec (tzv. met´oda ”round-robin”). R´eˇzia jadra,
pri taktovan´ı procesora 10 MHz a frekvencii prep´ınania u
´loh 10 kHz, vyˇzaduje priemerne 20
percent procesorov´eho ˇcasu. AvrX m´a implementovan´e semafory vhodn´e pre synchroniz´aciu u
´loh alebo riadenie vyl´
uˇcenia (tzv. ”mutual exclusion”). Volania vyuˇz´ıvaj´
uce semafory
maj´
u blokuj´
uci aj neblokuj´
uci charakter. V¨aˇcˇsina neblokuj´
ucich volan´ı m´a svoj ekvivalent aj
v pouˇz´ıvatel’om definovan´
ych preruˇseniach. AvrX implementuje rad ˇcasovaˇcov na riadenie
ˇcasovan´
ych udalost´ı nastavitel’n´
ych volan´ım jadra.
Prepnutie u
´lohy trv´a 92 cyklov. Poˇcas prepnutia sa odloˇzia vˇsetky registre procesora (32
registrov, SREG, PC) do z´asobn´ıka u
´lohy. Po prepnut´ı u
´lohy s´
u vˇsetky registre inicializovan´e
na nulu. Kaˇzd´a u
´loha m´a svoj vlastn´
y z´asobn´ık, na ktorom sa odklad´a kontext u
´lohy poˇcas
14
2. Anal´
yza
prepnutia a vnorenie do funkci´ı. Jadro m´a svoj vlastn´
y z´asobn´ık. Ukazovatel’ na vrchol
z´asobn´ıka, priorita a umiestnenie v rade s´
u odloˇzen´e v kontrolnom bloku u
´lohy (TCB). TCB
´
m´a vel’kost’ 6B. Uloha mˆoˇze nadob´
udat’ stavy: inicializ´acia, spusten´a (running), pozastaven´
a
(suspended), blokovan´a (blocked), pripraven´a (ready).
Semafory nadob´
udaj´
u stavy obsaden´y (pend) , ˇcakaj´
uci (wait) a vol’n´y (done). Ak je
semafor v stave obsaden´y pre konkr´etnu u
´lohu, pre in´
uu
´lohu je stav semafora ˇcakaj´
uci. Na
semafor smie ˇcakat’ viac u
´loh, priˇcom tieto u
´lohy s´
u blokovan´e.
Softv´erov´e ˇcasovaˇce reprezentuj´
u implement´aciu ˇcakania na udalost’. Kaˇzd´
y ˇcasovaˇc
je identifikovan´
y kontroln´
ym blokom ˇcasovaˇca s vel’kost’ou 6B. Kaˇzd´
y ˇcasovaˇc je po jeho
vytvoren´ı zaraden´
y na koniec radu ˇcasovaˇcov. V kontrolnom bloku ˇcasovaˇca je uchov´avan´a
16b hodnota reprezentuj´
uca dobu, po uplynut´ı ktorej ˇcasovaˇc vyprˇs´ı. T´ato hodnota je vypoˇc´ıtan´a ako rozdiel pouˇz´ıvatel’om zadan´eho oneskorenia a s´
uhrnn´eho oneskorenia urˇcen´eho
predch´adzaj´
ucimi ˇcasovaˇcmi.
Medziprocesn´a komunik´acia je realizovan´a pomocou radov spr´av. Kaˇzd´
y rad spr´av je
definovan´
y kontroln´
ym blokom spr´avy (MCB). Spr´ava mˆoˇze byt’ do radu zaraden´a procesom alebo pouˇz´ıvatel’om definovan´
ym preruˇsen´ım. Jednu spr´avu vie prij´ımat’ viac procesov.
Kaˇzd´a spr´ava je spolu so semaforom a ukazovatel’om na d’alˇsiu spr´avu zabalen´a do ob´alky.
2.6.2
FreeRTOS
Tento operaˇcn´
y syst´em bol zvolen´
y kvˆoli jeho popularite v oblasti n´avrhu jednoduch´
ych
vnoren´
ych syst´emov. FreeRTOS je real-time operaˇcn´
y syst´em navrhnut´
y pre menˇsie vnoren´e
syst´emy. Podporuje 27 architekt´
ur najm¨a z rodiny ARM7 a ARM Coretex-m3. FreeRTOS
je jadro, ktor´e mˆoˇze byt’ nastaven´e do kooperat´ıvneho, preempt´ıvneho alebo hybridn´eho
ˇ
m´odu. Prevaˇzn´a ˇcast’ OS je implementovan´a v jazyku C. Casti
k´odu z´avisl´e od architekt´
ury
procesora s´
u nap´ısan´e v jazyku symbolick´
ych inˇstrukci´ı. Jadro dosahuje vel’kost’ 4-9 kB,
podporuje tvorbu ˇstandardn´
ych procesov (´
uloh) a ˇspeci´alnych co-rut´ın (co-routines). Synchroniz´acia u
´loh je zabezpeˇcen´a prostredn´ıctvom semaforov, z´amok (mutex) a radov. OS m´a
moˇznost’ nastavenia detekcie preteˇcenia z´asobn´ıka. FreeRTOS nem´a softv´erov´e obmedzenie
poˇctu u
´loh a poˇctu prior´ıt u
´loh. Okrem pon´
ukan´
ych vlastnost´ı je operaˇcn´
y syst´em podporen´
y
vel’mi kvalitnou dokument´aciou, uk´aˇzkov´
ymi rieˇseniami a n´avodmi.[6]
15
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
´
Ulohy
(procesy) mˆoˇzu byt’ v stavoch beˇziaca (running), pripraven´e (ready), blokovan´e
(blocked) a zastaven´e (suspended). Na obr´azku 2.9 s´
u zobrazen´e povolen´e prechody stavov
u
´loh.
Obr. 2.9: Pr´ıpustn´e prechody u
´loh stavmi [6]
Pl´anovaˇc operaˇcn´eho syst´emu zabezpeˇcuje pridelenie procesorov´eho ˇcasu u
´lohe s najvyˇsˇsou prioritou pred u
´lohami s niˇzˇsou prioritou. Mnoˇzstvo prior´ıt sa nastavuje v konfiguraˇcnom
´
s´
ubore pred kompil´aciou operaˇcn´eho syst´emu. Kaˇzd´a u
´loha m´a svoj vlastn´
y z´asobn´ık. Uloha
je implementovan´a pouˇz´ıvatel’om ako jednoduch´a funkcia, (obr. 2.10) zvyˇcajne s nekoneˇcnou
sluˇckou v jej tele. Funkcii sa prostredn´ıctvom parametra daj´
u na vstup pripojit’ rˆozne d´ata.
´
Uloha je vytvoren´a a ukonˇcen´a volan´ım funkci´ı xTaskCreate() a xTaskDelete().
Obr. 2.10: R´amec u
´lohy [6]
OS implementuje Idle Task, ktor´a je automaticky spusten´a jadrom po inicializ´aci´ı. Jej
u
´lohou je ˇcistenie pam¨ate po skonˇcen´
ych u
´loh´ach. Poˇcas vykon´avania Idle Task je sp´
uˇst’an´a
funkcia Idle Task Hook. T´ato funkcia je vhodn´a na sp´
uˇst’anie u
´loh s rovnakou prioritou
16
2. Anal´
yza
ako Idle Task. Idle Task Hook sa pouˇz´ıva najm¨a na sp´
uˇst’anie Co-rut´ın alebo prep´ınanie
procesora do u
´sporn´eho m´odu.
Pomocou takzvanej Co-rutiny je moˇzn´e implementovat’ syst´em s menˇsou spotrebou
pam¨ate pretoˇze vˇsetky co-rutiny maj´
u spoloˇcn´
y z´asobn´ık.
Medziprocesn´a komunik´acia je zabezpeˇcen´a prostriedkami ako s´
u rady (queue), z´amky
(mutex) a semafory.
Rady sa najˇcastejˇsie pouˇz´ıvaj´
u na prenos inform´aci´ı medzi dvoma u
´lohami alebo medzi
u
´lohou a preruˇsen´ım (Obr. 2.11). Poˇcas inicializ´acie radu medzi u
´lohami sa urˇc´ı vel’kost’ jedn´eho bloku d´at, maxim´alny poˇcet blokov v rade a blokovac´ı ˇcas. Najˇcastejˇsie s´
u d´ata uloˇzen´e
v rade ako k´opia. D´ata sa t´
ym ochr´ania pred prep´ısan´ım. Ak je potrebn´e uˇsetrit’ priestor v
pam¨ati je moˇzn´e vloˇzit’ do radu ukazovatel’ na d´ata. Blokovac´ı ˇcas urˇcuje poˇcet tikov proce´
sora poˇcas, ktor´
ych je u
´loha blokovan´a. Uloha
je blokovan´a ak chce ˇc´ıtat’ z pr´azdneho radu
alebo ak chce zapisovat’ do pln´eho radu. Ak sa maxim´alny poˇcet blokov d´at v rade nastav´ı
na “1“ tak rad pln´ı aj synchronizaˇcn´
uu
´lohu.
Obr. 2.11: Pr´ıklad radu medzi dvoma u
´lohami [6]
FreeRTOS implementuje viacero druhov semaforov a z´amok. Semafory a z´amky s´
u
pouˇzitel’n´e na synchroniz´aciu medzi dvoma u
´lohami alebo preruˇsen´ım a u
´lohou.
• Bin´
arne semafory sa pouˇz´ıvaj´
u pre pr´ıstup k zariadeniam a pre synchronizaˇcn´e u
´lohy.
Bin´arny semafor sa od z´amky odliˇsuje v tom, ˇze neimplementuje dedenie priority.
T´
ym sa bin´arne semafory st´avaj´
u vhodnejˇs´ımi na realiz´aciu synchroniz´acie (Obr. 2.12).
Semafory maj´
u nastavitel’n´
u dobu blokovania u
´lohy. Blokovan´e u
´lohy na semafore s´
u
zoraden´e na z´aklade priority.
Obr. 2.12: Semafor ako prostriedok synchroniz´acie: preruˇsenie a u
´loha [6]
17
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
ˇ
• Standardn´
e semafory maj´
u nastavitel’n´
u hladinu, poˇcet u
´loh, ktor´e mˆoˇzu vst´
upit’ do
kritickej oblasti. Pouˇz´ıvaj´
u sa na poˇc´ıtanie udalost´ı. Semafor je inicializovan´
y na stav
zamknut´y, teda na nulu. Po pr´ıchode udalosti sa zv´
yˇsi hodnota semaforu a po spracovan´ı
udalosti u
´lohou sa jeho hodnota zn´ıˇzi. Druhou moˇznost’ou ako pouˇzit’ ˇstandardn´
y
semafor je riadenie pr´ıstupu ku zdrojom. V takomto pr´ıpade je semafor nastaven´
y na
nejak´
u poˇciatoˇcn´
u hodnotu “N“. Ak u
´loha chce prist´
upit’ ku zdroju tak zn´ıˇzi hodnotu
semaforu. Ak hodnota semaforu dosiahne nulu ˇziaden zdroj nie je vol’n´
y a u
´loha je
blokovan´a.
• Z´
amky narozdiel od bin´arneho semaforu implementuj´
u dedenie priority, preto s´
u
z´amky vhodnejˇsie pre riadenie pr´ıstupu k zariadeniu. Z´amka vystupuje ako token.
Na to aby u
´loha mohla prist´
upit’ k zdroju mus´ı si vziat’ token (Obr. 2.13).
Obr. 2.13: Z´amok vystupuj´
uci ako token pr´ıstupu k zdroju [6]
• Rekurz´ıvne z´
amky umoˇzn
ˇuj´
u viacn´asobn´e obsadenie z´amky vlastn´ıkom. Ak si u
´loha
obsad´ı z´amku N-kr´at, tak ostatn´e u
´lohy k z´amke nemˆoˇzu prist´
upit’ pok´
ym u
´loha neuvol’n´ı z´amku N-kr´at. Z´amky na rozdiel od semaforov nemˆoˇzu byt’ pouˇzit´e v pouˇz´ıvatel’om definovan´
ych preruˇseniach.
Mimo jadra je implementovan´a moˇznost’ softv´erov´
ych ˇcasovaˇcov vo forme sluˇzby (deaˇ
mon). Softv´erov´e ˇcasovaˇce sa pouˇz´ıvaj´
u na ˇcasovanie sp´
uˇst’ania u
´loh. Casovaˇ
c po vyprˇsan´ı
zavol´a callback funkciu, v ktorej je moˇzn´e definovat’ sp´
uˇst’an´
uu
´lohu.
FreeRTOS okrem ˇstandardn´
ych u
´loh poskytuje sluˇzby sledovania behu u
´loh posielan´ım
d´at na digit´alny alebo anal´ogov´
y v´
ystup (moˇzn´e pripojenie analyz´atora). Meria ˇstatistiku
trvania vykonania u
´lohy v absol´
utnom ˇcase, percentu´alny podiel absol´
utneho ˇcasu a ˇcasu
str´aven´eho na procesore. Operaˇcn´
y syst´em podporuje spr´avu pam¨ate a pre ARM Coretex
M3 jadr´a aj MPU (memory protection unit).
2.6.3
TinyOS
Operaˇcn´
y syst´em implementovan´
y v programovacom jazyku nesC, ktor´
y je dialektom jazyka
C. NesC rozˇsiruje ˇstandardn´e C o formu modul´arnosti implementovan´ım mechanizmu rozhran´ı medzi komponentami syst´emu.
18
2. Anal´
yza
Hlavnou myˇslienkou TinyOs je zavedenie architekt´
ury hardv´erovej abstrakcie (Hardware Abstraction Architecture skr. HAA) (Obr. 2.14). Hardv´erov´a abstrakcia zvyˇsuje znovupouˇzitel’nost’ (prenositel’nost’) zdrojov´eho k´odu a zjednoduˇsuje n´avrh aplik´aci´ı skr´
yvan´ım
hardv´erovej zloˇzitosti. Naopak hardv´erov´a abstrakcia je v konflikte s v´
ykonnost’ou a energetickou efektivitou senzorov´
ych siet´ı. Preto HAA hl’ad´a kompromis medzi efektivitou a
jednoduchost’ou n´avrhu aplik´aci´ı.[7]
Obr. 2.14: Architekt´
ura hardv´erovej abstrakcie HAA
HAA je organizovan´a do troch vrstiev. Kaˇzd´a vrstva m´a definovan´
u svoju u
´lohu a
je z´avisl´a od rozhrania definovan´eho niˇzˇsou vrstvou. Narozdiel od dvojvrstvov´
ych rieˇsen´ı
pouˇzit´
ych v in´
ych VOS ako je napr´ıklad WindowsCE, troj-´
urovˇ
nov´a ˇstrukt´
ura poskytuje
v¨aˇcˇsiu mieru platformovej nez´avislosti. HAA umoˇzn
ˇuje pripojenie pouˇz´ıvatel’skej aplik´acie
na rozhranie najvyˇsˇsej a strednej vrstvy abstrakcie.
Najniˇzˇsou vrstvou abstrakcie je vrstva Prezentaˇcn´a (Hardware Presentation Layer skr.
HPL). T´ato vrstva je umiestnen´a priamo nad hardv´erom a prezentuje moˇznosti hardv´eru
voˇci vyˇsˇs´ım vrstv´am. Vrstva pristupuje k hardv´eru ale aj prij´ıma preruˇsenia od hardv´eru.
Prezentaˇcn´a vrstva tvor´ı ˇcitatel’nejˇsie rozhranie voˇci vyˇsˇs´ım vrstv´am a skr´
yva zloˇzitost’.
Strednou vrstvou abstrakcie je Adaptaˇcn´a vrstva (Hardware Adaptation Layer skr.
HAL). Adaptaˇcn´a vrstva reprezentuje jadro architekt´
ury HAA. Zap´
uzdruje zloˇzitost’ HPL.
Na rozdiel od HPL smie mat’ HAL stavov´
y charakter. Adaptaˇcn´a vrstva je st´ale platformovo
ˇspecifick´a s ciel’om najlepˇsieho vyuˇzitia vlastnost´ı hardv´eru.
Najvyˇsˇsou vrstvou abstrakcie je vrstva rozhrania (Hardware Interface Layer skr. HIL).
19
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
HIL zap´
uzdruje platformovo ˇspecifick´
u HAL do platformovo nez´avislej reprezent´acie pre
platformovo nez´avisl´e aplik´acie.
Vˇsetky s´
uˇcasti operaˇcn´eho syst´emu s´
u implementovan´e v nesC ako komponent. Kaˇzd´
y
komponent m´a svoje komunikaˇcn´e rozhranie. Pl´anovaˇc ako komponent prij´ıma komponenty
u
´loh. Pl´anovaˇc je implementovan´
y ako FIFO rad. V rade smie byt’ maxim´alne 255 u
´loh,
´
priˇcom kaˇzd´
y typ u
´lohy smie byt’ v rade pr´ave raz. Uloha
sa mˆoˇze zaradit’ do radu znova t´
ym,
ˇze sa sama odloˇz´ı do radu poˇcas vykonania alebo v pr´ıpade, ak bola vytvoren´a syst´emom.
20
ˇ
3. Specifik´
acia
ˇ
3 Specifik´
acia
Operaˇcn´e syst´emy navrhnut´e pre vnoren´e aplik´acie sp´lˇ
naj´
u okrem z´akladn´
ych poˇziadaviek
(spol’ahlivost’, presnost’, efekt´ıvnost’ a f´erovost’) ˇstandardn´
ych operaˇcn´
ych syst´emov aj podmienky vyˇsˇsej odolnosti voˇci poruch´am behu programu. Zv¨aˇcˇsa pracuj´
u s obmedzenejˇs´ımi
v´
ykonov´
ymi, energetick´
ymi a pam¨at’ov´
ymi kapacitami. Preto musia byt’ navrhnut´e s dˆorazom na ˇsetrenie energie a s t´
ym spojenou minimaliz´aciou r´eˇzie jadra.
3.1
Poˇ
ziadavky na OS
Modul´arny operaˇcn´
y syst´em bude navrhnut´
y tak, aby sp´lˇ
nal poˇziadavky:
• modul´arnosti na u
´rovni jadra a pridruˇzen´
ych s´
uˇcast´ı OS. Modul´arnost’ zabezpeˇc´ı jednoduch´
u v´
ymenu modulov podl’a potreby a moˇznost´ı hardv´eru alebo ˇstrukt´
ury procesov.
• riadenia spotreby energie s dˆorazom na zv´
yˇsenie v´
ydrˇze syst´emu na u
´kor v´
ykonu.
Spotreba energie bude regulovatel’n´a podl’a vlastnost´ı zdroja. V pr´ıpade nap´ajania z
elektrickej siete alebo obnovitel’n´eho zdroja bude moˇzn´e regulovat’ spotrebu s ohl’adom
na zv´
yˇsenie v´
ykonu na u
´kor v´
ydrˇze syst´emu. Riadenie spotreby energie z´avis´ı od
moˇznost´ı procesora.
• univerz´alnosti s moˇznost’ou prenesenia na rˆozne hardv´erov´e architekt´
ury. Prispˆosobitel’nost’ je z´akladn´
ym u
´spechom kaˇzd´eho operaˇcn´eho syst´emu.
• obsluhy real-time procesov bez z´aruky dodrˇzania ˇcasov´
ych limitov.
• meratel’nosti z pohl’adu porovn´avania v´
ykonnosti a efekt´ıvnosti s in´
ymi operaˇcn´
ymi
syst´emami.
• rekonfigur´acie poˇcas behu operaˇcn´eho syst´emu z hl’adiska prid´avania nov´
ych programov
a dop´lˇ
nania k´odu programom, ktor´e nemaj´
u priraden´e spusten´e procesy.
3.2
N´
avrh ˇ
strukt´
ury operaˇ
cn´
eho syst´
emu
Modul´arny operaˇcn´
y syst´em bude navrhnut´
y ako monolitick´
y modul´arny syst´em. Operaˇcn´
y
syst´em bude pozost´avat’ z jadra a z perif´erie. (obr. 3.1).
21
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Obr. 3.1: Architekt´
ura operaˇcn´eho syst´emu
Na u
´rovni jadra bud´
u navrhnut´e moduly:
• procesn´
eho riadenia, ktor´
y bude zabezpeˇcovat’ prep´ınanie procesov (manaˇz´er u
´loh),
pl´anovanie procesov (pl´anovaˇc, scheduler) a riadenie komunik´acie medzi procesmi.
Moduly pl´anovaˇca bud´
u navrhnut´e viacer´
ymi met´odami podl’a rˆoznych krit´eri´ı ako
s´
uu
´spora r´eˇzie jadra, u
´spora pam¨ate, zv´
yˇsenie v´
ykonu a f´erovost’. Procesn´e riadenie
bude povinnou ˇcast’ou jadra.
• spr´
avy vstupov a v´
ystupov, ktor´
y bude zabezpeˇcovat’ spr´avu pr´ıstupu k hardv´erov´
ym zariadeniam.
• riadenia spotreby, ktor´
y bude zabezpeˇcovat’ riadenie spotreby energie a je navrhnut´
y
podl’a u
´rovne pridelen´
ych kompetenci´ı. Od najniˇzˇsej u
´rovne (vyp´ınanie neakt´ıvnych
zariaden´ı) aˇz po najvyˇsˇsiu u
´roveˇ
n (zasahovanie do riadenia procesov a cel´eho syst´emu
akt´ıvnym uspan´ım).
• spr´
avy pam¨
ate, ktor´
y bude spravovat’ pridelen´e pam¨at’ov´e prostriedky. N´avrh modulu bude pracovat’ len s hlavnou pam¨at’ou. Syst´em s pevn´
ym diskom (swaping, paging) nebude realizovan´
y. Spr´ava pam¨ate bude povinnou ˇcast’ou jadra.
• ˇ
statistiky, ktor´
y bude zameran´
y na meranie priemerne str´aven´eho ˇcasu procesov na
procesore, priemernej d´lˇzky vykon´avania procesu a poˇctu akt´ıvnych zariaden´ı.
22
ˇ
3. Specifik´
acia
Na u
´rovni perif´erie bud´
u implementovan´e extern´e volania jadra operaˇcn´eho syst´emu ako s´
u:
• volania extern´
eho prostredia - volania jadra s´
uvisiace napr´ıklad s riaden´ım spotreby.
• volania ovl´
adaˇ
cov - obsahuj´
uci MOS procesy spravuj´
uce pridruˇzen´e zariadenie.
• volania zav´
adzania - schopn´
y zavedenia nov´eho programu do pam¨ate poˇcas behu
syst´emu.
• volania aktualiz´
acie - schopn´eho zmeny k´odu programu poˇcas behu syst´emu.
3.3
Programov´
y a procesn´
y model
Pre potreby modul´arneho operaˇcn´eho syst´emu je zaveden´a konvencia znaˇcenia procesov
a vzt’ahov medzi nimi na b´aze, grafov. Na obr´azku 3.2 s´
u zn´azornen´e tri druhy hr´an a
ˇstyri druhy vrcholov, ktor´e s´
u identifikovan´e v syst´eme. Konvencia je vhodn´a na simul´aciu
vzt’ahov medzi procesmi v ˇcase ale aj vzt’ahov procesov vˇseobecne podl’a n´avrhu ˇstrukt´
ury programov´eho vybavenia. Na reprezentovanie stavu syst´emu v ˇcase budeme pouˇz´ıvat’
grafov´
u ˇstrukt´
uru, ktor´a bude reprezentovan´a procesn´
ym grafom (obr. 3.4). Na reprezentovanie programovej ˇstrukt´
ury syst´emu budeme pouˇz´ıvat’ grafov´
u ˇstrukt´
uru reprezentovan´
u
programov´
ym grafom (obr. 3.3). Vˇseobecne plat´ı, ˇze v procesnom grafe sa bude vyskytovat’ podmnoˇzina procesov a z´avislost´ı programov´eho grafu, priˇcom procesy a z´avislosti sa
mˆoˇzu opakovat’. Sp´
uˇst’acia z´avislost’ (ˇs´ıpka) zn´azorˇ
nuje vzt’ah medzi sp´
uˇst’ac´ım, rodiˇcov-
Obr. 3.2: Konvencia
sk´
ym procesom (na zaˇciatku ˇs´ıpky) a sp´
uˇst’an´
ym, dc´erskym procesom (na konci ˇs´ıpky). V
konfigur´aci´ı programov´eho syst´emu zn´azorˇ
nuje z´avislost’ moˇznost’ procesu priraden´eho jedn´emu programu spustit’ proces priraden´
y druh´emu programu. Stav syst´emu v ˇcase zn´azorn´ı
z´avislost’ aktu´alny vzt’ah rodiˇc a potomok.
23
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Komunikaˇcn´a z´avislost’ (ˇs´ıpka s pln´
ym kr´
uˇzkom) zn´azorˇ
nuje jednosmern´
y vzt’ah v´
ymeny
d´at medzi dvoma procesmi v rovnakom slede ako pri sp´
uˇst’acej z´avislosti. Synchronizaˇcn´a
z´avislost’ je ˇspeci´alnym pr´ıpadom komunikaˇcnej z´avislosti zn´azorˇ
nuj´
uca vzt’ah ˇcakania procesu, do ktor´eho vstupuje z´avislost’ na sign´al od procesu, z ktor´eho z´avislost’ vystupuje.
Modul´arny operaˇcn´
y syst´em bude po inicializ´aci´ı jadra syst´emu sp´
uˇst’at’ jeden inicializaˇcn´
y proces naz´
yvan´
y koreˇ
nov´
ym. Koreˇ
nov´
y proces sl´
uˇzi pre pouˇz´ıvatel’a na pr´ıpravu prv´
ych
procesov, ktor´e bud´
u v syst´eme spusten´e.
Okrem ˇstandardn´
ych procesov, ktor´
ych predkom je koreˇ
nov´
y proces bud´
u v syst´eme existovat’ procesy, ktor´e boli spusten´e z´asahom z okolit´eho prostredia. Procesy, ktor´
ych predok
nie je koreˇ
nov´
y proces naz´
yvame zdrojov´
y proces. Zdrojov´
y preto lebo ich sp´
uˇst’aˇcom bol
nejak´
y zdroj ako je napr´ıklad s´eriov´e rozhranie alebo syst´em preruˇsenia. Tak´
ymto procesom
vieme do syst´emu zaviest’ prvok asynchr´onnosti. Niektor´e inform´acie sa dost´avaj´
u do syst´emu len v predom neurˇcen´
ych intervaloch a nie je potrebn´e, preto pre ne udrˇzovat’ proces
v hlavnom toku.
Neˇstandardn´
ymi procesmi v syst´eme s´
u procesy modul´arneho operaˇcn´eho syst´emu, MOS
procesy. Tieto procesy s´
u procesmi operaˇcn´eho syst´emu, ktor´e bud´
u ˇstandardnou v´
ybavou
alebo doplnen´ım funkcionality syst´emu. Tak´eto procesy sl´
uˇzia ako vrstva nad rozhraniami
syst´emu.
Obr. 3.3: Pr´ıklad programov´eho grafu
Na obr´azku 3.3 je pr´ıklad programov´eho grafu kde s´
u zobrazen´e pr´ıpady ako sa mˆoˇze
znovu inicializovat’ koreˇ
nov´
y proces, pr´ıklady synchronizaˇcnej a komunikaˇcnej z´avislosti,
pr´ıklady sp´
uˇst’acej z´avislosti (ˇspeci´alne pre proces P4), vznik zdrojov´eho procesu a pr´ıstup na
24
ˇ
3. Specifik´
acia
MOS proces. Dˆoleˇzit´e je upozornit’, ˇze sp´
uˇst’acia z´avislost’ medzi MOSP1 a ZP1 je ˇspeci´alnym
pr´ıpadom sp´
uˇst’ania, kedy je proces spusten´
y extern´
ym z´asahom.
Na obr´azku 3.4 je pr´ıklad procesn´eho grafu, ktor´
y je reprezent´aciou spom´ınan´eho programov´eho grafu v konkr´etnom ˇcase. MOSP1 proces je v grafe zobrazen´
y dvakr´at aj ked’ v
syst´eme bude spusten´
y len raz pretoˇze to vypl´
yva z n´avrhu modul´arneho operaˇcn´eho syst´emu. V tomto pr´ıpade je proces rozdelen´
y pre zdˆoraznenie nez´avislosti ZP1 procesu od
zbytku procesov.
Obr. 3.4: Pr´ıklad procesn´eho grafu
3.4
Riadenie procesov
Inform´acie o kaˇzdom procese spustenom na syst´eme bud´
u uloˇzen´e v tabul’ke procesov. Jeden
z´aznam tabul’ky mˆoˇze obsahovat’: identifik´aciu procesu, adresu zaˇciatku pridelenej pam¨ate
d´at, vel’kost’ pridelenej pam¨ate d´at, stav pam¨ate d´at, stav registrov, ukazovatel’ na vrchol
z´asobn´ıka, programov´e poˇc´ıtadlo atd’.
´
Ulohy
bud´
u prep´ınan´e po uplynut´ı ˇcasu pridelenom u
´lohe operaˇcn´eho syst´emu. MOS
bude preempt´ıvny. Manaˇz´er u
´loh bude mat’ za u
´lohu riadit’ ˇzivotn´
y cyklus procesov (vytvorenie, prepnutie, zruˇsenie). Manaˇz´er u
´loh bude mat’ jednotliv´e funkcionality nastavitel’n´e pred
kompil´aciou.
Pl´anovanie u
´loh bude realizovan´e pomocou ˇstrukt´
ury sp´ajan´
y zoznam. Ak je u
´loha pripraven´a na vykon´avanie, tak sa vloˇz´ı do zoznamu ˇcakaj´
ucich u
´loh na procesor. V pr´ıpade
vel’k´eho mnoˇzstva u
´loh na pl´anovanie (nedostatok vol’nej pam¨ate) sa nov´e u
´lohy nebud´
u
vytv´arat’. Bude moˇzn´e nastavit’ odloˇzenie vytvorenia u
´lohy do takzvan´eho Jobu. Vloˇzenie
do zoznamu u
´loh bude realizovan´e rˆoznymi met´odami. Pouˇz´ıvatel’ si pred kompilovan´ım MOS
zvol´ı met´odu pl´anovania.
25
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Synchroniz´acia a komunik´acia medzi procesmi bude realizovan´a prostredn´ıctvom toku
d´at (stream). Tok d´at bude mat’ pr´ave jedn´eho odosielatel’a (sender) a pr´ave jedn´eho pr´ıjemcu (receiver). Odosielatel’ sa bude musiet’ registrovat’ na odosielanie d´at dan´emu pr´ıjemcovi. Pr´ıjemca si bude viest’ z´aznamy o vˇsetk´
ych registrovan´
ych odosielatel’och. Pr´ıjemca
potvrd´ı spojenie s odosielatel’om jeho v´
yberom zo zoznamu registrovan´
ych odosielatel’ov.
D´ata medzi odosielatel’om a pr´ıjemcom bud´
u pren´aˇsan´e v ˇstrukt´
ure rad (queue) ako odkaz na d´ata. Komunik´acia bude realizovan´a pomocou blokuj´
ucich aj neblokuj´
ucich volan´ı.
Pomocou toku d´at sa bude realizovat’ aj synchroniz´acia procesov.
3.5
Spr´
ava pam¨
ate
Inform´acie o kaˇzdom programe uloˇzenom v pam¨ati syst´emu bud´
u uloˇzen´e v tabul’ke programov. Jeden z´aznam tabul’ky mˆoˇze obsahovat’: identifik´aciu programu, adresu zaˇciatku
k´odu programu, vel’kost’ k´odu programu, vel’kost’ potrebnej pam¨ate d´at, poˇcet spusten´
ych
procesov.
Spr´avca pam¨ate bude mat’ za u
´lohu pridel’ovat’ pam¨at’ nov´
ym u
´loh´am a pridel’ovat’
pam¨at’ uˇz spusten´
ym u
´loh´am. V pr´ıpade, ˇze uˇz nie je dostatok priestoru na vytvorenie novej
u
´lohy, je poˇziadavka na vytvorenie u
´lohy odloˇzen´a. Poˇziadavka mˆoˇze byt’ realizovan´a, ak
bud´
u dostupn´e zdroje v pam¨ati. Procesy s rovnak´
ym rodiˇcovsk´
ym programom bud´
u mat’
pridelen´
u rovnak´
u pam¨at’ programu a vlastn´
u dynamick´
u d´atov´
u pam¨at’. Statick´a pam¨at’
d´at nebude uvaˇzovan´a.
3.6
Spr´
avca V/V zariaden´ı
´
Ulohou
spr´avcu V/V zariaden´ı bude riadit’ pr´ıstup k zariadeniam za pomoci MOS procesov,
ktor´e bud´
u volitel’nou s´
uˇcast’ou modul´arneho operaˇcn´eho syst´emu. V nastaven´ı bez MOS
procesov bude spr´avca pam¨ate obsluhovat’ pr´ıstup k zariadeniam prostredn´ıctvom volan´ı.
Procesy bud´
u pristupovat’ k zariadeniam prostredn´ıctvom volania a zariadenie bude oslovovat’ proces volan´ım uloˇzen´
ym v preruˇsen´ı. S MOS procesmi bude kaˇzd´e alebo individu´alne
zvolen´e zariadenie obalen´e Prezentaˇcnou vrstvou tvoriacou MOS proces. K MOS procesu
bud´
u ostatn´e procesy pristupovat’ pomocou vytvoren´eho toku d´at.
3.7
Riadenie spotreby energie
Volitel’n´
ym modulom MOS bude riadenie spotreby energie. Tento modul bude rozˇsirovat’
funkcionalitu ostatn´
ych modulov. Bude riaden´
y prostredn´ıctvom extern´
ych volan´ı. Extern´
ym
volan´ım sa mˆoˇze nastavit’ m´od pl´anovania u
´loh a prep´ınania u
´loh. Poˇcas prepnutia mˆoˇze
napr´ıklad manaˇz´er u
´loh vyradit’ procesor z ˇcinnosti jeho uveden´ım do u
´sporn´eho reˇzimu, a
26
ˇ
3. Specifik´
acia
t´
ym pred´lˇzit’ v´
ydrˇz syst´emu. Mˆoˇze sa zmenit’ spˆosob vykon´avania pl´anovania obmedzen´ım
vykonania u
´loh len na tie s najvyˇsˇsou prioritou. Ostatn´e u
´lohy s´
u uveden´e do pozastaven´eho
stavu.
3.8
ˇ
Statistika
ˇ
Statistick´
y modul modul´arneho operaˇcn´eho syst´emu bude zaznamen´avat’ hist´oriu vykonania
procesov. Bude viest’ ˇstatistiku kaˇzd´eho procesu a jadra. Predmetom ˇstatistiky bude trvanie
vykonania u
´lohy celkovo a na procesore. Z´aroveˇ
n bude veden´a aj ˇstatistika jednotliv´
ych
pripojen´
ych zariaden´ı k procesoru. Prostredn´ıctvom MOS procesu bude jednoznaˇcne zistitel’n´a d´lˇzka aktivity zariadenia, a teda nepriamo sa bude dat’ odvodit’ spotreba energie.
3.9
Perif´
eria operaˇ
cn´
eho syst´
emu
Okrem spom´ınan´
ych MOS procesov bude operaˇcn´
y syst´em mat’ moˇznost’ u
´pravy uˇz vloˇzen´
ych
programov. Vloˇzen´
y program sa jednoducho nahrad´ı novou verziou programu. Poˇcas behu
bude moˇzn´e do pam¨ate procesora vkladat’ aj nov´e programy. Vkladanie programu sa bude
realizovat’ prostredn´ıctvom procesu, ktor´
y bude ˇstandardne spusten´
y a pl´anovan´
y v operaˇcnom syst´eme. Po uloˇzen´ı programu bude proces ˇstandardne ukonˇcen´
y.
27
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
28
4. N´avrh
4 N´
avrh
T´ato kapitola sa podrobnejˇsie zaober´a n´avrhom jednotliv´
ych modulov navrhovan´eho operaˇcn´eho syst´emu.
4.1
Riadenie procesov
´
Ustrednou
ˇcast’ou jadra MOS bude riadenie procesov. Riadenie zabezpeˇc´ı v¨aˇcˇsinu pr´ace
s´
uvisiacej s procesmi. S´
uˇcast’ou riadenia procesov bud´
u moduly prep´ınania procesov, pl´anovania procesov a riadenia komunik´acie medzi procesmi. Ciel’ov´
ym objektom Riadenia procesov bud´
u programy a procesy.
4.1.1
Program
Program predstavuje zdrojov´
y k´od pre proces. Kaˇzd´
y program bude uv´adzan´
y v syst´eme
svojou hlaviˇckou PCB. Hlaviˇcka bude obsahovat’ z´aznamy o:
• zaˇciatku programu,
• konci programu,
• poˇciatoˇcnej vel’kosti d´atov´eho priestoru,
• inform´aciu o poˇcte spusten´
ych procesov a
• poˇciatoˇcnej priorite nov´eho procesu.
Hlaviˇcky procesov bud´
u ukladan´e v zozname programov.
4.1.2
Proces
Proces spusten´
y v MOS bude mat’ hlaviˇcku TCB uloˇzen´
u v tabul’ke spusten´
ych procesov,
ktor´
u bude spravovat’ manaˇz´er u
´loh. Obsahom hlaviˇcky procesu bude:
• ukazovatel’ na vrchol z´
asobn´ıka, ktor´
y bude nepovinnou s´
uˇcast’ou hlaviˇcky. Vrchol z´asobn´ıka ˇstandardne ukazuje na aktu´alny prvok, ktor´
y bol naposledy vloˇzen´
y do
z´asobn´ıka.
ˇ
• ukazovatel’ na dno z´
asobn´ıka, ktor´
y bude povinnou s´
uˇcast’ou hlaviˇcky. Standardne
ukazuje na zaˇciatok z´asobn´ıka priˇcom vrchol z´asobn´ıka nemˆoˇze byt’ niˇzˇsie ako dno.
Mˆoˇze sl´
uˇzit’ ako ochrana pred podteˇcen´ım z´asobn´ıka.
29
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
• ukazovatel’ na koniec z´
asobn´ıka, ktor´
y bude povinnou s´
uˇcast’ou hlaviˇcky. Pouˇz´ıva
sa na ochranou pred preteˇcen´ım z´asobn´ıka.
• ukazovatel’ na haldu, ktor´
y bude nepovinnou s´
uˇcast’ou hlaviˇcky. Bude odkazovat’
na pam¨at’ pre alokovanie premenn´
ych procesu.
• kontext procesu, ktor´
y bude nepovinnou s´
uˇcast’ou hlaviˇcky. Poˇcas prepnutia u
´lohy
bude moˇzn´e kontext procesu odloˇzit’ do z´asobn´ıka alebo do hlaviˇcky. Ak je kontext v
z´asobn´ıku, tak hlaviˇcka procesu je menˇsia. Niektor´e procesory maj´
u ˇspeci´alnu inˇstrukciu, ktor´a cel´
y kontext odloˇz´ı do zvolen´eho z´asobn´ıka. Na druh´
u stranu proces str´aca
ˇcast’ svojho pam¨at’ov´eho priestoru, a vznik´a probl´em, ak na z´asobn´ıku nie je dost’
miesta na odloˇzenie kontextu, ˇco si vyˇziada dodatoˇcn´e oˇsetrenie probl´emu.
• priorita, ktor´a bude nepovinnou s´
uˇcast’ou hlaviˇcky, v z´avislosti od v´
yberu spˆosobu
pl´anovania u
´loh.
• prepoˇ
ziˇ
can´
a priorita, ktor´a bude nepovinnou s´
uˇcast’ou hlaviˇcky, v z´avislosti od implement´acie prepoˇziˇcania priority. Ak u
´loha s vysokou prioritou ˇcak´a na d´ata od u
´lohy
s n´ızkou prioritou, tak u
´loha s vysokou prioritou prepoˇziˇciava svoju prioritu u
´lohe s
niˇzˇsou prioritou.
• identifik´
ator (PID), ktor´
y bude povinnou s´
uˇcast’ou hlaviˇcky. Reprezentuje ˇc´ıslo identifikuj´
uce proces a z´aroveˇ
n aj program, ktor´
y je vykon´avan´
y.
• odkaz na zoznam registrovan´
ych odosielatel’ov, ktor´
y bude nepovinnou s´
uˇcast’ou
hlaviˇcky. S´
uvis´ı s komunik´aciou medzi procesmi.
Procesu bude pridelen´
yu
´sek pam¨ate obsahuj´
uci ˇcast’ urˇcen´
u pre z´asobn´ık, a v z´avislosti
od nastavenia MOS, aj ˇcast’ urˇcen´
u pre haldu. Statick´e d´ata proces nebude mˆoct’ obsahovat’,
ak procesor nem´a b´azov´e registre. Staticky pridelen´
y priestor d´at bude program´ator musiet’
nahradit’ dynamickou alok´aciou. Glob´alne premenn´e tieˇz nebud´
u pouˇzitel’n´e.
Okrem ˇstandardn´
ych pouˇz´ıvatel’sk´
ych procesov bude MOS implementovat’ ˇspeci´alne
typy procesov:
• koreˇ
nov´
y proces, ktor´
y sa spust´ı vˇzdy po inicializ´acii MOS. V tomto procese pouˇz´ıvatel’ deklaruje, ktor´e procesy maj´
u byt’ spusten´e po inicializ´acii. V ˇstandardn´
ych OS
by sa tento proces dal prirovnat’ shellu ale nie doslovne, pretoˇze pouˇz´ıvatel’ nebude mat’
moˇznost’ zad´avat’ pr´ıkazy operaˇcn´emu syst´emu priamo (len v pr´ıpade pridania modulu
pouˇz´ıvatel’sk´eho rozhrania). Pouˇz´ıvatel’ bude mat’ moˇznost’ zmenit’ koreˇ
nov´
y proces
u
´pravou jeho zdrojov´eho k´odu, a t´
ym zmenit’ sp´
uˇst’an´e procesy. Koreˇ
nov´
y proces bude
nastavitel’n´
y podla potreby tak, aby sa znovu spustil v predom definovanom intervale
alebo aby ho spustil pouˇz´ıvatel’sk´
y proces pr´ıpadne by sa spustil len po inicializ´acii
syst´emu.
30
4. N´avrh
• MOS proces, ktor´
y zap´
uzdri zariadenie pripojen´e k procesoru. K zariaden´
u bude
moˇzn´e prist´
upit’ len prostredn´ıctvom tohto procesu. Tieto procesy bud´
u ˇciastoˇcne
platformovo z´avisl´e a bud´
u tvorit’ prezentaˇcn´
u vrstvu pre ostatn´e procesy. Mˆoˇzu byt’
pouˇzit´e na sledovanie, z´apis alebo ˇc´ıtanie zariadenia. MOS procesy bud´
u volitel’n´e a
bud´
u sa dat’ vypn´
ut’ v pr´ıpade, ˇze by neboli potrebn´e alebo ich pouˇz´ıvatel’ nechce
pouˇzit’. Bud´
u ˇspeci´alne navrhnut´e na minim´alne zat’aˇzenie syst´emu. Aktivuj´
u sa len
v pr´ıpade volania z pouˇz´ıvatel’sk´eho procesu alebo jadrom (preruˇsenie na zariaden´ı).
Akt´ıvne zostan´
u len v pr´ıpade, ak existuj´
u d´ata na spracovanie. S t´
ymito procesmi
bude moˇzn´e komunikovat’ prostredn´ıctvom d´atov´eho toku.
• zav´
adzac´ı proces, ktor´
y bude sl´
uˇzit’ na vkladanie nov´
ych programov do pam¨ate.
4.1.3
Manaˇ
z´
er u
´ loh
Manaˇz´er u
´loh bude spravovat’ vˇsetky spusten´e procesy v syst´eme. Hlaviˇcky procesov bud´
u
uloˇzen´e v tabul’ke procesov. Tabul’ka procesov bude uloˇzen´a v pam¨ati d´at procesora. Okrem
tabul’ky procesov bude manaˇz´er u
´loh spravovat’ aj tabul’ku programov. Manaˇz´er u
´loh bude
riaden´
y pomocou volan´ı jadra operaˇcn´eho syst´emu. Pomocou volan´ı bude moˇzn´e ˇc´ıtat’ povolen´e inform´acie o konkr´etnej u
´lohe, ale nebude moˇzn´e aby jedna u
´loha zasahovala do
nastaven´ı druhej u
´lohy.
Hlavn´
ymi u
´lohami manaˇz´era u
´loh bude riadenie prepnutia procesu, vytvorenie nov´eho
procesu a zruˇsenie skonˇcen´eho procesu. Prepnutie procesu je z´avisl´e od procesora, a preto
bude realizovan´e podl’a moˇznost´ı dan´eho procesora v jazyku symbolick´
ych inˇstrukci´ı. Vytvorenie nov´eho procesu bude realizovan´e volan´ım spawn() a bude z´avisiet’ od zost´avaj´
uceho
mnoˇzstva pam¨ate a mnoˇzstva spusten´
ych procesov.
Po pr´ıchode poˇziadavky na vytvorenie nov´eho procesu manaˇz´er u
´loh vykon´a nasleduj´
uce
oper´acie:
1. skontroluje, ˇci m´a vol’n´
y priestor pre proces v tabul’ke procesov (ak je nastaven´e
obmedzenie poˇctu spusten´
ych u
´loh). Ak priestor nie je, tak ˇziadost’ sa v z´avislosti
od v´
yberu pouˇz´ıvatel’a bude evidovat’, vznikne odloˇzen´a u
´loha (job) alebo sa ˇziadost’
zahod´ı.
2. skontroluje, ˇci neexistuj´
u odloˇzen´e ˇziadosti u
´loh (Joby). Ak existuj´
u odloˇzen´e ˇziadosti,
tak nov´
u ˇziadost’ odloˇz´ı a vytvor´ı u
´lohu, ktor´a bola odloˇzen´a (pr´ıpadne sa porovnaj´
u
priority ˇziadost´ı na z´aklade poˇciatoˇcnej priority u
´loh). T´ato oper´acia bude volitel’nou
pre pouˇz´ıvatel’a.
3. pod´a ˇziadost’ o vytvorenie priestoru spr´avcovi pam¨ate. V pr´ıpade, ˇze spr´avca nem´a
dostatok priestoru, tak bude ˇziadost’ v z´avislosti od v´
yberu pouˇz´ıvatel’a evidovan´a
alebo sa zahod´ı.
31
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
4. vytvor´ı proces v pr´ıpade, ˇze priestor v pam¨ati d´at je.
5. zarad´ı proces do pl´anovania.
Ak proces ukonˇcil svoju ˇcinnost’ manaˇz´er informuje spr´avcu pam¨ate, ˇze sa uvolnila
pam¨at’ dan´eho procesu a odstr´ani hlaviˇcku z tabul’ky procesov. Manaˇz´er kontroluje, ˇci neexistuj´
u nejak´e joby, ˇziadosti o vytvorenie nov´eho procesu, ak a´no tak sa job spracuje a vytvor´ı
sa z neho proces. T´ato moˇznost’ bude volitel’n´a pre pouˇz´ıvatel’a.
4.1.4
Pl´
anovaˇ
cu
´ loh
Pl´anovaˇc u
´loh bude rozhodovat’ o porad´ı pl´anovania procesov. Procesy bud´
u usporiadan´e v
ˇstrukt´
ure sp´ajan´
y zoznam.
D´atov´a ˇstrukt´
ura sp´ajan´
y zoznam (list) bude pouˇz´ıvan´a najm¨a na pr´acu s u
´lohami
(pr´ıstupn´a bude aj pre pouˇz´ıvatel’a). D´atov´a ˇstrukt´
ura bude navrhnut´a, tak aby bolo moˇzn´e
nov´e poloˇzky vkladat’ do zoznamu s ohl’adom na prioritu poloˇzky alebo vkladat’ na koniec
zoznamu bez ohl’adu na prioritu poloˇzky. Sp´ajan´
y zoznam bude obsahovat’ z´aznam o svojej vel’kosti a termin´ator. Termin´ator bude vˇzdy v zozname pr´ıtomn´
y, a ak bude zoznam
pr´azdny, tak bude ukazovat’ s´am na seba, teda bude tvorit’ kruhov´
u logick´
u ˇstrukt´
uru (obr.
´
´
4.1). Termin´ator sa nebude zapoˇc´ıtavat’ do dlˇzky zoznamu. Maxim´alna dlˇzka zoznamu bude
pevne stanoven´a poˇcas kompil´acie operaˇcn´eho syst´emu (mˆoˇze byt’ aj neobmedzen´a). Do zoznamu sa bud´
u vkladat’ poloˇzky (items). Poloˇzka bude ˇstrukt´
ura tvoren´a odkazom na d´ata,
napr´ıklad na TCB procesu. Bude obsahovat’ atrib´
ut, ktor´
y sa bude pouˇz´ıvat’ napr´ıklad ako
priorita, bude obsahovat’ ukazovatel’ na predch´adzaj´
uci prvok v zozname a nasleduj´
uci prvok
v zozname.
ˇ
Obr. 4.1: Strukt´
ura sp´ajan´eho zoznamu a poloˇzky
Nad sp´ajan´
ym zoznamom bud´
u implementovan´e oper´acie staraj´
uce sa o:
• inicializ´aciu sp´ajan´eho zoznamu,
32
4. N´avrh
• vkladanie a vyberanie poloˇziek sp´ajan´eho zoznamu,
• hl’adanie poloˇziek v sp´ajanom zozname,
• vyhl’adanie prvej respekt´ıve poslednej poloˇzky sp´ajan´eho zoznamu a
• zistenie plnosti respekt´ıve pr´azdnosti sp´ajan´eho zoznamu.
Z hl’adiska met´od pl´anovania bude pl´anovaˇc implementovan´
y t´
ymito pr´ıstupmi:
• pl´
anovanie bez priority vkladan´ım na koniec zoznamu pripraven´
ych procesov.
• pl´
anovanie s prioritou vkladan´ım do zoznamu pripraven´
ych procesov podl’a priority
s moˇznost’ou pridania funkcie prepoˇziˇciavania priority.
• pl´
anovanie s viacer´
ymi prioritn´
ymi zoznamami pripraven´
ych procesov vkladan´ım procesu podl’a jeho priority na koniec zoznamu urˇcenej priority s moˇznost’ou
pridania funkcie prepoˇziˇciavania priority.
Modul´arny operaˇcn´
y syst´em bude spracov´avat’ aj procesy re´alneho ˇcasu, ale bez z´aruky
dodrˇzania ˇcasov´eho limitu.
4.1.5
Riadenie komunik´
acie
Komunik´acia medzi procesmi bude zabezpeˇcen´a pomocou d´atov´eho toku. D´atov´
y tok bude
pozost´avat’ zo ˇstrukt´
ury rad a d’alˇs´ıch riadiacich inform´aci´ı.
ˇ
Strukt´
ura rad (queue) (obr. 4.2) bude pouˇz´ıvan´a ako jednosmern´
y kan´al, v ktorom sa
pren´aˇsaj´
u d´ata. Obsahom ˇstrukt´
ury rad bude aktu´alna vel’kost’, zaˇciatok radu a koniec radu.
Ak bude rad pr´azdny, tak koniec radu bude ukazovat’ na zaˇciatok radu a naopak. Poloˇzky
bud´
u vkladan´e do radu vˇzdy na koniec. Poloˇzka radu bude obsahovat’ atrib´
ut vyuˇzitel’n´
y
pri synchroniz´aci´ı, ukazovatel’ na pren´aˇsan´
y obsah a ukazovatel’ na d’alˇsiu poloˇzku v rade.
Zaˇciatok a koniec radu bud´
u trval´e a nebud´
u sa zapoˇc´ıtavat’ do d´lˇzky radu. D´lˇzka radu bude
pevne stanoven´a poˇcas kompil´acie operaˇcn´eho syst´emu.
Rad bude implementovan´
y z dˆovodu niˇzˇsej spotreby pam¨ate ako sp´ajan´
y zoznam a
z dˆovodu jednoduchˇs´ıch oper´aci´ı nad radom. Nad radom bud´
u implementovan´e oper´acie
staraj´
uce sa o:
• inicializ´aciu radu,
• vkladanie a vyberanie poloˇziek radu,
• vyhl’adanie prvej respekt´ıve poslednej poloˇzky radu a
• zistenie plnosti respekt´ıve pr´azdnosti radu.
33
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
ˇ
Obr. 4.2: Strukt´
ura radu a poloˇzky
Okrem radu bude hlaviˇcka toku d´at obsahovat’ aj identifik´ator registrovan´eho odosielatel’a, stav d´atov´eho toku, priestor na uloˇzenie pozastaven´eho odosielatel’a, priestor na uloˇzenie pozastaven´eho pr´ıjemcu a priestor pre z´amku. D´atov´
y tok bude mat’ jedn´eho odosielatel’a
a jedn´eho pr´ıjemcu.
ˇ
Odosielatel’ sa bude registrovat’ u pr´ıjemcu ˇziadost’ou o vytvorenie spojenia. Ziadost’
sa
zarad´ı (podl’a priority alebo na koniec) do zoznamu ˇcakaj´
ucich odosielatel’ov na pridelenie
d´atov´eho toku. Odkaz na zoznam ˇcakaj´
ucich registr´aci´ı bude mat’ kaˇzd´
y proces vo svojej
hlaviˇcke (TCB). Ak je zoznam ˇcakatel’ov pln´
y, tak dan´
y ˇziadatel’ bude odmietnut´
y. V pr´ıpade, ˇze pr´ıjemca nechce prij´ımat’ ˇziadne d´ata, tak registrovan´
y odosielatelia bud´
u musiet’
ˇcakat’. D´atov´
y tok je otvoren´
y aˇz po akceptovan´ı registr´acie pr´ıjemcom. Na strane pr´ıjemcu
sa bude dat’ rozhodn´
ut’, ˇci chce komunikovat’ s dan´
ym odosielatel’om. Ak pr´ıjemca nechce
komunikovat’ s odosielatel’om, tak dan´a registr´acia sa zamietne. Pr´ıjemca akceptovan´ım registr´acie povol´ı odosielatel’ovi odosielat’ d´ata (obr. 4.3).
Odosielanie d´at bude implementovan´e blokuj´
ucimi aj neblokuj´
ucimi volaniami. Odosielatel’ bude pozastaven´
y, ak sa pok´
usi odoslat’ d´ata do pln´eho radu blokuj´
ucim volan´ım.
Odosielatel’ bude mat’ moˇznost’ poslat’ d´ata a ˇcakat’ na potvrdenie blokuj´
ucim volan´ım. Pr´ıjemca bude prij´ımat’ d´ata blokuj´
ucim aj neblokuj´
ucim volan´ım. V pr´ıpade pokusu o ˇc´ıtanie
d´at z pr´azdneho radu blokuj´
ucim volan´ım bude pr´ıjemca pozastaven´
y, k´
ym nie s´
u pripraven´e
d´ata. Ak bude pr´ıjemca blokovan´
y a do radu bud´
u vloˇzen´e d´ata, tak pr´ıjemca bude odblokovan´
y. Rovnako ak bude blokovan´
y odosielatel’ a z radu bud´
u odobran´e d´ata, tak odosielatel’
bude odblokovan´
y.
34
4. N´avrh
Obr. 4.3: Pr´ıklad vytvorenia pouˇz´ıvatel’om navrhnutej komunik´acie
4.2
Spr´
avca pam¨
ate
Spr´avca pam¨ate bude viest’ inform´acie o vyuˇzit´ı pam¨ate programu, pam¨ate d´at a pam¨ate
procesov.
Pam¨at’ programov, d´at a premenn´
ych bude realizovan´a ako sp´ajan´
y zoznam u
´sekov. Zoznam bude obsahovat’ inform´aciu o nasleduj´
ucom u
´seku, vel’kosti u
´seku a obsadenosti u
´seku.
Na z´aklade volania malloc() bude spr´avca pam¨ate pridel’ovat’ pam¨at’ na u
´rovni premenn´
ych procesu alebo jadra. Na z´aklade volania tmalloc() bude spr´avca pridel’ovat’ pam¨at’ na
u
´rovni procesov. Na z´aklade volania pmalloc() bude spr´avca pridel’ovat’ pam¨at’ programom.
Vkladanie programu do pam¨ate bude realizovan´e pomocou nato urˇcen´eho zav´adzacieho procesu.
Spr´avca pam¨ate bude pridel’ovat’ pam¨at’ bud’ nov´emu procesu alebo premennej procesu.
Preto spr´avca bude poznat’ minim´alne inform´acie o vol’n´
ych u
´sekoch pam¨ate d´at nepridelenej
ˇziadnemu procesu. Na ˇziadost’ o vytvorenie nov´eho procesu (tmalloc()) spr´avca vyhl’ad´a
vhodn´
yu
´sek pam¨ate, ktor´
y vyhrad´ı pre proces.
V pr´ıpade, ˇze proces poˇzaduje alokovat’ pam¨at’ov´
y priestor pre svoju premenn´
u(malloc()),
spr´avca pam¨ate bude pridel’ovat’ pam¨at’ dvoma spˆosobmi, podl’a toho ako bude realizovan´a
pam¨at’ d´at procesu. Ako bolo spomenut´e kaˇzd´
y proces m´a mat’ pridelen´
u statick´
u a dynamick´
u pam¨at’ d´at. Statick´a pam¨at’ d´at bude v procesoch beˇziacich pod MOS vyl´
uˇcen´a, ak
procesor nebude mat’ b´azov´e registre. Dynamick´a pam¨at’ je zloˇzen´a zo z´asobn´ıka a haldy.
Z´asobn´ık je pam¨at’, ktor´a je obsadzovan´a bez priˇcinenia program´atora, napr´ıklad volan´ım
funkcie. Halda je pam¨at’, ktor´a sa obsadzuje s priˇcinen´ım program´atora, napr´ıklad alokovanie
35
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
priestoru pre ukazovatel’.
Z tohoto dˆovodu je moˇzn´e uvaˇzovat’ dve met´ody realiz´acie pridelenia pam¨at’ov´eho
priestoru premennej procesu:
• Bud’ bude halda spoloˇcnou pre vˇsetky procesy, a teda spr´avcovi bud´
u staˇcit’ dva zoznamy vol’n´
ych u
´sekov pam¨ate. Jeden pre v´
yber pam¨ate pre proces s menˇsou granularitou vel’kosti u
´seku. Druh´
y pre v´
yber pam¨ate pre premenn´
u s v¨aˇcˇsou granularitou
vel’kosti u
´seku, alebo
• kaˇzd´
y proces bude mat’ svoju vlastn´
u haldu vo svojom pam¨at’ovom priestore. S´
uˇcast’ou
hlaviˇcky procesu teda bude aj ukazovatel’ na zoznam vol’n´
ych u
´sekov pam¨ate. Spr´avca
pam¨ate bude pridel’ovat’ pam¨at’ na z´aklade priloˇzen´eho zoznamu vol’n´
ych u
´sekov pam¨ate z hlaviˇcky procesu.
4.3
Spr´
avca V/V zariaden´ı
Spr´avca V/V zariaden´ı bude spravovat’ kaˇzd´e alebo ˇcast’ zariaden´ı na procesore, ktor´e komunikuj´
u s okol´ım alebo s´
u internou s´
uˇcast’ou procesora (ˇcasovaˇc). Spr´avca V/V zariaden´ı
bude tvoren´
y mnoˇzinou blokuj´
ucich a neblokuj´
ucich volan´ı, prostredn´ıctvom ktor´
ych bude
moˇzn´e prist´
upit’ k poˇzadovan´emu zariadeniu. Vybran´e zariadenia bud´
u obalen´e platformovo
z´avislou prezentaˇcnou vrstvou realizovanou v jazyku symbolick´
ych inˇstrukci´ı, s ktorou bude
komunikovat’ konkr´etne volanie. Spr´avca V/V zariaden´ı bude vykon´avat’ aj spr´avu preruˇsen´ı
generovan´
ych zariadeniami.
Namiesto volan´ı bude mˆoct’ MOS riadit’ zariadenia pomocou MOS procesov. Ak chce
pouˇz´ıvatel’sk´
y proces komunikovat’ so zariaden´ım, mus´ı sa registrovat’ ako odosielatel’ na
konkr´etnom MOS procese. Naopak ak chce zariadenie komunikovat’ s konkr´etnym pouˇz´ıvatel’sk´
ym procesom, MOS proces sa mus´ı registrovat’ na pouˇz´ıvatel’skom procese ako odosielatel’. Spr´avca V/V zariaden´ı bude v takomto pr´ıpade tvorit’ vrstvu nad zariadeniami,
ktor´a je platformovo z´avisl´a. S touto vrstvou bud´
u pracovat’ MOS procesy, ktor´e bud´
u ˇciastoˇcne platformovo z´avisl´e.
4.4
Riadenie spotreby energie
Riadenie spotreby energie bude priamou s´
uˇcast’ou modulov spr´avy V/V zariaden´ı a riadenia procesov. Riadenie spotreby je platformovo z´avisl´e a zv¨aˇcˇsa bude implementovan´e v
jazyku symbolick´
ych inˇstrukci´ı. Spr´ava V/V zariaden´ı bude vyp´ınat’ respekt´ıve uv´adzat’ do
u
´sporn´eho reˇzimu zariadenia v pr´ıpade, ˇze nie s´
u potrebn´e. Riadenie procesov bude uv´adzat’
do u
´sporn´eho reˇzimu procesor v pr´ıpade n´ızkeho alebo ˇziadneho poˇctu spusten´
ych procesov.
36
4. N´avrh
4.5
Riadenie pr´ıstupu
Moduly MOS alebo pouˇz´ıvatel’sk´e procesy, ktor´e potrebuj´
u aby pr´ıstup do niektor´
ych zariaden´
y alebo u
´sekov k´odu bol chr´anen´
y pred vstupom viacer´
ych procesov, bud´
u mˆoct’ pouˇzit’
sluˇzby riadenia pr´ıstupu pomocou semaforov a z´amok. Riadenie pr´ıstupu bude platformovo
z´avisl´e. Ak procesor m´a podporu inˇstrukcie kontroly a z´apisu premennej (TSL), tak riadenie
pr´ıstupu bude navrhnut´e s pouˇzit´ım tejto inˇstrukcie. V pr´ıpade, ˇze procesor tak´
uto inˇstrukciu
nepodporuje, tak kontrola a nastavenie premennej bude chr´anen´e zak´azan´ım a po vykonan´ı
op¨atovn´
ym povolen´ım preruˇsenia.
Pri pokuse o vstup do kritickej oblasti, ktor´a je uˇz obsaden´a bude ˇziadatel’ o vstup
pozastaven´
y alebo blokovan´
y. Blokovanie respekt´ıve pozastavenie ˇziadatel’a bude z´avisiet’
od v´
yberu typu volania.
V´
ystup z kritickej oblasti jednoducho otvor´ı z´amku respekt´ıve zn´ıˇzi hodnotu semafora.
4.6
Perif´
eria Operaˇ
cn´
eho syst´
emu
Okrem jadra operaˇcn´eho syst´emu bude operaˇcn´
y syst´em implementovat’ najm¨a MOS procesy,
ktor´e, ako bolo spomenut´e, bud´
u obal’ovat’ pripojen´e zariadenia procesora.
Na perif´erii operaˇcn´eho syst´emu bude implementovan´
y aj mechanizmus zav´adzania a
aktualiz´acie programov. T´ato moˇznost’ je vhodn´a najm¨a, ak je nutn´e udrˇzat’ operaˇcn´
y syst´em
v chode bez potreby jeho op¨atovnej inicializ´acie. Mnoh´e operaˇcn´e syst´emy na tak´eto moˇznosti
neprihliadaj´
u, ˇco brzd´ı ich pouˇzitie v pln´
ych prev´adzkach. Aktualiz´aciou programu sa bude
rozumiet’ v´
ymena programov, ktor´e uˇz s´
u zaveden´e v programovej pam¨ati. Zavedenie u
´plne
nov´eho programu bude jednoduchˇsou verziou aktualiz´acie, kedy sa len na vol’n´e miesto v
pam¨ati programov umiestni nov´
y program.
ˇ
Ziadost’
o zavedenie nov´eho programu spust´ı zav´adzac´ı proces, ktor´
y sa pl´anuje na procesor. Proces bude ˇziadat’ spr´avcu pam¨ate o pridelenie miesta pre nov´
y program. V pr´ıpade,
ˇze miesto nie je, je ˇziadost’ zamietnut´a a proces zav´adzaˇc konˇc´ı. V pr´ıpade kladnej odozvy
spr´avcu pam¨ate je nov´
y program uloˇzen´
y do pam¨ate d´at a je vytvoren´
y nov´
y z´aznam do
tabul’ky programov.
ˇ
Ziadost’
o aktualiz´aciu programu spust´ı zav´adzac´ı proces, ktor´
y poˇziada o v´
ymenu programu s dan´
ym identifikaˇcn´
ym ˇc´ıslom. Proces, rovnako ako pri zaveden´ı nov´eho programu,
vykon´a z´apis programu do pam¨ate programov. Pˆovodn´
y program bude mat’ v hlaviˇcke programu nastaven´
y pr´ıznak, ktor´
y odkazuje na z´aznam v hlaviˇcke nov´eho programu, ˇc´ım sa
zabezpeˇc´ı sp´
uˇst’anie nov´
ych procesov pod novou verziou programu. Ak pˆovodn´
y program uˇz
nem´a ˇziadnu spusten´
u inˇstanciu, tak sa jeho z´aznam v tabul’ke programov prep´ıˇse nov´
ym
z´aznamom a jeho priestor v pam¨ati programov sa uvol’n´ı.
Moˇznost’ zav´adzania do pam¨ate programov bude umoˇznen´a len, ak procesor podporuje
37
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
z´apis do pam¨ate programu za behu syst´emu.
4.7
V´
yber platformy
Modul´arny operaˇcn´
y syst´em bude testovan´
y na procesore rodiny ARM7 pr´ıpadne aj na
procesore z rodiny Atmel AVR.
Z kateg´orie procesorov ARM7 bude pouˇzit´a v´
yvojov´a doska Sam7-p256 od firmy Olimex
[8] s procesorom AT91SAM7S256 [9]. V´
yvojov´
y kit m´a 256 kB pam¨ate programu na ˇcipe typu
flash a 64 kB pam¨ate d´at na ˇcipe typu ram. V´
yvojov´a doska m´a vyveden´e dve s´eriov´e rozhrania, m´a moˇznost’ vyvedenia s´eriov´eho rozhrania na v´
ypis ladiacich spr´av, USB 2.0, 10 bitov´
y
anal´ogovo-digit´alny prevodn´ık, I2C rozhranie, SPI rozhranie, 3x ˇcasovaˇc, 4x PWM, watchdog WDT, DMA (priami pr´ıstup k pam¨ati pre vˇsetky zariadenia), dve tlaˇcidl´a, konektor na
SD kartu. Moˇznost’ pr´ace v 60 MHz frekvencii. Procesor m´a vyveden´e vˇsetky piny na doske.
Programovanie a ladenie prostredn´ıctvom JTAG.
38
5. Implement´acia
5 Implement´
acia
T´ato kapitola prezentuje implementovan´e ˇcasti MOS na platforme ARM7tdmi. V ˇcase publikovania tejto pr´ace s´
u implementovan´e a funkˇcne otestovan´e d´atov´e ˇstrukt´
ury sp´ajan´
y
zoznam a rad. Implementovan´
y a funkˇcne otestovan´
y je modul spr´avy pam¨ate, pl´anovania
u
´loh, medziprocesnej komunik´acie, manaˇzmentu procesov, riadenia pr´ıstupu a ˇstatistiky. Implementovan´e s´
u platformovo z´avisl´e ˇcasti operaˇcn´eho syst´emu. MOS m´a rozvrstven´
y zdrojov´
y k´od podl’a modulov do samostatn´
ych hlaviˇckov´
ych a zdrojov´
ych s´
uborov. Platformovo
nez´avisl´e ˇcasti MOS s´
u implementovan´e v programovacom jazyku C. Platformovo z´avisl´e
ˇcasti MOS s´
u implementovan´e z ˇcasti v programovacom jazyku C a z ˇcasti v jazyku symbolick´
ych inˇstrukci´ı.
5.1
ˇ
Strukt´
ura zdrojov´
ych k´
odov MOS
Vlastnosti MOS sa nastavuj´
u prostredn´ıctvom konfiguraˇcn´eho s´
uboru config.h. V tomto s´
ubore je zoznam konfiguraˇcn´
ych premenn´
ych riadiacich spˆosob kompil´acie MOS. Platformovo
z´avisl´e defin´ıcie typov premenn´
ych s´
u uloˇzen´e v hlaviˇckovom s´
ubore port.h. Platformovo
z´avisl´e ˇcasti zdrojov´eho k´odu s´
u s´
ustreden´e v zdrojov´
ych s´
uboroch port.c, main.c a asmport.S.
V s´
ubore port.c s´
u definovan´e funkcie inicializuj´
uce ˇcasovanie prepnutia u
´lohy, funkcie
riadiace vstup a v´
ystup z kritickej oblasti a pomocn´e funkcie s´
uvisiace so ˇstatistick´
ym meran´ım.
V s´
ubore main.c sa nach´adza funkcia main, v ktorej sa inicializuj´
u jednotliv´e moduly
MOS. V tomto s´
ubore je implementovan´a sp´
uˇst’acia sekvencia MOS.
V s´
ubore asmport.S s´
u uloˇzen´e ob´alky volan´ı MOS, ktor´e vyˇzaduj´
u prepnutie do chr´anen´eho m´odu jadra. Nach´adza sa tu platformovo z´avisl´a inicializ´acia spustenia MOS a odloˇzenie a naˇc´ıtanie kontextu poˇcas prepnutia u
´lohy.
Platformovo nez´avisl´e ˇcasti MOS s´
u s´
ustreden´e v s´
uboroch ipc.c, taskMNG.c, memMNG.c, list.c, queue.c a mos.c. V s´
ubore ipc.c s´
u funkcie riadiace medziprocesn´
u komunik´aciu.
V s´
ubore taskMNG.c s´
u funkcie s´
uvisiace s inicializ´aciou MOS, pl´anovan´ım, vytv´aran´ım,
ukonˇcovan´ım a prep´ınan´ım u
´loh. S´
u tu aj funkcie s´
uvisiace so ˇstatistick´
ym meran´ım.
V s´
ubore memMNG.c s´
u funkcie s´
uvisiace s pridel’ovan´ım pam¨ate procesom a premenn´
ym. S´
u tu aj funkcie s´
uvisiace so ˇstatistick´
ym meran´ım.
V s´
uboroch list.c a queue.c s´
u funkcie u
´zko s´
uvisiace so ˇstrukt´
urou sp´ajan´
y zoznam
respekt´ıve ˇstrukt´
urou rad.
39
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
V s´
ubore mos.c je uloˇzen´a defin´ıcia koreˇ
nov´eho procesu MOS. Do tohto s´
uboru mˆoˇzu
pouˇz´ıvatelia vkladat’ svoje defin´ıcie procesov a definovat’ pracovn´
u n´aplˇ
n koreˇ
nov´eho procesu.
Okrem spom´ınan´
ych s´
uborov s´
u s´
uˇcast’ou zdrojov´
ych k´odov MOS aj s´
ubory CStartup.S
ubory s´
u prevzat´
ymi s´
ubormi od spoloˇcnosti Atmel. Sl´
uˇzia na
a Cstartup SAM7.c. Tieto s´
n´ızko´
urovˇ
nov´
u inicializ´aciu platformy ARM7tdmi.
5.2
D´
atov´
eˇ
strukt´
ury sp´
ajan´
y zoznam a rad
Sp´ajan´
y zoznam bol implementovan´
y, tak ako bol navrhnut´
y v kapitole 4. N´avrh (obr. 4.1).
Zoznam je realizovan´
y ako ˇstrukt´
ura obsahuj´
uca z´aznam o aktu´alnej vel’kosti zoznamu a
ˇ
termin´ator, ktor´
y je typu poloˇzka. Strukt´
ura poloˇzka obsahuje z´aznam atrib´
utu, ukazovatel’
na obsah poloˇzky typu void, ukazovatele na predch´adzaj´
ucu a nasleduj´
ucu poloˇzku typu
poloˇzka. Zoznam nem´a implementovan´e blokovanie procesov. Nad sp´ajan´
ym zoznamom s´
u
implementovan´e oper´acie:
uru zoznamu. T´ato funkcia inicial• L init(zoznam) m´a na vstupe ukazovatel’ na ˇstrukt´
izuje vel’kost’ zoznamu na “0“. Ukazovatele na nasleduj´
ucu a predch´adzaj´
ucu poloˇzku
v termin´atore nastav´ı tak, aby ukazovali na termin´ator.
• L push(zoznam, poloˇzka), L insert(zoznam, poloˇzka) riadia vkladanie do zoznamu.
Funkcia L push() vloˇz´ı poloˇzku na koniec zoznamu. Funkcia L insert() vloˇz´ı poloˇzku do
zoznamu na z´aklade hodnoty atrib´
utu. Po vloˇzen´ı poloˇzky do zoznamu vracaj´
u funkcie
ukazovatel’ na vkladan´
u poloˇzku. Ak je zoznam pln´
y, funkcie vracaj´
u hodnotu NULL.
u poloˇzku a jej hodnotu vr´ati na v´
ystup. Ak
• L pop(zoznam) vyberie zo zoznamu prv´
je zoznam pr´azdny tak vr´ati hodnotu NULL.
• L isFull(zoznam), L isEmpty(zoznam) s´
u makrami a vracaj´
u “1“ ak je zoznam pln´
y
resp. pr´azdny a “0“ ak nie je zoznam pln´
y resp. pr´azdny.
• L first(zoznam), L last(zoznam) s´
u makrami a vracaj´
u ukazovatel’ na prv´
u resp. posledn´
u
poloˇzku, na ktor´
u ukazuje termin´ator.
• L search(zoznam, d´ata), L searchAtt(zoznam, atrib´
ut) vyhl’ad´avaj´
u poloˇzku na z´aklade hodnoty ukazovatel’a na d´ata resp. na z´aklade hodnoty atrib´
utu. Pouˇzitie t´
ychto
funkci´ı bude eˇste predmetom rozhodovania.
• L delete(poloˇzka) dan´
u poloˇzku, n´ajden´
u funkciou L search(), odpoj´ı z radu. T´ato
funkcia bude tieˇz predmetom sk´
umania jej pouˇzitel’nosti.
Rad bol implementovan´
y, tak ako bol navrhnut´
y v kapitole 4. N´avrh (obr. 4.2). Rad
je realizovan´
y ako ˇstrukt´
ura obsahuj´
uca z´aznam o aktu´alnej vel’kosti radu, poloˇzku konca
40
5. Implement´acia
a poloˇzku zaˇciatku radu. Poloˇzka obsahuje z´aznam atrib´
ut, ukazovatel’ na pren´aˇsan´e d´ata
typu void, ukazovatel’ na nasleduj´
ucu poloˇzku v rade. Rad nem´a implementovan´e blokovanie
u
´loh. Nad radom s´
u implementovan´e oper´acie:
uru radu. T´ato funkcia inicializuje
• Q init(rad) m´a na vstupe ukazovatel’ na ˇstrukt´
vel’kost’ radu na “0“ a poloˇzku zaˇciatku radu nastav´ı tak aby ukazovala na poloˇzku
konca a naopak.
• Q push(rad, poloˇzka) riadi vkladanie do radu. Funkcia vloˇz´ı poloˇzku na koniec radu.
Po vloˇzen´ı poloˇzky do radu funkcia vracia ukazovatel’ na vkladan´
u poloˇzku. V pr´ıpade,
ak je rad pln´
y, funkcia vracia hodnotu NULL.
u poloˇzku z radu a vr´ati ju na v´
ystupe. Ak je rad pr´azdny tak
• Q pop(rad) vyberie prv´
vr´ati hodnotu NULL.
• Q isFull(rad), Q isEmpty(rad) s´
u makrami a vracaj´
u “1“ ak je rad pln´
y resp. pr´azdny
a “0“ ak nie je rad pln´
y resp. pr´azdny.
u makrami a vracaj´
u ukazovatel’ na prv´
u resp. posledn´
u
• Q first(rad), Q last(rad) s´
poloˇzku, na ktor´
u ukazuje zaˇciatok resp. koniec.
5.3
Spr´
avca pam¨
ate
Spr´avca pam¨ate bol implementovan´
y podl’a n´avrhu. Spr´avca pam¨ate spravuje:
• Z´asobn´ık jadra (stack). Priestor pre odkladanie premenn´
ych jadra. Jeho vel’kost’ sa
nastavuje v konfiguraˇcnom s´
ubore. Zaˇciatok a koniec z´asobn´ıka je uloˇzen´
y v statick´
ych
premenn´
ych, ktor´e s´
u naplnen´e poˇcas inicializ´acie spr´avcu.
• Haldu jadra (heap). Priestor na alokovanie pam¨ate premenn´
ym jadra (napr. hlaviˇcky
u
´loh a procesov). Ak je MOS nastaven´
y tak, ˇze procesy nemaj´
u svoju intern´
u haldu,
je tu alokovan´
y priestor aj pre premenn´e procesov. Poˇciatok haldy jadra je uloˇzen´
yv
statickej premennej a je nastaven´
y poˇcas inicializ´acie spr´avcu pam¨ate.
• Pam¨at’ procesov. Vymedzuje priestor na alokovanie pam¨ate pre sp´
uˇst’an´e procesy. Poˇciatok pam¨ate procesov je uloˇzen´
y v statickej premennej a je nastaven´
y poˇcas inicializ´acie
spr´avcu pam¨ate.
• Halda procesu. Vymedzuje priestor pre alokovanie premenn´
ych procesov. Halda procesu
sa generuje poˇcas vytvorenia procesu len vtedy, ak je konfigurovan´a v konfiguraˇcnom
s´
ubore.
41
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Pridel’ovanie pam¨ate je realizovan´e pomocou met´ody prv´y vyhovuj´
uci (first fit). Z´aklad´
n´
ym kameˇ
nom met´ody je udrˇziavanie zoznamu u
´sekov pam¨ate. Usek
je ˇstrukt´
ura, ktor´a m´a
svoju adresu urˇcen´
u poz´ıciou v pam¨ati, m´a ukazovatel’ na d’alˇs´ı u
´sek, m´a inform´aciu o d´lˇzke
u
´seku a m´a inform´aciu o stave u
´seku. Inform´acie o stave a vel’kosti u
´seku s´
u v naˇsej implement´acii zl´
uˇcen´e do jednej poloˇzky. Poˇzadovan´a vel’kost’ pridelenej pam¨ate je zarovnan´a na
4B (32-bitov´e syst´emy). Z tohto dˆovodu s´
u dva najmenej v´
yznamn´e bity vel’kosti pridelenej
pam¨ate vˇzdy nulov´e. Najmenej v´
yznamn´
y byt je preto pouˇzit´
y ako bit indikuj´
uci obsadenost’
u
´seku. Ak je bit nulov´
y, u
´sek je vol’n´
y, a ak je bit jednotkov´
y, tak u
´sek je obsaden´
y. Po definovanom u
´seku nasleduje pam¨at’, ktor´a je pod jeho spr´avou (Obr. 5.1).
Obr. 5.1: Zoznam u
´sekov pam¨ate a ˇstrukt´
ura u
´sek
Poˇcas inicializ´acie sa podl’a konfiguraˇcn´eho s´
uboru nastav´ı pam¨at’ haldy a pam¨at’ procesov. Obe pam¨ate spoˇciatku obsahuj´
u jedin´
y u
´sek, ktor´
y nem´a suseda a jeho vel’kost’ je
nastaven´a na konfigurovan´
u vel’kost’ zmenˇsen´
u o r´eˇziu u
´seku. Rovnak´
y postup je vykonan´
y
po pridelen´ı pam¨ate pre haldu procesu.
Spr´avca pam¨ate disponuje tromi funkciami, ktor´e spravuj´
u pam¨at’. S´
u to funkcie:
• malloc(vel’kost’),
• tmalloc(vel’kost’) a
• free(premenn´a).
Funkcia malloc() pridel’uje pam¨at’ pre premenn´e procesov aj jadra. Ak je procesor v
privilegovanom reˇzime, tak sa pridel’uje pam¨at’ v halde jadra, inak je pridel’ovan´a pam¨at’ v
halde procesu. Poˇcas pridel’ovania pam¨ate sa najprv hl’ad´a u
´sek rovnak´
y alebo v¨aˇcˇs´ı ako je
poˇzadovan´a vel’kost’ (vel’kost’ je zaokr´
uhlen´a nahor na n´asobok ˇstyroch bajtov). Ak sa tak´
y
u
´sek n´ajde a je v¨aˇcˇs´ı ako poˇzadovan´a vel’kost’ zv¨aˇcˇsen´
y o r´eˇziu, dan´
yu
´sek sa rozdel´ı na dva.
Prv´
y bude mat’ poˇzadovan´
u vel’kost’ a druh´
y zost´avaj´
ucu vel’kost’. N´asledne sa dan´
yu
´sek
nastav´ı na obsaden´
y (obr. 5.2).
42
5. Implement´acia
Obr. 5.2: Priebeh vykonania funkcie malloc()
Funkcia tmalloc() pridel’uje pam¨at’ pre nov´e procesy. Funkcia sa spr´avne vykon´a len
ak je procesor v chr´anenom reˇzime. Tmalloc() funguje na rovnakom princ´ıpe ako funkcia
malloc(). Rozdiel je v zaokr´
uhlen´ı (nahor) poˇzadovanej vel’kosti pam¨ate na konfigurovatel’n´
y
n´asobok (napr. 256 B) a v pridelen´ı u
´seku. Uˇz vybran´
yu
´sek sa pred pridelen´ım rozdel´ı na
dva skoro rovnako vel’k´e u
´seky. Prv´
yu
´sek sa st´ava haldou, ktor´a bude o r´eˇziu menˇsia ako
druh´
yu
´sek, ktor´
y sa st´ava z´asobn´ıkom (obr. 5.3).
Obr. 5.3: Priebeh vykonania funkcie tmalloc()
Funkcia free() uvol’ˇ
nuje pridelen´
u pam¨at’. Funkcia funguje rovnako pre vˇsetky druhy
pam¨at´ı MOS. Vstup funkcie je premenn´a. Adresa u
´seku pridelenej pam¨ate sa vypoˇc´ıta ako
43
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
rozdiel adresy pridelenej vstupnej premennej a r´eˇzie u
´seku. Po identifikovan´ı u
´seku sa dan´
y
u
´sek uvol’n´ı. Po uvol’nen´ı u
´seku sa zist’uje, ˇci nasleduj´
uci u
´sek nie je tieˇz vol’n´
y. Ak je
vol’n´
y, tak dan´e u
´seky sa zl´
uˇcia do jedn´eho. T´ato oper´acia sa opakuje, k´
ym sa nen´ajde
prv´
y obsaden´
y u
´sek alebo sa neskonˇc´ı pam¨at’. Tak´
ymto rieˇsen´ım sa ˇciastoˇcne zamedzuje
fragment´acii pam¨ate (obr. 5.4).
Obr. 5.4: Priebeh vykonania funkcie free()
5.4
Riadenie procesov
V ˇcasti riadenie procesov sme implementovali modul Pl´anovaˇc, Manaˇz´er u
´loh a Riadenie
komunik´acie.
5.4.1
Pl´
anovaˇ
c
Pl´anovanie u
´loh bolo implementovan´e troma rˆoznymi met´odami. Zdrojov´
y k´od pl´anovaˇca
je v s´
ubore taskMNG.c. Spoloˇcn´
ym prvkom vˇsetk´
ych troch druhov pl´anovaˇca je staticky
uloˇzen´
y sp´ajan´
y zoznam (v pr´ıpade viac´
urovˇ
nov´eho pl´anovaˇca pole sp´ajan´
ych zoznamov), do
ktor´eho sa ukladaj´
u pripraven´e u
´lohy. Tento zoznam je viditel’n´
y len v s´
ubore taskMNG.c.
Pouˇz´ıvatel’ nevie priamo zasiahnut’ do procesu pl´anovania. Sp´ajan´
y zoznam je inicializovan´
y
poˇcas inicializ´acie MOS. Pl´anovanie riadia tri funkcie:
• funkcia SCH init() inicializuje sp´ajan´
y zoznam.
• funkcia schedule() vklad´a u
´lohu do sp´ajan´eho zoznamu. Ak je zoznam pln´
y, vracia
chybov´
u hodnotu.
44
5. Implement´acia
• funkcia getTask() vyber´a u
´lohu zo zoznamu. Ak je zoznam pr´azdny, vracia chybov´
u
hodnotu.
Pl´
anovanie Round Robin
Tento druh pl´anovania pouˇz´ıva vyˇsˇsie uveden´
u ˇstrukt´
uru sp´ajan´
y zoznam na ukladanie u
´loh
´
pripraven´
ych a ˇcakaj´
ucich na pridelenie procesorov´eho ˇcasu. Ulohy s´
u vkladan´e do zoznamu
podl’a poradia v akom prich´adzaj´
u, princ´ıpom prv´a dnu prv´a von (FIFO).
Prioritn´
e pl´
anovanie
V prioritnom pl´anovan´ı sa pouˇz´ıva predom definovan´a priorita u
´lohy. Priorita u
´lohy je urˇcen´a
´
poˇcas vytvorenia u
´lohy. Ulohy
s´
u vkladan´e do zoznamu podl’a v´
yˇsky priority. Prvou sa stane
u
´loha s najvyˇsˇsou prioritou.
Viac u
´ rovˇ
nov´
e pl´
anovanie
Viac´
urovˇ
nov´e pl´anovanie je zaloˇzen´e na princ´ıpe ukladania u
´loh s prioritou, spadaj´
ucou do
rovnakej triedy, do samostatn´eho sp´ajan´eho zoznamu. Naˇse prioritn´e pl´anovanie vytv´ara
ych zoznamov, kde k je najvyˇsˇsia moˇzn´a priorita.
n = k2 sp´ajan´
´
´lohy. V´
yhodou tak´ehoto rieˇsenia je
Uloha
je vloˇzen´a do radu n = k2 , kde k je priorita u
´
r´
ychla realiz´acia delenia dvomi pomocou bytov´eho posunu doprava. Uloha
je vkladan´a do
vybran´eho sp´ajan´eho zoznamu vˇzdy na koniec.
Pri v´
ybere u
´loh z pl´anovaˇca sa postupne prech´adza od prioritne najvyˇsˇsieho sp´ajan´eho
zoznamu po prioritne najniˇzˇs´ı.
5.4.2
Manaˇ
z´
er u
´ loh
´
Ulohou
modulu Manaˇz´er u
´loh je spravovat’ hlaviˇcky uloˇzen´
ych programov (PCB), hlaviˇcky
spusten´
ych procesov (TCB) a aktu´alne beˇziacu u
´lohu (running). Hlaviˇcky sa s´
ustredia do
dvoch samostatn´
ych sp´ajan´
ych zoznamov. S´
u to zoznamy Tabul’ka hlaviˇciek programov
(PCBT) a Tabul’ka hlaviˇciek procesov (TCBT). Sp´ajan´e zoznamy s´
u statick´
ymi premenn´
ymi MOS, ktor´e sa nastavuj´
u poˇcas inicializ´acie MOS. Manaˇz´er u
´loh poskytuje rozhranie
pre vkladanie nov´
ych hlaviˇciek programov a sp´
uˇst’anie, prep´ınanie a ukonˇcovanie procesov.
Aktu´alne beˇziaca u
´loha je uloˇzen´a v statickej premennej.
Hlaviˇcka programu je ˇstrukt´
ura, ktor´a udrˇzuje inform´acie o uloˇzenom programe v programovej pam¨ati procesora. Kaˇzd´a hlaviˇcka programu spolu so ˇstrukt´
urou poloˇzky, ktor´a ju
zapuzdruje, m´a svoj alokovan´
y priestor v halde jadra. Na obr´azku 5.5 je zobrazen´a ˇstrukt´
ura
hlaviˇcky programu spolu so zapuzdrujucou poloˇzkou zoznamu. Atrib´
ut poloˇzky (oznaˇcen´
y
*) nadob´
uda poˇcas inicializ´acie hlaviˇcky hodnotu identifik´atora programu. Identifik´ator jednoznaˇcne identifikuje kaˇzd´
y program. Adresa zaˇciatku programu odkazuje na poˇciatoˇcn´
u
45
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
adresu programu v pam¨ati programov. Vel’kost’ pam¨ate d´at urˇcuje, ak´
y vel’k´
yu
´sek pam¨ate z
pam¨ate procesov bude pridelen´
y novej inˇstancii programu. Poˇcet spusten´
ych u
´loh ud´ava aktu´alny poˇcet beˇziacich procesov, ktor´e s´
u inˇstanciami dan´eho programu. Poˇciatoˇcn´a priorita
urˇcuje ak´
u bude mat’ proces prioritu po jeho vytvoren´ı.
ˇ
Obr. 5.5: Strukt´
ura PCB a zapuzdruj´
uca poloˇzka zoznamu
Hlaviˇcka procesu je ˇstrukt´
ura, ktor´a udrˇzuje inform´acie o spustenom procese. Kaˇzd´a hlaviˇcka procesu spolu so ˇstrukt´
urou poloˇzky, ktor´a ju zapuzdruje, m´a svoj alokovan´
y priestor
v halde jadra. Na obr´azku 5.6 je zobrazen´a ˇstrukt´
ura hlaviˇcky programu spolu so zapuzdrujucou poloˇzkou zoznamu. Prvky ˇstrukt´
ury oznaˇcen´e * s´
u volitel’n´
ymi. Ich pr´ıtomnost’
v ˇstrukt´
ure z´avis´ı od konfigur´acie MOS. Prvky oznaˇcen´e ** sa navz´ajom vyluˇcuj´
u. Podl’a
konfigur´acie sa v hlaviˇcke nach´adza bud’ kontext u
´lohy alebo len vrchol z´asobn´ıka, v ktorom
je odloˇzen´
y kontext. Atrib´
ut poloˇzky (oznaˇcen´
y ***) nadob´
uda poˇcas inicializ´acie hlaviˇcky
hodnotu priority, ak je nakonfigurovan´a. Stav u
´lohy uv´adza aktu´alny stav, v ktorom sa u
´loha
nach´adza (pripraven´a, pozastaven´a, ukonˇcen´a...). Prvok D´atov´e toky odkazuje na sp´ajan´
y
zoznam, v ktorom sa ukladaj´
u ˇziadosti o komunik´aciu. Z´amka indikuje, ˇci je alebo nie je
obsaden´a kritick´a oblast’ pod´avania ˇziadost´ı.
ˇ
Obr. 5.6: Strukt´
ura TCB a zapuzdruj´
uca poloˇzka zoznamu
46
5. Implement´acia
Skryt´
e funkcie
Modul pouˇz´ıva pre pouˇz´ıvatel’a nepr´ıstupn´e funkcie MOSP init() a initContext(). Prv´a funkcia sl´
uˇzi na inicializovanie koreˇ
nov´eho procesu MOS. Druh´a funkcia inicializuje kontext kaˇzdej
novej u
´lohy.
Verejn´
e volania
Modul pon´
uka pre pouˇz´ıvatel’a volania: TMNG initStreams(), TMNG pushStream(), TMNGpopStream(), TMNG taskPid(), TMNG taskHeap() a TMNG taskPriority(). Tieto volania
nevyˇzaduj´
u prepnutie do chr´anen´eho reˇzimu, a preto sa vykon´avaj´
u v kontexte procesu, ktor´
y
ich volal.
y zoznam, v ktorom sa ukladaj´
u poloˇzky ˇzia• TMNG initStreams() inicializuje sp´ajan´
dost´ı o komunik´aciu. Tieˇz inicializuje z´amku, ktor´a riadi vstup do kritick´
ych oblast´ı.
• TMNG pushStream(pid, d´atov´
y tok) sl´
uˇzi na vloˇzenie ˇziadosti do sp´ajan´eho zoznamu.
Pid urˇcuje, ktorej u
´lohe sa ˇziadost’ pod´ava. D´atov´
y tok je ukazovatel’om na ˇziadost’.
Ak dan´a u
´loha neexistuje, sp´ajan´
y zoznam je pln´
y alebo sa nepodarilo vst´
upit’ do KO,
volanie vracia chybov´
u hodnotu.
ych danej u
´lohe jednu ˇzia• TMNG popStream() vyber´a zo zoznamu ˇziadost´ı adresovan´
dost’. V pr´ıpade, ˇze nebol inicializovan´
y sp´ajan´
y zoznam ˇziadost´ı, vracia chybov´
u hodnotu. Ak in´a u
´loha uˇz obsadila kritick´
u oblast’, vracia chybov´
u hodnotu. Ak je dan´
y
zoznam pr´azdny, vracia chybov´
u hodnotu.
´lohy.
• TMNG taskPid() vracia identifik´ator pr´ave beˇziacej u
• TMNG taskHeap() vracia odkaz na haldu pr´ave beˇziacej u
´lohy. Vyuˇz´ıva sa v alokovan´ı
pam¨ate pre premenn´
u procesu.
Skryt´
e volania
MOS vyuˇz´ıva volania, ktor´e vyˇzaduj´
u prepnutie procesora do chr´anen´eho reˇzimu ale nemaj´
u
ob´alku volania (nie s´
u pr´ıstupn´e pouˇz´ıvatel’ovi). Volanie TMNG init() inicializuje TCBT
(tabul’ku hlaviˇciek programov), PCBT (tabul’ku hlaviˇciek procesov) a nastav´ı beˇziacu u
´lohu.
Volanie switchContext(nov´a, star´a) je prvkom, ktor´
y zabezpeˇcuje odloˇzenie aktu´alne
beˇziacej u
´lohy do zoznamu pripraven´
ych u
´loh a naˇc´ıtanie novej u
´lohy zo zoznamu pripraven´
ych u
´loh. Na obr´azku 5.7 je zobrazen´
y priebeh vykonania volania. Na vstupe volania
s´
u umiestnen´e ukazovatele na miesto v pam¨ati, kde bude po ukonˇcen´ı volania umiesten´a
v´
ysledn´a adresa kontextov starej a novej u
´lohy. S t´
ymto v´
ysledkom pracuje funkcia odkladaj´
uca kontext. Ak aktu´alne beˇziaca u
´loha je v stave pozastaven´a, tak sa nepl´anuje a naˇc´ıta sa
len nov´a u
´loha z pripraven´
ych u
´loh.
47
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Obr. 5.7: Volanie switchTask()
Chr´
anen´
e volania
Modul poskytuje aj volania, ktor´e vyˇzaduj´
u prepnutie procesora do chr´anen´eho reˇzimu ale
s´
u pr´ıstupn´e pomocou ob´alky volania pouˇz´ıvatel’ovi. S´
u to volania spawn(), taskEnd() a
newProgram().
y program. Volanie je
Volanie newProgram() vykon´a vytvorenie hlaviˇcky pre uˇz zaveden´
implementovan´e tak, aby nebolo moˇzn´e vytvorit’ dve hlaviˇcky programu s rovnak´
ym identifik´atorom programu. Nie je implementovan´
y zav´adzaˇc, preto nevznikla potreba mat’ rovnak´e
identifik´atory. Po overen´ı, ˇze neexistuje dan´
y program sa alokuje priestor pre hlaviˇcku a poloˇzku zoznamu, ktor´a ju zap´
uzdri. Ak nastane probl´em s nedostatkom pam¨ate, volanie skonˇc´ı
ne´
uspechom. Po u
´speˇsnom vloˇzen´ı programu sa hlaviˇcka zap´
uzdri do poloˇzky zoznamu, t´a
sa vloˇz´ı do PCBT. Ak nie je dost’ miesta v PCBT, volanie konˇc´ı ne´
uspechom.
´lohy v MOS. Vstupom
Volanie spawn(pid) vykon´a vytvorenie a napl´anovanie novej u
volania je Pid programu, z ktor´eho m´a byt’ vytvoren´a inˇstancia. Volanie over´ı, ˇci program
dan´eho pid existuje, ak neexistuje volanie konˇc´ı s chybou. Nasleduje vytvorenie hlaviˇcky
procesu a vytvorenie poloˇziek pre TCBT a zoznam pripraven´
ych u
´loh. Ak nie je dostatok
pam¨ate pre vytv´aran´e, prvky volanie skonˇc´ı s chybou. Po vytvoren´ı poloˇziek sa inicializuje
hlaviˇcka procesu. Po inicializ´acii hlaviˇcky sa zap´
uzdri do poloˇzky a vloˇz´ı sa do zoznamu
pripraven´
ych u
´loh. Ak je zoznam pln´
y, tak volanie konˇc´ı s chybou. Hlaviˇcka sa tieˇz zap´
uzdri
do druhej poloˇzky a vloˇz´ı do TCBT. Ak tu nastane probl´em s plnost’ou TCBT volanie skonˇc´ı
48
5. Implement´acia
s chybou. Ak vˇsetko prebehne bez probl´emov, volanie vr´ati identifik´ator novej u
´lohy (obr.
5.8).
Obr. 5.8: Volanie spawn()
Volanie taskEnd() vykon´a bezpeˇcn´e ukonˇcenie u
´lohy. Poˇcas v´
ykonu volania sa uvol’n´ı
cel´a pam¨at’ alokovan´a pre proces a alokovan´a v halde jadra. Ak je MOS skompilovan´
y aj so
ˇstatistick´
ym modulom, tak sa hlaviˇcka v TCBT neuvol’ˇ
nuje aby sa ponechali inform´acie o
danej u
´lohe (obr. 5.9).
Obr. 5.9: Volanie taskEnd()
49
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
5.4.3
Riadenie komunik´
acie
Riadenie komunik´acie je implementovan´e ako spom´ınan´
y d´atov´
y tok. D´atov´
y tok je ˇstrukt´
ura, ktor´a obsahuje ukazovatel’ na rad, do ktor´eho sa bud´
u posielat’ d´ata, identifik´ator
procesu, ktor´
y vystupuje ako odosielatel’, stav d´atov´eho toku, poloˇzky na odloˇzenie blokovan´eho odosielatel’a a pr´ıjemcu a z´amok. Nad d´atov´
ym tokom s´
u implementovan´e oper´acie:
• senderConnect(PID) na z´aklade identifik´atora u
´lohy vytvor´ı ˇziadost’ o spojenie a vloˇz´ı
ju do zoznamu ˇcakaj´
ucich ˇziadost´ı. Funkcia vracia handle, ktor´
y je typu void*. V pr´ıpade ak je zoznam registr´aci´ı pln´
y, tak funkcia vracia NULL. Prid´avanie do zoznamu
registr´aci´ı je chr´anen´e z´amkou, aby sa zabr´anilo n´asobn´emu pr´ıstupu odosielatel’ov.
• receiverConnect() vyberie registr´aciu zo zoznamu a inicializuje spojenie s odosielatel’om. Ak je zoznam pr´azdny, funkcia vracia NULL. Odoberanie zo zoznamu je chr´anen´e
rovnakou z´amkou ako pri prid´avan´ı do zoznamu.
• send(d´ata, handle), sendAck(d´ata, handle), notify(d´ata, handle) sl´
uˇzia na odosielanie
d´at pr´ıjemcovi. Funkcie send() a sendAck() s´
u blokuj´
uce. Ak je rad spr´av pln´
y, tak
odosielatel’ je pozastaven´
y, k´
ym sa v rade neuvol’n´ı miesto. Funkcia sendAck() priklad´a
k spr´ave aj mechanizmus potvrdenia prijatia spr´avy. Funkcia nastav´ı atrib´
ut poloˇzky
na nenulov´
u hodnotu a pozastav´ı odosielatel’a, k´
ym dan´a spr´ava nie je potvrden´a
pr´ıjemcom. Funkcia notify() je neblokuj´
uci ekvivalent funkcie send() a vracia chybov´
u
hodnotu, ak je rad spr´av pln´
y.
• receive(d´ata, handle), read(d´ata, handle) sl´
uˇzia na prij´ımanie d´at poslan´
ych odosielatel’om. Funkcia receive() je blokuj´
uca, teda ak pr´ıjemca chce ˇc´ıtat’ z pr´azdneho radu,
je pozastaven´
y, k´
ym do radu nepr´ıde spr´ava. Funkcia read() je neblokuj´
ucim ekvivalentom funkcie receive(), ktor´
y vr´ati chybov´
u hodnotu, ak je rad pr´azdny. Obe funkcie
v pr´ıpade preˇc´ıtania spr´avy s potvrden´ım odblokuj´
u odosielatel’a, ˇc´ım je potvrden´e
prijatie spr´avy.
• senderPid(handle) vr´ati na z´aklade handle d´atov´eho toku identifik´ator odosielatel’a.
T´ato funkcia sa d´a pouˇzit’, ak chce pr´ıjemca sp¨atne odosielat’ d´ata odosielatel’ovi
vytvoren´ım opaˇcn´eho d´atov´eho toku.
• receiverDisconnect(handle) spˆosob´ı zmenu stavu toku d´at na stav odpojen´
y, ˇc´ım odosielatel’ uˇz nemˆoˇze posielat’ d’alˇsie d´ata. T´ato funkcia vr´ati “1“ ak s´
u v rade eˇste nejak´e
d´ata. Ak v rade nie s´
u ˇziadne d´ata, tak priestor alokovan´
y radom sa uvol’n´ı a funkcia
vr´ati “0“.
• streamDestroy(handle) uvol’n´ı pam¨at’ov´
y priestor d´atov´eho toku.
50
5. Implement´acia
Niektor´e detaily riadenia komunik´acie bud´
u eˇste prepracovan´e. Probl´emom mˆoˇze byt’ nadviazanie komunik´acie, v ktorej bude inici´ator komunik´acie pr´ıjemca.
5.5
Riadenie Pr´ıstupu
V riaden´ı pr´ıstupu sme implementovali ochranu vstupu a v´
ystupu do kritickej oblasti pomocou z´amok. V pr´ıpade, ˇze chce pouˇz´ıvatel’ chr´anit’ u
´sek k´odu a s nim spojen´
y pr´ıstup
u
k d´atam alebo prostriedkom, mˆoˇze pouˇzit’ volania beginCritical() a endCritical(), ktor´e s´
platformovo z´avisl´e a nach´adzaj´
u sa v s´
ubore port.c. Implementovali sme aj funkcionalitu
pozastavenia u
´lohy pomocou volan´ı suspendItem() a unSuspendItem(), ktor´e sa nach´adzaj´
u
v s´
ubore taskMNG.c.
Z´amka je realizovan´a ako ukazovatel’ na hodnotu. Ak je hodnota nenulov,´a z´amka je
otvoren´a, inak je z´amka uzamknut´a.
Volanie beginCritical(*z´amka) je zabalen´e volan´ım beginCritical(). Volanie sa teda nevykon´a, ak nie je procesor v privilegovanom reˇzime, ktor´
y je nepreruˇsitel’n´
y. Volanie testuje
obsah ukazovatel’a. Ak je obsah nulov´
y (zamknut´
y), tak volanie vracia hodnotu jeden inak
nastav´ı obsah na nulu a vracia nulu. Volanie endCritical() mˆoˇze byt’ vykonan´e hocikedy.
Nastav´ı z´amku na hodnotu uvol’nen´a.
Volanie suspendItem(**poloˇzka) zabezpeˇc´ı pozastavenie pl´anovania u
´lohy, k´
ym nie je
znovu rozhodnut´e, ˇze u
´loha mˆoˇze byt’ znovu pl´anovan´a. Poˇcas vykonania volania sa zap´
uzdruj´
uca poloˇzka zoznamu odloˇz´ı do priestoru, na ktor´
y ukazuje vstupn´a premenn´a. Nastav´ı
sa stav u
´lohy v hlaviˇcke na pozastaven´a. Po vykonan´ı t´
ychto oper´aci´ı volanie vkroˇc´ı do
cyklu, v ktorom ˇcak´a k´
ym nepr´ıde prepnutie u
´lohy. Podmienkou cyklu je stav u
´lohy rovn´
y
pozastaven´
y.
Volanie unSuspendItem(**poloˇzka) zabezpeˇc´ı zmenu stavu u
´lohy nasp¨at’ do stavu pripraven´a. Na vstupe volania je odkaz na poloˇzku, ktor´a bola odloˇzen´a volan´ım suspendItem().
Volanie dan´
u poloˇzku napl´anuje pomocou volania schedule() a skonˇc´ı.
Po prepnut´ı kontextu do u
´lohy, ktor´a bola predt´
ym pozastaven´a sa nastav´ı programov´e
poˇc´ıtadlo na adresu vo volan´ı suspendItem(). Tu naposledy u
´loha ˇcakala, k´
ym nenastane
prepnutie v cykle. Podmienka cyklu sa nespln´ı, pretoˇze sa zmenil stav u
´lohy z pozastaven´
a
na pripraven´a, a teda volanie suspendItem() skonˇc´ı a u
´loha mˆoˇze pokraˇcovat’ v ˇstandardnom
vykon´avan´ı.
5.5.1
Ob´
alka volania
Ob´alka volania zabezpeˇcuje pr´ıstup k volaniu, ktor´e vyˇzaduje aby procesor bol poˇcas jeho
v´
ykonu v chr´anenom reˇzime. Ak chce pouˇz´ıvatel’ vo svojom procese sp´
uˇst’at’ chr´anen´e volanie
tak mus´ı zavolat’ ob´alku volania, ktor´a m´a rovnak´
y n´azov ako chr´anenie volanie. Napr´ıklad ak
51
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
chceme vyvolat’ nov´
y proces, tak zavol´ame ob´alku spawn(pid), v ktorom je zabezpeˇcen´e prepnutie do chr´anen´eho reˇzimu, vykonanie volania spawn(pid) a prepnutie do pouˇz´ıvatel’sk´eho
reˇzimu. Ob´alky s´
u platformovo z´avisl´e rieˇsenie. Na platforme ARM7tdmi s´
u realizovan´e pomocou inˇstrukcie swi.
5.6
ˇ
Statistick´
y modul
ˇ
Statistick´
y modul je rozloˇzen´
y do s´
uborov taskMNG.c, memMNG.c, port.c a asmport.s. Jeho
u
´lohou je posielanie inform´aci´ı o stave jednotliv´
ych meran´
ych veliˇc´ın na hostitel’sk´
y poˇc´ıtaˇc.
ˇ
Implementovali sme posielanie d´at prostredn´ıctvom s´eriov´eho rozhrania. Statistick´
y modul je
implementovan´
y tak, aby mal minim´alny vplyv na r´eˇziu pri behu MOS v reˇzime jadra. Modul
pozost´ava zo skupiny funkci´ı, ktor´e sa volaj´
u priamo z procesov. Naˇsou myˇslienkou bolo
p´
uˇst’anie t´
ychto funkci´ı najm¨a z koreˇ
nov´eho procesu. Drviv´a v¨aˇcˇsina funkci´ı je vykon´avan´a
v pouˇz´ıvatel’skom m´ode procesora, ˇc´ım sa zabezpeˇcuje mal´e ovplyvˇ
novanie behu syst´emu.
V´
yhodou rieˇsenia je, ˇze ˇstatistick´
y modul posiela iba surov´e d´ata, ˇc´ım sa minimalizuje r´eˇzia na
strane MOS. V´
ypoˇctov´a a prezenˇcn´a f´aza sa realizuje v hostitel’skej aplik´aci´ı na hostitel’skom
poˇc´ıtaˇci.
5.6.1
S´
eriov´
a komunik´
acia
Komunikaˇcn´a ˇcast’ ˇstatistick´eho modulu je umiestnen´a v s´
ubore port.c pozost´ava z troch
funkci´ı:
• DBGU init() inicializuje s´eriov´e rozhranie na strane Vnoren´eho syst´emu (BaudRate
115200, bez parity, 1 stop bit, 8 d´atov´
ych bitov, bez kontroly). Nastaven´e bolo ladiace
s´eriov´e rozhranie procesora at91sam7s256.
• DBGU sendCmd(pr´ıkaz) odosiela ˇc´ıslo pr´ıkazu z´av¨azn´e pre hostitel’sk´
u aplik´aciu.
• DBGU send(*d´ata,vel’kost’) odosiela z´ıskan´e d´ata hostitel’skej aplik´acii. Najprv sa odoˇsle poˇcet bajtov, kol’ko m´a aplik´acia prijat’, a potom sa odoˇsl´
u po bajtoch d´ata.
5.6.2
Odosielan´
e d´
ata
Funkcie, ktor´e realizuj´
u pr´ıpravu a odosielanie d´at, s´
u:
ych inform´aci´ı z tabul’ky programov.
• TMNG statistics PCBT() realizuje odoslanie vˇsetk´
• TMNG statistics TCBT() realizuje odoslanie vˇsetk´
ych inform´aci´ı z tabul’ky u
´loh. Ak
je nastaven´
y reˇzim MOS s meran´ım ˇstatistiky, tak sa hlaviˇcky ukonˇcen´
ych u
´loh neodstraˇ
nuj´
u z tabul’ky u
´loh. S´
uˇcast’ou funkcie je aj odoslanie vyuˇzitia haldy prostredn´ıctvom funkcie MMNG statistics taskHeap().
52
5. Implement´acia
• MMNG statistics kernelHeap(prikaz) realizuje odoslanie stavu vyuˇzitia haldy jadra
alebo pam¨ate programov. Ak je pr´ıkaz odoslanie haldy, tak s´
u odosielan´e d´ata: poˇcet
obsaden´
ych u
´sekov haldy a ich sum´arna vel’kost’, poˇcet neobsaden´
ych u
´sekov haldy a
ich sum´arna vel’kost’. Ak je pr´ıkaz odoslanie pam¨ate programu, tak s´
u odoslan´e d´ata:
poˇcet obsaden´
ych u
´sekov pam¨ate programu a ich sum´arna vel’kost’, poˇcet neobsaden´
ych
u
´sekov pam¨ate programu a ich sum´arna vel’kost’.
u funkciu ako predch´adzaj´
uca funk• MMNG statistics taskHeap(adresa) realizuje rovnak´
cia s t´
ym rozdielom, ˇze realizuje v´
ypoˇcet na z´aklade vstupnej adresy.
• MMNG statistics kernelStack() realizuje odoslanie vrcholu, konca a zaˇciatku z´asobn´ıka jadra. T´ato funkcia je jedinou, ktor´a mus´ı byt’ vykonan´a v chr´anenom reˇzime
jadra. Funkcia m´a svoju ob´alku volania.
ˇ
Statistick´
y modul zasahuje do prepnutia kontextu t´
ym, ˇze uklad´a do hlaviˇcky u
´lohy aj poˇcet
prepnut´ı, poˇcas ktor´
ych dan´a u
´loha uˇz beˇz´ı. T´
ym sa zan´aˇsa mal´a r´eˇzia do prepnutia kontextu.
Je to potrebn´e z dˆovodu potreby merania ˇcasu str´avenom na procesore.
5.7
Platformovo z´
avisl´
eˇ
casti MOS
MOS sme implementovali na platforme ARM7tdmi konkr´etne na procesore at91sam7s256.
Tento procesor podporuje niekol’ko reˇzimov jadra, z ktor´
ych sme vyuˇzili User m´od, Fast Inˇ
terrupt m´od, Interrupt m´od a Supervisor m´od. Dalˇsie inform´acie o jednotliv´
ych vlastnostiach
procesora moˇzno n´ajst’ v katal´ogov´
ych listoch a manu´aloch od v´
yrobcu procesora [9, 10, 11].
5.7.1
Prepnutie do chr´
anen´
eho reˇ
zimu
Prepnutie do chr´anen´eho reˇzimu a s n´ım spojen´e ob´alky volan´ı sme realizovali pomocou
inˇstrukcie swi (obr. 5.10). T´ato inˇstrukcia, ktorej parameter je ˇc´ıslo volania, vyvol´a prepnutie
Obr. 5.10: Ob´alka volania spawn
do chr´anen´eho reˇzimu. V chr´anenom reˇzime sa vykon´ava vyhl’adanie volania podl’a jeho ˇc´ısla
vo funkci´ı SWI Handler Entry (obr. 5.11). Ak sa nen´ajde volanie, chr´anen´
y reˇzim sa ukonˇc´ı
53
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
bez vykonania akejkol’vek zmeny. Ak sa volanie n´ajde, tak sa vykon´a a po jeho skonˇcen´ı sa
znova procesor vr´ati do pouˇz´ıvatel’sk´eho reˇzimu. Poˇc´ıtadlo adresy inˇstrukcie je nastaven´e na
adresu d’alˇsej inˇstrukcie po inˇstrukcii swi. K´od SWI Handler Entry sme prebrali a upravili
podl’a manu´alu [11].
Obr. 5.11: N´ajdenie konkr´etneho volania
5.7.2
Prepnutie kontextu
MOS sme implementovali preempt´ıvne, a preto na prepnutie u
´lohy potrebujeme pouˇz´ıvat’
nejak´
y spˆosob ˇcasovania. Na ˇcasovanie prepnutia pouˇz´ıvame ˇspeci´alny ˇcasovaˇc Periodic interval timer (PIT). Tento ˇcasovaˇc je zloˇzen´
y z 20b ˇcasovaˇca, ktor´
y m´a nastavitel’n´
uu
´roveˇ
n
preteˇcenia a z 12b poˇc´ıtadla preteˇcen´ı. Ak ˇcasovaˇc preteˇcie, tak vyvol´a preruˇsenie, ktor´e
sme nastavili tak, aby preplo procesor do Fast interrupt m´odu. Prepnutie spˆosob´ı spustenie
funkcie FIQ Handler Entry (5.12), ktor´a sa nach´adza v s´
ubore Cstartup.S od firmy Atmel.
FIQ Handler Entry na z´aklade adresy, ktor´a je uloˇzen´a v registri R0 procesor skoˇc´ı na v´
ykon
poˇzadovanej funkcie. Po vyvolan´ı preruˇsenia PIT sa zavol´a funkcia taskSwitch, ktor´a nie je
pr´ıstupn´a pouˇz´ıvatel’ovi. T´ato funkcia, nap´ısan´a v jazyku symbolick´
ych inˇstrukci´ı, overuje,
ˇci prepnutie bolo volan´e z reˇzimu User, ak nie, prepnutie sa nevykon´a. Po overen´ı sa vol´a
funkcia switchContext(), ktor´a vr´ati dve adresy, na ktor´
ych sa nach´adza kontextov´
y z´asobn´ık. Prv´a adresa je z´asobn´ık, do ktor´eho sa odloˇz´ı kontext starej u
´lohy a druh´a je kontextov´
y
z´asobn´ık, z ktorej sa naˇc´ıta kontext novej u
´lohy. Po vykonan´ı odloˇzenia a naˇc´ıtania kontextu
54
5. Implement´acia
Obr. 5.12: Fast interrupt entry
je inicializovan´
y PIT, a ak je zapnut´
y ˇstatistick´
y modul, tak sa odloˇz´ı do kontextu starej
u
´lohy hodnota poˇc´ıtadla preteˇcen´ı z PIT (obr. 5.13).
Obr. 5.13: Odloˇzenie kontextu, prepnutie u
´lohy, naˇc´ıtanie kontextu
55
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
5.8
Podporn´
a aplik´
acia na hostitel’skom poˇ
c´ıtaˇ
ci
Implementovali sme konzolov´
u aplik´aciu, ktor´a sleduje s´eriov´e rozhranie hostitel’sk´eho poˇc´ıtaˇca. Aplik´acia bola implementovan´a v jazyku C a bola otestovan´a len na operaˇcnom syst´eme
Windows 7.
Aplik´acia po spusten´ı inicializuje s´eriov´
y port. Po inicializ´aci´ı vykon´ava nekoneˇcn´
u
sluˇcku, v ktorej sa ˇcak´a na pr´ıkaz od sledovan´eho vnoren´eho zariadenia s MOS. Po identifikovan´ı pr´ıkazu sp´
uˇst’a spracovanie a v´
ypis inform´aci´ı prijat´
ych cez s´eriov´
y port.
56
6. Testovanie
6 Testovanie
V tejto kapitole uv´adzame postup a v´
ysledky testovania nami implementovan´eho modul´arneho operaˇcn´eho syst´emu.
6.1
Testovacia zostava
ˇ
MOS bol testovan´
y na v´
yvojovej doske sam7s256 od firmy Olimex [8]. Statistick´
e meranie
bolo realizovan´e na notebooku s operaˇcn´
ym syst´emom Windows 7 a intern´
ym s´eriov´
ym
rozhran´ım. V´
yvojov´a doska bola programovan´a a laden´a pomocou program´atora ARM-USBOCD od firmy Olimex [12].
Z hl’adiska programov´eho vybavenia bol na hostitel’skom poˇc´ıtaˇci nainˇstalovan´
y:
• kompil´ator arm-none-eabi-gcc verzia 4.6.2 inˇstalovan´
y v bal´ıku yagaro a yagaro tools
[13]
• openOCD server [14]
• ovl´adaˇce pre ARM-USB-OCD program´ator [12, 15]
• nami implementovan´a aplik´acia na ˇc´ıtanie s´eriovej komunik´acie
6.2
Testovan´
a programov´
aˇ
strukt´
ura
Pre overenie funkˇcnosti MOS sme navrhli jednoduch´
u programov´
u ˇstrukt´
uru zobrazen´
u na
obr´azku 6.1.
Obr. 6.1: Programov´
y graf testovan´eho syst´emu
57
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Na obr´azkoch 6.2-6.5 s´
u diagramy priebehu jednotliv´
ych programov spusten´
ych na MOS.
Koreˇ
nov´
y proces vytvor´ı hlaviˇcky programov a sp´
uˇst’a procesy p0 a p1. Po spusten´ı procesov
pln´ı funkciu ˇstatistick´eho procesu.
Obr. 6.2: Priebeh koreˇ
nov´eho procesu
Po spusten´ı koreˇ
nov´eho procesu sa najprv spust´ı proces P0 6.3. Proces P0 inicializuje
port v´
yvojovej dosky s pripojen´
ymi di´odami, sp´
uˇst’a proces p2 a v nekoneˇcnej sluˇcke odosiela
d´ata s potvrden´ım procesu P2.
Obr. 6.3: Priebeh procesu p0
58
6. Testovanie
Ako posledn´
y sa vytvor´ı proces P1, ktor´
y beˇz´ı samostatne. Proces P1 zap´ına a vyp´ına
v nekoneˇcnej sluˇcke di´odu na v´
yvojovej doske 6.4.
Obr. 6.4: Priebeh procesu p1
Proces P2 inicializuje zoznam ˇcakatel’ov na komunik´aciu a inicializuje spojenie, o ktor´e
ˇziadal proces P0. N´asledne prij´ıma spr´avy od procesu P2. Ak dostane hodnotu “1“ tak zapne
di´odu a ak “0“ tak di´odu vypne.
Obr. 6.5: Priebeh procesu p2
59
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
6.3
Testovan´
e konfigur´
acie MOS
MOS sme testovali v reˇzime s povolenou medziprocesnou komunik´aciou a s moˇznost’ou pozastavenia vykonania u
´loh. V tejto ˇcasti uvedieme testy vykonan´e v reˇzime pl´anovania RoundRobin s odloˇzen´ım kontextu do hlaviˇcky u
´lohy alebo do z´asobn´ıka u
´lohy a v reˇzime pl´anovania
s prioritou s odloˇzen´ım kontextu do z´asobn´ıka.
6.3.1
Pl´
anovanie Round-Robin
Pri testovan´ı s pl´anovan´ım boli v pam¨ati programu nasledovn´e programy (zobrazen´a hlaviˇcka
programu) (6.6). V hlaviˇcke programu je uveden´a poˇciatoˇcn´a adresa programu, vel’kost’ pam¨ate d´at, poˇcet spusten´
ych u
´loh a poˇciatoˇcn´a priorita. V ˇcase v´
ypisu stavu hlaviˇciek boli
vˇsetky u
´lohy uˇz spusten´e.
Obr. 6.6: V´
ystup testovania - hlaviˇcky programov
60
6. Testovanie
Odloˇ
zenie kontextu do z´
asobn´ıka
MOS sme nechali beˇzat’ pribliˇzne 3 min´
uty. V´
ystupom z behu je sumariz´acia z obr´azku
6.7. V sum´ari je uveden´a aj priorita a prepoˇziˇcan´a priorita, ktor´a pre tento pr´ıpad nie je
smerodajn´a. Kaˇzdej u
´lohe je moˇzn´e identifikovat’ otca okrem u
´lohy 1, ktor´a je koreˇ
nov´a.
Kaˇzd´a u
´loha m´a uveden´
u spotrebu pam¨ate haldy a stav z´asobn´ıka. Okrem sum´aru u
´loh je
´
tu uveden´a aj spotreba pam¨ate jadra. Uloha
3 (P2) ukazuje, ˇze bola na procesore podstatne
menej ako ostatn´e u
´lohy. Je to zapr´ıˇcinen´e jej ˇcakan´ım na spr´avu od u
´lohy 2 (P0).
Obr. 6.7: V´
ystup testovania - hlaviˇcky procesov a vyuˇzitie pam¨ate (odloˇzenie do z´asobn´ıka)
61
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Odloˇ
zenie kontextu do hlaviˇ
cky
MOS sme nechali beˇzat’ pribliˇzne 3 min´
uty. V´
ystupom z behu je sumariz´acia z obr´azku 6.8.
Ako vidno vo vyuˇzit´ı z´asobn´ıka, je tu menˇsia spotreba vo vˇsetk´
ych u
´loh´ach oproti odloˇzeniu
´
kontextu do z´asobn´ıka. Uloha
3 (P2) m´a tak m´alo procesn´eho ˇcasu pretoˇze v¨aˇcˇsinu ˇcasu bola
ˇ
pozastaven´a. Cakala na spr´avu od u
´lohy 2 (P0).
Obr. 6.8: V´
ystup testovania - hlaviˇcky procesov a vyuˇzitie pam¨ate (odloˇzenie do hlaviˇcky)
62
6. Testovanie
6.3.2
Pl´
anovanie s prioritou
Na obr´azku 6.9 je uveden´
y stav programov uloˇzen´
ych v pam¨ati programov a poˇcet spusten´
ych
u
´loh v danom procesore pre dan´
y program.
Obr. 6.9: V´
ystup testovania - hlaviˇcky programov
Na obr´azku 6.10 je sum´ar stavu u
´loh po uplynut´ı pribliˇzne troch min´
ut. Ako vidno najv¨aˇcˇsiu prevahu m´a u
´loha 1, pretoˇze m´a najvyˇsˇsiu prioritu. Priorita je dan´a s´
uˇctom priority
a prepoˇziˇcanej priority. Ostatn´e u
´lohy maj´
u rovnak´
u prioritu po s´
uˇcte s prepoˇziˇcanou priori´
tou. Uloha
3 ako aj v minul´
ych meraniach vykazuje n´ızke percento pl´anovania pretoˇze ˇcak´a
na spr´avu od u
´lohy 2.
63
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Obr. 6.10: V´
ystup testovania - hlaviˇcky procesov a vyuˇzitie pam¨ate (odloˇzenie do z´asobn´ıku)
64
6. Testovanie
6.4
Prepnutie u
´ lohy
Prepnutie kontextu od vyvolania trvalo v reˇzime Round-robin 14,3 mikro sekundy pri takˇ je 14,3 percentn´a r´eˇzia pri taktovan´ı prepnutia 10 KHz. Pri
tovan´ı procesora 48 MHz. Co
ostatn´
ych pl´anovaniach je prepnutie v ide´alnom pr´ıpade rovnako dlh´e ale ak nast´ava usporiadanie u
´loh, tak prepnutie sa predlˇzuje. Samotn´e odloˇzenie a naˇc´ıtanie kontextu trv´a 3,3
mikrosekundy pri rovnakom taktovan´ı 48 MHz. V´
ypoˇcet trvania prepnutia bol vykonan´
y
poˇcas reˇzimu ladenia odˇc´ıtan´ım hodnoty z PIT.
6.5
Vyuˇ
zitie pam¨
ate d´
at
Pl´anovaˇc samostatne zaber´a 17 B (freeRTOS 236 B [16]) + 16 B za kaˇzd´
u pl´anovan´
uu
´lohu.
´
Uloha
v minim´alnej konfigur´aci´ı zaber´a 30 B + 16 B (freeRTOS 64 B [16]). V maxim´alnej
konfigur´aci´ı minie 116 B + 16 B.
Rad minie 25 B (freeRTOS 76 B [16]) d´at + 12 B za kaˇzd´
u nov´
u poloˇzku.
6.6
Vyuˇ
zitie pam¨
ate programu
Minim´alna konfigur´acia zaberie pribliˇzne 5,5 kB pam¨ate programu. V maxim´alnej konfigur´acii zaberie pribliˇzne 9,5 kB pam¨ate programu.
65
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
66
7. Zhodnotenie
7 Zhodnotenie
Projekt sp´lnil vˇsetky stanoven´e ciele. V´
ystupom projektu je funguj´
uce jadro modul´arneho
operaˇcn´eho syst´emu. Jadro operaˇcn´eho syst´emu je v´
yluˇcne preempt´ıvne a pozost´ava zo
spr´avy pam¨ate, spr´avy procesov, pl´anovaˇca, medziprocesnej komunik´acie a riadenia pr´ıstupu. MOS je rozˇs´ıren´
y o ˇstatistick´
y modul, ktor´
ym je moˇzn´e odosielat’ d´ata pre extern´
u
aplik´aciu. Implementovali sme extern´
u aplik´aciu, ktor´a spracuje prich´adzaj´
uce d´ata zo s´eriov´eho rozhrania.
Poˇcas pr´ace na projekte sme sa stretli s mnoh´
ymi probl´emami, ktor´e sme vyrieˇsili.
Pr´ıkladom bol problem s viditel’nost’ou funkci´ı, ktor´e sme implementovali. Niektor´e verejn´e
funkcie sme chceli pouˇzit’ len v r´amci modulov MOS. Probl´em sme nakoniec oˇsetrili overen´ım, ˇci bol procesor prepnut´
y do chr´anen´eho reˇzimu. Probl´em nastal aj pri realiz´acii
prepnutia kontextu. Prepnutie je riaden´e preruˇsen´ım, ktor´e je mapovan´e do FIQ m´odu.
Probl´emom bolo obˇcasn´e preruˇsenie aj v chr´anenom reˇzime procesora, ked’ˇze nebolo zak´azan´e FIQ preruˇsenie. Toto sme oˇsetrili t´
ym, ˇze hned’ po prepnut´ı do chr´anen´eho reˇzimu
sme zak´azali preruˇsenie FIQ. Dodatoˇcne sme implementovali overovanie, ˇci FIQ preruˇsenie
nastalo v´
yluˇcne v pouˇz´ıvatel’skom m´ode procesora. Nie menej dˆoleˇzit´
ym probl´emom bola
potreba prepnutia procesora do chr´anen´eho reˇzimu s moˇznost’ou pokraˇcovania v k´ode ale
v novom reˇzime bez moˇznosti zneuˇzitia pouˇz´ıvatel’om. Toto sme vyrieˇsili overen´ım adresy
odkial’ bola poˇziadavka zadan´a. Ak poˇziadavka je zadan´a z adresy patriacej k´odu MOS,
tak dan´e prepnutie bude vykonan´e. Z´asadn´
ym probl´emom pri n´avrhu bola identifik´acia najvhodnejˇsieho zaˇciatku implement´acie. Po identifikovan´ı najvhodnejˇsieho zaˇciatku, ktor´
ym sa
stal modul Spr´ava pam¨ate, nabrala implement´acia r´
ychly sp´ad. Poˇcas implement´acie sme sa
riadili modul´arnym a pr´ırastkov´
ym v´
yvojom. Z´ıskali sme zruˇcnost’ s jazykom symbolick´
ych
inˇstrukci´ı pre platformu ARM, ˇco povaˇzujeme za cenn´
u sk´
usenost’.
Poˇcas p´ısania tohto dokumentu sme si uvedomili zop´ar nejasnost´ı a nezmyselnost´ı v implement´aci´ı MOS. MOS nem´a implementovan´
y mechanizmus ˇcasovan´eho odloˇzenia v´
ykonu
u
´lohy Blokovac´ı mechanizmus. Tento nedostatok sa odr´aˇza pri pl´anovan´ı s prioritou, ked’
u
´loha, ktor´a by mohla ˇcakat’ na pridelenie prostriedku zaber´a priestor pl´anovania a nedovol’uje vykonanie ostatn´
ych u
´loh, ktor´e maj´
u niˇzˇsiu prioritu.
Napriek t´
ymto maliˇckostiam mˆoˇzeme zhodnotit’, ˇze MOS je z pam¨at’ovej (programovej
aj d´atovej) str´anky efekt´ıvnejˇs´ı ako freeRTOS, ˇco je pre n´as vel’k´
ym u
´spechom. Rozdelenie
k´odu podl’a platformovej z´avislosti zefekt´ıvˇ
nuje a ur´
ychl’uje pren´aˇsanie na in´e platformy. Na
prenesenie na in´
u platformu staˇc´ı implementovat’ platformovo z´avisl´
y k´od.
Do bud´
ucnosti by sme chceli pracovat’ na zdokonal’ovan´ı MOS. Uvedomili sme si, ˇze
implement´acia ˇstrukt´
ur sp´ajan´eho zoznamu a z´aroveˇ
n radu znaˇcne zvyˇsuje n´aroky na vel’kost’
67
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
k´odu. Navyˇse pri pl´anovan´ı u
´loh by postaˇcovala na uloˇzenie u
´lohy aj ˇstrukt´
ura rad. Z´aroveˇ
n
sme si poˇcas testovania vˇsimli mal´
u ˇcast’ k´odu, ktor´a je platformovo z´avisl´a ale je v s´
ubore,
´
ktor´
y nie je platformovo z´avisl´
y, ˇco mˆoˇze predlˇzit’ ˇcas prenesenia MOS na in´e platformy.
V koneˇcnom zhodnoten´ı hodnot´ıme projekt ako vel’mi u
´speˇsn´
y. Pre n´as pr´aca na projekte znamen´a obrovsk´
u sk´
usenost’ a mnoˇzstvo nov´
ych vedomost´ı v oblasti vnoren´
ych operaˇcn´
ych syst´emov, pr´aci s rodinou procesorov ARMv4, zruˇcnost´ı s jazykom symbolick´
ych
inˇstrukci´ı a jazykom C.
68
´
LITERATURA
Literat´
ura
[1] A. S. Tanenbaum, Modern Operating Systems (2nd Edition) (GOAL Series). Prentice
Hall, 2001.
[2] A. S. Tanenbaum and A. S. Woodhull, Operating Systems Design and Implementation
(3rd Edition). Prentice Hall, 2006.
ˇ
[3] J. Stefanoviˇ
c, Z´aklady operaˇcn´ych syst´emov. STU, 2007.
[4] J. J. Labrosse, J. Ganssle, and e. a. Robert Oshana, Embedded Software: Know It All
(Newnes Know It All). Newnes, 2007.
[5] L. Barello, AvrX Real Time Kernel, 2007. http://www.barello.net/avrx/.
[6] The FreeRTOS Project, 2011. http://www.freertos.org/.
[7] TinyOS, 2011. http://www.tinyos.net.
[8] Datasheet, SAM7-S256 development board, Users Manual, 2008.
[9] Datasheet, AT91SAM7S256, 2010.
[10] Technical Reference Manual, ARM7TDMI (Rev 3), 2001.
[11] User Guide, ARM Software Development Toolkit V. 2.50, 1998.
[12] Datasheet, ARM USB JTAG DEBUGGER, 2006.
[13] M.
Fischer,
YAGARTO,
http://www.yagarto.de/.
Yet
another
GNU
ARM
toolchain,
2012.
Times,
2012.
[14] User Guide, Open On-Chip Debugger: OpenOCD, 2012.
[15] Installing ARM-USB-OCD - rev.G drivers for Windows 7, 2010.
[16] FreeRTOS
FAQ
Memory
Usage
http://www.freertos.org/FAQMem.html.
and
Boot
69
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
70
A. Digit´alne m´edium
A Digit´
alne m´
edium
• /dokument - obsahuje digit´alnu formu tohto dokumentu vo form´ate PDF.
• /MOS - obsahuje implementovan´e ˇcasti modul´arneho operaˇcn´eho syst´emu.
• /podporn´
a dokument´
acia - obsahuje katal´ogov´e listy a manu´aly pouˇzit´
ych hardv´erov´
ych komponentov.
• /podporn´
y softv´
er - obsahuje softv´er a ovl´adaˇce, ktor´e boli pouˇzit´e pri implementovan´ı a testovan´ı MOS.
71
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
72
B. V´
yvoj´arska pr´ıruˇcka
B V´
yvoj´
arska pr´ıruˇ
cka
Inˇ
stal´
acia v´
yvojov´
eho prostredia
Na priloˇzenom digit´alnom nosiˇci je uloˇzen´
y softv´er potrebn´
y na rozbehnutie syst´emu. Dostupn´
u inˇstal´aciu sme pouˇz´ıvali na operaˇcnom syst´eme Windows 7. Na ostatn´
ych OS nevieme
zaruˇcit’ funkˇcnost’.
1. Rozbal’te .zip s´
ubor OpenOCD OnlinePackage MV.zip uloˇzen´
y v prieˇcinku /podporn´y
softv´er na digit´alnom m´ediu. Odpor´
uˇcame, aby bal´ıˇcek bol rozbalen´
y do kr´atkej cesty
a aby cesta neobsahovala medzery.
2. V prieˇcinku /ARM-USB-OCD-DRIVER, ktor´
y je v rozbalenom bal´ıˇcku s´
u uloˇzen´e
ovl´adaˇce. Postupujte podl’a n´avodu How to install OpenOCD on Windows 7.pdf uloˇzen´eho
v tomto prieˇcinku.
3. Pridajte do premennej prostredia Path prieˇcinok /openOCD, ktor´
y sa nach´adza v
bal´ıˇcku
4. Nainˇstalujete YAGARTO umiestnen´
y v /podporn´y softv´er. Postupujte podl’a pokynov
inˇstal´atora. Nezabudnite zaˇskrtn´
ut’ uloˇzenie do premenn´
ych prostredia. Najlepˇsie je
nainˇstalovat’ do prieˇcinku kde ste rozbalili OpenOCD OnlinePackage MV.
5. Nainˇstalujte YAGARTO-tools umiestnen´
y v /podporn´y softv´er. Postupujte podl’a pokynov inˇstal´atora. Najlepˇsie je nainˇstalovat’ do prieˇcinku kde ste rozbalili OpenOCD OnlinePackage MV.
ˇ s´ı manu´al k openOCD n´ajdete v prieˇcinku /podporn´a dokument´acia pod n´azvom
Dalˇ
openOCD.pdf
Inˇ
stal´
acia portf´
olia MOS
Portf´olio MOS je uloˇzen´e v prieˇcinku /MOS. Skop´ırujte tento prieˇcinok kam potrebujete.
Pre spustenie ladenia MOS otvorte pr´ıkazov´
y riadok nastaven´
y do prieˇcinku mos/microcon/at91sam7s. Zadajte pr´ıkaz make debug. Spust´ıte t´
ym kompil´aciu MOS a program gdb
(ladenie). Zadan´ım pr´ıkazu make all kompilujete zdrojov´e s´
ubory v danej konfigur´aci´ı. Pr´ıkaz
vylistuje zdrojov´
y k´od a sumariz´aciu. Zadan´ım pr´ıkazu make program spust´ıte naprogramovanie skompilovan´eho MOS do v´
yvojovej dosky sam7-p256. Pr´ıkazom make clean vyˇcist´ıte
kompil´aciu z poˇc´ıtaˇca.
73
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
Prenesenie na in´
e platformy
Ak chcete preniest’ MOS na in´
u platformu je potrebn´e:
• vytvorit’ kompilaˇcn´
y s´
ubor, v ktorom sa kompiluj´
u jednotliv´e s´
ubory MOS.
• implementovat’ inicializaˇcn´
y .S s´
ubor ak je potrebn´e inicializovat’ z´asobn´ıky.
• implementovat’ s´
ubor main.c V tomto s´
ubore sa inicializuje podpora jazyku C. V
tomto s´
ubore sa inicializuje MOS. Tu sa volaj´
u funkcie MMNG init(), TMNG init(),
InitTimedTaskSwitch(), MOSP start(). Poradie mus´ı byt’ zachovan´e.
• implementovat’ funkciu InitTimedTaskSwitch(), v ktorej sa inicializuje ˇcasovaˇc prepnutia.
• implementovat’ funkciu MOSP start(), ktor´a sp´
uˇst’a MOS.
• implementovat’ ob´alky volan´ı a zabezpeˇcit’ chr´anen´
y reˇzim pred pouˇz´ıvatel’om.
• implementovat’ odloˇzenie kontextu, v ktorom sa mus´ı zavolat’ funkcia switchContext().
74
C. Pouˇz´ıvatel’sk´a pr´ıruˇcka
C Pouˇ
z´ıvatel’sk´
a pr´ıruˇ
cka
Konfigur´
acia MOS
MOS sa konfiguruje cez konfiguraˇcn´
y s´
ubor config.h V tomto s´
ubore pouˇz´ıvatel’ nastav´ı
poˇzadovan´e parametre MOS.
Vlastn´
e programy
Program tvor´ı svoj program ako funkciu bez vstupn´eho a v´
ystupn´eho parametra. T´ato funkcia mˆoˇze ale nemus´ı mat’ v sebe nekoneˇcn´
u sluˇcku. Okrem funkcie pouˇz´ıvatel’ vytvor´ı v
s´
ubore MOS.h alebo priloˇz´ı vo vlastnom s´
ubore makro s definovan´ım PID programu. Pouˇz´ıvatel’ priloˇz´ı deklar´aciu funkcie. Kaˇzd´
y program m´a mat’ svoj vlastn´
y jedineˇcn´
y identifik´ator. Programu, sa poˇcas spustenia MOS, mus´ı vytvorit’ hlaviˇcka programu pomocou volania
newProgram(PID,meno funkcie,priorita,vel’kost’ d´at). Toto volanie je najlepˇsie umiestnit’ do
koreˇ
nov´eho procesu.
Koreˇ
nov´
y proces
uˇcame najprv vytvorit’ hlaV s´
ubore MOS.c je funkcia MOS ROOT. V tele funkcie odpor´
viˇcky vˇsetk´
ych programov v MOS. N´asledne pouˇz´ıvatel’ sp´
uˇst’a prv´
y pouˇz´ıvatel’sk´
y proces
pomocou volania spawn(pid). Pre potreby merania MOS odpor´
uˇcame tu uviest’ v sluˇcke
odosielanie ˇstatistick´
ych meran´ı.
Volania MOS
´lohy
• T Pid TMNG taskPid() - vracia pid aktu´alnej u
• void * TMNG taskHeap() - vracia haldu aktu´alnej u
´lohy
• T ListAttribute TMNG TaskPriority() - vracia prioritu aktu´alnej u
´lohy
• T UInt TMNG InitStreams() - inicializuje d´atov´
u komunik´aciu aktu´alnej u
´lohy
• void * TMNG popStream() - v´
yber ˇziadosti adresovanej aktu´alnej u
´lohe
• void taskEnd() - ukonˇcenie u
´lohy
´lohy zaloˇzenej na programe
• T Pid spawn(T ListAttribute pid) - vytvorenie novej u
dan´eho pid
75
Modul´arny operaˇcn´
y syst´em pre vnoren´
y syst´em
• T PCB newProgram(T ListAttribute pid, void * begin, T ListAttribute priority, T Long
len) - vytvorenie hlaviˇcky pre novy program
• void DBGU init() - inicializovanie s´eriov´eho prepojenia pre potreby ˇstatistick´eho merania
• void TMNG statistics PCBT() - odoslanie ˇstatistiky programov cez s´eriov´e rozhranie
• void TMNG statistics TCBT() - odoslanie ˇstatistiky u
´loh cez s´eriov´e rozhranie
• void* malloc(T UInt size) - alokovanie priestoru na halde
• void free(void * pointer) - uvolnenie alokovan´eho piestoru na halde
• void MMNG statistics kernelHeap(T Char cmd) - odoslanie ˇstatistiky haldy jadra/procesnej pam¨ate
• void MMNG statistics kernelStack() - odoslanie ˇstatistiky vyuˇzitia z´asobn´ıka
• T IPCHandle senderConnect(T Pid pidReceiver) - pripojenie k danej u
´lohe ˇziadost’ou
• T IPCHandle receiverConnect() - pripojenie k ˇziadatel’ovi
• T UInt send(void *message, T IPCHandle handle) - blokuj´
uce odoslanie spr´avy
• T UInt sendAck(void *message, T IPCHandle handle) - blokuj´
uce odoslanie spr´avy s
potvrden´ım
• T UInt notify(void *message, T IPCHandle handle) - neblokuj´
uce odoslanie spr´avy
• T Pid senderPid(T IPCHandle handle) - zistenie pid u
´lohy, ktor´a odosiela
• T UInt receive(void **message, T IPCHandle handle) - blokuj´
uce prijatie spr´avy
• T UInt read(void **message, T IPCHandle handle) - neblokuj´
uce prijatie spr´avy
• T UInt receiverDisconnect(T IPCHandle handle) - odpojenie od odosielatel’a
• T UInt senderDisconnect(T IPCHandle handle) - odpojenie od prij´ımatel’a
• T UInt streamDestroy(T IPCHandle handle) - zruˇsenie komunikaˇcn´eho toku
• T UInt streamState(T IPCHandle handle) - navr´atenie stavu komunikaˇcn´eho toku
76
Download

Slovenská technická univerzita v Bratislave Fakulta