Bakalářská práce
Doporučení pro volbu „real-time“ operačního systému pro 8-bitové mikrořadiče vypracoval: Radek Měšťan vedoucí práce: Ing. Pavel Houška, Ph.D. obor: Aplikovaná informatika a řízení 2006
Anotace: Práce se v úvodní části zabývá typy real time operačních systémů, jejich základní rozdělení a vlastnosti operačních systémů. Definují se zde klíčové požadavky, které jsou kladeny na RTOS. V další části jsou stanovena kritéria hodnocení pro volbu operačního systému. Dále je rozebráno jádro operačního systému, jeho funkce, požadavky, zabezpečení apod. Jsou zde uvedeny licenční podmínky pro operační systémy. V další části jsou popsány složitější operační systémy s vyššími nároky na zdroje počítače, pak jednoduché operační systémy pro malé mikrořadiče. Závěr práce je věnován vlastní volbě operačního systému.
Anotation: The first part of this bachelor work was focused on various types of real time operating systems, their basic dividing and operating systems´ properties. Key requirements imposed on RTOS are defined here, too. In the other part of the bachelor work rating criterias for a choice of operating systems are determined. Furthermore a core of operating system, its functions, requirements and security are analyzed in my work. Licence conditions are described here as well. In the next part there are complicated operating systems with higher requirements of PC source demonstrated, together with simple operating systems for small microcontrollers. The end of my dissertation work is applied to my own choice of operating system.
Poděkování Rád bych poděkoval vedoucímu své bakalářské práce Ing. Pavlu Houškovi, Ph.D. za pomoc a rady, které mi poskytoval v průběhu psaní této práce.
Obsah Obsah.......................................................................................................................................... 1 1
Úvod ................................................................................................................................... 3
2
Real-time operační systém ................................................................................................. 4
3
2.1
Vestavné systémy....................................................................................................... 4
2.2
Typy real-time systémů .............................................................................................. 4
Základní rozdělení a vlastnosti operačních systémů .......................................................... 5 3.1
Multitasking ............................................................................................................... 5
3.1.1
Kooperativní multitasking.................................................................................. 5
3.1.2
Preemptivní multitasking ................................................................................... 5
3.2
Multithreading............................................................................................................ 6
3.2.1
Procesy ............................................................................................................... 6
3.2.2
Vlákno ................................................................................................................ 6
3.3
Plánování úloh............................................................................................................ 6
3.4
Přepínání úloh ............................................................................................................ 7
3.5
Mezní časové zpoždění (latence) – deadline.............................................................. 7
3.6
Garbage collection...................................................................................................... 7
3.7
Dynamické přidělování paměti .................................................................................. 8
4
Důležité vlastnosti při výběru RTOS ............................................................................... 10
5
Realizace RTOS ............................................................................................................... 11 5.1
Kernel ....................................................................................................................... 11
5.2
Meziprocesová komunikace a Synchronizace.......................................................... 12
5.2.1
File descriptors ................................................................................................. 12
5.2.2
Semafory .......................................................................................................... 12
5.2.3
Mutexy ............................................................................................................. 12
5.2.4
Kritické sekce................................................................................................... 13
5.3
Dědičnost priorit....................................................................................................... 13
5.4
Přepínání procesů ..................................................................................................... 13
6
Zabezpečení operačních systémů ..................................................................................... 14
7
Licenční podmínky pro Operační Systémy...................................................................... 16 7.1
Projekt GNU............................................................................................................. 16
1
8
9
7.1.1
GNU GPL (General Public Licence) v. 2 ........................................................ 16
7.1.2
GNU Lesser General Public License v. 2.1 ..................................................... 16
7.1.3
GNU Free Documentation License v. 1.2 ........................................................ 16
Real-Time Operační Systémy (RTOS) ............................................................................ 17 8.1
Linux ........................................................................................................................ 17
8.2
RTLinux ................................................................................................................... 19
8.3
RTAI/fusion ............................................................................................................. 19
8.4
MS Windows............................................................................................................ 19
8.5
Přehled RTOS pro 8-bitové mikrokontroléry........................................................... 23
8.5.1
eXtreme Minimal Kernel - XMK..................................................................... 23
8.5.2
Pico]OS ............................................................................................................ 23
8.5.3
FreeRTOS......................................................................................................... 24
8.5.4
embOS.............................................................................................................. 24
8.5.5
Salvo OS........................................................................................................... 25
8.5.6
CMX-TINY™ .................................................................................................. 26
Volba RTOS pro potřeby laboratoří prostředků automatického řízení ............................ 27 Typy úloh řešené laboratoří...................................................................................... 27
9.1 9.1.1
Konstrukce inteligentních snímačů .................................................................. 27
9.1.2
Konstrukce inteligentních aktuátorů ................................................................ 27
9.1.3
Konstrukce řídicích systémů ............................................................................ 27
9.1.4
Používané architektury mikrořadičů ................................................................ 28
9.2 10
Kritéria výběru RTOS .............................................................................................. 28 Volba operačního systému ........................................................................................... 29
Přehled RTOS splňujících kritéria výběru ....................................................................... 29 11
Závěr............................................................................................................................. 30
12
Literatura ...................................................................................................................... 31
13
Slovník pojmů .............................................................................................................. 32
2
1
Úvod
Práce se zabývá analýzou existujících „real-time“ operačních systémů a stanovením kritérií pro jejich hodnocení. V první části práce je proveden základní rozbor vlastností a požadavků, podle kterých se budou posuzovat vlastnosti „real-time“ operačních systémů. Počítač bez operačního software je velmi drahá „hromada“ kovu, plastu a křemíku. Počítač se skládá z procesoru, operační paměti, úložiště a vstupně/výstupních zařízení (z angličtiny I/O) jako jsou například klávesnice, monitory a ovladače. Operační systém (OS) je software nebo firmware, který má kontrolu nad všemi komponenty. Při vytváření programu obvykle neznáme fyzické vrstvy každého počítače. Pokud i přesto víme, jak bude počítač vypadat, zcela určitě nebudeme zjišťovat, jakým způsobem se například budou zapisovat data na pevný disk. Funkce operačního systému je zajistit komunikaci s hardware na nízké úrovni (low-level). Operační systém vytváří vrstvu, která odděluje programy (aplikace) od hardware. Na počítači z pohledu uživatele by mělo jít spustit současně více programů. Procesor však není schopen obsloužit dva programy současně. OS nejprve vybere jeden program, který zpracuje a poté si vezme další program. Tato vlastnost se nazývá „multitasking“ a je popsána v kapitole 4.1. Existuje mnoho různorodých operačních systémů např. Microsoft Windows, Mac OS, Linux pro desktopové PC, Symbian OS, Palm OS, Windows CE, FreeRTOS, extreme Minimal Kernel (XMK), VxWorks pro vestavné systémy a mobilní zařízení. A právě jejich volbou se tato práce zabývá. Real-timové operační systémy mají uplatnění tam, kde je vyžadována okamžitá odezva na vzniklé podněty. Využívá se jich v širokém spektru odvětví, např. v průmyslu, dopravě, elektrárnách, apod. V současnosti jsou implementovány na různých platformách a úrovních hardwaru od mikrokontroléru přes průmyslové automaty až po osobní a specializované počítače pro různé účely. Existuje mnoho operačních systémů, které v reálném čase nepracují (Non-RTOS). Ty mohou poskytovat podobné služby jako RTOS, avšak je to patrné pouze na první pohled. Při bližším zkoumání nacházíme zásadní rozdíly. Real-Time OS musí být deterministický, to znamená, že úlohy jsou naplánovány a zpracovány v definovatelném čase. RTOS musí včas reagovat na nepředvídatelné podněty. Aby byl systém schopen předvídatelně reagovat, musí být pečlivě zvoleny všechny komponenty hardware i software. Chybně navržený systém i se špičkovým hardware a software vede k nefunkčnosti celého systému a ohrožení lidských životů a majetku.
3
2
Real-time operační systém
V dnešní technicky vyspělé době počítačů a komunikačních technologií jsou vyvinuty nové architektury pro real-time systémy, které kladou důraz na spolehlivost, rozšiřitelnost, univerzálnost a na jednotnost celého systému. Díky jednotnému systému jsou nižší náklady na údržbu a přijetí nového hardware a software.
2.1
Vestavné systémy
Vestavné zařízení je počítačový systém, který je zabudován uvnitř stroje, elektrického spotřebiče, elektronického systému nebo jen za účelem oddělení citlivých částí od okolí z důvodu rušení, apod. Mezi nejtypičtější oblasti použití vestavných systémů patří například: automobilový průmysl (řízení dodávky paliva, anti-block-systém, air-bag), v domácnosti (televize, pračky, atd.), telekomunikace, senzorika, průmyslové regulátory, apod. Vestavné systémy lze charakterizovat ze dvou různých úhlů pohledu. Uživatele nezajímá co je uvnitř, ale jsou pro něj důležité užitné vlastnosti jako je spolehlivost a cena. Naopak pro konstruktéry a výrobce je klíčová metodika vývoje, dostupnost součástek, požadavky na přístrojové vybavení apod. Z pohledu uživatele lze vestavné systémy charakterizovat: − navrženy pouze pro jednoúčelovou aplikaci − předem dané požadavky (rozměry, výkon, odolnost, apod.) − schopnost reagovat na vzniklé podněty v reálném čase (RTOS) Z pohledu vývojáře se vestavné systémy jeví jako systémy, kde je: − hardware i software vyvíjen souběžně − výběr z mnoha procesorů a operačních systémů − menší množství systémových zdrojů − robustní HW i SW (odolný proti vnějším poruchám, rušení, apod.)
2.2
Typy real-time systémů
Ve vestavných systémech není nutné dosáhnout předvídatelného chování, tento systém nelze považovat za real-timeový a jeho případné využití je v méně náročných aplikacích. Real time OS lze rozdělit na následující typy: − hard real-time - při překročení vymezeného časového úseku nastává selhání celého zařízení, jsou ohroženy lidské životy i majetek, na systém jsou kladeny maximální požadavky − soft real-time - časový úsek může být překročen, zařízení lze i nadále provozovat, dochází ke snížení kvality, nehrozí žádné ohrožení osob a majetku − non real-time - nejsou požadovány konečné časy pro splnění úlohy, hlavní smysl spočívá v provedení úlohy v průměrném čase (např. osobní počítače)
4
3
Základní rozdělení a vlastnosti operačních systémů
3.1
Multitasking
Multitasking je technika používaná pro běh více nezávislých procesů jedním procesorem. 3.1.1
Kooperativní multitasking
Výpočetní čas procesoru je přidělen jednomu programu na dobu jeho běhu. Po ukončení programu je procesor vrácen operačnímu systému. Ten ho pak přidělí jinému programu. Tato metoda má nevýhodu, že program nemusí procesor vrátit v dostatečně krátkém časovém úseku, což způsobí dojem, že ostatní programy nepracují. Ještě horší případ nastane ve chvíli, kdy program procesor nevrátí vůbec (např. zhavaruje). Tato situace vede ve většině případů k havárii celého systému. 3.1.2
Preemptivní multitasking
Výpočetní čas procesoru je přidělen programu pouze na určitou dobu a po jeho uplynutí je úloha pozastavena a operační systém přidělí výpočetní čas jinému programu. Z toho vyplývá, že nemohou nastat stavy uvedené u kooperativního multitaskingu. Nevýhodou tohoto řešení je vyšší náročnost na hardware počítače. Výhody: − umožňuje kdykoli přejít k jinému programu, aniž bychom byli nuceni přerušovat rozpracovanou činnost − jednotlivé programy mohou lépe spolupracovat, neomezují se pouze na výměnu souborů, ale mohou navzájem ovlivňovat svoji činnost − umožňuje realizaci multiuživatelského systému − umožňuje lepší využití kapacity výpočetního systému Nevýhody: − špatně navržený systém může při běhu většího množství programů negativně ovlivnit funkčnost aktivních aplikací, se kterými uživatel právě pracuje, to se projeví např. extrémním zpomalením - zvýšením doby odezvy (problém především u kooperativního multitaskingu) − realizace multitaskingu se neobejde bez správy procesů, která má svou vlastní režii (spotřebovává procesorový čas), v krajním případě může dojít až k zahlcení systému, kdy většina procesorového času je spotřebovávána na režii (hrozí především u preemptivního multitaskingu) − realizace multitaskingového operačního systému je složitější - má větší nároky na hardware počítače (více RAM a úložného prostoru, rychlejší procesor, atd.) − pokud není OS spojen s dostatečným systémem zabezpečení, zvyšuje se riziko ztráty dat
5
3.2
Multithreading Je schopnost programu sám sebe větvit.
3.2.1
Procesy
V obecném povědomí je proces znám spíše jako aplikace. Ovšem v odborné terminologii je proces považován za spuštěnou instanci nějakého programu. Samotný proces není vykonáván, zpracovávají se pouze vlákna daného procesu. Proces pouze obsahuje zdroje (paměť, otevřené soubory, strojový kód). Každý proces obsahuje nejméně jedno vlákno. Toto vlákno je vytvořeno automaticky po spuštění aplikace a nazývá se primární. Po ukončení primárního vlákna jsou uvolněny zdroje celého procesu a aplikaci považujeme za ukončenou. 3.2.2
Vlákno
Vlákno představuje výkonnou jednotku procesu, protože zpracovává kód a používá zdroje procesu. Vlákna sdílí zdroje procesu neomezeně. Pokud ale chtějí používat zdroje z jiného procesu, pak musí použít nějaký mechanismus, např. IPC (Inter - Process Communication), protože standardně jsou vlákna z jiných procesů mezi sebou důsledně chráněna. Pojem „IPC“ je mírně zavádějící, ve skutečnosti mezi sebou nekomunikují procesy, ale vlákna z různých procesů. Plánovač úloh ve Windows pracuje pouze s vlákny a zajišťuje jejich zdánlivě paralelní běh. Nejprve se provádí jedno vlákno a poté procesor zpracovává další. Jejich rychlým přepínáním je vyvoláván dojem, že vlákna běží souběžně.
3.3
Plánování úloh
RTOS je založen na prioritním zpracování a přepínání úloh. Každá úloha má svou prioritu. S rostoucí prioritou roste také nutnost odbavení úlohy procesorem. Rychlého odbavení lze dosáhnout přepínáním úloh. To znamená, že operační systém je schopen zastavit právě probíhající úlohu, která má nižší prioritu, a spustit úlohu s vyšší prioritou. Po skončení této úlohy operační systém pokračuje s prováděním předchozí úlohy. Úlohy mají tři stavy: běží, připraven nebo blokován. Většinu času je úloha blokována. V procesoru je vždy pouze jedna běžící úloha. V menších systémech mají statut připraven maximálně tři úlohy. Nejpoužívanější metody plánování: − Round robin – při zpracování aktivního vlákna s nižší prioritou než má vlákno čekající ve frontě, je vlákno uloženo a vráceno zpět do fronty, poté je připraveno pro běh vlákno s vyšší prioritou. Round-robin pracuje buď v preemptivním nebo kooperativním multitaskingu. Pokud nastane situace, že jsou připravena vlákna se stejnou prioritou, každé vlákno bude spuštěno na definovanou dobu. Nelze tudíž přesně definovat čas zpoždění, protože vlákna mohou být různě náročná a mohou se zpracovávat delší dobu. − dle priorit - rozdíl od metody Round robin je ve zpracování vláken se stejnou prioritou. Vlákno se provádí tak dlouho, dokud není ukončeno, nebo dokud není připraveno vlákno s vyšší prioritou. Nikdy není přepnuto vlákno vláknem se
6
stejnou prioritou.
3.4
Přepínání úloh
RTOS nejčastěji poskytují přepínání úloh dle priorit. Úloha s vyšší prioritou je upřednostněna před úlohou s prioritou nižší ještě před spuštěním úloh. Operační systém obsahuje mechanismus „inverze priorit“. To je stav, kdy vlákno s vyšší prioritou požaduje přístup k systémovým zdrojům, které v danou chvíli drží vlákno s nižší prioritou. V tomto případě dojde k přepnutí (preempci) do vlákna s vyšší prioritou, které však nemůže běžet díky zablokovanému systémovému zdroji. Jediným řešením je umožnit vláknu, které drží systémový zdroj, ihned dokončit činnost a umožnit tak jiným vláknům pokračovat v jejich činnosti.
Obr.1 Přepnutí úloh.
3.5
Mezní časové zpoždění (latence) – deadline
Jedna z nejdůležitějších vlastností real-time systémů je mezní časové zpoždění systému. Pohybuje se v řádech od 10-12 [s] až po desítky minut. Dnešní procesory (v osobních počítačích) jsou výkonné, jejich zpoždění včetně přerušení se pohybuje v řádech mikrosekund, ale jejich tepelný výkon je značný. Vyžadují nucené chlazení. Tato nevýhoda znemožňuje nasazení těchto typů procesorů v náročných podmínkách, které jsou v běžné praxi. Pro maximální spolehlivost je nutné, aby v těchto systémech bylo minimální množství pohyblivých součástí jako jsou větráky nebo pevné disky. V praxi je schopen RTOS reagovat na zpoždění v rozmezí 0.01-100 milisekund.
3.6
Garbage collection
Garbage collection je pojem, který je znám od počátku šedesátých let minulého století. V tehdejší době byl Garbage collection („GC“) používán pro optimalizaci diskového prostoru na sálovém počítači. Později, kdy se začalo pracovat ve větší míře s databázemi, se „GC“ uplatňoval jako nástroj pro optimalizaci nebo defragmentaci databáze. S dalším vývojem programovacích jazyků se „GC“ se používal ve smyslu uvolňování dynamické paměti. Tato metoda poskytuje automatickou správu paměti, provádí uvolňování nepotřebné paměti s
7
nízkou prioritou. Pokud má nějaký programovací jazyk zabudovanou podporu „GC“, používají se především tyto dvě následující metody. První, jednoduší, lze nalézt například v jazyku Perl a nazývá se „reference count GC“. U každého objektu je uvedeno, kolik ostatních objektů na něj navazuje. Pokud tento počet klesne na nulu, je objekt odstraněn. Tento způsob „GC“ je velmi rychlý. Má však jeden nedostatek a tím jsou „cyklické reference“. Ukazuje-li objekt A na objekt B a naopak, a na tyto objekty (A a B) již žádné další objekty neukazují, měly by se v „GC“ smazat, což se nestane, protože mají „reference count“ 1. Druhá modernější metoda, která je například v Javě, se nazývá „mark & sweep“. Je výrazně pomalejší než výše uvedená metoda, ale je to zatím nejdokonalejší známá metoda na čištění objektů. Spočívá v jednom kořenovém objektu, který představuje hlavní program. „GC“ začíná právě u tohoto objektu, označí všechny objekty od něj dosažitelné. Zbylé objekty, které nejsou dosažitelné, se smažou. Tato metoda je velmi náročná na výkon procesoru. Je proto kombinována s již zmíněnou starší metodou.
3.7
Dynamické přidělování paměti
Determinismus se uplatňuje i v oblasti dynamického přidělování RAM paměti. NonRTOS často využívá metody „heap“, pro kterou se používá český termín „halda“. V jazyce C se pracuje s touto pamětí pomocí funkcí „maloc“ a „free“. Paměť lze alokovat až v okamžiku, kdy je potřeba a až je známo, kolik jí bude potřeba. V okamžiku, kdy již není paměť potřeba, lze ji vrátit systému. Pomocí volání „maloc“ si úlohy mohou dočasně půjčit danou velikost paměti od operačního systému. Jakmile úloha skončí, vrátí se paměť zpět operačnímu systému pomocí příkazu „free“. Operační systém vrátí tuto část paměti do celkového objemu paměti. Vrácená paměť může být použita jako část většího celku nebo ji lze rozdělit na menší bloky pro úlohy s menšími nároky. Neustálým rezervováním a uvolňováním paměti postupně dojde ke fragmentaci paměti. Fragmenty paměti jsou pak nepoužitelné pro požadavky dalších procesů - malé bloky paměti nelze spojit a vytvořit tak spojitou oblast. Operační systém může odmítnout novou aplikaci z důvodu nedostatku souvislé paměti. Tento problém lze vyřešit speciální metodou „garbage collection“. Bohužel způsob provozu toho softwaru je nedeterminitstiský, náhodně přidává zpoždění při běhu, tudíž je nevhodný pro RTOS. RTOS podporuje přidělení paměti bez fragmentace omezením velikosti paměťové oblasti, která bude využívána pro aplikace. Tato metoda je méně pružná než přidělování volných oblastí z celého paměťového prostoru, ale zamezí fragmentaci. Metoda „memory pool“ přiděluje aplikacím přesně dané velikosti paměti, např. 4 nebo 8 velikostí z celkové sdílené paměti. Tato metoda zcela odstraní fragmentaci paměti při přidělení. Po vrácení bloku zpět do sdílené paměti se již nepřiřadí do definovaných velikostí a opět postupně dochází ke fragmentaci. Pro eliminaci této nevýhody se používá postup, který vrácený paměťový blok vypíše na seznam volných oblastí (obr.2). Tímto postupem zamezíme fragmentaci nebo k rozdělování částí paměti do bloků.
8
Obr.2 Sdílená paměť se seznamem volných oblastí pro dočasné přidělení.
9
4
Důležité vlastnosti při výběru RTOS − plánování úkolů a přepínání úloh − obsluha vstupně výstupního zařízení (I/O) − široká podpora procesorů − dobrá škálovatelnost podle požadavků − rozšířené služby, například podpora sítí − POSIX standart - možnost přenositelnosti na jiný RTOS − determinismus - předvídatelné chování − spolehlivost - systém nesmí zkolabovat, musí být odolný proti chybám − zabezpečenost - použití pouze pro účel, pro který byl systém zkonstruován
Hlavní rozdíly, ve kterých se RTOS liší od běžných operačních systémů jsou: − obsluha plánování − podpora vestavného bezdiskového prostředí − podpora dalších komunikačních rozhraní, licenční podmínky a cena RTOS je obvykle škálovatelný a strukturovaný, což umožňuje jeho rozšiřitelnost. Základní (vnitřní) částí je kernel, který poskytuje nezbytné úkony pro běh RTOS. Počet vrstev charakterizuje složitost systému. NON-RTOS umožní v jistých okamžicích rychlé přepnutí běžící aplikace v případě malého počtu procesů. Při větší zátěži může způsobit velké časové zpoždění, i když provádí přepnutí téhož procesu. Výhoda RTOS je zřejmá - v daném časovém úseku je úloha vždy zpracována. Ve většině případů je rychlejší než nedeterministické plánovače, zvláště v případech, kdy je nutné obsluhovat více procesů.
Obr.3 Přepnutí procesů v závislosti na době přepnutí.
10
5
Realizace RTOS
5.1
Kernel
Kernel je jádro operačního systému. Je to část softwaru, která je odpovědná za poskytování bezpečného přístupu k hardware a dalším procesům. Procesem rozumíme program, který je právě prováděn. Operační systém obsluhuje mnoho procesů, které vyžadují jistou velikost přiřazení operační paměti (RAM). Kernel rozhoduje o tom, kdy a na jak dlouho přidělí požadovaný hardware danému procesu. Přístup k hardwaru může být velmi komplikovaný z důvodu různých hardwarových řešení. Proto kernel v sobě obsahuje jistou vrstvu hardwarového oddělení (jedná se o sadu instrukcí, které jsou univerzální pro hardwarová zařízení), která slouží ke skrytí složitosti komunikace mezi hardware a poskytuje jasné a přehledné rozhraní. Toto rozhraní pomáhá programátorům vyvíjet programy, které jsou použitelné i na jiná zařízení. V operačním systému Windows se tato vrstva nazývá „Hardware abstraction layer“ (HAL), v sytému UNIX je to „Hardware control“. Funkční princip jádra se liší v použitém operačním systému.
Obr.4 Základní služby poskytované RTOS kornel. Jádro tvoří: − správa úkolů - jejich plánování, zpracování, přidělování priority − komunikace mezi úkoly a synchronizace - zajišťuje přenos informací bez nebezpečí poškození, jejich koordinaci a to tak, aby byla efektivní komunikace i s jiným zařízením, synchronizace - snaha o zamezení přístupu několika paralelně běžících úkolů − časovače - RTOS klade maximální požadavky na dodržení daného časového
11
kvanta, časovač dodává jádru např. time-out, zpoždění apod. − dynamická správa paměti - tato část umožňuje přidělení RAM, pro účely softwaru, některé velmi malé RTOS, které mají omezenou kapacitu RAM nepodporují dynamické přidělování bloků paměti − vstupně výstupní zařízení (I/O) - zajišťují sjednocení přístupu a organizace hardwarových zařízení RTOS může obsahovat velké množství dalších komponent, např. komunikace po síti, správa systému po síti, správa databází, uživatelské rozhraní, grafické rozhraní apod. I když jsou tyto komponenty mnohem větší a složitější než funkce jádra, vyžadují jeho přítomnost, protože využívají jeho služeb. Systém obsahuje pouze ty komponenty, které jsou nezbytně nutné pro běh systému.
5.2
Meziprocesová komunikace a Synchronizace
Vetšina operačních systémů včetně RTOS poskytuje různé mechanizmy pro komunikaci a synchronizaci mezi procesy. Tyto mechanizmy jsou nezbytné v preemptivním prostředí mnoha procesů, bez nich by procesy nemohly správně komunikovat z důvodu narušení nebo jejich kolize. 5.2.1
File descriptors
„File descriptors“ je index, pomocí kterého jádro získává přehled o všech otevřených souborech. Tato datová struktura je uspořádána do tabulky a každý spuštěný proces má svou tabulku. Aplikace nemůže samostatně přistupovat ke čtení nebo zápisu do souboru, vytvoří si specifický klíč, pomocí kterého získá jádro přístup k souboru jménem dané aplikace. Úkolem „file descriptoru“ je zamezit duplicitní otevření souboru, když je soubor otevřen jiným programem, popřípadě jeho kopírování či vymazání. 5.2.2
Semafory
Semafory slouží k přidělování přístupu ke sdíleným zdrojům. Funkce semaforu se provádí čítačem. Když je počáteční hodnota jedna, semafor pustí úlohu ke zpracování a provede snížení jeho hodnoty o jedničku. Je-li hodnota semaforu nula, je další čekající úloha blokována. Funkce čeká specifikovanou dobu na uvolnění zdroje. Po vykonání požadované činnosti (úloha už ke zdroji nebude přistupovat), dojde ke zvýšení hodnoty semaforu. Při zvýšení hodnoty semaforu se načte nový úkol z fronty. V real-timových systémech lze semafory použít jak k synchronizaci úkolů (vláken) jedné aplikace, tak k synchronizaci úkolů patřícím různým aplikacím. Provádí se to pomocí tzv. „mailboxů“ (mailboxes). Mailboxy (zvané také jako message pool, nebo buffery buffers) jsou dočasně uložené zprávy, které slouží pro komunikaci mezi jednotlivými aplikacemi. 5.2.3
Mutexy
Mutexy - „mutually exclusive access“ jsou nejjednodušším prostředkem pro synchronizaci vláken. Používá se pro zamykání globálních proměnných, ke kterým se
12
přistupuje z více vláken. Vlákno může mutex zamknout či odemknout. Mutex může být zamknut maximálně jedním vláknem, a proto se často používá právě pro synchronizaci přístupu ke sdíleným proměnným. 5.2.4
Kritické sekce
Téměř identickým synchronizačním prostředkem jako jsou mutexy, jsou objekty zvané kritické sekce. Kritické sekce se od mutexů liší tím, že jejich použití je možné pouze vlákny jedné aplikace. Tímto omezením lze dosáhnout mnohem vyšší rychlosti při přidělování přístupu.
5.3
Dědičnost priorit
Pro redukci zpoždění způsobeným aplikací s vysokou prioritou, která se pokouší přistupovat ke kritickým úsekům již uzamčeným úlohou s nižší prioritou, byl původní realtime mutex vylepšen o dědění priorit. Dědičnost priorit zvyšuje prioritu úlohy, která byla během práce v kritickém úseku předběhnuta na nejvyšší úroveň ze všech úloh čekajících na přístup do téhož kritického úseku.
5.4
Přepínání procesů
Čas, který je nutný pro přepnutí procesu, je důležitý pro posuzování kvality operačního systému. Při obecném nepreemtivním zpracování (výpočtu) operační systém provádí přepnutí pouze v okamžicích tiku časovače. Tento tik může být nastaven např. na 10 ms. Pokud je potřeba přepnout na jinou úlohu v jinou dobu v průběhu 10 ms, k přepnutí dojde vždy až na konci periody 10 ms. Takové zpoždění je nepřípustné v drtivé většině RTOS systémů. Více sofistikované preemtivní plánovače procesů určují, který proces bude zpracován. Realizuje se to pomocí tabulky procesů, ve které jsou uloženy informace o procesech (priorita, stav, apod.). V případě velkého množství připravených procesů (velká tabulka), hledání v této tabulce zabere více času a není možné přesně určit, kdy bude úloha provedena. Real time operační systémy provádí hledání pomocí inkrementální tabulky, která se stále aktualizuje, což umožňuje plánovači procesů určit, kdy se který proces zpracuje a v jakém čase.
13
6
Zabezpečení operačních systémů
V minulosti bylo mnoho systémů izolováno, nebo byly v lokální síti propojeny programovatelnými logickými kontroléry. Postupem času, kdy klesaly ceny a rostl výkon mikroprocesorů, začaly na trh pronikat kontrolní systémy. V současnosti jsou na RTOS systémy kladeny požadavky vzdálené správy, diagnostiky, zaměření na propojení s jednotnými počítači ve výrobní vrstvě, schopnost opětovně použít koncepty a komponenty v kontrolních systémech. Je pravděpodobné, že v budoucnu se bude používat jen několik dominujících řešení. Tato standardizace umožní zrychlení vývoje a zavede známou bezpečnostní problematiku.
Obr.5 Nejčastější bezpečnostní požadavky pro vestavné systémy. Obr.4. ukazuje některé základní bezpečnostní požadavky z pohledu koncového uživatele. Je zde použit termín „Základní bezpečnostní funkce“, který poukazuje na jistou úroveň bezpečnosti, celistvosti a požadavku na autorizaci. Přístup do systému by měl být omezen pouze pro autorizované uživatele. Přístup do sítě nebo ke službám by měl být poskytován pouze pokud je zařízení autorizováno. Je tedy nezbytné mít správně nastavenou bezpečnostní politiku v síti. Další nutnou bezpečnostní funkcí je dostupnost vestavného systému. Může nastat situace, kde nějaká entita zabrání v systému provedení úkolu, a to může vést až k degradaci výkonu nebo k úplnému odmítnutí služby autorizovaným uživatelům. Pro zabezpečení vestavného systému je požadováno chránění kritických či citlivých informací (kód nebo data) po celou dobu jejich existence, od vytvoření až po řádné vymazání. Takovéto bezpečné úložiště je nutné pro zajištění zabezpečených informací ve vestavném systému. Význam bezpečnosti nebo též Digital rights management (DRM), lze přeložit jako „Správa digitálních práv“, je stěžejním pojmem pro technické metody, kterými se kontroluje nebo
14
omezuje používání obsahu digitálních médií. Termín „Odolnost proti neoprávněným úpravám“ znamená, že je kladen důraz na zabezpečení zařízení, i když zařízení selže nebo není v provozu. Software je ve vestavných systémech největším zdrojem zranitelnosti. Hlavním cílem je vyvinout maximálně zabezpečený systém. Problémy jsou v: − složitosti - dnešní software je složitý a v budoucnu bude ještě složitější. S rozsáhlejším množstvím kódu se zvyšuje pravděpodobnost vzniku chyb a bezpečnostních oslabení. Problém složitosti se ještě zhoršuje při použití programovacích jazyků C nebo C++. Tyto jazyky nejsou chráněny před jednoduchými útoky, jako je např. přetečení bufferu. Jazyky C a C++ jsou velmi populární z hlediska efektivity kódu, ale mnohem více náchylnější na chyby programátora. − rozšiřitelnosti - moderní systémy jsou navrženy tak, aby byly rozšiřitelné, např. připojením externího zařízení, ovladačů nebo modulů, akceptováním nového kódu, systém tento kód přijme a začne s ním pracovat. Dnešní operační systémy podporují rozšiřitelnost přes ovladače zařízení a moduly, to ovšem přináší další rizika oslabení systému − připojitelnosti - v dnešní době jsou vestavné systémy připojeny na internet, tato konektivita má své výhody i nevýhody. Výhoda je zřejmá: možnost vzdálené správy zařízení. Nevýhoda je, že při malém selhání dochází k ohrožení zabezpečení, potencionální útočník již nepotřebuje fyzický přístup k systému
15
7
Licenční podmínky pro Operační Systémy
7.1
Projekt GNU
Projekt GNU byl založen v roce 1984 s cílem vytvořit klon operačního systému UNIX, který by byl šířen jako svobodný software (angl. free software) pod určitými licencemi. Tyto licence vydané v rámci projektu GNU zaručují uživatelům svobodného software a dokumentace patřičná práva. Tyto licence nejsou jediné, které je možno pro svobodný software použít. Existuje také mnoho licencí, které jsou s nimi kompatibilní a umožňují tedy šíření aplikací coby svobodného software, aniž by měly cokoliv společného s projektem GNU. Jejich výčet je zveřejněn na internetu [2]. Za svobodný software pokládáme takové aplikace, které jsou šířeny se zachováním určitých práv a svobod pro jejich koncového uživatele. Jedná se o právo: − spouštět program za jakýmkoliv účelem − studovat, jak program pracuje a přizpůsobit ho svým potřebám, předpokladem k tomu je přístup ke zdrojovému kódu − redistribuovat kopie dle svobodné vůle − vylepšovat program a zveřejňovat zlepšení, aby z nich mohla mít prospěch celá komunita, předpokladem je opět přístup ke zdrojovému kódu 7.1.1
GNU GPL (General Public Licence) v. 2
Hlavní a původní licence projektu GNU zaručuje uživateli nejširší práva. Pokud se programátor rozhodne šířit svůj program pod licencí GNU GPL, zavazuje se příjemci tohoto programu poskytnout stejná práva, jaká má on sám nebo jaká mu byla prostřednictvím GPL poskytnuta. Tak je zajištěno, že svobodný kód nemůže být využit v kódu proprietárním (uzavřeným). 7.1.2
GNU Lesser General Public License v. 2.1
GNU LGPL je méně striktní v případě linkování svobodné knihovny s proprietárním kódem. Jestliže knihovna nahrazuje již existující uzavřenou knihovnu s podobnými funkcemi, bývá zpravidla šířena pod LGPL. Tato licence chrání pouze svobodu kódu knihovny a nebrání jejímu začlenění do proprietárních aplikací. Programátor tak může v uzavřené aplikaci nahradit proprietární knihovnu svobodnou, aniž by tím porušil licenci. 7.1.3
GNU Free Documentation License v. 1.2
Nejmladší z licencí vystavených Free Software Foundation pro projekt GNU je Free Documentation License. Vychází z GNU GPL, ale je určena pro svobodné šíření dokumentace, nikoliv software. V současné době je pod tuto licenci převáděna veškerá dokumentace k projektu GNU. K dispozici je už i několik velice kvalitních publikací.
16
8
Real-Time Operační Systémy (RTOS)
8.1
Linux
Operační systém GNU/linux je svobodná implementace Unixu vyvíjená týmem programátorů, kteří mají za cíl vytvořit operační systém podle norem POSIX a Single Unix specification. POSIX je přenositelné rozhraní pro operační systémy vycházející ze systémů UNIX. Určuje, jak mají POSIX - systémy vypadat, co mají umět, apod. Tyto normy vyjadřují standardizaci pro hard-real-time systémy. Linux je šířen zdarma pod licencí GNU/GPL, k dispozici jsou zdrojové kódy. GNU/Linux je od základu navržen podle POSIX, zajišťuje tedy dobrou přenositelnost z a na jiné systémy splňující tento standard. Existuje mnoho modifikací například: RTLinux, RTAI. Základní popis architektury UNIX je na obr. 2.
Obr.6 Základní popis UNIX architektury. Podrobnější popis architektury UNIX ukazuje následující obr. 7:
17
Obr.7 Architektura UNIX. Uživatelský program vyvolává služby operačního systému přímo přes knihovny. „Rozhraní systémového volání“ (System call interface) je vrstva, kde je uživateli poskynut přístup ke speciálním funkcím kernelu. Z druhé strany operační systém obsahuje primitiva, která přímo komunikují s hardware. Mezi těmito rozhraními se systém dělí na dvě části. První se stará o „podsystém řízení procesu“ (process kontrol subsystem) a druhá má na starosti „Souborový podsystém“ (file subsystem). Podsystém řízení procesu je odpovědný za řízení paměti, plánování a kontrolu nad procesy, synchronizaci a komunikaci mezi procesy. Souborový podsystém vyměňuje data mezi pamětí a externím zařízením jako proud znaků nebo bloků. K této výměně je zapotřebí použít různé ovladače. Pro blokově orientovaný přenos je vyrovnávací paměť disku použita jako systémová mezipaměť (buffer) v hlavní paměti. Buffer je vložen mezi externí zařízení a uživatelem adresovaný prostor.
18
8.2
RTLinux
Jedná se o komerční linuxovou hard real-time modifikaci, která kromě úpravy jádra přináší také sadu nástrojů a modulů rozšiřujích možnosti jádra. Usiluje o co největší přiblížení POSIX norem. Nabízí možnost běhu speciálních úloh a obslužných rutin přerušení. Nejhorší situace nastane mezi okamžikem, kdy je procesorem detekováno přerušení a okamžikem, kdy začne pracovat rutina obsluhující toto přerušení, tj. nejméně 15 mikrosekund. Periodické úlohy na stejném hardware dosahují zpoždění 25 mikrosekund od naplánovaného okamžiku. Tyto časy jsou limitovány hardwarem, který se ale neustále vyvíjí a tudíž se snižují i tyto prodlevy. Standardní Linux má výborný průměrný výkon a může dokonce poskytovat řádově milisekundovou přesnost v plánování úloh použitím POSIXových soft real-time schopností. Standardní Linux není navržen tak, aby poskytoval přesnost pod milisekundu a spolehlivé časovací záruky. Klíčovým cílem návrhu RTLinuxu je: − transparentnost - neexistují žádné uzavřené černé skříňky − modularita - možnost vynechat nepotřebnou funkci a ušetřit tak zátěž systému − rozšiřitelnost - schopnost přidání modulů a úpravy systému podle požadavků
8.3
RTAI/fusion
Jedná se v podstatě o přídavný modul, který využívá služeb HAL (Hardware Abstaction Layer), což je abstraktní vrstva ležící nad hardwarem. RTAI znamená „Real Time Application Interface“ (aplikační rozhraní v reálném čase). Nejedná se o RTOS, je založen na linuxovém jádře a poskytuje možnost vytvořit plně preemtivní jádro. Běžný Linux trpí nedostatkem podpory reálného času. K zajištění správnosti časování je nutné provést v jádře několik změn jako například obsluha přerušení nebo metody plánování. Takto můžeme získat platformu s nízkou prodlevou a plnící náročné požadavky na předvídatelnost v non - RTOS prostředí Linuxu (přístup k TCP/IP, grafické zobrazení, souborové a databázové systémy apod.). RTAI se skládá z obsluhy přerušení (interrupt dispatcher), RTAI zachycuje přerušení periférií a v případě nutnosti je přesměrovává do Linuxu.
8.4
MS Windows
MS Windows je komerční produkt, je znám jako běžný Operační systém v osobních počítačích. Ovšem existují i ve formě vestavného operačního systému a v mobilních zařízeních. V roce 1996 Microsoft vstoupil do světa vestavných operačních systémů vydáním Windows CE. V současné době poslední produkty jsou tyto: − Windows CE 5.0 - RTOS pro mobilní 32-bitové zařízení − Windows XP embedded - poskytuje RTOS na platformě PC − Windows 2000 with Server Appliance Kit - umožňuje vybudování různých druhů serverových aplikací, včetně aplikace vestavěného sítového úložiště, Web serverové aplikace, Windows terminálů. Operační systém Windows CE se v poslední době začíná stále více objevovat i v zařízeních určených k řízení technologických procesů. Je vak znám spíše jako operační
19
systém z malých kapesních počítačů. Poslední verze je 5.0. Předešlé verze byly .NET a CE 3.0. Kompatibilita mezi CE 3.0 a .NET byla velmi omezena. Avšak Windows CE 5.0 je zcela kompatibilní s .NET. Windows XP embedded je operační systém určený pro větší komplexnější systémy. Windows CE 5.0 je určen pro menší a méně komplexní RTOS aplikace. Je použit jako operační systém v kapesních počítačích s různorodým hardware. Windows CE poskytuje vývojářům stejný vzhled a rozhraní jako na desktopovém PC. Windows CE obsahuje rozhraní Win32 API, která je funkčně omezená od verze Windows XP. Windows CE je plně preemtivní multitaskinkový operační systém. Vícenásobné procesy mohou běžet současně, každý proces běží v chráněné části paměti. Procesy, které se skládají z jednoho nebo více vláken, mohou mít různou prioritu. Windows CE pracují v reálném čase, je tedy nutné garantovat rychlé odbavení událostí kdykoli to bude nutné. Provádí se to vyvoláním přerušení běžícího vlákna a spuštění vlákna s vysokou prioritou. Windows CE má svou hierarchii. Nejnižší vrstva je OEM abstraction layer (nebo také OAL, obdoba HAL – Hardware Abstraction Layer - použitá ve větších systémech), která poskytuje rozhraní mezi hardwarovým zařízením a jádrem systému (kernel). OAL je přizpůsobený mikroprocesoru a zahrnuje nízko úrovňové hardwarové specifikace kódu pro aktivní řízení, hodiny reálného času, časovače a řízení přerušení. Nad OAL vrstvou se nachází Win32 API, která obsluhuje grafickou komunikaci, komunikaci ve Windows a jiné základní funkce jádra. Nejvyšší vrstvu tvoří uživatelská aplikace. Windows 2000 nemá architekturu mikrokernelu, jedná se o upravenou architekturu, která je modulární. Každá systémová funkce je obsluhována samostatně v operačním systému. Ostatní části operačního systému a všechny aplikace přistupují přes komponentu používající standardní rozhraní. Žádný modul nemůže být odpojen, updatován nebo nahrazen bez přepsání celého sytému, nebo aplikačního programového rozhraní (API). Na rozdíl od pravého RTOS, Windows jsou konfigurovány tak, že mnoho vnějších systémových funkcí běží v kernel módu a to z důvodu požadavku vysokého výkonu. Windows 2000 se přibližuje RTOS tím, že využívají přepínání vláken, módů a používají více vyrovnávací paměti.
20
Obr.8 Architektura Windows 2000. Popis architektury Windows 2000: Hardware abstraction layer (HAL) obsluhuje základní hardware a jeho odezvu. Izoluje operační systém od hardwaru. Vytváří systémovou sběrnici, která obsluhuje přímý přístup k paměti (DMA), kontrolu nad přerušením, systémový časovač. Microkernel je základní komponenta operačního systému. Obsluhuje plánování vláken, přepínání, ovládání přerušení, synchronizaci přepínání více procesorů. Microkernel má svůj vlastní kód, který neběží ve vláknech jako je tomu u jiných aplikací, tudíž je to pouze část operačního systému. Device drivers obsahuje souborový systém a ovladače hardwarových zařízení, překládá uživatelské volání funkcí do hardware. Windows 2000 zahrnují modul pro specifické systémové funkce a poskytují API pro uživatelský mód: − I/O manager - základní služba pro obsluhu I/O zařízení, které je přístupné aplikacím a je odpovědné za obsluhu hardware − Object management - vytváří, obsluhuje, maže objekty a datové typy, které jsou použity v procesech a vláknech, používá stejná pravidla pro ponechání, pojmenování a nastavení zabezpečení objektů − Security reference monitor - provádí kontrolu přístupu a kontroluje správnost pravidel
21
− Process/thread monitor - vytváří a maže objekty, vlákna, stopy po procesech. − Local procedure call (LPC) Facility - vynucuje vazbu klient/server mezi aplikacemi a řídícími podsystémy uvnitř systému − Virtual memory manager - mapuje virtuální adresy v adresovaném prostoru do fyzické paměti − Cache manager - zvyšuje výkon u souborových I/O (pevný disk) zařízení, je to mezipaměť, která optimalizuje přístup k datům z pomalého disku − Windows/graphic modules - vytváří grafické rozhraní a řídí grafické zařízení
22
8.5
Přehled RTOS pro 8-bitové mikrokontroléry
8.5.1
eXtreme Minimal Kernel - XMK
XMK je preemptivní multithreadingový real time operační systém pro mikrokontroléry [3]. Byl navřen s ohledem na malé dostupné zdroje paměti. Přehled velikosti OS pro procesor H8/300L, při použití kompilátoru HEW2 Tiny C/C++: BYTES
Popis
Funkce v RAM
Funkce v ROM
Minimální množství paměti pro běh OS
Bez aplikace
Bez obslužných rutin
340; 18
Minimální množství paměti vč. komponent
Počet vláken, obsluha přerušení, prostor pro vlákno aplikace, přerušení
Plánovač
360; 215
ROM; RAM
Původně systém obsahoval pouze preemptivní plánovač a primitiva k synchronizaci vláken. Je rozšířitelný i na 16bit a 32bit platformy. V současnosti podporuje mailboxy, memory pools, file descriptors, ovladače hardwaru a TCP/IP podporu. S rostoucí funkčností si však XMK zachoval stále nízké paměťové nároky. XMK je rozdělen do dvou částí. První, „XMK plánovač“, který poskytuje preemptivní plánovač, vlákna, primitiva pro synchronizaci vláken. Druhá, „APL“ (Application Programming Layer – Aplikační programová vrstva), obsahuje jádro a nezávislé knihovny, které poskytují např. tyto služby: mezivláknová komunikace, heaps, memory pools, networking atd. Aplikaci vyvinutou pro „APL“ (Application Programming Layer - Aplikační programová vrstva) lze jednoduše přenést na jiný operační systém, jako například Windows či Linux. Tím lze vyvíjet aplikace na PC před vlastním přenesením do vestavného systému. 8.5.2
Pico]OS
Pico]OS je real time operační systém podporující velké množství architektur od 8-bit procesorů s malou pamětí až po 32-bit procesory s mnohonásobně větší pamětí [4]. Podporuje preemptivní multitasking. Pico]OS je rozdělen do dvou vrstev. První je tzv. „pico-layer“ – jádro operačního systému, které obsahuje: − plánovač - podporuje dva režimy „standard priority based“ a „Round robin“, maximálně 64 úloh (8 bit), 1024 úloh (32bit) − události - semafory, mutexy − prostor pro zprávy - na každou úlohu je jedna schránka pro zprávy − softwarové přerušení - maximálně 256 (8bit) Druhá vrstva je volitelná „nano-layer“, pomocí které lze dodefinovat další vlastnosti,
23
například vytížení procesoru, upřesnění vlastností událostí, apod. Podporuje několik typů procesorů: 6502 CPU a kompatibilní řady, 80x86 v reálném módu, systém je zaveditelný z MS-DOS, umožňuje pico]OS běžet na MS Windows, ARM, SAMSUNG S3C2510A (ARM940T ) a kompatibilní řady, Atmel(tm) RISC procesor. Přehled paměťové náročnosti pro 8-bit mikroprocesory AVR:
8.5.3
BYTES
Popis
Funkce
Minimální množství paměti pro běh OS
Úlohy (3 + 1 nečinná), události (4), časovače (2)
ROM; RAM 2690; 724
FreeRTOS
FreeRTOS je opensource real-time operační systém [5]. Je zaměřený na vestavné systémy. Je napsán v programovacím jazyce C, je přenositelný na mnoho jiných platforem. Jeho výhoda spočívá v malé velikosti a široké podpoře procesorů: ARM, Microchip PIC, Atmel AVR, Motorola HSC12. Pro každou podporovanou platformu existuje demonstrační projekt jak programovat. Při použití AVR procesoru je celková velikost operačního systému přibližně 4,4 Kbytes. Popis
Funkce v RAM
BYTES RAM
Minimální množství paměti vč. komponent
Plánovač, priority, úlohy, fronty, semafory
203
Funkce v ROM Při použití GCC kompilátoru a AVR procesou
BYTES ROM 4400
Oproti jiným operačním systémům má FreeRTOS jen několik vlastností, které poskytuje jádro (kernel): − Plánovač (preemptivní nebo kooperativní) − Obsluha fronty zpráv − Semafory pro synchronizaci Typickým využitím FreeRTOS je použití nějakého druhu (časově kritického) algoritmu, který provádí např. monitorování senzoru. Předpokládejme, že máme systém se senzorem, který potřebuje určitou dobu ke zpracování pro získání žádané veličiny. Je rozhodující měřit ve stanovených časových úsecích pro udržení kvality měření. Při zobrazování dat na LCD-display je nutné udržovat aktuální informační obsah. Pro ovládání systému se používá klávesnice. Systém tedy musí obsluhovat tři různá zařízení, která mají různou prioritu. Preemptivní plánovač FreeRTOS zajistí, aby byly zpracovány nejdůležitější úlohy. Takto lze charakterizovat malý real-time systém. 8.5.4
embOS embOS je komerční real-time operační systém pro vestavná zařízení, navržen jako
24
plně preemptivní mutlitaskingový systém pro „hard real-time“ nasazení [6]. I přes tyto požadavky si zachoval minimální nároky na hardware. Všechny funkce embOS byly vytvořeny jako samostatné moduly, které jsou vyvolány pouze v případě potřeby. Paměťové nároky OS jsou dostatečně malé, aby bylo možné tento OS použít i na malé procesory. Všechny úlohy a komunikace mohou být za běhu dynamicky vytvářeny, mazány nebo upravovány. EmbOS podporuje zpracování úloh pomocí metody round-robin. Je snadno přenositelný podle požadavků na procesor. EmbOS umožňuje vývojářům vyvíjet program na osobních počítačích s OS Windows, nebo Linux. Jádro je naprogramováno v jazyce „C“ a v assembleru. Může být spuštěn na každém procesoru, pro který existuje dle norem „ANSI“ kompilátor. Mohou to být všechny 8, 16 a 32 bitové procesory. Typické využití pro embOS jsou například: zařízení pro měření napájené z baterií, telekomunikační zařízení, strojírenství, lékařství, … − Počet úloh, mailboxů, semaforů a časovačů je omezen pouze dostupnou RAM pamětí − Maximální počet přidělení priorit: 255 − Neomezený počet úloh se stejnou prioritou (plánovač Round robin) − Široká podpora síťových protokolů: TCP/IP, FTP, SMTP, SNMP, NFS, PPP, ATM, ISDN, RPC, Telnet, Bootp Popis
Funkce v RAM (BYTES)
BYTES RAM
BYTES
Minimální množství paměti vč. komponent velikost, závisí na kompilátoru
Schránka (9-15), semafor (4-5), časovač (9-11), plánovač, semafory
18-25
1100-1600
8.5.5
ROM
Salvo OS
Salvo OS je komerční real-time multitaskingový operační systém pro malé jednočipové mikrořadiče s omezenou velikostí RAM a ROM paměti [8]. Je přenositelný, konfigurovatelný, podporuje mnoho procesorů. Podporuje 16 úrovní priorit, které jsou obsluhovány metodou Round-robin. Salvo OS má několik verzí, které se liší v možnostech nastavení a ceně: − Salvo Lite - je jako jediný freeware. Obsahuje všechny základní znaky ostré verze s nemožností konfigurace nastavení a úpravy zdrojového kódu. Je vhodný pro testování. − Salvo tiny - je základní použitelná distribuce s omezenou konfigurovatelností. − Salvo LE - je pokročilá distribuce s podstatně rozšířenou konfigurovatelností − Salvo Pro - je nejlepší verze, která poskytuje kompletní nastavování. Není nijak omezen počet úloh apod. Je maximálně flexibilní a výkonný včetně zdrojového kódu.
25
8.5.6
Popis
BYTES RAM
BYTES
Minimální množství paměti vč. komponent velikost, závisí na kompilátoru
50-100
1000-2000
ROM
CMX-TINY™
TINY™ je komerční real time multitaskingový operační systém pro tyto rodiny procesorů: Motorola 68HC08, Hitachi H8/300 & H8/300H & H8S, Atmel AVR, Infineon (Siemens) 80C16x, Toshiba TLCS-900, NEC 78K0/K0S, TI MSP430, STMicroelectronics ST7 a jiné. Byl navržen pro systémy s malým množstvím RAM (od 512 KBYTES) [7]. Operační systém obsluhuje: úlohy, události, zprávy, zdroje, časovače, přerušení, přepínání, kooperativní plánovač atd. Při vývoji na PC, má přednastavené rozhraní, ve kterém lze pohodlně nastavovat parametry bez nutnosti vstupu do kódu.
Obr.9 Rozhraní CMX-TINY™.
26
9
Volba RTOS pro potřeby laboratoří prostředků automatického řízení
9.1
Typy úloh řešené laboratoří
9.1.1
Konstrukce inteligentních snímačů
Inteligentní snímač je tvořen citlivou části (čidlo nebo snímač s analogovým výstupem), převodníkem pro převod fyzikální veličiny do digitální podoby, částí zajišťující zpracování dat a komunikačním modulem pro připojení do systému. Mimo citlivé části jsou ostatní prvky realizovány na sw. úrovni uvnitř mikrořadiče. Požadavky na mikrořadič jsou:
9.1.2
-
přesný A/D převodník
-
256 až 4096 BYTE paměti RAM pro data
-
8 až 64 KBYTE paměti ROM pro program (FLASH, EEPROM)
-
od 128 BYTE paměti pro ukládaní nastavení (musí si pamatovat i po vypnutí napájení)
-
schopnost provést minimálně 1000 operací s čísly s plovoucí desetinou tečkou
-
komunikační rozhraní pro UART/I2C/SPI anebo LIN
-
minimálně 2 časovače pro řízení operací
Konstrukce inteligentních aktuátorů
Inteligentní aktuátor tvoří komunikační rozhraní, digitální regulátor a snímací část zpětné vazby, která se chová jako inteligentní snímač a diagnostiky stavu aktuátoru.
9.1.3
-
přesný A/D převodník
-
od 256 BYTE paměti RAM pro data
-
od 8 KBYTE paměti ROM pro program (FLASH, EEPROM)
-
od 1 KBYTE paměti pro ukládaní nastavení (musí si pamatovat i po vypnutí napájení)
-
schopnost provést minimálně 1000 operací s čísli s plovoucí desetinou tečkou
-
komunikační rozhraní pro UART/I2C/SPI, CAN anebo USB
-
minimálně 2 časovače pro řízení operací
-
možnost generovat PWM modulaci
Konstrukce řídicích systémů
Jedná se hlavně řídicí systémy mobilních robotů, vyhodnocovací a řídicí jednotky. Požadavky na hardware a software začínají na požadavcích shodných s inteligentními aktuátory:
27
9.1.4
-
od 256 BYTE paměti RAM pro data
-
od 8 KBYTE paměti ROM pro program (FLASH, EEPROM)
-
od 1 KBYTE paměti pro ukládaní nastavení (musí si pamatovat i po vypnutí napájení)
-
schopnost provést minimálně 1000 operací s čísli s plovoucí desetinou tečkou
-
několik komunikační rozhraní pro UART/I2C/SPI, CAN nebo USB
-
minimálně 2 časovače pro řízení operací
-
ukládání vyšších objemů dat (CF nebo SD karty), souborový systém FAT12, 16, 32
-
možnost uživatelského rozhraní (display znakové nebo grafické, klávesnice)
Používané architektury mikrořadičů
V současnosti jsou používány 8-bitové mikrořadiče založené na jádrech Intel MCS51 a Atmel AVR8, 16-bitové mikrořadiče založené na jádře Hitachi H8S. Do budoucna je plánováno používání 32-bitových mikrořadičů postavených na jádře ARM (ARM7TDMI-S).
9.2
Kritéria výběru RTOS
RTOS musí mít dostatečnou schopnost k poskytování real-time požadavků. Při srovnávání dvou RTOS existuje mnoho rozdílných vlastností, které mají vliv na konkrétní chování RTOS. -
minimální velikost operačního systému
-
přenositelnost - musí podporovat více typů jader mikrořadičů
-
podpora uživatelského rozhraní (display, klávesnice)
-
podpora komunikačního rozhraní, UART/I2C/SPI, CAN nebo USB
-
modul pro připojení paměťové karty (CF, SD)
-
minimální konfigurace se musí vejít do 256 BYTE paměti RAM
-
minimální konfigurace se musí vejít do 8 KBYTE paměti ROM
-
možnost vyřadit nepoužitý kód z binárních souborů
-
generování PWM modulace
28
10
Volba operačního systému XMK Hitachi H8s, Podporované H8300. Atmel procesory AVR, …
Pico]OS
FreeRTOS
EmbOS
Salvo OS
Intel 80x86, AVR, ARM, …
ARM, AVR, ...
ARM, AVR, …
ARM, AVR, Motorola, …
Minimum RAM (BYTES)
215
724
200
18
50-100
Minimum ROM (BYTES)
340
2690
cca 4400
1100
1000-2000
p. jazyk + překladač
C, assembler + GCC
C
C + GCC
C+ IAR(AVR)
C + IAR, ImageCraft
Licence
BSD
BSD
GNU-GPL
Komerční 5000€ -[9]
Komerční 1250$-[10]
www
[3]
[4]
[5]
[6]
[8]
Přehled RTOS splňujících kritéria výběru Vzhledem k tomu, že operační systém bude provozován ve školních laboratořích, je zbytečný nákup operačního systému. volím proto open-source verzi operačního systému. Z hlediska velikosti se jeví jako favorit XMK OS, na internetu je možné nalézt on-line manuál. Velikost OS je uvedena jen pro běh OS bez žádných funkcí. Aby byl OS použitelný v praxi, potřebuje alespoň 360 BYTES ROM a 215 BYTES RAM. Pico]OS podporuje více procesorů než XMK, on-line manuál je k dispozici na internetu, ale je přiliš velký pro nejmenší procesory. FreeRTOS podporuje nejvíce procesorů, lze ho použít i pro velmi malé systémy. Na internetu jsou k dispozici demonstrační verze aplikací k jednotlivým procesorům a také přehledná technická dokumentace. Operační systém FreeRTOS se jeví jako nejlepší varianta výběru. Na webových stránkách [5] je velmi dobře propracovaná dokumentace. Jsou popsány základní principy chodu Real-time operačního systému a ukázky demonstračních zdrojových kódů. Za poplatek (35$) je možné zakoupit dokumentaci v souboru Windows nápovědy (*.CHM). Každému podporovanému procesoru je věnován prostor pro jeho popis. Vzhledem k tomu, že operační systém je možné šířit pod licencí GNU-GPL, pro požadavky uvedené v kapitole 10. volím operační systém FreeRTOS.
29
11
Závěr
Úkolem mé bakalářské práce bylo doporučit volbu „real-time“ operačního systému pro 8-bitové mikrořadiče. V úvodu se práce zabývá základním rozdělením a stručným přehledem „real-time“ operačních systémů. V další části práce jsou rozebrány základní vlastnosti operačních systémů. Dále byla definována základní terminologie, rozdíly mezi jednotlivými funkcemi, metody používané při předcházení chyb a stanovení vlastností důležitých pro real-time operační systém, principy a funkce jádra (kernelu) a jeho popis struktury a formy zabezpečení v různých operačních systémech. V dalších částech této práce byly popsány různě složité a vyspělé „real-time“ operační systémy jako Windows Embedded či Linux pro výkonnější mikroprocesory a poté pro 8-bitové mikroprocesory. Největším problémem při zpracování této práce bylo získat jednotlivé informace o velikostech RTOSů, protože každý systém podporuje jiné procesory každý z nich je testován na jiné platformě. Tato bakalářská práce měla za cíl přiblížit důležité vlastnosti, které musí kvalitní operační systém splňovat. Volba operačního systému není jednoduchou záležitostí. Je nezbytné zohlednit a posoudit všechny požadavky, které jsou na systém kladeny. V závěru se věnuji volbě konkrétního real-time operačního systému pro použití ve školních laboratořích. Pro tyto účely byl jako nejvhodnější shledán „real-time“ operační systém FreeRTOS. Jeho hlavní výhody oproti ostatním systémům jsou: dobře zpracovaná dokumentace, široká podpora procesorů a v neposlední řadě open-source licence.
30
12
Literatura
[1]
http://www.gnu.org/licenses/license-list.cs.html
[2]
http://gcc.gnu.org/
[3]
http://www.shift-right.com/xmk/
[4]
http://picoos.sourceforge.net/memory.html#config
[5]
http://www.freeRTOS.org
[6]
http://www.segger.com/embos.html
[7]
http://www.testech-elect.com/cmx/tiny.htm
[8]
http://www.pumpkininc.com/
[9]
http://www.segger.com/pricelist_embos.html#embosniosgnu
[10] http://store2.esellerate.net/store/catalog.aspx?s=STR1717021
31
13
Slovník pojmů
ANSI: American National Standards Institute - Americká instituce, která vyvíjí americké průmyslové standardy ve shodě s mezinárodními standardy ISO. POSIX: Portable Operating System Interface - přenositelné rozhraní pro operační systémy, standardizované jako IEEE 1003 a ISO/IEC 9945. Vychází ze systémů UNIX, a určuje, jak mají POSIX systémy vypadat, co by měli umět, principy, funkce atd. POSIX zahrnuje různé aspekty operačních systémů, např. správu procesů, práci se soubory, meziprocesovou komunikaci, síťové protokoly atd. - celkem se jedná o 15 dokumentů. Modulární systém: Jádro je sestaveno s podporou modulů (ovladačů), lze je v případě potřeby nahrát do jádra nebo je uvolnit.
32
