Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Implementace vybraných

Západoˇceská univerzita v Plzni Fakulta aplikovaných vˇed Katedra informatiky a výpoˇ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áci 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é 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án´ı kontextu . 4.2 Pˇreruˇsen´ı . . . . . . . . . . 4.2.1 Periodické pˇreruˇsen´ı 4.3 Event Control Block . . . . 4.3.1 Speciáln´ı 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áva pamˇeti . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Pl´ anov´ an´ı proces˚ u 5.1 Preemtivn´ı/Nepremtivn´ı plánován´ı . . 5.2 Prediktivn´ı synchronizace . . . . . . . 5.3 Situaˇcn´ı model . . . . . . . . . . . . . ´ 5.3.1 Ulohy . . . . . . . . . . . . . . ˇ e cyklické . . . . . . . . . . 5.3.2 Cistˇ 5.3.3 Pˇreváˇznˇe cyklické . . . . . . . . 5.3.4 Asynchronn´ı a predikovatelné . 5.3.5 Asynchronn´ı a nepredikovatelné ˇ 5.3.6 Cinitel vyt´ıˇzen´ı CPU . . . . . . 5.4 Obsluha pˇreruˇsen´ı . . . . . . . . . . . . 5.5 Statické rozvrhován´ı . . . . . . . . . . 5.5.1 Rate Monotonic . . . . . . . . . 5.5.2 Deadline Monotonic . . . . . . 5.6 Dynamické rozvrhován´ı . . . . . . . . . 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ód˚ u . . . . . . . 6.2 Moˇznosti jak vytvoˇrit u ´lohu . . . . . . . 6.2.1 Vlastn´ı funkce na vytváˇ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é plánován´ı . . . . . . . . 6.3.2 Dynamické plánován´ı . . . . . . . 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é prostˇred´ı . . . . . . . . . . . . . . . . . . . . . . . . 55 B Sestaven´ı konfigurace

58

´ 1 Uvod µC/OS-II je operaˇcn´ı systém reálného ˇcasu dodávan´ y ve formˇe zdrojov´ ych kód˚ u programovac´ıho jazyka C, implementovan´ y na v´ıce neˇz 40 hardwarov´ ych architekturách. Za jeho v´ yvojem stoj´ı spoleˇcnost Micriµm Technologies Corporation a je pouˇz´ıván v celé ˇradˇe aplikac´ı od ˇr´ıd´ıc´ı elektroniky aˇz po letectv´ı. Pro nekomerˇcn´ı a akademické pouˇzit´ı nemus´ı b´ yt tento systém licencován. K implementaci µC/OS-II na konkrétn´ı procesor je nutno upravit jeho konfiguraci a doplnit zdrojové kódy operaˇcn´ıho systému o kód specifick´ y pro dan´ y procesor. Takto upraven´ y systém µC/OS-II b´ yvá naz´ yván portem. Pro vytvoˇren´ı spustitelného kódu je nutn´ y pˇrekladaˇc jazyka C, assembleru a sestavovac´ı program. C´ılem této práce je implementace jiného neˇz standardn´ıho plánován´ı proces˚ u operaˇcn´ıho systému µC/OS-II 2.86. Standardn´ım se mysl´ı statické nastaven´ı priorit po spuˇstˇen´ı systému. 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ázev jednoˇcipového mikropoˇc´ıtaˇce firmy Renesas Technology Corporation. Oˇcekáváno je lepˇs´ı vyuˇzit´ı strojového ˇcasu procesoru. Dále u pˇr´ıpadov´ ych u ´loh zaruˇcen´ı splnˇen´ı mezn´ıho ˇcasu vykonáván´ı oproti stávaj´ıc´ı implementaci, zároveˇ n mezi implementovan´ ymi algoritmy. • Seznamte se s operaˇcn´ım systémem MicroC/OS-II. • Prostudujte metody plánován´ı u ´loh v RTOS. Vyberte metody vhodné pro implementaci v µC/OS-II. • Navrhnˇete u ´pravy plánovaˇce proces˚ u v µC/OS-II tak, aby umoˇzn ˇoval plánován´ı podle zvolen´ ych metod. • Správnou funkˇcnost plánovaˇce demonstrujte na vhodn´ ych pˇr´ıkladech.

1

2 Real-time systémy Real-time operaˇcn´ı systémy (RTOS) jsou speciálnˇe navrhovány pro splnˇen´ı pˇr´ısn´ ych ˇcasov´ ych omezen´ı. Problematiku RTOS si ukáˇzeme na následuj´ıc´ım pˇr´ıkladu z bˇeˇzného ˇzivota. Jako pˇr´ıklad uved’me systém vyhodnocuj´ıc´ı u ´daje v automobilu napˇr. systémy ABS, ESR apod. Zde nás ihned napadne, ˇze zpracován´ı u ´daj˚ u od bezpeˇcnostn´ıch prvk˚ u mus´ı m´ıt aktuáln´ı hodnoty. Tedy máme pevnˇe dan´ y ˇcasov´ yu ´daj, do kdy mus´ı b´ yt informace vyhodnoceny. Nen´ı-li toto splnˇeno, jsou informace bezcenné. Nejen v automobilech nalezneme systém, kter´ y zpracovává obraz pˇred automobilem (k rozeznán´ı dopravn´ıch znaˇcek). Zde jiˇz nen´ı tak striktn´ı omezen´ı na dobu odezvy. Uvˇedom´ıme-li si, jak zásadn´ı je z´ıskán´ı informace o sn´ıˇzené rychlosti. Obraz b´ yvá obvykle zpracováván na vzdálenost 100m, tedy pˇri 90km/h ujedeme pˇri zpoˇzdˇen´ı jedné sekundy 25m. I po této dobˇe máme znaˇcku stále pˇred námi a tedy zónu se sn´ıˇzenou rychlost´ı také. Ale napˇr´ıklad pˇri zpoˇzdˇen´ı 5s bychom byli uˇz v zónˇe a v lepˇs´ım pˇr´ıpadˇe by nám hrozila pokuta. Máme tedy definován deadline události, ale nemus´ıme jej tak striktnˇe dodrˇzet jako v pˇr´ıpadˇe bezpeˇcnostn´ı v´ ybavy. Systému, kde je povoleno pˇrekroˇcen´ı deadlinu o nezbytnˇe nutné zpoˇzdˇen´ı. M˚ uˇzeme ˇr´ıci, ˇze témˇeˇr kaˇzd´ y ˇr´ıd´ıc´ı systém, je systém reálného ˇcasu. Pro pˇredstavu kde se RTOS pouˇz´ıvá, uved’me nˇekteré pˇr´ıklady. • Automobily - ˇr´ıd´ıc´ı jednotky motoru, bezpeˇcnostn´ı prvky v´ ybavy • Domácnost - praˇcky, mikro-vlnné trouby, myˇcky, kotle na vytápˇen´ı • Letectv´ı - zbraˇ nové systémy, navigaˇcn´ı systémy, radarov´ y systém ˇ ızen´ı v´ yroby - automatizované v´ yrobn´ı linky • R´ Napˇr´ıklad rozvinuté letecké kontroln´ı systémy, které pouˇz´ıvaj´ı jeden centráln´ı poˇc´ıtaˇc, se mus´ı vyrovnat s nˇekolika letadlov´ ymi subsystémy, coˇz vyˇzaduje operaˇcn´ı systém s oddˇelen´ım ˇcasu a prostoru pro pˇripojené systémy. Prostorové dˇelen´ı znamená, ˇze kaˇzd´ y u ´kol je bezpeˇcnˇe izolovan´ y v pamˇeti poˇc´ıtaˇce, zat´ımco ˇcasové oddˇelen´ı je vlastnˇe rozdˇelen´ı v´ ykonného ˇcasu procesoru. 2

Real-time systémy

Historie a souˇcasný stav

Toto dˇelen´ı umoˇzn ˇuje jedinému procesoru vykonávat nˇekolik u ´loh souˇcasnˇe, bez rizika jednoho u ´kolu zp˚ usobit problémy 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ém˚ u je vhodné 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áln´ ymi dˇeji. Oddˇelen´ı funkc´ı (co u ´loha dˇelá) a ˇcasov´ ych charakteristik (kdy to dˇelá) jednotliv´ ych u ´loh. Samozˇrejmˇe je to prostˇredn´ık mezi hardwarovou a aplikaˇcn´ı vrstvou. Pomáhá program˚ um efektivnˇe vyuˇz´ıvat hardwarové a systémové prostˇredky. Vzájemnˇe je od sebe um´ı oddˇelit. V nˇekolika situac´ıch RTOS jsou pˇr´ıtomny v oblasti embedded systém˚ u, a vˇetˇsinu ˇcasu nevyˇzaduj´ı zásah uˇzivatel˚ u.

2.1

Historie a souˇ casn´ y stav

2.2

Obecn´ e pojmy

V této ˇcásti uvedeme pouze nejzákladnˇ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án za RTOS. D˚ uleˇzité je, ˇze mus´ı dodrˇzet ˇcasové meze kladené na dobu jeho odezvy pro u ´ˇcely dané konkrétn´ı RT aplikace.

2.2.2

Determinismus

Systémy reálného ˇcasu mus´ı b´ yt pˇredv´ıdatelné vzhledem ke svému chován´ı v ˇcase. Mus´ı b´ yt vˇzdy zaruˇcena maximáln´ı doba odezvy, po kterou systém u ´lohu spln´ı. V opaˇcném pˇr´ıpadˇe nastává jeho selhán´ı. Determinismus nen´ı omezen pouze na ˇcasové spektrum, ale oznaˇcuje pˇred3

Real-time systémy

Klasifikace RTOS

v´ıdatelnost událost´ı. Lze tedy v jeho libovolném stavu s pˇr´ısluˇsn´ ymi hodnotami na vstupu jednoznaˇcnˇe urˇcit, jak´ y bude jeho následuj´ıc´ı stav a v´ ystup. Prvn´ı pˇr´ıpad determinismu se naz´ yvá temporáln´ı, druh´ y událostn´ı. Jin´ ymi slovy ˇreˇceno, je urˇciteln´ y v ˇcase a nebo na základˇe u ´dálosti.

2.3

Klasifikace RTOS

Dˇelen´ı RT systém˚ u, m˚ uˇze b´ yt bráno dle ˇrady hledisek. Ve vˇetˇsinˇe literatury jsou dˇeleny podle potˇreby dodrˇzet ˇcasové poˇzadavky kladené na systém.

2.3.1

Hard

Na u ´vodn´ım pˇr´ıkladu jsme naznaˇcili ˇcasovou závislost v´ ysledk˚ uu ´loh. Podle n´ı dˇel´ıme také na hard real-time a soft real-time. Hard systémy dodrˇzuj´ı term´ın dokonˇcen´ı dávky pˇresnˇe, pokud v ˇcas nedokonˇc´ıme u ´lohu, chován´ı systému obvykle vede ke katastrofáln´ım dopad˚ um. Napˇr. kontroln´ı a ˇr´ıd´ıc´ı systémy jaderné elektrárny striktnˇe dodrˇzuj´ı term´ın ukonˇcen´ı1 .

2.3.2

Soft

Systémy nedodrˇzuj´ıc´ı striktnˇe term´ın ukonˇcen´ı, mohou ”obˇcas”minout deadline. Co znamená ”obˇcas”? Nejˇcastˇeji se definuje procentuáln´ım zastoupen´ım, napˇr. 99% bude dodrˇzeno. Nebo se definuj´ı funkce v závislosti na ˇcase, kde po term´ınu ukonˇcen´ı maj´ı klesaj´ıc´ı tendenci relevantnosti dat. Klesaj´ıc´ı pouˇzitelnost dat a zpoˇzdˇen´ı, nám zde nevad´ı.

2.3.3

Firm

Oproti tomu systémy firm maj´ı mez, do které jsou data relevantn´ı, a nevede opoˇzdˇen´ı term´ınu ukonˇcen´ı k pádu systému. Pakliˇze je tato mez pˇrekroˇcena, m˚ uˇze to m´ı vliv na stabilitu, ba dokonce na pád systému.

1

v ang. lit. deadline

4

3 Pˇrehled RTOS Na trhu existuje celá ˇrada RTOS a vybrat z nich nemus´ı b´ yt jednoduché. M˚ uˇzeme vyb´ırat z volnˇe dostupn´ ych tak i komerˇcn´ıch. Také m˚ uˇzeme vyb´ırat podle podporovan´ ych platforem, podpoˇre samotného v´ yrobce ˇci komunity. Vˇetˇsina RTOS má vlastnosti popsané v´ yˇse. V následuj´ıc´ı ˇcásti jsou vyzdvihnuty vlastnosti, kter´ ymi se dan´ y v´ yrobce prezentuje. Uvedené systémy jsou byly vybrány podle nejˇcastˇejiˇs´ıho zastoupen´ı a jsou minimem toho, co nab´ız´ı trh.

3.1

Windows Embeded

Mezi hlavn´ı zbranˇe systém˚ 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é 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énou tˇechto systém˚ u je práce s vlastn´ımi technologiemi. Zejména pro podporu synchronizace dat, vyuˇzit´ı profil˚ u, m´ıstn´ı sluˇzby, reklamn´ı odvˇetv´ı, business intelligence a line-in-business aplikac´ı, zpracován´ı dat ze zaˇr´ızen´ı. Zapojen´ı zaˇr´ızen´ı do jedné platformy pˇrináˇs´ı napˇr´ıklad: • Silverlight pro Windows Embedded • Internet Explorer Embedded • Dotykové ovládán´ı • Media Player • Office and PDF Viewers • a dalˇs´ı Mezi podporované platformy patˇr´ı ARM architektura, x86 procesory, x64 procesory, MIPS a dalˇs´ı. Samozˇrejmost´ı se pak stává podpora napˇr´ıklad nˇekter´ ych souborov´ ych systém˚ u, bluetooth technologie a dalˇs´ı. V´ yvoj aplikac´ı je plnˇe podporován v´ yvojov´ ym prostˇred´ı Microsoft Visio. 1

[WinEM]

5

Pˇrehled RTOS

3.2

QNX Neutrino

QNX Neutrino

Rozsáhlá 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árn´ı chipsety, vˇcetnˇe ARM, MIPS, PowerPC, SH-4, a x86, umoˇzn ˇuje návrháˇr˚ um vybrat nejlepˇs´ı hardwarové platformy pro jejich embedded systém, pak se rychle dostat své systémy do provozu. D´ıky mikrojádru architektury QNX Neutrino RTOS2 , prakticky jakákoli souˇcást (i low-level ovladaˇc) m˚ uˇze selhat, bez poˇskozen´ı jádra nebo jiné souˇcásti. Vyt´ıˇzen´ı procesoru, pokud jsou zdroje omezené, z´ıskaj´ı procesy dle pod´ıl˚ u. Pokud ovladaˇce zaˇr´ızen´ı, protokol zásobn´ıku, nebo aplikace selˇze. Je v QNX Neutrino RTOS zaˇr´ızeno, tak aby nezkolaboval systém. Ale manaˇzer ukonˇcil u ´lohu s problémem a obnovil jej (ˇcasto za nˇekolik milisekund bez restartu). Podporované jsou téˇz s´ıt’ové technologie, mezi nˇeˇz patˇr´ı IPv4, IPv6, IPSec, FTP, HTTP, SSH a Telnet. Unikátn´ı transparentn´ı distribuce umoˇzn ˇuje pˇr´ıstup k prostˇredk˚ um na libovolném uzlu v s´ıti, pro bezproblémové peer-to-peer sd´ılen´ı zdroj˚ u. QNX souborové systémy jsou obsluhovány mimo mikrojádro v uˇzivatelské chránˇené-pamˇeti. V´ yvojáˇri mohou spustit, zastavit, nebo aktualizovat souborové systémy za bˇehu bez nutnosti restartu. V´ıce souborov´ ych systém˚ u m˚ uˇze b´ yt spuˇstˇeno souˇcasnˇe a dokonce pracovat naráz s c´ılem rozˇs´ıˇrit navzájem schopnosti.

3.3

Wind River VxWorks

VxWorks3 byl navrˇzen pro pouˇzit´ı v r˚ uzn´ ych multi-jádrov´ ych sestavách jako svého ˇcasu jedin´ y operaˇcn´ı systém na symetrickém/asymetrickém multiprocesovém reˇzimu nebo jako host OS na vrcholu Wind River Hypervisor. VxWorks je vysoce ˇskálovateln´ y RTOS. VxWorks systémy zahrnuj´ı certifikovan´ y OS pro velmi pˇr´ısné bezpeˇcnostn´ı normy. VxWorks také nab´ız´ı nˇekolik u ´rovn´ı zabezpeˇcen´ı, vysokou odol2 3

[QNXso] [VxWor]

6

Pˇrehled RTOS

Nucleus

nost RTOS bezpeˇcnosti pro nároˇcné poˇzadavky Common Criteria a National Information Assurance Partnership (NIAP). VxWorks má ˇreˇsen´ı pro kaˇzd´ y aspekt vestavˇen´ ych systém˚ u komunikace. S Wind River Tilcon Graphics Suite maj´ı v´ yvojáˇri k dispozici rychl´ y návrh grafického uˇzivatelského rozhran´ı. Podporované 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éˇz nab´ız´ı RTOS. Silné stránky tohoto systému jsou v rozdˇelen´ı funkc´ı, tak aby byly co nejv´ıce nezávislé a pˇri pádu aplikace nezkolaboval cel´ y systém. Operaˇcn´ı systém poskytuje bohaté moˇznosti pro grafické uˇzivatelské rozhran´ı. Samozˇrejmost´ı je ovládán´ı 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é dalˇs´ı. Umoˇzn ˇuje také virtualizace nˇekter´ ych rozhran´ı, napˇr. RS232. Mezi s´ıt’ov´ ymi protokoly nechyb´ı IPv4 ani IPv6, souˇcást´ı jsou pˇr´ıpravy napˇr´ıklad pro SNTP klienty, SMTP klient/server. Podpora multimédi´ı je na vysoké u ´rovni, vyuˇz´ıvaj´ı otevˇrené, platformˇe nezávislé API OpenMax. To umoˇzn ˇuje pˇrehrávat standardn´ı typy audio a video formát˚ u. S podporou rozhran´ı pamˇet’ov´ ych médi´ı, je spojena podpora souborov´ ych systém˚ u FAT12, FAT16, FAT32 a také vlastn´ıho Nucleus SAFE pro flash pamˇeti. Podporované platformy jsou PowerPC, MIPS, ColdFire, Atmel. Stejnˇe jako u vˇetˇsiny pˇredchoz´ıch, závis´ı 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é reakce jsou zajiˇstˇeny i v pˇr´ıtomnosti sloˇzit´ ych I/O operac´ı, protoˇze jádro systému umoˇzn ˇuje extrémnˇe krátké a rychle obslouˇzené pˇreruˇsen´ı. LynxOS RTOS také pouˇz´ıvá lineárn´ı ˇskálovatelnost, takˇze z˚ ustává neochvˇejnˇe deterministick´ y. Toho je vyuˇzito zejména pro v´ ybornou odezvu napˇr´ıklad v komunikac´ıch. Schopnosti s´ıt’ové komunikace tohoto systému jsou taktéˇz vyspˇelé, nechyb´ı napˇr´ıklad IPSec, IPv6, integrovan´ y firewall, a Quality of Service (QoS). Zahrnuje nejnovˇejˇs´ı protokoly a moˇznosti pro vytváˇ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ému jsou doporuˇcovány pro Eclipse, kter´ y je de facto ˇs´ıˇren jako otevˇren´ y v´ yvojov´ y nástroj. Vhodn´ ym doplˇ nkem je i debugger SpyKer schopn´ y monitorován´ı vˇsech událost´ı v systému. Mezi platformami, které tento systém podporuje, najdeme x86 od desek s procesory s 386 aˇz po Core 2 Duo procesory. Vyj´ımkou nejsou ani nˇekteré procesory AMD a Via Cyrix. Samozˇrejmˇe najdeme zástupce dalˇs´ı architektury, mezi nˇeˇz patˇr´ı nejr˚ uznˇejˇs´ı procesory PowerPC, nˇekteré desky s MIPS mikroprocesory, nebo zástupce od IBM ˇrada 440.

3.6

Linux

Zab´ yvat se schopnostmi operaˇcn´ıch systém˚ u zaloˇzen´ ych na Linuxovém jádˇre je takˇrka nemoˇzné. 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é stanice. Nav´ıc zde naráˇz´ıme na nejednotnost distribuc´ı, pˇredevˇs´ım v desktopové sféˇre. Pro operaˇcn´ı systém Linux existuj´ı extern´ı ˇreˇsen´ı, které jsou v implementovány do jádra systému. Od poˇcátku nebyl Linux navrhován jako RealTime operaˇcn´ı systém. Zmˇenit jeho jádro, které má navrˇzeno fixnˇe prioritn´ı plánován´ı, by bylo pˇrinejmenˇs´ım nevhodné a komplikované. Z tohoto d˚ uvodu 5

[LyRto]

8

Pˇrehled RTOS

Linux

je moˇzné doplnit tento systém o RT plánován´ı, formou minimáln´ıch u ´prav jádra a dodán´ım extern´ıch modul˚ u plánován´ı. Funguj´ı zde tak pospolu jak u ´lohy real-time-ové, tak ne-real-time-ové pospolu. Ne-RT u ´lohy jsou vykonávány v pˇr´ıpadˇe, ˇze nemá b´ yt vykonávána RT u ´loha.

9

4 µC/OS-II V této kapitole probereme v rychlosti vlastnosti vybraného real-time operaˇcn´ıho systému. Nebudeme se jimi vˇsak zab´ yvat dopodrobna, nen´ı to c´ılem práce. Sp´ıˇse to berme jako základ, kter´ y by mˇel v´ yvojáˇr pracuj´ıc´ı s µC/OS-II znát.

4.1

´ Ulohy

´ Ulohou oznaˇcujeme programov´ y kód oddˇelen´ y v ˇcase a pamˇeti, kter´ y vykonává poˇzadovanou funkci. Obvykle je u ´loha implementována jako nekoneˇcná smyˇcka. Verze 2.00 obsahuje 64 prioritn´ıch u ´rovn´ı, kaˇzdá m˚ uˇze odpov´ıdat právˇe jedné u ´loze. Ve skuteˇcnosti jsou nˇekteré rezervovány pro systémová vlákna. 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ádro umoˇzn ˇuje pomoc´ı rezervovan´ ych funkc´ı mˇenit priority vláken, oznaˇcit vlákno za smazané, fakticky jej ale nesmaˇze.

4.1.1

Stavy u ´ loh

Kaˇzd´ y u ´kol pˇri svém bˇehu se m˚ uˇze dostat do nˇekolika stav˚ u. Podle nich plánovaˇc urˇcuje, která u ´loha bude vykonávána. Stavy u ´loh v µC/OS-II jsou: • dormant • ready • running • waiting • interrupted ´ Dormant odpov´ıdá stavu, kdy je vlákno v pamˇeti, ale nen´ı dostupné. Uloha, která je ready, ˇceká na ukonˇcen´ı právˇe bˇeˇz´ıc´ıho vlákna a je pˇripraveny k bˇehu. Vlákno vlastn´ıc´ı CPU je running. Waiting u ´kol, ˇceká na dokonˇcen´ı napˇr. I/O operace, na sd´ılené 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ázek 4.1: Stavy vláken pˇreruˇsen´ı vzniklé nenadálou událost´ı a pˇreb´ırá CPU. Na obr. 4.1 jsou stavy znázornˇeny spolu s pˇrechody mezi nimi. Obecnˇe nem˚ uˇzeme ˇr´ıci, ˇze by kaˇzd´ y RTOS pouˇz´ıval stejné oznaˇcen´ı, ale jistˇe pˇridá ˇci ubere nˇejak´ y jin´ y stav.

4.1.2

Task Control Block

Kaˇzdé vytvoˇrené vlákno má k sobˇe pˇridruˇzen´ y pamˇet’ov´ y prostor naz´ yvan´ y task control block. TCB je datová struktura, pouˇz´ıvaná µC/OS-II k udrˇzen´ı stavu nejen pˇreruˇsené u ´lohy. Po vykonán´ı u ´lohy s vyˇsˇs´ı prioritou, návratu k pˇreruˇsené a opˇet z´ıskat kontrolu nad CPU, tam kde vykonáván´ı opustila. Struktura obsahuje • ukazatel na vrchol zásobn´ıku u ´lohy • ukazatel na dno zásobn´ıku u ´lohy • velikost zásobn´ıku 11

´ Ulohy

µC/OS-II • nastaven´ı rozˇs´ıˇren´ı zásobn´ıku • nastaven´ı ovˇeˇren´ı zásobn´ıku • indikaci vyˇciˇstˇen´ı zásobn´ıku • nastaven´ı pouˇzit´ı Floating Point • identifikátor vlákna • následn´ıka a pˇredch˚ udce (TCB) • ukazatel na Event Control Block • ukazatel na zprávy vláknu • ukazatel na zachycené události • informaci zda bude u ´loha ready po splnˇen´ı vybrané události • 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án´ı u ´lohy • ukazatel na uˇzivatelské rozˇs´ıˇren´ı TCB

Po inicializován´ı µC/OS-II jsou vˇsechny TCB v tabulce propojeny jako spojov´ y seznam voln´ ych OS TCB. Velikost tabulky je omezitelná nastaven´ım poˇctu u ´loh v souboru os cpu.h. Jiné systémy mohou udrˇzovat dalˇs´ı u ´daje, napˇr. nˇekteré se hod´ı pro dynamické plánován´ı u ´loh, statistické u ´daje apod.

4.1.3

V´ ybˇ er u ´ lohy

Kaˇzdá u ´loha ve stavu ready je um´ıstˇena v seznamu ready list. Poloˇzky nesou informace o OSRdyGrp a OSRdyTbl[]. Priority jsou seskupovány po osmi u ´lohách ve skupinˇe. Na obr.4.2 je znázornˇena struktura ready listu a v´ ybˇer poloˇzky. Bitová maska je v kódu 1 z n nikoli v klasické dvojkové soustavˇe. Kaˇzd´ y bit OSRdyGrp reprezentuje sv´ ym indexem skupinu, která 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ázek 4.2: V´ ybˇer u ´lohy z Ready listu vlákno ve stavu ready, a je indexem do OSRdyTbl[]. Neˇz je pˇrepnut kontext procesoru je nutné vybrat z ready listu u ´lohu. V p˚ uvodn´ı implementaci µC/OS-II je doba v´ ybˇeru závislá na poˇctu u ´loh a je konstantn´ı. Zp˚ usob jak naj´ıt ready u ´lohu je prost´ y, ale pomal´ y. Plánovaˇc by musel vˇzdy proj´ıt celou OSRdyTabl[], naˇstˇest´ı je toto vyˇreˇseno statickou lookup tabulkou. Ve které pomoc´ı indexu OSRdyGrp z´ıskáme Y souˇradnici do OSRdyTbl[] a z indexu OSrdyTbl[Y] z´ıskáme X souˇradnici. Takto popsan´ y ready list nelze brát jako obecnˇe pouˇz´ıvan´ y v RTOS. Objevuj´ı se varianty pouˇzit´ı prioritn´ıch front, zajiˇstˇen´ı správné um´ıstˇen´ı pozice podle priority je otázkou ˇrad´ıc´ıch algoritm˚ u, nebo pouˇzit´ım kl´ıˇc˚ u jako priorit. Pˇri v´ ybˇeru u ´loh plánovaˇc m˚ uˇze b´ yt pˇreruˇsen. Obsluha a správa pˇreruˇsen´ı je dostupná i v pˇr´ıpadˇe pˇreplánován´ı. Pouze by se nemˇelo stát, ˇze pˇreruˇsen´ı vyvolá opˇetovné pˇreplánován´ı. Totiˇz v pˇr´ıpadˇe návratu do plánovaˇce, na stejné m´ısto kde byl pˇreruˇsen, by mohlo doj´ıt k situaci, ˇze právˇe vyvolané pˇreruˇsen´ı-pˇreplánován´ı zmˇenilo pomˇery v systému a nemusela by b´ yt vybrána správná u ´loha. K zákazu pˇreruˇsen´ı systém definuje funkce OSShedLock() a OSShedUnLock() tyto funkce se mus´ı pouˇz´ıvat párovˇe, tzn. zamknout a po vybrán´ı 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é uchovat informace o pˇreruˇsené ˇci pro danou chv´ıli splnˇené u ´loze. K tomu je pˇreddefinováno makro, které mus´ı v´ yvojáˇr portace vytvoˇrit pro kaˇzdou platformu zvláˇst’. Mˇel by se postarat o bezchybné uloˇzen´ı hodnot registr˚ u procesoru. Implementace tohoto makra je záleˇzitost´ı obsluhy softwarového pˇreruˇsen´ı. Pˇrenositelnosti a napsán´ı maker pro specifické platformy je záleˇzitost velmi komplikovaná, podrobnˇeji se j´ı vˇenuje autor systému ve své 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ávˇe vykonávan´ y program a zaˇc´ıt vykonávat 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ého procesorového ˇcasu by strávil ve smyˇcce ˇcekán´ım na dan´ y hardware. V dneˇsn´ı dobˇe se pˇreruˇsen´ı vyuˇz´ıvá mnohem v´ıc pˇri pˇrep´ınán´ı proces˚ u. Pˇreruˇsen´ı v architekturách se vyvolá dvˇema základn´ımi zp˚ usoby, Software-generated (softwarovˇe) a External-hardware generated (hardwarovˇe), tedy vyvolané vnˇejˇs´ım okol´ım. To se dále rozdˇeluje na NMI3 nemaskovatelné a na INTR4 . Softwarová pˇreruˇsen´ı vznikaj´ı v jediném pˇr´ıpadˇe, a to kdyˇz procesor naraz´ı na instrukci pˇreruˇsen´ı µC/OS-II se toto provád´ı inkrementován´ım OSIntNesting nebo pouˇzit´ım funkce OSIntEnter. Kdyˇz jsem v minulém odstavci definoval pˇreruˇsen´ı vyvolané mimo procesor, nebyla to u ´plnˇe pravda, protoˇze do hardwarového pˇreruˇsen´ı se ˇrad´ı tzv. Internal HW, která vznikaj´ı pˇri vnitˇrn´ı chybˇe kódu, napˇr. dˇelen´ı nulou, ˇspatná instrukce. Externˇe vyvolané pˇreruˇsen´ı nastává pˇri ˇzádosti ze vstupu (vnˇejˇs´ı hardware) nebo chybˇe matematického koprocesoru. Co se tedy stane, kdyˇz procesor obdrˇz´ı ˇzádost o pˇreruˇsen´ı? Nejprve zkontroluje, jestli se dan´ y signál bude maskovat a pokud ne, pˇreruˇs´ı právˇe 2

pˇreruˇsen´ı Non Maskable Interrupt 4 Interrupt Request 3

14

µC/OS-II

Event Control Block

vykonávan´ y program a zaˇcne vykonávat 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ádro na vstup do obsluhy pˇreruˇsen´ı. Následnˇe se provede uˇzivatelské obslouˇzen´ı pˇreruˇsen´ı. Po jeho ukonˇcen´ı se informuje jádro o v´ ystup z ISR, obnov´ı kontext CPU a pokraˇcuje se v u ´loze dál. V µC/OS-II je opˇet pouze definována obsluha pˇreruˇsen´ı. Jej´ı implementace závis´ı téˇz na jednotlivé architektuˇre.

4.2.1

Periodick´ e pˇ reruˇ sen´ı

Je speciáln´ı pˇr´ıpad pˇreruˇsen´ı, vˇetˇsinou slouˇz´ıc´ı k odmˇeˇrován´ı poˇctu instrukc´ı, dobˇe vykonáván´ı apod.. Doporuˇcená periody je od deseti do sta opakován´ı ˇ ım ˇcastˇeji jsou vyvolávána pˇreruˇsen´ı, t´ım v´ıce to vede za jednu sekundu. C´ ke zpomalen´ı systému. Na druhou stranu jsou pravidelná pˇreruˇsen´ı, která jsou obslouˇzena hardwarovˇe, napˇr. v µC/OS-II je takto znaˇceno clock tick, ˇcesky ˇcasto oznaˇcované jako hodinové pˇreruˇsen´ı a je závislé na hardwarovém ˇcasovaˇci procesoru. V´ yvojáˇr systému má d´ıky tomu k dispozici zp˚ usob jak zmˇeˇrit ˇcasové u ´daje. Umoˇzn ˇuje mu také na jednotky ˇcasu nebo poˇcet hodinov´ y pˇreruˇsen´ı uspat ˇcinnost u ´lohy. Také to umoˇzn ˇuje drˇzet informaci o dobˇe bˇehu systému, 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ást´ı 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áklad˚ um a vynechali jsme nˇekteré velmi d˚ uleˇzité schopnosti. O doplnˇen´ı funkˇcnosti systému se stará blok ECB. Tento blok slouˇz´ı vlákn˚ 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á, jedin´ y kdo m˚ uˇze ˇcekat na signál pˇres ECB, jsou vlákna, nikoli obsluˇzné rutiny pˇreruˇsen´ı. Zaznamenávat signály do ECB vˇsak m˚ uˇzou jak vlákna tak ISR. Pokud nˇejaká u ´loha oˇcekává signál v ECB, mˇela by b´ yt definována ˇcekac´ı doba. 15

µC/OS-II

Event Control Block

Blok událost´ı je definován jako struktura obsahuj´ıc´ı pˇet u ´daj˚ u. Uvádˇet zde jak vypadá struktura v pamˇeti, nen´ı d˚ uleˇzité. Jelikoˇz hlavn´ı ˇcást, tedy tabulka komu se signalizuje, je stejná jako tabulka s ready u ´lohami. V´ ybˇer, odebrán´ı a vloˇzen´ı signálu do struktury ECB je totoˇzn´ y s v´ ybˇerem ready u ´loh podle priorit. • typ události • ˇc´ıtaˇc v pˇr´ıpadˇe semaforu • ukazatel na frontu nebo zprávu • tabulku ˇcekatel˚ u • index do tabulky ´ Uloha ˇcekaj´ıc´ı na signál z ECB je vyjmuta z ready listu a je vloˇzena do wait listu ECB. Blok˚ u ECB je v systému v´ıc stejnˇe jako blok˚ u TCB, jsou organizovány jako spojov´ y seznam, jehoˇz maximáln´ı délka je konfigurovatelná.

4.3.1

Speci´ aln´ı funkˇ cnosti

Semafory jsou synchronizaˇcn´ı prvky, pˇreváˇznˇe vyuˇzité k synchronizaci proces˚ u a samozˇrejmˇe i vláken. Semafor je prvek skládaj´ıc´ı se z celoˇc´ıselného ˇc´ıtaˇce a operacemi nad semaforem. Hodnota ˇc´ıtaˇce se pohybuje na vymezeném 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á konvence ˇr´ıká, ˇze ˇc´ıtaˇc nab´ yvá hodnot 0 aˇz N, kde N kde N je kladné celé ˇc´ıslo oznaˇcuj´ıc´ı napˇr. omezen´ı velikosti fronty. Zaj´ımav´ y je napˇr. semafor binárn´ı, tedy s ˇc´ıtaˇcem 0 aˇz N, kter´ y se dá vyuˇz´ıt k vzájemnému vylouˇcen´ı u ´loh. Takov´ yto semafor naz´ yváme zkrácenˇe Mutex. Dalˇs´ı co v´ yvojáˇri ECB umoˇzn ˇuje je pouˇzit´ı zpráv. K dispozici máme moˇznost pˇredávat jednu zprávu pouˇzit´ım OS EVENT TYPE MBOX nebo ˇuje vynˇekolik do fronty OS EVENT TYPE Q. Oboj´ı pˇredáván´ı stran umoˇzn b´ırán´ı zpráv pomoc´ı blokován´ı u ´lohy pˇri prázdné frontˇe, tak i pouze vybrán´ı bez blokován´ı pokud je fronta prázdná. Rozd´ıl mezi pouˇzit´ım jedné zprávy a fronty je v pouˇzit´ı ukazatele OSEventPtr v OE EVENT, v pˇr´ıpadˇe fronty ukazuje na strukturu OS Q, která 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ázek 4.3: Propojen´ı ECB a OS Q • ukazatel na poˇcátek 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é synchronizaˇcn´ı prvky. Programátor˚ um poskytne funkce pro vytvoˇren´ı a základn´ı obsluhu. Nav´ıc napˇr. u semafor˚ u umoˇzn ˇuje z´ıskat jejich datovou strukturu. Signalizaci u ´lohám skrze tyto prvky se provád´ı právˇe pomoc´ı ECB. 17

µC/OS-II

4.4

Event-Flag

Event-Flag

Pouˇzit´ı ECB je mocn´ y nástroj, m´ısto nˇej lze v ˇradˇe pˇr´ıpad˚ u pouˇz´ıt na pamˇet’ 5 a obsluhu ménˇe nároˇcné pˇr´ıznakové signalizován´ı . Signalizace se zde provád´ı nastavován´ım séri´ı bit˚ u, udrˇzuj´ıc´ıch informace o stavech. Datová struktura OSFlagGroup obsahuje • typ signalizace (flag) • ukazatel na seznam OSFlagNode • OSFlagFlags drˇz´ıc´ı status událost´ı Struktura OSFlagNode urˇcuje, která u ´loha a na co ˇceká. Struktury jsou mezi sebou propojené, daj´ı se tak pomoc´ı typu skládat podm´ınky pro ˇcekaj´ıc´ı vlákna. Jej´ı struktura je • odkaz na OSFlagGroup • ukazatel na dalˇs´ı OSFlagNode (pˇredka a následovn´ıka) • ukazatel na TCB ˇcekaj´ıc´ı u ´lohy • vzor signalizace bit˚ u • typ struktury OR/AND (ALL/ANY) Vytváˇren´ı skupiny signalizace mohou jen vlákna, nikdy se nesm´ı stát, aby se vytváˇreli v ISR. Po vytvoˇren´ı je skupina prázdná a je nutné nastavit jej´ı parametry. Seznam podm´ınek je moˇzné vytvoˇrit pˇripraven´ım struktur. Taktéˇz signalizován´ım blokován´ı, kdyˇz se naraz´ı na funkci OSFlagPend(), jej´ıˇz parametry jsou data struktury OSFlagNode. Po odblokován´ı u ´lohy je nutné ji odebrat z listu ˇcekatel˚ u a oznaˇcit vlákno za ready.

4.5

Spr´ ava pamˇ eti

V´ yvojáˇr aplikac´ı v C/C++, kter´ y bˇeˇznˇe pouˇz´ıvat dynamické alokován´ı a uvolˇ nován´ı pamˇeti pomoc´ı malloc() a free(), by si mˇel uvˇedomit následuj´ıc´ı. Pouˇzit´ı tˇechto funkc´ı je velmi nebezpeˇcné, tyto funkce zajiˇst’uj´ı velikost 5

Zn´ amˇejˇs´ı anglické pojmenov´ an´ı Event-Flag

18

µC/OS-II

Spr´ ava pamˇeti

alokované pamˇeti. Co vˇsak nezajiˇst’uje, je souvislost oblasti v pamˇeti. Takto alokovaná oblast m˚ uˇze b´ yt fragmentovaná, to znamená, ˇze oblast nen´ı alokovaná v jednom kuse, ale je roztrouˇsena po mal´ ych ˇcástech do voln´ ych oblast´ı. Nav´ıc k tomu, je doba alokace a dealokace nedeterministická, právˇe d´ıky fragmentaci. µC/OS-II poskytuje mechanismus zajiˇst’uj´ıc´ı deterministick´ y ˇcas vykonán´ı funkc´ı alokace a uvolnˇen´ı pamˇeti. Aby toto bylo moˇzné, mus´ı b´ yt blok v souvislé ˇcásti pamˇeti. K tomu slouˇz´ı partition obsahuj´ıc´ı bloky o zvolené velikosti. Struktura udrˇzuj´ıc´ı informace se naz´ yvá memory control block. • ukazatel na zaˇcátek • ukazatel na dalˇs´ı strukturu • velikost bloku • poˇcet blok˚ u • volné bloky Na následuj´ıc´ım obrázku 4.4 vid´ıme náznak propojen´ı MCB ve spojen´ı seznamu a také je zde naznaˇceno pouˇzit´ı blok˚ u a zbylého volného 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ázek 4.4: Alokace blok˚ u pamˇeti

20

5 Plánován´ı proces˚ u Jedná se o základn´ı schopnost jader operaˇcn´ıch systém˚ u. V pˇr´ıpadˇe RTOS je d˚ uraz kladen na ˇcasová omezen´ı u ´loh. V následuj´ıc´ı ˇcásti budou vysvˇetleny d˚ uleˇzité pojmy a algoritmus plánován´ı v µC/OS-II. Posléze se dostaneme k pokroˇcilejˇs´ım, které jsme implementovali.

5.1

Preemtivn´ı/Nepremtivn´ı pl´ anov´ an´ı

Pokud je povoleno pˇreruˇsen´ı u ´lohy plánovaˇcem, naz´ yváme plánován´ı preemtivn´ı. Posléze j´ı byl odebrán ˇcas CPU a byla spuˇstˇena u ´loha s aktuálnˇe nejvyˇsˇs´ı prioritou. Pˇreruˇsené u ´loze je nastaven stav pˇripraven a ˇceká, neˇz bude vybrána k bˇehu. Preemptivn´ı plánován´ı je moˇzné pouze u preemptivn´ıch u ´loh. U nepreemptivn´ıho plánován´ı nedocház´ı k pˇreruˇsen´ı spuˇstˇené u ´lohy plánovaˇcem. Nepˇreruˇsen´ı vˇsak m˚ uˇze vést k chybám v ˇcasován´ı, které 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é RT architektury, protoˇze nevyˇzaduje speciáln´ı mechanismus pˇr´ıstupu do kritické sekce ani pro ˇrazen´ı u ´loh do front.

5.2

Prediktivn´ı synchronizace

T´ım je myˇslena schopnost v´ıce procesové komunikace a predikován´ı ˇcasu. Kdyˇz proces sd´ıl´ı prostˇredky, je velmi ˇcasto nutná synchronizace kv˚ uli integritˇe dat. Kdyˇz nˇejak´ y proces pouˇz´ıvá sd´ılen´ y zdroj, jin´ y mus´ı ˇcekat. Tento ˇ ˇcas nen´ı pˇredem znám´ y. Reˇsen´ım m˚ uˇze b´ yt napˇr´ıklad maximáln´ı trván´ı semaforu, které ale negarantuje pˇr´ıstup kritického procesu k nekritickému. 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án´ı 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ázek 5.1: Doba dávky

5.3

Situaˇ cn´ı model

Proces kontroly poˇc´ıtaˇce provád´ı jeden nebo v´ıce kontroln´ıch a monitorovac´ıch funkc´ı. Kaˇzdá funkce je asociována s jedn´ım nebo v´ıce u ´koly. Nˇekteré z tˇechto u ´kol˚ u jsou provádˇeny v reakci na události v zaˇr´ızen´ı nebo sleduj´ı ˇ adn´ systém. Ostatn´ı jsou provádˇeny v reakci na události v jin´ ych u ´kolech. Z´ y zu ´kol˚ u nem˚ uˇze b´ yt proveden pˇred zahájen´ım akce, která jej vyvolává. Kaˇzd´ y zu ´kol˚ u mus´ı b´ yt dokonˇcen pˇred dobou, neˇzli je opˇet vyvolán plánovaˇcem.

5.3.1

´ Ulohy

1 ´ Ulohy jsou jednoduché programy, které maj´ı CPU v dan´ y ˇcas pro sebe. Návrhov´ y proces real-time aplikac´ı vyˇzaduje rozdˇelen´ı práce do u ´loh po ˇcástech problému. Kaˇzd´ yu ´kol má svou prioritu vykonáván´ı, vlastn´ı hodnoty ´ registr˚ u CPU, vlastn´ı zásobn´ık. Ulohy b´ yvaj´ı ˇcasto realizovány 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ávka2 . Dávky potˇrebuj´ı k bˇehu zdroje, jako je napˇr. ˇ CPU, s´ıt’, kritická sekce. Casto se hardwarové zdroje naz´ yvaj´ı ”procesory”. ˇ Casov´ y pr˚ ubˇeh dávky je na obr.5.1. Kromˇe programového kódu události, které urˇcuje programátor, je nutná 1 2

v ang. lit. task v ang. lit. oznaˇcov´ ano job

22


Situaˇcn´ı model

znát tyto ˇcasové u ´daje u ´lohy τi : ˇ uvolnˇen´ı dávky pˇripravené k bˇehu. • ri - Cas • Ci - Term´ın nejdelˇs´ıho bˇehu u ´lohy • Di - Relativn´ı term´ın dokonˇcen´ı dávky • Ti - Perioda volán´ı u ´lohy (pouze pro periodické). Kvalita plánován´ı u ´loh závis´ı na pˇresnosti v´ yˇse napsan´ ych u ´daj˚ u. Dále bychom mˇeli poˇc´ıtat s délkou vykonáván´ı operac´ı pˇrepnut´ı kontextu u ´lohy, volán´ı jin´ ych obsluˇzn´ ych funkc´ı jádra.

5.3.2

ˇ e cyklick´ Cistˇ e

Takto nahl´ıˇz´ıme na aplikace, které spouˇst´ı kaˇzdou u ´lohu periodicky. Maj´ı témˇeˇr nemˇenné poˇzadavky na systémové prostˇredky, napˇr. digitáln´ı regulátor, ˇr´ızen´ı letu a jiné.

5.3.3

Pˇ rev´ aˇ znˇ e cyklick´ e

Vˇetˇsina u ´loh je spouˇstˇena periodicky. Systém reaguje na nˇejaké extern´ı asynchronn´ı události, napˇr. modern´ı avionické a ˇr´ıdic´ı systémy.

5.3.4

Asynchronn´ı a predikovateln´ e

Poˇzadavky na systémové prostˇredky se mohou bˇehem po sobˇe jdouc´ıch spuˇstˇen´ı velmi liˇsit, ale maj´ı známé meze. Vˇetˇsina u ´loh nen´ı periodická, napˇr. multimediáln´ı komunikace, zpracován´ı signálu z radaru, sledován´ı objekt˚ ua dalˇs´ı.

5.3.5

Asynchronn´ı a nepredikovateln´ e

Pˇreváˇznˇe reaguj´ı na asynchronn´ı události. Kde obsluha je velmi sloˇzitá, napˇr. real-time simulace, real-time ˇr´ızen´ı atp. 23


5.3.6

Obsluha pˇreruˇsen´ı

ˇ Cinitel vyt´ıˇ zen´ı CPU

V tomto bodˇe si ukáˇzeme horn´ı mez vyuˇzit´ı procesoru. Definujeme (procesorové) vyt´ıˇzen´ı, jako ˇcasu procesoru stráven´ y nad sadou u ´loh. Jin´ ymi slovy je to také jedna m´ınus doba neˇcinnosti procesoru. Tedy CTii je zlomek ˇcasu procesoru stráven´ y vykonáván´ı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áni horn´ı poˇzadavkem, aby vˇsechny u ´lohy a jejich lh˚ uty na kritické okamˇziky byly splnitelé. Jak je zaj´ımavá doln´ı hranice vyt´ıˇzen´ı procesoru nechám na vaˇsem uváˇzen´ı. Naopak velmi zaj´ımav´ ym tématem je tedy ”Jak velké mus´ı b´ yt vyt´ıˇzen´ı procesoru, aby byla sada u ´loh plánovatelná?”. V pr˚ ubˇehu textu se vrát´ıme k tématu za pouˇzit´ı v´ ysledk˚ u práce vˇenuj´ıc´ı se statickému pˇridˇelován´ı priorit [CLLiu], k porovnán´ı nasimulovan´ ych hodnot s teoretick´ ymi hodnotami nˇekter´ ych algoritm˚ u.

5.4

Obsluha pˇ reruˇ sen´ı

Mechanismus plánován´ı obsluhy pˇreruˇsen´ı je pro RTOS kl´ıˇcovou vlastnost´ı. Pˇreruˇsovac´ı systém má své vlastn´ı priority, které 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átká, jak je to jen moˇzné. Pˇresto spousta zaˇr´ızen´ı potˇrebuje delˇs´ı dobu k prvádˇen´ı akc´ı po skonˇcen´ı pˇreruˇsen´ı, ty pak pˇrecházej´ı pod ISR.

5.5

Statick´ e rozvrhov´ an´ı

Nˇekdy oznaˇcované jako offline plánován´ı. Rozvrˇzen´ı u ´loh zde prob´ıhá jeˇstˇe pˇred jejich spuˇstˇen´ım. Vyhodnot´ı se jak ˇcasové tak i datové závislosti. Kaˇzd´ y proces je naplánován tak, aby byl vykonáván co nejdˇr´ıve. V´ ysledn´ y plán b´ yvá realizován listem plánu, 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á pˇredpokládá stejné parametry u ´loh a neumoˇzn ˇuje pˇrizp˚ usoben´ı se zmˇenám.

24


5.5.1

Dynamické rozvrhov´ an´ı

Rate Monotonic

Mechanismus v literatuˇre oznaˇcovan´ y jako Rate Monotonic je statick´ y algoritmus. Vycház´ı z pˇredpokladu, ˇze u ´lohy volané nejˇcastˇeji maj´ı v´ yznamnˇejˇs´ı prioritu. V´ yznamnost priority je tedy pˇr´ımo u ´mˇerná kmitoˇctu, odpov´ıdaj´ıc´ıho jej´ı periodˇe. Nepˇr´ımo u ´mˇerná je tedy statickému parametru T u ´lohy. Jestliˇze nen´ı mechanismus schopen zajistit plánovatelnost u ´loh, jsou ˇreˇsen´ım problému bud’to zmˇeny parametr˚ uu ´loh nebo pouˇzit´ı jiného plánovac´ıho algoritmu neˇz RM. Zmˇeny parametr˚ uu ´loh vedou na zmˇeny parametr˚ u celého systému, coˇz je vˇetˇsinou nepˇrijatelné. Pˇr´ıˇcinou selhán´ı 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ého pˇriˇrazován´ı priorit nepˇr´ımo u ´mˇernˇe hodnotˇe ˇcasové meze oznaˇcovan´ y zkratkou DM, popˇr´ıpadˇe IDA (Inverse Deadline). Vycház´ı z pˇredpokladu, ˇze u ´lohy s menˇs´ı hodnotou ˇcasové meze jsou v´ yznamnˇejˇs´ı. V´ yznamnost u ´lohy je v tomto pˇr´ıpadˇe nepˇr´ımo u ´mˇerná hodnotˇe statického parametru D u ´lohy. Tento mechanismus je schopn´ y dobˇre plánovat 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ánovat i u ´lohy, které nejsou plánovatelné pomoc´ı RM.

5.6

Dynamick´ e rozvrhov´ an´ı

Implementaˇcnˇe sloˇzitˇejˇs´ı je plánován´ı u ´loh za bˇehu systému. Kdy docház´ı k jejich anal´ yzám a plánován´ı podle v´ ysledk˚ u, ˇci dle podnˇet˚ u z okol´ı. K pˇreplánován´ı a zmˇenˇe priorit docház´ı podle parametr˚ u algoritm˚ u. V´ yhodou tohoto pˇr´ıstupu je právˇe neustálá schopnost se pˇrizp˚ usobovat zmˇenám. Tyto metody jsou vhodné zejména pro aperiodické a sporadické u ´lohy. Z velmi poˇcetné mnoˇziny jsme vybrali jednoduˇsˇs´ı EDF a LLF.

25


5.6.1

Dynamické rozvrhov´ an´ı

Earliest Deadline First

Z posledn´ıho statického plánován´ı bychom mohli vyvodit prvn´ı dynamické. Mechanismus EDF, jak jiˇz název naznaˇcuje, urˇcuje priority nepˇr´ımo u ´mˇernˇe dobˇe zb´ yvaj´ıc´ı v ˇcase t do uplynut´ı ˇcasové meze. Garantuje, ˇze v´ yznamnˇejˇs´ı priorita je v ˇcase t pˇriˇrazena tˇem u ´lohám, kter´ ym zb´ yvá do uplynut´ı doby splnˇen´ı ménˇe ˇcasu.

5.6.2

Least Laxity First

Algoritmy pˇrekonávaj´ıc´ı vlastnosti EDF samozˇrejmˇe existuj´ı, jedn´ım z nich je LLF. Tento algoritmus pˇriˇrazuje priority u ´lohám 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án´ı kontextu a vˇetˇs´ı poˇcet preempc´ı.

26

6 Implementace V této kapitole si ukáˇzeme, jak probˇehlo doimplementován´ı vybran´ ych plánovac´ıch algoritm˚ u. Snahou bylo co nejv´ıce vyuˇz´ıt stávaj´ıc´ıho kódu, velikost rozˇs´ıˇren´ı by mˇela b´ yt rovnˇeˇz pˇrijatelná. Postupnˇe zde probereme u ´pravy potˇrebné pro kompilaci kódu, poté zakládán´ı u ´loh podle modelu, rozˇs´ıˇren´ı task control blocku. Poté se budeme vˇenovat implementaci algoritm˚ u v´ ybˇeru a nakonec zmˇenˇe priorit a následnému v´ ybˇeru spuˇstˇen´ı.

6.1

Modifikace zdrojov´ ych k´ od˚ u

Bez zásahu do origináln´ıho kódu se neobejdeme, avˇsak jediné nad ˇc´ım bychom u ´pravy mˇeli provádˇet, jsou pouze ˇcásti kódu definuj´ıc´ı pˇrekládané kousky systému. V´ ykonn´ y kód by mˇel z˚ ustat beze zmˇen a nezavedeme do nˇej chyby vedouc´ı k neoˇcekávanému chován´ı. Po anal´ yze zdrojov´ ych kód˚ u, je evidentn´ı, ˇze budeme modifikovat soubory os core.c a pˇridáme konfiguraˇcn´ı makra do os cfg.h. Ideáln´ı by bylo samozˇrejmˇe nemˇenit p˚ uvodn´ı kód v˚ ubec, taková situace v jazyce C nen´ı moˇzná. Potˇrebovali bychom na základˇe definován´ı 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án´ı funkc´ı a metod, proto abychom zachovali kódovou 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ánován´ı. V celku jednoduˇse a elegantnˇe jsme z´ıskali jednoduché volby mezi p˚ uvodn´ım plánován´ım a vlastn´ım rozˇs´ıˇren´ım. Nyn´ı je nutné oznaˇcit makrem funkce, které budeme novˇe navrhovat, podm´ınkou zachycenou preprocesorem k podm´ınˇenému 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án´ı zaimplementován´ı podm´ınek pro kompilaci je souˇcást´ı pˇr´ılohy A.

6.2

Moˇ znosti jak vytvoˇ rit u ´ lohu

Závislosti na p˚ uvodn´ıch funkc´ıch µC/OS-II máme obalené podm´ınkami ˇ pˇrekladu. V kapitole 5 jsme si definovali ˇcasové parametry u ´loh. Casov´ e parametry si zde nem˚ uˇzeme pˇredstavit jako veliˇcinu ˇcasu, tedy nezadávaj´ı se napˇr. sekundy ani minuty. V rozˇs´ıˇren´ı je oznaˇcujeme ˇcasov´ ym u ´dajem poˇcet tick˚ u systému. V podstatˇe jsou dva zp˚ usoby jak zavést parametry do systému a to • napsat nové funkce na vytváˇren´ı u ´loh s parametry • vyuˇz´ıt OSTaskCreateExt

6.2.1

Vlastn´ı funkce na vytv´ aˇ ren´ı u ´ loh

Napsat nové funkce pro vytváˇren´ı u ´loh nen´ı nejvhodnˇejˇs´ı ˇreˇsen´ı. Funkce by v podstatˇe kop´ırovali funkˇcnost stávaj´ıc´ıch, k tomu by zavedli do systému parametry. Jejich pˇridán´ı by znamenalo vyˇreˇsen´ı problému kam a jak nejlépe je zaˇradit. Zda je pˇridat napˇr. jako samostatn´ y seznam podle priorit u ´loh. To by zˇrejmˇe nebylo dobré, vedlo by to k zatˇeˇzován´ı systému 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ódech je struktura TCB vytvoˇrena tak, aby byly voleny jednotlivé ˇcásti v závislosti na konfiguraci v os cfg.h. To mimo jiné dokáˇze uspoˇrit znaˇcnou ˇcást vyuˇzité 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ávaj´ıc´ıho TCB. 28

Implementace


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ázce zdrojového kódu jsou vˇsechny vlastnosti naˇseho modelu, spuˇstˇen´ı u ´lohy, doba opakován´ı, maximáln´ı doba vykonáván´ı a mezn´ı term´ın splnˇen´ı. Pro nˇekteré algoritmy je vhodné udrˇzovat hodnotu, kolik jiˇz u ´loha strávila ˇcasu vykonáván´ım. Vˇsimnˇeme si obalen´ı podm´ınˇen´ ym pˇrekladem, kter´ y tyto informace pˇridá v pˇr´ıpadˇe pouˇzit´ı jiného neˇz v´ ychoz´ıho plánován´ı.

29

Implementace

6.2.3


Vyuˇ zit´ı OSTaskCreateExt

Pˇredchoz´ı varianta poˇc´ıtá s mal´ ym, ale pˇreci jen zásahem do zásadn´ı ˇcásti systému. 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áci s bˇeˇzn´ ym systémem kv˚ uli vˇetˇs´ı variabilitˇe pˇredáván´ı dat u ´lohám.

6.2.4

Standartn´ı parametry

task pdata

Ukazatel na v´ ykonn´ y kód u ´lohy. Je ukazatel na data pˇredávané jako parametr u ´loze. Napˇr´ıklad vlákno obsluhuj´ıc´ı asynchronn´ı sériov´ y port, pomoc´ı nˇej m˚ uˇze informovat o rychlosti pˇrenosu, chybách a jiné obsluze portu. ptos V tomto parametru je ukazatel na vrchol zásobn´ıku. Do zásobn´ıku se ukládaj´ı lokáln´ı promˇenné, parametry funkc´ı, návratové adresy a registry CPU pro obnovu po pˇreruˇsen´ı. ˇ ım vyˇsˇs´ı ˇc´ıslo obprio Urˇcuje poˇcáteˇcn´ı, unikátn´ı prioritu vlákna. C´ sahuje, t´ım menˇs´ı prioritu u ´loha má. id Oznaˇcen´ı ˇc´ıseln´ ym identifikátorem vláken. pbos Ukazatel na poˇcátek nebo také dno zásobn´ıku. stk size Velikost zásobn´ıku u ´lohy ve zvolené ˇs´ıˇrce, pˇri pouˇzit´ı INT8U je to poˇcet byt˚ u, pˇri pouˇzit´ı INT16U se jedná o poˇcet dvou bytov´ ych blok˚ u atd. ˇ opt Sestnácti bitové nastaven´ı, z ˇcehoˇz doln´ıch 8 bit˚ u pouˇz´ıvá µC/OSII a horn´ıch 8 bit˚ u je urˇceno uˇzivateli. pext V této promˇenné m˚ uˇzeme m´ıt ukazatel na uˇzivatelskou datovou strukturu. Tomuto pointru bude vˇenován následuj´ıc´ı kapitola 6.2.5. Nastaven´ı ˇrady parametr˚ u je záleˇzitost´ı konfigurace systému, k tomu dobˇre poslouˇz´ı [MicroII]. Ukázkové 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


Parametry modelu u ´ lohy

K zaveden´ı parametr˚ u u ´lohy pouˇzijeme parametr pext. Obecnˇe slouˇz´ı k pˇredáván´ı uˇzivatelsky definovan´ ych oblast´ı pamˇeti, typicky datov´ ych struktur. Nic nám tedy nebrán´ı 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éto struktuˇre udrˇzujeme ˇcasové u ´daje u ´lohy, k tomu jeˇstˇe stále m˚ uˇzeme pˇridat uˇzivatelská data. D˚ uleˇzité 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ále. Casov´ e parametry u ´loh jsou d˚ uleˇzité pro samotné plánovac´ı algoritmy, a proto spoléhaj´ı na existenci této struktury. D˚ uleˇzité je, aby i systémové u ´lohy obsahovaly dodateˇcné ˇcasové parametry. V µC/OS-II je obvykle nˇekolik systémov´ ych u ´loh. Pro funkˇcnost plánován´ı je nutné urˇcit jakou prioritu pˇriˇradit systémov´ ym vlákn˚ um. Situace se usnadˇ nuje t´ım, ˇze systémové u ´lohy jsou bud’to nejvyˇsˇs´ı priority, anebo nejniˇzˇs´ı. Uvaˇzme nejprve nejniˇzˇs´ı, vlákna idle task a stat task. Maj´ı pevnˇe dané priority, proto m˚ uˇzeme snadno pˇridat strukturu s ˇcasov´ ymi parametry. Inicializaˇcn´ı funkce mus´ı zjistit dodán´ı správn´ ych hodnot, odkaz na správné TCB u ´lohy je dan´ y systémov´ 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émového ˇcasovaˇce, kter´ y bˇeˇz´ı s pˇredem stanovenou prioritou. Aby bylo moˇzné ˇcasové u ´daje mˇeˇrit, mus´ı b´ yt zprovoznˇen systémov´ y ˇcas. Tato ˇcást se provád´ı pˇri portaci systému na vybranou architekturu, proto bylo vyuˇzito portace na H8S [PJer].

6.3


V této fázi máme dle konfiguraˇcn´ıho souboru moˇznost vybrat bud’to plánován´ı p˚ uvodn´ı, nebo extern´ı. Abychom jej mohli zavést, bylo nutné v souboru ucos ii.c uvést, o kter´ y soubor se jedná. #include

V nataˇzeném souboru jsou shromáˇzdˇeny zásadn´ı funkˇcn´ı bloky pro rozˇs´ıˇrenou funkci plánován´ı. Volbou konfigurace o jeho pouˇzit´ı, jsme zajistili zkompilován´ı vlastn´ı, témˇeˇr totoˇzné funkce OS SchedNew(). Jej´ı smysl spoˇc´ıvá ve vybrán´ı vlákna, které je ve stavu ready a má nejvˇetˇs´ı prioritu. Celou tuto metodu jsme pˇrepsali do podoby vyuˇz´ıvaj´ıc´ı bloky, pˇrekládané na základˇe zvoleného algoritmu. V´ yˇse uvedená funkce má za u ´kol proj´ıt vˇsechny u ´lohy. Ovˇeˇrit zda jsou ve stavu ready, zda nenesou informaci o uspán´ı. Dále mus´ı zajistit aktuáln´ı ˇcasové 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áz´ıme jednu u ´lohu po drohé, z bloku na kter´ y máme ukazatel pext, naˇcteme potˇrebné u ´daje pro vybran´ y algoritmus. V zásadˇe nen´ı rozd´ıl mezi volbou dynamického nebo statického plánován´ı, rozd´ıly mezi zvolen´ ym algoritmem jsou v kódu sp´ıˇse kosmetické.

32

Implementace

6.3.1


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án´ı plánovaˇce, podle statick´ ych parametr˚ u. Nev´ yhoda tohoto ˇreˇsen´ı je zcela evidentn´ı. Jednak by se jednalo o poˇcáteˇ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é plánován´ı s pouˇzit´ım EDF, ukládá do parametr˚ u u ´loh mezn´ı ˇcas splnˇen´ı, v závislosti 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á nám tedy neˇz urˇcit dobu vstupu do dˇeje. Nejjednoduˇsˇs´ı a námi pouˇzit´ y zp˚ usob je OST IM E + T , kde OS TIME je aktuáln´ı doba strávená bˇehem systému a k n´ı pˇripoˇctená perioda. Abychom se nepˇripravili o prvn´ı periodu bˇehu u ´loh, ˇrekneme, ˇze prvn´ı doba vstupu, je 33

Implementace


právˇe ta doba, kdy se ji pokouˇs´ıme poprvé urˇcit. Abychom co nejménˇe omezili rychlost systému, jsou ˇcasové parametry dopoˇcteny tˇesnˇe pˇred porovnán´ı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ávislosti na ˇcase um´ıme urˇcit, chyb´ı nám tedy doba, jak dlouho uˇz u ´loha zpracovávala sv˚ uj u ´kol. To provedeme odeˇcten´ım aktuáln´ı doby bˇehu systému od doby, kdy bylo vlákno pˇreruˇseno. Jak je toto provádˇeno, bude popsáno v kapitole 6.4. Nav´ıc jsme uˇzivateli dali moˇznost zjistit, zda nˇekterá u ´loha nestihla svou deadline.

6.3.3

Zmˇ ena priorit

Nyn´ı jsme ve fázi, kdy um´ıme zjistit parametry u ´loh a kdy podle nich jsme schopni urˇcit u ´lohu ke spuˇstˇen´ı. Právˇe v této ˇcásti zpracován´ı jsme schopni dodat uˇzivateli informace o minut´ı deadline. Známe totiˇz posledn´ı u ´lohu ve stavu ready a i tu kterou se chystáme 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ého, tak pˇri pouˇzit´ı dynamického plánován´ı je situace jasnˇe dána. Nen´ı tˇreba mˇenit priority v systému. Pˇri pr˚ uchodu TCB listem vyhledáme nejmenˇs´ı hodnotu D(t) nebo v pˇr´ıpadˇe LLF L(t). Nam´ısto aby byla priorita aktuálnˇe nejd˚ uleˇzitˇejˇs´ı u ´lohy vybrána pomoc´ı mapy priorit, vybranou prioritu nastav´ıme do globáln´ı promˇenné OSPrioHighRdy.

6.4

Sbˇ er parametr˚ uu ´ loh

Zmˇenit dle priority u ´lohu um´ıme, zb´ yvá urˇcit data, podle kter´ ych se tento proces dˇeje. Základn´ı parametry, tedy periodu spouˇstˇen´ı, vstup do periody, mezn´ı term´ın a maximáln´ı vykonáván´ı u ´lohy, pro statické i dynamické algoritmy mus´ı zadat v´ yvojáˇr aplikace. K tomuto u ´ˇcelu byla vytvoˇrena inicializaˇcn´ı funkce. Jej´ı v´ yhodou je hlavnˇe odpadnut´ı vynulován´ı alokované pamˇeti, na kterou v´ yvojáˇ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éto práce, je sbˇer informac´ı pro plánovac´ı algoritmy. Do jaké struktury jsou data sb´ırána, jsme si uvedli v kapitole 35

Implementace


6.2.5. Tato struktura se mus´ı pr˚ ubˇeˇznˇe aktualizovat pro kaˇzdé vlákno. Je tedy zˇrejmé, ˇze se data budou sb´ırat pˇri práci u ´lohy. Samozˇrejmˇe bychom mohli dát toto privilegium uˇzivateli, to by zp˚ usobilo nˇekolik problém˚ u, jednak nen´ı jisté, ˇze by uˇzivatel správnˇe aktualizoval u ´daje. A hlavnˇe co je d˚ uleˇzitˇejˇs´ı, uˇzivatelská u ´loha m˚ uˇze b´ yt náhodnˇe pˇreruˇsena. Pokud bychom napˇr. sb´ırali data na zaˇcátku, uprostˇred a na konci smyˇcky. Dostávali bychom jen statistické u ´daje, ˇc´ım déle by systém fungoval, t´ım lepˇs´ı bychom z´ıskali. Aˇc by se jednalo o velmi jednoduchou implementaci, byla by velmi nevhodná. Lepˇs´ı volbou je implementace do systému. Vˇsimnˇeme si, ˇze po naplánován´ı u ´loh, docház´ı k pˇrepnut´ı kontextu procesoru. To je také ve chv´ıli, kdy v´ıme, jaká u ´loha pracovala a jaká bude pracovat. Zde máme bud’to variantu bez zásahu do souboru os core.c nebo s mal´ ym zásahem. Totiˇz pˇri portaci µC/OS-II se mus´ı vytváˇret funkce OSIntCtxSw, ta je obvykle napsána v jazyce symbolick´ ych adres. Slouˇz´ı k vytvoˇren´ı softwarového pˇreruˇsen´ı pro pˇrepnut´ı u ´loh. Spolu s n´ı se vytváˇr´ı prototypy dalˇs´ıch deseti uˇzivatelsk´ ych funkc´ı, z nichˇz OSTaskSwHook je volána z OSIntCtxSw. Podm´ınkou by tedy bylo, aby v´ yvojáˇr aplikace vˇzdy do dané funkce um´ıstil naˇsi OS ShedDataStart, která by uloˇzila dynamické parametry pˇreruˇsené u ´lohy. Nové u ´loze by se poˇcáteˇcn´ı hodnoty nemohli nastavit a museli bychom v jedné funkci zjistit prioritu nové u ´lohy a j´ı nastavit poˇcáteˇcn´ı parametry. Hlavn´ı nev´ yhodou by byla nutnost zásahu uˇzivatele. Naproti tomu staˇc´ı m´ırnˇe upravit soubor os core.c, pˇresnˇeji do funkce OS Sched a také do funkce ukonˇcen´ı obsluhy pˇreruˇsen´ı OSIntExit, pˇridán´ım podm´ınky pro pˇreklad pouˇzit´ı dynamického plánován´ı. 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é pro sbˇer dat je abychom neuˇz´ıvali operátor˚ u násoben´ı a dˇelen´ı, aˇc mikroprocesory ˇc´ım dál ˇcastˇeji obsahuj´ı sofistikovanˇejˇs´ı aritmeticko-logické jednotky, patˇr´ı stále k nejpomaleji provádˇen´ ym operac´ım. Kde by nás to zˇrejmˇe velmi svádˇelo, jsou v´ ypoˇcty aktuáln´ıch deadline a period, respektive vstup˚ uu ´loh do dˇeje. Napˇr´ıklad vypoˇcten´ı aktuáln´ı deadline da ct = pext− > OST CBP eriodStart+pext− > OST CBDeadline). Bylo tedy nutné zaˇr´ıdit, aby se vˇzdy správnˇe dopoˇcetl zaˇcátek periody a to i v pˇr´ıpadˇe, ˇze dojde k 36

Implementace


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ázek 6.1: Pohled na implementované plánován´ı pˇrekroˇcen´ı deadline. Následuj´ıc´ı v´ yvojov´ y diagram na obr.6.1 statického plánován´ı ukazuje cel´ y cyklus.

37

7 Zhodnocen´ı ˇreˇsen´ı Jeˇstˇe neˇz se pˇresuneme k porovnán´ı práce, ukaˇzme si jednoduch´ y pˇr´ıklad. Uvaˇzme plánován´ı Rate Monotocnic mechanismem, pouhé ˇctyˇri u ´lohy s parametry prvn´ı u ´lohy τ0 (r0 , C0 , D0 , T0 ) = τ0 (0, 3, 5, 20), druhé τ1 (r1 , C1 , D1 , T1 ) = τ1 (0, 3, 7, 12), tˇret´ı τ2 (r2 , C2 , D2 , T2 ) = τ2 (0, 4, 10, 10) a ˇctvrté τ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énˇe d˚ uleˇzitou v poˇrad´ı τ2 , τ1 , τ0 , τ3 nebo τ2 , τ1 , τ3 , τ0 . Plán generovan´ y na základˇe priorit je vyobrazen na obrázku 7.1, kde v ˇcase t = 0 vzniknout poˇzadavky na souˇcasné vyvolán´ı 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ávˇe tato u ´loha. Zbylé 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á ze zb´ yvaj´ıc´ıch má nejvyˇsˇs´ı prioritu. Poté 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ánovatelnost mnoˇziny u ´loh RTOS, jak je tomu v´ yˇse, vzniká problém ˇreˇsiteln´ y dvˇema základn´ımi zp˚ usoby. Prvn´ı zp˚ usob spoˇc´ıvá ve zmˇenˇe parametr˚ u RT u ´loh s c´ılem zajistit plánovatelnost dané 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ém. Zcela jistˇe by hrozilo jejich nesplnˇen´ı a hodlám si tvrdit i dost nevyzpytatelné chován´ı. Druhé ˇreˇsen´ı spoˇc´ıvá v pouˇzit´ı jiného zp˚ usobu plánován´ı, algoritmus RM optimálnˇe plánuje 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ázek 7.1: RM plán

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ázek 7.2: DM plán Kdyˇz bychom na uvedené u ´lohy vzaly mechanismus DM, zjistili bychom, ˇze jsou j´ım plánovatelné. Tento algoritmus je pro nás vˇsak okrajovou záleˇzitost´ı, uvedeme alespoˇ n v´ ysledn´ y plán na 7.1. Zopakujme alespoˇ n, ˇze plánován´ı je nepˇr´ımo u ´mˇerné parametru D. Nemˇen ˇme podm´ınky a naplánujme u ´lohy pomoc´ı algoritmu EDF. Tento zp˚ usob plánován´ı pˇrep´ıná 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áln´ıch priorit kaˇzdé u ´lohy a v´ ysledné hodnoty ukazuje tabulka 7.Tabulka EDF plán

τ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án

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án

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án´ı vznikly modelové u ´lohy. Nevykonávaj´ı ˇzádnou funkci, pouze demonstruj´ı okolnosti bˇehu systému. Mohli bychom si pˇredstavit, ˇze 39



´ simulujeme interakci ˇctyˇr u ´loh. Uloha tedy nevykonává nic, na zaˇcátku si inicializuje ˇcasové parametry. Spust´ı ˇcekán´ı podle stanovené maximáln´ı doby bˇehu. Poté odeˇcte u ´daje o skonˇcen´ı a pˇredá ˇr´ızen´ı OS. Vytváˇren´ı dalˇs´ıch deadline a zaˇcátk˚ u period jsou v rozˇs´ıˇren´ı záleˇzitost´ı plánovaˇce. Pouze pro p˚ uvodn´ı ˇreˇsen´ı se mus´ı u ´lohy transformovat do podoby následuj´ı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áln´ıho plánovaˇce, museli jsme implementovat do uˇzivatelské funkce App TimeTickHook() zp˚ usob probouzen´ı vláken pro periodické u ´lohy. Ten kontroluje dobu uplynut´ı u ´lohy od uspán´ı. 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



}

Na pˇr´ıkladu pouˇzit´ı standardn´ıho plánovaˇce, je v dobˇe OSTime = 18 máme posledn´ı tick na vykonán´ı 3 tickové u ´lohy. Po dokonˇcen´ı oznám´ıme miss. V dalˇs´ım pr˚ ubˇehu se hodnoty miss objevuj´ı ˇc´ım dál ˇcastˇeji. V testován´ı jsme pouˇzili schopnost reagovat na minut´ı kritické meze a simulovali jsme jej´ı opravu. Aby se musela kontrolovat po kaˇzdém 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


3 1 2

OSTIME =0x0EC OSTIME =0x0F1 OSTIME =0x0F4

0

OSTIME =0x0FC

1 2 3 1 2


0

OSTIME =0x111

1 3

OSTIME =0x119 OSTIME =0x11C

2 0

OSTIME =0x11D OSTIME =0x126

1 2 3 1 2


0

OSTIME =0x13B

=0x0D5 =0x0D8 =0x0E2 =0x0E5 =0x0E7

=0x0FF =0x102 =0x106 =0x10C =0x10F

=0x129 =0x12C =0x135 =0x136 =0x139

41



Uvedené poˇcáteˇcn´ı hodnoty staˇc´ı k usouzen´ı, ˇze p˚ uvodn´ı plánován´ı nijak neusnadˇ nuje práci v´ yvojáˇre. Vˇsechny parametry mus´ı dobˇre zváˇzit a sám urˇcit priority v posloupnosti, tak aby se vlákna správnˇe vykonávala. Na dalˇs´ı ukázce viz obr.7.3 vid´ıme selhán´ı statick´ ych algoritm˚ u. Vezmˇeme parametry u ´loh z u ´vodn´ıho pˇr´ıkladu. Teoreticky jsme si ukázali, ˇze statické algoritmy selˇzou. Aˇz algoritmus EDF je schopn´ y vybrat vhodnou u ´lohu a plán dokonˇcit bez ohroˇzen´ı stability celku. Priority jsou pro u ´lohy τ0 aˇz τ3 zadávány v poˇrad´ı 11a14. Na p˚ uvodn´ım algoritmu nemáme ˇsanci ze systému zjistit, zda se u ´loha stihla vykonat v ˇcas. Leda bychom si zavedli vlastn´ı poˇc´ıtán´ı v taskách. 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á, aby si uˇzivatel nastavil na jak dlouho je u ´loha suspendována. Proto jsme pro otestován´ı p˚ uvodn´ıho plánován´ı doimplementovali uˇzivatelskou metodu OSTaskIdleHook(). V n´ıˇz jsme u ´lohy po uplynut´ı uspán´ı opˇet aktivovali. Malá zmˇena ve v´ ybˇeru a hned jsme schopni splnit mnohem vˇetˇs´ı ˇcást u ´loh. I pˇresto vˇsak docház´ı k situac´ım, ˇze nejsme schopni zaruˇcit splnˇen´ı u ´loh. V následuj´ıc´ı ˇcásti na obr.7.4 máme porovnán´ı implementovan´ ych dynamick´ ych algoritm˚ u. Na prvn´ım dynamickém algoritmu jsme si ovˇeˇrili, zda jsme teoretické hodnoty spoˇcetli do tabulky 7.Tabulka EDF plán správnˇe. Na druhém vid´ıme jedineˇcnost pˇr´ıstupu ke zpracován´ı a ˇcastˇejˇs´ı pˇrep´ınán´ı kontextu mezi u ´lohami. Algoritmus least laxity first vyb´ırá u ´lohy ve správném poˇrad´ı, tak aby nedocházelo k miss. Kv˚ uli ˇcastému pˇrep´ınán´ı kontextu algoritmu LLF, museli b´ yt vstupy pro simulátor doplnˇeny i do souboru s rozˇs´ıˇren´ım. Aˇckoli jsme poˇcáteˇcn´ı hodnoty spoˇcetli správnˇe, docház´ı k minut´ı deadline u obou algoritm˚ u, které nejsme témˇeˇr schopni odhalit jinak, neˇzli simulován´ım. Zv´ yˇse uveden´ ych v´ ystup˚ u vypl´ yvaj´ı následuj´ıc´ı povinnosti v´ yvojáˇre. • Dokonale analyzovat pouˇzitou harwarovou platformu • Analyzovat ˇcasové parametry vytvoˇren´ ych u ´loh • Ovˇeˇrit simulacemi funkˇcnost • Upravit kritická m´ısta • Pˇr´ıpadnˇe schopnˇe reagovat na kritická m´ısta 42



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


=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ázek 7.3: Statické 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


=0x104 =0x108 =0x10C =0x111

=0x13B =0x13F =0x140 =0x144 =0x147



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


2 0

OSTIME =0x11C OSTIME =0x120

1

OSTIME =0x125

2 1


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ázek 7.4: Dynamické 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


Nevýhody ˇreˇsen´ı

• !Nezapomenout na pˇreruˇsen´ı, které kritické 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é 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ává fungovat a jin´ y to jeˇstˇe zvládne, se povedlo jen pro statick´ y rate monotonic. D´ıky ˇrazen´ı podle period, nen´ı ani u velmi prost´ ych u ´loh zajistit správn´ y bˇeh. Pro zb´ yvaj´ıc´ı algoritmy je situace mnohem lepˇs´ı, z pozorován´ı v tabulce 7.1.Vybrané 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ánovatelnosti bychom mohli oznaˇcit Ci ≤ Dmin . Vˇsechny simulované u ´lohy prob´ıhaly alespoˇ n do ˇcasu OSTime 0x200, kde jiˇz byla velká pravdˇepodobnost, ˇze budeme schopni rozpoznat problémové u ´lohy. Aplikace k otestován´ı jsou na pˇriloˇzeném CD v adresáˇri \function workspace\WorkSpace\IntrApp.

7.2

Nev´ yhody ˇ reˇ sen´ı

Pod´ıváme-li se na ˇcasové parametry u ´loh, mus´ıme si uvˇedomit, ˇze hodnoty mus´ı b´ yt v souladu s ˇcasov´ ymi parametry systému. Napˇr. u ´loha τ1 (0, 3, 7, 12) hodnoty udávaj´ı poˇcet tik˚ u. Kolik instrukc´ı za jeden tik se provede, je závislé 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ém ménˇe v´ ykonné platformˇe. Mohl by systém b´ yt nestabiln´ı a nepˇredv´ıdateln´ y. Souvislost hledejme ve správném nastaven´ı poˇctu tik˚ u za sekundu. Zejména z d˚ uvodu, ˇze vyhledán´ı u ´lohy s nejvyˇsˇs´ı prioritou, po té pˇrepnout kontext procesoru by trvalo n-krát déle, neˇz u ´loha podle parametr˚ u od v´ yvojáˇre. 45


Výhody ˇreˇsen´ı

Pokud by u ´loha byla opravdu provádˇela svou ˇcinnost, jak uvedl. Bylo by vhodné uvaˇzovat pˇrinejmenˇs´ım o pouˇzit´ı p˚ uvodn´ıho plánován´ı. Pˇrenáˇs´ı se tak zodpovˇednost na v´ yvojáˇre pouˇz´ıvaj´ıc´ı rozˇs´ıˇren´ı, kter´ y mus´ı velmi dobˇre znát podm´ınky pouˇzit´ı. V pˇredchoz´ı ˇcásti jsme zm´ınili, ˇze doba vyhledán´ı u ´lohy nejvyˇsˇs´ı priority prodluˇzuje dobu mezi pˇrepnut´ım kontextu. Sbˇer dat pro pˇreplánován´ı by mohl b´ yt pˇresunut do rukou v´ yvojáˇre, aby jej vhodnˇe vyuˇz´ıval ve funkci OSTaskSwHook, ta je volána jako uˇzivatelská pˇri pˇrepnut´ı kontextu. Sám v´ yvojáˇ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ám, byla pˇri dokonˇcován´ı práce zavrhnuta. Zejména z d˚ uvodu znaˇcného zvˇetˇsen´ı reˇzie jádra systému oproti vlastn´ı funkci u ´loh. Problém by spoˇc´ıval v ˇrad´ıc´ım algoritmu, at’ bychom vybrali jak´ ykoli jednoduˇse implementovateln´ y v jazyce C, nejlépe 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ádˇelo 20 instrukc´ı vˇcetnˇe návratov´ ych. V obou pˇr´ıpadech d´ıky pˇridán´ı inicializace vzrostl poˇcet instrukc´ı o OSN S Y ST ASK, kter´ ym se mus´ı dodat ideáln´ı ˇcasové parametry. Samotnému plánován´ı vzrostl poˇcet instrukc´ı n-násobnˇe na hodnotu N · 60 + 50, v závislosti na poˇctu u ´loh, nejv´ıce jej ovlivˇ nuje zaznamenáván´ı správn´ ych u ´daj˚ u. V´ ybˇer priority pˇresto z˚ ustal stále sloˇzitosti O(N ).

7.3

V´ yhody ˇ reˇ sen´ı

Zakomponován´ım naˇsich plánovac´ıch metod odpadá nutnost v´ yvojáˇre pˇriˇradit priority u ´lohám, tak by plán splnily. Zejména d´ıky dynamick´ ym algoritm˚ um, je mnoˇzina splnˇen´ ych u ´loh vˇetˇs´ı neˇzli p˚ uvodn´ı plánovatelná mnoˇzina. Zadán´ı práce povaˇzuji za splnˇené, pouze se mohla vˇetˇs´ı ˇcást vˇenovat simulac´ım a jejich porovnán´ı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ány formou vyz´ yván´ı u ´loh. Reˇzii dalˇs´ı u ´lohy v systému jsme se vyhnuli d´ıky kontrole priorit pˇri návratu z pˇreruˇsen´ı. Nav´ıc jsme pˇripravili model odpoˇctu ˇcasov´ ych u ´daj˚ u i pro jiné aplikace, kter´ y m˚ uˇzeme pouˇz´ıt i bez zapnutého rozˇs´ıˇren´ı. 46


Výhody ˇreˇsen´ı

Pokud známe velmi dobˇre pouˇzitou hardwarovou platformu a jsme schopni správnˇe urˇcit okolnosti dˇeje. Dosáhneme nejlepˇs´ıch v´ ysledk˚ u plánovaˇ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ánovaˇc je deterministick´ y. Pˇri shodˇe parametr˚ u totiˇz nehroz´ı, ˇze pokaˇzdé vybere jinou u ´lohu. Vybere totiˇz tu u ´lohu, která byla do TCB zadána dˇr´ıv. Systém µC/OS-II se zapracovan´ ymi algoritmy, je schopn´ y reagovat na události opoˇzdˇen´ı zpracován´ı u ´lohy. Je tedy na uˇzivateli jak se k tomu postav´ı.

47

8 Závˇer Tato práce se vˇenuje nejbˇeˇznˇejˇs´ım plánovac´ım algoritm˚ um Real-time operaˇcn´ım systém˚ um. Statické algoritmy rate monotonic a deadline monotonic spolu s dynamick´ ymi early deadline first a least laxity jsou implementovány do RTOS µC/OS-II. Aby bylo implementován´ı moˇzné, jsou u ´vodn´ı kapitoly vˇenovány u ´vodu do problematiky samotn´ ych RT systém˚ um a nejv´ıce právˇe µC/OS-II. V kapitole 5 jsou vysvˇetleny vytvoˇrené plánovac´ı algoritmy. Jejichˇz implementace je popsána v následuj´ıc´ı kapitole 6, spolu s popisem d˚ uleˇzit´ ych blok˚ u zdrojové kódu. V pˇredposledn´ı kapitole 7 jsou shrnuty pˇripom´ınky k realizaci. Dále jsou zde v´ ysledky simulac´ı, spolu s modelovou testovac´ı u ´lohou. Kv˚ uli n´ıˇz bylo udrˇzován´ı u ´daj˚ uou ´lohách 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á dokonalá znalost architektury mikroprocesoru. V ostatn´ıch pˇr´ıpadech jsou doborou volbou v´ ybˇeru u ´loh jak podle statické hodnoty deadline, tak i jej´ı závislosti na ˇcase. V´ ysledky simulace ukázaly, ˇze implementované rozˇs´ıˇren´ı je lepˇs´ı volbou pro v´ ybˇer u ´loh. Práce splˇ nuje vˇsechny body zadán´ı, 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ório de Mecatrônica EESC – Universidade de São Paulo, 2009 [Sojka] M. Sojka: Programov´ an´ı systém˚ u re´ alného ˇcasu pˇrednáˇsky ˇ CVUT, Praha, záˇ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áˇ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ému 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ávrh ˇcasovˇe kritických systém˚ 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ém Open Shortest Path First akronym pro Portable Operating System Interface Routing Information Protocol Reduced Instruction Set Computer Real-Time Real-time Operaˇcn´ı Systém 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áken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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ávky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.1

Pohled na implementované plánován´ı . . . . . . . . . . . . . . 37

7.1

RM plán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2

DM plán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.3

Statické algoritmy . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.4

Dynamické algoritmy . . . . . . . . . . . . . . . . . . . . . . . 44

A.1 Prvn´ı spuˇstˇen´ı HEW . . . . . . . . . . . . . . . . . . . . . . . 56 A.2 Otevˇren´ı projektu . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.3 V´ yvojové prostˇred´ı HEW . . . . . . . . . . . . . . . . . . . . . 57 A.4 Adresn´ı prostor simulátoru HEW . . . . . . . . . . . . . . . . 57

53

Seznam tabulek

54

A Vývojová prostˇred´ı a nastaven´ı µC/OS-II A Nebudeme se vˇenovat standardn´ım moˇznostem nastaven´ı systému. Pouze si ukáˇzeme jak vyuˇz´ıt pˇridané vlastnosti systému. Jak je správnˇe nakonfigurovat. K tomu nepotˇrebujeme ˇzádné v´ yvojové prostˇred´ı, staˇc´ı nám libovoln´ y textov´ y editor. Po té co nakonfigurujeme pˇrekládané ˇcásti systému, ukáˇzeme si jak na instalovaném prostˇred´ı upraven´ y kód pˇreloˇzit. Zmiˇ nované materiály jsou um´ıstˇené na pˇriloˇzeném záznamovém mediu.

A.1

V´ yvojov´ e prostˇ red´ı

K v´ yvoji aplikace µC/OS-II bylo pouˇzito v´ yvojového prostˇred´ı Highperformance Embedded Workshop verze 4.08.00.011 dostupné na mediu, \software\h8v7000 ev.exe, kde jsou dostupné také rozd´ılové aktulizace. Novˇejˇs´ı jsou ke staˇzen´ı z hlavn´ıch stránek [Ren]. Ke staˇzen´ı je nutné b´ yt zaregistrován. 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ánkách naleznete také manuály k v´ yvojovému kitu EVB2633F. K prostˇred´ı dále nainstalujeme GNUH8 Windows Tool Chain(ELF), \software\GNUH8v1003-ELF.exe, nejlépe v nejnovˇejˇs´ı verzi, ke staˇzen´ı jsou opˇet po registraci na [KPIT]. Pˇri instalaci je vyˇzadován aktivaˇcn´ı kód zaslan´ y emailem. Po naistalován´ı je pˇrekladaˇc integrován do prostˇred´ı HEW. Ke staˇzen´ı jsou zde k dispozici téˇz manuály k pˇrekladaˇci a assembleru. HEW obvykle ukládá pracovn´ı sloˇzku jako c:\Workspace\. Doporuˇcil bych strukturu sloˇzek zachovat, staˇc´ı tedy z CD zkop´ırovat adresáˇr Workspace. Ten obsahuje port pro pouˇzit´ y kit, port je sloˇzen z pár ukázkov´ ych aplikac´ı z [PJer]. Po spuˇstˇen´ı HEW se nás aplikace zeptá, zda chceme zaˇc´ıt nov´ y projekt, nebo otevˇr´ıt ve vybraném um´ıstˇen´ı, viz. obr.A.1. Zvol´ıme moˇznost vybrat a v následuj´ıc´ım oknˇe Obr.A.2 vybereme soubor dp.hew. Pravdˇepodobnˇe se nás jeˇstˇe v závislosti na verzi HEW zeptá, zda chceme projekt transformovat do nové podoby. Pokud se to stane zvol´ıme yes. Po naˇcten´ı projektu bude v´ yvojové prostˇred´ı odpov´ıdat zhruba obr.A.3. V levé ˇcásti je pˇrehled soubor˚ u projektu a závislost´ı soubor˚ u mezi sebou.

55

Vývojová prostˇred´ı a nastaven´ı µC/OS-II

Vývojové prostˇred´ı

Obrázek A.1: Prvn´ı spuˇstˇen´ı HEW

Obrázek A.2: Otevˇren´ı projektu V´ ychoz´ı instalace a nastaven´ı pˇrekladaˇce jsou funkce schopné. Jediné co zb´ yvá nastavit pro simulátor kitu je adresn´ı prostor simulátoru. Simulátor procesoru H8S/2600 má nastaven rozsah adres simulované pamˇeti tak, aby vyhovoval obvykl´ ym u ´lohám. Pokud je to nutné (simulátor hlás´ı chybu Memory Access Error(Address:H’xxxxxxxx) ), lze rozsah pamˇeti upravit v oknˇe, které se otevˇre pˇr´ıkazem Setup - Simulator - Memory Resource. Záznamy 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ásleduj´ıc´ı obrázek A.4. Krom nastaven´ı pamˇeti, je dobré ovˇeˇrit, odkud se nahrává pˇreloˇzená aplikace a o jak´ y typ simulátoru se jedná. Toto nastaveni najdeme v menu DebugSetings, na záloˇzce target vybereme H8S/2600A Simulátor. Doln´ı ˇcásti okna je v´ ypis nahrávan´ ych soubor˚ u, pokud zde ˇzádn´ y nen´ı, pˇridáme jej tlaˇc´ıtkem Add. Pokud se zde nacház´ı, zkontrolujeme, ˇze se jedná a správné um´ıstˇen´ı. Správné je ve v´ ychoz´ım nastaven´ı, kdyˇz je zde nastaven pˇreloˇzen´ y soubor ze sloˇzky otevˇreného projektu.

56

Vývojová prostˇred´ı a nastaven´ı µC/OS-II

Vývojové prostˇred´ı

Obrázek A.3: V´ yvojové prostˇred´ı HEW

Obrázek A.4: Adresn´ı prostor simulátoru 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é kódy. Postup je to jednoduch´ y, pro verzi systému 2.86 bude platit následuj´ıc´ı postup. Upozornil bych, ˇze v budouc´ıch verz´ıch se budou liˇsit zejména uvedené ˇrádky, kde se zmˇeny provád´ı. Systém jako takov´ y dodrˇzuje jistou organizaˇcn´ı strukturu, popsanou v [MicroII]. Zde se dozv´ıme, ˇze soubory jádra systému jsou drˇzeny v jedné sloˇzce a ostatn´ı, závislé k portaci jsou ve sloˇzce jiné. Proto do sloˇzky se soubory jádra zkop´ırujeme soubory os sched ext.c a os sched ext.h, ty se nacházej´ı ve sloˇzce \os sched ext\. Dále mus´ıme upravit p˚ uvodn´ı zdrojové kódy. Zaˇcnˇeme od ucosii.c, zde k seznamu vkládan´ ych soubor˚ u pˇridáme #include

Stejnou ˇrádku pˇridáme do souboru includes.h, kter´ y pouˇz´ıváme pro v´ yvoj aplikac´ı a importu dodateˇcn´ ych knihoven. Do souboru ucosii.h je dobré um´ıstit kontrolu pouˇzit´ı rozˇs´ıˇren´ı, tato podm´ınka pˇri pˇrekladu ovˇeˇr´ı, zda je pouˇzito vytváˇren´ı u ´loh s extern´ımi daty. Doporuˇcuji, pokud pˇridáváme podm´ınky pˇrekladu, které nevyb´ıraj´ı pˇr´ımo kousky kódu, 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áme na konec souboru os cfg.h. #define OS SCH TYPE

typ planovani

Typ plánován´ı nahrad´ıme ˇc´ıslem • 0 P˚ uvodn´ı statické plánován´ı 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ánovac´ıch algoritm˚ u nepˇreloˇzila funkce OS SchedNew(). Na ˇrádku pˇred komentáˇr (1630) um´ıst´ıme #i f OS SCH TYPE == 0

a za konec funkce, resp. pˇred komentáˇr (1670) následuj´ıc´ı funkce #endif

Dále 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é provedeme ve funkci OS Shed() na ˇrádku (1620) a také ve funkci OSStart()(790). Po tˇechto u ´pravách je systém pouˇziteln´ y pro dalˇs´ı v´ yvoj portace a funkˇcn´ı aplikace. Pokud se vám shoduj´ı verze µC/OS-II a nedˇelali jste ˇza´dné 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é ´ stanovuje p˚ uvodn´ı implementace. Uloha je napsána jako nekoneˇcná smyˇcka, která neobsahuje volán´ı return. Aby docházelo k pˇrep´ınán´ı u ´loh systémem, mus´ı b´ yt uvnitˇr smyˇcky volána jedna z následuj´ıc´ıch funkc´ı • OSMboxPend() • OSFlagPend() • OSMutexPend() • OSQPend() 59

Sestaven´ı konfigurace • OSSemPend() • OSTimeDly() • OSTimyDlyHMSM() • OSTaskSuspend() • OSTaskDel() Priority, které uˇzivatel zadá nebudou respektovány s v´ yhradami. T´ım je myˇsleno, ˇze uˇzivatelem zadané priority mus´ı b´ yt unikátn´ı a nesm´ı b´ yt z rezervovan´ ych priorit. Jen pro u ´plnost jsou rezervovány 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ánován´ı 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á plánovaˇc jak odmˇeˇrovat u ´daje. Dále mus´ıme vytvoˇrit strukturu OS SCHED EXT. A vyplnit následuj´ıc´ı parametry vztaˇzené k modelu u ´lohy viz obr.5.1 • OSTCBStartTask - odpov´ıdá parametru r • OSTCBMaxTime - odpov´ıdá parametru C • OSTCBDeadline - odpov´ıdá parametru D • OSTCBPeriod - odpov´ıdá parametru T Pokud potˇrebuje uˇzivatel pˇredávat data, k ˇcemuˇz p˚ uvodnˇe pext slouˇzil, mus´ıme upravit jej´ı zpracován´ı a posunout se o jeden pointer dál na OS SCHED EXT->pext. Takto pˇripravená data pˇredáme funkci OSTaskCreateExt(). Jeˇstˇe pˇred spuˇstˇen´ım multitaskingu, je nutné inicializovat extern´ı scheduler a to volán´ım funkce OSSchedExtInit().Toto zd˚ urazˇ nujeme, kv˚ uli neinicializované pamˇeti plánovaˇce, kde pak docház´ı k poruˇsen´ı pravidel adresace pamˇeti. Pokud jsme provedli vˇsechny kroky z pˇredchoz´ı kapitoly, máme upraven´ y systém pˇripraven k pouˇzit´ı. Ke snadnˇejˇs´ımu zadáván´ı parametr˚ uu ´loh lze vyuˇz´ıt vytvoˇrenou funkci, které se pˇredá 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ávn´ y bˇeh. Spolu s touto funkc´ı byl vytvoˇren model u ´lohy, na kter´ y je moˇzné r˚ uznˇe upravit a pouˇz´ıt. Samozˇrejmost´ı je moˇznost pouˇzit´ı standardn´ıho plánován´ı rozˇs´ıˇreného o sbˇer informac´ı task˚ u. Tento model naleznete v adresáˇri \function workspace\WorkSpace\IntrApp.

61

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Implementace vybraných

Recommend Documents