Implementace Rtos Do Mikrokontrolérů Stm32 S Jádrem Arm Cortex-M4f

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV AUTOMATIZACE A MĚŘICÍ TECHNIKY

FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF CONTROL AND INSTRUMENTATION

IMPLEMENTACE RTOS DO MIKROKONTROLÉRŮ STM32 S JÁDREM ARM CORTEX-M4F

IMPLEMENTATION OF RTOS INTO STM32 MICROCONTROLLERS WITH ARM CORTEX-M4F CORE

DIPLOMOVÁ PRÁCE MASTER'S THESIS

AUTOR PRÁCE Bc. ADOLF GOTHARD AUTHOR

VEDOUCÍ PRÁCE Ing. TOMÁŠ MACHO, Ph.D. SUPERVISOR

BRNO 2014 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

Fakulta elektrotechniky a komunikačních technologií

Ústav automatizace a měřicí techniky

Diplomová práce magisterský navazující studijní obor Kybernetika, automatizace a měření

Student: Bc. Adolf Gothard ID: 125432 Ročník: 2 Akademický rok: 2013/2014

NÁZEV TÉMATU: Implementace RTOS do mikrokontrolérů STM32 s jádrem ARM Cortex-M4F

POKYNY PRO VYPRACOVÁNÍ: 1. Seznamte se s mikrokontroléry STM32F407VGT6 s jádrem ARM Cortex-M4F a vývojovou deskou STM32F4DISCOVERY. 2. Vyhledejte operační systémy (OS) reálného času, které lze provozovat na mikrokontrolérech s jádrem ARM Cortex-M4F. Popište základní vlastnosti a prostředky těchto OS. 3. Rozeberte možnosti implementace PSD regulátorů do mikrokontroléru STM32F407VGT6 s využitím OS reálného času. 4. Implementujte dva vybrané volně šiřitelné OS reálného času do mikrokontroléru STM32F407VGT6. 5. Realizujte softwarovou implementaci PSD regulátoru při použití vybraných OS reálného času. Řešte i řízení A/D a D/A převodníků. 6. Vyhodnoťte vhodnost vybraných OS reálného času pro realizaci embedded systémů zahrnujících regulační algoritmy.

DOPORUČENÁ LITERATURA: Mikroprocesory s architekturou ARM On line. Dostupné z http://www.root.cz/clanky/mikroprocesory-s-architekturou-arm/.

Termín zadání: 10.2.2014 Termín odevzdání: 19.5.2014

Vedoucí práce: Ing. Tomáš Macho, Ph.D. Konzultanti diplomové práce:

doc. Ing. Václav Jirsík, CSc. UPOZORNĚNÍ: Předseda oborové rady Autor diplomové práce nesmí při vytváření diplomové práce porušit autorská práva třetích osob, zejména nesmí zasahovat nedovoleným způsobem do cizích autorských práv osobnostních a musí si být plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení části druhé, hlavy VI. díl 4 Trestního zákoníku č.40/2009 Sb. Abstrakt

Tato diplomová práce se zabývá výb ěrem a implementací dvou voln ě ši řitelných opera čních systém ů reálného času do výkonného 32-bitového mikrokontroléru s jádrem ARM Cortex-M4F. Nejprve je v krátkosti obecn ě popsána architektura ARM, její programátorský model, instruk ční soubor a stru čně také jádro Cortex-M4F. Následuje popis architektury použitého mikrokontroléru STM32F407VGT6 od výrobce ST Microelectronics, popis organizace vestav ěných pam ětí a funkcí vestav ěných A/D a D/A p řevodník ů. Další část práce je pak v ěnována vyhledání opera čních systém ů reálného času s podporou jádra ARM Cortex-M4F a výb ěru dvou z těchto systém ů pro implementaci. Vybrané systémy jsou podrobn ěji popsány v následujících dvou kapitolách. Další kapitola se zabývá rozborem možností implementace číslicového PSD regulátoru v četn ě komplexn ějšího systému takových regulátor ů p ři použití opera čního systému reálného času. Následuje popis implementace vybraných opera čních systém ů a navržených regulátor ů. V záv ěru práce je provedeno vyhodnocení vlastností vybraných opera čních systém ů reálného času z hlediska vhodnosti pro realizaci embedded systém ů s důrazem na regula ční systémy.

Klí čová slova

RTOS, implementace, ARM Cortex-M4F, STM32F407VGT6, PSD regulátor, embedded systémy, FreeRTOS, ChibiOS/RT

3 Abstract

This masters's thesis deals with choice and implementation of two free real-time operating systems into powerful 32-bit microcontroller with ARM Cortex-M4F core. First, there is shortly described the ARM architecture in general, its programmer's model, instruction set and Cortex-M4F core in brief. Next is description of the architecture of used microcontroller STM32F407VGT6 from ST Microelectronics, description of its integrated memories and their organization and functions of its integrated A/D and D/A converters. Next part of this thesis deals with searching real-time operating systems with ARM Cortex-M4F core support and then choose two of these systems for the implementation. The chosen operating systems are more closely described in two following chapters. Next chapter analyses possible implementations of the digital PSD controller and more complex system of such controllers using real-time operating system. Following chapter describes implementation of chosen operating systems and designed controllers. Last chapter deals with evaluation of features and qualities of the chosen real-time operating systems for implementation of embedded control system.

Keywords

RTOS, implementation, ARM Cortex-M4F, STM32F407VGT6, PSD controller, embedded systems, FreeRTOS, ChibiOS/RT

Bibliografická citace:

GOTHARD, A. Implementace RTOS do mikrokontrolér ů STM32 s jádrem ARM Cortex- M4F . Brno: Vysoké u čení technické v Brn ě, Fakulta elektrotechniky a komunika čních technologií, 2014. 105 s. Vedoucí diplomové práce Ing. Tomáš Macho, Ph.D..

Prohlášení

Prohlašuji, že svou diplomovou práci na téma Implementace RTOS do mikrokontrolér ů STM32 s jádrem ARM Cortex-M4F jsem vypracoval samostatn ě pod vedením vedoucího diplomové práce a s použitím odborné literatury a dalších informa čních zdroj ů, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené diplomové práce dále prohlašuji, že v souvislosti s vytvo řením této diplomové práce jsem neporušil autorská práva t řetích osob, zejména jsem nezasáhl nedovoleným zp ůsobem do cizích autorských práv osobnostních a jsem si pln ě v ědom následk ů porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetn ě možných trestn ěprávních d ůsledk ů vyplývajících z ustanovení části druhé, hlavy VI. díl 4 Trestního zákoníku č. 40/2009 Sb.

V Brn ě dne: 19. kv ětna 2014 ………………………… podpis autora

Pod ěkování

Děkuji vedoucímu diplomové práce Ing. Tomáši Machovi, Ph.D. za vedení mé práce a dále za odbornou pomoc a rady p ři jejím vypracování.

V Brn ě dne: 19. kv ětna 2014 ………………………… podpis autora

7 Obsah

1 Úvod...... 13 2 Architektura ARM...... 15 2.1 Programátorský model...... 15 2.1.1 Módy procesoru...... 15 2.1.2 Registry ...... 16 2.1.3 Výjimky...... 17 2.2 Instruk ční soubor ...... 18 2.2.1 Instruk ční soubor ARM...... 18 2.2.2 Instruk ční soubor Thumb ...... 18 2.3 Jádro ARM Cortex-M4F...... 19 2.3.1 Standard CMSIS...... 19 3 Mikrokontrolér STM32F407VGT6 ...... 21 3.1 Systémová architektura...... 23 3.1.1 Popis jednotlivých sb ěrnic...... 24 3.2 Organizace pam ěti ...... 25 3.2.1 Vestav ěná pam ěť SRAM...... 25 3.3 Vestav ěné A/D p řevodníky...... 25 3.3.1 Výb ěr kanál ů ...... 26 3.3.2 Módy p řevodu ...... 26 3.3.3 Výsledek p řevodu...... 27 3.3.4 Parametry A/D p řevodu...... 27 3.4 Vestav ěné D/A p řevodníky...... 27 3.4.1 Parametry D/A p řevodník ů ...... 28 3.5 Vývojová deska STM32F4-Discovery ...... 28 4 Výb ěr opera čních systém ů reálného času ...... 30 4.1 Opera ční systémy reálného času...... 30 4.2 Výb ěr RTOS s podporou jádra ARM Cortex-M4F ...... 31 4.3 Popis n ěkterých nalezených opera čních systém ů ...... 32 4.3.1 NuttX...... 32 4.3.2 µC/OS-II...... 34 4.3.3 eCos...... 34

8 5 Opera ční systém FreeRTOS...... 37 5.1 Podporované architektury a nástroje...... 37 5.2 Struktura zdrojových soubor ů...... 38 5.3 Správa úloh...... 40 5.4 Plánování a priority...... 42 5.5 Synchronizace a komunikace ...... 44 5.5.1 Fronty ...... 44 5.5.2 Binární semafory...... 45 5.5.3 Čítací semafory ...... 46 5.5.4 Mutexy ...... 46 5.5.5 Příznaky událostí...... 47 5.6 Časování ...... 47 5.7 Správa pam ěti ...... 48 5.7.1 Podpora MPU...... 50 5.8 Koprogramy...... 50 6 Opera ční systém ChibiOS/RT...... 51 6.1 Podporované architektury a nástroje...... 52 6.2 Architektura systému...... 53 6.3 Struktura zdrojových soubor ů...... 55 6.4 Správa úloh...... 56 6.5 Plánování a priority...... 59 6.6 Synchronizace a komunikace ...... 60 6.6.1 Čítací semafory ...... 61 6.6.2 Binární semafory...... 61 6.6.3 Mutexy ...... 62 6.6.4 Podmín ěné prom ěnné...... 63 6.6.5 Příznaky událostí...... 64 6.6.6 Zprávy ...... 64 6.6.7 Fronty ...... 65 6.7 Správa pam ěti ...... 65 7 Možnosti implementace PSD regulátor ů s využitím OS reálného času ..... 67 7.1 PSD regulátor ...... 67 7.1.1 Vstupy a výstupy...... 68 7.1.2 Výpo čet ...... 69 7.1.3 Další praktické požadavky ...... 70

9 7.2 Komplexní regula ční systémy ...... 71 7.2.1 Systémy s jedinou vzorkovací periodou...... 71 7.2.2 Systémy s více vzorkovacími periodami...... 72 7.3 Návrh PSD regulátoru jako úlohy opera čního systému...... 75 8 Implementace...... 77 8.1 Vytvo ření projektu pro systém FreeRTOS...... 78 8.2 Vytvo ření projektu pro systém ChibiOS/RT ...... 79 8.3 Implementace PSD regulátoru v systému FreeRTOS...... 81 8.4 Implementace PSD regulátoru v systému ChibiOS/RT...... 84 9 Vyhodnocení vlastností vybraných OS reálného času ...... 87 9.1 Vyhodnocení vlastností systému FreeRTOS ...... 88 9.2 Vyhodnocení vlastností systému ChibiOS/RT ...... 89 10 Záv ěr...... 92

10 Seznam obrázk ů

Obr. 2-1: Organizace registr ů procesoru ARM [1] ...... 17 Obr. 2-2: Blokové schéma procesoru s jádrem ARM Cortex-M4(F) [9]...... 20 Obr. 3-1: Blokové schéma mikrokontroléru rodiny STM32F40x [12]...... 22 Obr. 3-2: Architektura sb ěrnic mikrokontrolér ů rodiny STM32F40x [13]...... 23 Obr. 3-3: Blokové schéma zapojení vývojové desky STM32F4-Discovery [14] ...... 29 Obr. 5-1: Struktura distribuce opera čního systému FreeRTOS [55]...... 39 Obr. 5-2: P řechodový diagram stav ů úloh v systému FreeRTOS [60] ...... 42 Obr. 5-3: Znázorn ění spoušt ění úloh pomocí algoritmu Round-Robin [60]...... 43 Obr. 5-4: Vzájemný vztah mezi aplikací a obsluhou softwarového časova če [74]...... 47 Obr. 6-1: Vztahy jednotlivých sou částí opera čního systému ChibiOS/RT [89] ...... 53 Obr. 6-2: Vztahy mezi subsystémy jádra systému ChibiOS/RT [89] ...... 54 Obr. 6-3: Struktura b ěžného ovlada če za řízení [89] ...... 55 Obr. 6-4: Pracovní oblast úlohy [101]...... 58 Obr. 6-5: P řechodový diagram stav ů úloh v systému ChibiOS/RT [101]...... 58 Obr. 6-6: Seznam p řipravených úloh [101]...... 59 Obr. 6-7: Vztahy mezi synchroniza čními prost ředky [89]...... 60 Obr. 6-8: P řechodový diagram stav ů čítacího semaforu [104] ...... 61 Obr. 6-9: P řechodový diagram stav ů binárního semaforu [104]...... 62 Obr. 6-10: P řechodový diagram stav ů mutexu [104]...... 63 Obr. 6-11: Správa pam ěti v systému ChibiOS/RT [89] ...... 66 Obr. 7-1: Cyklické provád ění řídicího programu s periodou T [121]...... 70

Obr. 7-2: Srovnání statického d ělení kódu, EDF a RM pro systém S 123 [121] ...... 75 Obr. 7-3: Principiální znázorn ění činnosti úlohy opera čního systému ...... 76 Obr. 8-1: Zjednodušené znázorn ění struktury projektu pro systém FreeRTOS...... 79 Obr. 8-2: Zjednodušené znázorn ění struktury projektu pro systém ChibiOS/RT...... 81 Obr. 8-3: Vývojový diagram úlohy pro PSD regulátor...... 86

11 Seznam tabulek

Tab. 2-1: Módy procesoru s architekturou ARM [1] ...... 15 Tab. 2-2: Výjimky a módy pro jejich obsluhu [1]...... 18 Tab. 5-1: Struktura TCB v systému FreeRTOS...... 41 Tab. 6-1: Architektury podporované opera čním systémem ChibiOS/RT [83] ...... 52 Tab. 6-2: Struktura reprezentující úlohu v systému ChibiOS/RT...... 57

12 1 ÚVOD

V sou časné dob ě jsou číslicové řídicí systémy všeobecn ě rozší řené pravd ěpodobn ě ve všech odv ětvích řídicích úloh. Jedním z hlavních d ůvod ů je skute čnost, že veškeré výpo čty realizované softwarov ě lze snadno a rychle modifikovat podle aktuálních pot řeb pouze zm ěnou programu řídicího po číta če. To dává k dispozici velmi univerzální nástroj, jehož použitelnost pro danou řídicí úlohu je omezena v podstat ě jen výkonem samotného po číta če nebo mikrokontroléru. Moderní procesory pak disponují výkonem, který je pro v ětšinu řídicích úloh dostate čný. Dalšími výhodami jsou prakticky absolutní stabilita nastavených parametr ů, možnost jejich snadn ější adaptivní modifikace za b ěhu a dále nap ř. možnost komunikace a synchronizace s dalšími systémy. Základní spole čnou vlastností číslicových řídicích systém ů je samotný charakter jejich činnosti, který je diskrétní a sekven ční (nejsou zde uvažovány vícejádrové ani víceprocesorové systémy, pop ř. systémy s obvody FPGA). P ři řízení jednodušších systém ů bez zvláštních časových požadavk ů tato vlastnost nep ředstavuje problém. Čím je však řídicí systém komplexn ější, tím obtížn ější je zaru čit požadované časové chování. U časov ě kritických systém ů (tzv. real-time systémy) obvykle nespln ění daných časových požadavk ů zp ůsobí výrazné snížení výkonu nebo i selhání celého systému, což m ůže mít velmi vážné d ůsledky. Pro real-time systémy již tedy m ůže sekven ční zpracování algoritmu p ředstavovat problém. Tento problém je obvykle řešen použitím metod, které zpracovávají provád ění řídicího algoritmu tak, aby byla v daný okamžik vždy provedena správná operace. Jednou z těchto metod je použití opera čního systému reálného času ( real-time operating system , RTOS). Tato diplomová práce se zabývá implementací opera čních systém ů reálného času do moderního výkonného 32-bitového mikrokontroléru s jádrem ARM Cortex-M4F z rodiny STM32 firmy ST Microelectronics a následnou realizací číslicového regulátoru s využitím t ěchto systém ů. Cílem práce je tedy výb ěr, popis a implementace dvou voln ě ši řitelných opera čních systém ů reálného času do daného mikrokontroléru a dále vyhodnocení jejich použitelnosti pro realizaci regula čních systém ů. Na za čátku práce je proveden stru čný obecný popis procesorové architektury ARM a velmi krátce je popsáno také jádro Cortex-M4F, na kterém je založen použitý mikrokontrolér STM32F407VGT6, jehož popisu se v ěnuje t řetí kapitola. Je zde popsána architektura mikrokontroléru, organizace pam ěti a podrobn ěji také vestav ěné A/D a D/A převodníky, které jsou velmi d ůležitou sou částí řídicích systém ů. Dále je uveden krátký popis použité vývojové desky STM32F4-Discovery. Čtvrtá kapitola je v ěnována jednak stru čnému obecnému popisu opera čních systém ů reálného času, jednak vyhledání a popisu OS reálného času s podporou jádra ARM Cortex-M4F a výb ěru systém ů pro implementaci do použitého mikrokontroléru. Následující dv ě kapitoly se pak zabývají podrobn ějším popisem vybraných OS reálného času. U t ěchto kapitol byla pokud možno dodržována stejná struktura.

13 Sedmá kapitola je v ěnována rozboru možností implementace číslicového PSD regulátoru. Za číná stru čným obecným popisem PSD regulátoru jako číslicové náhrady PID regulátoru, následn ě jsou probrány nejd ůležit ější části jeho implementace a také některé další praktické požadavky. Ve druhé části kapitoly jsou probrány možnosti implementace komplexn ějších regula čních systém ů, které využívají více regulátor ů. Poslední část kapitoly je v ěnována možnostem návrhu regulátoru jako úlohy pro použití v OS reálného času. V další kapitole je pak popsána již praktická implementace jednak samotných vybraných opera čních systém ů, jednak navržených úloh pro PSD regulátory s použitím těchto systém ů. Devátá kapitola je v ěnována poslednímu bodu zadání a je zde provedeno vyhodnocení vlastností vybraných OS reálného času pro realizaci embedded systém ů, které zahrnují regula ční algoritmy.

14 2 ARCHITEKTURA ARM

Mikroprocesory s architekturou ARM jsou v sou časné dob ě velmi rozší řené p ředevším v mobilních za řízeních. V oblasti mobilních telefon ů se podíl ARM procesor ů blíží sto procent ům. Dále jsou rozší řené v sí ťových, spot řebních a vestav ěných (embedded) za řízeních, kde mají dlouhodob ě vysoký podíl zejména díky nízké spot řeb ě. Také politika firmy ARM Holdings, kdy je jednotlivým výrobc ům licencována architektura jako duševní vlastnictví, s tím, že výrobce m ůže na čip p řidat další za řízení (pam ěti, periferie atd.), p řisp ěla k rozší ření procesor ů s touto architekturou.

2.1 Programátorský model

Jak bylo uvedeno, ARM je architektura typu RISC (Reduced Instruction Set Computer). Typickou vlastností RISC architektur je malý soubor instrukcí stejné délky, v ětší množství registr ů, jednoduché adresování, z řet ězení instrukcí (pipelining). Operace s daty jsou provád ěny pouze v registrech (load/store architektura). Architektura ARM navíc nabízí v ětší kontrolu nad aritmeticko-logickou jednotkou (ALU), adresní módy s automatickou inkrementací nebo dekrementací, instrukce typu Load and Store Multiple pro na čítání/ukládání více dat sou časn ě a podmín ěné provád ění instrukcí pro optimalizaci po čtu skok ů v programu [1]. Procesory ARM pracují s t ěmito datovými typy: Byte (8 bit ů) Halfword (16 bit ů) Word (32 bit ů).

2.1.1 Módy procesoru

Architektura ARM podporuje sedm procesorových módu. Mezi jednotlivými módy lze přepínat softwarov ě nebo p ři p říchodu p řerušení/ošet ření výjimek. Tyto módy jsou uvedeny v Tab. 2-1.

Tab. 2-1: Módy procesoru s architekturou ARM [1] mód procesoru zkratka módu popis User usr Mód pro provád ění b ěžných program ů FIQ fiq Obsluha rychlých p řerušení IRQ irq Obecná obsluha p řerušení Supervisor svc Chrán ěný mód pro opera ční systém Abort abt Ochrana pam ěti/virtuální pam ěti Undefined und Softwarová emulace hardwarových koprocesor ů System sys Pro vykonávání d ůležitých úloh opera čního systému

15 Většina uživatelských program ů b ěží v módu User. Pokud je procesor v tomto módu, nemá b ěžící program p řístup k některým částem systému a není možná programová zm ěna módu. Ostatní módy jsou privilegované ( privileged ) a mají úplný přístup ke všem sou částem systému. V privilegovaných módech lze také libovoln ě měnit módy procesoru. Z těchto šesti privilegovaných mód ů je p ět mód ů výjimkových (exception ). Jsou to:

FIQ IRQ Supervisor Abort Undefined

Do výjimkových mód ů se procesor dostává p říchodem ur čité výjimky (nap ř. přerušení). Každý výjimkový mód má p řiřazeny n ěkteré speciální registry, aby nebyla ovliv ňována činnost programu v uživatelském (User) módu (viz část 2.1.2). Posledním módem je systémový (System) mód. Tento mód má k dispozici stejné registry jako uživatelský (User) mód. Stále se však jedná o privilegovaný mód. Je ur čen pro n ěkteré d ůležité úlohy opera čního systému, které vyžadují plný p řístup k systémovým zdroj ům a sou časn ě není vhodné, aby používaly stejné speciální registry jako výjimkové módy. Stav úlohy, b ěžící v módu System, není tedy narušen p říchodem nějaké výjimky.

2.1.2 Registry

Procesory ARM mají celkem 37 registr ů o délce 32 bit ů. Z toho 31 registr ů pro obecné použití v četn ě programového číta če ( program counter ) a šest stavových ( status ) registr ů. Registry jsou organizovány ve skupinách a jejich viditelnost závisí na aktuálním módu procesoru. V každém módu je viditelných 15 registr ů pro všeobecné použití (R0 až R14), programový číta č (R15) a jeden nebo dva stavové registry. Ve výjimkových módech jsou vždy n ěkteré registry nahrazeny speciálními registry, ur čenými pouze pro daný mód. Registry R0 až R7 jsou stejné ve všech módech a nemají žádné systémové využití. Mohou být použity k jakémukoliv ú čelu. Registr R13 je normáln ě používán jako ukazatel zásobníku (SP – stack pointer ), registr R14 (LR – link register ) slouží k uchování návratových adres z podprogram ů a p řerušení. Registr R15 slouží jako programový číta č (PC – program counter ). Pro podrobný popis organizace registr ů a jejich funkce viz [1], [2]. Organizace registr ů je znázorn ěna na Obr. 2-1

16 Obr. 2-1: Organizace registr ů procesoru ARM [1]

2.1.3 Výjimky

Architektura ARM podporuje sedm typ ů výjimek, které mohou být generovány vnit řními nebo vn ějšími zdroji. P řed obsluhou výjimky je aktuální stav uložen, aby bylo možné po ukon čení obsluhy pokra čovat ve vykonávání p ůvodního programu. M ůže nastat více výjimek sou časn ě. V Tab. 2-2 jsou typy výjimek a módy, ve kterých probíhá obsluha dané výjimky. Při p říchodu výjimky je nejprve uložena návratová adresa do p říslušného registru R14 (každý mód má k dispozici vlastní registr R14) a aktuální stav (registr CPSR) je uložen do p říslušného registru SPSR. Následn ě jsou provedena další nastavení v závislosti na daném módu a do programového číta če je uložena adresa vektoru příslušné výjimky. Po vykonání obsluhy p řerušení je obnoven registr CPSR a obsah p říslušného registru R14 je p řesunut do programového číta če. Pro podrobný popis činnosti a nastavení p ři obsluze jednotlivých typ ů výjimek viz [1].

17 Tab. 2-2: Výjimky a módy pro jejich obsluhu [1] typ výjimky mód Reset Supervisor Nedefinované instrukce Undefined Softwarové p řerušení Supervisor Selhání na čtení instrukce Abort Selhání p řístupu do datové pam ěti Abort Přerušení IRQ Rychlé p řerušení FIQ

2.2 Instruk ční soubor

2.2.1 Instruk ční soubor ARM

Původní instruk ční soubor procesor ů ARM obsahuje instrukce délky 32 bit ů, zarovnané v pam ěti na celá slova, tj. instrukce jsou uloženy na adresách d ělitelných 4 (slovo ARM procesor ů p ředstavují 4 byty). Tém ěř každá instrukce obsahuje podmínkové pole, které je umíst ěno v nejvyšších čty ř bitech. Na obsahu podmínkového pole pak závisí, zda bude instrukce provedena. Tato speciální vlastnost ARM instrukcí umož ňuje minimalizovat po čet skok ů v programu a tím zvýšit výkon. Další vlastností je z řet ězené zpracování instrukcí ( pipeline ). Zpracování instrukce je rozd ěleno na n ěkolik částí a tyto části jsou provád ěny jednotliv ě. Díky tomu je možné zpracovávat více instrukcí sou časn ě v různém stavu rozpracování. V případ ě architektury ARMv7 a starší jsou instrukce rozd ěleny na t ři fáze a je tedy možné zpracovávat t ři instrukce sou časn ě. První fází je na čtení instrukce ( fetch ), dále dekódování ( decode ) a provedení instrukce ( execute ).

2.2.2 Instruk ční soubor Thumb

Nov ější rodiny procesor ů ARM jsou vybaveny instruk ční sadou Thumb. Tato instruk ční sada vznikla pro použití ve vestav ěných ( embedded ) systémech, kde je krom ě nízké spot řeby zapot řebí také úspora pam ěti. Instrukce Thumb jsou podmnožinou p ůvodních instrukcí ARM a mají délku pouze 16 bit ů. To umož ňuje dosáhnout v ětší hustoty kódu a v ětšího výkonu u implementací, používajících datové sb ěrnice o ší řce 16 bit ů a užší. V [3] je uvedeno, že program, využívající instrukce Thumb, p řeložený z kódu napsaného v jazyku C, dosahuje 65 % velikosti programu, který využívá instrukce ARM. Zkrácením instrukcí však došlo k odstran ění podmínkového pole a je tedy nutné využívat standardních skoků.

18 Thumb instrukce využívají standardní registry a pracují s 32-bitovými daty tak jako instrukce ARM. To umož ňuje p řepínání mezi instruk čními soubory i v rámci jednotlivých funkcí [4]. P řed vykonáním Thumb instrukce je tato p řevedena dekodérem na délku 32 bit ů.

Instruk ční sada Thumb-2 vznikla rozší řením p ůvodní sady Thumb o n ěkteré 32-bitové instrukce. Cílem je slou čit výhody instruk čních sad ARM a Thumb, tedy vysoký výkon a vysokou hustotu kódu, tak, aby nebylo nutné p řepínat mezi jednotlivými sadami. Podle [5] je úspora velikosti kódu Thumb-2 oproti ARM 26 % a pokles relativního výpo četního výkonu pouze o 2 %.

2.3 Jádro ARM Cortex-M4F

Jádro Cortex-M4 pat ří do rodiny procesor ů Cortex-M. Tato rodina je ur čena pro použití ve vestav ěných ( embedded ) systémech, kde je zapot řebí nízká spot řeba a malé rozm ěry. Tyto mikrokontroléry mohou mít velmi široké využití (nap ř. automobilová technika, řízení motor ů, pr ůmyslová automatizace). Procesor ARM Cortex-M4 je postaven na architektu ře ARMv7-M [6], [7] a má implementovánu instruk ční sadu Thumb-2. Instrukce jsou rozd ěleny na t ři fáze a jejich zpracovávání je z řet ězeno. Procesor je navržen zejména pro číslicové zpracování signál ů. Pro tyto ú čely má implementovány n ěkteré vlastnosti DSP (instrukce MAC, SIMD). Nabízí také jednotku pro zpracování čísel s pohyblivou řádovou čárkou (FPU – floating point unit ) s přesností single precision vyhovující standardu IEEE 754 [8]. Procesor s jednotkou FPU je ozna čován jako Cortex-M4F. Dále je vestav ěna jednotka pro ochranu a správu pam ěti (MPU – memory protection unit ). Lze ji použít k ochran ě p řístupu do pam ěti v případ ě provád ění kritického kódu, může být ovládána opera čním systémem reálného času. Podrobné informace o vlastnostech a použití procesoru Cortex-M4F lze nalézt v [9]. Na je blokové schéma procesoru s jádrem ARM Cortex-M4(F).

2.3.1 Standard CMSIS

Ve vestav ěných systémech je vývoj software jedním z hlavních faktor ů, ovliv ňujících cenu za řízení. Komplexnost software se zvyšuje a tím dochází i ke zvyšování ceny za jeho vývoj [10]. Proto je snaha o standardizaci a opakované využití softwarových komponent. Standard CMSIS ( Cortex Microcontroller Software Interface Standard ) je, jak z názvu vyplývá, ur čen pro mikrokontroléry rodiny Cortex-M. Jedná se o abstraktní rozhraní (HAL – hardware abstraction layer ) nezávislé na výrobci, pop ř. rozši řitelné výrobcem, které zprost ředkovává p řístup k sou částem jádra mikrokontroléru a také

19 k periferiím. CMSIS definuje aplika ční rozhraní (API – application programming interface ) pro všechny mikrokontroléry Cortex-M. Podrobn ější popis standardu CMSIS lze nalézt nap ř. v [10] a [11].

Obr. 2-2: Blokové schéma procesoru s jádrem ARM Cortex-M4(F) [9]

20 3 MIKROKONTROLÉR STM32F407VGT6

STM32F407VGT6 je výkonný 32-bitový mikrokontrolér firmy ST Microelectronics, který pat ří do rodiny mikrokontrolér ů STM32F40x. Tato rodina je založena na RISC jád ře ARM Cortex-M4F, které lze taktovat až na 168 MHz. Jádro mikrokontroléru obsahuje jednotku pro výpo čty s čísly s pohyblivou řádovou čárkou (FPU) s přesností single precision (viz část 2.3). Je implementována také sada DSP instrukcí. Díky tomu lze tyto mikrokontroléry použít i pro náro čnější zpracování signálu. Mikrokontrolér STM32F407VGT6 obsahuje rychlé vestavěné pam ěti. Programová pam ěť FLASH má velikost 1MB. Pro verifikaci obsahu pam ěti m ůže být také použita jednotka CRC ( cyclic redundancy check ). Vestav ěná systémová pam ěť SRAM má velikost 192 kB a mikrokontrolér dále obsahuje 4kB záložní SRAM. K této záložní pam ěti m ůže p řistupovat pouze CPU a je chrán ěna proti nežádoucímu p řepisu. Sou částí mikrokontroléru je řada vstupn ě/výstupních port ů a periferií. T ěmito periferiemi jsou t ři 12-bitové A/D p řevodníky, dva 12-bitové D/A p řevodníky, nízkop říkonový obvod reálného času (RTC), dvanáct 16-bitových časova čů v četn ě dvou PWM časova čů pro řízení motor ů, dva 32-bitové časova če, generátor náhodných čísel. Mezi komunika ční rozhraní pat ří:

3x I 2C 3x SPI 2x I 2S 4x USART 2x UART USB OTG 2x CAN SDIO/MMC Ethernet Rozhraní pro kameru

Napájecí nap ětí mikrokontroléru m ůže být 1,8 až 3,6 V. Dodáván je v pouzd ře LQFP100 a nabízí 82 vstupn ě/výstupních vývod ů pro obecné použití (GPIO). Na je blokové schéma mikrokontrolér ů rodiny STM32F40x. Podrobn ější popis mikrokontroléru lze nalézt v [12], [13].

21 Obr. 3-1: Blokové schéma mikrokontroléru rodiny STM32F40x [12]

22 3.1 Systémová architektura

Ke vzájemné komunikaci jednotlivých částí slouží vícevrstvý systém propojení n ěkolika 32-bitových sb ěrnic (AHB bus matrix ). Pomocí tohoto systému je propojeno osm sb ěrnic typu master a sedm typu slave . Systém umož ňuje sou časné propojení r ůzných za řízení a tím zrychlení činnosti mikrokontroléru. Také zajiš ťuje arbitraci p ři sou časné komunikaci více za řízení typu master. K arbitraci je použit algoritmus Round-Robin [13]. Sb ěrnice typu master jsou: 1) sb ěrnice I-bus, D-bus a S-bus jádra Cortex-M4F 2) DMA1 pam ěť ová sb ěnice 3) DMA2 pam ěť ová sb ěrnice 4) DMA2 sb ěrnice pro periferie 5) Ethernetová DMA sb ěrnice 6) USB DMA sb ěrnice

Sb ěrnice typu slave jsou: 1) ICode sb ěrnice FLASH pam ěti 2) DCode sb ěrnice FLASH pam ěti 3) SRAM1 (112 kB) 4) SRAM2 (16 kB) 5) Sb ěrnice periferií AHB1 6) Sb ěrnice periferií AHB2 7) Pam ěť ové rozhraní FSMC

Obr. 3-2: Architektura sb ěrnic mikrokontrolér ů rodiny STM32F40x [13]

23 3.1.1 Popis jednotlivých sb ěrnic

Sb ěrnice I-Bus Tato sb ěrnice slouží k na čítání instrukcí z pam ěti obsahující kód (vestav ěné FLASH/SRAM pam ěti nebo externí pam ěť p řes rozhraní FSMC).

Sb ěrnice D-bus Používá se k na čítání literál ů a pro p řístup ladicích prost ředk ů. Dále je použita ke komunikaci jádra s CCM ( core coupled memory ) datovou RAM 64kB, která je přístupná pouze z jádra mikrokontroléru.

Sb ěrnice S-bus Systémová sb ěrnice ur čená pro p řístup jádra mikrokontroléru k pam ěti SRAM a k periferiím.

Pam ěť ová sb ěrnice DMA Tato sb ěrnice je používána k přímému p řístupu do pam ětí (mechanismus DMA – direct memory access ).

Periferní sb ěrnice DMA Používána mechanismem DMA pro p římý p řístup k periferiím mikrokontroléru nebo k přenos ům mezi pam ětmi.

Ethernet a USB DMA sb ěrnice Sb ěrnice použité ke p římému p řístupu ethernetového a USB OTG za řízení k pam ěti.

AHP/APB m ůstky Sou částí systému jsou dva AHB/APB m ůstky, ozna čené APB1 a APB2, které zajiš ťují pln ě synchronní propojení mezi systémovou sb ěrnicí AHB ( advanced high- performance bus ) a dv ěma periferními APB sb ěrnicemi. K těmto periferním sb ěrnicím jsou p řipojeny číta če/ časova če, A/D a D/A p řevodníky a v ětšina komunika čních rozhraní mikrokontroléru. Můstky umož ňují správu periferních hodinových signál ů, vhodnou volbu jejich frekvence a p řípadné odpojení hodin pro úsporu energie. Po resetu mikrokontroléru jsou všechny hodinové signály zakázány krom ě komunika čních rozhraní pro FLASH a SRAM pam ěti.

24 3.2 Organizace pam ěti

Mikrokontrolér STM32F407VGT6 disponuje lineárním adresovým prostorem o velikosti 4 GB, který je spole čný pro programovou pam ěť , datovou pam ěť , registry a vstupn ě/výstupní porty. Data jsou kódována ve formátu little-endian , tj. nejmén ě významný byte (LSB) dat je uložen na pam ěť ové místo s nejnižší adresou. Adresový prostor je rozd ělen do osmi blok ů po 512 MB. Organizace pam ěti je podrobn ě popsána v [13].

3.2.1 Vestav ěná pam ěť SRAM

Mikrokontrolér STM32F407VGT6 obsahuje celkem 192 kB vestav ěné systémové pam ěti SRAM a 4 kB záložní pam ěti SRAM. K pam ěti SRAM lze p řistupovat po bytech, p ůl-slovech (16 bit ů) nebo celých slovech (32 bit ů). Systémová pam ěť SRAM je rozd ělena na následující části.

SRAM 1 a SRAM 2 Pam ěti o velikosti 112 kB a 16 kB p řístupné pro všechna za řízení typu master. Díky tomuto rozd ělení pam ěti je možné používat jednotlivé části sou časn ě.

CCM – core coupled memory Pam ěť o velikosti 64 kB. Tato pam ěť je p řístupná pouze z CPU pomocí D-bus sb ěrnice.

3.3 Vestav ěné A/D p řevodníky

Převod analogové hodnoty na číslo pro zpracování v po číta či nebo mikrokontroléru a následný p řevod čísla zp ět na analogovou hodnotu je v číslicové regula ční technice jedním z hlavních problém ů. Vlastnosti a parametry t ěchto p řevod ů mají velký vliv na celý regula ční obvod. Proto budou v této a v následující podkapitole podrobn ěji popsány A/D a D/A p řevodníky vestav ěné v mikrokontroléru STM32F407VGT6. Mikrokontrolér STM32F407VGT6 disponuje t řemi vestav ěnými A/D p řevodníky. Tyto p řevodníky jsou založeny na principu postupné aproximace a mají nastavitelné rozlišení (až 12 bit ů). P řevodníky mohou využívat 16 externích kanál ů a t ři interní kanály (vnit řní referen ční nap ětí, nap ětí baterie a vestav ěný sníma č teploty). Samoz řejmostí je možnost vyvolání p řerušení po ukon čení p řevodu. Navíc lze vyvolat přerušení p ři p řekro čení nebo nedosažení ur čité úrovn ě vstupního signálu ( analog watchdog ). Každý kanál m ůže být vzorkován s vlastní vzorkovací frekvencí.

25 Hodinový signál m ůže být bu ď spole čný pro všechny p řevodníky (odvozený z hodinového signálu pro periferie d ělením dv ěma, čty řmi, šesti nebo osmi), nebo lze použít p římo tento hodinový signál. Lze zvláš ť povolit pro každý p řevodník. Převodníky lze také použít v tzv. Multi ADC módech, kde dva nebo t ři p řevodníky pracují spole čně a umož ňují tak dosáhnout kratší doby p řevodu p ři práci s více kanály, pop ř. je možné dosáhnout až t řikrát rychlejší vzorkování jednoho kanálu (p ři použití t ří převodník ů).

3.3.1 Výb ěr kanál ů

A/D p řevodníky mají k dispozici dohromady 16 externích multiplexovaných kanál ů. Převod t ěchto kanál ů lze rozd ělit do dvou skupin. Skupina regular group m ůže být sestavena až z šestnácti p řevod ů (každý kanál je převeden). Po čet a po řadí p řevod ů je nutno nastavit. Skupina injected group m ůže být složena až ze čty ř p řevod ů. Op ět je nutno nastavit po čet kanál ů a jejich po řadí.

3.3.2 Módy p řevodu

Převod m ůže být provád ěn v následujících módech [13].

Single A/D p řevodník vykoná pouze jediný p řevod. Tento p řevod m ůže být odstartován programov ě nebo externím spoušt ěcím vstupem. Na konci p řevodu je uložen výsledek a je nastaven p říznak ukon čení p řevodu. Je možné vyvolat p řerušení.

Continuous V tomto módu probíhají konverze jako v módu single, ale po provedení p řevodu je ihned zahájen nový p řevod. Tento mód nelze použít pro kanály typu injected.

Scan Tento mód slouží k převodu více kanál ů. Pro každý kanál, p řiřazený do skupiny, je proveden p řevod tak jako v módu single a následn ě je automaticky spušt ěn p řevod následujícího kanálu. Je možné ukon čit činnost po p řevodu posledního kanálu, nebo pokra čovat podobn ě jako v módu continuous. P řerušení je možné vyvolat bu ď po převodu každého kanálu nebo po ukon čení p řevodu celé skupiny. Také je možné pomocí DMA p řenášet výsledek p řevodu p římo do SRAM. To platí pouze pro kanály typu regular.

Discontinuous Slouží k provedení p řevodu ur čitého po čtu kanálů (max. 8) z vybrané skupiny pomocí externího spoušt ěcího vstupu.

26 3.3.3 Výsledek p řevodu

Výsledek p řevodu je uložen do 16-bitového datového registru. Data mohou být zarovnána vlevo nebo vpravo. Pro výsledek p řevodu skupiny injected group lze navíc ode číst uživatelsky definovanou konstantu a získat tak nap ř. záporné číslo. V případ ě požadavku rychlé konverze více než jednoho kanálu skupiny regular group lze výhodn ě použít DMA mechanismu k uložení více p řevedených hodnot do pam ěti. Přerušení lze vyvolat po ukon čení p řevodu skupiny regular group , po ukon čení převodu skupiny injected group , dále p ři p řekro čení/nedosažení ur čité úrovn ě vstupního signálu ( analog watchdog ) a p ři ztrát ě dat (p řete čení) p ři p řenosu pomocí DMA.

3.3.4 Parametry A/D p řevodu

Krom ě funk čních vlastností A/D p řevodníku jsou velmi d ůležité také parametry vlastního p řevodu jako rychlost, p řesnost a rozlišení. Tyto parametry jsou zvlášt ě důležité pro použití v číslicové regulaci. Jak bylo uvedeno, vestav ěné A/D p řevodníky mikrokontroléru STM32F407VGT6 mají nastavitelné rozlišení 6, 8, 10 nebo 12 bit ů. Podle [12] je celkový čas p řevodu (v četn ě doby vzorkování) p ři rozlišení 12 bit ů a hodinové frekvenci p řevodníku 30 MHz maximáln ě 16,40 µs. Maximální rychlost vzorkování p ři stejné frekvenci (30 MHz) a rozlišení 12 bit ů je 2 Msps p ři použití jediného p řevodníku. V případ ě použití t ří p řevodník ů je to až 6 Msps. Vzorkovací čas lze nastavit pro každý kanál zvláš ť (externí i interní) v osmi krocích v rozmezí 3 až 480 hodinových cykl ů A/D p řevodníku. V případ ě hodinové frekvence 30 MHz je to rozmezí 0,1 µs až 16 µs. Vlastní čas p řevodu metodou postupné aproximace je dán použitým rozlišením a pohybuje se od 6 hodinových cykl ů pro rozlišení 6 bit ů po 12 cykl ů pro rozlišení 12 bit ů. Výrobce uvádí, že celková chyba p řevodu p ři frekvenci 30 MHz je typicky ±2 LSB a celková maximální chyba je ±5 LSB [12].

3.4 Vestav ěné D/A p řevodníky

V mikrokontroléru STM32F407VGT6 jsou vestav ěny také dva 12-bitové D/A převodníky s nap ěť ovým výstupem. P řevodníky mohou pracovat samostatn ě nebo synchronn ě. Rozlišení je nastavitelné na 8 nebo 12 bit ů. P ři použití rozlišení 12 bit ů mohou být data pro p řevod zarovnána vlevo nebo vpravo. Na výstupu p řevodník ů lze použít vestav ěný výstupní odd ělovací zesilova č, který snižuje výstupní impedanci a umož ňuje p římé buzení malé zát ěže p římo, bez použití přídavného zesilova če.

27 Převod m ůže být spušt ěn softwarov ě, externím spoušt ěcím vstupem nebo intern ě časova čem. K přenosu dat lze také využít mechanismus DMA. Je k dispozici také lineární posuvný registr pro generování pseudonáhodného signálu. Dále je možné generovat trojúhelníkový signál. D/A p řevodníky lze použít ve dvoukanálovém režimu, kdy jsou jedním zápisem do registr ů ovládány oba p řevodníky. Lze nastavit nezávislé nebo synchronní spoušt ění.

3.4.1 Parametry D/A p řevodník ů

Výrobce uvádí výstupní impedanci 15 k Ω p ři vypnutém odd ělovacím zesilova či. Minimální zat ěžovací odpor p ři rezistivní zát ěži uvádí 1,5 M Ω pro dosažení p řesnosti 1%. P ři zapnutém odd ělovacím zesilova či je minimální zat ěžovací odpor 5 k Ω a maximální kapacita 50 pF [12]. Podle katalogového listu [12] je diferenciální nelinearita maximáln ě ±2 LSB. Maximální integrální nelinearita (odchylka od lineárního pr ůběhu výstupu) je ±4 LSB. Chyba zp ůsobená posunem výstupu ( offset ) je ±12 LSB p ři vnit řním referen čním nap ětí 3,6 V. Čas pot řebný k ustálení výstupu je maximáln ě 6 µs. Maximální frekvence zm ěn výstupu je 1 Msps za podmínky malých zm ěn (zm ěna o 1 LSB).

3.5 Vývojová deska STM32F4-Discovery

STM32F4-Discovery je levná vývojová deska od firmy ST Microelectronics, jejíž hlavní sou částí je mikrokontrolér STM32F407VGT6, popisovaný v této kapitole. Vývojovou desku lze pomocí USB p řipojit k PC se systémem Windows XP a vyšší, přičemž p řes rozhraní USB je zajišt ěno také napájení desky. V základním stavu je tedy k využívání desky t řeba pouze PC s odpovídajícím softwarovým vybavením. Deska pak také poskytuje nap ětí 5 V a 3 V pro externí aplikace s proudovým odb ěrem maximáln ě 100 mA. Samoz řejm ě je možné desku napájet i z externího zdroje 5 V. Deska se připojuje k PC kabelem USB A – mini-B. Sou částí desky je také programovací a ladicí rozhraní ST-LINK/V2, jehož činnost a komunikace s PC je zajišt ěna prost řednictvím druhého mikrokontroléru (STM32F103). Rozhraní ST-LINK/V2 slouží k programování a lad ění mikrokontrolér ů řad STM32 a STM8 a lze jej použít jak k programování a lad ění pro použitý mikrokontrolér STM32F407VGT6, tak jako samostatný programátor pro jiné aplikace. K tomuto ú čelu je na desce zvláš ť vyvedený programovací konektor SWD ( serial wire debugging ) a dvojice přepínacích propojek ( jumper ), pomocí kterých lze snadno zvolit požadovanou funkci [14]. Všech 100 vývod ů mikrokontroléru STM32F407VGT6 je vyvedeno na konektory po stranách desky. Dále je k dispozici m ěř icí místo (JP1) pro m ěř ení spot řeby mikrokontroléru. Na desce je také n ěkolik pájecích m ůstk ů pro zm ěnu n ěkterých funkcí

28 a USB Micro-AB konektor s indika čními LED diodami pro p řipojení k USB OTG rozhraní mikrokontroléru STM32F407VGT6. Mezi další vybavení vývojové desky STM32F4-Discovery pat ří: 1) nízkop říkonový t říosý lineární MEMS akcelerometr LIS302DL firmy ST Microelectronics s citlivostí ±2/±8 g [15], p řipojený k mikrokontroléru p řes rozhraní SPI. 2) všesm ěrový MEMS mikrofon MP45DT02 firmy ST Microelectronics s citlivostí -26 dB a maximálním rozlišitelným akustickým tlakem 120 dBSPL [16]. 3) nízkop říkonový audio D/A p řevodník CS43L22 firmy Cirrus Logic s integrovaným zesilova čem t řídy D a sluchátkovým zesilova čem [17], připojený k mikrokontroléru p řes rozhraní I 2C 4) stavové a uživatelské LED diody 5) uživatelské tla čítko a tla čítko reset

Vývojovou desku STM32F4-Discovery dodává nap ř. internetový obchod Farnell (www.farnell.com ). Deska je dodávána s nahraným demonstra čním programem ve FLASH pam ěti mikrokontroléru. Je možné dodat také p říslušenství (rozši řující deska s konektory pro n ěkterá komunika ční rozhraní, 3,5“ LCD modul, CMOS kamera). Na Obr. 3-3 je blokové schéma zapojení desky.

Obr. 3-3: Blokové schéma zapojení vývojové desky STM32F4-Discovery [14]

29 4 VÝB ĚR OPERA ČNÍCH SYSTÉMŮ REÁLNÉHO ČASU

4.1 Opera ční systémy reálného času

Opera ční systém reálného času ( Real-time operating system , RTOS) je víceúlohový (multi-tasking ) opera ční systém pro použití v oblastech, kde je zapot řebí vykonávání ur čitých složit ějších úloh v definovaných časových intervalech ( deadline ). To je často vyžadováno zejména v regula ční a m ěř icí technice, robotice a obecn ě ve vestav ěných systémech. V případ ě složit ějších problém ů již nemusí být možné p ři použití smy čkového řízení zaru čit požadované časové vlastnosti. Použitím opera čního systému reálného času lze zaru čit deterministické chování i p ři realizaci složit ějších úloh. Z toho plyne základní požadavek na opera ční systém reálného času, tj. deterministické chování. Chování systému m ůže být řízeno událostmi nebo časem, v praxi jsou často na opera ční systém reálného času kladeny tyto dva požadavky sou časn ě. Opera ční systém reálného času je tedy takový opera ční systém, který je schopen provád ět výpo čty a reagovat na události v definovaných časových intervalech ( deadlines ) [18]. Systémy pracující v reálném čase lze klasifikovat na následující skupiny.

Soft real-time systémy U tohoto typu systém ů není nutné časové intervaly dodržet p řesn ě a jejich nedodržení obvykle nevede k vážným následk ům. Posta čí, pokud požadavky budou spln ěny v ur čitém časovém intervalu. V [19] je uvedeno, že soft real-time systém je takový systém, kde naprogramovaná reakce na ur čitý podn ět je tém ěř vždy dokon čena ve známém kone čném čase.

Hard real-time systémy Tyto systémy musí bezpodmíne čně zajistit dodržení časových požadavk ů. Nespln ění těchto požadavk ů by vedlo k selhání systému a potenciáln ě nebezpe čným situacím. Podle [19] je hard real-time systém takový systém, kde je garantováno, že reakce systému na podn ět bude dokon čena ve známém kone čném čase.

Toto d ělení lze pak aplikovat nejen na celé systémy, ale nap ř. i na jednotlivé procesy v rámci jednoho systému. V praxi se pak lze často setkat s ob ěma uvedenými požadavky na časové chování sou časn ě a to zejména u velkých systém ů [18]. Je také samoz řejm ě možné, aby sou částí systému byly krom ě hard a soft real-time proces ů také procesy bez zvláštních časových požadavk ů [19]. Je nutné si uv ědomit, že časové vlastnosti systému, tj. p říslušnost k některé z uvedených skupin, stejn ě tak jako celková funk čnost a spolehlivost systému, nejsou

30 ur čeny prostým použitím opera čního systému reálného času, ale především správným a pe člivým návrhem systému jako celku, tj. v četn ě všech funk čních blok ů a zp ůsobu jejich vzájemné interakce. Pokud je dodržen správný návrh a implementace systému, lze s použitím OS reálného času dosáhnout velmi spolehlivých výsledk ů. Na druhé stran ě s sebou použití opera čního systému p řináší také celkové snížení výkonnosti systému a p ři nevhodném návrhu i problémy s konzistencí provád ěných operací. Pokud je nap ř. jedna úloha v pr ůběhu čtení dat na ur čitou dobu p řerušena z důvodu spušt ění jiné úlohy s vyšší prioritou, je možné, že čtená data budou b ěhem této doby zm ěněna. To bude pravd ěpodobn ě mít nežádoucí následky. Z tohoto d ůvodu disponují opera ční systémy řadou synchroniza čních prost ředk ů, které slouží nejen k synchronizaci a komunikaci mezi úlohami, ale často i k ochran ě r ůzných sdílených zdroj ů. Opera ční systém reálného času by m ěl disponovat preemptivním plánova čem úloh, který zajistí, že bude v každém okamžiku provád ěna úloha s nejvyšší prioritou, která je schopna b ěhu. Nepreemptivní, tj. kooperativní OS lze také použít. Tyto systémy jsou jednodušší, avšak zde je nutný kvalitní návrh tak, aby každá úloha umožnila b ěh také úlohám ostatním a nedošlo k zablokování.

4.2 Výb ěr RTOS s podporou jádra ARM Cortex-M4F

Jedním z úkol ů této práce je vyhledání opera čních systém ů reálného času, které lze provozovat na mikrokontrolérech s jádrem ARM Cortex-M4F. Jádro Cortex-M4 je krom ě absence jednotky FPU totožné s jádrem Cortex-M4F. OS reálného času s podporou jádra Cortex-M4 by tedy prakticky jist ě bylo možné použít i s jádrem Cortex-M4F, samoz řejm ě bez nároku na hardwarové výpo čty s plovoucí řádovou čárkou. Pro realizaci regula čních embedded systém ů je však práv ě tato vlastnost žádoucí a proto byl p ři vyhledávání RTOS kladen d ůraz na p římou podporu jádra Cortex-M4F, tj. včetn ě podpory FPU, bez nutnosti úprav. Tím byl stanoven první požadavek a podle n ěj bylo nalezeno n ěkolik následujících opera čních systém ů (jsou uvedeny v přibližném po řadí podle nalezení).

FreeRTOS [20] NuttX [21] µC/OS-II [22] SMX RTOS [23] ChibiOS/RT [24] eCos [25]

31 Nalezené OS reálného času lze následn ě rozd ělit na dv ě skupiny podle toho, zda jsou voln ě ši řitelé, či nikoliv. Z uvedených šesti systém ů jsou komer ční pouze dva a to systémy µC/OS-II a SMX RTOS. Pro systém µC/OS-II je nabízena bezplatná zkušební verze na 45 dní, vzhledem k omezené dob ě však tato nabídka nebyla využita. Skupinu voln ě ši řitelných OS tvo ří zbylé čty ři systémy. Jedním z úkol ů zadání a sou časn ě cíl ů této práce je výb ěr dvou voln ě ši řitelných OS reálného času. První a ve zna čném p ředstihu p řed ostatními OS byl nalezen opera ční systém FreeRTOS. Tento systém je velmi dob ře známý, profesionáln ě vyvíjený a ov ěř ený, proto byl vybrán jako první OS k implementaci do zadaného mikrokontroléru STM32F407VGT6. Dalšími nalezenými systémy byly NuttX a ChibiOS/RT. Systém NuttX nabízí podporu standard ů POSIX a ANSI, kompaktnost a konfigurovatelnost. Z pohledu realizace regula čního embedded systému však nenabízí žádné zvlášt ě užite čné funkce. Dokumentace, která je dostupná na internetových stránkách, je navíc jen velmi nep řehledná. Opera ční systém ChibiOS/RT nabízí vysokou rychlost, což je pro realizaci regula čních systém ů výhodné. Dále nabízí kompaktnost a také vrstvu abstrakce hardwaru (HAL), která obsahuje ovlada če b ěžn ě používaných periferií. Dostupná dokumentace je p řehledná a srozumitelná. Díky uvedeným vlastnostem byl tedy systém ChibiOS/RT vybrán jako druhý OS pro implementaci do daného mikrokontroléru. Poslední uvedený systém eCos byl nalezen až pozd ěji. Tento systém nabízí zajímavé vlastnosti, vzhledem k jeho komplexnosti a nedostatku času však nebyl použit.

Podrobn ějšímu popisu vybraných systém ů, tj. systém ů FreeRTOS a ChibiOS/RT budou v ěnovány samostatné kapitoly (kap. 5 a 6). V následující části je uveden stru čný popis ostatních nalezených OS reálného času. Systém SMX RTOS nebude popsán z důvodu pozdního nalezení použitelné dokumentace.

4.3 Popis n ěkterých nalezených opera čních systém ů

4.3.1 NuttX

NuttX je otev řený opera ční systém reálného času, který je ur čen pro malé vestav ěné systémy. Tento systém vyhovuje standard ům POSIX a ANSI a dále p řebírá pro rozší ření funkcionality n ěkteré standardní API funkce ze systému Unix a n ěkterých dalších opera čních systém ů reálného času (nap ř. VxWorks). Díky shod ě se standardy lze snadno do systému NuttX p řenést software, vytvo řený pro jiný standardní opera ční systém. D ůraz je kladen také na nízké pam ěť ové nároky a velkou škálovatelnost od 8-bitových až po 32-bitové systémy. Opera ční systém NuttX nabízí množství funkcí a obsahuje velké množství zdrojových soubor ů, kde v ětšina z nich obsahuje pouze jedinou funkci. Tyto zdrojové

32 soubory se p ři p řekladu sestavují do knihoven. Objektové soubory z těchto knihoven se poté p řipojují k výslednému spustitelnému souboru v závislosti na tom, které části a funkce opera čního systému jsou použity. Díky tomu je dosaženo velmi dobré modularity a škálovatelnosti a výsledný binární soubor má minimální velikost, protože obsahuje pouze funkce, které jsou systémem využívány [26]. Systém NuttX nabízí krom ě úloh ( task ) také podporu vláken podle standardu POSIX (pthread ). Tato vlákna mohou být vytvo řena úlohou a následn ě s touto úlohou sdílí její zdroje. Úlohy jsou tedy navzájem nezávislé, zatímco vlákna vždy sdílí prost ředky úlohy, která je vytvo řila. N ěkteré funkce opera čního systému jsou implementovány jako interní úlohy/vlákna. Úlohy jsou spoušt ěny podle priority, tj. b ěží vždy úloha s nejvyšší prioritou. Je také možné, aby m ělo více úloh stejnou prioritu. Tyto úlohy jsou pak ve výchozím nastavení spoušt ěny podle algoritmu FIFO. Tento plánovací algoritmus, n ěkdy také ozna čovaný FCFS ( First Come, First Served ), spouští úlohy jednoduše podle po řadí p říchodu jejich požadavku na b ěh [27]. Systém NuttX také voliteln ě podporuje plánovací algoritmus Round-Robin s nastavitelným časovým kvantem. Pro synchronizaci a komunikaci mezi úlohami systém NuttX nabízí fronty zpráv, čítací semafory, watchdog časova če a signály. Semafory jsou základním synchroniza čním prost ředkem v systému NuttX a jsou preferovány pro ochranu p řístupu ke zdroj ům. V ětšina dalších synchroniza čních prost ředk ů využívá funkcionality semafor ů. Semafory podporují také mechanismus d ědění priorit. Jeho využití je konfigurovatelné. Signály slouží pro asynchronní komunikaci mezi úlohami, pop ř. mezi úlohami a obslužnými rutinami p řerušení. Úloha, mlže vyslat signál jiné konkrétní úloze. Tato úloha, jakmile je spušt ěna, provede akci, která je pro tento signál uživatelsky definována. Systém NuttX voliteln ě nabízí také škálovatelný jednoduchý souborový systém s podporou FAT12/16/32. Dále je k dispozici velké množství ovlada čů pro r ůzná za řízení v četn ě ovlada če pro sí ťová rozhraní, USB rozhraní, sériová komunikace, rozhraní I2C, I2S, NAND pam ěti, ovlada če pro pam ěť ové karty MMC, SD, SDH komunikující p řes rozhraní SPI nebo SDIO, ovlada če pro A/D a D/A p řevodníky, časova če apod. Dále jsou nabízeny ovlada če pro segmentové i grafické LCD displeje přes paralelní rozhraní i rozhraní SPI. Pro sí ťovou komunikaci je p řítomna podpora protokol ů TCP/IP, UDP, ICMP. Systém také pln ě integruje standardní knihovnu C a matematickou knihovnu pro podporu výpo čtů v plovoucí řádové čárce [21]. Kompletní seznam podporovaných architektur, rozd ělených podle jádra, pop ř. podle výrobce, lze nalézt v [28].

33 4.3.2 µC/OS-II

Systém µC/OS-II je p řenosný a škálovatelný opera ční systém reálného času, ur čený pro mikrokontroléry a digitální signálové procesory (DSP). Nabízí jednoduché použití a jeho zdrojový kód je vytvo řen v jazyku C podle standardu ANSI C. Tento systém je implementován také ve velkém množství aplikací s vysokou funk ční bezpe čností. Jádro systému je preemptivní a aplikace m ůže využít 254 úloh, kde jedné priority může nabývat pouze jedna úloha. Pro synchronizaci lze využít semafory, p říznaky událostí, mutexy s eliminací inverze priorit, fronty a zprávy typu mailbox . Dále jsou nabízeny časova če. Je možná alokace pam ěti po blocích o pevné velikosti [22]. Jsou podporovány jednotky FPU, MPU i MMU a také víceprocesorové systémy. Pam ěť ová náro čnost systému je 6 až 24 kB programové pam ěti v závislosti na konfiguraci. Spot řeba pam ěti RAM je od 500 B výše. Lze využít vestav ěné m ěř ení výkonu, nap ř. využití CPU a zásobník ů nebo po čítadlo p řepnutí kontextu. Systém µC/OS-II je certifikován také nap ř. podle normy IEC61508 [29]. V sou časné dob ě je podporováno p řibližn ě 50 procesorových architektur od r ůzných výrobc ů [30]. K systému µC/OS-II je dostupná také rozsáhlá dokumentace ve form ě knihy, kterou lze stáhnout z [31].

4.3.3 eCos

Opera ční systém eCos je voln ě ši řitelný a otev řený opera ční systém reálného času, který je ur čen pro embedded aplikace. Jeho název je zkratkou slovního spojení Embedded Configurable Operating System , což nazna čuje velmi dobrou konfigurovatelnost systému. Jednou z hlavních vlastností opera čního systému eCos je konfigura ční systém. Tento systém dovoluje p ři tvorb ě aplikací ovliv ňovat jak funkcionalitu jednotlivých částí opera čního systému, tak i jejich implementaci, což obvykle není možné. To v podstat ě umož ňuje vytvo řit speciální opera ční systém, který p řesn ě spl ňuje požadavky konkrétní aplikace. Uvedená vlastnost činí z opera čního systému eCos velmi univerzální systém, použitelný v širokém rozsahu embedded aplikací. Je také zajišt ěna minimalizace pam ěť ových nárok ů, veškerá nepot řebná funkcionalita systému m ůže být odstran ěna. S konfigura čním systémem souvisí také architektura opera čního systému eCos. Ten se skládá z r ůzných komponent, což poskytuje standardní mechanismus pro rozši řování funkcionality systému. Jednotlivé komponenty jsou bu ď p římou sou částí distribuce nebo je lze získat od komunity vývojá řů , pop ř. také jako komer ční produkty t řetích stran [32]. Systém eCos se skládá z následujících komponent [33].

34 Vrstva abstrakce hardwaru (HAL) Tato vrstva slouží k odd ělení implementace závislé na dané architektu ře od ostatních částí systému, které ji využívají a pro které poskytuje jednotné aplika ční rozhraní (API). Celá vrstva HAL je implementována v jazyku C a jazyku symbolických adres. Rozhraní je implementováno pomocí maker, což dovoluje jeho efektivní využití, protože je eliminováno volání funkcí. Nevýhodou tohoto p řístupu je pak zvyšování pam ěť ových nárok ů. Je kladen d ůraz na snadnou rozši řitelnost pro nové platformy. Vrstva abstrakce hardwaru se skládá ze t ří modul ů. První modul definuje architekturu. V systému eCos je za samostatnou architekturu považována každá rodina procesor ů. Tento modul obsahuje kód pro inicializaci procesoru, správu p řerušení a p řepínání kontextu a n ěkteré další funkce, specifické pro ur čitou rodinu procesor ů. Druhý modul definuje variantu, tj. konkrétní procesor dané rodiny. Kód obsažený v tomto modulu m ůže obsahovat ovlada če pro r ůzná za řízení, kterými konkrétní procesor/mikrokontrolér disponuje. Třetí modul definuje platformu. Platformou je zde myšlen ur čitý hardware, nap ř. vývojová deska, obsahující ur čitý mikrokontrolér. Modul obsahuje inicializaci hardwaru, konfiguraci mikrokontroléru apod.

Jádro systému ( Kernel ) Jádro p ředstavuje základní část systému a poskytuje standardní funkce, požadované od OS reálného času, tj. zpracování p řerušení, plánování úloh, synchronizace. Tyto jednotlivé části jsou konfigurovatelné a umož ňují tedy p řizp ůsobení systému požadavk ům aplikace. Jádro systému je implementováno v jazyku C++. Oficiální aplika ční rozhraní pro jazyk C++ však neexistuje. Jádro také podporuje rozhraní API podle standard ů µITRON [34] a POSIX. Opera ční systém eCos nabízí dv ě r ůzné možnosti plánování úloh, p řičemž použita může být jen jedna. Prvním plánovacím mechanismem je multilevel queue scheduler . Ten dovoluje provád ění n ěkolika úloh se stejnou prioritou. Po čet úrovní priorit je konfigurovatelný od 1 do 32 s tím, že nejvyšší priorita odpovídá hodnotě 0 a nejnižší priorita hodnot ě 31. Mezi r ůznými úrovn ěmi plánova č rozhoduje podle priorit, tj. je spušt ěna úloha s nejvyšší prioritou.. Úlohy o stejné priorit ě jsou spoušt ěny po časových úsecích (timeslicing ), tj. v postat ě algoritmus Round-Robin. Druhý plánovací mechanismus je bitmap scheduler . Tento plánova č umož ňuje rovn ěž více priorit, avšak není možné, aby existovalo více úloh se stejnou prioritou. To zjednodušuje plánování a tento plánova č je tak velmi efektivní. Využitelné úrovn ě priorit jsou stejné jako u prvního plánovacího mechanismu.

35 Volba plánovacího mechanismu závisí na pot řebách konkrétní aplikace. Podrobn ější popis plánování lze nalézt v [33]. Pro synchronizaci nabízí systém eCos mutexy, semafory, podmín ěné prom ěnné, příznaky, zprávy a zámky spinlock pro víceprocesorové systémy typu SMP [35]. Popis synchroniza čních mechanism ů lze nalézt v [36] a [33]. Jádro systému dále nabízí číta če, časova če a alarmy, alokaci pam ěti, využívající bloky pevné velikosti ( memory pools ), dále prost ředky pro lad ění a trasování.

Knihovna ISO C a matematická knihovna Systém eCos je kompatibilní se standardní knihovou ISO C a dále nabízí matematickou knihovnu, která m ůže pracovat ve čty řech r ůzných módech kompatibility (výchozí je kompatibilita se standardem POSIX) [33].

Ovlada če za řízení Ovlada če pro sériovou komunikaci, ethernet, SPI, I 2C, CAN, A/D p řevodníky, framebuffer pro zobrazování, watchdog obvody. Lze také vytvo řit vlastní ovlada če. Ovlada če mohou být vrstvené, tj. složit ější ovlada če mohou využívat jiných ovlada čů . Aplikace s ovlada čem za řízení komunikuje prost řednictvím standardního vstupn ě/výstupního rozhraní.

Podpora programu GDB (GNU debugger ) Pro lad ění systém nabízí software pro komunikaci aplikace s ladicím programem GNU debugger.

Systém eCos zahrnuje krom ě vlastní funkcionality také všechny nástroje, pot řebné k vývoji vestav ěných aplikací. Jedná se o konfigura ční nástroje, dále GNU překlada če, linkery, ladicí prost ředky a simulátory. V sou časné dob ě podporuje systém eCos 18 procesorových architektur [32].

36 5 OPERA ČNÍ SYSTÉM FREERTOS

FreeRTOS je voln ě ši řitelný, otev řený opera ční systém reálného času, ur čený pro použití v menších vestav ěných ( embedded ) za řízeních. Projekt FreeRTOS vznikl s cílem poskytnout kvalitní, voln ě ši řitelný opera ční systém reálného času, který by byl jednoduše použitelný. Zakladatelem projektu je Richard Barry, ředitel spole čnosti Real Time Engineers Ltd., která v sou časné dob ě tento systém vyvíjí a udržuje. Hlavními cíli vývoje systému jsou snadná použitelnost, robustnost a nízká pam ěť ová náro čnost [37]. Podle [38] je pro b ěh jádra na mikrokontroléru s jádrem ARM7 p ři plné optimalizaci t řeba 236 byt ů pam ěti RAM a navíc 64 byt ů pro každou vytvo řenou úlohu. P ři této konfiguraci je velikost jádra v rozmezí 5 až 10 kB. Základní funkcionalita opera čního systému FreeRTOS p ředstavuje pouze vlastní plánova č ( scheduler ) a správu úloh, komunikaci a synchronizaci mezi úlohami a časování. Systém lze dále rozší řit o p řídavné funkce, např. sí ťové rozhraní. V sou časné dob ě je podle [39] oficiáln ě podporováno více než 30 r ůzných procesorových architektur. Plánování úloh m ůže být preemptivní, kooperativní, pop ř. hybridní. Pro synchronizaci a komunikaci mezi úlohami lze použít fronty, semafory, mutexy a rekurzivní mutexy. Dále systém nabízí efektivní softwarové časova če [40] a p říznaky událostí [41]. Lze využít makra pro sledování b ěhu aplikace [42] a detekci přete čení zásobníku [43]. Po čet úloh a možných priorit není softwarov ě omezen, je možné p řiřadit více úlohám stejnou prioritu. Také je možnost podpory jednotky správy a ochrany pam ěti (MPU) pro mikrokontroléry s jádry ARM Cortex-M3. FreeRTOS je velmi populární a rozší řený opera ční systém pro embedded za řízení [44]. Je ší řen pod upravenou licencí GNU GPL. Tato úprava spo čívá v umožn ění použití systému v komer čních aplikacích a dále osvobozuje od povinnosti zveřejnit kód aplikace, pokud nedošlo k úprav ě jádra systému, nap ř. ke zm ěně nebo rozší ření jeho funk čnosti. Je také nabízena komer ční licence s profesionální podporou a zárukami. Více informací o licencích lze najít v [45]. Z opera čního systému FreeRTOS je také odvozen komer ční systém SAFERTOS [46], který spl ňuje normu funk ční bezpe čnosti IEC 61508 SIL 3 [47].

5.1 Podporované architektury a nástroje

Jak bylo uvedeno, opera ční systém FreeRTOS oficiáln ě podporuje více než 30 architektur mikrokontrolér ů. V [48] je uveden oficiální seznam výrobc ů s podporovanými rodinami mikrokontrolér ů a vývojovými nástroji. Od výrobce ST Microelectronics je podporována rodina mikrokontrolér ů STM32 s jádry ARM Cortex-M0, Cortex-M3 a Cortex-M4F, dále rodina STR7 založená na

37 jádru ARM7 a rodina STR9 s jádrem ARM9. Sou částí systému je mimo jiné také demo aplikace p římo pro mikrokontrolér STM32F407. Podporované vývojové nástroje pro mikrokontroléry tohoto výrobce jsou IAR, Atollic TrueStudio, GCC, Keil, Rowley CrossWorks. Mezi další oficiáln ě podporované výrobce pat ří: Altera Atmel Cortus Cypress Energy Micro Freescale Fujitsu Infineon Luminary Micro Microchip NEC Microsemi (Actel) NXP Renesas Silicon Labs Texas Instruments Xilinx

Je podporována i architektura x86 a je dostupný také simulátor systému FreeRTOS pro opera ční systém Windows [49]. Dále jsou dostupné i uživatelské modifikace pro několik dalších rodin procesorů, které však nejsou oficiáln ě podporovány. Detailní seznam výrobc ů a podporovaných rodin mikrokontrolér ů v četn ě popisu demo aplikací lze nalézt v [50].

5.2 Struktura zdrojových soubor ů

Opera ční systém FreeRTOS je distribuován ve form ě zdrojových soubor ů. Sou částí distribuce je krom ě jádra systému a jeho volitelných sou částí také velké množství demonstra čních aplikací pro podporované architektury a p řeklada če, pop ř. pro r ůzná integrovaná vývojová prost ředí (IDE). Distribuci lze zdarma stáhnout ve form ě standardního zip archivu (.zip) nebo ve form ě samorozbalovacího archivu (.exe) [51]. V dob ě psaní této práce je aktuální verze 8.0.0. Ve staženém hlavním adresá ři ( FreeRTOSV8.0.0 ) se nachází krom ě textového souboru s popisem a odkaz ů na internetové stránky projektu FreeRTOS také dva podadresá ře. Podadresá ř FreeRTOS obsahuje vlastní zdrojové soubory opera čního

38 systému, demonstra ční aplikace a licen ční informace. Podadresá ř FreeRTOS-Plus pak obsahuje n ěkteré p řídavné funkce pro systém FreeRTOS a produkty t řetích stran, nap ř. vstupn ě/výstupní funkce, souborový systém atd. [52]. Další popis bude v ěnován struktu ře adresá ře FreeRTOS . Ta je znázorn ěna na Obr. 5-1.

Obr. 5-1: Struktura distribuce opera čního systému FreeRTOS [55]

V podadresá ři Source se nachází zdrojové soubory jádra systému v četn ě volitelných sou částí. Vlastní jádro systému je reprezentováno pouze t řemi zdrojovými soubory (tasks.c , queue.c a list.c ) [53]. Tyto soubory p ředstavují funkcionalitu pro správu úloh, front a seznam ů. Dále se zde nachází zdrojové soubory pro volitelné sou části systému. Jsou to timers.c pro funkce softwarových časova čů , croutine.c pro využití koprogram ů a event_groups.c pro p říznaky událostí. Adresá ř Source dále obsahuje podadresá ře include a portable . V podadresá ři include jsou umíst ěny všechny pot řebné hlavi čkové soubory. Podadresá ř portable pak obsahuje r ůzné implementace správy pam ěti (podadresá ř MemMang ) a dále zdrojové a hlavi čkové soubory, které jsou specifické pro konkrétní překlada č a architekturu. Struktura t ěchto soubor ů je následující. Nejprve je provedeno t říd ění podle p řeklada če (pop ř. použitého IDE). Každý překlada č je reprezentován vlastním adresá řem. V tomto adresá ři se pak nachází množství dalších podadresá řů , kde každý p ředstavuje jednu z podporovaných architektur. Každý z těchto podadresá řů pak obsahuje hlavi čkový soubor portmacro.h , definující nap ř. použité datové typy, a zdrojový soubor port.c , který definuje další specifika dané architektury a jeho velká část je psána v jazyce symbolických adres. Tyto dva soubory tedy v podstat ě tvo ří hardwarovou abstrakci (HAL). Podadresá ře n ěkterých architektur obsahují další soubory, které jsou sou částí HAL. Chceme-li nap ř. použít mikrokontrolér STM32F407VGT6 (jádro ARM Cortex-M4F) a překlada č GCC, pak soubory vrstvy HAL nalezneme v adresá ři

39 FreeRTOSV8.0.0/FreeRTOS/Source/portable/GCC/ARM_CM4F . Tyto soubory, stejn ě jako n ěkterou z implementací správy pam ěti (podadresá ř MemMang ), je pak samoz řejm ě t řeba p řidat ke zdrojovým soubor ům aplikace. V adresá ři FreeRTOSV8.0.0/FreeRTOS/Demo se nachází demonstra ční aplikace pro r ůzné architektury. Tyto aplikace lze využít jako vzor k tvorb ě aplikace vlastní. Sou částí demo aplikace je i konfigura ční soubor FreeRTOSConfig.h , který slouží k uživatelskému nastavení systému, nap ř. frekvence systémových hodin, maximální velikost haldy pro alokaci pam ěti, použití mutex ů apod. Více informací o tomto konfigura čním souboru lze nalézt v [54].

5.3 Správa úloh

Základní a nejd ůležit ější funkcí opera čního systému je správa úloh. Jednotlivé úlohy jsou spravovány pomocí řídicích blok ů úloh (Task Control Block, dále jen TCB). Tento blok obsahuje informace, které jsou využívány jádrem opera čního systému. Každá vytvo řená úloha má vlastní TCB, který pln ě ur čuje její stav. V [55] je uveden popis TCB pro FreeRTOS verze 4.1.3 z konce roku 2006 (dostupná z [56]), v [57] je pak uvedena struktura TCB pro blíže neur čenou verzi FreeRTOS, pravd ěpodobn ě z roku 2011 (dle data vytvo ření souboru). Z porovnání těchto dvou struktur je vid ět, že TCB se m ěnil s spolu s vývojem systému. Byla p řidána nap ř. nastavení použití jednotky ochrany a správy pam ěti (MPU) pro mikrokontroléry, které touto jednotkou disponují, nebo použití mutexů (funkcionalita pro mutexy byla uvedena ve verzi 4.5.0 v roce 2007 [58]). V Tab. 5-1 je uvedena struktura TCB použitá ve verzi FreeRTOS 8.0.0. Informace byly p řevzaty p římo ze zdrojového souboru tasks.c , který je sou částí jádra systému. TCB je zde definován jako typ struktury, obsahující pot řebné prom ěnné r ůzných datových typ ů. V ětšina t ěchto prom ěnných je definována podmín ěně, v závislosti na uživatelské konfiguraci systému a použitém mikrokontroléru. Úloha m ůže nabývat jednoho ze čty ř stav ů [59]. Na Obr. 5-2 je diagram p řechod ů mezi stavy úloh, p řevzatý z [60]. Tyto stavy jsou následující.

Běžící ( Running ) Stav, ve kterém se nachází aktuáln ě b ěžící úloha. V tomto stavu m ůže být v jednom okamžiku pouze jedna úloha a tato úloha má přístup k procesoru. Obvykle je to úloha s nejvyšší prioritou. Stav B ěžící m ůže úloha opustit bu ď sama, nebo rozhodnutím plánova če ( scheduler ), který také rozhoduje o spoušt ění úloh.

Připravená/ čekající ( Ready ) V tomto stavu se m ůže nacházet více úloh, které mají k dispozici všechny požadované zdroje a pouze čekají na spušt ění. Čekající úlohy jsou se řazeny v seznamu podle priority a jsou postupn ě spoušt ěny, tj. p řesouvány do stavu B ěžící.

40 Blokovaná ( Blocked ) V tomto stavu se nachází úlohy, které čekají na n ějakou událost nebo zdroj. Událost může být časová (nap ř. p ři cyklickém spoušt ění úlohy) nebo externí. Zdrojem mohou být fronty a semafory. Úloha se ve stavu Blokovaná m ůže nacházet pouze po ur čitou dobu, po jejímž uplynutí je odblokována a poté p řesunuta do stavu P řipravená

Pozastavená ( Suspended ) Do tohoto, pop ř. z tohoto stavu se úloha m ůže dostat pouze zavoláním p říslušné funkce aplika čního rozhraní (API) opera čního systému. Pro stav Pozastavená není možné ur čit časový limit.

Tab. 5-1: Struktura TCB v systému FreeRTOS název prom ěnné význam pxTopOfStack ukazatel aktuálního vrcholu zásobníku úlohy xMPUSettings nastavení pro jednotku MPU xGenericListItem stav úlohy 1 xEventListItem místo v seznamu událostí uxPriority priorita úlohy pxStack ukazatel za čátku zásobníku pcTaskName název úlohy pro lad ění pxEndOfStack ukazatel konce zásobníku uxCriticalNesting hloubka vno ření pro kritickou sekci uxTCBNumber po čet vytvo ření TCB (použití pro lad ění) uxTaskNumber číslo úlohy (pro trasování) uxBasePriority poslední priorita p řid ělená úloze (d ědění priorit) pxTaskTag tag hodnota p řid ělená úloze 2 ulRunTimeCounter čas b ěhu úlohy (úloha ve stavu B ěžící) xNewLib_reent reentrantní struktura pro knihovnu Newlib 3

1 Jedná se o položku seznamu, která reprezentuje danou úlohu a náleží do n ěkterého ze seznam ů připravených, blokovaných nebo pozastavených úloh. Tím je v podstat ě ur čen stav úlohy. 2 Tuto hodnotu jádro systému nepoužívá a lze ji využít libovoln ě v aplikaci. M ůže p ředstavovat libovolnou hodnotu v četn ě ukazatele na funkci. V [61] a [62] lze nalézt popis API funkcí pro nastavení a čtení této hodnoty v četn ě p říklad ů použití. 3 Newlib je knihovna pro jazyk C a je ur čena pro použití ve vestav ěných systémech. [63] Ukazatel na tuto strukturu je použit pro p ředávání kontextových informací p ři použití knihovních funkcí. Více nap ř. v [64] a [65]. Podpora knihovny Newlib v systému FreeRTOS je volitelná.

41 Obr. 5-2: P řechodový diagram stav ů úloh v systému FreeRTOS [60]

5.4 Plánování a priority

Jak bylo výše uvedeno, plánova č ( scheduler ) opera čního systému FreeRTOS m ůže být preemptivní nebo kooperativní. P ři každém uplynutí periody systémových hodin je vyvoláno p řerušení a plánova č pracuje jako obslužná rutina tohoto p řerušení. Podle [55] je v této obslužné rutin ě vždy nejprve resetován časova č, m ěř ící systémový čas. Další akce jsou závislé na nastaveném režimu. V preemptivním režimu je pak uložen kontext práv ě b ěžící úlohy. Následn ě je inkrementován systémový čas. Tato událost m ůže zp ůsobit odblokování n ěkterých úloh, proto je testováno i toto. Pokud dojde k odblokování úlohy s vyšší prioritou, n ěž má úloha práv ě b ěžící, dochází k přepnutí kontextu ( context switch ). Plánovací mechanizmus rozhoduje o spoušt ění úloh pouze na základ ě priority. Každé úloze je přid ělena priorita v rozsahu od 0 (úlohy s nejnižší prioritou) do maximální hodnoty. Tuto maximální prioritu lze nastavit uživatelsky podle požadavk ů aplikace. Nakonec je kontext obnoven a obsluha p řerušení kon čí. Pokud je nastaven kooperativní režim, dojde pouze k inkrementaci systémového času. Pokud se ve stavu P řipravená nachází více úloh se stejnou prioritou a není tedy možné rozhodnout, která úloha by m ěla b ěžet, je pro plánování aplikován algoritmus Round-Robin [66]. Tento algoritmus spo čívá v přid ělení ur čitého časového kvanta (quantum, time-slice ), po který je daná úloha vykonávána. Po uplynutí tohoto času je

42 úloha p řerušena a je spušt ěna úloha další. Takto je každé úloze p řid ělen stejný čas pro běh. Je samoz řejm ě možné provést p řepnutí úloh d říve než uplyne vymezené časové kvantum, pokud nap ř. práv ě b ěžící úloha sama vyšle požadavek k přepnutí nebo dojde-li k odblokování úlohy s vyšší prioritou. Volba časového kvanta je kompromisem mezi dobou čekání jednotlivých úloh a frekvencí p řepínání kontextu. V [66] je uvedeno, že pro deset úloh (proces ů) je p ři časovém kvantu 100 ms a dob ě p řepnutí kontextu 5 ms doba čekání poslední úlohy 945 ms a procesorový čas spot řebovaný pro p řepínání kontextu p ředstavuje 4 % z celkového času. Oproti tomu p ři časovém kvantu 10 ms je doba čekání poslední úlohy pouze 135 ms, ale čas spot řebovaný na p řepínání kontextu se zvýšil na více než 33 %. V systému FreeRTOS je časové kvantum, p řid ělené jednotlivým úlohám, rovno period ě systémových hodin. P ři každém p řerušení po uplynutí periody hodin je provedeno p řepnutí na další úlohu [60]. Na Obr. 5-3 je p říklad spoušt ění dvou úloh se stejnou prioritou.

Obr. 5-3: Znázorn ění spoušt ění úloh pomocí algoritmu Round-Robin [60]

Opera ční systém FreeRTOS dále nabízí využití kritických sekcí. Kritická sekce je úsek kódu, který z nějakého d ůvodu nemá být p řerušován. Pro tento ú čel lze použít definovaná makra pro vstoupení do kritické sekce a její opušt ění. P ři vstupu do kritické sekce jsou zakázána p řerušení a p ři opušt ění této sekce jsou p řerušení op ět povolena. Kritické sekce ve FreeRTOS mohou být vno řené. Pokud funkce v kritické sekci zavolá jinou funkci, která taktéž obsahuje kritickou sekci, dochází k vno ření. Každá úloha má vlastní prom ěnnou pro uložení hloubky vno ření do kritické sekce (viz Tab. 5-1). P ři každém vstupu do kritické sekce je tato prom ěnná inkrementována, při každém opušt ění kritické sekce je dekrementována.

43 Plánova č úloh je také možné pozastavit. Na rozdíl od kritické sekce, kde jsou zakázána p řerušení, je p ři pozastavení plánova če obsluha p řerušení povolena. Pozastavení lze použít pro úlohy, které pot řebují b ěžet nap ř. po delší dobu a zárove ň je zapot řebí zachovat aktivní obsluhu p řerušení. Podle [55] m ůže být pozastavení plánova če vno řené, tj. lze plánova č pozastavit několikrát. Pak je t řeba jeho činnost obnovit stejným po čtem volání p říslušné funkce. Při obnovení funkce plánova če je otestováno, zda v dob ě, kdy byla jeho činnost pozastavena, nedošlo k odblokování n ěkterých úloh. Pokud došlo k odblokování úlohy s vyšší prioritou, než má úloha práv ě b ěžící, dojde okamžit ě po obnovení činnosti k přepnutí na tuto úlohu. V dob ě, kdy je pozastavena činnost plánova če, nesmí být volány API funkce, které by m ěly za následek p řepnutí kontextu [67].

5.5 Synchronizace a komunikace

Pro synchronizaci a komunikaci nabízí systém n ěkolik prost ředk ů. Základním z těchto prost ředk ů jsou fronty. Mechanizmu front pak využívají ostatní synchroniza ční a komunika ční prost ředky opera čního systému FreeRTOS [60].

5.5.1 Fronty

Jak bylo uvedeno, fronty jsou hlavním prost ředkem komunikace mezi úlohami. Lze je použít ke sdílení dat mezi úlohami nebo mezi úlohami a obslužnými rutinami p řerušení. Ve v ětšin ě p řípad ů je fronta využívána jako pam ěť typu FIFO ( First In, First Out ) s tím, že data jsou posílána na konec fronty. Lze také posílat data na za čátek fronty. Fronta je charakterizována dv ěma parametry. Prvním je velikost dat, tj. velikost jedné každé datové bu ňky, uložené ve front ě. Druhým parametrem je délka fronty, tj. po čet bun ěk o dané velikosti. Tyto parametry jsou pevn ě nastaveny p ři vytvo ření fronty. Data jsou frontami p řenášena pomocí kopií, tj. pokud úloha pošle do fronty data, jsou tato data zkopírována. Podle [68] je tento p řístup vhodný mimo jiné z následujících důvod ů. Data uložená v prom ěnných mohou být do fronty poslána p římo, bez nutnosti vytvá řet pomocné prom ěnné. Stejn ě tak je možné data z fronty ukládat p římo do prom ěnných. Po odeslání do fronty m ůže úloha s prom ěnnou ihned pracovat, protože její obsah byl zkopírován. Dále je možné do fronty p ředávat data odkazem, pokud je místo samotných dat do fronty zkopírován ukazatel na tyto data. Další možností je do fronty odeslat strukturu, která obsahuje ukazatel na data a také prom ěnnou, která udává velikost t ěchto dat. Tímto je možno dosáhnout r ůzné délky dat v jedné front ě. Podobným p řístupem lze do fronty posílat r ůzné typy dat a zpráv, kdy zp ůsob zpracování dat závisí na jejich typu, poslaném do fronty spolu s těmito daty.

44 Alokaci pam ěti pro fronty obstarává jádro systému a pouze jádro má k této pam ěti přístup. To zajistí p ředání dat i v případ ě, že komunikující úlohy mají k dispozici r ůzné pam ěť ové prostory (z d ůvodu ochrany pam ěti). Pro použití v obslužných rutinách p řerušení jsou ur čeny zvláštní funkce pro práci s frontami, což dovoluje jisté zjednodušení. Více informací lze nalézt v [68].

Pokud se úloha pokouší číst z prázdné fronty, pop ř. zapisovat do plné fronty, je zablokována (p řesunuta do stavu Blokovaná). P ři volání funkcí pro čtení nebo zápis do fronty je také možné nastavit časový limit, po který je úloha blokována.Ve stavu Blokovaná z ůstává úloha až do doby, kdy jsou ve front ě k dispozici data (pop ř. je k dispozici volné místo pro zápis) nebo když dojde k dosažení nastaveného časového limitu pro blokování. Poté je úloha p řesunuta do stavu P řipravená. Pokud je blokováno více úloh, čekajících na frontu, je jako první odblokována úloha s nejvyšší prioritou [68]. V [60] je dále uvedeno, že pokud je blokováno více úloh, čekajících na frontu, a majících stejnou prioritu, jako první bude odblokována úloha, která první odeslala požadavek. Při čtení z fronty je p řečtený prvek odebrán, je však možné použít speciální funkci pro čtení, která zajistí, aby byl p řečtený prvek zachován.

5.5.2 Binární semafory

Binární semafory p ředstavují nejjednodušší zp ůsob synchronizace úloh pop ř. úloh a p řerušení. Binární semafor je v podstat ě fronta s délkou rovnou jedné, tj. lze do n ěj uložit pouze jeden prvek. Tento semafor tedy m ůže být bu ď prázdný nebo plný, tj. nabývá pouze dvou stav ů. Odtud název binární [69]. Úlohy a obslužné rutiny p řerušení, využívající binárních semafor ů, pak nepracují přímo s obsahem této jednoprvkové fonty, ale pouze s informací, zda je plná nebo prázdná. Obsluha semaforu je obdobná jako u fronty. Úlohy mohou semafor nastavit (give ) nebo p řečíst ( take ). P řečtením je semafor vyprázdn ěn a m ůže být op ětovn ě nastaven. Podobn ě jako u front je úloha p ři pokusu p řečíst semafor, který nebyl nastaven, p řesunuta do stavu Blokovaná až do doby, kdy dojde k jeho nastavení. Op ět je možné nastavit časový limit pro odblokování v případ ě, že do této doby není semafor nastaven. Při nastavování semaforu k blokování nedochází. Pokud se úloha pokouší nastavit semafor, který je již nastaven, vrátí p říslušná funkce chybové hlášení. V [69] je uveden p říklad použití binárního semaforu pro synchronizaci obsluhy periferie. Úloha, která tuto periferii obsluhuje, je v ětšinu času ve stavu Blokovaná. P ři pot řeb ě obsluhy periferie je vyvoláno p řerušení a obslužná rutina tohoto p řerušení pouze nastaví binární semafor. P ři nastavení semaforu dochází k odblokování úlohy a tato obslouží periferii.

45 5.5.3 Čítací semafory

Tyto semafory lze považovat op ět za fronty, v tomto p řípad ě s délkou v ětší než jedna. Čítací semafory tedy mohou být p řečteny vícekrát. Tak jako u binárních semafor ů zde nezáleží na obsahu, pouze na informaci, jestli je semafor prázdný či nikoliv. Nastavování a čtení čítacích semafor ů probíhá stejným zp ůsobem jako u semafor ů binárních [60]. Při vytvo ření čítacího semaforu jsou ur čeny dva jeho parametry. První je maximální po čet nastavení ( give ) semaforu, tj. v podstat ě jeho délka. Druhým parametrem je po čáte ční nastavení. Toto po čáte ční nastavení udává, kolikrát je možné semafor p řečíst (take ) bez toho, aby jej bylo nutno znovu nastavit. Typickým využitím čítacích semafor ů je po čítání zpracovaných událostí [70]. P ři příchodu události je čítací semafor nastaven, p ři jejím zpracování jinou úlohou je přečten. Obsah semaforu pak udává rozdíl po čtu událostí p řišlých a zpracovaných. Dalším uvedeným p říkladem použití p ři správ ě zdroj ů, které jsou po četn ě omezeny. Toto omezení je nastaveno p ři vytvo ření semaforu. Pokud úloha pot řebuje zdroj využít, přečte ( take ) semafor. Pokud je obsah semaforu vy čerpán, není již k dispozici žádný zdroj. Po skon čení práce se zdrojem daná úloha nastaví ( give ) semafor zp ět a zdroj lze znovu použít.

5.5.4 Mutexy

Mutexy lze použít k řešení vzájemného vylou čení ( mutual exclusion ) a obvykle slouží ke hlídání p řístupu k n ějakému zdroji. V podstat ě se jedná o binární semafory. Stejn ě jako u semafor ů lze op ět nastavit časový limit pro p řečtení mutexu. Úloha, která má využívat zdroj, musí mutex p řečíst ( take ). Tím získává právo využívat tento zdroj. Po použití úloha op ět mutex nastaví ( give ) a p řístup k hlídanému zdroji je možný [71]. Na rozdíl od binárních semafor ů využívají mutexy mechanizmus d ědění priorit. Tento mechanizmus má zajistit, aby úloha s vysokou prioritou byla blokována po co nejkratší dobu. Pokud je blokována úloha s vyšší prioritou, čekající na mutex, který byl již p řečten ( take ) jinou úlohou s prioritou nižší, je priorita této úlohy do časn ě zvýšena na hodnotu priority čekající úlohy. Tímto je podle [71] v některých p řípadech zajišt ěna minimalizace vzniku inverze priorit, avšak nedochází k úplnému odstran ění tohoto jevu. Podle [60] použití mutex ů zvyšuje celkovou komplexnost aplikace a pokud je to možné, je vhodné se jejich použití vyhnout. Zvláštním typem mutex ů jsou rekurzivní mutexy [72]. Tyto mutexy lze p řečíst (take ) n ěkolikrát. Pokud úloha p řečte n ěkolikrát rekuzivní mutex, je nutné, aby jej stejným po čtem nastavení vrátila do stavu, kdy je k dispozici k přečtení také ostatním úlohám.

46 5.5.5 Příznaky událostí

Novinkou uvedenou ve verzi FreeRTOS 8.0.0 jsou p říznaky událostí ( event flag ), pop ř. jejich skupiny ( event group ). Tyto p říznakové bity a skupiny pat ří k synchroniza čním prost ředk ům a lze je použít k indikaci p říchodu události nebo n ěkolika událostí. Více informací a odkazy na p říklady použití lze nalézt v [41].

5.6 Časování

K časovému spoušt ění funkcí lze využít softwarové časova če. P řed použitím musí být softwarový časova č nejprve vytvo řen. Po spušt ění m ěř í časova č nastavenou dobu a po jejím uplynutí je zavolána p říslušná funkce ( timer callback function ). Podle [73] nesmí taková funkce volat API funkce, které by zp ůsobily blokování (nap ř. pozastavení úlohy nebo nastavení nenulového časového limitu pro čtení z fronty). Vzhledem k tomu, že softwarové časova če jsou volitelnou sou částí systému, není jejich funkcionalita p římo sou částí jádra systému. Místo toho je realizována samostatn ě v obslužné úloze časova če ( timer service task, daemon task ). N ěkteré API funkce pro časova če, které jsou využívány v aplikaci, pak pro komunikaci s obslužnou úlohou časova če využívají standardní fronty ( timer command queue ). Tato fronta je využívána pouze systémem a nelze k ní p řistupovat p římo [74]. Obr. 5-4 ukazuje vztah aplikace, komunika ční fronty a obslužné úlohy časova če.

Obr. 5-4: Vzájemný vztah mezi aplikací a obsluhou softwarového časova če [74]

47 K dispozici jsou dva typy časova čů . Prvním typem je jednorázový časova č ( one-shot timer ), který po uplynutí nastaveného času spustí požadovanou funkci pouze jednou a dále již čas nem ěř í. M ůže být však restartován aplikací. Druhým typem časova če je automatický časova č ( auto-reload timer). Tento časova č je po uplynutí nastaveného času a spušt ění p říslušné funkce automaticky restartován. Tím lze dosáhnout periodického spoušt ění funkcí [75]. Časova č je možné za b ěhu resetovat. Pokud se tak stane, dochází k přepo čtu m ěř ené doby a m ěř ení času je tedy relativní k okamžiku, kdy došlo k resetu. V [76] je uveden příklad použití pro ovládání podsv ětlení LCD displeje, kdy je zapot řebí podsv ětlení vypnout 5 s po stisknutí posledního tla čítka.

5.7 Správa pam ěti

Při vytvá ření úloh, front, semafor ů atd. je t řeba vyhradit a p řid ělit t ěmto instancím pot řebnou pam ěť RAM. Použití standardních funkcí pro alokaci pam ěti ( malloc() , free() ) však obvykle není vhodné. Tyto funkce nejsou vždy v embedded systémech dostupné, jsou pam ěť ov ě náro čné a jsou nedeterministické, tj. čas pot řebný k jejich vykonání nemusí být vždy stejný [77]. Podobné nevýhody standardních funkcí jsou uvedeny také v [60], kde je navíc zmín ěno i nebezpe čí preempce p ři alokaci a dále fragmentace pam ěti. Z těchto d ůvod ů je t řeba spravovat pam ěť jinak. Opera ční systém FreeRTOS má správu pam ěti implementovanou ve vrstv ě HAL, tedy odd ělenou od jádra systému. Jádro pak pouze využívá nadefinované funkce bez ohledu na implementaci. Výhodou tohoto řešení je možnost využívat r ůzné implementace správy pam ěti (viz dále), pop ř. implementovat vlastní správu, která přesn ě vyhovuje konkrétní aplikaci. V sou časné dob ě jsou spolu se systémem FreeRTOS k dispozici čty ři r ůzné implementace správy pam ěti Tyto implementace definují aloka ční funkce, které jsou využívány jádrem systému a volány n ěkterými API funkcemi. Navzájem se liší zp ůsobem a možnostmi alokace a každá je ur čena pro jiný druh aplikací. Každá implementace se pak nachází v samostatném zdrojovém souboru.

Varianta 1 Tato implementace je nejjednodušší. Po čítá se pouze s jednorázovou alokací pam ěti, tj. alokovaná pam ěť nem ůže být uvoln ěna. V [77] je uvedeno, že v ětšina vestav ěných aplikací vytvá ří všechny pot řebné úlohy, fronty a synchroniza ční prost ředky p ři startu, ješt ě p řed spušt ěním vlastního opera čního systému, a pak je využívá po celou dobu své činnosti. Není tedy t řeba využívat uvol ňování pam ěti ani op ětovnou alokaci. V [77] je dále uvedeno, že tato implementace je vždy deterministická.

48 Implementace alokuje pole o konfigurovatelné velikosti, které p ředstavuje haldu (heap ) a p ři pot řeb ě alokovat pam ěť toto pole dále d ělí. Podle [60] je toto řešení velmi pam ěť ov ě náro čné. Tuto variantu správy pam ěti lze nalézt v souboru heap_1.c v adresá ři MemMang .

Varianta 2 Na rozdíl od p ředchozí varianty, tato umož ňuje také uvol ňování pam ěti. Uvoln ěná pam ěť však z ůstává v blocích, není možné spojit p řilehlé volné bloky do jednoho. V [77] je uvedeno, že tato varianta již není deterministická, avšak nabízí lepší efektivitu než standardní funkce. Implementace používá k alokaci algoritmus best fit , který vyhledává nejmenší volný blok, vyhovující svou velikostí požadavku alokace [78]. Příklad takové alokace je uveden v [60]. Vzhledem k uvedeným vlastnostem je tato implementace vhodná pro aplikace, které dynamicky alokují pam ěť , avšak velikost alokované pam ěti je vždy stejná. Jinak m ůže docházet k problém ům s fragmentací pam ěti. Pokud je nap ř. dynamicky alokována fronta, která má p ři každé alokaci jinou délku, vzniká ve volné pam ěti množství malých samostatných blok ů, které mohou znemožnit další alokaci [77]. Tuto variantu lze nalézt v souboru heap_2.c v adresá ři MemMang .

Varianta 3 Tato varianta se od p ředchozích výrazn ě liší. V podstat ě se nejedná o vlastní implementaci správy pam ěti, ale pouze o speciální využití standardních funkcí malloc() a free() . Implementace definuje jednoduchou funkci (tzv. wrapper ), která pouze vhodným zp ůsobem volá standardní funkce. Tato funkce zajistí bezpe čné provedení (tzv. thread safety ) alokace pam ěti. Toho je dosaženo pozastavením plánova če v dob ě alokace, pop ř. uvol ňování pam ěti [60]. Provedení této funkce lze nalézt ve zdrojovém souboru heap_3.c v adresá ři MemMang . Použití této implementace vyžaduje nastavení haldy pomocí linkeru (nastavení v konfigura čním souboru systému FreeRTOS nemá v tomto p řípad ě význam). Samoz řejmostí je nutnost podpory použitých standardních knihovních funkcí. V [77] i [60] je dále uvedeno, že tato varianta je také nedeterministická a p řináší s sebou podstatné zv ětšení velikosti jádra systému.

Varianta 4 Poslední implementace používá aloka ční algoritmus first fit . Tento algoritmus použije k alokaci první volný blok pam ěti, který svou velikostí spl ňuje požadavek [78]. Na rozdíl od druhé varianty ( heap_2.c ) zde dochází ke spojování p řilehlých volných blok ů pam ěti. Díky tomu je oproti druhé variant ě mnohem mén ě pravd ěpodobné, že pam ěť bude fragmentována i p ři náhodné alokaci [77]. Tato implementace je rovn ěž nedeterministická.

49 V [77] je dále uvedeno, že je tato varianta zvlášt ě vhodná pro aplikace, které pot řebují p římo volat aloka ční funkce (namísto nep římého volání s použitím API funkcí). Tato implementace byla p řidána do systému FreeRTOS verze 7.2.0 v roce 2012 [58] a není tedy uvedena v [60] (rok vytvo ření souboru 2009). Lze ji nalézt ve zdrojovém souboru heap_4.c v adresáři MemMang .

5.7.1 Podpora MPU

Systém FreeRTOS nabízí podporu jednotky pro správu a ochranu pam ěti (MPU) pro mikrokontroléry s jádrem ARM Cortex-M3. Jednotku MPU lze použít k ochran ě jádra systému a k ochran ě dat. Také je možné ji použít k ochran ě periferií a k detekci přete čení zásobník ů úloh [79]. Podpora jednotky MPU pro mikrokontroléry s jádrem ARM Cortex-M4/M4F není prozatím oficiáln ě oznámena.

5.8 Koprogramy

Krom ě klasických úloh ( task ) podporuje systém FreeRTOS také koprogramy (co-routines ), které jsou volitelnou sou částí systému. Lze je použít spole čně s úlohami, nebo i samostatn ě namísto úloh. Koprogramy jsou ur čeny pro použití na malých mikrokontrolérech, které disponují velmi malým množstvím pam ěti RAM [80]. Koprogramy jsou principiáln ě obdobné jako úlohy, avšak liší se v několika bodech. Všechny koprogramy v aplikaci využívají spole čný zásobník. To p řináší výrazné snížení spot řeby pam ěti RAM oproti použití úloh. P ři blokování koprogramu však hrozí ztráta dat, proto je t řeba prom ěnné, které mají být zachovány, deklarovat jako statické. Koprogramy jsou spoušt ěny v kooperativním módu a lze jim nastavit prioritu. Tato priorita je však respektována pouze v rámci koprogram ů. To znamená, že pokud jsou spoušt ěny spolu s úlohami, pak mají vždy vyšší prioritu úlohy. Více informací o koprogramech je možné nalézt v [81].

50 6 OPERA ČNÍ SYSTÉM CHIBIOS/RT

ChibiOS/RT je otev řený a voln ě ši řitelný opera ční systém reálného času, navržený pro embedded aplikace, které požadují výpo četní efektivitu a nízkou pam ěť ovou náro čnost. Mezi hlavní vlastnosti tohoto systému pat ří kompaktnost, dobrá p řenositelnost a vysoká rychlost. Podle [24] dosahuje systém ChibiOS/RT nejlepší doby p řepnutí kontextu ve své t říd ě díky optimalizaci architektury. V [82] je uvedeno, že s mikrokontrolérem z rodiny STM32F4, taktovaném na 168 MHz, a p ři použití překlada če GCC ve verzi 4.6.2 je možné dosáhnout doby p řepnutí kontextu 0,4 µs. Sou časn ě je uvedena velikost přeloženého jádra systému 6172 B. Opera ční systém ChibiOS/RT oficiáln ě podporuje n ěkolik procesorových architektur. Jejich po čet je výrazn ě menší než u d říve popsaného systému FreeRTOS, podle [83] je však hlavním cílem projektu poskytnout dobrou podporu pro n ěkolik populárních architektur namísto jakékoliv podpory pro co nejvíce architektur. Výsledkem toho je jednak podpora r ůzných vývojových desek (v četn ě STM32F4-Discovery) a inicializa čních procedur, a zejména možnost využít kompletní vrstvy abstrakce hardwaru (HAL), která nabízí ovlada če pro velké množství za řízení, nap ř. sériové rozhraní, A/D p řevodníky, sb ěrnice CAN I 2C a SPI, UART, USB atd. Systém lze díky tomu použít jako kompletní opera ční systém, bez nutnosti jakékoliv komunikace se samotnou hardwarovou částí. Samoz řejmostí je možnost využití pouze samotného jádra. Plánova č jádra ( scheduler ) je preemptivní, mezi synchroniza ční a komunika ční prost ředky pat ří semafory, mutexy, podmín ěné prom ěnné, synchronní a asynchronní zprávy, p říznaky událostí a fronty. Systém nabízí také softwarové časova če. V [84] jsou dále uvedeny n ěkteré vlastnosti systému ChibiOS/RT. Jednou z těchto vlastností je, že jádro systému využívá pouze statickou alokaci pam ěti, tj. alokace probíhá p ři překladu. Je možné využít i dynamickou alokaci, ta je však pouze jako volitelná vrstva nad staticky alokovaným jádrem. Další vlastností je, že jádro nevyužívá žádné tabulky a pole s pevnou velikostí. Díky tomu nedojde k přete čení. Systém nabízí jednoduché aplika ční rozhraní, API funkce mají pouze jeden ú čel a neobsahují testování parametr ů. Tím nedochází ke zpomalování provád ění t ěchto funkcí. Testování parametr ů však m ůže být aktivováno p ři lad ění. Podle [84] jsou API funkce vytvo řeny tak, aby p ři p ředání správných parametr ů nikdy nedošlo k selhání. Výjimkou jsou volitelné funkce dynamické alokace, které mohou nahlásit nedostatek pam ěti. Lze využít také podpory externích knihoven pro práci se souborovým systémem a sí ťovou komunikací. Tyto knihovny jsou sou částí distribuce systému. Dále je možné využít grafickou knihovnu µGFX (www.ugfx.org), která byla p ůvodn ě ur čena pouze pro tento systém.

51 Hlavním vývojá řem opera čního systému ChibiOS/RT je Giovanni Di Sirio, který je také vedoucím projektu. Samotný systém ChibiOS/RT je vyvíjen od roku 2007, avšak je založen na systému, který vznikl kolem roku 1992 [85], [86]. Systém ChibiOS/RT je ve své stabilní verzi ší řen pod licencí GNU GPL3 s výjimkou. Tato výjimka, podobn ě jako u systému FreeRTOS, povoluje za ur čitých podmínek použití v aplikacích, které obsahují také uzav řený kód. Dále je možné získat i n ěkolik komer čních licencí. Více informací lze nalézt v [87].

6.1 Podporované architektury a nástroje

Jak bylo výše uvedeno, opera ční systém ChibiOS/RT podporuje pom ěrn ě malé množství procesorových architektur a jeho vývoj je sm ěř ován p ředevším k dobré podpo ře t ěchto vybraných architektur. Seznam oficiáln ě podporovaných rodin mikrokontrolér ů a p řeklada čů je uveden v Tab. 6-1, p řevzaté z [83]. Z této tabulky je patrné, že rozsah podporovaných mikrokontrolér ů je výrazn ě menší než u d říve popsaného systému FreeRTOS. V současné dob ě je podporováno celkem osm r ůzných architektur. V tabulce lze nalézt také rodinu STM32F4 výrobce ST Microelectronics, založenou na jádru ARM Cortex-M4. Pro tuto rodinu podporovány p řeklada če GCC, IAR a RVCT. Sou částí distribuce je také demonstra ční aplikace pro mikrokontrolér STM32F407 a vývojovou desku STM32F4 Discovery).

Tab. 6-1: Architektury podporované opera čním systémem ChibiOS/RT [83] architektura překlada č podporované rodiny mikrokontrolér ů ARM Cortex-M0 GCC LPC11, LPC11U, STM32F0 ARM Cortex-M0 RVCT LPC11, LPC11U, STM32F0 ARM Cortex-M3 GCC LPC13, STM32F1, STM32F2, STM32L1 ARM Cortex-M3 IAR LPC13, STM32F1, STM32F2, STM32L1 ARM Cortex-M3 RVCT LPC13, STM32F1, STM32F2, STM32L1 ARM Cortex-M4 GCC STM32F3, STM32F4 ARM Cortex-M4 IAR STM32F3, STM32F4 ARM Cortex-M4 RVCT STM32F3, STM32F4 ARM7 GCC AT91SAM7, LPC214 ATmega128, AT90CAN128, MegaAVR GCC ATmega328p, ATmega1280 MSP430 GCC MSP430F1611 Power Architecture GCC/HighTec SPC56 e200z STM8 Cosmic STM8L, STM8S STM8 Raisonance STM8L, STM8S

52 V [88] lze nalézt dv ě p řehledné tabulky, které ukazují podporované subsystémy jádra pro jednotlivé architektury a dále podporu subsystém ů vrstvy HAL pro r ůzné rodiny mikrokontrolér ů. Také je zde uveden simulátor pro architekturu x86.

6.2 Architektura systému

Opera ční systém ChibiOS/RT je velmi modulární a je rozd ělen do n ěkolika nezávislých sou částí. Tyto sou části jsou dále d ěleny na subsystémy. Hlavní části systému jsou popsány dále. Mimo tyto části jsou také nabízeny n ěkteré další funkce [89]. Na Obr. 6-1 jsou znázorn ěny vztahy mezi jednotlivými sou částmi systému.

Obr. 6-1: Vztahy jednotlivých sou částí opera čního systému ChibiOS/RT [89]

Jádro systému ( Kernel ) Základní část systému, nezávislá na použité platform ě. Spolu s vrstvou port layer tvo ří samostatn ě funk ční celek, schopný funkce nezávisle na ostatních částech systému.

53 Samotné jádro je taktéž modulární a je rozd ěleno na n ěkolik subsystém ů. V ětšina z těchto subsystém ů je volitelná a jejich použití není nutné. Vazby mezi subsystémy jádra jsou znázorn ěny na Obr. 6-2. Základními a povinnými subsystémy jsou inicializace a nízkoúrov ňová správa systému ( System ), plánova č ( Scheduler ), správa úloh ( Threads ) a časování ( Timers ). Jejich popis lze nalézt v [90]. Mimo tyto povinné subsystémy je zde uvedena také skupina subsystém ů pro synchronizaci (synchroniza ční mechanismy jsou popsány podrobn ěji v části 6.6) a vrstva port layer (viz dále). Sou částí jádra systému je pak také správa pam ěti ( část 6.7) a dále vstupn ě/výstupní mechanismy (více také v [91]) a prost ředky pro lad ění [92], [93].

Obr. 6-2: Vztahy mezi subsystémy jádra systému ChibiOS/RT [89]

Vrstva port layer Tato vrstva pat ří k hlavním sou částem systému. Je závislá na dané architektu ře, resp. kombinaci architektury a použitého p řeklada če. Port vrstva definuje inicializa ční procedury systému, abstrakci vektor ů p řerušení, zámky systému, p řepínání kontextu. Díky tomu se jedná o velmi kritickou část opera čního systému, jejíž implementace může mít velký vliv na celkový výkon systému.

Platformní vrstva ( Platform layer ) Platformní vrstva obsahuje implementaci nízkoúrov ňových ovlada čů a obvykle odpovídá jednotlivým podporovaným rodinám mikrokontrolér ů.

Inicializace vývojové desky Systém také p římo podporuje r ůzné typy vývojových desek pro podporované mikrokontroléry. Tato část je pak využita k inicializaci desky a definici n ěkterých vstupn ě/výstupních vývod ů použitého mikrokontroléru, nap ř. p řipojených LED diod.

Vrstva abstrakce hardwaru (HAL) Tato vrstva obsahuje ovlada če b ěžných i mén ě b ěžných za řízení, v ětšinou komunika čních. Nabízí spole čné aplika ční rozhraní, které je nezávislé na použité platform ě a překlada či. Vrstva HAL využívá platformní vrstvu, která, jak bylo uvedeno, poskytuje nízkoúrov ňové implementace ovlada čů hardwaru. Systém ChibiOS/RT obsahuje dva

54 typy ovlada čů za řízení. Tyto ovlada če jsou rozlišeny podle toho, zda komunikují p římo s hardwarem, či nikoliv. Prvním typem je b ěžný ovlada č za řízení ( Normal Device Driver ). Tento ovlada č je rozd ělen na část vysokoúrov ňovou ( high level driver , HLD ), která komunikuje s aplikací, a část nízkoúrov ňovou ( low level driver , LLD ), která zprost ředkovává p řístup ke konkrétnímu hardwaru. Vysokoúrov ňová část definuje API funkce a části ovlada če, které jsou nezávislé na platform ě. Nízkoúrov ňová část ovlada če je pak implementována v platformní vrstv ě. Struktura b ěžného ovlada če je na Obr. 6-3. P říkladem b ěžného ovlada če m ůže být ovlada č pro komunika ční za řízení SPI.

Obr. 6-3: Struktura b ěžného ovladače za řízení [89]

Druhým typem ovlada če je komplexní ovlada č za řízení ( Complex Device Driver ). Tento typ ovlada če nekomunikuje p římo s hardwarem, ale pouze definuje vysokoúrov ňové funkce pro práci se za řízením. Pro p řístup k hardwaru pak využívá ostatních ovlada čů a to bu ď b ěžných nebo komplexních. Jako p říklad komplexního ovlada če lze uvést ovlada č komunikace pro pam ěť ové karty MMC/SD, který využívá běžný ovlada č rozhraní SPI [89]. Více informací o vrstv ě HAL a jednotlivých poskytovaných ovlada čích za řízení lze nalézt v [94].

6.3 Struktura zdrojových soubor ů

Distribuce opera čního systému ChibiOS/RT obsahuje zdrojové soubory jádra systému, částí specifických pro danou architekturu, vrstvy HAL a dalších volitelných sou částí. Další sou částí distribuce je dokumentace, množství demonstra čních a testovacích aplikací a také externí knihovny pro sí ťové rozhraní a souborový systém. Zdrojové soubory opera čního systému ChibiOS/RT je možné získat n ěkolika zp ůsoby [95]. Nejjednodušším zp ůsobem je stažení zip archivu. Stabilní verze systému vždy obsahuje sudé číslo v ozna čení verze, nap ř. 2.6.3, která je aktuální v dob ě psaní této práce. Ve staženém adresá ři ChibiOS_2.6.3 lze nalézt textové soubory s popisem distribuce a historií a také licen ční podmínky. Dále obsahuje n ěkolik podadresá řů . Jsou to podadresá ře boards , kde jsou umíst ěny konfigura ční a zdrojové soubory pro r ůzné vývojové desky, demos , obsahující demonstra ční aplikace, docs , obsahující soubory dokumentace, ext , kde lze nalézt externí knihovny, os , který obsahuje zdrojové soubory jádra a dalších sou částí systému, test , kde se nachází testovací aplikace pro systém a testhal , obsahující aplikace pro testování vrstvy HAL.

55 Následuje popis struktury adresá ře os , který je nejd ůležit ější. Tento adresá ř obsahuje čty ři podadresá ře. V podadresá ři kernel jsou umíst ěny zdrojové a hlavi čkové soubory jádra systému. Podadresá ř ports obsahuje zdrojové soubory pro jednotlivé podporované architektury. Podobn ě jako u systému FreeRTOS je nejprve provedeno rozd ělení do podadresá řů podle p řeklada če a následn ě podle architektury. V podadresá ři hal jsou umíst ěny zdrojové soubory a dokumentace vrstvy HAL. Poslední podadresá ř various obsahuje n ěkteré další funkce a knihovny, které nejsou p římo sou částí systému [96].

Konfigurace systému je provedena pomocí konfigura čních hlavi čkových soubor ů. Ty jsou rozd ěleny podle částí systému. Základním konfigura čním souborem, který je vyžadován jádrem systému, je chconf.h , který lze nalézt v adresá ři ChibiOS_2.6.3/os/kernel/templates a také v adresá ři každé demonstra ční aplikace. Zde lze konfigurovat základní parametry systému jako je frekvence systémových hodin, velikost p řid ělené pam ěti RAM, optimalizace rychlosti. Dále povolování všech volitelných částí systému, nap ř. jednotlivých synchroniza čních mechanism ů a také nastavení ladicích prost ředk ů [97]. Pro využití vrstvy HAL je dále t řeba použít další konfigura ční soubor halconf.h , který je umíst ěn v adresá ři ChibiOS_2.6.3/os/hal/templates . Obsahuje vysokoúrov ňová nastavení jednotlivých ovlada čů za řízení v četn ě možnosti volby, které ovlada če mají být použity. Nízkoúrov ňová nastavení, závislá na použité platform ě se nachází v konfigura čním souboru mcuconf.h . Tento soubor lze nalézt v adresá ři demonstra čních aplikací, vždy pro konkrétní typ mikrokontroléru [98].

6.4 Správa úloh

V dokumentaci k opera čnímu systému ChibiOS/RT je místo výrazu úloha ( task ) používán výraz vlákno ( thread ). Vzhledem k tomu, že v tomto p řípad ě jde v podstat ě pouze o v ěc používání názvosloví a nikoli rozdílu ve funkci, lze oba tyto názvy považovat za ekvivalentní. Opera ční systém ChibiOS/RT nabízí dva typy úloh. Jsou to úlohy statické a dynamické. Výchozím typem jsou statické úlohy, které vyžadují staticky alokovanou oblast pam ěti. Pam ěť pro dynamické úlohy m ůže být alokována dv ěma zp ůsoby a to bu ď v hald ě ( heap ), nebo po blocích o pevné velikosti ( memory pool ). Mechanismy správy pam ěti jsou stru čně popsány v části 6.7. Více informací o možnostech vytvá ření úloh lze nalézt v [99] a [100]. Každá úloha v systému ChibiOS/RT je p ředstavována strukturou Thread Structure , která obsahuje informace pot řebné ke správ ě úloh. V Tab. 6-2 je uvedena její podoba. Tato struktura je definována v hlavi čkovém souboru chthreads.h , který lze nalézt v adresáři ChibiOS_2.6.3/os/kernel/include . Data uvedená v Tab. 6-2 byla p řevzata

56 přímo z tohoto souboru. Podobn ě jako v systému FreeRTOS je v ětšina t ěchto položek definována podmín ěně v závislosti na konfiguraci systému.

Tab. 6-2: Struktura reprezentující úlohu v systému ChibiOS/RT název prom ěnné význam p_next ukazatel další úlohy v seznamu/front ě p_prev ukazatel p ředcházející úlohy v seznamu/front ě p_prio priorita úlohy p_ctx struktura představující kontext p_newer ukazatel nov ější úlohy v registru p_older ukazatel starší úlohy v registru p_name název úlohy p_stklimit ukazatel konce zásobníku p_state aktuální stav úlohy p_flags různé p říznaky úlohy p_refs odkazy na danou úlohu p_preempt čas, který zbývá úloze do preempce (Round-Robin) p_time čas spot řebovaný úlohou rdymsg kód p ředaný p ři p řechodu do stavu P řipravená 4 exitcode ukon čovací kód 5 wtobjp ukazatel na synchroniza ční objekt, na který úloha čeká ewmask maska povolených událostí p_waiting seznam čekajících úloh p_msgqueue fronta pro zprávy p_msg zpráva p_epending maska čekajících událostí p_mtxlist seznam mutex ů, držených danou úlohou p_realprio vlastní priorita úlohy, nezd ěděná p_mpool memory pool, kde se nachází pracovní oblast úlohy THREAD_EXT_FIELDS další položky 6

Popsaná struktura p ředstavuje obdobu TCB, popsaného v kapitole 5 pro systém FreeRTOS. Každé úloze náleží mimo tuto strukturu také vlastní zásobník a n ěkolik dalších oblastí, ur čených k přepínání kontextu a obsluze p řerušení. Vše je alokováno do

4 Zpráva, která je poslána úloze p ři jejím zavolání z jiné úlohy nebo obslužné rutiny p řerušení. 5 Kód, který je proveden p ři ukon čení/pozastavení úlohy jinou úlohou. 6 Tyto položky nejsou obvykle p řítomné, lze je libovoln ě definovat uživatelsky v konfigura čním souboru chconf.h (viz část 6.3).

57 oblasti pam ěti nazvané Thread Working Area nebo Workspace , což lze p řeložit jako pracovní oblast úlohy/vlákna. Pracovní oblast je soukromá pro každou úlohu a daná úloha obvykle nevyužívá pam ěť mimo tuto oblast. Výjimkou je p řístup ke sdíleným dat ům [101]. Na Obr. 6-4 je znázorn ěna pracovní oblast úlohy.

Obr. 6-4: Pracovní oblast úlohy [101]

Obr. 6-5: P řechodový diagram stav ů úloh v systému ChibiOS/RT [101]

58 V [101] je uveden p řechodový diagram stav ů úlohy. Tento diagram je na Obr. 6-5. Z diagramu lze vy číst, že úloha m ůže nabývat p ěti stav ů. T ěmito stavy jsou

Běžící ( Running ) Připravená ( Ready ) Čekající/Spící ( Sleeping ) Pozastavená ( Suspended ) Zastavená ( Stop )

V [90] lze nalézt podstatn ě v ětší množství stav ů, které p ředstavují čekání na r ůzné synchroniza ční mechanismy, nap ř. semafory, fronty a události.

6.5 Plánování a priority

Plánova č opera čního systému ChibiOS/RT je preemptivní. Strategie plánování je založena na prioritách, tj. vždy je spušt ěna úloha, která má nejvyšší prioritu a sou časn ě se nachází ve stavu P řipravená. Pro tento ú čel systém definuje seznam p řipravených úloh jako obousm ěrný seznam, který obsahuje úlohy řazené podle priority [101]. Na Obr. 6-6 je znázorn ěno propojení mezi jednotlivými položkami tohoto seznamu. Každá položka obsahuje ukazatel na další a také na p ředcházející položku s tím, že poslední položka seznamu (úloha s nejvyšší prioritou, pop ř. jedna z těchto úloh) ukazuje zp ět na za čátek seznamu. Úlohy, které jsou do tohoto seznamu přidávány, jsou vždy za řazeny až za úlohy s vyšší nebo stejnou prioritou. Jak je na Obr. 6-6 dále znázorn ěno, aktuáln ě b ěžící úloha se v seznamu p řipravených úloh nenachází, k odkazování na tuto úlohu slouží systémový ukazatel s názvem currp .

Obr. 6-6: Seznam p řipravených úloh [101]

59 Po inicializaci systému jsou automaticky vytvo řeny dv ě úlohy. První je prázdná úloha ( Idle thread ). Tato úloha má nejnižší prioritu a b ěží pouze, pokud není provád ěna žádná jiná úloha. Druhou vytvo řenou úlohou je hlavní úloha ( Main thread ). Tato úloha provádí kód funkce main() a obvykle vytvá ří ostatní úlohy [99]. Systém ChibiOS/RT dovoluje použití 128 úrovní priority s tím, že stejné priority může nabývat více úloh [101]. Pokud má více úloh stejnou prioritu, je pro jejich spoušt ění použit plánovací algoritmus Round-Robin, podobn ě jako u systému FreeRTOS. Tento algoritmus byl již popsán v části 5.4. Na rozdíl od systému FreeRTOS, kde je časové kvantum pevn ě dáno, lze v systému ChibiOS/RT tuto dobu nastavit libovoln ě v násobcích periody systémových hodin. Pokud je časové kvantum nastaveno jako nulové, dojde k zákazu časového p řepínání a úlohy jsou spoušt ěny v kooperativním režimu. To však platí pouze pro úlohy se stejnou prioritou a úlohy s vyšší prioritou jsou i dále spoušt ěny preemptivn ě [97]. V [102] je uvedeno, že obslužné rutiny p řerušení je vhodné považovat za speciální úlohy, jejichž priorita bude nastavena nad oblastí priorit, ur čených pro b ěžné úlohy. Toto je obzvlášt ě vhodné p ři použití v architekturách, které umož ňují preempci obslužných rutin p řerušení (nap ř. architektura ARM Cortex-M).

6.6 Synchronizace a komunikace

Jak bylo uvedeno, systém ChibiOS/RT pro synchronizaci úloh a komunikaci nabízí pom ěrn ě velké množství prost ředk ů. Krom ě základních prost ředk ů jako jsou semafory nebo fronty lze využít také synchronních a asynchronních zpráv a podmín ěných prom ěnných. Synchroniza ční mechanismy s výjimkou binárních semafor ů, asynchronních zpráv a podmín ěných prom ěnných využívají pouze API funkcí plánova če. Schematické znázorn ění vazeb mezi synchroniza čními prost ředky a plánova čem jádra je na Obr. 6-7.

Obr. 6-7: Vztahy mezi synchroniza čními prost ředky [89]

60 6.6.1 Čítací semafory

Tento synchroniza ční prost ředek m ůže nabývat libovolného množství stav ů. Základem čítacího semaforu je číta č, tj. prom ěnná, která v podstat ě ur čuje stav semaforu. Tato prom ěnná m ůže nabývat také záporných hodnot. V případ ě, že je hodnota záporná, udává stav číta če po čet úloh, čekajících na semafor. Pro čítací semafory jsou definovány dv ě operace. První operací je čekání ( wait ). Prakticky jde obdobu operace take , která byla popsána v části 5.5.2. P ři provedení operace čekání je dekrementována hodnota číta če. Pokud je po dekrementaci hodnota záporná, je obsluhovaná úloha za řazena do čekací fronty. Druhou operací je signál (signal ). Op ět se jedná o obdobu operace give u semafor ů v systému FreeRTOS. Operace signál inkrementuje číta č semaforu. Pokud je výsledkem nezáporná hodnota, je volající úloha odstran ěna z čekací fronty. Na Obr. 6-8 je p řechodový diagram stav ů čítacího semaforu. Uvedené operace mohou být provád ěny libovolnou úlohou, semafory nejsou na rozdíl od mutex ů vlastn ěny žádnou úlohou. Jsou definována i makra pro rychlou zm ěnu nebo zjišt ění stavu semaforu [103]. Čítací semafor lze vytvo řit s libovolnou nezápornou po čáte ční hodnotou. P ři operacích se semafory lze využít časové limity. Nastavením časového limitu je možné zajistit ur čitou dobu čekání úlohy na semafor. Pokud není b ěhem této doby semafor k dispozici, dochází k odstran ění úlohy z čekací fronty a je obnoveno její vykonávání. Také je možné semafor resetovat, čímž dojde k vyprázdn ění fronty čekajících úloh. Další funkcí je p ředávání zpráv p ři provád ění operace čekání. Tato zpráva nese informaci, zda operace prob ěhla normálním zp ůsobem nebo b ěhem čekání nastala nějaká událost, nap ř. vypršel nastavený časový limit [104].

Obr. 6-8: P řechodový diagram stav ů čítacího semaforu [104]

V [104] je dále uveden p říklad použití čítacího semaforu p ři hlídání zdroj ů. Také je zde uvedena poznámka, že pomocí mechanismu čítacích semafor ů jsou implementovány vstupn ě/výstupní fronty.

6.6.2 Binární semafory

Binární semafory využívají funkcionalitu čítacích semafor ů a jsou implementovány v podob ě maker, která využívají funkce definované pro čítací semafory. Obsah číta če binárního semaforu nem ůže p řekro čit hodnotu 1. Binární semafor má tedy pouze dva stavy, které ur čují, zda je tento semafor k dispozici, či nikoliv. Hodnota číta če m ůže být záporná a v tomto p řípad ě op ět udává po čet úloh čekajících na semafor. Pokud je

61 hodnota číta če záporná nebo nulová, semafor není k dispozici (stav taken ), pokud je rovna jedné, je semafor k dispozici (stav not taken ) [105]. Podobn ě jako pro čítací semafory, jsou i pro binární semafory definovány dv ě operace. První operací je přečtení semaforu ( take ). Tato operace p řevádí semafor do stavu taken . Pokud je již v tomto stavu, je volající úloha za řazena do seznamu čekajících. Druhou operací je uvoln ění ( release ). Tato operace má za následek p řechod semaforu do stavu, kdy je k dispozici ( not taken ), pop ř. odstran ění volající úlohy z čekací fronty. Pokud je operace uvoln ění provedena na semaforu, který již byl uvoln ěn (je k dispozici, tj. ve stavu not taken ), nemá tato operace žádný efekt. Stejn ě jako u čítacích semafor ů m ůže s binárními semafory pracovat kterákoli úloha nebo obslužná rutina p řerušení. Binární semafory mohou být vytvo řeny s libovolným po čáte čním stavem a lze využít časové limity a reset stejn ě jako u čítacích semafor ů. Taktéž jsou k dispozici zprávy o stavu operace čekání [104]. Na Obr. 6-9 je p řechodový diagram stav ů binárního semaforu.

Obr. 6-9: P řechodový diagram stav ů binárního semaforu [104]

6.6.3 Mutexy

Mezi synchroniza ční prost ředky pat ří také mutexy, které již byly popsány v části 5.5.4. Na rozdíl od semafor ů mají mutexy vlastníka. Tak jako binární semafory, mohou mutexy nabývat dvou stav ů. Tyto stavy ur čují, zda je mutex vlastn ěný ( owned ), či volný (not owned ). Úlohy mohou s mutexy provád ět dva druhy operací. První operací je uzamknutí ( lock ). Úloha, která tuto operaci provede, získává vlastnictví, pop ř., pokud je mutex již vlastn ěn jinou úlohou, je volající úloha p řesunuta do fronty čekajících úloh. Druhou operací je odemknutí mutexu ( unlock ). Tuto operaci m ůže provést pouze úloha, která vlastní mutex. Pokud je v čekací front ě nejaká úloha, je tato z fronty odstran ěna a je jí p ředáno vlastnictví mutexu [104]. Na Obr. 6-10 je p řechodový diagram stav ů mutexu.

62 Obr. 6-10: P řechodový diagram stav ů mutexu [104]

Podle [106] má funkcionalita mutex ů v systému ChibiOS/RT implementovanou plnou podporu d ědění priorit k minimalizaci problému inverze priorit. P ři za řazení úlohy do fronty úloh, čekajících na mutex, je úloze, která mutex vlastní zvýšena priorita na hodnotu, kterou má úloha čekající. Samoz řejm ě to platí pouze v případ ě, že čekající úloha má vyšší prioritu než úloha, která vlastní mutex. Pokud má prioritu nižší nebo stejnou, priorita úlohy, vlastnící mutex, se nem ění. Tento mechanismus pracuje s libovolným množstvím mutex ů a úloh. V [104] je dále uvedeno n ěkolik poznámek k používání mutex ů v systému ChibiOS/RT. Je zde uvedeno, že operace odemknutí ( unlock ) nep řijímá žádné parametry a p ři volání této operace systém vždy odemkne poslední mutex, který daná úloha vlastní. Pro tyto ú čely je pro každou úlohu spravován seznam vlastn ěných mutex ů (viz Tab. 6-2). Navíc je definována operace pro odemknutí všech mutex ů, vlastn ěných úlohou ( unlock all ). Další p řídavnou operací je pokusné uzamknutí mutexu ( try lock ), kdy p ři neúsp ěšném pokusu o uzamknutí (získání vlastnictví) mutexu nedochází k čekání.

6.6.4 Podmín ěné prom ěnné

Podmín ěné prom ěnné v systému ChibiOS/RT jsou implementovány jako rozší ření funkcionality mutex ů a nemohou být použity samostatn ě. Použitím mutex ů a podmín ěných prom ěnných lze implementovat synchroniza ční prost ředek, zvaný monitor [107]. Podmín ěná prom ěnná slouží k signalizaci spln ění n ějaké podmínky a neobsahuje tedy žádnou hodnotu. Podmín ěná prom ěnná je p ředstavována frontou úloh, čekajících na tuto prom ěnnou, tj. čekajících na spln ění ur čité podmínky [108]. Úloha, čekající na spln ění podmínky je zablokována, p řidána do čekací fronty podmín ěné prom ěnné a mutex, aktuáln ě vlastn ěný touto úlohou, je odemknut. Po spln ění podmínky je mutex op ět uzamknut a čekající úloha je odblokována.

63 6.6.5 Příznaky událostí

Správa událostí je d ůležitou sou částí opera čního systému ChibiOS/RT. V ětšina nízkoúrov ňových ovlada čů generuje události pro signalizaci stavu aplikaci. Události jsou generovány asynchronn ě. Systém ChibiOS/RT implementuje správu událostí specifickým zp ůsobem a definuje dva objekty pro práci s událostmi. Prvním objektem je zdroj událostí ( Event Source ). Jedná se o systémový objekt, který slouží k upozornění na událost. Pokud událost nastane, m ůže úloha nebo obslužná rutina přerušení vyslat ( broadcast ) pomocí zdroje události informaci o p říchodu této události všem registrovaným úlohám. V systému může existovat neomezené množství zdroj ů událostí [109]. Dalším objektem je sledova č událostí ( Event Listener ). Tento objekt slouží k propojení úloh se zdroji událostí. Každá úloha m ůže sledovat neomezené množství těchto zdroj ů. Proces p řiřazení úlohy ke zdroji událostí pomocí sledova če událostí se nazývá registrace ( registration ) [110]. Každý sledova č událostí má vlastní masku, která je logicky p řičtena k masce p říslušné úlohy. To znamená, že každé úloze lze nezávisle definovat identifikátory událostí. Je možné, aby úloha čekala na jednu nebo více událostí a dále je možné nastavit logické podmínky pro toto čekání.

6.6.6 Zprávy

Opera ční systém ChibiOS/RT nabízí dva druhy p řenosu zpráv mezi úlohami. Prvním je synchronní p řenos, kdy daná úloha vysílá zprávu ur čenou pro jinou konkrétní úlohu, druhým je asynchronní p řenos, pomocí kterého m ůže mezi sebou komunikovat více úloh p řes frontu zpráv.

Synchronní zprávy (synchronous messages ) poskytují jednoduchý a rychlý mechanismus pro komunikaci mezi úlohami. Tento mechanismus dovoluje p řenos zpráv dv ěma sm ěry. Velké rychlosti je dosaženo tím, že mezi úlohami nejsou kopírována samotná data, ale pouze dojde k přenosu ukazatele na tato data. Zprávy jsou obvykle zpracovávány v po řadí podle p říchodu (FIFO), je však možné je zpracovávat také podle priorit. Vykonávání úlohy, čekající na zprávu je pozastaveno až do p říchodu této zprávy. Úloha, která zprávu vyšle, je taktéž zastavena, dokud nedostane od p řijímající úlohy oznámení o p řijetí. Více informací o synchronních zprávách lze nalézt v [111].

Mechanismus asynchronních zpráv využívá jednosm ěrnou frontu zpráv a objekt mailbox . Tento objekt obsahuje odkaz na frontu a také semafory, jejichž funkcionalita je využita k signalizaci míry zapln ění fronty. Pokud je fronta plná, úloha, která vysílá zprávu, čeká, dokud není místo uvoln ěno, pop ř. dokud nevyprší nastavený časový limit [112]. Na rozdíl od synchronních zpráv ne čeká úloha, odesílající zprávu, na odpov ěď přijímající úlohy.

64 6.6.7 Fronty

Fronty jsou v systému ChibiOS/RT využívány v ětšinou v ovlada čích za řízení, využívajících sériovou komunikaci. Ovlada če jsou obvykle rozd ěleny na dv ě části. Fronty mohou být vstupní ( Input queue ), kdy nízkoúrov ňová část ovlada če do fronty zapisuje a vysokoúrov ňová část čte, nebo výstupní ( Output queue ), kdy do fronty zapisuje vysokoúrov ňová část a nízkoúrov ňová část z fronty čte. Pokud je zkombinována vstupní a výstupní fronta, vzniká obousm ěrná fronta ( Full duplex queue ) [113].

6.7 Správa pam ěti

Jak bylo uvedeno jádro systému ChibiOS/RT využívá statickou alokaci pam ěti. Díky tomu se lze obejít bez správy pam ěti, pokud to aplikace dovoluje. Správa pam ěti je však dostupná v podob ě volitelných sou částí systému. Opera ční systém ChibiOS/RT nabízí t ři r ůzné možnosti alokace pam ěti, které budou popsány dále. Také je možné využít standardních funkcí pro alokaci. V [114] lze nalézt přehlednou srovnávací tabulku pro r ůzné možnosti správy pam ěti. Na Obr. 6-11 jsou pak znázorn ěny vazby mezi jednotlivými mechanismy. V obrázku jsou také znázorn ěny dynamické úlohy ( Dynamic Threads ), které využívají zde popisovaných aloka čních prost ředk ů (viz část 6.4). Následuje stru čný popis aloka čních mechanism ů poskytovaných systémem ChibiOS/RT.

Hlavní alokátor pam ěti ( Core memory manager , Core allocator ) Tato sou část pracuje jako hlavní správce pam ěti. Její funkcionalitu využívají ostatní mechanismy správy pam ěti. Tím je zajišt ěna konzistentnost operací nad pam ětí a je možné, aby sou časn ě pracovalo více aloka čních mechanism ů. Jedná se o jednoduchý aloka ční mechanismus, který umož ňuje pouze alokaci blok ů pam ěti bez možnosti jejich uvoln ění. Mechanismus je deterministický a bezpe čný, lze jej použít také v obslužných rutinách p řerušení a v [114] je jeho použití obecn ě doporu čeno, pokud je aplikací vyžadována dynamická alokace bez požadavku na uvol ňování paměti. Tento alokátor také poskytuje bloky pam ěti pro další aloka ční mechanismy [115].

Alokace v hald ě ( Heap allocator ) Aloka ční mechanismus pro dynamickou alokaci v hald ě v četn ě možnosti uvol ňovat pam ěť . K alokaci je použit algoritmus first fit , který byl stru čně popsán v části 6.6.4. Další informace o algoritmu first fit lze nalézt v [78]. Mechanismus již není

65 deterministický a p řináší nebezpe čí fragmentace pam ěti. Také jej nelze použít v obslužných rutinách p řerušení [114]. Funkce definované pro tento mechanismus jsou ekvivalentní k standardním funkcím malloc() a free() . Hlavním rozdílem oproti standardním funkcím je zajišt ění bezpe čného volání ( thread safety ). Je také možné využít API funkce tohoto alokátoru pouze jako wrapper funkce pro standardní aloka ční funkce [116].

Alokace po blocích ( Memory pools ) Tento mechanismus nabízí alokaci i uvol ňování blok ů pam ěti s pevnou velikostí. Jeho výhodou je p ředevším konstantní čas alokace (determinismus) a také absence problém ů s fragmentací pam ěti a vysoká rychlost [117]. Lze jej použít i v obslužných rutinách p řerušení a lze také definovat více takových blok ů [114].

Obr. 6-11: Správa pam ěti v systému ChibiOS/RT [89]

66 7 MOŽNOSTI IMPLEMENTACE PSD REGULÁTOR Ů S VYUŽITÍM OS REÁLNÉHO ČASU

Tato kapitola je v ěnována stru čnému obecnému popisu číslicového PSD regulátoru z teoretického i praktického hlediska a možnostem implementace jediného PSD regulátoru a také n ěkolika takových regulátor ů p ři použití opera čního systému reálného času.

7.1 PSD regulátor

Proporcionáln ě-suma čně-diferen ční regulátor je číslicovou obdobou spojitého PID regulátoru. Čím kratší je vzorkovací perioda, tím více se výstup diskrétního PSD regulátoru blíží výstupu spojitého regulátoru PID. Proto musí být vzorkovací perioda pom ěrn ě krátká. Samoz řejmostí je spln ění vzorkovacího teorému. Ideální spojitý PID regulátor lze popsat následující rovnicí [119].

 t ( ) ()()=  + 1 ()τ τ + de t  tu K te ∫ e d TD  (7-1)  TI 0 dt  kde (tu ) je ak ční zásah (výstup) regulátoru, K je zesílení regulátoru,

TI je integra ční časová konstanta,

TD je deriva ční časová konstanta, (te ) = (tw )− (ty ) je regula ční odchylka, tj. rozdíl mezi žádanou hodnotou a výstupem soustavy. PSD regulátor zpracovává informace v diskrétních časových okamžicích t = kT , kde k = ,2,1,0 K a T je perioda vzorkování. Pro diskrétní PSD regulátor je integra ční složka nahrazena sumací. Pro náhradu integrace lze použít zp ětnou obdélníkovou, dop řednou obdélníkovou nebo lichob ěžníkovou náhradu. Nejb ěžn ější náhradou je zp ětná obdélníková metoda. Deriva ční složka je nahrazena zp ětnou diferencí [118].

67 PSD regulátor lze pak popsat následující rovnicí [118].

 T k T  ()()kTu = K kTe + ∑ ()iTe + D ()()()kTe − e[]k −1 T  (7-2)  TI i=1 T  Tento tvar se nazývá polohový pop ř. paralelní [119]. Jeho nevýhodou je podle [118] nutnost uchovávat v pam ěti všechny hodnoty (iTe ), i = ,2,1 K,k pro výpo čet suma ční části. Zmín ěnou nevýhodu odstra ňuje p řír ůstkový tvar regulátoru. Tento tvar je rekurentní a ur čuje se pouze p řír ůstek ak ční veli činy k její p ředchozí hodnot ě. Pro tento p řír ůstek platí ∇ (kTu ) = (kTu )− u[(k −1)T ] (7-3)

Dosazením rovnice pro polohový tvar (7-2) do rovnice (7-3) lze získat p řír ůstkový tvar PSD regulátoru [118].

 T T  ∇ ()()()kTu = K()kTe − e[]k −1 T + ()kTe + D ()()()kTe − 2e[]k −1 T + e[]()k − 2 T   TI T  (7-4)

7.1.1 Vstupy a výstupy

V implementacích číslicových PID regulátor ů jsou obvykle používány proudové nebo nap ěť ové vstupy. Proudové vstupy jsou nej čast ěji 4-20 mA, dále 0-20 mA, 10-50 mA. Nap ěť ové vstupy mohou být 0-10 V, 0-5 V, -10-10 V. Dalšími typy vstup ů mohou být nap ř. speciální vstupy pro termo články nebo odporové sníma če teploty (nap ř. Pt100). Pro optické sníma če polohy a rychlosti lze použít impulsní vstupy [120]. K převodu analogových vstupních signál ů na číslo jsou podle [119] používány dvanáctibitové, pop ř. šestnáctibitové A/D p řevodníky. Nutnou podmínkou správné funkce číslicového regulátoru je spln ění vzorkovacího teorému. Tato podmínka bývá obvykle spln ěna, její spln ění však nebývá posta čující. Správná volba vzorkovací periody je velmi d ůležitá, protože m ůže výrazn ě ovlivnit regula ční d ěj. Podle [118] lze za vhodnou vzorkovací periodu považovat takovou hodnotu, p ři které nedojde ke zhoršení regula čního d ěje o více než 15 % oproti použití analogického spojitého regulátoru. P říliš krátká perioda vzorkování vede k velkým ak čním zásah ům a ke zvyšování nárok ů na rychlost výpo čtů i p řevodník ů a obecn ě na celý regula ční obvod. Při zv ětšování periody vzorkování se zv ětšuje vliv suma ční složky a snižuje vliv složky

68 diferen ční. P ři p říliš dlouhé vzorkovací period ě dochází k destabilizaci regula čního obvodu. Výstupy regulátoru mohou být spojité nebo nespojité, podle druhu regulované veli činy. Spojité, tj. analogové výstupy jsou obvykle proudové 4 – 20 mA, p řípadn ě 0 – 20 mA. Mohou být také nap ěť ové, nap ř. 0 – 10 V. Jako nespojité výstupy jsou často využívány výkonové binární reléové výstupy [120]. Tyto výstupy mohou sloužit pouze jako dvoustavové pro jednoduchou regulaci nebo je lze využít pro pulsn ě-ší řkovou modulaci (PWM) a řídit jimi přímo nap ř. menší stejnosm ěrné motory.

7.1.2 Výpo čet

Vlastní výpo čet ak čního zásahu regulátoru, pop ř. jeho p řír ůstku (viz výše), probíhá přesn ě podle daných rovnic, p řevedených na sekvenci jednotlivých mezivýpo čtů. Výpo čty jsou provád ěny s datovými typy s pohyblivou řádovou čárkou (float , double ), které nabízení mnohem v ětší rozsah a p řesnost výpo čtů p ři stejné pam ěť ové náro čnosti. Reálné datové typy s sebou p ři softwarovém řešení p řinášejí také nevýhodu v podob ě v ětší časové náro čnosti. Moderní mikrokontroléry však disponují dostate čným výkonem i pro tyto výpo čty. Výraznou výhodou pro realizaci nejen řídicích algoritm ů je pak p řítomnost jednotky pro hardwarové výpo čty s plovoucí řádovou čárkou (FPU), která umož ňuje regula ční výpo čty mnohonásobn ě zrychlit. Musí docházet k cyklickému vykonávání t ěchto výpo čtů s periodou rovnou dané vzorkovací period ě T . To je obvykle zajišt ěno hardwarovým časova čem, který po každém uplynutí vzorkovací periody vyšle požadavek k přerušení a obslužná rutina tohoto p řerušení pak spustí smy čku programu, která provede výpo čet. Velmi d ůležitým praktickým požadavkem je, že nejdelší možná doba provád ění programu ( worst-case execution time , WCET) musí být kratší než vzorkovací perioda regulátoru. Do této doby je nutné zahrnout nejen dobu vlastního výpo čtu ak čního zásahu, ale také doby p řevodu vstupních analogových hodnot na číslo, p řípadnou úpravu t ěchto hodnot, nastavení výstupu v četn ě doby p řevodu binární hodnoty zp ět na analogovou a veškeré další operace, související p římo s danou řídicí úlohou. Definujeme-li tuto dobu WCET pro daný regulátor jako C , pak musí platit následující podmínka [121]. C < T (7-5) Tato podmínka je také znázorn ěna na Obr. 7-1. Do celkové doby výpo čtu je zde zahrnuto také čtení vstup ů ( Read ) a nastavení výstup ů ( Write ). Čas, nevyužitý výpo čtem je ozna čen jako Idle a lze jej využít nap ř. k obsluze uživatelského rozhraní nebo ke komunikaci s nad řazeným systémem. Pokud není podmínka (7-5) spln ěna, není možné zajistit správnou odezvu regulátoru a m ůže dojít k podstatnému zhoršení regula čního pochodu a v některých p řípadech nap ř. i k nebezpe čným situacím. Hodnota WCET je závislá na konkrétní

69 architektu ře/platform ě a její ur čení je obtížné zvláště u moderních procesor ů, využívajících r ůzné techniky pro zvýšení výkonu [121].

Obr. 7-1: Cyklické provád ění řídicího programu s periodou T [121]

7.1.3 Další praktické požadavky

Praktické realizace PSD regulátor ů se obvykle dopl ňují n ěkterými funkcemi. Základní algoritmus m ůže být modifikován pro zmenšení p řekmitu výstupní veli činy p ři zm ěnách žádané hodnoty. To jsou regulátory S-PD a PS-D [119]. V případ ě algoritmu PS-D vstupuje regula ční odchylka do proporcionální a integra ční (suma ční) části regulátoru, do deriva ční (diferen ční) části vstupuje pouze záporn ě vzatá regulovaná veli čina. Tím dochází ke zmenšení vlivu rychlých zm ěn žádané hodnoty a tím ke p řekmitu regulované veli činy. V p řípad ě S-PD regulátoru pak záporn ě vzatá regulovaná veli čina vstupuje do deriva ční i proporcionální části a regula ční odchylka vstupuje pouze do suma ční části, čímž lze dosáhnout dalšího omezení rychlých zm ěn ak čního zásahu regulátoru. Dalším problémem p ři praktické realizaci je derivační složka a její náchylnost na šumy a poruchové signály. Ve spojitém regulátoru je díky setrva čnostem zajišt ěna částe čná odolnost proti rychlým zm ěnám regula ční odchylky. Číslicová realizace je však na tyto vlivy náchylná, protože, jak bylo uvedeno, výpo čet se provádí z navzorkovaných hodnot p řesn ě podle zadaných rovnic. Tím m ůže dojít k příliš velkým zm ěnám ak ční veli činy. Tomuto jevu lze zabránit filtrací deriva ční složky nap ř. podle [119]. Velikost reálného ak čního zásahu je vždy n ějakým zp ůsobem omezena (velikost napájecího nap ětí, doraz ak čního členu). Pokud dojde k takovému omezení a regula ční odchylka je dále integrována, zv ětšuje se velikost ak čního zásahu, aniž by se projevila na výstupu regulátoru. Až se zm ěnou znaménka regula ční odchylky za čne se za čne integra ční složka zmenšovat, což vyžaduje ur čitý čas. Tím vzniká tzv. wind-up zpožd ění, které zhoršuje kvalitu regula čního d ěje. U číslicových regulátor ů je tento problém op ět výrazn ější, protože zde nejsou žádná fyzikální omezení a jediné praktické omezení je dáno rozsahem reprezentací čísel v po číta či/mikrokontroléru. Proto je t řeba algoritmicky omezit další na čítání integra ční složky regulátoru, pokud ak ční veli čina překro čí ur čitou maximální hodnotu, a to až do doby, kdy dojde ke zm ěně znaménka

70 regula ční odchylky [118]. K ochran ě proti p řeintegrování lze použít r ůzných metod s různými vlastnostmi. Základem všech metod je detekce saturace ak ční veli činy regulátoru. V [122] jsou uvedeny nejd ůležit ější metody. Pro praktické využití spojitých i diskrétních regulátor ů se dále používá mechanismus beznárazového p řepínání mezi ru čním a automatickým režimem. V ru čním režimu lze nastavovat ak ční veli činu. Beznárazové p řepínání musí zajistit hladký p řechod mezi jednotlivými režimy p ři nulové regula ční odchylce. P ři použití polohového algoritmu je nutné zajistit, aby p ři p řepnutí byl výstup regulátoru shodný s ru čně nastavenou hodnotou. U p řír ůstkového algoritmu je pak p ředchozí hodnota ak čního zásahu vždy uložena do pam ěti bez ohledu na to, ve kterém režimu byla nastavena [118]. Pro beznárazové p řepínání lze použít nap ř metodu zp ětného sledování signálu, která je vhodná i pro vícerozm ěrné regula ční systémy. Mimo to ji lze využít také k ochran ě proti wind-up zpožd ění s prom ěnnými hodnotami mezí saturace ak ční veli činy [122].

7.2 Komplexní regula ční systémy

V předcházející části byla obecn ě popisována implementace regula čního systému s jediným regulátorem. Taková implementace je pom ěrn ě snadná, a obvykle nevyžaduje použití zvláštních technik ani opera čního systému jako prost ředníka mezi regula čním algoritmem a hardwarem použitého po číta če nebo mikrokontroléru. Díky tomu je velmi jednoduchá a bezpe čná. V řídicích úlohách se však lze setkat také se složit ějšími systémy, které, mají-li být úsp ěšn ě řízeny, vyžadují komplexn ější regula ční obvody. Tyto systémy mohou mít více stup ňů volnosti, které je obvykle nutné řídit sou časn ě a je tedy nutné použít více sou časn ě pracujících regulátor ů. Pokud má být takové řízení realizováno po číta čem nebo mikrokontrolérem, který je ze své podstaty sekven čním systémem a neumož ňuje tedy paralelní zpracování, je t řeba zajistit spolehlivé plánování a provád ění jednotlivých operací a výpo čtů tak, aby bylo vždy zajišt ěno, že každý výpo čet bude proveden se správnými a aktuálními daty a bude ukon čen v daném čase. Toto je základní p ředpoklad pro správnou funkci systém ů reálného času.

7.2.1 Systémy s jedinou vzorkovací periodou

Nejjednodušším p řípadem komplexního řídicího systému je soustava n ěkolika regulátor ů, pracujících se stejnou periodou vzorkování. To znamená, že b ěhem této periody musí být sekven čně proveden výpo čet všech t ěchto regulátor ů, v četn ě čtení vstup ů a nastavení výstup ů tak, jak bylo uvedeno výše, aniž by celkový čas p řekro čil K dobu vzorkovací periody. Definujeme-li pro systém s n regulátory c1 cn se spole čnou

71 vzorkovací periodou T dobu WCET i -tého regulátoru jako Ci , musí být pro realizaci takového systému spln ěna podmínka n < ∑Ci T . (7-6) i=1 Podmínka (7-6) je v podstat ě rozší řením výše uvedené podmínky (7-5) pro systém s více regulátory. Jestliže je tato podmínka spln ěna, lze použít jednoduchý plánovací mechanismus a spoušt ět jednotlivé výpo čty sekven čně, pop ř. by bylo možné jednotlivým regulátor ům p řiřadit priority podle d ůležitosti a spoušt ět jejich výpo čty podle t ěchto priorit. Tato metoda, kdy jsou programy spouštěny jeden po druhém, umož ňuje využít již vytvo řený kód pro všechny regulátory a jednoduchými úpravami nap ř. m ěnit po čet regulátor ů. P ři použití uvedeného plánovacího mechanismu je pak možné nap ř. n ěkterý regulátor jednoduše vy řadit z provozu. Metoda nabízí dobrou modularitu, není však p říliš efektivní z pohledu využití procesorového času. Větší efektivity, ovšem s následkem výrazn ě menší modularity, lze pak dosáhnout spojením všech regulátor ů do jediného programu a využitím optimaliza čních nástroj ů k vygenerování kódu pro celý řídicí systém. N ěkteré části výpo čtů jsou spole čné pro více regulátor ů a je tedy možné provést tyto výpo čty pouze jednou. Tím dochází k redukci po čtu operací a zefektivn ění kódu a je možné na daném procesoru dosáhnout kratší doby vzorkování [121].

7.2.2 Systémy s více vzorkovacími periodami

Obecn ějším a čast ějším p řípadem regulovaného systému je soustava s několika stupni volnosti, které mají r ůznou dynamiku. To znamená, že pro řízení takové soustavy je nutné použít systém regulátor ů s různými vzorkovacími periodami. V [121] je takový ( ) = K systém s n regulátory popsán jako množina dvojic c ,Tii pro i 1 n , kde Ti je celo číselná vzorkovací perioda i -tého regulátoru ci . Pro tento systém lze dále definovat základní periodu, tj. nejkratší periodu, se kterou bude systém pracovat, jako nejv ětšího spole čného d ělitele ( greatest common divisor , gcd) vzorkovacích period jednotlivých regulátor ů. Pro základní periodu T tedy platí. = ( K ) T gcd T1 , ,Tn . (7-7) V [121] je definována také tzv. super-perioda P , která p ředstavuje dobu, po které se bude opakovat spoušt ění jednotlivých regulátor ů. Pokud tedy bude nalezena vyhovující sekvence spoušt ění pro jednu super-periodu, lze řídicí systém považovat za funk ční. Super-periodu lze definovat jako nejmenší spole čný násobek vzorkovacích period jednotlivých regulátor ů ( least common multiple , lcm). = ( K ) P lcm T1 , ,Tn (7-8) Přirozeným a nejjednodušším řešením tohoto problému je spoušt ění úloh jednotlivých regulátor ů vždy v násobcích základní periody, odpovídajících jednotlivým

72 vzorkovacím periodám Ti . Toto řešení je však neefektivní. V některých cyklech je třeba, aby byly provedeny výpo čty všech regulátor ů, zatímco v ostatních cyklech je provád ěno mnohem mén ě výpo čtů. V případ ě nesoud ělných vzorkovacích period je pak možné, že budou n ěkteré cykly zcela nevyužity, neuvažujeme-li další funkce, jako nap ř. obsluhu uživatelského rozhraní. Nejkratší základní perioda, dosažitelná s použitím daného procesoru, je ur čena sou čtem čas ů WCET jednotlivých regulátor ů. Op ět musí být spln ěna podmínka (7-6). Za p ředpokladu, že lze úlohu zpracovávající výpo čet daného regulátoru rozd ělit na několik částí, které lze provád ět v mén ě využitých cyklech, je možné dosáhnout efektivn ějšího využití procesorového času. Podmínkou je, aby byla celá úloha dokon čena v odpovídajícím časovém intervalu. Pro první spušt ění úlohy regulátoru ci ( ) ([ − ]⋅ ⋅ ) je to interval ;0Ti . Obecn ě pro k -té spušt ění bude tento interval k 1Ti ;k Ti . Spodní hranice intervalu je v [121] ozna čena jako čas spušt ění ( release time ) a horní hranice jako deadline , tj. časový limit pro dokon čení úlohy. Tento zp ůsob řešení lze provést bu ď statickým rozd ělením p ři p řekladu nebo použitím opera čního systému reálného času.

Statické d ělení První zp ůsob spo čívá ve statickém rozd ělení kódu na n ěkolik částí s přibližn ě stejnou délkou provád ění a spoušt ění t ěchto částí rovnom ěrn ě v daném intervalu. Tím lze dosáhnout lepší efektivity. V [121] je uvedeno, že tato metoda je v praxi populární a je použita v některých komer čních nástrojích.

Použití RTOS Další možností, jak bylo uvedeno, je využití opera čního systému reálného času. Každý regulátor je zde reprezentován samostatnou úlohou a tyto úlohy jsou spoušt ěny preemptivním plánova čem opera čního systému. Úlohy s delší periodou jsou provád ěny pouze když je k dispozici dostatek času a jsou p řerušovány úlohami, které mají být vykonány d říve. Nevýhodou je ur čitý čas, strávený p řepínáním kontextu p ři zm ěně běžící úlohy. Z tohoto d ůvodu je doba p řepnutí kontextu jedním z nejd ůležit ějších parametr ů každého opera čního systému reálného času. Jestliže definujeme relativní množství času, strávené vykonáváním i -té úlohy jako C i , pak pro n úloh bude celkové relativní množství času, strávené jejich zpracováním, Ti tj. v podstat ě koeficient využití procesoru ( utilization factor ), dáno následujícím vztahem [123]. n C U = ∑ i (7-9) i=1 Ti

73 Jestliže má být plánování realizovatelné, tj. koeficient využití procesoru musí být menší než 100 %, pak musí platit n C U < 1 ⇒ ∑ i < 1. (7-10) i=1 Ti Podmínka (7-10) je uvedena také v [121]. K plánování lze použít r ůzných strategií. Dv ě nejpopulárn ější plánovací strategie jsou podle [121] EDF ( earliest deadline first ) a RM ( rate-monotonic ).

Metoda EDF První uvedená metoda spo čívá v tom, že je vždy vybrána úloha s nejbližším časem pro ukon čení ( deadline ) a tato je provád ěna, tj. je jí p řid ělena nejvyšší priorita. Jedná se tedy o dynamickou zm ěnu priorit úloh v závislosti na časových limitech. Pokud jsou tyto časy stejné u více úloh, je výb ěr libovolný s tím, že p řednost je dána úloze, která již případn ě b ěží, aby bylo minimalizováno p řepínání kontextu. Tato metoda je podrobn ěji popsána v [123] jako Deadline Driven Scheduling.

Metoda RM Druhá metoda využívá statické p řid ělování priorit, které vychází z frekvence provád ění jednotlivých úloh, tj. priority jsou úlohám p řid ěleny podle velikosti vzorkovacích period. Úloha pro regulátor s nejkratší vzorkovací periodou bude mít nejvyšší prioritu, úloha pro regulátor s nejdelší periodou pak bude mít nejnižší prioritu. Tato metoda provádí více preempcí a je tedy mén ě efektivní než výše uvedená, je však jednodušší ji v opera čních systémech implementovat [121].

V [121] je dále uveden p říklad systému se t řemi regulátory. Tento systém je popsán = {( ) ( ) ( )} = = S123 c1 ,1, c2 ,2, c3 3, . Základní perioda je T 1 a super-perioda P 6. Intervaly pro spoušt ění jednotlivých regulátor ů c1 až c3 jsou následující. ( ) ( ) ( ) ( ) ( ) ( ) c1 : 6;5,5;4,4;3,3;2,2;1,1;0 ()()() c2 : 6,4,4,2,2,0 ()() c3 : 6,3,3,0 Na Obr. 7-2 je srovnání t ří uvedených metod d ělení programu, tj. statické d ělení (na obrázku ozna čeno Static), algoritmus EDF a algoritmus RM. Statickým rozd ělením jsou

úlohy regulátor ů c2 a c3 rozd ěleny na c21 , c22 a c31 , c32 , c33 a tyto jednotlivé části jsou spoušt ěny tak, aby byly dodrženy uvedené časové intervaly.

Na Obr. 7-2 je dále vid ět, že p ři použití metody EDF není první instance úlohy c3 přerušena t řetí instancí úlohy c1 , protože tyto úlohy mají stejný časový limit pro vykonání ( deadline ) a je tedy v souladu s výše uvedeným principem metody zachováno provád ění úlohy c3 . K tomuto však nedochází u metody RM, kdy je kv ůli statickému

74 přid ělení priorit vykonávání úloh c2 a c3 vždy v daném okamžiku p řerušeno úlohou c1 . ( ) To má za následek, že první instance úlohy c3 není dokon čena v daném intervalu 3;0 , jak je patrné na Obr. 7-2. Zbylá část výpo čtu (na obrázku ozna čena šipkou) je provedena až po p řekro čení horního limitu tohoto intervalu. Metodu RM tedy nelze pro uvedený systém na dané platform ě použít.

Obr. 7-2: Srovnání statického d ělení kódu, EDF a RM pro systém S123 [121]

7.3 Návrh PSD regulátoru jako úlohy opera čního systému

V klasické smy čkové implementaci se lze na regulátor dívat jako na sekvenci operací a výpo čtů, která je opakovan ě spoušt ěna obvykle s využitím hardwarového časova če. Pokud je t řeba, aby pracovalo sou časn ě více regulátor ů, je obvykle nutné tuto sekvenci modifikovat. P ři složit ějších úpravách programu pak dochází nejen ke zvyšování obtížnosti údržby a lad ění, ale i ke snižování celkové spolehlivosti systému a jeho schopnosti vyhov ět daným požadavk ům na časové chování. M ůže tedy dojít i k selhání takového systému. Z pohledu opera čního systému je vhodn ější o regulátoru uvažovat jako o funk čním bloku, který disponuje ur čitými vstupy a výstupy. Tento blok je možné spoušt ět a zastavovat, m ěnit prioritu jeho provád ění, pop ř. v případ ě pot řeby dynamicky vytvá řet další instance tohoto základního bloku. Pokud je daná řídicí úloha rozd ělena na takovéto funk ční bloky, je tím snížena obtížnost lad ění a zvýší se celková p řehlednost vytvo řeného systému. V případ ě správného návrhu pak také dochází ke zvýšení spolehlivosti a selhání n ěkteré z mén ě kritických funkcí nemusí zp ůsobit selhání celého systému, což je v některých aplikacích velmi d ůležité (tzv. fault-tolerant systémy).

75 Principiální funkce popsaného bloku m ůže vypadat např. tak, jak je nazna čeno na Obr. 7-3. Po úvodní inicializaci bloku, provedené při spušt ění systému, pop ř. p ři jeho vytvo ření, je jeho vykonávání pozastaveno až do doby, kdy je zapot řebí. Tento blok je pak spoušt ěn pouze v případ ě pot řeby a tím je umožn ěn b ěh dalších blok ů. Samoz řejm ě je možné, že vykonávání bloku bude p řerušeno nap ř. z důvodu p říchodu požadavku s vyšší prioritou. Správné a rychlé p řepnutí kontextu a jeho op ětovné obnovení p ři návratu musí zajistit opera ční systém.

Obr. 7-3: Principiální znázorn ění činnosti úlohy opera čního systému

start systému (vytvo ření bloku)

inicializace bloku

čekání na spušt ění

provedení operace

Z uvedeného principu vychází vlastní návrh PSD regulátoru jako úlohy pro implementaci s použitím vybraných OS reálného času. V inicializa ční části po spušt ění úlohy jsou vytvo řeny všechny pot řebné prom ěnné, vypo čteny n ěkteré konstantní hodnoty a také inicializovány použité synchroniza ční prost ředky. Následuje hlavní smy čka úlohy, kde je vždy nejprve proveden požadavek na spušt ění A/D p řevodu. Po tomto požadavku je úloha pozastavena (blokována) a čeká na synchroniza ční pokyn, že byl p řevod ukon čen. Po odblokování a uložení p řevedených dat je t řeba provést kontrolu, zda nedošlo ke zm ěně žádané hodnoty nebo n ěkterého parametru regulátoru. Pokud ano, jsou tyto hodnoty zm ěněny. Následn ě je p řevedené binární číslo p řepo čteno na reálnou hodnotu vstupního signálu a je proveden vlastní regula ční výpo čet. Po provedení výpo čtu je hodnota p řepo čtena zp ět na binární číslo a toto číslo je posláno k převodu na analogovou hodnotu.

76 8 IMPLEMENTACE

V této kapitole bude popsán postup implementace nejprve obou vybraných opera čních systém ů od stažení distribuce systému z internetu p řes vytvo ření a konfiguraci pracovního prost ředí až po implementaci navržených regula čních struktur.

Vybrané OS reálného času byly staženy v podob ě zdrojových soubor ů, které bylo nutno p řipojit k vlastnímu projektu. Programy byly tvo řeny v jazyku C. Pro implementaci programového vybavení byly použity vývojové nástroje z projektu GNU Tools for ARM Embedded Processors , které jsou spravovány zam ěstnanci spole čnosti ARM [124]. Tyto voln ě ši řitelné nástroje jsou odvozeny od b ěžných nástroj ů GNU a jsou ur čeny pro procesory s jádry Cortex-M a Cortex-R. Je možné je použít jak na systémech s Linuxovým jádrem, tak i na opera čních systémech Windows a Mac OS. Mezi nástroji jsou nejen základní programy jako p řeklada č, linker apod., ale také nap ř. ladicí program gdb nebo programy pro zjišt ění velikosti p řeložených binárních soubor ů. Pro tvorbu programového vybavení byla použita verze 4.7 2013q2. Po stažení předsestavené verze pro Windows v .zip archivu o velikosti p řibližn ě 100 MB je vhodné nastavit systémovou prom ěnnou PATH tak, aby obsahovala cestu k binárním soubor ům všech nástroj ů, tj. k podadresá ři bin v ko řenovém adresá ři distribuce. Tímto nastavením je pak zajišt ěno pohodlné volání všech program ů bez nutnosti nastavovat cestu v každém projektu. Pro nahrávání p řeloženého binárního souboru do FLASH programové paměti mikrokontroléru byl použit program STM32 ST-LINK Utility , který je pro tento ú čel voln ě ke stažení z internetových stánek výrobce použitého mikrokontroléru ST Microelectronics. V po čátcích práce bylo rozhodnuto, že pro testování nebude použito žádné integrované vývojové prost ředí (IDE). D ůvodem pro toto rozhodnutí byla v první řad ě špatná dostupnost kvalitních a voln ě ši řitelných IDE, pop ř. jejich složitá konfigurace, a také absence podpory komunika čního rozhraní ST-LINK/V2, kterým disponuje použitá vývojová deska STM32F4-Discovery. Program STM32 ST-LINK Utility však disponuje rozhraním CLI ( Command-Line Interface ), tj. rozhraním pro použití z příkazového řádku. Proto bylo rozhodnuto, že p řeklad i programování mikrokontroléru bude provedeno v jednom kroku, voláním z příkazového řádku. Dalším použitým nástrojem tedy byl program GNU make , který slouží k automatizaci a usnadn ění p řekladu v ětšího množství zdrojových soubor ů. Tento program je b ěžnou sou částí Linuxových systém ů. Vzhledem k tomu, že v systémech Windows není tato funkce p římo dostupná, byla použita varianta programu make z distribuce vývojových prost ředk ů WinAVR [125] verze 20100110 (nejnov ější verze) pro mikrokontroléry řady AVR firmy Atmel. Funkce této varianty programu make se neliší od p ůvodního programu z projektu GNU.

77 Pro řízení p řekladu slouží speciální soubor Makefile který obsahuje popis vzájemných závislostí jednotlivých zdrojových soubor ů a postup p řekladu, p řípadn ě další p říkazy. Program make , a tedy i p řeklad a všechny související operace definované v souboru Makefile , lze spustit z příkazového řádku stejnojmenným p říkazem make , případn ě s dalšími parametry, kterými lze ur čit požadovanou činnost programu make . Po zavolání tohoto p říkazu je automaticky proveden p řeklad a je možné automaticky ihned po p řekladu výsledný binární soubor nahrát do pam ěti FLASH mikrokontroléru zavoláním CLI funkcí programu STM32 ST-LINK Utility ze souboru Makefile tak, jak bylo popsáno výše. K použití tohoto však nedošlo, bylo shledáno, že pro daný ú čel je dosta čující vždy p řeložený binární soubor otev řít v grafickém rozhraní programu STM32 ST-LINK Utility a spustit programování ru čně. Pro vlastní tvorbu a prohlížení zdrojových kód ů byl použit voln ě ši řitelný univerzální editor PSPad , ur čený pro systémy Microsoft Windows. Tento editor nabízí zvýrazn ění syntaxe pro množství r ůzných jazyk ů, samoz řejm ě v četn ě C/C++. Pro lad ění lze využít program gdb , který je sou částí výše popsaných vývojových nástroj ů.

8.1 Vytvo ření projektu pro systém FreeRTOS

Pro práci se systémem FreeRTOS byla jako základ použita struktura p řevzatá z projektu, staženého z [126]. Tento projekt byl použit již p ři ov ěř ování funkce samotné vývojové desky a použitého mikrokontroléru (bez použití OS). Projekt již obsahuje tém ěř vše pot řebné k vývoji aplikací pro vývojovou desku STM32F4-Discovery v četn ě standardních knihoven a ovlada čů , dodávaných výrobcem ST Microelectronics, a skriptu pro linker. Původní struktura obsahuje tři adresá ře. Adresá ř src obsahuje zdrojové soubory aplikace, obslužných rutin p řerušení a systémové konfigurace. Adresá ř inc pak podobn ě obsahuje hlavi čkové soubory. Poslední adresá ř lib obsahuje výše zmín ěné standardní knihovny a ovlada če pro vývojovou desku a vestav ěné periferie použitého mikrokontroléru a dále inicializa ční rutinu vytvo řenou v jazyku symbolických adres (startup_stm32f4xx.s ). Struktura tohoto adresá ře je dále d ělena obdobn ě, tj. na zdrojové a hlavi čkové soubory a také je provedeno další logické d ělení. Knihovny, využívané jádrem mikrokontroléru jsou umíst ěny odd ělen ě od ovlada čů periferií, jejichž použití je volitelné. Struktura projektu dále obsahuje zmín ěný skript pro linker ( stm32_flash.ld ) a dále hlavní soubor Makefile , který popisuje vzájemné závislosti jednotlivých zdrojových soubor ů a postup p řekladu a sestavení výsledného binárního souboru. Soubor Makefile je využíván programem make , který je do adresá ře projektu zkopírován. Úprava pro použití systému FreeRTOS spo čívala v první řad ě v přidání dalšího adresá ře se zdrojovými soubory OS do projektu. Tento adresá ř byl pojmenován

78 FreeRTOS a v něm byl vytvo řen podadresá ř Source tak, aby byla dodržena struktura adresá řů distribuce systému FreeRTOS (viz část 5.2). Do podadresá ře portable pak byly vloženy pouze zdrojové soubory správy pam ěti a p říslušné soubory portu pro překlada č GCC a architekturu ARM Cortex-M4F. Struktura projektu je znázorn ěna na Obr. 8-1. Pro zachování p řehlednosti není znázorn ěna vnit řní struktura adresá ře lib .

Obr. 8-1: Zjednodušené znázorn ění struktury projektu pro systém FreeRTOS

adresá ř projektu FreeRTOS

FreeRTOS lib inc src Makefile make.exe stm32_flash.ld Source … *.h *.c

*.c include portable

*.h MemMang GCC

heap_x.c ARM_CM4F

port.c portmacro.h

Dále byl upraven hlavní soubor Makefile . V tomto souboru jsou definovány všechny zdrojové soubory, které mají být p řeloženy ( SRCS ). Je tedy nutné definovat také zdrojové soubory systému FreeRTOS, p řípadn ě další vytvo řené zdrojové soubory. Tímto je p říprava projektu pro použití s opera čním systémem FreeRTOS dokon čena.

8.2 Vytvo ření projektu pro systém ChibiOS/RT

Struktura projektu pro opera ční systém ChibiOS/RT byla p řevzata z demonstra ční aplikace pro vývojovou desku STM32F4-Discovery, která je sou částí distribuce. P ři pokusu o první p řeklad se však objevila chyba, zp ůsobená pravd ěpodobn ě nekompatibilitou (demonstra ční aplikace jsou ur čeny pro p řeklad pod Linuxovými systémy). Po n ěkolika neúsp ěšných pokusech o odstran ění této chyby bylo rozhodnuto, že pro práci se systémem ChibiOS/RT bude využit již nainstalovaný balík otev řených

79 program ů Cygwin , který umož ňuje emulaci unixových systém ů na opera čních systémech Microsoft Windows. Byla použita verze 2.819. Více o tomto balíku program ů lze nalézt v [127]. Zdrojové soubory projektu je t řeba zkopírovat do adresá ře, kde je balík Cygwin nainstalován a to do podadresá ře cyqwin/home/(uživatelské jméno) . Struktura projektu byla následn ě upravena následujícím zp ůsobem. Z adresá ře boards byly vymazány všechny nepot řebné podadresá ře pro vývojové desky a ponechán pouze podadresá ř ST_STM32F4_DISCOVERY pro použitou vývojovou desku. Stejn ě tak byly vymazány všechny podadresá ře z adresá ře os/hal/platforms krom ě podadresá ře STM32F4xx a STM32 a z adresá ře os/ports byly ponechány pouze podadresá ře common a GCC/ARMCMx . Následn ě byly odstran ěny adresá ře test a testhal , které slouží k testování funkcí opera čního systému a pro projekt nejsou pot řebné. Poslední úpravou bylo p řesunutí demonstra ční aplikace z adresá ře demos/ARMCM4- STM32F407-DISCOVERY do nov ě vytvo řeného adresá ře ur čeného pro zdrojové soubory projektu ChibiOS_2.6.3/projekt . Zbytek demonstra čních aplikací byl op ět smazán. Z důvodu absence ovlada če pro D/A p řevodník ve vrstv ě HAL systému ChibiOS/RT byl p řidán další adresá ř ST_periph_lib , který obsahuje pot řebné zdrojové soubory standardních ovlada čů periferií od výrobce mikrokontroléru ST Microelectronics. Bylo také nutné upravit hlavní soubor Makefile . První úprava spo čívala v nastavení správné cesty ke zdrojovým soubor ům opera čního systému (prom ěnná CHIBIOS ). Dále byly p řidány zdrojové soubory ovlada čů z adresá ře ST_periph_lib k ostatním zdrojovým soubor ům v jazyku C (prom ěnná CSRC ) a cesta k hlavi čkovým soubor ům těchto ovlada čů (prom ěnná INCDIR ). Sou časn ě byly odebrány soubory pro testování (TESTSRC a TESTINC ) a odebráno vložení souboru test.mk pro tyto soubory. Následn ě bylo také povoleno použití jednotky FPU ( USE_FPU = yes ). Tímto je projekt p řipraven k použití. Zjednodušené znázorn ění struktury projektu je na Obr. 8-2.

80 Obr. 8-2: Zjednodušené znázorn ění struktury projektu pro systém ChibiOS/RT

adresá ř projektu ChibiOS/RT

boards docs ext os ST_periph_lib projekt

… … inc src

ST_STM32F4_DISCOVERY *_dac.h *_dac.c *_rcc.h *_rcc.c

cfg board.c * stm32f4xx board.h chconf.h board.mk halconf.h mcuconf.h Makefile

hal kernel ports vari ous

… platforms … common GCC …

STM32 STM32F4xx ARMCM x ARMCM x

… … CMSIS …

…

8.3 Implementace PSD regulátoru v systému FreeRTOS

Úloha pro PSD regulátor byla nejprve implementována v systému FreeRTOS podle principiálního návrhu uvedeného v části 7.3. Pro synchronizaci úlohy regulátoru s A/D převodníkem byla použita fronta, pomocí které jsou sou časn ě posílána p řevedená data. Další fronta byla použita pro p ředávání žádané hodnoty, p řípadn ě parametr ů regulátoru, z nad řazené úlohy. Vzhledem k tomu, že není t řeba provád ět uvol ňování pam ěti, bylo použita nejjednodušší implementace správy pam ěti (soubor heap_1.c , viz část 5.7). Zásobník byl nastaven na 1000 slov, tj. pro 32-bitové slovo je velikost zásobníku 4000 B.

81 Takovéto nastavení zásobníku je pln ě dosta čující pro lad ění programu se všemi pot řebnými prom ěnnými. Program byl rozd ělen do dvou soubor ů Ve zdrojovém souboru main.c je hlavní funkce main() , kde je provedena inicializace vstupn ě výstupních vývod ů mikrokontroléru, nastavení A/D a D/A převodníku, nastavení priorit p řerušení a také vytvo ření vlastní úlohy pro PSD regulátor. Je zde také obslužná rutina p řerušení od A/D p řevodníku ADC_IRQHandler() . V této rutin ě je pouze otestován p říznak ukon čení p řevodu p říslušného p řevodníku a p řevedená data jsou odeslána do fronty xADCQueue pomocí speciální API funkce pro využití v obslužných rutinách p řerušení xQueueSendFromISR() . Dále je zde provedeno testování, zda odesláním dat do fronty nedošlo k odblokování n ěkteré úlohy. Pokud ano, je tato úloha spušt ěna ihned po návratu z přerušení. Druhým souborem je zdrojový soubor main_tasks.c a p řipojený hlavi čkový soubor main_tasks.h . Ve zdrojovém souboru main_tasks.c jsou globáln ě deklarovány použité fronty a je zde samotná úloha pro PSD regulátor. V hlavi čkovém souboru main_tasks.h jsou pak uvedeny definice konstant pro regulátor (inicializa ční časové konstanty a zesílení, rozsah vstupních a výstupních signál ů a rozlišení p řevodníku) a dále globální prom ěnné. Úloha pro PSD regulátor je realizována formou nekonečné smy čky. Vývojový diagram úlohy PSD regulátoru je na Obr. 8-3. Po spušt ění úlohy je nejprve provedena inicializace. Prom ěnné pro data z A/D p řevodníku a pro D/A p řevodník jsou celo číselného datového typu integer o ší řce 16 bit ů (použité rozlišení je 12 bit ů), ostatní prom ěnné pro regula ční odchylku, ak ční zásah, stav regulátoru a prom ěnné pro přepo čet převedeného čísla na reálnou hodnotu signálu jsou typu float , tj. s plovoucí řádovou čárkou s přesností single precision , aby bylo možno pro výpo čty s nimi využít jednotku FPU. Po definici a deklaraci pot řebných prom ěnných je vypo čítána frekvence spoušt ění úlohy podle vztahu 1000 xFrequency = ⋅T _ S , (8-1) configTICK _ RATE _ HZ

kde configTICK _RATE _ HZ je frekvence systémových hodin nastavená v konfigura čním souboru FreeRTOSConfig.h T _S je vzorkovací perioda regulátoru definovaná v souboru main_tasks.h .

Následn ě jsou pomocí API funkce xQueueCreate() vytvo řeny fronty pro komunikaci úlohy s obslužnou rutinou p řerušení, pop ř. s nadřazenou řídicí úlohou. Po vytvo ření front jsou vypo čteny reálné hodnoty LSB pro vstupní a výstupní signál.

82 Následující vztah je uveden pro vstupní signál.

PSD _ IN _ RNG fInputLSB = , (8-2) 2 PSD _ IN _ RES −1

kde PSD _IN _ RNG je rozsah vstupního signálu (konstanta) PSD _IN _ RES je rozlišení A/D p řevodníku (konstanta).

Ob ě konstanty ve vztahu (8-2) jsou definovány v hlavi čkovém souboru main_tasks.h jako parametry regulátoru. Pro LSB výstupního signálu (prom ěnná fOutputLSB ) platí v podstat ě stejný vztah, pouze s jinými konstantami, taktéž definovanými v souboru main_tasks.h , proto zde nebude uveden. Po tomto výpo čtu vstupuje provád ění úlohy do hlavní smy čky. V hlavní smy čce je nejprve zjišt ěn aktuální systémový čas pomocí API funkce xTaskGetTickCount() a uložen jako poslední čas spušt ění úlohy a následn ě je spušt ěn A/D p řevod pomocí p římého zápisu do registru CR2 p řevodníku ADC1, pop ř. jiného použitého p řevodníku. Následn ě je proveden pokus o čtení dat z fronty xADCQueue . Pokud data nejsou k dispozici (fronta je prázdná), úloha je zablokována a v tomto stavu čeká až do doby, kdy jsou data dostupná. Jakmile jsou data v po řádku p řijata, je proveden p řepo čet na reálnou hodnotu vstupního signálu podle vztahu

fInputVal = PSD _ IN _ MIN + uiInputDat a ⋅ fInputLSB , (8-3)

kde PSD _IN _ MIN je spodní hranice rozsahu vstupního signálu, definovaná jako konstanta v souboru main_tasks.h uiInputDat a je binární hodnota z A/D p řevodníku ( integer 16 bit ů).

Prom ěnná fInputVal tedy p ředstavuje vstup do regulátoru, tj. výstup regulované soustavy. Dále je provedena kontrola, zda nejsou data ve front ě xParQueue , pomocí které mohou být p ředávány parametry regulátoru v četn ě žádané hodnoty. Pro tuto kontrolu je nastaven krátký časový limit. To znamená, že pokud nejsou data v této front ě dostupná b ěhem kontroly, je úloha blokována pouze na velmi krátkou dobu a poté pokra čuje v činnosti. Tím je zajišt ěna funkce regulátoru nezávisle na tom, zda byly nebo nebyly zm ěněny jeho parametry. Následuje vlastní regula ční výpo čet. Tento výpo čet byl vytvo řen podle p říkladu implementace PSD regulátoru s filtrací deriva ční složky a dynamickým omezením suma ční složky, který je uveden v [128]. Výpo čet zde nebude uveden, protože jeho provedení není z hlediska této práce p říliš d ůležité. Lze jej nalézt ve zdrojovém souboru main_tasks.c ve funkci vPSDTask() , pop ř. v podobné form ě v [128].

83 Po vypo čtení ak čního zásahu (prom ěnná fOutputVal ) je jeho reálná hodnota přepo čtena na binární číslo pro p řevod D/A p řevodníkem podle vztahu

fOutputVal uiOutputDa ta = , (8-4) fOutputLSB

Přepo čtená hodnota je následn ě pomocí funkcí standardních ovlada čů periferií od ST Microelectronics odeslána k převodu D/A p řevodníkem na výstupní analogovou hodnotu ak čního zásahu. Poté je úloha zablokována pomocí API funkce vTaskDelayUntil() a čeká na další spušt ění.

8.4 Implementace PSD regulátoru v systému ChibiOS/RT

Implementace úlohy pro PSD regulátor byla provedena také v systému ChibiOS/RT. Tato implementace je z velké části shodná s implementací v systému FreeRTOS, uvedené v předešlé části, a liší se v podstat ě pouze z důvodu odlišných funkcí obou systém ů. Vývojový diagram na Obr. 8-3 je tedy platný i pro tuto implementaci. Základním rozdílem oproti p ředešlé implementaci je využití vrstvy HAL, kterou systém ChibiOS/RT nabízí. Konkrétn ě jde o využití ovlada če pro A/D p řevodník a dále ovlada čů pro GPIO vývody mikrokontroléru. Vzhledem k tomu, že vrstva HAL systému ChibiOS/RT nenabízí ovlada č pro D/A p řevodník, bylo nutné k projektu p řipojit také standardní ovlada č pro tento převodník od výrobce mikrokontroléru tak, jak popisuje část 8.2. K předávání paramter ů regulátoru byl využit mechanismus asynchronních zpráv, popsaný v části 6.6.6. Velikost zásobníku byla op ět nastavena na vysokou hodnotu 4000 B, aby byly p ři lad ění vylou čeny problémy zp ůsobené její p říliš malou hodnotou. Program je op ět rozd ělen do dvou soubor ů se stejnými názvy jako u systému FreeRTOS, tj. main.c a main_tasks.c s hlavi čkovým souborem main_tasks.h . Ve zdrojovém souboru main.c je definována inicializa ční struktura pro nastavení A/D převodníku ADCConvGroup , kde je provedeno nastavení po čtu kanál ů, spoušt ění apod. Je zde také odkaz na tzv. callback funkci, která je volána po ukon čení p řevodu [129]. Tato funkce je také definována v souboru main.c jako ADCCallback() a pouze nastavuje semafor ADCSemaphore , který je využit pro synchronizaci úlohy PSD regulátoru a A/D převodníku. Ve funkci main() je nejprve inicializována vrstva HAL (funkce halInit() ). Následuje nastavení D/A p řevodníku pomocí funkcí standardních ovlada čů výrobce ST Microelectronics. Tato inicializace musí následovat až po volání funkci halInit() , jinak dochází k problém ům, které jsou pravd ěpodobn ě zp ůsobeny p řepisem ur čitých registr ů. Dále jsou nastaveny GPIO vývody mikrokontroléru pomocí funkcí vrstvy HAL systému ChibiOS/RT. Po tomto nastavení již následuje inicializace vlastního

84 opera čního systému pomocí funkce chSysInit() . Následn ě již mohou být spušt ěny úlohy. Úlohy a globální prom ěnné jsou definovány ve zdrojovém souboru main_tasks.c , podobn ě jako u systému FreeRTOS. Úloha pro PSD regulátor je definována jako statická (viz část 6.4). V inicializa ční části této úlohy jsou op ět definovány pot řebné prom ěnné a inicializovány synchroniza ční prost ředky, tj. binární semafor xADCSemaphore pro synchronizaci s A/D p řevodníkem a synchroniza ční objekt typu Mailbox s názvem xParMailbox pro p řípadné p ředávání parametr ů z nad řazené úlohy. Je t řeba definovat také pam ěť ovou oblast, kterou bude Mailbox využívat pro p řenos zpráv. Op ět jsou provedeny výpo čty LSB vstupního a výstupního signálu podle vztah ů, uvedených v části 8.3. Po inicializaci úloha vstupuje do hlavní smy čky, kde je nejprve zjišt ěn aktuální systémový čas (funkce chTimeNow() ) a následn ě je vypo čten čas následujícího spušt ění pomocí makra MS2ST() , které p řevádí čas v ms na po čet inkrementací systémových hodin. Jako parametr tohoto makra lze tedy p římo p ředat nastavenou hodnotu vzorkovací periody regulátoru v ms. Dále je spušt ěn p řevod pomocí funkce vrstvy HAL adcConvert() . Úloha následn ě čeká na semaforu xADCSemaphore pomocí funkce chBSemWaitTimeout() a je blokována, dokud není tento semafor nastaven. Po nastavení semaforu je z připravené globální prom ěnné vy čtena p řevedená hodnota. Tato hodnota je p řepo čtena na reálnou hodnotu vstupního signálu podle vztahu (8-3). Následuje kontrola zm ěny parametr ů pomocí funkce chMBFetch() s nastaveným krátkým časovým limitem a vlastní regula ční výpo čet. Ten je stejný jako v případ ě implementace v systému FreeRTOS. Stejný je i p řepo čet ak čního zásahu na binární hodnotu (vztah (8-4)). Odeslání této hodnoty k převodu D/A p řevodníkem na analogovou hodnotu je také shodné s implementací v systému FreeRTOS. Poté je úloha pozastavena pomocí funkce chThdSleepUntil() až do p říchodu další vzorkovací periody.

85 Obr. 8-3: Vývojový diagram úlohy pro PSD regulátor

START

inicializace

zjišt ění akt. času

spušt ění A/D převodu

čekání na p řevedená data (fronta - blokování)

přepo čet p řevedené binární hodnoty na reálnou hodnotu

kontrola parametr ů

regula ční výpo čet

přepo čet vypo čtené hodnoty ak čního zásahu na binární číslo

odeslání dat k D/A p řevodu

čekání na další periodu (blokování)

86 9 VYHODNOCENÍ VLASTNOSTÍ VYBRANÝCH OS REÁLNÉHO ČASU

Posledním bodem zadání je vyhodnocení vhodnosti vybraných opera čních systém ů reálného času pro realizaci embedded systém ů zahrnujících regula ční algoritmy. Toto vyhodnocení je možné provést z hlediska nabízených funkcí, vlastností a parametr ů, uvedených v dokumentaci vybraných opera čních systém ů, a také z hlediska praktické implementace t ěchto OS, tj. složitost vlastní implementace, vyžadované nástroje pro vývoj, použitelnost API rozhraní apod. Zde uvedené vyhodnocení bere v úvahu ob ě tato hlediska. P řed vlastním vyhodnocením budou popsány d ůležité požadavky na regula ční systémy využívající OS reálného času. Opera ční systém pro použití v regula čních systémech by m ěl disponovat deterministickým preemptivním plánova čem úloh se systémem nastavení priorit v četn ě možnosti m ěnit prioritu úloh za b ěhu systému. M ělo by být také umožn ěno nastavit několika úlohám stejnou prioritu a tyto úlohy spoušt ět po nastavitelných časových intervalech (Round-Robin). P řítomnost dalších funkcí jako dynamická tvorba a mazání úloh b ěhem činnosti již není nutná a ve v ětšin ě regula čních systém ů by tyto funkce byly pravd ěpodobn ě zbyte čné. Velmi vhodná je pak p řítomnost podpory hardwarových výpo čtů s plovoucí řádovou čárkou, tj. podpora jednotky FPU. P ři použití této jednotky lze mnohonásobn ě zvýšit rychlost regula čních výpo čtů. OS by m ěl nabízet r ůzné synchroniza ční a komunika ční prost ředky, které jsou velmi důležité pro zajišt ění správné činnosti řídicího systému. Z těchto prost ředk ů jsou pro řídicí systémy d ůležité zejména semafory a fronty pro p ředávání zpráv a dat. Semafory poskytují rychlou synchronizaci mezi úlohami a také mezi úlohami a obslužnými rutinami p řerušení, fronty lze výhodn ě použít pro p ředávání dat nap ř. p ři čtení převedené hodnoty z A/D p řevodníku v příslušné obslužné rutin ě. Velmi d ůležitým parametrem opera čního systému reálného času je doba p řepnutí kontextu. Tato doba spoluur čuje efektivitu celého systému. Pro realizaci embedded systém ů je obecn ě velmi d ůležitým parametrem OS jeho pam ěť ová náro čnost. Embedded systémy z důvodu požadavku na nízkou cenu a malé rozm ěry obvykle disponují omezeným množstvím pam ěti a to jak programové, tak datové pam ěti RAM. Je proto vhodné, aby použitý OS reálného času využíval tyto pam ěti v nejmenší možné mí ře. S tím je spojena také konfigurovatelnost systému, tj. možnost ur čení, které z nabízených funkcí budou ve výsledku zahrnuty a které nikoliv. Z hlediska implementace je vhodné, aby byla k použitému opera čnímu systému dostupná kvalitní a p řehledná dokumentace, což není zdaleka vždy spln ěno. Kvalitní a rychlou technickou podporu lze o čekávat pouze u komer čních systém ů, avšak její přítomnost alespo ň v podob ě diskusního fóra na internetu bývá p řítomna i u voln ě ši řitelných OS. Dalším požadavkem je p řehledný a dob ře okomentovaný zdrojový kód.

87 9.1 Vyhodnocení vlastností systému FreeRTOS

FreeRTOS je pravd ěpodobn ě nejpoužívan ějším voln ě ši řitelným opera čním systémem reálného času. Je ší řen pod upravenou licencí GNU GPL. Díky této úprav ě umož ňuje použití i v komer čních aplikacích bez nutnosti zve řejnit zdrojový kód za spln ění jistých podmínek. Nabízí preemptivní i kooperativní plánování úloh a koprogramy, neklade omezení týkající se po čtu úrovní priorit ani po čtu úloh se stejnou prioritou. Úlohy se stejnou prioritou jsou spoušt ěny pomocí algoritmu Round-Robin, jehož časové kvantum však nelze nastavit, resp. je shodné s dobou periody systémových hodin. To lze považovat za nedostatek. Priority úlohám lze dynamicky m ěnit a to jak práv ě b ěžící úloze, tak i úlohám, které aktuáln ě neb ěží. Podobn ě je možné úlohy také pozastavovat a blokovat. K dispozici je také množství dalších užite čných funkcí. Plánova č úloh je možné pozastavit. Z pohledu správy a plánování úloh je tedy systém FreeRTOS velmi dob ře vybavený a poskytuje dostatek funkcí. Základním synchroniza čním prost ředkem systému FreeRTOS jsou fronty. Data jsou frontami p řenášena pomocí kopií, což je intuitivní a flexibilní. Je možné pomocí front předávat také ukazatele na p ředávaná data a zvýšit tak efektivitu p ři p ředávání většího objemu dat. Použití front je velmi jednoduché. Na mechanismu front jsou pak založeny ostatní synchroniza ční prost ředky, tj. čítací a binární semafory a mutexy. Tyto synchroniza ční prost ředky, zejména fronty, jsou dle mého názoru pro použití v embedded regula čních systémech dostate čné. Vhodná je i p řítomnost funkcí softwarových časova čů . Systém dále nabízí p říznaky událostí. Sou částí distribuce systému jsou také čty ři r ůzné implementace správy pam ěti, od jednoduché, která nabízí pouze alokaci bez možnosti uvol ňování pam ěti, po složit ější správu pam ěti, která však již nezaru čuje deterministické chování. Je tedy možné zvolit takovou implementaci, která vyhovuje požadavk ům aplikace. Systém nabízí také podporu jednotky MPU pro mikrokontroléry s jádrem ARM Cortex-M3. Pro v ětšinu regula čních systém ů by m ěla být dosta čující nejjednodušší implementace a ani podpora MPU není z tohoto pohledu p říliš d ůležitá. Doba p řepnutí kontextu je v [38] udávána 84 strojových cykl ů p ři použití mikrokontroléru s jádrem ARM Cortex-M3 a p řeklada če Keil a s plnou optimalizací pro rychlost. P ři použití vyšších taktovacích frekvencí použitého mikrokontroléru by se tedy doba p řepnutí kontextu m ěla pohybovat nejvýše v jednotkách µs, což je, vzhledem k běžným vzorkovacím periodám v řádu desítek až stovek ms, pro v ětšinu regula čních systém ů naprosto dosta čující. V [38] je dále uvedena spot řeba pam ěti jádrem systému 236 B pam ěti RAM a 5 až 10 kB programové pam ěti pro architekturu ARM7. Tyto údaje jsou rovn ěž velmi p říznivé pro realizaci embedded systém ů. Opera ční systém FreeRTOS nabízí také pom ěrn ě široké možnosti konfigurace. Lze konfigurovat jak základní funkce systému (frekvence hodin, po čet úrovní priorit,

88 minimální velikost zásobníku), tak použití jednotlivých synchroniza čních funkcí, koprogram ů, časova čů a dalších funkcí. Systém tak lze nakonfigurovat podle požadavk ů aplikace, což je velmi vhodné. Dokumentace k systému FreeRTOS je k dispozici zdarma na internetových stránkách projektu, její p řehlednost však není p říliš vysoká a n ěkteré její části jsou zastaralé. Další možností je zakoupení dokumentace formou p říru čky. Samotný zdrojový kód systému je otev řený a dostupný, dob ře komentovaný a pom ěrn ě přehledný. Funkce API rozhraní jsou logicky pojmenovány a dodržují jednotnou konvenci. Implementace systému je pom ěrn ě snadná a v podstat ě veškeré problémy, které se b ěhem implementace objevily, byly zp ůsobeny jinými faktory. Za velmi d ůležitou vlastnost pro realizaci regula čních systém ů lze považovat podporu jednotky FPU pro mikrokontroléry s jádrem ARM Cortex-M4F. Výhodou může být také podpora velkého množství procesorových architektur. V sou časné dob ě je podporováno více než 30 architektur od tém ěř dvaceti r ůzných výrobc ů. Pro lad ění poskytuje systém FreeRTOS sadu trasovacích maker, která jsou volána při ur čitých systémových událostech, což poskytuje ú činný ladicí nástroj. Je také vhodné poznamenat, že systém FreeRTOS není opera čním systémem v pravém smyslu, protože nabízí v podstat ě pouze funkcionalitu jádra a žádn ě další funkce jako nap ř. vrstvu HAL nebo vestav ěný souborový systém. Z pohledu implementace regula čních embedded systém ů je však tato vlastnost spíše výhodou, protože v ětšina z těchto funkcí by s nejv ětší pravd ěpodobností nebyla použita a pouze by se snižovala p řehlednost a jednoduchost systému. Záv ěrem je možné prohlásit, že FreeRTOS je kvalitní a úsporný opera ční systém reálného času, vhodný z hlediska funkcí i implementace pro použití nejen v regula čních systémech, ale obecn ě v mnoha oblastech embedded systém ů.

9.2 Vyhodnocení vlastností systému ChibiOS/RT

Opera ční systém reálného času ChibiOS/RT je ší řen op ět pod upravenou licencí GNU GPL s výjimkou, která za ur čitých podmínek, v této výjimce uvedených, osvobozuje od nutnosti zve řejnit vytvo řený zdrojový kód. Systém ChibiOS/RT nabízí preemptivní plánova č úloh. Po čet úrovní priorit je omezen na 128, toto omezení by však ve v ětšin ě embedded systém ů nem ělo p řinášet žádné problémy. Je povoleno nastavení stejné priority více úlohám, úlohy se stejnou prioritou jsou pak spoušt ěny algoritmem Round-Robin s nastavitelným časovým kvantem. Tato vlastnost je výhodná, protože umož ňuje v ětší flexibilitu spoušt ění. Pokud je časové kvantum nastaveno nulové, lze docílit kooperativního módu. Za b ěhu je možné m ěnit prioritu pouze práv ě b ěžící úloze. Aktuáln ě b ěžící úlohu je možné pozastavit pop ř. ukon čit, lze také vyslat požadavek na ukon čení jiné úlohy. Systém nabízí dva typy úloh – úlohy statické, které jsou vytvo řeni p ři kompilaci, a úlohy

89 dynamické, které mohou být tvo řeny za b ěhu systému pomocí n ěkterého z aloka čních mechanism ů. Pro správu úloh a plánování poskytuje systém ChibiOS/RT dostatek funkcí. Pro synchronizaci a komunikaci nabízí opera ční systém ChibiOS/RT pom ěrn ě velké množství r ůzných prost ředk ů. Mezi tyto prost ředky pat ří čítací a binární semafory, mutexy, p říznaky událostí, synchronní a asynchronní zprávy, podmín ěné prom ěnné a fronty. Pro v ětšinu embedded systém ů v četn ě systém ů regula čních jsou jist ě nabízené prost ředky i jejich funkce více než dostate čné. Dále jsou nabízeny i funkce softwarových časova čů . Jádro systému využívá statickou alokaci pam ěti. Statická alokace je bezpe čná a deterministická a pro použití v regula čních systémech je tento zp ůsob dosta čující. Je však také možné využít volitelné mechanismy správy pam ěti, které umož ňují dynamickou alokaci v hald ě nebo pomocí mechanismu pam ěť ových blok ů o pevné velikosti. Systém ChibiOS/RT je deklarován jako velmi rychlý a kompaktní. Doba p řepnutí kontextu je p ři použití mikrokontroléru z rodiny STM32F4, taktovaném na 168 MHz a p ři použití p řekladače GCC je v [83] uvedena 0,40 µs. Pro ostatní architektury ARM se doba p řepnutí kontextu pohybuje již v jednotkách µs a nijak výrazn ě tedy nep řekonává konkurenci. Nicmén ě je tato doba dostate čná i pro realizaci rychlých regula čních systém ů. Velikost programové pam ěti požadovaná jádrem je podle [83] pom ěrn ě nízká a pohybuje od 5 do 10 kB, což je pro realizaci embedded systém ů výhodné. Systém zahrnuje krom ě vlastního jádra také další subsystémy, zejména vrstvu HAL, která poskytuje ovlada če pro množství standardních za řízení pro všechny podporované architektury, dále podporu vývojových desek v četn ě jejich inicializace a také možnost integrace nap ř. souborových systém ů. P řítomnost vrstvy HAL je výhodná, b ěhem implementace se však ukázalo, že tato vrstva neobsahuje ovlada č pro D/A p řevodník, což je pro realizaci regula čních systém ů podstatný nedostatek. Dodate čné dopln ění funkcí pro D/A p řevodník ze standardních ovlada čů ST Microelectronics s sebou přineslo komplikace a snížení p řehlednosti kódu. Jsou nabízeny rozsáhlé možnosti konfigurace. Samoz řejmostí je konfigurace frekvence systémových hodin, dále systém umož ňuje nastavení časového kvanta pro algoritmus Round-Robin, velikost pam ěti RAM p řid ělené systému, optimalizace pro rychlost, atd. Dále je možné vybírat jednotlivé synchroniza ční a ladicí prost ředky, vybírat které ovlada če vrstvy HAL budou použity v četn ě nastavení n ěkterých funkcí těchto ovlada čů . Je také možno konfigurovat použití r ůzných periferií, specifických pro konkrétní architekturu. Možnosti konfigurace systému jsou tedy výborné. Dokumentace je zdarma dostupná na internetových stránkách formou strukturovaného dokumentu, který je provázán s aktuálním zdrojovým kódem systému. Tato dokumentace je kvalitní a pom ěrn ě p řehledná. Na internetových stránkách projektu

90 je také řada článk ů týkajících se architektury systému, ale také obsahujících obecné informace z oblasti opera čních systém ů reálného času. Pro technickou podporu je k dispozici udržované diskusní fórum, kde lze nalézt velmi užite čné informace. Zdrojový kód je otev řený a dob ře komentovaný a pom ěrn ě p řehledný. Názvy funkcí jsou kv ůli použití p ředpony „ ch “ a také kv ůli zkracování v některých p řípadech nep řehledné. Na druhou stranu jsou díky použití p ředpony jasn ě odd ěleny funkce systému od uživatelských funkcí. K dispozici jsou rovn ěž ladicí funkce. Jsou to funkce pro trasování, kontrolu parametr ů a hlídání stavu systému. Je také k dispozici registr všech aktivních úloh v systému, který lze použít nejen pro ladicí ú čely. Velkou výhodou pro realizaci embedded systém ů zahrnujících regula ční výpo čty je podpora jednotky FPU pro architekturu ARM Cortex-M4F. Naopak nevýhodou je podpora jen omezeného množství procesorových architektur. V sou časné dob ě je podporováno pouze osm r ůzných architektur. Opera ční systém ChibiOS/RT je tedy zajímavou alternativou k ostatním OS reálného času. Je rychlý a kompaktní a také nabízí n ěkteré p řídavné funkce, zejména vrstvu HAL, která m ůže velmi usnadnit vývoj embedded systém ů. Pro aplikace, které tuto vrstvu využijí, jde o vhodnou volbu. Absence ovlada če pro D/A p řevodník však realizaci regula čního systému pon ěkud komplikuje a jist ě je možné pro tyto aplikace nalézt vhodn ější systém.

91 10 ZÁV ĚR

Tato diplomová práce se zabývala výb ěrem a implementací opera čních systém ů reálného času do výkonného mikrokontroléru s jádrem ARM Cortex-M4F a následnou implementací PSD regulátor ů s využitím t ěchto opera čních systém ů. Nejprve bylo provedeno seznámení s architekturou použitého mikrokontroléru STM32F407VGT6 výrobce ST Microelectronics. V krátkosti byla popsána architektura ARM a jádro Cortex-M4F, dále byla popsána systémová architektura použitého mikrokontroléru a také byly zdokumentovány d ůležité funkce a možnosti jeho vestav ěných A/D a D/A p řevodník ů. Byl proveden pr ůzkum opera čních systém ů reálného času, které nabízejí podporu mikrokontrolér ů z rodiny STM32 s jádrem ARM Cortex-M4F. B ěhem tohoto pr ůzkumu bylo p ři bližším zkoumání vlastností n ěkterých nalezených opera čních systém ů zjišt ěno, že je podporováno pouze jádro Cortex-M4, tj. varianta bez hardwarové jednotky FPU. Vzhledem ke skute čnosti, že pro regula ční systémy jsou jedním ze základních požadavk ů rychlé výpo čty s plovoucí řádovou čárkou, byl proto p ři vyhledávání opera čních systém ů kladen d ůraz na p římou podporu jednotky FPU. Tomuto požadavku vyhov ělo šest systém ů, které byly v práci uvedeny. Zde je t řeba poznamenat, že nebylo snahou vyhledat všechny systémy, vyhovující uvedenému požadavku, ale pouze nalézt několik opera čních systém ů s různými vlastnostmi. Pro další výb ěr byly v souladu se zadáním práce up řednostn ěny voln ě ši řitelné opera ční systémy. Následn ě byly zkoumány základní vlastnosti t ěchto opera čních systém ů a byla vyvinuta snaha tyto vlastnosti alespo ň stru čně zdokumentovat. Na základ ě tohoto pr ůzkumu pak bylo možné u činit další rozhodnutí ohledn ě výb ěru opera čních systém ů pro implementaci. Pro implementaci do použitého mikrokontroléru STM32F407VGT6 a následnou implementaci PSD regulátor ů byly vybrány systémy FreeRTOS a ChibiOS/RT. Opera ční systém FreeRTOS byl vybrán jako první, protože je profesionáln ě vyvíjený a ov ěř ený a nebyly tedy o čekávány žádné v ětší komplikace p ři jeho implementaci. Jako druhý opera ční systém byl vybrán systém ChibiOS/RT a to zejména díky nabízeným vlastnostem (krátká doba p řepnutí kontextu, vrstva HAL) a dále díky voln ě dostupné kvalitní a p řehledné dokumentaci. Po implementaci a otestování (zejména testování funk čnosti jednotky FPU) vybraných opera čních systém ů následovala vlastní implementace úloh pro PSD regulátory. Implementace PSD regulátoru v systému FreeRTOS byla podle o čekávání tém ěř bezproblémová, jediný závažn ější problém p ředstavovalo chybné nastavení priority přerušení A/D p řevodníku. Řešení tohoto problému bylo časov ě pom ěrn ě náro čné, nicmén ě úsp ěšné. Implementace PSD regulátoru v systému ChibiOS/RT pak p řinesla problém v podob ě absence ovlada če pro D/A p řevodník ve vrstv ě HAL. Proto byly využity

92 standardní ovlada če od výrobce mikrokontroléru ST Microelectronics. Jejich integrace do systému ChibiOS/RT byla pom ěrn ě snadná, avšak m ěla za následek jisté snížení přehlednosti a konzistence kódu. Ob ě implementace PSD regulátoru byly tedy úsp ěšn ě realizovány. Tyto implementace dovolují použití n ěkolika nezávislých regulátor ů, v případ ě, že každý regulátor má p řid ěleny vlastní p řevodníky. Žádanou hodnotu, stejn ě jako nastavitelné parametry regulátor ů je možné p ředávat z nad řazené úlohy. Jako rozší ření se nabízí implementace kompletního regulátoru, tj. v četn ě uživatelského rozhraní s možností p řepnout do režimu ru čního ovládání a také realizace beznárazového p řepínání mezi ru čním a automatickým režimem. Stávající implementaci by dále bylo možno doplnit o řídicí úlohu, která by spoušt ěla jednotlivé regulátory v daných časových okamžicích a dosáhnout tak realizace komplexního řídicího systému pro systém s několika stupni volnosti. Nakonec bylo provedeno vyhodnocení vlastností vybraných opera čních systém ů reálného času podle posledního bodu zadání. Nejprve byly uvedeny vlastnosti, které lze z hlediska realizace regula čních embedded systém ů o čekávat, pop ř. považovat za výhodné. Následn ě byly vlastnosti obou vybraných systém ů srovnány s těmito požadavky. P ři vyhodnocení byly krom ě t ěchto vlastností brány v úvahu také další aspekty, jako je kvalita dokumentace a složitost vlastní implementace.

93 Seznam literatury

[1] ARM. ARM Architecture Reference Manual [online]. Copyright © 1996-1998, 2000, 2004, 2005 ARM Limited, Issue I, July 2005 [cit 2013-12-20]. Dostupné z: https://www.scss.tcd.ie/John.Waldron/3d1/arm_arm.pdf [2] TIŠNOVSKÝ, Pavel. Pohled programátora na mikroprocesory ARM. In: ROOT.CZ [online]. 13. 3. 2012 [cit 2013-12-22]. Dostupné z: http://www.root.cz/clanky/pohled-programatora-na-mikroprocesory-arm/ [3] ARM. ARM Architecture Overview [online]. [cit 2013-12-25]. Dostupné z: http://web.eecs.umich.edu/~prabal/teaching/eecs373- f10/readings/ARM_Architecture_Overview.pdf [4] TIŠNOVSKÝ, Pavel. Mikroprocesory s architekturou ARM. In: ROOT.CZ [online]. 6. 3. 2012 [cit 2013-12-22]. Dostupné z: http://www.root.cz/clanky/mikroprocesory-s-architekturou-arm/ [5] TIŠNOVSKÝ, Pavel. Instruk ční sada Thumb-2 u mikroprocesor ů ARM. In: ROOT.CZ [online]. 10. 4. 2012 [cit 2013-12-22]. Dostupné z: http://www.root.cz/clanky/instrukcni-sada-thumb-2-u-mikroprocesoru-arm/ [6] ARM. ARM ®v7-M Architecture Reference Manual [online]. Copyright © 2006-2010 ARM Limited, Issue C_errata_v3, February 2010 [cit 2013-12-26]. Dostupné z: http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf [7] ARM. ARMv7-M Architecture Application Level Reference Manual [online]. Copyright © 2006-2007 ARM Limited, Issue B, August 2007 [cit 2013-12-26]. Dostupné z: http://www.pjrc.com/arm/pdf/doc/DDI0405B_arm_v7m_architecture_app_level_referenc e_manual.pdf [8] TIŠNOVSKÝ, Pavel. Norma IEEE 754 a p říbuzní: formáty plovoucí řádové te čky. In: ROOT.CZ [online]. 31. 5. 2006 [cit 2013-12-30]. Dostupné z: http://www.root.cz/clanky/norma-ieee-754-a-pribuzni-formaty-plovouci-radove-tecky/ [9] ARM. ARM ® Cortex ™-M4 Processor: Technical Reference Manual, Revision r0p1 [online]. Copyright © 2009, 2010, 2013 ARM Limited, Issue D, 11 June 2013 [cit 2013-12-22]. Dostupné z: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439d/DDI0439D_cortex_m4_proc essor_r0p1_trm.pdf [10] DOULOS. Getting started with CMSIS [online]. Copyright © 2009 by Doulos [cit 2013-12-23]. Dostupné z: http://www.doulos.com/knowhow/arm/CMSIS/

94 [11] ARM. CMSIS – Cortex Microcontroller Software Interface Standard. ARM.com [online]. © ARM Ltd. Copyright 2013 [cit 2013-12-23]. Dostupné z: http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software- interface-standard.php [12] ST MICROELECTRONICS. STM32F405xx, STM32F407xx [online datový list]. © 2013 STMicroelectronics, Rev 4, June 2013 [cit 2013-12-23]. Dostupné z: http://www.st.com/st-web- ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf [13] ST MICROELECTRONICS. RM0090 Reference manual [online]. © 2013 STMicroelectronics, Rev 5, September 2013 [cit 2013-12-23]. Dostupné z: http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020. pdf [14] ST MICROELECTRONICS. UM1472 User Manual: STM32F4DISCOVERY STM32F4 high-performance discovery board . © 2012 ST Microelectronics, Rev 2, January 2012 [cit 2013-12-30]. [15] ST MICROELECTRONICS. LIS302DL [online datový list]. © 2008 STMicroelectronics, Rev 4, October 2008 [cit 2013-12-30]. Dostupné z: http://www.st.com/st-web- ui/static/active/en/resource/technical/document/datasheet/CD00135460.pdf [16] ST MICROELECTRONICS. MP45DT02 [online datový list]. © 2012 STMicroelectronisc, Rev 5, July 2012 [cit 2013-12-30]. Dostupné z: http://www.st.com/st-web- ui/static/active/en/resource/technical/document/datasheet/DM00025467.pdf [17] CIRRUS LOGIC. CS43L22 [online datový list]. Copyright © Cirrus Logic, Inc. 2010, Revision F2, MARCH 2010 [cit 2013-12-30]. Dostupné z: http://www.cirrus.com/en/pubs/proDatasheet/CS43L22_F2.pdf [18] KU ČERA, Pavel. Opera ční systémy reálného času: Úvod [online prezentace]. MRTS/NRTS 2013-2014 [cit 2014-1-5]. Dostupné z: http://taceo.eu/mrts.php [19] DI SIRIO, Giovanni. RTOS Concepts. ChibiOS/RT free embedded RTOS [online]. [cit 2014-1-5]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:rtos_concepts [20] REAL TIME ENGINEERS. FreeRTOS. Freertos.org [online]. [cit 14-5-15]. Dostupné z: http://www.freertos.org/index.html [21] NUTTX. NuttX Real-Time Operating System. NuttX Real-Time Operating System [online]. [cit 2014-5-15]. Dostupné z: http://nuttx.org/

95 [22] MICRIUM. µC/OS-II Overview. Micrium [online]. [cit 2014-5-15]. Dostupné z: http://micrium.com/rtos/ucosii/overview/ [23] MICRO DIGITAL. SMX® RTOS. Micro digital [online]. [cit 2014-5-15]. Dostupné z: http://www.smxrtos.com/rtos/ [24] DI SIRIO, Giovanni. ChibiOS/RT Homepage. ChibiOS/RT free embedded RTOS [online]. [cit 2014-5-15]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php [25] ECOS. Home Page. eCos [online]. [cit 2014-5-15]. Dostupné z: http://ecos.sourceware.org/ [26] NUTTX. About. NuttX Real-Time Operating System [online]. [cit 2014-5-15]. Dostupné z: http://nuttx.org/doku.php?id=documentation:about [27] ARPACI-DUSSEAU, Remzi H., Andrea C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces: 7 Scheduling: Introduction [online]. [cit 2014-5-15]. Dostupné z: http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf [28] NUTTX. Supported Platforms. NuttX Real-Time Operating System [online]. [cit 2014-5-15]. Dostupné z: http://nuttx.org/Documentation/NuttX.html#platforms [29] MICRIUM. µC/OS-II Specifications. Micrium [online]. [cit 2014-5-15]. Dostupné z: http://micrium.com/rtos/ucosii/specifications/ [30] MICRIUM. µC/OS-II Ports. Micrium [online]. [cit 2014-5-15]. Dostupné z: http://micrium.com/rtos/ucosii/ports/ [31] MICRIUM. µC/OS-II Documentation Home. Micrium Doc [online]. [cit 2014-5-15]. Dostupné z: https://doc.micrium.com/pages/viewpage.action?pageId=10753158 [32] ECOS. About eCos. eCos [online]. [cit 2014-5-15]. Dostupné z: http://ecos.sourceware.org/about.html [33] MASSA, Anthony J. Embedded Software Development with eCos ™ [online]. Upper Saddle River: Prentice Hall Professional Technical Reference, 2003. [cit 2014-5-15]. Dostupné z: http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/perens/0130354732.pdf [34] ITRON. Micro-ITRON4.0 Specification. ITRON [online]. [cit 2014-5-15]. Dostupné z: http://www.ertl.jp/ITRON/SPEC/mitron4-e.html [35] ECOS. SMP Support. eCos Reference Manual [online]. [cit 2014-5-15]. Dostupné z: http://ecos.sourceware.org/docs-3.0/ref/kernel-smp.html [36] ECOS. eCos Reference Manual. eCos Reference Manual [online]. [cit 2014-5-15]. Dostupné z: http://ecos.sourceware.org/docs-3.0/ref/ecos-ref.html [37] REAL TIME ENGINEERS. About FreeRTOS. Freertos.org [online]. [cit 2014-3-11]. Dostupné z: http://www.freertos.org/RTOS.html

96 [38] REAL TIME ENGINEERS. FreeRTOS FAQ – Memory Usage, Boot Times & Context Switch Times. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/FAQMem.html [39] REAL TIME ENGINEERS. Features Overview. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/FreeRTOS_Features.html [40] REAL TIME ENGINEERS. Software Timers. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/RTOS-software-timer.html [41] REAL TIME ENGINEERS. Event Bits (or flags) and Event Groups. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/FreeRTOS-Event-Groups.html [42] REAL TIME ENGINEERS. Trace Hook Macros. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/rtos-trace-macros.html [43] REAL TIME ENGINEERS. Stack Usage and Stack Overflow Checking. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/Stacks-and-stack-overflow-checking.html [44] REAL TIME ENGINEERS. Android, FreeRTOS top EE Times’ 2013 embedded.survey. EE Times [online]. [cit 2014-3-14]. Dostupné z: http://www.eetimes.com/document.asp?doc_id=1263083 [45] REAL TIME ENGINEERS. License Details. Freertos.org [online]. [cit 2014-3-14]. Dostupné z: http://www.freertos.org/a00114.html [46] HIGH INTEGRITY SYSTEMS. SAFERTOS, the first RTOS pre-certified to IEC 61508. SAFERTOS [online]. [cit 2014-3-14]. Dostupné z: http://www.highintegritysystems.com/safertos/ [47] HIGH INTEGRITY SYSTEMS. Certification and Standards of our Safety Critical RTOS, SAFERTOS. SAFERTOS [online]. [cit 2014-3-14]. Dostupné z: http://www.highintegritysystems.com/safertos/certification-and-standards/ [48] REAL TIME ENGINEERS. Official FreeRTOS Ports. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/RTOS_ports.html [49] REAL TIME ENGINEERS. FreeRTOS Windows Simulator. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/FreeRTOS-Windows-Simulator- Emulator-for-Visual-Studio-and-Eclipse-MingW.html [50] REAL TIME ENGINEERS. FreeRTOS Ports. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/a00090.html [51] REAL TIME ENGINEERS. RTOS Source Code Download Instructions. Freertos.org [online].[cit 2014-3-28]. Dostupné z: http://www.freertos.org/a00104.html

97 [52] REAL TIME ENGINEERS. FreeRTOS+ Ecosystem Showcase. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/FreeRTOS-Plus/index.shtml [53] REAL TIME ENGINEERS. Source Organization. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/a00017.html [54] REAL TIME ENGINEERS. Customisation. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/a00110.html [55] GOYETTE, Rich. An Analysis and Description of the Inner Workings of the FreeRTOS Kernel [online]. 1 April 07 [cit 2014-3-16]. Dostupné z: http://www.mikrocontroller.net/attachment/95930/FreeRTOSPaper.pdf [56] SOURCEFORGE. FreeRTOS Real Time Kernel (RTOS). SourceForge.net [online]. [cit 2014-3-16]. Dostupné z: http://sourceforge.net/projects/freertos/files/FreeRTOS/ [57] D’SOUZA Deepak. Free RTOS Implementation [online prezentace]. 23 August 2011 [cit 2014-3-16]. Dostupné z: http://drona.csa.iisc.ernet.in/~deepakd/ukieri/ictac-school/RTOS-implementation.pdf [58] REAL TIME ENGINEERS. History.txt. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/History.txt [59] REAL TIME ENGINEERS. Tasks. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/RTOS-task-states.html [60] MELOT, Nicolas. Study of an operating system: FreeRTOS [online]. [cit 2014-3-16]. Dostupné z: http://wiki.csie.ncku.edu.tw/embedded/FreeRTOS_Melot.pdf [61] REAL TIME ENGINEERS. vTaskSetApplicationTaskTag. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/vTaskSetApplicationTag.html [62] REAL TIME ENGINEERS. xTaskGetApplicationTaskTag. Freertos.org [online]. [cit 2014-3-16]. Dostupné z: http://www.freertos.org/xTaskGetApplicationTaskTag.html [63] SOURCEWARE. The Newlib Homepage. sourceware.org [online]. [cit 2014-3-16]. Dostupné z: http://sourceware.org/newlib/ [64] EMBEDDED. Embedding with GNU: Newlib. Embedded [online]. [cit 2014-3-16]. Dostupné z: http://www.embedded.com/design/prototyping-and- development/4024867/Embedding-with-GNU-Newlib [65] EMBEDDED. Embedding GNU: Newlib, Part 2. Embedded [online]. [cit 2014-3-16]. Dostupné z: http://www.embedded.com/electronics-blogs/industry- comment/4023922/Embedding-GNU-Newlib-Part-2 [66] KRZYZANOWSKI, Paul. Process Scheduling [online]. February 19, 2014 [cit 2014-03-21]. Dostupné z: http://www.cs.rutgers.edu/~pxk/416/notes/07-scheduling.html

98 [67] MAJ, Cezary. FreeRTOS – API [online]. [cit 2014-3-21]. Dostupné z: http://fiona.dmcs.pl/~cmaj/ARM/FreeRTOS%20API.pdf [68] REAL TIME ENGINEERS. FreeRTOS Queues. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/Embedded-RTOS-Queues.html [69] REAL TIME ENGINEERS. FreeRTOS BinarySemaphores. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/Embedded-RTOS-Binary-Semaphores.html [70] REAL TIME ENGINEERS. FreeRTOS Counting Semaphores. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/Real-time-embedded-RTOS-Counting-Semaphores.html [71] REAL TIME ENGINEERS. FreeRTOS Mutexes. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/Real-time-embedded-RTOS-mutexes.html [72] REAL TIME ENGINEERS. FreeRTOS Recursive Mutexes. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/RTOS-Recursive-Mutexes.html [73] REAL TIME ENGINEERS. Software Timers. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/RTOS-software-timer.html [74] REAL TIME ENGINEERS. The timer service/daemon task, and the timer command queue. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/RTOS-software-timer-service-daemon-task.html [75] REAL TIME ENGINEERS. One-shot timers versus auto-reload timers. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/One-shot-Vs-auto-reload-real-time-software-timers.html [76] REAL TIME ENGINEERS. Resetting a software timer. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/Resetting-an-RTOS-software-timer.html [77] REAL TIME ENGINEERS. Memory Management. Freertos.org [online]. [cit 2014-3-21]. Dostupné z: http://www.freertos.org/a00111.html [78] LASZLO, Zoltan. Memory Allocation in VxWorks 6.0 [online]. Copyright © 2005 Wind River Systems, Inc [cit 2014-3-21]. Dostupné z: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9869&rep=rep1&type=pdf [79] REAL TIME ENGINEERS. Memory Protection Unit (MPU) Support. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html

99 [80] REAL TIME ENGINEERS. Tasks and Co-routines. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/taskandcr.html [81] REAL TIME ENGINEERS. Co-routines. Freertos.org [online]. [cit 2014-3-28]. Dostupné z: http://www.freertos.org/croutine.html [82] DI SIRIO, Giovanni. Performance Data. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-4]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:metrics [83] DI SIRIO, Giovanni. Supported Architectures. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-4]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:architectures [84] DI SIRIO, Giovanni. ChibiOS/RT Brief Introduction. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-4]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:documents:introduction [85] MIGLIAVACCA, Martino. Embedded Systems RTOS: The ChibiOS/RT Project [online prezentace]. November 18, 2011 [cit 2014-4-4]. Dostupné z: http://home.deib.polimi.it/bellasi/lib/exe/fetch.php?media=teaching:2012:rtos_chibios_ha ndout.pdf [86] DI SIRIO, Giovanni. ChibiOS background and history. ChibiOS/RT RTOS [online forum]. Jun 15, 2012 [cit 2014-4-4]. Dostupné z: http://forum.chibios.org/phpbb/viewtopic.php?f=2&t=481 [87] DI SIRIO, Giovanni. License. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-4]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:license [88] DI SIRIO, Giovanni. Features Matrix. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-5]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:matrix [89] DI SIRIO, Giovanni. ChibiOS/RT General Architecture. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-15]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:documents:architecture [90] DI SIRIO, Giovanni. Threads. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group__threads.html [91] DI SIRIO, Giovanni. Streams and Files. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group__streams.html [92] DI SIRIO, Giovanni. Debug. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group__debug.html [93] DI SIRIO, Giovanni. Registry. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group__registry.html

100 [94] DI SIRIO, Giovanni. HAL. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group___i_o.html [95] DI SIRIO, Giovanni. Downloads. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-5]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:download [96] DI SIRIO, Giovanni. Various. ChibiOS/RT [online]. [cit 2014-4-5]. Dostupné z: http://chibios.sourceforge.net/html/group__various.html [97] DI SIRIO, Giovanni. Configuration: Kernel. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group__config.html [98] DI SIRIO, Giovanni. Configuration: HAL. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/group___h_a_l___c_o_n_f.html [99] DI SIRIO, Giovanni. How to create a thread. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-5]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:howtos:createthread [100] FENG, Lu. ChibiOS Essential: Introdiction to ChibiOS kernel functions, ver 1.0 [online]. [cit 2014-4-5]. Dostupné z: http://www.jacobfeng.com/wp-content/uploads/2013/05/chibios_essential.pdf [101] DI SIRIO, Giovanni. Kernel Concepts. ChibiOS/RT [online]. [cit 2014-4-15]. Dostupné z: http://chibios.sourceforge.net/html/concepts.html [102] DI SIRIO, Giovanni. Priority Levels. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-5]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:kb:priority [103] DI SIRIO, Giovanni. Counting Semaphores. ChibiOS/RT [online]. [cit 2014-4-7]. Dostupné z: http://chibios.sourceforge.net/html/group__semaphores.html [104] DI SIRIO, Giovanni. Counting Semaphores, Binary Semaphores and Mutexes explained. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-7]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:semaphores_mutexes [105] DI SIRIO, Giovanni. Binary Semaphores. ChibiOS/RT [online]. [cit 2014-4-7]. Dostupné z: http://chibios.sourceforge.net/html/group__binary__semaphores.html [106] DI SIRIO, Giovanni. Mutexes. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__mutexes.html [107] DI SIRIO, Giovanni. Condition Variables. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__condvars.html

101 [108] ARPACI-DUSSEAU, Remzi H., Andrea C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces: 30 Condition Variables [online]. [cit 2014-4-8]. Dostupné z: http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf [109] DI SIRIO, Giovanni. Event Flags. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__events.html [110] DI SIRIO, Giovanni. Events Explained. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-8]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:kb:events [111] DI SIRIO, Giovanni. Synchronous Messages. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__messages.html [112] DI SIRIO, Giovanni. Mailboxes. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__mailboxes.html [113] DI SIRIO, Giovanni. I/O Queues. ChibiOS/RT [online]. [cit 2014-4-8]. Dostupné z: http://chibios.sourceforge.net/html/group__io__queues.html [114] DI SIRIO, Giovanni. How to manage memory. ChibiOS/RT free embedded RTOS [online]. [cit 2014-4-10]. Dostupné z: http://www.chibios.org/dokuwiki/doku.php?id=chibios:howtos:manage_memory [115] DI SIRIO, Giovanni. Core Memory Manager. ChibiOS/RT [online]. [cit 2014-4-11]. Dostupné z: http://chibios.sourceforge.net/html/group__memcore.html [116] DI SIRIO, Giovanni. Heaps. ChibiOS/RT [online]. [cit 2014-4-11]. Dostupné z: http://chibios.sourceforge.net/html/group__heaps.html [117] DI SIRIO, Giovanni. Memory Pools. ChibiOS/RT [online]. [cit 2014-4-11]. Dostupné z: http://chibios.sourceforge.net/html/group__pools.html [118] BALÁT Ě, Jaroslav. Automatické řízení . 1. vydání. Praha: BEN – technická literatura, 2003. ISBN 80-7300-020-2. [119] PIVO ŇKA, Petr. Číslicová řídicí technika . Brno: FEKT VUT v Brn ě, 2003. [120] HLAVA, Jaroslav. PID regulátory – jejich vlastnosti, modifikace a číslicová implementace [online prezentace]. [cit 2014-5-15]. Dostupné z: http://www.fm.tul.cz/esf0247/index.php?download=822 [121] CASPI, Paul, Oded Maler. From Control Loops to Real-Time Programs [online]. [cit 2014-5-15]. Dostupné z: http://www-verimag.imag.fr/~maler/Papers/caspimaler.pdf [122] ZEZULKA, F., J. PÁSEK, M. FINDURA, V. BRAUN, J. PRE ČAN: Automatizace proces ů. Brno: FEKT VUT v Brn ě, 2012.

102 [123] LIU, C. L., James W. Layland. Scheduling Algorithms for Multiprogramming in Hard- Real-Time Environment. Journal of the Association for Computing Machinery, Vol 20, No. 1, January 1973 . [cit 2014-5-15]. [124] GCC ARM EMBEDDED MAINTAINERS. GNU Tools for ARM Embedded Processors. Launchpad [online]. [cit 2014-5-15]. Dostupné z: https://launchpad.net/gcc-arm-embedded [125] SOURCEFORGE. WinAVR. SourceForge.net [online]. [cit 2014-5-15]. Dostupné z: http://sourceforge.net/projects/winavr/ [126] HERBERT, Jeremy. Getting Started with the STM32F4 and GCC [online]. [cit 2014-5-15]. Dostupné z: http://jeremyherbert.net/get/stm32f4_getting_started [127] LEBEDA, Martin. Cygwin – Unix ve Windows. In: ROOT.CZ [online]. 24. 1. 2005 [cit 2014-5-22]. Dostupné z: http://www.root.cz/clanky/cygwin-unix-ve-windows/ [128] VELEBA, Václav. Číslicová řídicí technika: Po číta čová cvi čení. Brno FEKT VUT v Brn ě 2005. [cit 2014-5-15]. [129] DI SIRIO, Giovanni. ADC Driver. ChibiOS/RT [online]. [cit 2014-5-15]. Dostupné z: http://chibios.sourceforge.net/html/group___a_d_c.html

103 Seznam zkratek a symbol ů

ZKRATKY

A/D Analogov ě/digitální AHB Advanced High-performance Bus ALU Arithmetic an Logic Unit API Application Programming Interface ARM Advanced RISC Machine CAN Controller Area Network CCM Core Coupled Memory CLI Command Line Interface CMOS Complementary Metal Oxide Semiconductor CMSIS Cortex Microcontroller Software Interface Standard CPSR Current Program Status Register CPU Central Processing Unit CRC Cyclic Redundancy Check D/A Digitáln ě/Analogový dBSPL dB Sound Pressure Level DMA Direct Memory Access DSP Digital Signal Processing EDF Earliest Deadline First FAT File Allocation Table FCFS First Come, First Served FIFO First In, First Out FPU Floating Point Unit FSMC Flexible Static Memory Controller GNU GNU’s Not Unix GPIO General Purpose Input/Output HAL Hardware Abstraction Layer I2C Inter-Integrated Circuit I2S Inter-IC Sound ICMP Internet Control Message Protocol IDE Integrated Development Environment LCD Liquid Crystal Display LED Light Emitting Diode LR Link Register LSB Least Significant Bit/Byte LQFP Low profile Quad Flat Package MAC Multiply and Accumulate MEMS Micro Electro-Mechanical Systems MMU Memory Management Unit MPU Memory Protection Unit Msps Mega Samples Per Second

104 PC Program Counter, Personal Computer PID Proporcionáln ě-Integra čně-Deriva ční POSIX Portable Operating System Interface PSD Proporcionáln ě-Suma čně-Diferen ční PWM Pulse Width Modulation RISC Reduced Instruction Set Computer RMA Rate-Monotonic Algorithm RTC Real-Time Clock RTOS Real-Time Operating System SDIO/MMC Secure Digital Input/Output / Multi-Media Card SIMD Single Instruction, Multiple Data SMP Symmetric Multiprocessing SP Stack Pointer SPI Serial Peripheral Interface SPSR Saved Program Status Register SRAM Static Random Access Memory SWD Serial Wire Debug TCB Task Control Block TCP/IP Transmission Control Protocol/Internet Protocol UART Universal Asynchronous Receiver/Transmitter UDP User Datagram Protocol USART Universal Synchronous/Asynchronous Receiver/Transmitter USB Universal Serial Bus USB OTG USB On-The-Go WCET Worst Case Execution Time

SYMBOLY

(te ) regula ční odchylka ve spojitém čase (kTe ) regula ční odchylka v diskrétním čase K proporcionální zesílení regulátoru T perioda vzorkování, pop ř. základní perioda systému regulátor ů

TD deriva ční časová konstanta

TI integra ční časová konstanta (tu ) ak ční zásah ve spojitém čase (kTu ) ak ční zásah v diskrétním čase ∇ (kTu ) přír ůstek ak čního zásahu v diskrétním čase (tw ) žádaná hodnota ve spojitém čase (ty ) výstupní veli čina ve spojitém čase

ci ozna čení i -tého regulátoru, pop ř. obecn ě úlohy RTOS

Ci doba WCET i -tého regulátoru, pop ř. obecn ě periodické úlohy RTOS P super-perioda systému regulátor ů

105