Z´apadoˇcesk´a univerzita v Plzni Fakulta aplikovan´ych vˇed Katedra informatiky a v´ypoˇcetn´ı techniky
Diplomov´ a pr´ ace Implementace vybran´ ych metod pro pl´ anov´ an´ı u ´ loh v RTOS µC/OS-II
Plzeˇ n, 2012
Frantiˇsek Svoboda
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 16. kvˇetna 2012 Frantiˇsek Svoboda
Abstract Implementation of selected methods for task scheduling in RTOS µC/OS-II This work describes how to change task scheduling in µC/OS-II operating system. This work also shows what is need in Real-time operation system. Scheduling methods are created for the pure code RTOS. The port’s examples for ( x86 / Renesas microcontroller H8S2633F ) are written in C and processor-specific assembly language. The CD-ROM contains source code for the H8S2633F port and implements scheduling algorithm.
Obsah ´ 1 Uvod
1
2 Real-time syst´ emy 2.1 Historie a souˇcasn´ y stav 2.2 Obecn´e pojmy . . . . . . 2.2.1 Doba odezvy . . 2.2.2 Determinismus . 2.3 Klasifikace RTOS . . . . 2.3.1 Hard . . . . . . . 2.3.2 Soft . . . . . . . 2.3.3 Firm . . . . . . . 3 Pˇ rehled RTOS 3.1 Windows Embeded . 3.2 QNX Neutrino . . . 3.3 Wind River VxWorks 3.4 Nucleus . . . . . . . 3.5 LynxOS RTOS . . . 3.6 Linux . . . . . . . .
. . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
4 µC/OS-II ´ 4.1 Ulohy . . . . . . . . . . . . 4.1.1 Stavy u ´loh . . . . . . 4.1.2 Task Control Block . 4.1.3 V´ ybˇer u ´lohy . . . . . 4.1.4 Pˇrep´ın´an´ı kontextu . 4.2 Pˇreruˇsen´ı . . . . . . . . . . 4.2.1 Periodick´e pˇreruˇsen´ı 4.3 Event Control Block . . . . 4.3.1 Speci´aln´ı funkˇcnosti . 4.4 Event-Flag . . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
2 3 3 3 3 4 4 4 4
. . . . . .
5 5 6 6 7 8 8
. . . . . . . . . .
10 10 10 11 12 14 14 15 15 16 18
4.5
Spr´ava pamˇeti . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Pl´ anov´ an´ı proces˚ u 5.1 Preemtivn´ı/Nepremtivn´ı pl´anov´an´ı . . 5.2 Prediktivn´ı synchronizace . . . . . . . 5.3 Situaˇcn´ı model . . . . . . . . . . . . . ´ 5.3.1 Ulohy . . . . . . . . . . . . . . ˇ e cyklick´e . . . . . . . . . . 5.3.2 Cistˇ 5.3.3 Pˇrev´aˇznˇe cyklick´e . . . . . . . . 5.3.4 Asynchronn´ı a predikovateln´e . 5.3.5 Asynchronn´ı a nepredikovateln´e ˇ 5.3.6 Cinitel vyt´ıˇzen´ı CPU . . . . . . 5.4 Obsluha pˇreruˇsen´ı . . . . . . . . . . . . 5.5 Statick´e rozvrhov´an´ı . . . . . . . . . . 5.5.1 Rate Monotonic . . . . . . . . . 5.5.2 Deadline Monotonic . . . . . . 5.6 Dynamick´e rozvrhov´an´ı . . . . . . . . . 5.6.1 Earliest Deadline First . . . . . 5.6.2 Least Laxity First . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
21 21 21 22 22 23 23 23 23 24 24 24 25 25 25 26 26
6 Implementace 6.1 Modifikace zdrojov´ ych k´od˚ u . . . . . . . 6.2 Moˇznosti jak vytvoˇrit u ´lohu . . . . . . . 6.2.1 Vlastn´ı funkce na vytv´aˇren´ı u ´loh 6.2.2 Rozˇs´ıˇren´ı TCB . . . . . . . . . . 6.2.3 Vyuˇzit´ı OSTaskCreateExt . . . . 6.2.4 Standartn´ı parametry . . . . . . . 6.2.5 Parametry modelu u ´lohy . . . . . 6.3 Implementace algoritm˚ u . . . . . . . . . 6.3.1 Statick´e pl´anov´an´ı . . . . . . . . 6.3.2 Dynamick´e pl´anov´an´ı . . . . . . . 6.3.3 Zmˇena priorit . . . . . . . . . . . 6.4 Sbˇer parametr˚ uu ´loh . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
27 27 28 28 28 30 30 31 32 33 33 34 35
7 Zhodnocen´ı ˇ reˇ sen´ı 38 7.1 Testovac´ı u ´lohy . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2 Nev´ yhody ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.3 V´ yhody ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8 Z´ avˇ er
48
A V´ yvojov´ a prostˇ red´ı a nastaven´ı µC/OS-II 55 A.1 V´ yvojov´e prostˇred´ı . . . . . . . . . . . . . . . . . . . . . . . . 55 B Sestaven´ı konfigurace
58
´ 1 Uvod µC/OS-II je operaˇcn´ı syst´em re´aln´eho ˇcasu dod´avan´ y ve formˇe zdrojov´ ych k´od˚ u programovac´ıho jazyka C, implementovan´ y na v´ıce neˇz 40 hardwarov´ ych architektur´ach. Za jeho v´ yvojem stoj´ı spoleˇcnost Micriµm Technologies Corporation a je pouˇz´ıv´an v cel´e ˇradˇe aplikac´ı od ˇr´ıd´ıc´ı elektroniky aˇz po letectv´ı. Pro nekomerˇcn´ı a akademick´e pouˇzit´ı nemus´ı b´ yt tento syst´em licencov´an. K implementaci µC/OS-II na konkr´etn´ı procesor je nutno upravit jeho konfiguraci a doplnit zdrojov´e k´ody operaˇcn´ıho syst´emu o k´od specifick´ y pro dan´ y procesor. Takto upraven´ y syst´em µC/OS-II b´ yv´a naz´ yv´an portem. Pro vytvoˇren´ı spustiteln´eho k´odu je nutn´ y pˇrekladaˇc jazyka C, assembleru a sestavovac´ı program. C´ılem t´eto pr´ace je implementace jin´eho neˇz standardn´ıho pl´anov´an´ı proces˚ u operaˇcn´ıho syst´emu µC/OS-II 2.86. Standardn´ım se mysl´ı statick´e nastaven´ı priorit po spuˇstˇen´ı syst´emu. V´ ysledky by mˇely b´ yt ovˇeˇreny vhodn´ ymi testovac´ımi u ´lohami, napˇr. na H8S2633F, coˇz je obchodn´ı n´azev jednoˇcipov´eho mikropoˇc´ıtaˇce firmy Renesas Technology Corporation. Oˇcek´av´ano je lepˇs´ı vyuˇzit´ı strojov´eho ˇcasu procesoru. D´ale u pˇr´ıpadov´ ych u ´loh zaruˇcen´ı splnˇen´ı mezn´ıho ˇcasu vykon´av´an´ı oproti st´avaj´ıc´ı implementaci, z´aroveˇ n mezi implementovan´ ymi algoritmy. • Seznamte se s operaˇcn´ım syst´emem MicroC/OS-II. • Prostudujte metody pl´anov´an´ı u ´loh v RTOS. Vyberte metody vhodn´e pro implementaci v µC/OS-II. • Navrhnˇete u ´pravy pl´anovaˇce proces˚ u v µC/OS-II tak, aby umoˇzn ˇoval pl´anov´an´ı podle zvolen´ ych metod. • Spr´avnou funkˇcnost pl´anovaˇce demonstrujte na vhodn´ ych pˇr´ıkladech.
1
2 Real-time syst´emy Real-time operaˇcn´ı syst´emy (RTOS) jsou speci´alnˇe navrhov´any pro splnˇen´ı pˇr´ısn´ ych ˇcasov´ ych omezen´ı. Problematiku RTOS si uk´aˇzeme na n´asleduj´ıc´ım pˇr´ıkladu z bˇeˇzn´eho ˇzivota. Jako pˇr´ıklad uved’me syst´em vyhodnocuj´ıc´ı u ´daje v automobilu napˇr. syst´emy ABS, ESR apod. Zde n´as ihned napadne, ˇze zpracov´an´ı u ´daj˚ u od bezpeˇcnostn´ıch prvk˚ u mus´ı m´ıt aktu´aln´ı hodnoty. Tedy m´ame pevnˇe dan´ y ˇcasov´ yu ´daj, do kdy mus´ı b´ yt informace vyhodnoceny. Nen´ı-li toto splnˇeno, jsou informace bezcenn´e. Nejen v automobilech nalezneme syst´em, kter´ y zpracov´av´a obraz pˇred automobilem (k rozezn´an´ı dopravn´ıch znaˇcek). Zde jiˇz nen´ı tak striktn´ı omezen´ı na dobu odezvy. Uvˇedom´ıme-li si, jak z´asadn´ı je z´ısk´an´ı informace o sn´ıˇzen´e rychlosti. Obraz b´ yv´a obvykle zpracov´av´an na vzd´alenost 100m, tedy pˇri 90km/h ujedeme pˇri zpoˇzdˇen´ı jedn´e sekundy 25m. I po t´eto dobˇe m´ame znaˇcku st´ale pˇred n´ami a tedy z´onu se sn´ıˇzenou rychlost´ı tak´e. Ale napˇr´ıklad pˇri zpoˇzdˇen´ı 5s bychom byli uˇz v z´onˇe a v lepˇs´ım pˇr´ıpadˇe by n´am hrozila pokuta. M´ame tedy definov´an deadline ud´alosti, ale nemus´ıme jej tak striktnˇe dodrˇzet jako v pˇr´ıpadˇe bezpeˇcnostn´ı v´ ybavy. Syst´emu, kde je povoleno pˇrekroˇcen´ı deadlinu o nezbytnˇe nutn´e zpoˇzdˇen´ı. M˚ uˇzeme ˇr´ıci, ˇze t´emˇeˇr kaˇzd´ y ˇr´ıd´ıc´ı syst´em, je syst´em re´aln´eho ˇcasu. Pro pˇredstavu kde se RTOS pouˇz´ıv´a, uved’me nˇekter´e pˇr´ıklady. • Automobily - ˇr´ıd´ıc´ı jednotky motoru, bezpeˇcnostn´ı prvky v´ ybavy • Dom´acnost - praˇcky, mikro-vlnn´e trouby, myˇcky, kotle na vyt´apˇen´ı • Letectv´ı - zbraˇ nov´e syst´emy, navigaˇcn´ı syst´emy, radarov´ y syst´em ˇ ızen´ı v´ yroby - automatizovan´e v´ yrobn´ı linky • R´ Napˇr´ıklad rozvinut´e leteck´e kontroln´ı syst´emy, kter´e pouˇz´ıvaj´ı jeden centr´aln´ı poˇc´ıtaˇc, se mus´ı vyrovnat s nˇekolika letadlov´ ymi subsyst´emy, coˇz vyˇzaduje operaˇcn´ı syst´em s oddˇelen´ım ˇcasu a prostoru pro pˇripojen´e syst´emy. Prostorov´e dˇelen´ı znamen´a, ˇze kaˇzd´ y u ´kol je bezpeˇcnˇe izolovan´ y v pamˇeti poˇc´ıtaˇce, zat´ımco ˇcasov´e oddˇelen´ı je vlastnˇe rozdˇelen´ı v´ ykonn´eho ˇcasu procesoru. 2
Real-time syst´emy
Historie a souˇcasn´y stav
Toto dˇelen´ı umoˇzn ˇuje jedin´emu procesoru vykon´avat nˇekolik u ´loh souˇcasnˇe, bez rizika jednoho u ´kolu zp˚ usobit probl´emy v jin´ ych u ´kolech. V´ ysledkem tohoto je napˇr. sn´ıˇzen´ı poˇctu poˇc´ıtaˇc˚ u v letadle a tedy redukovat jeho hmotnost. Tento druh syst´em˚ u je vhodn´e pouˇz´ıvat tam kde, potˇrebujeme reflektovat pˇrirozen´ y paralelismus skuteˇcn´ ych dˇej˚ u. Synchronizace a v´ ymˇena dat mezi u ´lohami reprezentuje interakci mezi re´aln´ ymi dˇeji. Oddˇelen´ı funkc´ı (co u ´loha dˇel´a) a ˇcasov´ ych charakteristik (kdy to dˇel´a) jednotliv´ ych u ´loh. Samozˇrejmˇe je to prostˇredn´ık mezi hardwarovou a aplikaˇcn´ı vrstvou. Pom´ah´a program˚ um efektivnˇe vyuˇz´ıvat hardwarov´e a syst´emov´e prostˇredky. Vz´ajemnˇe je od sebe um´ı oddˇelit. V nˇekolika situac´ıch RTOS jsou pˇr´ıtomny v oblasti embedded syst´em˚ u, a vˇetˇsinu ˇcasu nevyˇzaduj´ı z´asah uˇzivatel˚ u.
2.1
Historie a souˇ casn´ y stav
2.2
Obecn´ e pojmy
V t´eto ˇc´asti uvedeme pouze nejz´akladnˇejˇs´ı vlastnosti.
2.2.1
Doba odezvy
Hlavn´ım parametrem RTOS je vˇcasnost odezvy na vstupn´ı podnˇety. Reakce na podnˇety nemus´ı b´ yt nutnˇe za jednotky mikrosekund, aby byl povaˇzov´an za RTOS. D˚ uleˇzit´e je, ˇze mus´ı dodrˇzet ˇcasov´e meze kladen´e na dobu jeho odezvy pro u ´ˇcely dan´e konkr´etn´ı RT aplikace.
2.2.2
Determinismus
Syst´emy re´aln´eho ˇcasu mus´ı b´ yt pˇredv´ıdateln´e vzhledem ke sv´emu chov´an´ı v ˇcase. Mus´ı b´ yt vˇzdy zaruˇcena maxim´aln´ı doba odezvy, po kterou syst´em u ´lohu spln´ı. V opaˇcn´em pˇr´ıpadˇe nast´av´a jeho selh´an´ı. Determinismus nen´ı omezen pouze na ˇcasov´e spektrum, ale oznaˇcuje pˇred3
Real-time syst´emy
Klasifikace RTOS
v´ıdatelnost ud´alost´ı. Lze tedy v jeho libovoln´em stavu s pˇr´ısluˇsn´ ymi hodnotami na vstupu jednoznaˇcnˇe urˇcit, jak´ y bude jeho n´asleduj´ıc´ı stav a v´ ystup. Prvn´ı pˇr´ıpad determinismu se naz´ yv´a tempor´aln´ı, druh´ y ud´alostn´ı. Jin´ ymi slovy ˇreˇceno, je urˇciteln´ y v ˇcase a nebo na z´akladˇe u ´d´alosti.
2.3
Klasifikace RTOS
Dˇelen´ı RT syst´em˚ u, m˚ uˇze b´ yt br´ano dle ˇrady hledisek. Ve vˇetˇsinˇe literatury jsou dˇeleny podle potˇreby dodrˇzet ˇcasov´e poˇzadavky kladen´e na syst´em.
2.3.1
Hard
Na u ´vodn´ım pˇr´ıkladu jsme naznaˇcili ˇcasovou z´avislost v´ ysledk˚ uu ´loh. Podle n´ı dˇel´ıme tak´e na hard real-time a soft real-time. Hard syst´emy dodrˇzuj´ı term´ın dokonˇcen´ı d´avky pˇresnˇe, pokud v ˇcas nedokonˇc´ıme u ´lohu, chov´an´ı syst´emu obvykle vede ke katastrof´aln´ım dopad˚ um. Napˇr. kontroln´ı a ˇr´ıd´ıc´ı syst´emy jadern´e elektr´arny striktnˇe dodrˇzuj´ı term´ın ukonˇcen´ı1 .
2.3.2
Soft
Syst´emy nedodrˇzuj´ıc´ı striktnˇe term´ın ukonˇcen´ı, mohou ”obˇcas”minout deadline. Co znamen´a ”obˇcas”? Nejˇcastˇeji se definuje procentu´aln´ım zastoupen´ım, napˇr. 99% bude dodrˇzeno. Nebo se definuj´ı funkce v z´avislosti na ˇcase, kde po term´ınu ukonˇcen´ı maj´ı klesaj´ıc´ı tendenci relevantnosti dat. Klesaj´ıc´ı pouˇzitelnost dat a zpoˇzdˇen´ı, n´am zde nevad´ı.
2.3.3
Firm
Oproti tomu syst´emy firm maj´ı mez, do kter´e jsou data relevantn´ı, a nevede opoˇzdˇen´ı term´ınu ukonˇcen´ı k p´adu syst´emu. Pakliˇze je tato mez pˇrekroˇcena, m˚ uˇze to m´ı vliv na stabilitu, ba dokonce na p´ad syst´emu.
1
v ang. lit. deadline
4
3 Pˇrehled RTOS Na trhu existuje cel´a ˇrada RTOS a vybrat z nich nemus´ı b´ yt jednoduch´e. M˚ uˇzeme vyb´ırat z volnˇe dostupn´ ych tak i komerˇcn´ıch. Tak´e m˚ uˇzeme vyb´ırat podle podporovan´ ych platforem, podpoˇre samotn´eho v´ yrobce ˇci komunity. Vˇetˇsina RTOS m´a vlastnosti popsan´e v´ yˇse. V n´asleduj´ıc´ı ˇc´asti jsou vyzdvihnuty vlastnosti, kter´ ymi se dan´ y v´ yrobce prezentuje. Uveden´e syst´emy jsou byly vybr´any podle nejˇcastˇejiˇs´ıho zastoupen´ı a jsou minimem toho, co nab´ız´ı trh.
3.1
Windows Embeded
Mezi hlavn´ı zbranˇe syst´em˚ u postaven´ ych na platformˇe spoleˇcnosti Microsoft 1 patˇr´ı podpora sv´ ych sluˇzeb. D´ıky tomu se daj´ı uˇsetˇrit nemal´e v´ ydaje za v´ yvoj nadstandartn´ıch poˇzadavk˚ u. Vyuˇzit´ı najde od pˇrenosn´ ych ultrazvukov´ ych pˇr´ıstroj˚ u, GPS zaˇr´ızen´ı, bankomat˚ u po vyuˇzit´ı ve velk´ ych stavebn´ıch stroj´ıch. Hlavn´ı dom´enou tˇechto syst´em˚ u je pr´ace s vlastn´ımi technologiemi. Zejm´ena pro podporu synchronizace dat, vyuˇzit´ı profil˚ u, m´ıstn´ı sluˇzby, reklamn´ı odvˇetv´ı, business intelligence a line-in-business aplikac´ı, zpracov´an´ı dat ze zaˇr´ızen´ı. Zapojen´ı zaˇr´ızen´ı do jedn´e platformy pˇrin´aˇs´ı napˇr´ıklad: • Silverlight pro Windows Embedded • Internet Explorer Embedded • Dotykov´e ovl´ad´an´ı • Media Player • Office and PDF Viewers • a dalˇs´ı Mezi podporovan´e platformy patˇr´ı ARM architektura, x86 procesory, x64 procesory, MIPS a dalˇs´ı. Samozˇrejmost´ı se pak st´av´a podpora napˇr´ıklad nˇekter´ ych souborov´ ych syst´em˚ u, bluetooth technologie a dalˇs´ı. V´ yvoj aplikac´ı je plnˇe podporov´an v´ yvojov´ ym prostˇred´ı Microsoft Visio. 1
[WinEM]
5
Pˇrehled RTOS
3.2
QNX Neutrino
QNX Neutrino
Rozs´ahl´a podpora POSIX standard˚ u usnadˇ nuje pˇrenositelnost aplikac´ı a rychlou migraci z Linux, Unix, a dalˇs´ıch open source program˚ u. Runtime podpora a sady BSP pro popul´arn´ı chipsety, vˇcetnˇe ARM, MIPS, PowerPC, SH-4, a x86, umoˇzn ˇuje n´avrh´aˇr˚ um vybrat nejlepˇs´ı hardwarov´e platformy pro jejich embedded syst´em, pak se rychle dostat sv´e syst´emy do provozu. D´ıky mikroj´adru architektury QNX Neutrino RTOS2 , prakticky jak´akoli souˇc´ast (i low-level ovladaˇc) m˚ uˇze selhat, bez poˇskozen´ı j´adra nebo jin´e souˇc´asti. Vyt´ıˇzen´ı procesoru, pokud jsou zdroje omezen´e, z´ıskaj´ı procesy dle pod´ıl˚ u. Pokud ovladaˇce zaˇr´ızen´ı, protokol z´asobn´ıku, nebo aplikace selˇze. Je v QNX Neutrino RTOS zaˇr´ızeno, tak aby nezkolaboval syst´em. Ale manaˇzer ukonˇcil u ´lohu s probl´emem a obnovil jej (ˇcasto za nˇekolik milisekund bez restartu). Podporovan´e jsou t´eˇz s´ıt’ov´e technologie, mezi nˇeˇz patˇr´ı IPv4, IPv6, IPSec, FTP, HTTP, SSH a Telnet. Unik´atn´ı transparentn´ı distribuce umoˇzn ˇuje pˇr´ıstup k prostˇredk˚ um na libovoln´em uzlu v s´ıti, pro bezprobl´emov´e peer-to-peer sd´ılen´ı zdroj˚ u. QNX souborov´e syst´emy jsou obsluhov´any mimo mikroj´adro v uˇzivatelsk´e chr´anˇen´e-pamˇeti. V´ yvoj´aˇri mohou spustit, zastavit, nebo aktualizovat souborov´e syst´emy za bˇehu bez nutnosti restartu. V´ıce souborov´ ych syst´em˚ u m˚ uˇze b´ yt spuˇstˇeno souˇcasnˇe a dokonce pracovat nar´az s c´ılem rozˇs´ıˇrit navz´ajem schopnosti.
3.3
Wind River VxWorks
VxWorks3 byl navrˇzen pro pouˇzit´ı v r˚ uzn´ ych multi-j´adrov´ ych sestav´ach jako sv´eho ˇcasu jedin´ y operaˇcn´ı syst´em na symetrick´em/asymetrick´em multiprocesov´em reˇzimu nebo jako host OS na vrcholu Wind River Hypervisor. VxWorks je vysoce ˇsk´alovateln´ y RTOS. VxWorks syst´emy zahrnuj´ı certifikovan´ y OS pro velmi pˇr´ısn´e bezpeˇcnostn´ı normy. VxWorks tak´e nab´ız´ı nˇekolik u ´rovn´ı zabezpeˇcen´ı, vysokou odol2 3
[QNXso] [VxWor]
6
Pˇrehled RTOS
Nucleus
nost RTOS bezpeˇcnosti pro n´aroˇcn´e poˇzadavky Common Criteria a National Information Assurance Partnership (NIAP). VxWorks m´a ˇreˇsen´ı pro kaˇzd´ y aspekt vestavˇen´ ych syst´em˚ u komunikace. S Wind River Tilcon Graphics Suite maj´ı v´ yvoj´aˇri k dispozici rychl´ y n´avrh grafick´eho uˇzivatelsk´eho rozhran´ı. Podporovan´e jsou mikroprocesory napˇr´ıklad spoleˇcnost´ı Aitech Defense Systems Inc., AMD, ARM Ltd., Broadcom Corporation, Freescale Semiconductor, Goma Elettronica S.P.A., Hilscher Gesellschaft fur Systemautomation mbH., Integrated Device Technology (IDT), Intel Corporation a mnoho dalˇs´ıch.
3.4
Nucleus
Spoleˇcnost Mentor Graphics4 t´eˇz nab´ız´ı RTOS. Siln´e str´anky tohoto syst´emu jsou v rozdˇelen´ı funkc´ı, tak aby byly co nejv´ıce nez´avisl´e a pˇri p´adu aplikace nezkolaboval cel´ y syst´em. Operaˇcn´ı syst´em poskytuje bohat´e moˇznosti pro grafick´e uˇzivatelsk´e rozhran´ı. Samozˇrejmost´ı je ovl´ad´an´ı dotykov´ ych panel˚ u. Nechyb´ı zde podpora nejr˚ uznˇejˇs´ıch standardn´ıch komunikaˇcn´ıch rozhran´ı a protokol˚ u. Mezi nˇeˇz patˇr´ı USB, SATA, IDE a mnoh´e dalˇs´ı. Umoˇzn ˇuje tak´e virtualizace nˇekter´ ych rozhran´ı, napˇr. RS232. Mezi s´ıt’ov´ ymi protokoly nechyb´ı IPv4 ani IPv6, souˇc´ast´ı jsou pˇr´ıpravy napˇr´ıklad pro SNTP klienty, SMTP klient/server. Podpora multim´edi´ı je na vysok´e u ´rovni, vyuˇz´ıvaj´ı otevˇren´e, platformˇe nez´avisl´e API OpenMax. To umoˇzn ˇuje pˇrehr´avat standardn´ı typy audio a video form´at˚ u. S podporou rozhran´ı pamˇet’ov´ ych m´edi´ı, je spojena podpora souborov´ ych syst´em˚ u FAT12, FAT16, FAT32 a tak´e vlastn´ıho Nucleus SAFE pro flash pamˇeti. Podporovan´e platformy jsou PowerPC, MIPS, ColdFire, Atmel. Stejnˇe jako u vˇetˇsiny pˇredchoz´ıch, z´avis´ı platforma na pˇrekladaˇci zde jazyka C++ pro c´ılovou platformu. 4
[Nucle]
7
Pˇrehled RTOS
3.5
LynxOS RTOS
LynxOS RTOS
Komponenty RTOS v LynxOS5 jsou navrˇzeny pro absolutn´ı determinismus. Tyto pˇredv´ıdateln´e reakce jsou zajiˇstˇeny i v pˇr´ıtomnosti sloˇzit´ ych I/O operac´ı, protoˇze j´adro syst´emu umoˇzn ˇuje extr´emnˇe kr´atk´e a rychle obslouˇzen´e pˇreruˇsen´ı. LynxOS RTOS tak´e pouˇz´ıv´a line´arn´ı ˇsk´alovatelnost, takˇze z˚ ust´av´a neochvˇejnˇe deterministick´ y. Toho je vyuˇzito zejm´ena pro v´ ybornou odezvu napˇr´ıklad v komunikac´ıch. Schopnosti s´ıt’ov´e komunikace tohoto syst´emu jsou takt´eˇz vyspˇel´e, nechyb´ı napˇr´ıklad IPSec, IPv6, integrovan´ y firewall, a Quality of Service (QoS). Zahrnuje nejnovˇejˇs´ı protokoly a moˇznosti pro vytv´aˇren´ı s´ıt’ov´ ych prvk˚ u, vˇcetnˇe Gigabit Ethernet, SNMP v1, 2 a 3, smˇerovac´ı algoritmy jako RIPv2, OSPFv2 a BGP-4. V´ yvoj aplikac´ı a u ´pravy syst´emu jsou doporuˇcov´any pro Eclipse, kter´ y je de facto ˇs´ıˇren jako otevˇren´ y v´ yvojov´ y n´astroj. Vhodn´ ym doplˇ nkem je i debugger SpyKer schopn´ y monitorov´an´ı vˇsech ud´alost´ı v syst´emu. Mezi platformami, kter´e tento syst´em podporuje, najdeme x86 od desek s procesory s 386 aˇz po Core 2 Duo procesory. Vyj´ımkou nejsou ani nˇekter´e procesory AMD a Via Cyrix. Samozˇrejmˇe najdeme z´astupce dalˇs´ı architektury, mezi nˇeˇz patˇr´ı nejr˚ uznˇejˇs´ı procesory PowerPC, nˇekter´e desky s MIPS mikroprocesory, nebo z´astupce od IBM ˇrada 440.
3.6
Linux
Zab´ yvat se schopnostmi operaˇcn´ıch syst´em˚ u zaloˇzen´ ych na Linuxov´em j´adˇre je takˇrka nemoˇzn´e. A to d´ıky tomu, ˇze pokr´ yvaj´ı nepˇrebernou oblast pouˇzit´ı, od jednoduch´ ych s´ıt’ov´ ych prvk˚ u, pˇres mobiln´ı telefony aˇz po serverov´e stanice. Nav´ıc zde nar´aˇz´ıme na nejednotnost distribuc´ı, pˇredevˇs´ım v desktopov´e sf´eˇre. Pro operaˇcn´ı syst´em Linux existuj´ı extern´ı ˇreˇsen´ı, kter´e jsou v implementov´any do j´adra syst´emu. Od poˇc´atku nebyl Linux navrhov´an jako RealTime operaˇcn´ı syst´em. Zmˇenit jeho j´adro, kter´e m´a navrˇzeno fixnˇe prioritn´ı pl´anov´an´ı, by bylo pˇrinejmenˇs´ım nevhodn´e a komplikovan´e. Z tohoto d˚ uvodu 5
[LyRto]
8
Pˇrehled RTOS
Linux
je moˇzn´e doplnit tento syst´em o RT pl´anov´an´ı, formou minim´aln´ıch u ´prav j´adra a dod´an´ım extern´ıch modul˚ u pl´anov´an´ı. Funguj´ı zde tak pospolu jak u ´lohy real-time-ov´e, tak ne-real-time-ov´e pospolu. Ne-RT u ´lohy jsou vykon´av´any v pˇr´ıpadˇe, ˇze nem´a b´ yt vykon´av´ana RT u ´loha.
9
4 µC/OS-II V t´eto kapitole probereme v rychlosti vlastnosti vybran´eho real-time operaˇcn´ıho syst´emu. Nebudeme se jimi vˇsak zab´ yvat dopodrobna, nen´ı to c´ılem pr´ace. Sp´ıˇse to berme jako z´aklad, kter´ y by mˇel v´ yvoj´aˇr pracuj´ıc´ı s µC/OS-II zn´at.
4.1
´ Ulohy
´ Ulohou oznaˇcujeme programov´ y k´od oddˇelen´ y v ˇcase a pamˇeti, kter´ y vykon´av´a poˇzadovanou funkci. Obvykle je u ´loha implementov´ana jako nekoneˇcn´a smyˇcka. Verze 2.00 obsahuje 64 prioritn´ıch u ´rovn´ı, kaˇzd´a m˚ uˇze odpov´ıdat pr´avˇe jedn´e u ´loze. Ve skuteˇcnosti jsou nˇekter´e rezervov´any pro syst´emov´a vl´akna. Nejvyˇsˇs´ı ˇctyˇri a nejniˇzˇs´ı ˇctyˇri v pozdˇejˇs´ıch verz´ıch je moˇznost vyuˇzit´ı aˇz 256 priorit. J´adro umoˇzn ˇuje pomoc´ı rezervovan´ ych funkc´ı mˇenit priority vl´aken, oznaˇcit vl´akno za smazan´e, fakticky jej ale nesmaˇze.
4.1.1
Stavy u ´ loh
Kaˇzd´ y u ´kol pˇri sv´em bˇehu se m˚ uˇze dostat do nˇekolika stav˚ u. Podle nich pl´anovaˇc urˇcuje, kter´a u ´loha bude vykon´av´ana. Stavy u ´loh v µC/OS-II jsou: • dormant • ready • running • waiting • interrupted ´ Dormant odpov´ıd´a stavu, kdy je vl´akno v pamˇeti, ale nen´ı dostupn´e. Uloha, kter´a je ready, ˇcek´a na ukonˇcen´ı pr´avˇe bˇeˇz´ıc´ıho vl´akna a je pˇripraveny k bˇehu. Vl´akno vlastn´ıc´ı CPU je running. Waiting u ´kol, ˇcek´a na dokonˇcen´ı napˇr. I/O operace, na sd´ılen´e zdroje. Interrupt service routine1 obsluhuje 1
Interrupted d´ ale jen ISR
10
´ Ulohy
µC/OS-II
TASK WAITING
TASK DORMANT
TASK READY
TASK RUNING
ISR WAITING
Obr´azek 4.1: Stavy vl´aken pˇreruˇsen´ı vznikl´e nenad´alou ud´alost´ı a pˇreb´ır´a CPU. Na obr. 4.1 jsou stavy zn´azornˇeny spolu s pˇrechody mezi nimi. Obecnˇe nem˚ uˇzeme ˇr´ıci, ˇze by kaˇzd´ y RTOS pouˇz´ıval stejn´e oznaˇcen´ı, ale jistˇe pˇrid´a ˇci ubere nˇejak´ y jin´ y stav.
4.1.2
Task Control Block
Kaˇzd´e vytvoˇren´e vl´akno m´a k sobˇe pˇridruˇzen´ y pamˇet’ov´ y prostor naz´ yvan´ y task control block. TCB je datov´a struktura, pouˇz´ıvan´a µC/OS-II k udrˇzen´ı stavu nejen pˇreruˇsen´e u ´lohy. Po vykon´an´ı u ´lohy s vyˇsˇs´ı prioritou, n´avratu k pˇreruˇsen´e a opˇet z´ıskat kontrolu nad CPU, tam kde vykon´av´an´ı opustila. Struktura obsahuje • ukazatel na vrchol z´asobn´ıku u ´lohy • ukazatel na dno z´asobn´ıku u ´lohy • velikost z´asobn´ıku 11
´ Ulohy
µC/OS-II • nastaven´ı rozˇs´ıˇren´ı z´asobn´ıku • nastaven´ı ovˇeˇren´ı z´asobn´ıku • indikaci vyˇciˇstˇen´ı z´asobn´ıku • nastaven´ı pouˇzit´ı Floating Point • identifik´ator vl´akna • n´asledn´ıka a pˇredch˚ udce (TCB) • ukazatel na Event Control Block • ukazatel na zpr´avy vl´aknu • ukazatel na zachycen´e ud´alosti • informaci zda bude u ´loha ready po splnˇen´ı vybran´e ud´alosti • informace, zda je u ´loha odloˇzena na urˇcit´ y ˇcas • stav u ´lohy • prioritu u ´lohy • udaje zrychluj´ıc´ı v´ ybˇer ready u ´lohy • indikace smaz´an´ı u ´lohy • ukazatel na uˇzivatelsk´e rozˇs´ıˇren´ı TCB
Po inicializov´an´ı µC/OS-II jsou vˇsechny TCB v tabulce propojeny jako spojov´ y seznam voln´ ych OS TCB. Velikost tabulky je omeziteln´a nastaven´ım poˇctu u ´loh v souboru os cpu.h. Jin´e syst´emy mohou udrˇzovat dalˇs´ı u ´daje, napˇr. nˇekter´e se hod´ı pro dynamick´e pl´anov´an´ı u ´loh, statistick´e u ´daje apod.
4.1.3
V´ ybˇ er u ´ lohy
Kaˇzd´a u ´loha ve stavu ready je um´ıstˇena v seznamu ready list. Poloˇzky nesou informace o OSRdyGrp a OSRdyTbl[]. Priority jsou seskupov´any po osmi u ´loh´ach ve skupinˇe. Na obr.4.2 je zn´azornˇena struktura ready listu a v´ ybˇer poloˇzky. Bitov´a maska je v k´odu 1 z n nikoli v klasick´e dvojkov´e soustavˇe. Kaˇzd´ y bit OSRdyGrp reprezentuje sv´ ym indexem skupinu, kter´a obsahuje 12
´ Ulohy
µC/OS-II OSRdyGrp 7 6 5 4 3 2 1 0
OSRdyTbl[OS_LOWEST_PRIO / 8 + 1] Highest Priority
x
[0] [1] [2] [3] [4] [5] [6] [7]
7 6 5 4 3 2 1 15 14 13 12 11 10 9 23 22 21 20 19 18 17 31 30 29 28 27 26 25 39 38 37 36 35 34 33 47 46 45 44 43 42 41 55 54 53 52 51 50 49 63 62 61 60 59 58 57
0 8 16 24 32 40 48 56
y
Task Priority #
Task's Priority
Lowest Priority
0 0 Y Y Y X X X Bit position in OSRdyTbl[OS_LOWEST_PRIO / 8 + 1] Bit position in OSRdyGrp and Index into OSRdyTbl[OS_LOWEST_PRIO / 8 + 1]
Obr´azek 4.2: V´ ybˇer u ´lohy z Ready listu vl´akno ve stavu ready, a je indexem do OSRdyTbl[]. Neˇz je pˇrepnut kontext procesoru je nutn´e vybrat z ready listu u ´lohu. V p˚ uvodn´ı implementaci µC/OS-II je doba v´ ybˇeru z´avisl´a na poˇctu u ´loh a je konstantn´ı. Zp˚ usob jak naj´ıt ready u ´lohu je prost´ y, ale pomal´ y. Pl´anovaˇc by musel vˇzdy proj´ıt celou OSRdyTabl[], naˇstˇest´ı je toto vyˇreˇseno statickou lookup tabulkou. Ve kter´e pomoc´ı indexu OSRdyGrp z´ısk´ame Y souˇradnici do OSRdyTbl[] a z indexu OSrdyTbl[Y] z´ısk´ame X souˇradnici. Takto popsan´ y ready list nelze br´at jako obecnˇe pouˇz´ıvan´ y v RTOS. Objevuj´ı se varianty pouˇzit´ı prioritn´ıch front, zajiˇstˇen´ı spr´avn´e um´ıstˇen´ı pozice podle priority je ot´azkou ˇrad´ıc´ıch algoritm˚ u, nebo pouˇzit´ım kl´ıˇc˚ u jako priorit. Pˇri v´ ybˇeru u ´loh pl´anovaˇc m˚ uˇze b´ yt pˇreruˇsen. Obsluha a spr´ava pˇreruˇsen´ı je dostupn´a i v pˇr´ıpadˇe pˇrepl´anov´an´ı. Pouze by se nemˇelo st´at, ˇze pˇreruˇsen´ı vyvol´a opˇetovn´e pˇrepl´anov´an´ı. Totiˇz v pˇr´ıpadˇe n´avratu do pl´anovaˇce, na stejn´e m´ısto kde byl pˇreruˇsen, by mohlo doj´ıt k situaci, ˇze pr´avˇe vyvolan´e pˇreruˇsen´ı-pˇrepl´anov´an´ı zmˇenilo pomˇery v syst´emu a nemusela by b´ yt vybr´ana spr´avn´a u ´loha. K z´akazu pˇreruˇsen´ı syst´em definuje funkce OSShedLock() a OSShedUnLock() tyto funkce se mus´ı pouˇz´ıvat p´arovˇe, tzn. zamknout a po vybr´an´ı u ´lohy odemknout.
13
µC/OS-II
4.1.4
Pˇreruˇsen´ı
Pˇ rep´ın´ an´ı kontextu
Po v´ ybˇeru u ´lohy je nutn´e uchovat informace o pˇreruˇsen´e ˇci pro danou chv´ıli splnˇen´e u ´loze. K tomu je pˇreddefinov´ano makro, kter´e mus´ı v´ yvoj´aˇr portace vytvoˇrit pro kaˇzdou platformu zvl´aˇst’. Mˇel by se postarat o bezchybn´e uloˇzen´ı hodnot registr˚ u procesoru. Implementace tohoto makra je z´aleˇzitost´ı obsluhy softwarov´eho pˇreruˇsen´ı. Pˇrenositelnosti a naps´an´ı maker pro specifick´e platformy je z´aleˇzitost velmi komplikovan´a, podrobnˇeji se j´ı vˇenuje autor syst´emu ve sv´e knize [MicroII].
4.2
Pˇ reruˇ sen´ı
V souvislosti s v´ ybˇerem u ´lohy a pˇrepnut´ım kontextu jsme zm´ınili pˇreruˇsen´ı. 2 Interrupt je schopnost procesoru pozastavit pr´avˇe vykon´avan´ y program a zaˇc´ıt vykon´avat jin´ y program (obsluhu pˇreruˇsen´ı). Zaˇcalo se implementovat do procesor˚ u z d˚ uvodu obsluhy periferii – pˇresnˇeji V/V zaˇr´ızen´ı. Procesor je obvykle mnohem rychlejˇs´ı neˇz ostatn´ı hardware, a tak kdyby se zab´ yval pouze obsluhou periferie, byl by v danou chv´ıli nevyuˇzit a vˇetˇsinu sv´eho procesorov´eho ˇcasu by str´avil ve smyˇcce ˇcek´an´ım na dan´ y hardware. V dneˇsn´ı dobˇe se pˇreruˇsen´ı vyuˇz´ıv´a mnohem v´ıc pˇri pˇrep´ın´an´ı proces˚ u. Pˇreruˇsen´ı v architektur´ach se vyvol´a dvˇema z´akladn´ımi zp˚ usoby, Software-generated (softwarovˇe) a External-hardware generated (hardwarovˇe), tedy vyvolan´e vnˇejˇs´ım okol´ım. To se d´ale rozdˇeluje na NMI3 nemaskovateln´e a na INTR4 . Softwarov´a pˇreruˇsen´ı vznikaj´ı v jedin´em pˇr´ıpadˇe, a to kdyˇz procesor naraz´ı na instrukci pˇreruˇsen´ı µC/OS-II se toto prov´ad´ı inkrementov´an´ım OSIntNesting nebo pouˇzit´ım funkce OSIntEnter. Kdyˇz jsem v minul´em odstavci definoval pˇreruˇsen´ı vyvolan´e mimo procesor, nebyla to u ´plnˇe pravda, protoˇze do hardwarov´eho pˇreruˇsen´ı se ˇrad´ı tzv. Internal HW, kter´a vznikaj´ı pˇri vnitˇrn´ı chybˇe k´odu, napˇr. dˇelen´ı nulou, ˇspatn´a instrukce. Externˇe vyvolan´e pˇreruˇsen´ı nast´av´a pˇri ˇz´adosti ze vstupu (vnˇejˇs´ı hardware) nebo chybˇe matematick´eho koprocesoru. Co se tedy stane, kdyˇz procesor obdrˇz´ı ˇz´adost o pˇreruˇsen´ı? Nejprve zkontroluje, jestli se dan´ y sign´al bude maskovat a pokud ne, pˇreruˇs´ı pr´avˇe 2
pˇreruˇsen´ı Non Maskable Interrupt 4 Interrupt Request 3
14
µC/OS-II
Event Control Block
vykon´avan´ y program a zaˇcne vykon´avat program obsluhy pˇreruˇsen´ı (Interrupt Service Routine). Provede se v´ ybˇer obsluhy podle vektor˚ u pˇreruˇsen´ı (u vˇetˇsiny microprocesor˚ u), uloˇz´ı se kontext prob´ıhaj´ıc´ı u ´lohy a upozorn´ı se j´adro na vstup do obsluhy pˇreruˇsen´ı. N´aslednˇe se provede uˇzivatelsk´e obslouˇzen´ı pˇreruˇsen´ı. Po jeho ukonˇcen´ı se informuje j´adro o v´ ystup z ISR, obnov´ı kontext CPU a pokraˇcuje se v u ´loze d´al. V µC/OS-II je opˇet pouze definov´ana obsluha pˇreruˇsen´ı. Jej´ı implementace z´avis´ı t´eˇz na jednotliv´e architektuˇre.
4.2.1
Periodick´ e pˇ reruˇ sen´ı
Je speci´aln´ı pˇr´ıpad pˇreruˇsen´ı, vˇetˇsinou slouˇz´ıc´ı k odmˇeˇrov´an´ı poˇctu instrukc´ı, dobˇe vykon´av´an´ı apod.. Doporuˇcen´a periody je od deseti do sta opakov´an´ı ˇ ım ˇcastˇeji jsou vyvol´av´ana pˇreruˇsen´ı, t´ım v´ıce to vede za jednu sekundu. C´ ke zpomalen´ı syst´emu. Na druhou stranu jsou pravideln´a pˇreruˇsen´ı, kter´a jsou obslouˇzena hardwarovˇe, napˇr. v µC/OS-II je takto znaˇceno clock tick, ˇcesky ˇcasto oznaˇcovan´e jako hodinov´e pˇreruˇsen´ı a je z´avisl´e na hardwarov´em ˇcasovaˇci procesoru. V´ yvoj´aˇr syst´emu m´a d´ıky tomu k dispozici zp˚ usob jak zmˇeˇrit ˇcasov´e u ´daje. Umoˇzn ˇuje mu tak´e na jednotky ˇcasu nebo poˇcet hodinov´ y pˇreruˇsen´ı uspat ˇcinnost u ´lohy. Tak´e to umoˇzn ˇuje drˇzet informaci o dobˇe bˇehu syst´emu, napˇr. pˇri pouˇzit´ı 32b ˇc´ıtaˇce jsme schopni pro frekvenci 100Hz odmˇeˇrit 497 dn´ı v kuse. Nastaven´ı je souˇc´ast´ı souboru os cfg.h s nastaven´ım konstanty OS TICKS PER SEC.
4.3
Event Control Block
Zat´ım jsme se vˇenovali u ´pln´ ym z´aklad˚ um a vynechali jsme nˇekter´e velmi d˚ uleˇzit´e schopnosti. O doplnˇen´ı funkˇcnosti syst´emu se star´a blok ECB. Tento blok slouˇz´ı vl´akn˚ um ke komunikaci mezi sebou, k zajiˇstˇen´ı konzistentn´ıho pˇr´ıstupu ke sd´ılen´ ym zdroj˚ um pomoc´ı semafor˚ u a front. Pravidla pouˇzit´ı ECB jsou prost´a, jedin´ y kdo m˚ uˇze ˇcekat na sign´al pˇres ECB, jsou vl´akna, nikoli obsluˇzn´e rutiny pˇreruˇsen´ı. Zaznamen´avat sign´aly do ECB vˇsak m˚ uˇzou jak vl´akna tak ISR. Pokud nˇejak´a u ´loha oˇcek´av´a sign´al v ECB, mˇela by b´ yt definov´ana ˇcekac´ı doba. 15
µC/OS-II
Event Control Block
Blok ud´alost´ı je definov´an jako struktura obsahuj´ıc´ı pˇet u ´daj˚ u. Uv´adˇet zde jak vypad´a struktura v pamˇeti, nen´ı d˚ uleˇzit´e. Jelikoˇz hlavn´ı ˇc´ast, tedy tabulka komu se signalizuje, je stejn´a jako tabulka s ready u ´lohami. V´ ybˇer, odebr´an´ı a vloˇzen´ı sign´alu do struktury ECB je totoˇzn´ y s v´ ybˇerem ready u ´loh podle priorit. • typ ud´alosti • ˇc´ıtaˇc v pˇr´ıpadˇe semaforu • ukazatel na frontu nebo zpr´avu • tabulku ˇcekatel˚ u • index do tabulky ´ Uloha ˇcekaj´ıc´ı na sign´al z ECB je vyjmuta z ready listu a je vloˇzena do wait listu ECB. Blok˚ u ECB je v syst´emu v´ıc stejnˇe jako blok˚ u TCB, jsou organizov´any jako spojov´ y seznam, jehoˇz maxim´aln´ı d´elka je konfigurovateln´a.
4.3.1
Speci´ aln´ı funkˇ cnosti
Semafory jsou synchronizaˇcn´ı prvky, pˇrev´aˇznˇe vyuˇzit´e k synchronizaci proces˚ u a samozˇrejmˇe i vl´aken. Semafor je prvek skl´adaj´ıc´ı se z celoˇc´ıseln´eho ˇc´ıtaˇce a operacemi nad semaforem. Hodnota ˇc´ıtaˇce se pohybuje na vymezen´em intervalu, kde jedna strana oznaˇcuje nulov´ y poˇcet pˇr´ıstup˚ u a jedno pln´ y poˇcet pˇr´ıstup˚ u a blokuje u ´lohy. Zaˇzit´a konvence ˇr´ık´a, ˇze ˇc´ıtaˇc nab´ yv´a hodnot 0 aˇz N, kde N kde N je kladn´e cel´e ˇc´ıslo oznaˇcuj´ıc´ı napˇr. omezen´ı velikosti fronty. Zaj´ımav´ y je napˇr. semafor bin´arn´ı, tedy s ˇc´ıtaˇcem 0 aˇz N, kter´ y se d´a vyuˇz´ıt k vz´ajemn´emu vylouˇcen´ı u ´loh. Takov´ yto semafor naz´ yv´ame zkr´acenˇe Mutex. Dalˇs´ı co v´ yvoj´aˇri ECB umoˇzn ˇuje je pouˇzit´ı zpr´av. K dispozici m´ame moˇznost pˇred´avat jednu zpr´avu pouˇzit´ım OS EVENT TYPE MBOX nebo ˇuje vynˇekolik do fronty OS EVENT TYPE Q. Oboj´ı pˇred´av´an´ı stran umoˇzn b´ır´an´ı zpr´av pomoc´ı blokov´an´ı u ´lohy pˇri pr´azdn´e frontˇe, tak i pouze vybr´an´ı bez blokov´an´ı pokud je fronta pr´azdn´a. Rozd´ıl mezi pouˇzit´ım jedn´e zpr´avy a fronty je v pouˇzit´ı ukazatele OSEventPtr v OE EVENT, v pˇr´ıpadˇe fronty ukazuje na strukturu OS Q, kter´a udrˇzuje informace o frontˇe. 16
µC/OS-II
Event Control Block OS_EVENT
OS_EVENT_TYPE_Q
OSEventType OSEventCnt
0x00
OSEventPtr OSEventGroup
0x00 2
1
0
15 14 13 12 11 10
7
6
5
4
3
9
8
void *MsgTbl[]
23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56 message
OS_Q
message
.OSQPtr
message
.OSQStart
message
.OSQEntries
.OSQSize
.OSQSize .OSQOut .OSQIn .OSQEnd .OSQEntries
Obr´azek 4.3: Propojen´ı ECB a OS Q • ukazatel na poˇc´atek fronty • velikost fronty • v´ ystup fronty • vstup fronty • ukazatel na dalˇs´ı frontu • poˇcet prvk˚ u ve frontˇe Propojen´ı struktury ECB s OS Q je na obr.4.3. µC/OS-II umoˇzn ˇuje bez v´ yhrad pouˇz´ıt v´ yˇse uveden´e synchronizaˇcn´ı prvky. Program´ator˚ um poskytne funkce pro vytvoˇren´ı a z´akladn´ı obsluhu. Nav´ıc napˇr. u semafor˚ u umoˇzn ˇuje z´ıskat jejich datovou strukturu. Signalizaci u ´loh´am skrze tyto prvky se prov´ad´ı pr´avˇe pomoc´ı ECB. 17
µC/OS-II
4.4
Event-Flag
Event-Flag
Pouˇzit´ı ECB je mocn´ y n´astroj, m´ısto nˇej lze v ˇradˇe pˇr´ıpad˚ u pouˇz´ıt na pamˇet’ 5 a obsluhu m´enˇe n´aroˇcn´e pˇr´ıznakov´e signalizov´an´ı . Signalizace se zde prov´ad´ı nastavov´an´ım s´eri´ı bit˚ u, udrˇzuj´ıc´ıch informace o stavech. Datov´a struktura OSFlagGroup obsahuje • typ signalizace (flag) • ukazatel na seznam OSFlagNode • OSFlagFlags drˇz´ıc´ı status ud´alost´ı Struktura OSFlagNode urˇcuje, kter´a u ´loha a na co ˇcek´a. Struktury jsou mezi sebou propojen´e, daj´ı se tak pomoc´ı typu skl´adat podm´ınky pro ˇcekaj´ıc´ı vl´akna. Jej´ı struktura je • odkaz na OSFlagGroup • ukazatel na dalˇs´ı OSFlagNode (pˇredka a n´asledovn´ıka) • ukazatel na TCB ˇcekaj´ıc´ı u ´lohy • vzor signalizace bit˚ u • typ struktury OR/AND (ALL/ANY) Vytv´aˇren´ı skupiny signalizace mohou jen vl´akna, nikdy se nesm´ı st´at, aby se vytv´aˇreli v ISR. Po vytvoˇren´ı je skupina pr´azdn´a a je nutn´e nastavit jej´ı parametry. Seznam podm´ınek je moˇzn´e vytvoˇrit pˇripraven´ım struktur. Takt´eˇz signalizov´an´ım blokov´an´ı, kdyˇz se naraz´ı na funkci OSFlagPend(), jej´ıˇz parametry jsou data struktury OSFlagNode. Po odblokov´an´ı u ´lohy je nutn´e ji odebrat z listu ˇcekatel˚ u a oznaˇcit vl´akno za ready.
4.5
Spr´ ava pamˇ eti
V´ yvoj´aˇr aplikac´ı v C/C++, kter´ y bˇeˇznˇe pouˇz´ıvat dynamick´e alokov´an´ı a uvolˇ nov´an´ı pamˇeti pomoc´ı malloc() a free(), by si mˇel uvˇedomit n´asleduj´ıc´ı. Pouˇzit´ı tˇechto funkc´ı je velmi nebezpeˇcn´e, tyto funkce zajiˇst’uj´ı velikost 5
Zn´ amˇejˇs´ı anglick´e pojmenov´ an´ı Event-Flag
18
µC/OS-II
Spr´ ava pamˇeti
alokovan´e pamˇeti. Co vˇsak nezajiˇst’uje, je souvislost oblasti v pamˇeti. Takto alokovan´a oblast m˚ uˇze b´ yt fragmentovan´a, to znamen´a, ˇze oblast nen´ı alokovan´a v jednom kuse, ale je roztrouˇsena po mal´ ych ˇc´astech do voln´ ych oblast´ı. Nav´ıc k tomu, je doba alokace a dealokace nedeterministick´a, pr´avˇe d´ıky fragmentaci. µC/OS-II poskytuje mechanismus zajiˇst’uj´ıc´ı deterministick´ y ˇcas vykon´an´ı funkc´ı alokace a uvolnˇen´ı pamˇeti. Aby toto bylo moˇzn´e, mus´ı b´ yt blok v souvisl´e ˇc´asti pamˇeti. K tomu slouˇz´ı partition obsahuj´ıc´ı bloky o zvolen´e velikosti. Struktura udrˇzuj´ıc´ı informace se naz´ yv´a memory control block. • ukazatel na zaˇc´atek • ukazatel na dalˇs´ı strukturu • velikost bloku • poˇcet blok˚ u • voln´e bloky Na n´asleduj´ıc´ım obr´azku 4.4 vid´ıme n´aznak propojen´ı MCB ve spojen´ı seznamu a tak´e je zde naznaˇceno pouˇzit´ı blok˚ u a zbyl´eho voln´eho m´ısta.
19
µC/OS-II
OSMemFreeList
Spr´ ava pamˇeti
OSMemAddr
OSMemAddr
OSMemFreeList
OSMemFreeList
OSMemBlkSize
OSMemBlkSize
OSMemNBlks
OSMemNBlks
OSMemNFree
OSMemNFree
Partition #2
Partition #1
Partition
Partition
free space free space block
block
Obr´azek 4.4: Alokace blok˚ u pamˇeti
20
5 Pl´anov´an´ı proces˚ u Jedn´a se o z´akladn´ı schopnost jader operaˇcn´ıch syst´em˚ u. V pˇr´ıpadˇe RTOS je d˚ uraz kladen na ˇcasov´a omezen´ı u ´loh. V n´asleduj´ıc´ı ˇc´asti budou vysvˇetleny d˚ uleˇzit´e pojmy a algoritmus pl´anov´an´ı v µC/OS-II. Posl´eze se dostaneme k pokroˇcilejˇs´ım, kter´e jsme implementovali.
5.1
Preemtivn´ı/Nepremtivn´ı pl´ anov´ an´ı
Pokud je povoleno pˇreruˇsen´ı u ´lohy pl´anovaˇcem, naz´ yv´ame pl´anov´an´ı preemtivn´ı. Posl´eze j´ı byl odebr´an ˇcas CPU a byla spuˇstˇena u ´loha s aktu´alnˇe nejvyˇsˇs´ı prioritou. Pˇreruˇsen´e u ´loze je nastaven stav pˇripraven a ˇcek´a, neˇz bude vybr´ana k bˇehu. Preemptivn´ı pl´anov´an´ı je moˇzn´e pouze u preemptivn´ıch u ´loh. U nepreemptivn´ıho pl´anov´an´ı nedoch´az´ı k pˇreruˇsen´ı spuˇstˇen´e u ´lohy pl´anovaˇcem. Nepˇreruˇsen´ı vˇsak m˚ uˇze v´est k chyb´am v ˇcasov´an´ı, kter´e preemptivn´ı pˇr´ıstup odstran´ı, coˇz je nev´ yhodou tohoto pˇr´ıstupu. Takov´ yto u ´hel pohledu je z hlediska pˇr´ıstupu k d˚ uleˇzit´ ym prostˇredk˚ um v´ yhodnˇejˇs´ı pro jednoprocesorov´e RT architektury, protoˇze nevyˇzaduje speci´aln´ı mechanismus pˇr´ıstupu do kritick´e sekce ani pro ˇrazen´ı u ´loh do front.
5.2
Prediktivn´ı synchronizace
T´ım je myˇslena schopnost v´ıce procesov´e komunikace a predikov´an´ı ˇcasu. Kdyˇz proces sd´ıl´ı prostˇredky, je velmi ˇcasto nutn´a synchronizace kv˚ uli integritˇe dat. Kdyˇz nˇejak´ y proces pouˇz´ıv´a sd´ılen´ y zdroj, jin´ y mus´ı ˇcekat. Tento ˇ ˇcas nen´ı pˇredem zn´am´ y. Reˇsen´ım m˚ uˇze b´ yt napˇr´ıklad maxim´aln´ı trv´an´ı semaforu, kter´e ale negarantuje pˇr´ıstup kritick´eho procesu k nekritick´emu. Dalˇs´ı pouˇz´ıvanou technikou je neblokuj´ıc´ı synchronizace vyuˇz´ıvaj´ıc´ı fronty FIFO, t´ım je deterministicky urˇcen nejhorˇs´ı ˇcas pˇr´ıstupu ke sd´ılen´ ym zdroj˚ um.
21
Pl´ anov´an´ı proces˚ u
Situaˇcn´ı model
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 čas uvolnění 3 termín dokončení 10 relativní termín 7 doba odezvy 6 Obr´azek 5.1: Doba d´avky
5.3
Situaˇ cn´ı model
Proces kontroly poˇc´ıtaˇce prov´ad´ı jeden nebo v´ıce kontroln´ıch a monitorovac´ıch funkc´ı. Kaˇzd´a funkce je asociov´ana s jedn´ım nebo v´ıce u ´koly. Nˇekter´e z tˇechto u ´kol˚ u jsou prov´adˇeny v reakci na ud´alosti v zaˇr´ızen´ı nebo sleduj´ı ˇ adn´ syst´em. Ostatn´ı jsou prov´adˇeny v reakci na ud´alosti v jin´ ych u ´kolech. Z´ y zu ´kol˚ u nem˚ uˇze b´ yt proveden pˇred zah´ajen´ım akce, kter´a jej vyvol´av´a. Kaˇzd´ y zu ´kol˚ u mus´ı b´ yt dokonˇcen pˇred dobou, neˇzli je opˇet vyvol´an pl´anovaˇcem.
5.3.1
´ Ulohy
1 ´ Ulohy jsou jednoduch´e programy, kter´e maj´ı CPU v dan´ y ˇcas pro sebe. N´avrhov´ y proces real-time aplikac´ı vyˇzaduje rozdˇelen´ı pr´ace do u ´loh po ˇc´astech probl´emu. Kaˇzd´ yu ´kol m´a svou prioritu vykon´av´an´ı, vlastn´ı hodnoty ´ registr˚ u CPU, vlastn´ı z´asobn´ık. Ulohy b´ yvaj´ı ˇcasto realizov´any nekoneˇcnou smyˇckou a mobou b´ yt v r˚ uzn´ ych stavech, pˇr´ıklad viz obr.4.1.
Instanc´ı u ´lohy je d´avka2 . D´avky potˇrebuj´ı k bˇehu zdroje, jako je napˇr. ˇ CPU, s´ıt’, kritick´a sekce. Casto se hardwarov´e zdroje naz´ yvaj´ı ”procesory”. ˇ Casov´ y pr˚ ubˇeh d´avky je na obr.5.1. Kromˇe programov´eho k´odu ud´alosti, kter´e urˇcuje program´ator, je nutn´a 1 2
v ang. lit. task v ang. lit. oznaˇcov´ ano job
22
Pl´ anov´an´ı proces˚ u
Situaˇcn´ı model
zn´at tyto ˇcasov´e u ´daje u ´lohy τi : ˇ uvolnˇen´ı d´avky pˇripraven´e k bˇehu. • ri - Cas • Ci - Term´ın nejdelˇs´ıho bˇehu u ´lohy • Di - Relativn´ı term´ın dokonˇcen´ı d´avky • Ti - Perioda vol´an´ı u ´lohy (pouze pro periodick´e). Kvalita pl´anov´an´ı u ´loh z´avis´ı na pˇresnosti v´ yˇse napsan´ ych u ´daj˚ u. D´ale bychom mˇeli poˇc´ıtat s d´elkou vykon´av´an´ı operac´ı pˇrepnut´ı kontextu u ´lohy, vol´an´ı jin´ ych obsluˇzn´ ych funkc´ı j´adra.
5.3.2
ˇ e cyklick´ Cistˇ e
Takto nahl´ıˇz´ıme na aplikace, kter´e spouˇst´ı kaˇzdou u ´lohu periodicky. Maj´ı t´emˇeˇr nemˇenn´e poˇzadavky na syst´emov´e prostˇredky, napˇr. digit´aln´ı regul´ator, ˇr´ızen´ı letu a jin´e.
5.3.3
Pˇ rev´ aˇ znˇ e cyklick´ e
Vˇetˇsina u ´loh je spouˇstˇena periodicky. Syst´em reaguje na nˇejak´e extern´ı asynchronn´ı ud´alosti, napˇr. modern´ı avionick´e a ˇr´ıdic´ı syst´emy.
5.3.4
Asynchronn´ı a predikovateln´ e
Poˇzadavky na syst´emov´e prostˇredky se mohou bˇehem po sobˇe jdouc´ıch spuˇstˇen´ı velmi liˇsit, ale maj´ı zn´am´e meze. Vˇetˇsina u ´loh nen´ı periodick´a, napˇr. multimedi´aln´ı komunikace, zpracov´an´ı sign´alu z radaru, sledov´an´ı objekt˚ ua dalˇs´ı.
5.3.5
Asynchronn´ı a nepredikovateln´ e
Pˇrev´aˇznˇe reaguj´ı na asynchronn´ı ud´alosti. Kde obsluha je velmi sloˇzit´a, napˇr. real-time simulace, real-time ˇr´ızen´ı atp. 23
Pl´ anov´an´ı proces˚ u
5.3.6
Obsluha pˇreruˇsen´ı
ˇ Cinitel vyt´ıˇ zen´ı CPU
V tomto bodˇe si uk´aˇzeme horn´ı mez vyuˇzit´ı procesoru. Definujeme (procesorov´e) vyt´ıˇzen´ı, jako ˇcasu procesoru str´aven´ y nad sadou u ´loh. Jin´ ymi slovy je to tak´e jedna m´ınus doba neˇcinnosti procesoru. Tedy CTii je zlomek ˇcasu procesoru str´aven´ y vykon´av´an´ım u ´kolu i pro n u ´kol˚ u, faktorem vyt´ıˇzen´ı je: U=
∑n
Ci i=1 Ti
Pˇrestoˇze faktor vyt´ıˇzen´ı lze zlepˇsit zv´ yˇsen´ım hodnot Ci , nebo sn´ıˇzen´ım hodnoty Ti . Jsme limitov´ani horn´ı poˇzadavkem, aby vˇsechny u ´lohy a jejich lh˚ uty na kritick´e okamˇziky byly splnitel´e. Jak je zaj´ımav´a doln´ı hranice vyt´ıˇzen´ı procesoru nech´am na vaˇsem uv´aˇzen´ı. Naopak velmi zaj´ımav´ ym t´ematem je tedy ”Jak velk´e mus´ı b´ yt vyt´ıˇzen´ı procesoru, aby byla sada u ´loh pl´anovateln´a?”. V pr˚ ubˇehu textu se vr´at´ıme k t´ematu za pouˇzit´ı v´ ysledk˚ u pr´ace vˇenuj´ıc´ı se statick´emu pˇridˇelov´an´ı priorit [CLLiu], k porovn´an´ı nasimulovan´ ych hodnot s teoretick´ ymi hodnotami nˇekter´ ych algoritm˚ u.
5.4
Obsluha pˇ reruˇ sen´ı
Mechanismus pl´anov´an´ı obsluhy pˇreruˇsen´ı je pro RTOS kl´ıˇcovou vlastnost´ı. Pˇreruˇsovac´ı syst´em m´a sv´e vlastn´ı priority, kter´e jsou urˇceny samotn´ ym hardwarem. Priority obsluhy pˇreruˇsen´ı jsou vyˇsˇs´ı neˇz priority uˇzivatelsk´ ych proces˚ u. Pravidla RTOS urˇcuj´ı, ˇze obsluha pˇreruˇsen´ı mus´ı b´ yt tak kr´atk´a, jak je to jen moˇzn´e. Pˇresto spousta zaˇr´ızen´ı potˇrebuje delˇs´ı dobu k prv´adˇen´ı akc´ı po skonˇcen´ı pˇreruˇsen´ı, ty pak pˇrech´azej´ı pod ISR.
5.5
Statick´ e rozvrhov´ an´ı
Nˇekdy oznaˇcovan´e jako offline pl´anov´an´ı. Rozvrˇzen´ı u ´loh zde prob´ıh´a jeˇstˇe pˇred jejich spuˇstˇen´ım. Vyhodnot´ı se jak ˇcasov´e tak i datov´e z´avislosti. Kaˇzd´ y proces je napl´anov´an tak, aby byl vykon´av´an co nejdˇr´ıve. V´ ysledn´ y pl´an b´ yv´a realizov´an listem pl´anu, pˇri jeho tvorbˇe m˚ uˇze b´ yt pouˇzito nejr˚ uznˇejˇs´ıch heuristik. Nev´ yhodou tohoto pˇr´ıstupu, kter´a pˇredpokl´ad´a stejn´e parametry u ´loh a neumoˇzn ˇuje pˇrizp˚ usoben´ı se zmˇen´am.
24
Pl´ anov´an´ı proces˚ u
5.5.1
Dynamick´e rozvrhov´ an´ı
Rate Monotonic
Mechanismus v literatuˇre oznaˇcovan´ y jako Rate Monotonic je statick´ y algoritmus. Vych´az´ı z pˇredpokladu, ˇze u ´lohy volan´e nejˇcastˇeji maj´ı v´ yznamnˇejˇs´ı prioritu. V´ yznamnost priority je tedy pˇr´ımo u ´mˇern´a kmitoˇctu, odpov´ıdaj´ıc´ıho jej´ı periodˇe. Nepˇr´ımo u ´mˇern´a je tedy statick´emu parametru T u ´lohy. Jestliˇze nen´ı mechanismus schopen zajistit pl´anovatelnost u ´loh, jsou ˇreˇsen´ım probl´emu bud’to zmˇeny parametr˚ uu ´loh nebo pouˇzit´ı jin´eho pl´anovac´ıho algoritmu neˇz RM. Zmˇeny parametr˚ uu ´loh vedou na zmˇeny parametr˚ u cel´eho syst´emu, coˇz je vˇetˇsinou nepˇrijateln´e. Pˇr´ıˇcinou selh´an´ı tohoto algoritmu m˚ uˇze b´ yt skuteˇcnost, ˇze mechanismus RM je dobr´ y pro mnoˇzinu u ´loh s parametry D = T a jejichˇz priorita se nemˇen´ı v ˇcase.
5.5.2
Deadline Monotonic
Je mechanismus statick´eho pˇriˇrazov´an´ı priorit nepˇr´ımo u ´mˇernˇe hodnotˇe ˇcasov´e meze oznaˇcovan´ y zkratkou DM, popˇr´ıpadˇe IDA (Inverse Deadline). Vych´az´ı z pˇredpokladu, ˇze u ´lohy s menˇs´ı hodnotou ˇcasov´e meze jsou v´ yznamnˇejˇs´ı. V´ yznamnost u ´lohy je v tomto pˇr´ıpadˇe nepˇr´ımo u ´mˇern´a hodnotˇe statick´eho parametru D u ´lohy. Tento mechanismus je schopn´ y dobˇre pl´anovat i u ´lohy na mnoˇzinˇe D < T , tj. celkovˇe na mnoˇzinˇe D <= T . Tzn., ˇze algoritmem DM jsme schopni napl´anovat i u ´lohy, kter´e nejsou pl´anovateln´e pomoc´ı RM.
5.6
Dynamick´ e rozvrhov´ an´ı
Implementaˇcnˇe sloˇzitˇejˇs´ı je pl´anov´an´ı u ´loh za bˇehu syst´emu. Kdy doch´az´ı k jejich anal´ yz´am a pl´anov´an´ı podle v´ ysledk˚ u, ˇci dle podnˇet˚ u z okol´ı. K pˇrepl´anov´an´ı a zmˇenˇe priorit doch´az´ı podle parametr˚ u algoritm˚ u. V´ yhodou tohoto pˇr´ıstupu je pr´avˇe neust´al´a schopnost se pˇrizp˚ usobovat zmˇen´am. Tyto metody jsou vhodn´e zejm´ena pro aperiodick´e a sporadick´e u ´lohy. Z velmi poˇcetn´e mnoˇziny jsme vybrali jednoduˇsˇs´ı EDF a LLF.
25
Pl´ anov´an´ı proces˚ u
5.6.1
Dynamick´e rozvrhov´ an´ı
Earliest Deadline First
Z posledn´ıho statick´eho pl´anov´an´ı bychom mohli vyvodit prvn´ı dynamick´e. Mechanismus EDF, jak jiˇz n´azev naznaˇcuje, urˇcuje priority nepˇr´ımo u ´mˇernˇe dobˇe zb´ yvaj´ıc´ı v ˇcase t do uplynut´ı ˇcasov´e meze. Garantuje, ˇze v´ yznamnˇejˇs´ı priorita je v ˇcase t pˇriˇrazena tˇem u ´loh´am, kter´ ym zb´ yv´a do uplynut´ı doby splnˇen´ı m´enˇe ˇcasu.
5.6.2
Least Laxity First
Algoritmy pˇrekon´avaj´ıc´ı vlastnosti EDF samozˇrejmˇe existuj´ı, jedn´ım z nich je LLF. Tento algoritmus pˇriˇrazuje priority u ´loh´am podle volnosti u ´lohy v ˇcase t. Dobou volnosti je myˇsleno, na jak dlouho m˚ uˇze b´ yt u ´loha odloˇzena, aniˇz by pˇrekroˇcila svou ˇcasovou mez. Nev´ yhodou je ˇcastˇejˇs´ı pˇrep´ın´an´ı kontextu a vˇetˇs´ı poˇcet preempc´ı.
26
6 Implementace V t´eto kapitole si uk´aˇzeme, jak probˇehlo doimplementov´an´ı vybran´ ych pl´anovac´ıch algoritm˚ u. Snahou bylo co nejv´ıce vyuˇz´ıt st´avaj´ıc´ıho k´odu, velikost rozˇs´ıˇren´ı by mˇela b´ yt rovnˇeˇz pˇrijateln´a. Postupnˇe zde probereme u ´pravy potˇrebn´e pro kompilaci k´odu, pot´e zakl´ad´an´ı u ´loh podle modelu, rozˇs´ıˇren´ı task control blocku. Pot´e se budeme vˇenovat implementaci algoritm˚ u v´ ybˇeru a nakonec zmˇenˇe priorit a n´asledn´emu v´ ybˇeru spuˇstˇen´ı.
6.1
Modifikace zdrojov´ ych k´ od˚ u
Bez z´asahu do origin´aln´ıho k´odu se neobejdeme, avˇsak jedin´e nad ˇc´ım bychom u ´pravy mˇeli prov´adˇet, jsou pouze ˇc´asti k´odu definuj´ıc´ı pˇrekl´adan´e kousky syst´emu. V´ ykonn´ y k´od by mˇel z˚ ustat beze zmˇen a nezavedeme do nˇej chyby vedouc´ı k neoˇcek´avan´emu chov´an´ı. Po anal´ yze zdrojov´ ych k´od˚ u, je evidentn´ı, ˇze budeme modifikovat soubory os core.c a pˇrid´ame konfiguraˇcn´ı makra do os cfg.h. Ide´aln´ı by bylo samozˇrejmˇe nemˇenit p˚ uvodn´ı k´od v˚ ubec, takov´a situace v jazyce C nen´ı moˇzn´a. Potˇrebovali bychom na z´akladˇe definov´an´ı rozˇs´ıˇren´ı v konfiguraci pˇret´ıˇzen´ı p˚ uvodn´ıch funkc´ı, funkcemi vytvoˇren´ ymi. V programovac´ım jazyce C, neexistuje pˇretˇeˇzov´an´ı funkc´ı a metod, proto abychom zachovali k´odovou konvenci, vytvoˇr´ıme dalˇs´ı v souboru os cfg.h makro. #define OS SCH TYPE
/∗ −−−−−−− SCHEDULING MANAGEMENT −−−−−−−−− 0 /∗ Type o f t a s k s c h e d u l i n g (0 −4) /∗ MicroC/OS−I I s c h e d u l i n g (0) /∗ Rate monotonic s c h e d u l i n g (1) /∗ D e a d l i n e monotonic s c h e d u l i n g (2) /∗ Early deadline f i r s t s ch e du l i n g (3) /∗ Least l a x i t y f i r s t scheduling (4)
∗/ ∗/ ∗/ ∗/ ∗/ ∗/ ∗/
Makro definuje volbu typu pl´anov´an´ı. V celku jednoduˇse a elegantnˇe jsme z´ıskali jednoduch´e volby mezi p˚ uvodn´ım pl´anov´an´ım a vlastn´ım rozˇs´ıˇren´ım. Nyn´ı je nutn´e oznaˇcit makrem funkce, kter´e budeme novˇe navrhovat, podm´ınkou zachycenou preprocesorem k podm´ınˇen´emu pˇrekladu. #i f OS SCH TYPE == #ZVOLENY TYP PLANOVANI /∗ z d e bude f u n k c e ∗/ #endif
27
Implementace
Moˇznosti jak vytvoˇrit u ´lohu
Podrobnˇejˇs´ı popis pˇrid´an´ı zaimplementov´an´ı podm´ınek pro kompilaci je souˇc´ast´ı pˇr´ılohy A.
6.2
Moˇ znosti jak vytvoˇ rit u ´ lohu
Z´avislosti na p˚ uvodn´ıch funkc´ıch µC/OS-II m´ame obalen´e podm´ınkami ˇ pˇrekladu. V kapitole 5 jsme si definovali ˇcasov´e parametry u ´loh. Casov´ e parametry si zde nem˚ uˇzeme pˇredstavit jako veliˇcinu ˇcasu, tedy nezad´avaj´ı se napˇr. sekundy ani minuty. V rozˇs´ıˇren´ı je oznaˇcujeme ˇcasov´ ym u ´dajem poˇcet tick˚ u syst´emu. V podstatˇe jsou dva zp˚ usoby jak zav´est parametry do syst´emu a to • napsat nov´e funkce na vytv´aˇren´ı u ´loh s parametry • vyuˇz´ıt OSTaskCreateExt
6.2.1
Vlastn´ı funkce na vytv´ aˇ ren´ı u ´ loh
Napsat nov´e funkce pro vytv´aˇren´ı u ´loh nen´ı nejvhodnˇejˇs´ı ˇreˇsen´ı. Funkce by v podstatˇe kop´ırovali funkˇcnost st´avaj´ıc´ıch, k tomu by zavedli do syst´emu parametry. Jejich pˇrid´an´ı by znamenalo vyˇreˇsen´ı probl´emu kam a jak nejl´epe je zaˇradit. Zda je pˇridat napˇr. jako samostatn´ y seznam podle priorit u ´loh. To by zˇrejmˇe nebylo dobr´e, vedlo by to k zatˇeˇzov´an´ı syst´emu pˇri zmˇenˇe ˇcasov´ ych parametr˚ u ve spojen´ı se zmˇenou priorit. Z tohoto hlediska se jako lepˇs´ı ˇreˇsen´ı jev´ı rozˇs´ıˇren´ı task control blocku.
6.2.2
Rozˇ s´ıˇ ren´ı TCB
K ˇcemu task control block slouˇz´ı, jsme si uvedli v kapitole 4. Jiˇz v p˚ uvodn´ıch k´odech je struktura TCB vytvoˇrena tak, aby byly voleny jednotliv´e ˇc´asti v z´avislosti na konfiguraci v os cfg.h. To mimo jin´e dok´aˇze uspoˇrit znaˇcnou ˇc´ast vyuˇzit´e pamˇeti mikroprocesoru v pˇr´ıpadˇe, ˇze nejsou potˇreba. V tomto pˇr´ıpadˇe by se v´ıce neˇz hodilo pˇridat dalˇs´ı hodnoty do st´avaj´ıc´ıho TCB. 28
Implementace
Moˇznosti jak vytvoˇrit u ´lohu
typedef struct o s t c b { OS STK ∗OSTCBStkPtr ; /∗ P o i n t e r t o c u r r e n t t o p o f s t a c k #i f OS TASK CREATE EXT EN > 0 void ∗OSTCBExtPtr ; /∗ P o i n t e r t o u s e r d e f i n a b l e d a t a f o r TCB e x t e n s i o n OS STK ∗OSTCBStkBottom ; /∗ P o i n t e r t o bottom o f s t a c k INT32U OSTCBStkSize ; /∗ S i z e o f t a s k s t a c k ( i n number o f s t a c k e l e m e n t s ) INT16U OSTCBOpt ; /∗ Task o p t i o n s as p a s s e d by OSTaskCreateExt ( ) INT16U OSTCBId ; /∗ Task ID ( 0 . . 6 5 5 3 5 ) #endif struct o s t c b /∗ P o i n t e r t o struct o s t c b /∗ P o i n t e r t o
∗OSTCBNext ; next TCB i n t h e TCB l i s t ∗OSTCBPrev ; p r e v i o u s TCB i n t h e TCB l i s t
∗/
∗/ ∗/ ∗/ ∗/ ∗/
∗/ ∗/
. . . #i f OS TASK NAME SIZE > 1 INT8U OSTCBTaskName [ OS TASK NAME SIZE ] ; #endif /∗ Extended S c h e d u l i n g RM, DM, EDF, LLF ∗/ #i f OS SCH TYPE != 0 INT16U OSTCBR; /∗ A r r i v a l time o f t a s k ∗/ INT16U OSTCBC; /∗ Maximum time t a s k ∗/ INT16U OSTCBD; /∗ Task D e a d l i n e ∗/ INT16U OSTCBT; /∗ Task P e r i o d ∗/ INT16U OSTCBCur ; /∗ Task c u r r e n t time ∗/ #endif } OS TCB ;
V uk´azce zdrojov´eho k´odu jsou vˇsechny vlastnosti naˇseho modelu, spuˇstˇen´ı u ´lohy, doba opakov´an´ı, maxim´aln´ı doba vykon´av´an´ı a mezn´ı term´ın splnˇen´ı. Pro nˇekter´e algoritmy je vhodn´e udrˇzovat hodnotu, kolik jiˇz u ´loha str´avila ˇcasu vykon´av´an´ım. Vˇsimnˇeme si obalen´ı podm´ınˇen´ ym pˇrekladem, kter´ y tyto informace pˇrid´a v pˇr´ıpadˇe pouˇzit´ı jin´eho neˇz v´ ychoz´ıho pl´anov´an´ı.
29
Implementace
6.2.3
Moˇznosti jak vytvoˇrit u ´lohu
Vyuˇ zit´ı OSTaskCreateExt
Pˇredchoz´ı varianta poˇc´ıt´a s mal´ ym, ale pˇreci jen z´asahem do z´asadn´ı ˇc´asti syst´emu. Tomu jsme se pˇri implementaci rozˇs´ıˇren´ı chtˇeli vyhnout. Z toho d˚ uvodu jsme zvolili variantu ˇc´ıslo dvˇe. Vyuˇz´ıt funkci OSTaskCreateExt. Tato funkce je rozˇs´ıˇren´ım OSTaskCreate pro zaveden´ı u ´loh do µC/OS-II. Vyuˇz´ıt rozˇs´ıˇrenou variantu je doporuˇceno pro pr´aci s bˇeˇzn´ ym syst´emem kv˚ uli vˇetˇs´ı variabilitˇe pˇred´av´an´ı dat u ´loh´am.
6.2.4
Standartn´ı parametry
task pdata
Ukazatel na v´ ykonn´ y k´od u ´lohy. Je ukazatel na data pˇred´avan´e jako parametr u ´loze. Napˇr´ıklad vl´akno obsluhuj´ıc´ı asynchronn´ı s´eriov´ y port, pomoc´ı nˇej m˚ uˇze informovat o rychlosti pˇrenosu, chyb´ach a jin´e obsluze portu. ptos V tomto parametru je ukazatel na vrchol z´asobn´ıku. Do z´asobn´ıku se ukl´adaj´ı lok´aln´ı promˇenn´e, parametry funkc´ı, n´avratov´e adresy a registry CPU pro obnovu po pˇreruˇsen´ı. ˇ ım vyˇsˇs´ı ˇc´ıslo obprio Urˇcuje poˇc´ateˇcn´ı, unik´atn´ı prioritu vl´akna. C´ sahuje, t´ım menˇs´ı prioritu u ´loha m´a. id Oznaˇcen´ı ˇc´ıseln´ ym identifik´atorem vl´aken. pbos Ukazatel na poˇc´atek nebo tak´e dno z´asobn´ıku. stk size Velikost z´asobn´ıku u ´lohy ve zvolen´e ˇs´ıˇrce, pˇri pouˇzit´ı INT8U je to poˇcet byt˚ u, pˇri pouˇzit´ı INT16U se jedn´a o poˇcet dvou bytov´ ych blok˚ u atd. ˇ opt Sestn´acti bitov´e nastaven´ı, z ˇcehoˇz doln´ıch 8 bit˚ u pouˇz´ıv´a µC/OSII a horn´ıch 8 bit˚ u je urˇceno uˇzivateli. pext V t´eto promˇenn´e m˚ uˇzeme m´ıt ukazatel na uˇzivatelskou datovou strukturu. Tomuto pointru bude vˇenov´an n´asleduj´ıc´ı kapitola 6.2.5. Nastaven´ı ˇrady parametr˚ u je z´aleˇzitost´ı konfigurace syst´emu, k tomu dobˇre poslouˇz´ı [MicroII]. Uk´azkov´e pouˇzit´ı metody pro zaveden´ı u ´lohy obsahuje B spolu s nastaven´ım a pouˇzit´ım rozˇs´ıˇren´ı.
30
Implementace
6.2.5
Moˇznosti jak vytvoˇrit u ´lohu
Parametry modelu u ´ lohy
K zaveden´ı parametr˚ u u ´lohy pouˇzijeme parametr pext. Obecnˇe slouˇz´ı k pˇred´av´an´ı uˇzivatelsky definovan´ ych oblast´ı pamˇeti, typicky datov´ ych struktur. Nic n´am tedy nebr´an´ı definovat si vlastn´ı strukturu typedef struct o s s c h e d e x t { INT16U OSTCBStartTask ; INT16U OSTCBMaxTime ; INT16U OSTCBDeadline ; INT16U OSTCBPeriod ; /∗ p a r a m e t e r s i n time ∗/ INT32U OSTCBLastWork ; INT32U OSTCBRan ; INT32U OSTCBStartPeriod ; BOOLEAN OSTCBDeadlineMiss ; INT32U OSTCBFirstDeadline ; INT16U OSTCBLeastLaxity ; /∗ user data ∗/ void ∗ pext ; } OS SCHED EXT ;
V t´eto struktuˇre udrˇzujeme ˇcasov´e u ´daje u ´lohy, k tomu jeˇstˇe st´ale m˚ uˇzeme pˇridat uˇzivatelsk´a data. D˚ uleˇzit´e je donutit uˇzivatele aby ji pouˇzil a zvykl si, ˇ ˇze u ´roveˇ n s uˇzivatelsk´ ymi daty je o jedno zanoˇren´ı d´ale. Casov´ e parametry u ´loh jsou d˚ uleˇzit´e pro samotn´e pl´anovac´ı algoritmy, a proto spol´ehaj´ı na existenci t´eto struktury. D˚ uleˇzit´e je, aby i syst´emov´e u ´lohy obsahovaly dodateˇcn´e ˇcasov´e parametry. V µC/OS-II je obvykle nˇekolik syst´emov´ ych u ´loh. Pro funkˇcnost pl´anov´an´ı je nutn´e urˇcit jakou prioritu pˇriˇradit syst´emov´ ym vl´akn˚ um. Situace se usnadˇ nuje t´ım, ˇze syst´emov´e u ´lohy jsou bud’to nejvyˇsˇs´ı priority, anebo nejniˇzˇs´ı. Uvaˇzme nejprve nejniˇzˇs´ı, vl´akna idle task a stat task. Maj´ı pevnˇe dan´e priority, proto m˚ uˇzeme snadno pˇridat strukturu s ˇcasov´ ymi parametry. Inicializaˇcn´ı funkce mus´ı zjistit dod´an´ı spr´avn´ ych hodnot, odkaz na spr´avn´e TCB u ´lohy je dan´ y syst´emov´ ymi konstantami. INT8U OSSchedExtInit ( void ) { ... ptcb = OSTCBPrioTbl [ OS TASK TMR PRIO ] ; ptcb−>OSTCBExtPtr = ( void ∗ ) pextT ; ... ptcb = OSTCBPrioTbl [ OS TASK IDLE PRIO ] ; ptcb−>OSTCBExtPtr = ( void ∗ ) p e x t I ; ... ptcb = OSTCBPrioTbl [ OS TASK STAT PRIO ] ; ptcb−>OSTCBExtPtr = ( void ∗ ) pextS ; }
31
Implementace
Implementace algoritm˚ u
Funkce pamatuje i na aplikace vyuˇz´ıvaj´ıc´ı u ´lohu syst´emov´eho ˇcasovaˇce, kter´ y bˇeˇz´ı s pˇredem stanovenou prioritou. Aby bylo moˇzn´e ˇcasov´e u ´daje mˇeˇrit, mus´ı b´ yt zprovoznˇen syst´emov´ y ˇcas. Tato ˇc´ast se prov´ad´ı pˇri portaci syst´emu na vybranou architekturu, proto bylo vyuˇzito portace na H8S [PJer].
6.3
Implementace algoritm˚ u
V t´eto f´azi m´ame dle konfiguraˇcn´ıho souboru moˇznost vybrat bud’to pl´anov´an´ı p˚ uvodn´ı, nebo extern´ı. Abychom jej mohli zav´est, bylo nutn´e v souboru ucos ii.c uv´est, o kter´ y soubor se jedn´a. #include
V nataˇzen´em souboru jsou shrom´aˇzdˇeny z´asadn´ı funkˇcn´ı bloky pro rozˇs´ıˇrenou funkci pl´anov´an´ı. Volbou konfigurace o jeho pouˇzit´ı, jsme zajistili zkompilov´an´ı vlastn´ı, t´emˇeˇr totoˇzn´e funkce OS SchedNew(). Jej´ı smysl spoˇc´ıv´a ve vybr´an´ı vl´akna, kter´e je ve stavu ready a m´a nejvˇetˇs´ı prioritu. Celou tuto metodu jsme pˇrepsali do podoby vyuˇz´ıvaj´ıc´ı bloky, pˇrekl´adan´e na z´akladˇe zvolen´eho algoritmu. V´ yˇse uveden´a funkce m´a za u ´kol proj´ıt vˇsechny u ´lohy. Ovˇeˇrit zda jsou ve stavu ready, zda nenesou informaci o usp´an´ı. D´ale mus´ı zajistit aktu´aln´ı ˇcasov´e u ´daje a vybrat nejd˚ uleˇzitˇejˇs´ı u ´lohu. Ke kontrole parametr˚ uu ´loh pouˇzijeme TCB seznam. OS TCB ∗ ptcb ; ptcb = OSTCBList ; while ( ptcb−>OSTCBPrio != OS TASK IDLE PRIO ) { OS ENTER CRITICAL ( ) ; ... ptcb = ptcb−>OSTCBNext ; OS EXIT CRITICAL ( ) ; }
V seznamu proch´az´ıme jednu u ´lohu po droh´e, z bloku na kter´ y m´ame ukazatel pext, naˇcteme potˇrebn´e u ´daje pro vybran´ y algoritmus. V z´asadˇe nen´ı rozd´ıl mezi volbou dynamick´eho nebo statick´eho pl´anov´an´ı, rozd´ıly mezi zvolen´ ym algoritmem jsou v k´odu sp´ıˇse kosmetick´e.
32
Implementace
6.3.1
Implementace algoritm˚ u
Statick´ e pl´ anov´ an´ı
Rate monotonic scheduling a deadline monotonic scheduling je moˇzno pojmout dvˇe zp˚ usoby. Jednou z moˇznost´ı jak vyˇreˇsit v´ ybˇer u ´loh, je seˇrazen´ı u ´loh. A to pˇri prvn´ım vol´an´ı pl´anovaˇce, podle statick´ ych parametr˚ u. Nev´ yhoda tohoto ˇreˇsen´ı je zcela evidentn´ı. Jednak by se jednalo o poˇc´ateˇcn´ı zdrˇzen´ı, d´ıky schopnosti implementovat ˇrad´ıc´ı algoritmy sloˇzitosti N logN , jak´ ym je napˇr. ˇrazen´ı haldou. Ale co je v pˇr´ıpadˇe zaˇr´ızen´ı vyuˇz´ıvaj´ıc´ıch µC/OS-II d˚ uleˇzitˇejˇs´ı, je potˇreba vˇetˇs´ı pamˇeti k seˇrazen´ı priorit. Z tohoto d˚ uvodu bylo pˇrikroˇceno k v´ ybˇeru ready u ´lohy pˇri revizi u ´daj˚ u o pr˚ ubˇehu u ´lohy. // RATE MONOTONIC p a r a m e t e r s i f ( ( ptcb−>OSTCBStat | OS STAT RDY) == OS STAT RDY && ( ptcb−>OSTCBDly == 0 ) ) { i f ( o s t a s k f i r s t == ( void ∗ ) 0 ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } else { i f ( pext−>OSTCBPeriod < f i r s t p e x t −>OSTCBPeriod ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } } } ... // DEADLINE MONOTONIC p a r a m e t e r s i f ( ( ptcb−>OSTCBStat | OS STAT RDY) == OS STAT RDY && ( ptcb−>OSTCBDly == 0 ) ) { i f ( o s t a s k f i r s t == ( void ∗ ) 0 ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } else { i f ( pext−>OSTCBDeadline < f i r s t p e x t −>OSTCBDeadline ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } } }
6.3.2
Dynamick´ e pl´ anov´ an´ı
Dynamick´e pl´anov´an´ı s pouˇzit´ım EDF, ukl´ad´a do parametr˚ u u ´loh mezn´ı ˇcas splnˇen´ı, v z´avislosti na ˇcase. Jeho hodnota se v ˇcase mˇen´ı a spoˇcte se D(t) = T imerun + Dstat T imerun je doba, kdy u ´loha vstupuje do dˇeje a je tedy oznaˇcena jako ready. Nezb´ yv´a n´am tedy neˇz urˇcit dobu vstupu do dˇeje. Nejjednoduˇsˇs´ı a n´ami pouˇzit´ y zp˚ usob je OST IM E + T , kde OS TIME je aktu´aln´ı doba str´aven´a bˇehem syst´emu a k n´ı pˇripoˇcten´a perioda. Abychom se nepˇripravili o prvn´ı periodu bˇehu u ´loh, ˇrekneme, ˇze prvn´ı doba vstupu, je 33
Implementace
Implementace algoritm˚ u
pr´avˇe ta doba, kdy se ji pokouˇs´ıme poprv´e urˇcit. Abychom co nejm´enˇe omezili rychlost syst´emu, jsou ˇcasov´e parametry dopoˇcteny tˇesnˇe pˇred porovn´an´ım. // EARLY DEADLINE FIRST p a r a m e t e r s i f ( ( ptcb−>OSTCBStat | OS STAT RDY) == OS STAT RDY && ( ptcb−>OSTCBDly == 0 ) ) { i f ( o s t a s k f i r s t == ( void ∗ ) 0 ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } else { i f ( pext−>OSTCBFirstDeadline < f i r s t p e x t −>OSTCBFirstDeadline ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } } } ... //LEAST LAXITY FIRST p a r a m e t e r s pext−>OSTCBLeastLaxity = pext−>OSTCBLeastLaxity − OSTime − pext−>OSTCBRan ; i f ( ( ptcb−>OSTCBStat | OS STAT RDY) == OS STAT RDY && ( ptcb−>OSTCBDly == 0 ) ) { i f ( o s t a s k f i r s t == ( void ∗ ) 0 ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } else { i f ( pext−>OSTCBLeastLaxity < f i r s t p e x t −>OSTCBLeastLaxity ) { o s t a s k f i r s t = ptcb ; f i r s t p e x t = (OS SCHED EXT ∗ ) ( o s t a s k f i r s t −>OSTCBExtPtr ) ; } } }
Obdobnˇe se urˇcuj´ı hodnoty pro algoritmus LLF L(t) = D(t) − C(t). Hodnotu deadline v z´avislosti na ˇcase um´ıme urˇcit, chyb´ı n´am tedy doba, jak dlouho uˇz u ´loha zpracov´avala sv˚ uj u ´kol. To provedeme odeˇcten´ım aktu´aln´ı doby bˇehu syst´emu od doby, kdy bylo vl´akno pˇreruˇseno. Jak je toto prov´adˇeno, bude pops´ano v kapitole 6.4. Nav´ıc jsme uˇzivateli dali moˇznost zjistit, zda nˇekter´a u ´loha nestihla svou deadline.
6.3.3
Zmˇ ena priorit
Nyn´ı jsme ve f´azi, kdy um´ıme zjistit parametry u ´loh a kdy podle nich jsme schopni urˇcit u ´lohu ke spuˇstˇen´ı. Pr´avˇe v t´eto ˇc´asti zpracov´an´ı jsme schopni dodat uˇzivateli informace o minut´ı deadline. Zn´ame totiˇz posledn´ı u ´lohu ve stavu ready a i tu kterou se chyst´ame spustit. i f ( OSTime == 0 ) { OSTCBHighRdy = o s t a s k f i r s t ; OSPrioHighRdy = o s t a s k f i r s t −>OSTCBPrio ; } else {
34
Implementace
Sbˇer parametr˚ uu ´loh
OS SchedDataEnd ( OSTCBHighRdy ) ; OSTCBHighRdy = o s t a s k f i r s t ; OSPrioHighRdy = o s t a s k f i r s t −>OSTCBPrio ;
} OS SchedDataStart ( OSTCBHighRdy ) ;
void OS SchedDataStart ( OS TCB ∗HighRdy ) { OS SCHED EXT ∗ pext ; HighRdy−>OSTCBStat |= OS STAT RDY ; p e x t = HighRdy−>OSTCBExtPtr ; pext−>OSTCBLastWork = OSTime ; } void OS SchedDataEnd ( OS TCB ∗HighRdy ) { OS SCHED EXT ∗ pext ; p e x t = HighRdy−>OSTCBExtPtr ; pext−>OSTCBRan = OSTime − pext−>OSTCBLastWork ; i f ( OSTime > pext−>OSTCBFirstDeadline ) { pext−>OSTCBDeadlineMiss = OS TRUE ; } }
HighRdy−>OSTCBStat |= OS STAT SUSPEND ;
Stejnˇe jako v pˇr´ıpadˇe statick´eho, tak pˇri pouˇzit´ı dynamick´eho pl´anov´an´ı je situace jasnˇe d´ana. Nen´ı tˇreba mˇenit priority v syst´emu. Pˇri pr˚ uchodu TCB listem vyhled´ame nejmenˇs´ı hodnotu D(t) nebo v pˇr´ıpadˇe LLF L(t). Nam´ısto aby byla priorita aktu´alnˇe nejd˚ uleˇzitˇejˇs´ı u ´lohy vybr´ana pomoc´ı mapy priorit, vybranou prioritu nastav´ıme do glob´aln´ı promˇenn´e OSPrioHighRdy.
6.4
Sbˇ er parametr˚ uu ´ loh
Zmˇenit dle priority u ´lohu um´ıme, zb´ yv´a urˇcit data, podle kter´ ych se tento proces dˇeje. Z´akladn´ı parametry, tedy periodu spouˇstˇen´ı, vstup do periody, mezn´ı term´ın a maxim´aln´ı vykon´av´an´ı u ´lohy, pro statick´e i dynamick´e algoritmy mus´ı zadat v´ yvoj´aˇr aplikace. K tomuto u ´ˇcelu byla vytvoˇrena inicializaˇcn´ı funkce. Jej´ı v´ yhodou je hlavnˇe odpadnut´ı vynulov´an´ı alokovan´e pamˇeti, na kterou v´ yvoj´aˇri ˇcasto zapom´ınaj´ı. s t a t i c void OS SchedPext ( OS SCHED EXT ∗ p e x t , INT16U s t a r t T a s k , INT16U maxTime , INT16U d e a d l i n e , INT16U p e r i o d ) ;
Jeden z nejzaj´ımavˇejˇs´ıch u ´kol˚ u t´eto pr´ace, je sbˇer informac´ı pro pl´anovac´ı algoritmy. Do jak´e struktury jsou data sb´ır´ana, jsme si uvedli v kapitole 35
Implementace
Sbˇer parametr˚ uu ´loh
6.2.5. Tato struktura se mus´ı pr˚ ubˇeˇznˇe aktualizovat pro kaˇzd´e vl´akno. Je tedy zˇrejm´e, ˇze se data budou sb´ırat pˇri pr´aci u ´lohy. Samozˇrejmˇe bychom mohli d´at toto privilegium uˇzivateli, to by zp˚ usobilo nˇekolik probl´em˚ u, jednak nen´ı jist´e, ˇze by uˇzivatel spr´avnˇe aktualizoval u ´daje. A hlavnˇe co je d˚ uleˇzitˇejˇs´ı, uˇzivatelsk´a u ´loha m˚ uˇze b´ yt n´ahodnˇe pˇreruˇsena. Pokud bychom napˇr. sb´ırali data na zaˇc´atku, uprostˇred a na konci smyˇcky. Dost´avali bychom jen statistick´e u ´daje, ˇc´ım d´ele by syst´em fungoval, t´ım lepˇs´ı bychom z´ıskali. Aˇc by se jednalo o velmi jednoduchou implementaci, byla by velmi nevhodn´a. Lepˇs´ı volbou je implementace do syst´emu. Vˇsimnˇeme si, ˇze po napl´anov´an´ı u ´loh, doch´az´ı k pˇrepnut´ı kontextu procesoru. To je tak´e ve chv´ıli, kdy v´ıme, jak´a u ´loha pracovala a jak´a bude pracovat. Zde m´ame bud’to variantu bez z´asahu do souboru os core.c nebo s mal´ ym z´asahem. Totiˇz pˇri portaci µC/OS-II se mus´ı vytv´aˇret funkce OSIntCtxSw, ta je obvykle naps´ana v jazyce symbolick´ ych adres. Slouˇz´ı k vytvoˇren´ı softwarov´eho pˇreruˇsen´ı pro pˇrepnut´ı u ´loh. Spolu s n´ı se vytv´aˇr´ı prototypy dalˇs´ıch deseti uˇzivatelsk´ ych funkc´ı, z nichˇz OSTaskSwHook je vol´ana z OSIntCtxSw. Podm´ınkou by tedy bylo, aby v´ yvoj´aˇr aplikace vˇzdy do dan´e funkce um´ıstil naˇsi OS ShedDataStart, kter´a by uloˇzila dynamick´e parametry pˇreruˇsen´e u ´lohy. Nov´e u ´loze by se poˇc´ateˇcn´ı hodnoty nemohli nastavit a museli bychom v jedn´e funkci zjistit prioritu nov´e u ´lohy a j´ı nastavit poˇc´ateˇcn´ı parametry. Hlavn´ı nev´ yhodou by byla nutnost z´asahu uˇzivatele. Naproti tomu staˇc´ı m´ırnˇe upravit soubor os core.c, pˇresnˇeji do funkce OS Sched a tak´e do funkce ukonˇcen´ı obsluhy pˇreruˇsen´ı OSIntExit, pˇrid´an´ım podm´ınky pro pˇreklad pouˇzit´ı dynamick´eho pl´anov´an´ı. Podrobnosti modifikace viz pˇr´ıloha A. #i f OS SCH TYPE == 0 OSTCBHighRdy = OSTCBPrioTbl [ OSPrioHighRdy ] ; #e l s e OS SchedDataEnd ( OSTCBHighRdy ) ; OSTCBHighRdy = OSTCBPrioTbl [ OSPrioHighRdy ] ; OS SchedDataStart ( OSTCBHighRdy ) ; #endif
D˚ uleˇzit´e pro sbˇer dat je abychom neuˇz´ıvali oper´ator˚ u n´asoben´ı a dˇelen´ı, aˇc mikroprocesory ˇc´ım d´al ˇcastˇeji obsahuj´ı sofistikovanˇejˇs´ı aritmeticko-logick´e jednotky, patˇr´ı st´ale k nejpomaleji prov´adˇen´ ym operac´ım. Kde by n´as to zˇrejmˇe velmi sv´adˇelo, jsou v´ ypoˇcty aktu´aln´ıch deadline a period, respektive vstup˚ uu ´loh do dˇeje. Napˇr´ıklad vypoˇcten´ı aktu´aln´ı deadline da ct = pext− > OST CBP eriodStart+pext− > OST CBDeadline). Bylo tedy nutn´e zaˇr´ıdit, aby se vˇzdy spr´avnˇe dopoˇcetl zaˇc´atek periody a to i v pˇr´ıpadˇe, ˇze dojde k 36
Implementace
Sbˇer parametr˚ uu ´loh
Start scheduling
find first task by time parameters
load tcb_n
stora time parameters
tcb_n_priority != OS_TASK_IDLE_PRIO
+
-
set highest_priority
End scheduling
Obr´azek 6.1: Pohled na implementovan´e pl´anov´an´ı pˇrekroˇcen´ı deadline. N´asleduj´ıc´ı v´ yvojov´ y diagram na obr.6.1 statick´eho pl´anov´an´ı ukazuje cel´ y cyklus.
37
7 Zhodnocen´ı ˇreˇsen´ı Jeˇstˇe neˇz se pˇresuneme k porovn´an´ı pr´ace, ukaˇzme si jednoduch´ y pˇr´ıklad. Uvaˇzme pl´anov´an´ı Rate Monotocnic mechanismem, pouh´e ˇctyˇri u ´lohy s parametry prvn´ı u ´lohy τ0 (r0 , C0 , D0 , T0 ) = τ0 (0, 3, 5, 20), druh´e τ1 (r1 , C1 , D1 , T1 ) = τ1 (0, 3, 7, 12), tˇret´ı τ2 (r2 , C2 , D2 , T2 ) = τ2 (0, 4, 10, 10) a ˇctvrt´e τ3 (r3 , C3 , D3 , T3 ) = τ3 (0, 3, 20, 20). Podle definice RM budou u ´lohy seˇrazeny prioritnˇe od nejv´ yznamˇejˇs´ı po nejm´enˇe d˚ uleˇzitou v poˇrad´ı τ2 , τ1 , τ0 , τ3 nebo τ2 , τ1 , τ3 , τ0 . Pl´an generovan´ y na z´akladˇe priorit je vyobrazen na obr´azku 7.1, kde v ˇcase t = 0 vzniknout poˇzadavky na souˇcasn´e vyvol´an´ı vˇsech ˇctyˇr u ´loh. Protoˇze u ´loze τ2 je pˇriˇrazena nejv´ yznamnˇejˇs´ı priorita, pobˇeˇz´ı jako prvn´ı pr´avˇe tato u ´loha. Zbyl´e u ´lohy pˇrejdou do ˇcekaj´ıc´ıho stavu. Po dokonˇcen´ı u ´lohy τ2 v ˇcase t = 0 + C2 = 4 m˚ uˇze zaˇc´ıt bˇeˇzet u ´loha τ1 , kter´a ze zb´ yvaj´ıc´ıch m´a nejvyˇsˇs´ı prioritu. Pot´e jiˇz m˚ uˇze bˇeˇzet u ´loha τ3 nebo τ0 . Avˇsak bez ohledu na poˇrad´ı posledn´ıch dvou jmenovan´ ych u ´loh, pˇrekroˇc´ı τ0 svou ˇcasovou mez jiˇz v ˇcase t = 5, zat´ımco spuˇstˇen´ı u ´lohy je podle pˇriˇrazen´ ych priorit mechanismem RM nejdˇr´ıve v ˇcase t = 7. V pˇr´ıpadech nen´ı-li mechanismus RM schopen zajistit pl´anovatelnost mnoˇziny u ´loh RTOS, jak je tomu v´ yˇse, vznik´a probl´em ˇreˇsiteln´ y dvˇema z´akladn´ımi zp˚ usoby. Prvn´ı zp˚ usob spoˇc´ıv´a ve zmˇenˇe parametr˚ u RT u ´loh s c´ılem zajistit pl´anovatelnost dan´e mnoˇziny s modifikovan´ ymi parametry. Tento zp˚ usob je vˇsak nepˇrijateln´ y, jednali bychom zcela nelogicky proti p˚ uvodn´ım poˇzadavk˚ um na takov´ yto syst´em. Zcela jistˇe by hrozilo jejich nesplnˇen´ı a hodl´am si tvrdit i dost nevyzpytateln´e chov´an´ı. Druh´e ˇreˇsen´ı spoˇc´ıv´a v pouˇzit´ı jin´eho zp˚ usobu pl´anov´an´ı, algoritmus RM optim´alnˇe pl´anuje na mnoˇzinˇe u ´loh RT, mezi jejichˇz parametry plat´ı vztah D = T a jejichˇz priorita se v ˇcase nemˇen´ı.
r D
Ƭ3 Ƭ2 Ƭ1 Ƭ4 0
5
10
15
20
25
30
35
40
Obr´azek 7.1: RM pl´an
38
t
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
r D
Ƭ1 Ƭ2 Ƭ3 Ƭ4 0
5
10
15
20
25
30
35
40
t
Obr´azek 7.2: DM pl´an Kdyˇz bychom na uveden´e u ´lohy vzaly mechanismus DM, zjistili bychom, ˇze jsou j´ım pl´anovateln´e. Tento algoritmus je pro n´as vˇsak okrajovou z´aleˇzitost´ı, uvedeme alespoˇ n v´ ysledn´ y pl´an na 7.1. Zopakujme alespoˇ n, ˇze pl´anov´an´ı je nepˇr´ımo u ´mˇern´e parametru D. Nemˇen ˇme podm´ınky a napl´anujme u ´lohy pomoc´ı algoritmu EDF. Tento zp˚ usob pl´anov´an´ı pˇrep´ın´a mezi u ´lohami pˇr´ımo u ´mˇernˇe ˇcasu zb´ yvaj´ıc´ımu do deadline. Vynechme zdlouhav´ y a jednoduch´ y v´ ypoˇcet aktu´aln´ıch priorit kaˇzd´e u ´lohy a v´ ysledn´e hodnoty ukazuje tabulka 7.Tabulka EDF pl´an
τ0 τ1 τ2 τ3
r C D T 0 3 5 20 0 3 7 12 0 4 10 10 0 3 20 20
τ0 τ1 τ2 τ3
t 9 • 415 • 39 • 11 • 211
7.1
10 414 38 210 110
t 0 1 2 • 15 14 13 • 27 26 25 • 310 39 38 • 420 419 418 Tabulka EDF 11 413 37 29 19
12 13 412 411 26 15 38 37 18 27 Tabulka
14 410 14 36 26 EDF
3 421 14 27 317 pl´an
4 420 13 26 316
5 419 12 25 315
6 418 312 14 214
7 417 311 13 213
8 416 310 12 212
15 39 115 25 45 pl´an
16 28 314 14 424
17 27 313 13 423
18 26 312 12 422
19 25 311 11 421
20 14 310 210 420
Testovac´ı u ´ lohy
Pro u ´ˇcely testov´an´ı vznikly modelov´e u ´lohy. Nevykon´avaj´ı ˇz´adnou funkci, pouze demonstruj´ı okolnosti bˇehu syst´emu. Mohli bychom si pˇredstavit, ˇze 39
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
´ simulujeme interakci ˇctyˇr u ´loh. Uloha tedy nevykon´av´a nic, na zaˇc´atku si inicializuje ˇcasov´e parametry. Spust´ı ˇcek´an´ı podle stanoven´e maxim´aln´ı doby bˇehu. Pot´e odeˇcte u ´daje o skonˇcen´ı a pˇred´a ˇr´ızen´ı OS. Vytv´aˇren´ı dalˇs´ıch deadline a zaˇc´atk˚ u period jsou v rozˇs´ıˇren´ı z´aleˇzitost´ı pl´anovaˇce. Pouze pro p˚ uvodn´ı ˇreˇsen´ı se mus´ı u ´lohy transformovat do podoby n´asleduj´ıc´ı void t a s k 0 ( void ∗ pdata ) { OS SCHED EXT ∗ pext ; for ( ; ; ) { p e x t = (OS SCHED EXT ∗ ) pdata ; OS SchedDataStart ( OSTCBHighRdy ) ; pext−>OSTCBFirstDeadline = pext−>OSTCBStartPeriod + Puts ( STRING MESSAGE ) ;
pext−>OSTCBDeadline ;
i f ( pext−>OSTCBDeadlineMiss == OS TRUE) { Puts ( STRING MESSAGE ) ; } else { Puts ( STRING MESSAGE ) ; } while ( pext−>OSTCBRan <= pext−>OSTCBMaxTime ) { } pext−>OSTCBRan = 0 ; i f ( pext−>OSTCBFirstDeadline < OSTime ) { pext−>OSTCBFirstDeadline = ( INT32U ) pext−>OSTCBStartPeriod + pext−>OSTCBDeadline ; } while ( ( pext−>OSTCBStartPeriod )< OSTime ) { pext−>OSTCBStartPeriod = pext−>OSTCBStartPeriod + ( INT32U ) pext−>OSTCBPeriod ; } OS SchedDataEnd ( OSTCBHighRdy ) ; OSTimeDly ( pext−>OSTCBStartPeriod − OSTime ) ; / }
}
Abychom mohli otestovat funkci origin´aln´ıho pl´anovaˇce, museli jsme implementovat do uˇzivatelsk´e funkce App TimeTickHook() zp˚ usob probouzen´ı vl´aken pro periodick´e u ´lohy. Ten kontroluje dobu uplynut´ı u ´lohy od usp´an´ı. OS TCB ∗ ptcb ; ptcb = OSTCBList ; while ( ptcb−>OSTCBPrio != OS TASK IDLE PRIO ) { OS ENTER CRITICAL ( ) ; p e x t = (OS SCHED EXT ∗ ) ptcb−>OSTCBExtPtr ; i f ( pext−>OSTCBStartPeriod <= OSTime && ptcb−>OSTCBDly == 0 ) { OSTaskResume ( ptcb−>OSTCBPrio ) ; } ptcb = ptcb−>OSTCBNext ; OS EXIT CRITICAL ( ) ;
40
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
}
Na pˇr´ıkladu pouˇzit´ı standardn´ıho pl´anovaˇce, je v dobˇe OSTime = 18 m´ame posledn´ı tick na vykon´an´ı 3 tickov´e u ´lohy. Po dokonˇcen´ı ozn´am´ıme miss. V dalˇs´ım pr˚ ubˇehu se hodnoty miss objevuj´ı ˇc´ım d´al ˇcastˇeji. V testov´an´ı jsme pouˇzili schopnost reagovat na minut´ı kritick´e meze a simulovali jsme jej´ı opravu. Aby se musela kontrolovat po kaˇzd´em spuˇstˇen´ı u ´lohy znovu. Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start
− > Task − > Task − > Task − > Task − > Task − > MISS − > Task − > Task − > MISS − > Task − > MISS − > Task − > MISS − > Task − > Task − > Task − > Task − > Task − > MISS − > Task − > Task − > Task − > MISS − > Task − > MISS − > Task − > Task − > Task − > Task − > Task − > MISS − > Task − > MISS − > Task − > Task − > MISS − > Task − > Task − > MISS − > Task − > Task − > Task − > Task − > Task − > MISS − > Task − > MISS
2 3 1 2 0
OSTIME OSTIME OSTIME OSTIME OSTIME
=Hx0AE =0x0B2 =0x0B8 =0x0BB =0x0BD
1 2
OSTIME =0x0C5 OSTIME =0x0C9
3
OSTIME =0x0CD
0
OSTIME =0x0D2
1 2 1 2 0
OSTIME OSTIME OSTIME OSTIME OSTIME
3 1 2
OSTIME =0x0EC OSTIME =0x0F1 OSTIME =0x0F4
0
OSTIME =0x0FC
1 2 3 1 2
OSTIME OSTIME OSTIME OSTIME OSTIME
0
OSTIME =0x111
1 3
OSTIME =0x119 OSTIME =0x11C
2 0
OSTIME =0x11D OSTIME =0x126
1 2 3 1 2
OSTIME OSTIME OSTIME OSTIME OSTIME
0
OSTIME =0x13B
=0x0D5 =0x0D8 =0x0E2 =0x0E5 =0x0E7
=0x0FF =0x102 =0x106 =0x10C =0x10F
=0x129 =0x12C =0x135 =0x136 =0x139
41
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
Uveden´e poˇc´ateˇcn´ı hodnoty staˇc´ı k usouzen´ı, ˇze p˚ uvodn´ı pl´anov´an´ı nijak neusnadˇ nuje pr´aci v´ yvoj´aˇre. Vˇsechny parametry mus´ı dobˇre zv´aˇzit a s´am urˇcit priority v posloupnosti, tak aby se vl´akna spr´avnˇe vykon´avala. Na dalˇs´ı uk´azce viz obr.7.3 vid´ıme selh´an´ı statick´ ych algoritm˚ u. Vezmˇeme parametry u ´loh z u ´vodn´ıho pˇr´ıkladu. Teoreticky jsme si uk´azali, ˇze statick´e algoritmy selˇzou. Aˇz algoritmus EDF je schopn´ y vybrat vhodnou u ´lohu a pl´an dokonˇcit bez ohroˇzen´ı stability celku. Priority jsou pro u ´lohy τ0 aˇz τ3 zad´av´any v poˇrad´ı 11a14. Na p˚ uvodn´ım algoritmu nem´ame ˇsanci ze syst´emu zjistit, zda se u ´loha stihla vykonat v ˇcas. Leda bychom si zavedli vlastn´ı poˇc´ıt´an´ı v task´ach. Z tohoto d˚ uvodu bylo umoˇznˇeno udrˇzovat u ´daje o u ´loze i standardn´ı implementaci. Nav´ıc spouˇstˇet u ´lohy periodicky znamen´a, aby si uˇzivatel nastavil na jak dlouho je u ´loha suspendov´ana. Proto jsme pro otestov´an´ı p˚ uvodn´ıho pl´anov´an´ı doimplementovali uˇzivatelskou metodu OSTaskIdleHook(). V n´ıˇz jsme u ´lohy po uplynut´ı usp´an´ı opˇet aktivovali. Mal´a zmˇena ve v´ ybˇeru a hned jsme schopni splnit mnohem vˇetˇs´ı ˇc´ast u ´loh. I pˇresto vˇsak doch´az´ı k situac´ım, ˇze nejsme schopni zaruˇcit splnˇen´ı u ´loh. V n´asleduj´ıc´ı ˇc´asti na obr.7.4 m´ame porovn´an´ı implementovan´ ych dynamick´ ych algoritm˚ u. Na prvn´ım dynamick´em algoritmu jsme si ovˇeˇrili, zda jsme teoretick´e hodnoty spoˇcetli do tabulky 7.Tabulka EDF pl´an spr´avnˇe. Na druh´em vid´ıme jedineˇcnost pˇr´ıstupu ke zpracov´an´ı a ˇcastˇejˇs´ı pˇrep´ın´an´ı kontextu mezi u ´lohami. Algoritmus least laxity first vyb´ır´a u ´lohy ve spr´avn´em poˇrad´ı, tak aby nedoch´azelo k miss. Kv˚ uli ˇcast´emu pˇrep´ın´an´ı kontextu algoritmu LLF, museli b´ yt vstupy pro simul´ator doplnˇeny i do souboru s rozˇs´ıˇren´ım. Aˇckoli jsme poˇc´ateˇcn´ı hodnoty spoˇcetli spr´avnˇe, doch´az´ı k minut´ı deadline u obou algoritm˚ u, kter´e nejsme t´emˇeˇr schopni odhalit jinak, neˇzli simulov´an´ım. Zv´ yˇse uveden´ ych v´ ystup˚ u vypl´ yvaj´ı n´asleduj´ıc´ı povinnosti v´ yvoj´aˇre. • Dokonale analyzovat pouˇzitou harwarovou platformu • Analyzovat ˇcasov´e parametry vytvoˇren´ ych u ´loh • Ovˇeˇrit simulacemi funkˇcnost • Upravit kritick´a m´ısta • Pˇr´ıpadnˇe schopnˇe reagovat na kritick´a m´ısta 42
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
Rate Monotonic scheduling Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start
- > Task - > MISS - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS
0
OSTIME =0x0AF
1
OSTIME =0x0B0
2 1
OSTIME =0x0B4 OSTIME =0x0BC
2 3 2 1
OSTIME OSTIME OSTIME OSTIME
0
OSTIME =0x0CF
2 3 1 2 1 2 0
OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME
=0x0D2 =0x0D7 =0x0D8 =0x0DC =0x0E4 =0x0E6 =0x0EB
2 1 3 2 0
OSTIME OSTIME OSTIME OSTIME OSTIME
=0x0F0 =0x0F4 =0x0F7 =0x0FA =0x0FF
1 2 1 2 3 2 1
OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME
=0x100 =0x104 =0x10C =0x10E =0x113 =0x118 =0x11C
0
OSTIME =0x11F
2 3 1
OSTIME =0x122 OSTIME =0x127 OSTIME =0x128
2 1
OSTIME =0x12C OSTIME =0x134
2 0
OSTIME =0x136 OSTIME =0x13B
Deadline Monotonic scheduling Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start
=0x0BE =0x0C3 =0x0C8 =0x0CC
Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start
- > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > Task - > Task - > Task
Obr´azek 7.3: Statick´e algoritmy
43
0 1 3 2 0 1 2 1 2 0 3 1 2 1 0 2 3 1
OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME
=0x0A0 =0x0A8 =0x0AB =0x0AC =0x0B4 =0x0B7 =0x0BA =0x0C3 =0x0C6 =0x0C8 =0x0CD =0x0CF =0x0D3 =0x0DB =0x0DC =0x0E1 =0x0E8 =0x0EA
2 0 1
OSTIME =0x0ED OSTIME =0x0F0 OSTIME =0x0F6
2 1
OSTIME =0x0FA OSTIME =0x102
0 2 3 1
OSTIME OSTIME OSTIME OSTIME
2 0 1
OSTIME =0x114 OSTIME =0x118 OSTIME =0x11D
3 2 1
OSTIME =0x120 OSTIME =0x121 OSTIME =0x129
0 2 1
OSTIME =0x12C OSTIME =0x12F OSTIME =0x138
2 3 0 1 2
OSTIME OSTIME OSTIME OSTIME OSTIME
=0x104 =0x108 =0x10C =0x111
=0x13B =0x13F =0x140 =0x144 =0x147
Zhodnocen´ı ˇreˇsen´ı
Testovac´ı u ´lohy
Early Deadline First Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start Start
- > Task - > MISS - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > Task - > MISS - > Task - > MISS - > Task - > Task - > MISS
Least Laxity First
1
OSTIME =0x0AF
Start
2 0
OSTIME =0x0B9 OSTIME =0x0BA
Start Start
1
OSTIME =0x0BD
3 1
OSTIME =0x0C0 OSTIME =0x0C9
Start Start Start Start
2 0
OSTIME =0x0CC OSTIME =0x0CE
3 1
OSTIME =0x0D4 OSTIME =0x0D5
2 1
OSTIME =0x0DA OSTIME =0x0E1
0
OSTIME =0x0E4
2 3 1
OSTIME =0x0E7 OSTIME =0x0EB OSTIME =0x0ED
2 0
OSTIME =0x0F7 OSTIME =0x0F8
1
OSTIME =0x0FB
3 1
OSTIME =0x102 OSTIME =0x107
2 0
OSTIME =0x109 OSTIME =0x10C
3 1
OSTIME =0x116 OSTIME =0x119
2 0
OSTIME =0x11C OSTIME =0x120
1
OSTIME =0x125
2 1
OSTIME =0x129 OSTIME =0x131
Back Start Back Start Start Start Start Start Start Start Back Back Start Back Start Start Start Back Start Start Start Start Start Back Start Start Start Back Start Start Start Start Start Start Back Start
- > Task 1 - > MISS - > Task 2 - > Task 1 - > MISS - > Task 0 - > Task 2 - > Task 3 - > Task 1 - > MISS -> Task 3 - > Task 2 -> Task 3 - > Task 0 - > Task 1 - > MISS - > Task 2 - > Task 3 - > Task 1 - > Task 2 - > Task 0 -> Task 2 -> Task 3 - > Task 1 -> Task 3 - > Task 2 - > Task 1 - > Task 0 -> Task 1 - > Task 2 - > Task 3 - > Task 1 - > Task 2 - > Task 0 -> Task 2 - > Task 1 - > Task 3 - > Task 2 -> Task 3 - > Task 1 - > Task 0 - > Task 2 - > Task 1 - > Task 3 - > Task 2 -> Task 3 - > Task 0 - > MISS
Obr´azek 7.4: Dynamick´e algoritmy
44
OSTIME =0x0A7 OSTIME =0x0AB OSTIME =0x0B3 OSTIME OSTIME OSTIME OSTIME
=0x0B6 =0x0B9 =0x0BD =0x0BF
OSTIME =0x0C3 OSTIME =0x0CA OSTIME =0x0CD OSTIME OSTIME OSTIME OSTIME OSTIME
=0x0D0 =0x0D8 =0x0D9 =0x0DC =0x0DE
OSTIME =0x0E5 OSTIME =0x0E9 OSTIME =0x0F1 OSTIME =0x0F2 OSTIME OSTIME OSTIME OSTIME OSTIME
=0x0F7 =0x0FB =0x100 =0x103 =0x106
OSTIME =0x10C OSTIME =0x10F OSTIME =0x110 OSTIME OSTIME OSTIME OSTIME OSTIME OSTIME
=0x118 =0x11B =0x11E =0x124 =0x127 =0x128
OSTIME =0x12F
Zhodnocen´ı ˇreˇsen´ı
Nev´yhody ˇreˇsen´ı
• !Nezapomenout na pˇreruˇsen´ı, kter´e kritick´e hodnoty jeˇstˇe zhorˇs´ı τ0 τ1 τ2 τ3 ORIG RM DM EDF LLF
(0, 1, 25, 50) (0, 2, 40, 50) (0, 1, 35, 50) (0, 1, 30, 50) OK OK OK OK OK
(0, 1, 10, 20) (0, 8, 25, 50) (0, 2, 10, 18) (0, 12, 40, 50) (0, 1, 10, 10) (0, 6, 35, 50) (0, 2, 18, 20) (0, 4, 30, 50) MISS MISS OK MISS OK OK OK OK OK OK Vybran´e u ´lohy
(0, 13, 42, 45) (0, 12, 47, 50) (0, 12, 47, 48) (0, 11, 47, 47) MISS MISS MISS MISS MISS
Naj´ıt hranici kde jeden algoritmus pˇrest´av´a fungovat a jin´ y to jeˇstˇe zvl´adne, se povedlo jen pro statick´ y rate monotonic. D´ıky ˇrazen´ı podle period, nen´ı ani u velmi prost´ ych u ´loh zajistit spr´avn´ y bˇeh. Pro zb´ yvaj´ıc´ı algoritmy je situace mnohem lepˇs´ı, z pozorov´an´ı v tabulce 7.1.Vybran´e u ´lohy lze usoudit, C ˇze u ´spˇeˇsnost roste s klesaj´ıc´ım pomˇerem CT a D . To vˇse je nav´ıc ovlivnˇeno ∑ poˇctem u ´loh. Za jistou mez pl´anovatelnosti bychom mohli oznaˇcit Ci ≤ Dmin . Vˇsechny simulovan´e u ´lohy prob´ıhaly alespoˇ n do ˇcasu OSTime 0x200, kde jiˇz byla velk´a pravdˇepodobnost, ˇze budeme schopni rozpoznat probl´emov´e u ´lohy. Aplikace k otestov´an´ı jsou na pˇriloˇzen´em CD v adres´aˇri \function workspace\WorkSpace\IntrApp.
7.2
Nev´ yhody ˇ reˇ sen´ı
Pod´ıv´ame-li se na ˇcasov´e parametry u ´loh, mus´ıme si uvˇedomit, ˇze hodnoty mus´ı b´ yt v souladu s ˇcasov´ ymi parametry syst´emu. Napˇr. u ´loha τ1 (0, 3, 7, 12) hodnoty ud´avaj´ı poˇcet tik˚ u. Kolik instrukc´ı za jeden tik se provede, je z´avisl´e na platformˇe, ˇcasto i na optimalizaci pˇrekladaˇcem. Kdybychom hodnoty z u ´vodn´ıho pˇr´ıkladu pouˇzili v praxi na nˇejak´em m´enˇe v´ ykonn´e platformˇe. Mohl by syst´em b´ yt nestabiln´ı a nepˇredv´ıdateln´ y. Souvislost hledejme ve spr´avn´em nastaven´ı poˇctu tik˚ u za sekundu. Zejm´ena z d˚ uvodu, ˇze vyhled´an´ı u ´lohy s nejvyˇsˇs´ı prioritou, po t´e pˇrepnout kontext procesoru by trvalo n-kr´at d´ele, neˇz u ´loha podle parametr˚ u od v´ yvoj´aˇre. 45
Zhodnocen´ı ˇreˇsen´ı
V´yhody ˇreˇsen´ı
Pokud by u ´loha byla opravdu prov´adˇela svou ˇcinnost, jak uvedl. Bylo by vhodn´e uvaˇzovat pˇrinejmenˇs´ım o pouˇzit´ı p˚ uvodn´ıho pl´anov´an´ı. Pˇren´aˇs´ı se tak zodpovˇednost na v´ yvoj´aˇre pouˇz´ıvaj´ıc´ı rozˇs´ıˇren´ı, kter´ y mus´ı velmi dobˇre zn´at podm´ınky pouˇzit´ı. V pˇredchoz´ı ˇc´asti jsme zm´ınili, ˇze doba vyhled´an´ı u ´lohy nejvyˇsˇs´ı priority prodluˇzuje dobu mezi pˇrepnut´ım kontextu. Sbˇer dat pro pˇrepl´anov´an´ı by mohl b´ yt pˇresunut do rukou v´ yvoj´aˇre, aby jej vhodnˇe vyuˇz´ıval ve funkci OSTaskSwHook, ta je vol´ana jako uˇzivatelsk´a pˇri pˇrepnut´ı kontextu. S´am v´ yvoj´aˇr by si urˇcil jak ˇcasto sb´ırat data. Samotn´ y algoritmus sbˇeru informac´ı je sloˇzitosti O(N ). P˚ uvodn´ı myˇslenka seˇrazovat a novˇe pˇriˇrazovat priority vˇsem u ´loh´am, byla pˇri dokonˇcov´an´ı pr´ace zavrhnuta. Zejm´ena z d˚ uvodu znaˇcn´eho zvˇetˇsen´ı reˇzie j´adra syst´emu oproti vlastn´ı funkci u ´loh. Probl´em by spoˇc´ıval v ˇrad´ıc´ım algoritmu, at’ bychom vybrali jak´ ykoli jednoduˇse implementovateln´ y v jazyce C, nejl´epe takov´ y jenˇz nevyˇzaduje vˇetˇs´ı dodateˇcnou pamˇet’, byl by sloˇzitosti O(N logN ). Rychlost v´ ybˇeru u ´lohy se tedy sn´ıˇzila, v p˚ uvodn´ım ˇreˇsen´ı se prov´adˇelo 20 instrukc´ı vˇcetnˇe n´avratov´ ych. V obou pˇr´ıpadech d´ıky pˇrid´an´ı inicializace vzrostl poˇcet instrukc´ı o OSN S Y ST ASK, kter´ ym se mus´ı dodat ide´aln´ı ˇcasov´e parametry. Samotn´emu pl´anov´an´ı vzrostl poˇcet instrukc´ı n-n´asobnˇe na hodnotu N · 60 + 50, v z´avislosti na poˇctu u ´loh, nejv´ıce jej ovlivˇ nuje zaznamen´av´an´ı spr´avn´ ych u ´daj˚ u. V´ ybˇer priority pˇresto z˚ ustal st´ale sloˇzitosti O(N ).
7.3
V´ yhody ˇ reˇ sen´ı
Zakomponov´an´ım naˇsich pl´anovac´ıch metod odpad´a nutnost v´ yvoj´aˇre pˇriˇradit priority u ´loh´am, tak by pl´an splnily. Zejm´ena d´ıky dynamick´ ym algoritm˚ um, je mnoˇzina splnˇen´ ych u ´loh vˇetˇs´ı neˇzli p˚ uvodn´ı pl´anovateln´a mnoˇzina. Zad´an´ı pr´ace povaˇzuji za splnˇen´e, pouze se mohla vˇetˇs´ı ˇc´ast vˇenovat simulac´ım a jejich porovn´an´ım p˚ uvodn´ıho v´ ybˇeru u ´loh s rozˇs´ıˇren´ım. V souvislosti s algoritmem least laxity first, b´ yvaj´ı obvykle konstruov´any formou vyz´ yv´an´ı u ´loh. Reˇzii dalˇs´ı u ´lohy v syst´emu jsme se vyhnuli d´ıky kontrole priorit pˇri n´avratu z pˇreruˇsen´ı. Nav´ıc jsme pˇripravili model odpoˇctu ˇcasov´ ych u ´daj˚ u i pro jin´e aplikace, kter´ y m˚ uˇzeme pouˇz´ıt i bez zapnut´eho rozˇs´ıˇren´ı. 46
Zhodnocen´ı ˇreˇsen´ı
V´yhody ˇreˇsen´ı
Pokud zn´ame velmi dobˇre pouˇzitou hardwarovou platformu a jsme schopni spr´avnˇe urˇcit okolnosti dˇeje. Dos´ahneme nejlepˇs´ıch v´ ysledk˚ u pl´anovaˇce pˇri pouˇzit´ı algoritmu LLF. Nepˇr´ıjemnou dan´ı je ˇcastˇejˇs´ı poˇcet pˇrepnut´ı kontextu. Dalˇs´ı v´ yhoda je, ˇze pl´anovaˇc je deterministick´ y. Pˇri shodˇe parametr˚ u totiˇz nehroz´ı, ˇze pokaˇzd´e vybere jinou u ´lohu. Vybere totiˇz tu u ´lohu, kter´a byla do TCB zad´ana dˇr´ıv. Syst´em µC/OS-II se zapracovan´ ymi algoritmy, je schopn´ y reagovat na ud´alosti opoˇzdˇen´ı zpracov´an´ı u ´lohy. Je tedy na uˇzivateli jak se k tomu postav´ı.
47
8 Z´avˇer Tato pr´ace se vˇenuje nejbˇeˇznˇejˇs´ım pl´anovac´ım algoritm˚ um Real-time operaˇcn´ım syst´em˚ um. Statick´e algoritmy rate monotonic a deadline monotonic spolu s dynamick´ ymi early deadline first a least laxity jsou implementov´any do RTOS µC/OS-II. Aby bylo implementov´an´ı moˇzn´e, jsou u ´vodn´ı kapitoly vˇenov´any u ´vodu do problematiky samotn´ ych RT syst´em˚ um a nejv´ıce pr´avˇe µC/OS-II. V kapitole 5 jsou vysvˇetleny vytvoˇren´e pl´anovac´ı algoritmy. Jejichˇz implementace je pops´ana v n´asleduj´ıc´ı kapitole 6, spolu s popisem d˚ uleˇzit´ ych blok˚ u zdrojov´e k´odu. V pˇredposledn´ı kapitole 7 jsou shrnuty pˇripom´ınky k realizaci. D´ale jsou zde v´ ysledky simulac´ı, spolu s modelovou testovac´ı u ´lohou. Kv˚ uli n´ıˇz bylo udrˇzov´an´ı u ´daj˚ uou ´loh´ach poskytnuto i p˚ uvodn´ı implementaci. Nejlepˇs´ı volbou z implementovan´ ych algoritm˚ u je v´ ybˇer stupnˇe volnosti u ´lohy. Ale jen v pˇr´ıpadˇe, ˇze jsme schopni tento u ´daj odeˇc´ıst. K tomu d˚ uleˇzit´a dokonal´a znalost architektury mikroprocesoru. V ostatn´ıch pˇr´ıpadech jsou doborou volbou v´ ybˇeru u ´loh jak podle statick´e hodnoty deadline, tak i jej´ı z´avislosti na ˇcase. V´ ysledky simulace uk´azaly, ˇze implementovan´e rozˇs´ıˇren´ı je lepˇs´ı volbou pro v´ ybˇer u ´loh. Pr´ace splˇ nuje vˇsechny body zad´an´ı, a proto ji povaˇzuji za splnˇenou.
48
Literatura [MicroII] Jean J. Labrosse: µC/OS-II The Real-Time Kernel CMP Books, San Francisco, CA • New York, NY • Lawrence, KS, 2002. ISBN: 1-57820-103-9 [CRTOS] Rafael V. Aroca, Glauco Caurin: A Real Time Operating Systems (RTOS) ComparisonLaborat´orio de Mecatrˆonica EESC – Universidade de S˜ao Paulo, 2009 [Sojka] M. Sojka: Programov´ an´ı syst´em˚ u re´ aln´eho ˇcasu pˇredn´aˇsky ˇ CVUT, Praha, z´aˇr´ı 2010 [CLLiu] C.L. Liu, Jamse W. Layland: Scheduling Algorituhms for Multiprogramming in Hard-Real-Time Enviroment Project MAC, MIT, CIT, 1973 [WinEM] Microsoft: Windows Embedded home page. (ˇr´ıjen 2011). Informace naleznete na http://www.microsoft.com/cze/windowsembedded/ [Nucle] Mentor Graphics: Mentor Graphics home page. (ˇr´ıjen 2011). Informace naleznete na http://www.mentor.com/ [QNXso] QNX Software: QNX home page. (ˇr´ıjen 2011). Informace naleznete na http://www.qnx.com/ [VxWor] Wind River: Wind River home page. (ˇr´ıjen 2011). Informace naleznete na http://www.windriver.com/ [LyRto] LynuxWorks: LynuxWorks home page. (ˇr´ıjen 2011). Informace naleznete na http://www.lynuxworks.com/ [Ren] Renesas Electronics Corporation : Renesas home page. Pouˇ zit´ y software a ˇ radu informac´ ı naleznete na http://www.renesas.com/ 49
LITERATURA
LITERATURA
[KPIT] KPIT Tools : KPIT GNU Tools home page. Str´ anky pouˇ zit´ eho pˇ rekladaˇ ce http://www.kpitgnutools.com [Dud] Dr. Ing. Karel Dud´aˇcek : Work page K.Dud´ aˇcka. N´ avody k prostˇ red´ ı HEW v ˇ ceˇ stinˇ e naleznete na http://www.http://home.zcu.cz/~dudacek/ [PJer] Petr Jerman : Pouˇzit´ı operaˇcn´ıho syst´emu MicroC/OS-II na procesoru H8S. Port MicroC/OS-II pro procesory H8S 2600 [DIEDFonSL] Channamallikarjuna Mattihalli : Designing and Implementing of Earliest Deadline First scheduling algorithm on Standard Linux. 2010 IEEE/ACM [JStr] Josef Strnadel : N´avrh ˇcasovˇe kritick´ych syst´em˚ u I-IV. V ˇ casopise AUTOMA vyˇ slo v letech 2010-2011 [EDFlk] Dario Faggioli, Fabio Checconi, Michael Trimarchi, Claudio Scordino : An EDF scheduling class for the Linux kernel. European Commission under the ACTORS project (FP7ICT-216586).
50
51
LITERATURA
LITERATURA
Pouˇ zit´ e zkratky ABS ARM BGP BSP CPU ECB ESR FAT FIFO FTP GPS HTTP HW IDE INTR IP IPSec ISR MCB MIPS NMI OS OSPF POSIX RIP RISC RT RTOS SATA SH SMTP SNTP SSH TCB USB
Antiblockiersystem Advanced RISC Machine Border Gateway Protocol Board Support Packages Central Processing Unit Event Control Block Electronic Stability Control File Allocation Table First In First Out File Transfer Protocol Global Positioning System Hypertext Transfer Protocol Hardware Integrated Drive Electronics Interrupt Request Internet Protocol IP security Interrupt Service Routine Memory Control Block Microprocessor without Interlocked Pipeline Stages Non Maskable Interrupt Operaˇcn´ı syst´em Open Shortest Path First akronym pro Portable Operating System Interface Routing Information Protocol Reduced Instruction Set Computer Real-Time Real-time Operaˇcn´ı Syst´em Serial Advanced Technology Attachment SuperH (typ ARM procesoru) Simple Mail Transfer Protocol Simple Network Time Protocol 52 Secure Shell Task Control Block Universal Serial Bus
Seznam obr´ azk˚ u
4.1
Stavy vl´aken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2
V´ ybˇer u ´lohy z Ready listu . . . . . . . . . . . . . . . . . . . . 13
4.3
Propojen´ı ECB a OS Q . . . . . . . . . . . . . . . . . . . . . 17
4.4
Alokace blok˚ u pamˇeti . . . . . . . . . . . . . . . . . . . . . . . 20
5.1
Doba d´avky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1
Pohled na implementovan´e pl´anov´an´ı . . . . . . . . . . . . . . 37
7.1
RM pl´an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2
DM pl´an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3
Statick´e algoritmy . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4
Dynamick´e algoritmy . . . . . . . . . . . . . . . . . . . . . . . 44
A.1 Prvn´ı spuˇstˇen´ı HEW . . . . . . . . . . . . . . . . . . . . . . . 56 A.2 Otevˇren´ı projektu . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.3 V´ yvojov´e prostˇred´ı HEW . . . . . . . . . . . . . . . . . . . . . 57 A.4 Adresn´ı prostor simul´atoru HEW . . . . . . . . . . . . . . . . 57
53
Seznam tabulek
54
A V´yvojov´a prostˇred´ı a nastaven´ı µC/OS-II A Nebudeme se vˇenovat standardn´ım moˇznostem nastaven´ı syst´emu. Pouze si uk´aˇzeme jak vyuˇz´ıt pˇridan´e vlastnosti syst´emu. Jak je spr´avnˇe nakonfigurovat. K tomu nepotˇrebujeme ˇz´adn´e v´ yvojov´e prostˇred´ı, staˇc´ı n´am libovoln´ y textov´ y editor. Po t´e co nakonfigurujeme pˇrekl´adan´e ˇc´asti syst´emu, uk´aˇzeme si jak na instalovan´em prostˇred´ı upraven´ y k´od pˇreloˇzit. Zmiˇ novan´e materi´aly jsou um´ıstˇen´e na pˇriloˇzen´em z´aznamov´em mediu.
A.1
V´ yvojov´ e prostˇ red´ı
K v´ yvoji aplikace µC/OS-II bylo pouˇzito v´ yvojov´eho prostˇred´ı Highperformance Embedded Workshop verze 4.08.00.011 dostupn´e na mediu, \software\h8v7000 ev.exe, kde jsou dostupn´e tak´e rozd´ılov´e aktulizace. Novˇejˇs´ı jsou ke staˇzen´ı z hlavn´ıch str´anek [Ren]. Ke staˇzen´ı je nutn´e b´ yt zaregistrov´an. Postup instalace nebudeme popisovat, je velmi intuitivn´ı a verzi od verze se m´ırnˇe mˇen´ı. Na zm´ınˇen´ ych internetov´ ych str´ank´ach naleznete tak´e manu´aly k v´ yvojov´emu kitu EVB2633F. K prostˇred´ı d´ale nainstalujeme GNUH8 Windows Tool Chain(ELF), \software\GNUH8v1003-ELF.exe, nejl´epe v nejnovˇejˇs´ı verzi, ke staˇzen´ı jsou opˇet po registraci na [KPIT]. Pˇri instalaci je vyˇzadov´an aktivaˇcn´ı k´od zaslan´ y emailem. Po naistalov´an´ı je pˇrekladaˇc integrov´an do prostˇred´ı HEW. Ke staˇzen´ı jsou zde k dispozici t´eˇz manu´aly k pˇrekladaˇci a assembleru. HEW obvykle ukl´ad´a pracovn´ı sloˇzku jako c:\Workspace\. Doporuˇcil bych strukturu sloˇzek zachovat, staˇc´ı tedy z CD zkop´ırovat adres´aˇr Workspace. Ten obsahuje port pro pouˇzit´ y kit, port je sloˇzen z p´ar uk´azkov´ ych aplikac´ı z [PJer]. Po spuˇstˇen´ı HEW se n´as aplikace zept´a, zda chceme zaˇc´ıt nov´ y projekt, nebo otevˇr´ıt ve vybran´em um´ıstˇen´ı, viz. obr.A.1. Zvol´ıme moˇznost vybrat a v n´asleduj´ıc´ım oknˇe Obr.A.2 vybereme soubor dp.hew. Pravdˇepodobnˇe se n´as jeˇstˇe v z´avislosti na verzi HEW zept´a, zda chceme projekt transformovat do nov´e podoby. Pokud se to stane zvol´ıme yes. Po naˇcten´ı projektu bude v´ yvojov´e prostˇred´ı odpov´ıdat zhruba obr.A.3. V lev´e ˇc´asti je pˇrehled soubor˚ u projektu a z´avislost´ı soubor˚ u mezi sebou.
55
V´yvojov´a prostˇred´ı a nastaven´ı µC/OS-II
V´yvojov´e prostˇred´ı
Obr´azek A.1: Prvn´ı spuˇstˇen´ı HEW
Obr´azek A.2: Otevˇren´ı projektu V´ ychoz´ı instalace a nastaven´ı pˇrekladaˇce jsou funkce schopn´e. Jedin´e co zb´ yv´a nastavit pro simul´ator kitu je adresn´ı prostor simul´atoru. Simul´ator procesoru H8S/2600 m´a nastaven rozsah adres simulovan´e pamˇeti tak, aby vyhovoval obvykl´ ym u ´loh´am. Pokud je to nutn´e (simul´ator hl´as´ı chybu Memory Access Error(Address:H’xxxxxxxx) ), lze rozsah pamˇeti upravit v oknˇe, kter´e se otevˇre pˇr´ıkazem Setup - Simulator - Memory Resource. Z´aznamy v tabulce Memory Resource lze upravit tak, aby pamˇet’ pokr´ yvala cel´ y fyzick´ y adresn´ı prostor procesoru H8S, tj. 16 MB - viz n´asleduj´ıc´ı obr´azek A.4. Krom nastaven´ı pamˇeti, je dobr´e ovˇeˇrit, odkud se nahr´av´a pˇreloˇzen´a aplikace a o jak´ y typ simul´atoru se jedn´a. Toto nastaveni najdeme v menu DebugSetings, na z´aloˇzce target vybereme H8S/2600A Simul´ator. Doln´ı ˇc´asti okna je v´ ypis nahr´avan´ ych soubor˚ u, pokud zde ˇz´adn´ y nen´ı, pˇrid´ame jej tlaˇc´ıtkem Add. Pokud se zde nach´az´ı, zkontrolujeme, ˇze se jedn´a a spr´avn´e um´ıstˇen´ı. Spr´avn´e je ve v´ ychoz´ım nastaven´ı, kdyˇz je zde nastaven pˇreloˇzen´ y soubor ze sloˇzky otevˇren´eho projektu.
56
V´yvojov´a prostˇred´ı a nastaven´ı µC/OS-II
V´yvojov´e prostˇred´ı
Obr´azek A.3: V´ yvojov´e prostˇred´ı HEW
Obr´azek A.4: Adresn´ı prostor simul´atoru HEW
57
B Sestaven´ı konfigurace B Pokud potˇrebujeme rozˇs´ıˇrit jinou portaci, ˇci vzorov´ y µC/OS-II, potˇrebujeme lehce upravit zdrojov´e k´ody. Postup je to jednoduch´ y, pro verzi syst´emu 2.86 bude platit n´asleduj´ıc´ı postup. Upozornil bych, ˇze v budouc´ıch verz´ıch se budou liˇsit zejm´ena uveden´e ˇr´adky, kde se zmˇeny prov´ad´ı. Syst´em jako takov´ y dodrˇzuje jistou organizaˇcn´ı strukturu, popsanou v [MicroII]. Zde se dozv´ıme, ˇze soubory j´adra syst´emu jsou drˇzeny v jedn´e sloˇzce a ostatn´ı, z´avisl´e k portaci jsou ve sloˇzce jin´e. Proto do sloˇzky se soubory j´adra zkop´ırujeme soubory os sched ext.c a os sched ext.h, ty se nach´azej´ı ve sloˇzce \os sched ext\. D´ale mus´ıme upravit p˚ uvodn´ı zdrojov´e k´ody. Zaˇcnˇeme od ucosii.c, zde k seznamu vkl´adan´ ych soubor˚ u pˇrid´ame #include
Stejnou ˇr´adku pˇrid´ame do souboru includes.h, kter´ y pouˇz´ıv´ame pro v´ yvoj aplikac´ı a importu dodateˇcn´ ych knihoven. Do souboru ucosii.h je dobr´e um´ıstit kontrolu pouˇzit´ı rozˇs´ıˇren´ı, tato podm´ınka pˇri pˇrekladu ovˇeˇr´ı, zda je pouˇzito vytv´aˇren´ı u ´loh s extern´ımi daty. Doporuˇcuji, pokud pˇrid´av´ame podm´ınky pˇrekladu, kter´e nevyb´ıraj´ı pˇr´ımo kousky k´odu, um´ıstit na konec soubor˚ u. #i f OS SCH TYPE > 0 && OS TASK CREATE EXT EN < 1 #e r r o r STRING ABOUT EXPRESION #endif #i f OS SCH TYPE == 1 | | OS SCHE TYPE == 2 #i f OS MAX TASKS > (OS LOWEST PRIO / 2 ) #e r r o r STRING ABOUT EXPRESION #e n d i f #endif
Vˇsimnˇeme si, ˇze jsme pˇridali novou konstantu pˇrekladu, tu pˇrid´ame na konec souboru os cfg.h. #define OS SCH TYPE
typ planovani
Typ pl´anov´an´ı nahrad´ıme ˇc´ıslem • 0 P˚ uvodn´ı statick´e pl´anov´an´ı 58
Sestaven´ı konfigurace • 1 Extern´ı RMA • 2 Extern´ı DMA • 3 Extern´ı EDF • 4 Extern´ı LLF Nyn´ı budeme muset upravit soubor os core.c, mus´ıme zajistit, aby se pˇri pˇrekladu a volbˇe extern´ıch pl´anovac´ıch algoritm˚ u nepˇreloˇzila funkce OS SchedNew(). Na ˇr´adku pˇred koment´aˇr (1630) um´ıst´ıme #i f OS SCH TYPE == 0
a za konec funkce, resp. pˇred koment´aˇr (1670) n´asleduj´ıc´ı funkce #endif
D´ale pokraˇcujme u ´pravami ve funkci OSIntExit(), zde je m´ısto ˇ adek s OSTCBHighRdy = OSTCBPrizmˇeny kontextu procesoru. R´ oTbl[OSPrioHighRdy]; (664) nahrad´ıme za #i f OS SCH TYPE == 0 OSTCBHighRdy = OSTCBPrioTbl [ OSPrioHighRdy ] ; #endif
To sam´e provedeme ve funkci OS Shed() na ˇr´adku (1620) a tak´e ve funkci OSStart()(790). Po tˇechto u ´prav´ach je syst´em pouˇziteln´ y pro dalˇs´ı v´ yvoj portace a funkˇcn´ı aplikace. Pokud se v´am shoduj´ı verze µC/OS-II a nedˇelali jste ˇza´dn´e u ´pravy v souboru os core.c lze jej pˇrekop´ırovat jiˇz upraven´ y ze sloˇzky \function workspace\WorkSpace\UCOSIIBaseApp\MicroCOSIIv286 Jak pouˇz´ıvat rozˇs´ıˇren´ı Mus´ıme dodrˇzovat pravidla a doporuˇcen´ı, kter´e ´ stanovuje p˚ uvodn´ı implementace. Uloha je naps´ana jako nekoneˇcn´a smyˇcka, kter´a neobsahuje vol´an´ı return. Aby doch´azelo k pˇrep´ın´an´ı u ´loh syst´emem, mus´ı b´ yt uvnitˇr smyˇcky vol´ana jedna z n´asleduj´ıc´ıch funkc´ı • OSMboxPend() • OSFlagPend() • OSMutexPend() • OSQPend() 59
Sestaven´ı konfigurace • OSSemPend() • OSTimeDly() • OSTimyDlyHMSM() • OSTaskSuspend() • OSTaskDel() Priority, kter´e uˇzivatel zad´a nebudou respektov´any s v´ yhradami. T´ım je myˇsleno, ˇze uˇzivatelem zadan´e priority mus´ı b´ yt unik´atn´ı a nesm´ı b´ yt z rezervovan´ ych priorit. Jen pro u ´plnost jsou rezervov´any OS LOWEST PRIO, OS LOWEST PRIO - 1 a naopak nejvyˇsˇs´ı priority 0 a 1. Abychom mohli pouˇz´ıt rozˇs´ıˇren´ı o pl´anov´an´ı statick´ ymi nebo dynamicky ´mi algoritmy, mus´ı b´ yt pˇri portaci vytvoˇrena obsluha ˇc´ıtaˇce a ˇcasovaˇce, bez nˇej nem´a pl´anovaˇc jak odmˇeˇrovat u ´daje. D´ale mus´ıme vytvoˇrit strukturu OS SCHED EXT. A vyplnit n´asleduj´ıc´ı parametry vztaˇzen´e k modelu u ´lohy viz obr.5.1 • OSTCBStartTask - odpov´ıd´a parametru r • OSTCBMaxTime - odpov´ıd´a parametru C • OSTCBDeadline - odpov´ıd´a parametru D • OSTCBPeriod - odpov´ıd´a parametru T Pokud potˇrebuje uˇzivatel pˇred´avat data, k ˇcemuˇz p˚ uvodnˇe pext slouˇzil, mus´ıme upravit jej´ı zpracov´an´ı a posunout se o jeden pointer d´al na OS SCHED EXT->pext. Takto pˇripraven´a data pˇred´ame funkci OSTaskCreateExt(). Jeˇstˇe pˇred spuˇstˇen´ım multitaskingu, je nutn´e inicializovat extern´ı scheduler a to vol´an´ım funkce OSSchedExtInit().Toto zd˚ urazˇ nujeme, kv˚ uli neinicializovan´e pamˇeti pl´anovaˇce, kde pak doch´az´ı k poruˇsen´ı pravidel adresace pamˇeti. Pokud jsme provedli vˇsechny kroky z pˇredchoz´ı kapitoly, m´ame upraven´ y syst´em pˇripraven k pouˇzit´ı. Ke snadnˇejˇs´ımu zad´av´an´ı parametr˚ uu ´loh lze vyuˇz´ıt vytvoˇrenou funkci, kter´e se pˇred´a ukazatel na strukturu s parametry u ´lohy s t a t i c void OS SchedPext ( OS SCHED EXT ∗ p e x t , INT16U s t a r t T a s k , INT16U maxTime , INT16U d e a d l i n e , INT16U p e r i o d ) ;
60
Sestaven´ı konfigurace
Funkce zajist´ı inicializaci u ´daj˚ u potˇrebn´ ych pro spr´avn´ y bˇeh. Spolu s touto funkc´ı byl vytvoˇren model u ´lohy, na kter´ y je moˇzn´e r˚ uznˇe upravit a pouˇz´ıt. Samozˇrejmost´ı je moˇznost pouˇzit´ı standardn´ıho pl´anov´an´ı rozˇs´ıˇren´eho o sbˇer informac´ı task˚ u. Tento model naleznete v adres´aˇri \function workspace\WorkSpace\IntrApp.
61