InfoCo je PDA
Co je PDA
PDA BE300
Seznámení
Výbava
Obsah CD
Hardware
Tipy & Triky
Manuály
Hardware
Operační systémy
Hry
Programy
Programování
HP Jornada 720
Info
Výbava
Software
Hry
ActiveSync
E-knihy
.
Prohlížeče
Tvorba e-Knih
LOG-in/outInformace
|
Zimního času |
| Dnes je: 22. 11. 2024 |
| Internetový čas
@ 675 |
Microsoft Windows CE verze 2.12 a 3.0 a reálný čas
Dr. Ing. Dalibor Kačmář,
katedra automatizační techniky a řízení VŠB TU Ostrava
(e-mail: dalibor.kacmar @ vsb.cz)
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ů. Obvykle známe Windows CE z malých kapesních počítačů, s nimiž se tato platforma dostala do povědomí uživatelů nejdříve. Otázky, na které chci v tomto příspěvku odpovědět, si položil asi každý, kdo se zamyslel nad použitím platformy s Windows CE jako řídicího systému: může tento operační systém uspokojit stanovené potřeby a jak je to vlastně s jeho schopnostmi pracovat v reálném čase?
Ještě před tím, než se podíváme na skutečné možnosti operačního systému, je nutné definovat základní charakteristiky operačního systému, který má právo nést přívlastek real-time (RTOS). Základní obecné vlastnosti, které RTOS musí mít, srovnáme s možnostmi, kterými disponují verze 2.12 a 3.0 operačního systému Windows CE.
Jak je vlastně definován real-time systém?
Obecně existuje několik definic RTOS, které jsou naneštěstí v některých případech dosti protikladné. I přes tuto nejednotnost je možné real-time systém definovat takto: Real-time systém je takový systém, v němž správnost výpočtu nezáleží pouze na logické správnosti algoritmu, nýbrž i na čase, ve kterém byl výsledek vypočten. Nejsou-li časové podmínky systému dodrženy, říká se, že systém selhal (Donald Gillies). K této jednoduché definici je možné navíc dodat: Jelikož časová podmínka v operačním systému je bazální, je nutné, aby byla vždy splněna. Zajištění časování vyžaduje, aby systém byl predikovatelný.
Požadavky na RTOS, které jsou ve své podstatě skryty v předchozích definicích, lze shrnout do těchto bodů:
- RTOS musí být víceúlohový a preemtivní,
- RTOS musí podporovat prioritní systém procesů a vláken (thread),
- musí existovat dědičnost priorit,
- RTOS musí podporovat predikovatelné synchronizační mechanismy,
- chování RTOS musí být dostatečně známé.
Na základě předchozích požadavků musí výrobce operačního systému poskytnout několik základních metrik, které jsou výchozí při rozhodování o vhodnosti operačního systému pro řešení požadované úlohy. Jmenovitě to jsou:
- latence přerušení, neboli doba, která uplyne mezi událostí přerušení a spuštěním obsluhy,
- doby trvání jednotlivých volání systému,
- maximální doba, po kterou operační systém a ovládače zakazují (maskují) přerušení.
V následujících odstavcích se pokusím porovnat tyto obecné požadavky kladené na RTOS s možnostmi, které poskytují dvě verze operačního systému Microsoft Windows CE, verze 2.12 a 3.0. K ilustraci pro praxi budou použity výsledky dosažené v laboratořích firmy Microsoft na dvou platformách s procesory Hitachi SH3 a platformou CEPC (CE na platformě PC) s procesory firmy Intel. Obdobné testy jsou v současné době uskutečňovány i na katedře automatizační techniky a řízení Technické univerzity Ostrava.
Windows CE jako RTOS
Windows CE je preemptivní víceúlohový systém, který byl navržen jako operační systém pro obecné použití. Prvotně je určen pro jednoduchá zařízení neobsahující rotující paměťová média. Vzhledem k tomu, že nebyl vytvořen pevně pro jeden typ hardwaru, musí vždy mezi operačním systémem a vlastním zařízením existovat speciální unifikující vrstva softwaru, která je nazývána OEM Adaptation Layer (OAL).
Prioritní systém a multitasking
V závislosti na verzi operačního systému máme k dispozici 8 nebo 256 úrovní priorit. První hodnota platí pro verzi 2.12, druhá pro verzi 3.0. Je zřejmé, že počet přerušení výrazně vzrostl, a byla tak odstraněna jedna z výtek, které byly Windows CE 2.12 činěny při srovnání s jinými operačními systémy. Nejvyšší priorita má číslo 0 a nejnižší 7, resp. 255 (obr. 1).
Jak již bylo řečeno, operační systém je preemptivní. Systém priorit je právě oním klíčem, který určuje, jak jsou postupně přidělována časová kvanta jednotlivým běžícím vláknům. Velikosti časového kvanta, po které je vláknu přidělen procesor, jsou také v různých verzích operačního systému různě řízena. U verze 2.12 je kvantum konstantní a má implicitně hodnotu 25 ms (u verze 3.0 100 ms). Verze 3.0 však přináší možnost změnit velikost přidělovaného kvanta individuálně pro každé vlákno. Intenzita, se kterou jsou potom jednotlivá vlákna vykonávána, nezáleží pouze na schématu priorit, ale i na délce nastavených časových kvant.
Přiřazení vláken do jednotlivých skupin priorit definuje, jak jsou časová kvanta jádrem OS přidělována. Základní pravidlo stanovuje, že dříve jsou obsluhována vlákna s vyšší prioritou. Existuje-li však v systému více vláken se stejnou prioritou, jsou jim časová kvanta přidělována cyklicky. Aktuálně běžící vlákno tak může být přerušeno pouze jádrem OS při vypršení kvanta, vláknem s vyšší prioritou a samozřejmě obsluhou hardwarového přerušení.
Jedinou výjimkou z pravidla jsou vlákna s prioritou 0, označovaná jako THREAD _PRIORITY_TIME_CRITICAL. Běh vlákna s takovou prioritou nikdy není jádrem přerušen a vlákno je vykonáváno až do svého konce nebo do chvíle, kdy přijde do stavu čekání na systémový zdroj. Zde je velmi nutné, aby vlákno nebylo vykonáváno příliš dlouho, neboť může nastat degradace odezvy operačního systému na vnější podněty.
Časová základna
Mezi jednu ze služeb realizovanou operačním systémem patří i časování. Rozlišení časovače může výrazně ovlivnit množinu realizovaných úloh. Ve Windows CE 2.x je nejkratší perioda časovače rovna 25 ms, tedy je totožná s velikostí časového kvanta. Perioda časovače podstatně ovlivňuje možnosti přerušení činnosti (uspání) libovolného vlákna na stanovenou dobu. Řekněme, že použitím funkce Sleep(n) chceme nechat vlákno v nečinnosti n milisekund. Je-li rozlišení časovače 25 ms, je volání Sleep(1) sice syntakticky správné, ale ve skutečnosti dojde k uspání vlákna na 25 ms.
Změna v uvedeném způsobu časování nastává ve Windows CE 3.0. Zde je nejkratší perioda zkrácena na hodnotu 1 ms a je zcela nezávislá na velikosti časového kvanta. Voláním Sleep(1) bychom měli teoreticky dosáhnout stanovené prodlevy v běhu vlákna. Ve skutečnosti ale může být v mezičase přepnut kontext a může se vykonávat běh jiného vlákna (např. s vyšší prioritou). Dosti výrazně proto záleží na nastavení priorit jednotlivých běžících procesů a vláken.
Inverze priorit
Inverzí priorit rozumíme situaci, která nastane, požaduje-li vlákno s vyšší prioritou přístup ke zdrojům systému, které v danou chvíli právě exkluzivně 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 pro zablokovaný systémový zdroj. To je velmi nepříjemná situace, zejména v RTOS. Jediným řešením je umožnit vláknu, které systémový zdroj drží, co nejrychleji dokončit činnost, a umožnit tak i jiným vláknům pokračovat v činnosti. K vyřešení této situace používá Windows CE, stejně jako většina ostatních RTOS, systém inverze priorit, který umožní vláknu s nižší prioritou zdědit prioritu kritického vlákna, rychle vykonat potřebné operace až do chvíle uvolnění požadovaného zdroje a dále nechat pokračovat v práci kritické vlákno.
Způsob řízení inverze priorit je v obou verzích Windows CE mírně odlišný. Obecně lze říci, že ve verzi 2.x může být realizována inverze do libovolné úrovně, zatímco ve verzi 3.0 pouze do první úrovně. Celou situaci s inverzemi priorit lze ilustrovat na velmi jednoduchém příkladu tří vláken, která používají jeden ze synchronizačních objektů systému, řekněme mutex (mutex je objekt, který dokáže synchronizovat běh vláken různých procesů a zabránit jejich nebezpečnému souběhu).
Vlákna označíme písmeny A, B a C a mutexy písmeny Y a Z. Předpokládejme, že mutex Z vlastní v dané chvíli vlákno C a B je blokováno čekáním na Z. Vlákno B však v dané chvíli vlastní mutex Y. Nyní přijde ke slovu vlákno A, které má vyšší prioritu než vlákna B a C, a požaduje přístup k objektu mutexu Y. Obě verze operačního systému Windows CE vyřeší uvedenou situaci odlišným způsobem. Ve verzi 2.x je zvýšena priorita (priority boost) vlákna B na stejnou hodnotu, jako má A. Protože je B také blokováno, je zvýšena priorita stejným způsobem i vláknu C, aby byly co nejrychleji uvolněny synchronizační objekty. Jakmile přestane být vlákno A blokováno, je snížena priorita jak vláknu C, tak vláknu B.
Nastane-li uvedená situace ve Windows CE verze 3.0, zůstane vlákno A blokováno a priorita je zvýšena pouze vláknu B. Hlouběji se priority již nezvyšují. Obě vlákna (A i B) musí proto čekat na C, dokud neuvolní Z. Tím se zjednoduší složitý algoritmus inverze priorit a dále nastane časově deterministické chování systémových volání (Kcall).
Jedním z požadavků na RTOS je existence dobrých synchronizačních mechanismů, kterými se zabezpečuje korektní souslednost paralelně běžících aplikací a chrání se přístup ke sdíleným systémovým či jiným zdrojům.
Stejně jako jiné operační systémy, i Windows CE disponuje mnoha systémovými objekty, které umožňují realizovat synchronizaci běžících vláken (události, kritické sekce, mutexy, semafory atd.). Způsob, jakým jsou požadavky na synchronizaci zpracovávány, je silně ovlivněn potřebou inverze priorit. Aby bylo inverzi vůbec možné uskutečnit, musí být jednotlivé požadavky na synchronizační objekty ukládány do front FIFO podle priority vlákna, které požadavek vyvolalo. Při řešení problematiky inverze priorit plánovač jádra reorganizuje požadavky v jednotlivých frontách.
Pro synchronizaci je také nutná existence časovačů generujících události s nastavenou periodou. Ve schopnostech časovačů se jednotlivé verze operačního systému Windows CE dosti výrazně liší.
Podívejme se nyní na další možnosti přesného, lépe řečeno velmi přesného měření času, jaká existující služby časovačů nenabízejí.
Potřeba přesně měřit čas může být uspokojena interními výkonnými čítači, které mají mnohem vyšší rozlišení, než je tomu u časovače generujícího zprávy. Jejich dostupnost je však podmíněna konkrétním typem hardwaru a podporou v OAL. Jestliže tato podpora existuje, je možné měřit čas s přesností na jednotky mikrosekund, ale i vyšší. Mezi funkcemi API existují dvě, které umožní zjistit, s jakou přesností výkonné časovače pracují (QueryPerformanceFrequency) a kolik taktů od stanované chvíle bylo načteno (QueryPerfomanceCounter).
Zpracování přerušení
Primární úlohou RT aplikací je včasná odezva na externí události, která je velmi striktně omezena časovým intervalem. Pomalá, nebo dokonce chybějící odezva (nezpracování události) je považována za závažnou chybu operačního systému. Jedním z nejdůležitějších požadavků na RTOS je tedy co nejrychlejší odezva na externí událost. Ta je ve výpočetních systémech vyjádřena vyvoláním přerušení.
Aby se proces zpracování přerušení co nejvíce urychlil, je ve Windows CE rozdělen do dvou částí. První část zpracování přerušení je realizována obslužnou procedurou přerušení (Interrupt Service Routine, ISR) a druhá část pomocí vlákna služby přerušení (Interrupt Service Thread, IST).
Úkolem obslužné procedury přerušení je co nejrychleji obsloužit požadavek přerušení tak, aby žádající zdroj nemusel dlouho čekat. Nejčastěji jde pouze o načtení nebo vyslání požadovaných dat. Další případné zpracování či analýza dat musí být uskutečněny později.
V souvislosti se zpracováním přerušení se vždy objeví otázka možnosti vnořených přerušení. Vnořeným přerušením se rozumí možnost přerušit obsluhu aktuálního přerušení jiným, nejčastěji se stejnou nebo vyšší prioritou. Zde je nutné uvést, že priorita přerušení nemá nic společného s prioritou vláken nebo procesů. Priorita přerušení může být dána hardwarovým nebo softwarovým řešením. Každá z popisovaných verzí Windows CE se k otázce vnořených přerušení staví různým způsobem. Starší verze, verze 2.12, je nepodporuje, a nesplňuje tak jeden z požadavků kladených na RTOS. I přes tento nedostatek však může v mnohých situacích velmi spolehlivě vykonávat řídicí úlohy. Pro obslužné procedury přerušení u verze 2.12 to znamená, že musejí být skutečně napsány velmi úsporně, jelikož během jejich vykonávání jsou všechna přerušení maskována. Při výpočtu kritické odezvy musí být tato skutečnost vždy dobře zvážena.
Verze 3.0 Windows CE je na tom v ohledu vnořených přerušení mnohem lépe. Má jejich podporu zabudovánu tak, aby nevznikala případná zpomalení v obsluze přerušení s vysokou prioritou. Při vykonávání obslužné procedury přerušení jsou totiž zakázána pouze přerušení stejné nebo nižší úrovně. Je--li tedy vyvoláno přerušení s vyšší prioritou při provádění ISR nižší priority, je aktuální ISR přerušena a spuštěna obsluha nové ISR pro vyšší úroveň přerušení. I přes existenci vnořených přerušení je velmi žádoucí, aby obslužné procedury byly co nejkratší a nejrychlejší.
Latence přerušení
Latencí přerušení se rozumí časová prodleva, která uběhne mezi dobou, kdy se vyvolané externí přerušení dostane k procesoru, a momentem, kdy je spuštěna obslužná funkce přerušení. Při popisu RTOS, ale zejména při návrhu RT aplikace, je nutné přesně znát hodnoty této časové prodlevy. Všechny úvahy v následujících odstavcích vycházejí z předpokladu, že kód obslužné procedury je přítomen v operační paměti a že není odsunut do swapovacího souboru. V takovém případě by bylo velmi obtížné latenci determinovat, a hodnoty by se s nejvyšší pravděpodobností o několik řádů zvýšily.
Latenci přerušení je možné obecně vyjádřit vztahem 1.
kde
A je maximální doba, po kterou jádro zakáže přerušení. Tato doba by měla být co nejkratší a určitě omezená;
B je doba, po kterou se jádro rozhoduje, kterou obslužnou proceduru přerušení na základě přijatého přerušení spustit. Je to také doba, po kterou se ukládají potřebné registry procesoru, aby nebyly přepsány vyvolanou ISR;
C je doba, kterou jádro potřebuje pro dokončení zpracování procedury přerušení. Jde zejména o obnovení stavu procesoru, ve kterém se nacházel před vyvoláním obsluhovaného přerušení;
NISR je počet přerušení s vyšší prioritou, která nastanou před vlastním zpracováním přerušení;
TISRn je doba potřebná pro vykonání ISR n-tého přerušení.
Uvedený vztah je však platný pouze pro systém Windows CE 3.0, ve kterém existuje možnost realizovat vnořená přerušení. Zanedbáme-li tuto možnost, jak je tomu u verze 2.x, celý výraz se podstatně zjednoduší.
Tab. 1 ukazuje výsledky testů, které firma Microsoft získala na testovací platformě na bázi procesoru Intel s různým výkonem a Windows CE 3.0 (první sloupec Latence ISR). Tab. 2 pro ilustraci ukazuje stejné výsledky na platformě Hitachi s procesorem SH3 a starší verzí Windows CE (maximální a minimální hodnoty byly získány po vykonání 1 000 testů přerušení).
Tab. 1. Časové charakteristiky Windows CE 3.0 na platformě Intel (Microsoft Corporation)
| Latence ISR (ms) | Latence IST (ms) | |||||
| CPU | min. | průměr | max. | min. | průměr | max. |
| 486-SX, 33 MHz | 10,8 | 12,8 | 53,6 | 99,7 | 115,7 | 152,5 |
| Pentium, 90 MHz | 3,3 | 4,5 | 7,5 | 23,4 | 29,8 | 42,7 |
| Pentium II, 350 MHz | 3,3 | 3,5 | 5,0 | 10,0 | 12,1 | 14,2 |
Tab. 2. Časové charakteristiky Windows CE 2.11 na platformě Hitachi (Murray)
| Latence ISR (ms) | Latence IST (ms) | |||
| CPU | min. | max. | min. | max. |
| Hitachi D9000 s SH3 (60 MHz - interní, 14,75 MHz - externí) | 1,3 | 7,5 | 93 | 275 |
Druhá část zpracování dat přerušení se vykonává pomocí IST. IST je systémové vlákno, které je většinu času ve stavu čekání. Jakmile doběhne obsluha procedury přerušení, je na základě její návratové hodnoty obnoven běh patřičného vlákna IST. To pak dodatečně zpracovává potřebná data, která byla načtena nebo mají být příště vyslána. Libovolné vlákno IST však může být přerušeno procedurou ISR, aby byla zaručena co nepromptnější odezva. Stejným způsobem jako bylo možné vyjádřit latenci procedury ISR, můžeme popsat i IST vztahem 2.
kde
B je doba, po kterou se jádro rozhoduje, kterou obslužnou proceduru přerušení na základě přijatého přerušení spustit. Je to také doba, po kterou se ukládají potřebné registry procesoru, aby nebyly přepsány vyvolanou ISR;
C je doba, kterou jádro potřebuje pro dokončení zpracování procedury přerušení. Jde zejména o obnovení stavu procesoru, ve kterém se nacházel před vyvoláním obsluhovaného přerušení;
L je maximální doba strávená ve funkci příslušející jádru OS (označována jako Kcall);
M je doba potřebná pro naplánování spuštění vlákna.
Výsledky, kterých bylo dosaženo na testovací platformě, lze vidět v tab. 1 a tab. 2 (ve druhém sloupci).
Závěr
Microsoft Windows CE prošel velmi významným vývojem, zejména co se týče rozdílů mezi verzemi 2.12 a 3.0 v oblasti RT. Jeho posun ke skutečnému RTOS je velmi citelný. Windows 2.12 lze hodnotit jako operační systém splňující minimální požadavky kladené na RTOS a může být zcela jistě použit v určitých typech úloh vyžadujících RT vlastnosti. Splňuje především tyto požadavky:
- je multithreadový a preemptivní,
- podporuje osm úrovní priorit vláken,
- podporuje dědičnost priorit, která umožňuje dynamickou změnu pro realizaci inverze priorit,
- podporuje synchronizační mechanismy s deterministickým chováním,
- podporuje programovatelné časovače a přístup k vysoce výkonným časovačům,
- umožňuje dvouúrovňové zpracování přerušení pro rychlé odezvy,
- latence přerušení a jejich zpracování jsou determinovatelné a pevné,
- délka volání jádra je deterministická, pevná a nezávislá na počtu aktivních systémových objektů.
I přes všechny tyto pozitivní vlastnosti má verze 2.12 několik nedostatků, které někteří odborníci považují za velmi závažné. Jsou jimi zejména:
- počet úrovní priorit vláken je příliš nízký,
- přerušení nemohou být vnořena,
- latence přerušení je příliš vysoká.
S uvedenými výtkami nelze než souhlasit, avšak je nutné dodat, že nikde nejsou exaktně a absolutně stanoveny hodnoty, kterých by tyto parametry měly nabývat (zejména co se týče počtů priorit či latence). Pro typy úloh, pro něž je daný počet priorit dostatečný a časové odezvy přiměřené, je daná verze systému naprosto dostačující.
Ve verzi 3.0 však nastaly výrazné změny, a to zejména v uvedených třech sporných parametrech. Jak jsme si ukázali, tyto parametry nabývají těchto hodnot:
- počet úrovní priorit je zvýšen na 255,
- přerušení mohou být vnořená,
- latence přerušení byla výrazně snížena.
Windows CE 3.0 se tak pravděpodobně dostal na stejnou úroveň s ostatními real-time operačními systémy.
Článek vznikl jako součást řešení grantového projektu GAČR 101/00/0189.
