Určení real-time odezvy OS Microsoft Windows CE

Transkript

1 XXVI. ASR '2001 Seminar, Instruments and Control, Ostrava, April 26-27, 2001 Paper 33 Určení real-time odezvy OS Microsoft Windows CE KULHÁNEK, Jiří 1, KAČMÁŘ, Dalibor 2 1 Ing., Katedra ATŘ-352, VŠB-TU Ostrava, 17. listopadu, Ostrava - Poruba, jiri.kulhanek@vsb.cz 2 Dr. Ing., Katedra ATŘ-352, VŠB-TU Ostrava, 17. listopadu, Ostrava - Poruba, dalibor.kacmar@vsb.cz, Abstract: This contribution is focused on measuring of response to external event in Windows CE 2.11 operating system. The general purpose of realized measurement was discovering the real-time natures of Windows CE operating system generally. The second purpose was discovering the concrete response time values for tested platform. Tested platform was based on single board computer with i486 compatible processor and with expansions cards. For processing of external events and for generating response was created single-purpose device driver. The measuring of response times was realized in developed real-time application for OS MS-DOS. For calibration, checking and one-shot measures was used digital memory oscilloscope. Klíčová slova: real-time, Windows CE, přerušení 1 Úvod Vytvořením OS Windows CE reagovala firma Microsoft na poptávku po operačních systémech pro přenosná zařízení. Zároveň byl tento OS určen pro aplikaci na úlohy ovládání a řízení (real-time) dalších spotřebitelských zařízení s využitím rozhraní poskytovaného Win32 API. Z uvedených důvodů je tento OS menší, vyžadující méně HW zdrojů a zajišťující lepší realtime vlastnosti než ostatní 32 bitové OS Windows. Jedněmi ze zásadních real-time vlastností operačního systému jsou rychlost a spolehlivost odezvy na vzniklou událost (obvykle generovanou externím HW). Pro měření této real-time vlastnosti operačního systému Windows CE byla v rámci příspěvku navržena a realizována měřící sestava včetně software. 2 Testovaná platforma Testovaná platforma se skládala z jednodeskového počítače, rozšiřujících karet a operačního systému Microsoft Windows CE Jednodeskový počítač (Single Board Computer) byl PCM-4823 od firmy Advantech. Tento počítač má následující parametry [Advantech 2001]: procesor AMD Am5x86 133MHz výkonnostně srovnatelný s procesorem Intel Pentium 75MHz. Rozměry 145mm x 102 mm SVGA/LCD grafickou kartu EIDE řadič, řadič disketové mechaniky, paralelní a dva sériové porty ISA slot kompatibilní se standardem PC/104. Uvedený jednodeskový počítač je na obrázku

2 Na testovaném jednodeskovém počítači byl nainstalován operační systém Microsoft Windows CE Obrázek 1. Jednodeskový počítač Advantech PCM-4823 [Advantech 2001] Obrázek 2. Měřící karta PC/104 Advantech PCM-3730 [Advantech 2001] Pro vstup vnější události a generování odezvy byla použita digitální měřící karta PCM-3730 s těmito parametry: ISA karta s průchozím konektorem PC/104. opticky oddělené digitální vstupy a výstupy (8 vstupů / 8 výstupů) TTL vstupy a výstupy (16 vstupů / 16 výstupů) Nastavitelné generování přerušení (jedno) vzestupnou nebo sestupnou hranou signálu na opticky isolovaném nebo TTL vstupu. 3 Zapojení měřící sestavy Pro měření rychlosti odezvy operačního systému bylo použito externího generátoru obdélníkového signálu (PC program) přivedeného na TTL vstup měřící karty. V OS Windows CE byla provedena odezva (TTL výstup) na vzestupnou hranu externího signálu. Pomocí externích zařízení (osciloskop a PC) byla měřena doba odezvy. Odezva byla realizována invertováním výstupního signálu (viz. obrázek 3), doba odezvy je označena T. PC MS-DOS program LPT Externí signál SBC PCM-4823 Windows CE TTL vstup s IRQ PCM-3730 Odezva systému t LPT TTL výstup PCM-3730 T T t Obrázek 3. Odezva Windows CE na externí signál Pro přesné měření času odezvy byl použit paměťový osciloskop. Pro měření spolehlivosti odezvy systému na opakované signály byl použit počítač PC s MS-DOS programem (viz. obrázek 4)

3 Digitální paměťový osciloskop Externí událost Odezva systému PC MS-DOS program Jednodeskový počítač Windows CE Obrázek 4. Zapojení měřící sestavy Parametry použitých komponent: Počítač PC s procesorem Intel Celeron 466MHz, chipset Intel 810. Digitální paměťový osciloskop Tektronix TDS Softwarové řešení odezvy systému Pro co nejrychlejší odezvu na externí událost realizovanou pomocí přerušení (vzestupná hrana) byl vytvořen jednoúčelový ovladač k digitální kartě PCM Vytvořený ovladač používá IST thread s nejvyšší možnou prioritou zpracování. Tento thread je vyvolán operačním systémem jako reakce na přerušení a ihned provede odezvu invertováním výstupního signálu (viz obrázek 5). 1-IRQ 4 externí událost 3 Windows CE Kernel 2 Windows CE ISR procedura IST zpracování přerušení v ovladači karty odezva 5 Legenda: IRQ přerušení (Interrupt Request) ISR neodkladné zpracování přerušení (Interrupt Service Routine) IST hlavní zpracování přerušení (Interrupt Service Thread) Obrázek 5. Reakce OS prostřednictvím ovladače na externí událost Na obrázku 5. je vidět postupné provádění částí operačního systému a ovladače po vyvolání přerušení kartou PCM Odhadovaná časová náročnost jednotlivých částí zpracování přerušení pro OS Windows CE 2.11 je následující: 1. Zpracování IRQ operační systém Windows CE 2.11 neumožňuje současné zpracování více přerušení. Přerušení se tedy vyvolá buďto ihned, nebo vůbec (pokud se právě zpracovává jiné). Proto musí být zpracování přerušení velmi rychlé (systémové ISR procedury)

4 2. Vyvolání ISR procedury, proběhne velmi rychle operační systém nalezne v tabulce k odpovídajícímu přerušeni ISR a vyvolá ji. 3. ISR procedura nebyla ve vytvořeném ovladači pozměněna, byla tedy vyvolána implicitní systémová ISR. Systémová ISR procedura pouze nastaví událost pro aktivaci IST threadu a povolí ostatní přerušení [Microsoft 2001]. 4. Rychlost vyvolání IST threadu je závislá na jeho prioritě a aktuálním stavu ostatních threadů. V testované aplikaci měl IST thread maximální možnou prioritu, rychlost jeho vyvolání byla tedy závislá především na schopnosti operačního systému ukončit aktuálně zpracovávaný thread a aktivovat nový. Tento čas je patrně nejvíce proměnlivou konstantou v celkovém čase odezvy. 5. V realizovaném IST threadu je ihned po jeho aktivování provedeno invertování výstupního signálu. Tento čas je tedy také minimální. Poté je povoleno zpracovávané přerušení. 5 Softwarové řešení měřící aplikace Pro měření jednotlivých vzorků odezev bylo možné použít digitální paměťový osciloskop, ale pro měření spolehlivosti odezev na periodicky generované signály bylo nutné vytvořit speciální testovací aplikaci na PC. Hlavním problémem měření na PC je spolehlivé a přesné měření času odezvy měřeného systému. Tento problém je možné řešit dvěmi způsoby: použití speciální měřící karty s možností nastavování HW čítačů externím signálem. Samotné měření času je realizováno přesně pomocí HW prostředků, a PC pouze naměřená data převezme a zpracuje (v prakticky libovolném OS). použití standardního PC I/O nebo běžné měřící karty (bez čítače). Pro takové řešení je nutné realizovat měření času samotnou aplikací. Z toho důvodu je zapotřebí vytvořit aplikaci v operačním systému, který umožňuje běh real-time aplikací. Protože nebyla k dispozici vhodná měřící karta, byla realizována aplikace používající běžné PC I/O. Tato aplikace umožňovala pro dané měření dostatečnou přesnost měření (viz kapitola 7). Vytvořená aplikace byla realizována v operačním systému MS-DOS v jazyce C++ (kompilátor Visual C++ 1.0). Jako vstupně / výstupní port byl zvolen LPT port umožňující práci se signálem v TTL úrovních. HW omezení plynoucí z vlastností počítačových sběrnic omezila rychlost vzorkování vstupního signálu přibližně na hodnotu 1µs (rychlost procesoru je málo podstatná). Tato vzorkovací rychlost byla pro měření časů v desítkách mikrosekund dostatečná. Hlavním problémem proto bylo na PC platformě realizovat přesné měření času s rozlišovací frekvencí alespoň 1µs. Tento problém byl vyřešen využitím interního čítače procesorů Pentium a kompatibilních, který má rozlišovací přesnost závislou na frekvenci procesoru (pro 100MHz Pentium je to 10ns). Tato rozlišovací schopnost byla naprosto dostatečná (použitý procesor Celeron 466MHz zajišťoval rozlišovací schopnost 2.15ns). Nevýhodou uvedeného řešení je nemožnost použití aplikace na počítačích se staršími procesory než je Intel Pentium (např. testovaný SBC obsahoval procesor kompatibilní s i486). 6 Naměřené údaje Pro vyhodnocení odezvy operačního systému byly provedeny dvě sady měření. Jedna sada pro nezatížený operační systém a jedna sada měření pro zatížený systém. Zátěž systému byla realizována množstvím zároveň spuštěných threadů, extrémní zátěž prakticky znemožňovala práci s grafickým rozhraním. Tato zátěž minimálně ovlivnila maximální dobu odezvy systému je to důsledek vysoké priority použitého IST threadu. Každá sada měření se skládala z řady měření pro různé frekvence externích signálů. Přesnost uvedených je výrazně ovlivněna vzorkovací periodou na měřícím PC, pro všechna měření byla 1.45µs. V tabulkách 1 a 2 jsou uvedeny vždy měření pro 2 různé frekvence externího - 4 -

5 signálu. Frekvence 1Hz simuluje náhodný děj, frekvence 10kHz realizuje periodický signál na výkonnostní hranici měřeného systému. Z celého souboru naměřených dat jsou uvedeny vždy minimální,maximální a průměrné hodnoty odezvy (T Min, T Max, T Průměrná ). Frekvence externího signálu 1 Hz 3600 vzorků 10 khz vzorků T Průměrná 115 µs 34 µs T Min 65 µs 25 µs T Max 365 µs 1575 µs Tabulka 1. Měření nezatíženého systému Frekvence externího signálu 1 Hz 3600 vzorků 10 khz vzorků T Průměrná 235 µs 48 µs T Min 85 µs 25 µs T Max 565 µs 505 µs Tabulka 2. Měření zatíženého systému Z uvedených měření vyplývá, že maximální naměřená doma odezvy je 1.5 ms (viz tabulka 1). Při tomto měření byly zaregistrovány 4 odezvy delší než jedna milisekunda. Veškeré ostatní odezvy se přitom pohybovaly do 115 µs. Vzhledem k množství zaznamenávaných vzorků a rychlosti měření, nebyl zaznamenáván časový průběh jednotlivých odezev. Není proto možné určit, zda tyto extrémně pomalé odezvy nastaly ihned po sobě, nebo zcela náhodně během celého souboru měření. Při analýze příčiny těchto pomalých odezev je možné uvažovat dvě možnosti: Maximální časová provize pro přepnutí z běžícího threadu na thread s vyšší prioritou může pro měřený systém trvat až 1.5 ms. V operačním systému existují thready s maximální prioritou (např. IST thready systémových ovladačů), které mohou blokovat zpracování našeho IST threadu (taktéž s maximální prioritou). Předpokládáme tedy, že naprostá většina naměřené časové provize nastává právě při spouštění našeho IST threadu (4 volání na obrázku 5). Při veškerých ostatních měřeních se pohybovala maximální doba odezvy kolem hodnoty 0.5 ms a tyto pomalé odezvy byly taktéž velmi málo časté (viz grafy 1 až 4) Jak vyplývá z maximálních dob odezev pro 10kHz frekvenci externího signálu, tak systém odpověděl pomaleji než byla perioda vysílání. Tato možnost byla v měřícím software ošetřena tak aby nedocházelo k vysílání nových impulsů po dobu jednoho měření. Timeout měření byl ve všech případech nastaven na 1s a při žádném měření k němu nedošlo. Tento timeout by mohl nastat na měřeném zařízení pouze v případě kolize s jiným přerušením. Během měření se nepodařilo tuto situaci pomocí běžných zátěžových postupů docílit. Procentuální rozložení odezev při jednotlivých měřeních je vidět na grafech 1 až 4. V grafech jsou vždy zobrazeny pouze výrazné údaje, málo časté odezvy zde nejsou uvedeny (jejich maximální a minimální hodnoty jsou v tabulkách 1 a 2)

6 Graf 1. Rozložení odezev při nezatíženém systému (1Hz události) Graf 2. Rozložení odezev při nezatíženém systému (10 khz události) Graf 3. Rozložení odezev při zatíženém systému (1Hz události) - 6 -

7 Graf 4. Rozložení odezev při zatíženém systému (10 khz události) Porovnání chování zatíženého a nezatíženého systému je na grafech 5 a 6. Při měření zobrazeném na grafu 5 byl systém zatížen velikým množstvím spuštěných threadů. Operační systém proto musel vždy nejprve běžící thread přerušit a přepnout do IST threadu ovladače. Tento čas je poměrně proměnný (viz graf 5), ale má viditelnou určitou minimální časovou provizi. Na grafu 6 je vidět nezatížený systém, který patrně nezpracovával žádný aplikační thread. Odezvy jsou proto prakticky pořád stejné. Mezi časem 2.1 a 2.2 sekund (graf 6) je vidět dočasné zhoršení kvality odezvy, která je nejspíš způsobena paralelním prováděním některého systémového nebo aplikačního threadu. Doba odezvy je v této oblasti velmi podobná zatíženému systému na grafu 5. Vzorek časového průběhu odezev pro zatížený systém 450 Rychlost odezvy systému [ µs] Časová osa [s] Graf 5. Časový vzorek odezev pro zatížený systém (události s frekvencí 10 khz) - 7 -

8 Vzorek časového průběhu odezev pro nezatížený systém 300 Rychlost odezvy systému [ µs] Časová osa [s] Graf 6. Časový vzorek odezev pro nezatížený systém (události s frekvencí 10 khz) 7 Přesnost měření Naprostá většina realizovaných měření byla provedena pomocí vytvořené MS-DOS aplikace, pomocí poměrně nestandardních metod. Proto je na místě se zabývat otázkou přesnosti měření vyplývající z použité metody. Vzniklé chyby měření doby odezvy je možno rozdělit na dva druhy: Chyba vzniklá maximální vzorkovací frekvencí měřící aplikace Chyba vzniklá nepřesným měřením času Pro měření času byl použit vnitřní čítač procesoru, čítající s frekvencí procesoru. Přesnost přepočtu tohoto čítače na časové údaje je proto závislá na přesné znalosti frekvence procesoru. Hodinovou kalibrací byla tato frekvence určena jako MHz (oproti tabulkové 466 MHz). Uvažujeme-li možnou nepřesnost znalosti frekvence daného procesoru v rozsahu 2MHz, potom nepřesnost při měření času je: = 0,4%. 468 Pro měření byla použita frekvence procesoru MHz. Maximální vzorkovací perioda měření (psáno v assembleru) byla výrazně ovlivněna časovou provizí spojenou se čtením LPT portu, patrně z důvodu rychlostního omezení ISA sběrnice. Měřící aplikace prováděla pro každou sadu měření autodetekci času jednoho průchodu měřícím cyklem. Maximální perioda vzorkování tak byla určena jako 1.559µs. Při porovnání obou chyb metody měření je zřejmé, že přesnost měření ovlivnila zejména velikost vzorkovací periody. Jako chybu metody pro provedená měření proto uvažuji hodnotu µs. Kontrola přesnosti měření odezvy byla také provedena s pomocí osciloskopu. Na obrázcích 6 a 7 jsou zobrazena dvě samostatná měření doby odezvy systému, jedno pro rychlou odezvu a jedno pro pomalejší odezvu. Při měření na obrázku 6 byla odezva naměřená MS-DOS aplikací 24.1 µs, z osciloskopu odečtená hodnota je dx: µs. Při měření na obrázku 7 byla odezva naměřená aplikací µs, z osciloskopu odečtená hodnota je dx: µs. Na základě těchto kontrolních měření označuji jako maximální chybu metody měření hodnotu µs. Většina provedených měření byla navíc provedena s rozlišovací přesností 5 µs (tabulky 1 a 2, grafy 1 až 4)

9 Obrázek 6. Měření jedné odezvy na osciloskopu, aplikací naměřeno 24.1µs Obrázek 7 Měření jedné odezvy na osciloskopu, aplikací naměřeno µs

10 8 Závěr Pro měření odezvy operačního systému Windows CE 2.11 na testované platformě byla vytvořena metodika měření s dostatečnou přesností a variabilitou měření. Jako nejpodstatnější naměřený údaj, lze označit maximální naměřenou dobu odezvy IST threadu (1575 µs). Během měření nikdy nedošlo ke ztrátě události vlivem činnosti operačního systému. Vzhledem ke konstrukci OS Windows CE 2.11 je však taková ztráta přerušení možná, což silně zhoršuje jeho real-time vlastnosti. Během provedených měření byla testována odezva realizovaná pomocí IST threadu. Veliký rozsah časů odezvy, byl zapříčiněn provizemi OS při přepínání z běžících threadů na IST thread. Při vysoké frekvenci událostí (10 khz) se patrně prováděl především IST thread a ostatní thready se vůbec nespouštěly. Při frekvencích 1Hz se spouštěly i systémové thready s nízkou prioritou, což paradoxně způsobilo pomalejší odezvu systému než při vyšší frekvenci. Některé velmi pomalé odezvy (nad 1ms) mohou být také způsobeny paralelním během dvou threadů na nejvyšší prioritě. Takový thread by totiž nebyl naším IST threadem přerušen a mohl by tak způsobit značné zpomalení odezvy. V samotném operačním systému by se však takové thready neměly vyskytovat. Pro další hodnocení real-time vlastností bude vhodné měřit odezvu ISR rutiny, která není ovlivněna přepínáním threadů. Zároveň by bylo vhodné další měření provést pro OS Windows CE 3.0, který má v mnoha směrech lepší real-time vlastnosti než testovaný Windows CE Příspěvek vznikl jako součást řešení grantového projektu GAČR 101/00/ Literatura Advantech Co., Ltd. : Advantech poduct lines.[online] Taipei Taiwan, 2001 [cit ]. Dostupný z: <URL: BRANDEJS, M Mikroprocesory INTEL Pentium a spol. Praha : Grada. ISBN KAČMÁŘ, D Microsoft Windows CE verze 2.12 a 3.0 a reálný čas. Praha : Automa, Microsoft Corp.: DDK documentation. In MSDN January2001. Redmond USA : Microsoft Corporation,