České vysoké učení technické v Praze Fakulta elektrotechnická. Katedra měření. Diplomová práce. SW implementace uzlu Master sběrnice Measurement Bus

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření Diplomová práce SW implementace uzlu Master sběrnice Measurement Bus Karel Srnka Vedoucí práce: Doc. Ing. Jiří Novák, PhD. Praha 2010

2

3 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 3. ledna 2011 Karel Srnka

4 Poděkování Na tomto místě bych rád poděkoval vedoucímu diplomové práce panu Doc. Ing. Jiřímu Novákovi, PhD. za jeho vstřícný přístup po celou dobu tvorby této práce. Dále bych chtěl poděkovat panu Ing. Petrovi Záleskému za pomoc při návrhu a realizaci hardwarové části této práce. V neposlední řadě děkuji své rodině za podporu a vytvořené zázemí.

5 Název práce: SW implementace uzlu Master sběrnice Measurement Bus Autor: Karel Srnka Studijní obor: Kybernetika a měření Zaměření: Letecké informační a řídicí systémy Druh práce: Diplomová práce Vedoucí: Doc. Ing. Jiří Novák, PhD., Katedra měření, Elektrotechnická fakulta, České vysoké učení technické v Praze Abstrakt: Measurement Bus představuje na technické prostředky nenáročnou datovou sběrnici, často využívanou zejména v oblasti průmyslové automatizace a sběru dat. Cílem této práce je nabídnout levné a univerzální řešení připojení osobního počítače vybaveného operačním systémem Microsoft Windows k této datové sběrnici. Řešení spočívá v softwarové implementaci funkce stanice Master prostřednictvím ovladače jádra operačního systému, pracujícího nad obecným ovladačem sériového portu. Pro fyzické připojení počítače k této datové sběrnici je navrženo rozhraní EIA-485 (průmyslový standard využívaný sběrnicí Measurement Bus), připojitelné k počítači prostřednictvím dnes velmi rozšířeného rozhraní USB.

6 Title: SW Implementation of Measurement Bus Master Node Author: Karel Srnka Field of study: Cybernetics and Measurement Specialization: Airborne Information and Control Instrumentation Sort of project: Diploma thesis Supervisor: Doc. Ing. Jiří Novák, PhD., Department of Measurement, Faculty of Electrical Engineering, Czech Technical University in Prague Abstract: Measurement Bus represents a technically undemanding data bus, often employed in the field of manufacturing process automation and data acquisition. The aim of this work is to provide universal, low-cost solution for connecting personal computers running Microsoft Windows OS to the fieldbus. This goal is accomplished by software implementation of Measurement Bus Master node as a kernel-mode filter driver, working above the standard serial port driver. An EIA-485 interface (industrial standard employed by Measurement Bus) connectable via USB is designed to provide physical connection between PC and the fieldbus.

7 Obsah Seznam obrázků Seznam tabulek viii ix 1 Úvod 1 2 Measurement Bus Základní charakteristika Fyzická vrstva standardu Struktura sběrnice Konektory a terminátory Linková vrstva standardu Formát přenášených dat Adresování Řízení přenosu dat Jištění přenášených dat Časování Programování ovladačů pro OS Windows Vstupně-výstupní systém Windows Struktura vstupně-výstupního systému Zpracování vstupně-výstupního požadavku Typy ovladačů Windows Driver Model Driver Stack Struktura WDM ovladače Analýza a návrh řešení SW části Struktura SW řešení v

8 OBSAH 4.2 Specifika ovladačů typu filtr Funkce DriverEntry Funkce AddDevice PnP a Power management Instalace Volba vhodného typu filtru Požadavky na funkce ovladače Popis implementace Knihovna Použité prostředky Definované datové typy Exportované funkce Pojmenované události Komunikace s ovladačem Ovladač Použité prostředky Struktura ovladače Základní datové struktury Obsluha IOCTL žádostí Čtení a zápis dat Stavový automat Hromadný a křížový přenos dat Fyzické rozhraní EIA Základní požadavky na zařízení Výběrkomponent Integrovaný obvod FT232R Budič sběrnice EIA-485 ISO DC/DC měnič AM1S-0505SZ Výkonový MOSFET IRF Popiszapojení Realizace Instalace a testování Instalace ovladače Testovací aplikace vi

9 OBSAH 7.3 Průběh testování a jeho výsledky Závěr 55 A Řídicí znaky komunikačního protokolu 56 B Dokumentace funkcí exportovaných knihovnou 58 B.1 MbOpenSerialPort B.2 MbCloseSerialPort B.3 MbMasterEnable B.4 MbMasterDisable B.5 MbGetMasterStatus B.6 MbMasterReset B.7 MbSlaveEnable B.8 MbSlaveDisable B.9 MbGetSlaveStatus B.10 MbSlaveReset B.11 MbGetSlavePriority B.12 MbChangeSlavePriority B.13 MbRead B.14 MbWrite B.15 MbGetVersionInfo C Schéma zapojení fyzického rozhraní EIA D Seznam použitých součástek 70 Literatura 71 vii

10 Seznam obrázků 2.1 Lineární topologie datové sběrnice Zakončenívedenísběrnice Formát datového bloku Komunikační diagram řídicí stanice Zpracování vstupně-výstupního požadavku Typy ovladačů jádra operačního systému Princip vrstvení ovladačů ve WDM Struktura navrhovaného softwarového řešení Pořadí vertikálního řazení různých typů filtrů Realizované fyzické rozhraní EIA Grafické uživatelské rozhraní testovací aplikace Princip mechanismu P/Invoke viii

11 Seznam tabulek 2.1 Přiřazení pinů konektoru Canon Struktura adresovacího bajtu standardu Measurement Bus Formát status byte účastnické stanice Formát datové struktury MB_MSG Výčet pojmenovaných událostí Formát datové struktury MB_MASTER Formát datové struktury MB_SLAVE Formát datové struktury INPUT_MESSAGE Formát datové struktury OUTPUT_MESSAGE Přiřazení funkcí pinům CBUS čipu FT232R A.1 Řídicí znaky komunikačního protokolu D.1 Seznam použitých součástek ix

12 Kapitola 1 Úvod Measurement Bus představuje datovou sběrnici, která byla navržena primárně pro využití v oblasti průmyslové automatizace a sběru dat. Její hlavní výhody spočívají v jednoduchém komunikačním protokolu a malých nárocích na hardwarové vybavení potřebné pro implementaci. Tím jsou dány nižší náklady spojené s nasazením této datové sběrnice oproti jiným dnes běžně využívaným řešením, mezi které patří například známější Profibus. Z tohoto důvodu je Measurement Bus s oblibou využíván v aplikacích, kde není překážkou jeho nižší komunikační rychlost. Pro připojení osobních počítačů k této datové sběrnici jsou dnes běžně využívána řešení založená na rozšiřujících PCI, popř. starších ISA kartách. Tato řešení s sebou však nesou některé nevýhody, ze kterých můžeme jmenovat například náročnější instalaci nebo nemožnost použití s přenosnými počítači. Cílem této diplomové práce je nabídnout řešení, které umožní připojení osobního počítače s operačním systémem Microsoft Windows k této datové sběrnici za minimalizace podílu hardwarových prostředků. Toto řešení spočívá v softwarové implementaci funkcí stanice Master prostřednictvím ovladače jádra operačního systému, pracujícího nad ovladačem sériového portu. Jediným hardwarovým prostředkem nutným pro připojení počítače ke sběrnici tak zůstane samotné fyzické rozhraní EIA-485. Protože však toto rozhraní nepatří mezi standardní výbavu osobních počítačů, je součástí této práce také návrh a realizace fyzického rozhraní EIA-485, které lze připojit k počítači prostřednictvím portu USB. V úvodní kapitole této práce je představen standard Measurement Bus. Kromě obecné charakteristiky je zde s ohledem na poslání práce kladen hlavní důraz na popis fyzické a linkové vrstvy standardu. Následující tři kapitoly se zabývají řešením softwarové části projektu. První z těchto kapitol je věnována obecným aspektům programování ovladačů pro operační systémy Windows. Zde je rozebrána základní struktura ovladače a jeho interakce s jádrem operačního systému. V další kapitole této části 1

13 Úvod je provedena analýza problému, vybrán vhodný typ ovladače a definovány základní požadavky na jeho funkce. Ve třetí kapitole této části je proveden detailní popis implementace celého softwarového řešení. Návrhem a realizací fyzického rozhraní EIA-485 se zabývá předposlední kapitola práce. Závěrečná kapitola je potom zaměřena na proces instalace ovladače a kontrolu jeho funkčnosti. Zde je představena aplikace, vytvořená za účelem testování funkčnosti celého řešení, a dále popsán postup testování jako takového. Výstupem závěrečné kapitoly je seznam verzí OS Windows, se kterými je ovladač a tedy i celé realizované řešení kompatibilní. 2

14 Kapitola 2 Measurement Bus Measurement Bus (nebo také DIN-Messbus) vznikl v roce 1986 v Německu jako výsledek spolupráce subjektů z oblastí automobilového průmyslu a měření výrobní kvality s Německým národním metrologickým ústavem (PTB 1 ). Jejich snahou přitom bylo vytvoření na technické prostředky nenáročné datové sběrnice s jednoduchým komunikačním protokolem pro oblast průmyslové automatizace a sběru dat. Measurement Bus[1] byl standardizován v roce 1989 normou DIN , část 2, která definuje fyzickou a linkovou vrstvu z pohledu ISO-OSI modelu. Aplikační vrstva standardu byla definována až v roce 1995 normou DIN 66348, část 3. Jedná se o datovou sběrnici s řízením typu Master-Slave, přičemž k jedné stanici typu Master je možno připojit až 31 jednotek typu Slave. Fyzická vrstva přejímá standard EIA-485 a umožňuje plně duplexní přenos dat. Typická přenosová rychlost sběrnice je 9600 Bd, norma však připouští přenosové rychlosti až do 1 MBd. Běžné oblasti použití sběrnice zahrnují automatizovaný sběr dat a řízení výrobních procesů. Z dalších můžeme jmenovat například nasazení při automatizaci čerpacích stanic, pro které byl zvlášť vyvinut aplikační standard EPSI 3 [2], postavený právě na bázi Measurement Busu. 2.1 Základní charakteristika Measurement Bus byl navržen tak, aby bylo pro jeho implementaci zapotřebí pouze minimum hardwarových prostředků. Pro běžnou aplikaci postačí procesor vybavený obvodem UART 4, budič sběrnice EIA-485 s galvanickým oddělením a DC-DC konver- 1 Physikalisch-Technische Bundesanstalt 2 Deutsche Industrie-Norm 3 European Petrol Station Interface 4 universal asychronous receiver/transmitter 3

15 2.2. FYZICKÁ VRSTVA STANDARDU tor pro napájení galvanicky oddělené části. Komunikační protokol je realizován programově. Následující výčet uvádí hlavní rysy standardu Measurement Bus: EIA-485 jako fyzická vrstva standardu galvanicky oddělené plně duplexní rozhraní čtyřvodičová sběrnice se stíněným kabelem s kroucenými páry délka hlavního vedení až 500 m délka odbočky od hlavního vedení až 5 m přenosové rychlosti od 110 bit/s do 1 Mbit/s, 9600 bit/s povinně až 32 stanic připojených ke sběrnici (včetně stanice řídicí) řízení komunikace na principu Master-Slave asynchronní přenos znaků, 7 datových bitů, sudá parita datový blok délky až 128 bytů, zabezpečený příčnou paritou potvrzovaný přenos dat ve třech fázích: dotazovací, přenosová, uzavírací 2.2 Fyzická vrstva standardu Fyzická vrstva sběrnice je postavena na standardu EIA-485. Tím je definováno diferenciální kódování přenášených dat, jednotlivé napěťové úrovně a další parametry. Norma navíc dále specifikuje přesný typ používaných konektorů a přidává ještě některé další požadavky, jako například již zmíněné galvanické oddělení Struktura sběrnice Do přenosových rychlostí 100 kbit/s může být použita libovolná topologie sběrnice [3]. Pro vyšší přenosové rychlosti se však doporučuje zvolit lineární uspořádání s jedním hlavním vedením tak, jak je znázorněno na obrázku 2.1. Sběrnice je, jak již bylo řečeno, plně duplexní. Na jednom páru kroucených vodičů jsou data vysílána od řídicí stanice směrem k účastnickým a na druhém naopak účastnické stanice vysílají data ke stanici řídicí. Z tohoto důvodu musí být řídicí stanice připojena na hlavní vedení kabelem, který má na jedné straně vysílací a přijímací páry vodičů překřížené. Norma dále vyžaduje, aby byla sběrnice samotná za účelem potlačení souhlasného rušení od jednotlivých stanic galvanicky oddělena. 4

16 2.2. FYZICKÁ VRSTVA STANDARDU Obrázek 2.1: Lineární topologie sběrnice. Převzato z [4] Konektory a terminátory Pro připojení jednotlivých stanic ke sběrnici požaduje norma použití konektoru Canon 15. Význam jednotlivých pinů odpovídá standardu ISO 4903 a je uveden v tabulce 2.1. Stínění může být propojeno s provozní zemí pouze v jednom bodě a obvykle tomu tak bývá na řídicí stanici. Zakončení vedení sběrnice je provedeno podle obrázku 2.2. Hodnoty jednotlivých rezistorů jsou následující: R 1 = 510 Ω,R 2 = 150 Ω,R 3 = 120 Ω. číslo pinu význam 1 stínění 2 vysílaná data (A) 3-4 přijímaná data (A) volitelné 8 sběrnicová zem 9 vysílaná data (B) přijímaná data (B) volitelné 15 napájení +5 V (volitelné) Tabulka 2.1: Význam pinů konektorů Canon 15. 5

17 2.3. LINKOVÁ VRSTVA STANDARDU Obrázek 2.2: Zakončení vedení sběrnice. Převzato z [4]. 2.3 Linková vrstva standardu Linková vrstva vychází z mezinárodního standardu ISO Přístup ke sběrnici je řízen centrálně řídicí stanicí. Pro výměnu dat se využívá asynchronního přenosu znaků, které jsou řazeny do jednotlivých datových bloků Formát přenášených dat Jednotlivé znaky jsou vysílány na sběrnici ve standardním sériovém formátu. Po startbitu následuje sedm datových bitů, přičemž jako první je vysílán nejméně významný bit. Dále následují bit sudé parity a jeden stop-bit. Při přenosu dat jsou jednotlivé znaky organizovány do bloků, které mají formát podle obrázku 2.3. Každý datový blok je uvozen řídicím znakem STX, po kterém následuje maximálně 128 datových bajtů. V případě, že je datový blok posledním blokem přenášené zprávy, je ukončen řídicím znakem ETX. V opačném případě je ukončen znakem ETB. BCC je kontrolní znak sloužící k jištění datového bloku a jeho význam bude vysvětlen dále. Obrázek 2.3: Formát datového bloku. 6

18 2.3. LINKOVÁ VRSTVA STANDARDU Adresování Každá stanice typu slave má přiřazeny dvě adresy - jednu vysílací, označovanou jako SADR, a jednu přijímací, označovanou jako EADR. Formát těchto adres popisuje tabulka 2.2. Kromě toho je pro komunikaci využívána ještě jedna speciální adresa označovaná RADR. Z formálního hlediska se jedná o přijímací adresu stanice slave s číslem 0. Tato adresa však slouží ke skupinovému příjmu, kdy je vysílaná zpráva určena pro všechny účastnické stanice. datový bit význam 1-5 adresa jednotky 6 v logické 1 - vysílací adresa v logické 0 - přijímací adresa 7 stále v logické 1 Tabulka 2.2: Struktura adresovacího bajtu standardu Measurement Bus Řízení přenosu dat Při řízení komunikace mezi stanicí řídicí a stanicemi účastnickými se uplatňuje několik speciálních řídicích znaků. Jejich seznam je spolu s krátkým popisem významu každého znaku uveden v příloze A. Iniciativa k veškeré komunikaci po sběrnici přichází vždy od řídicí stanice. Účastnická stanice nikdy nevysílá data, pokud k tomu nebyla předtím řídicí stanicí vyzvána. Úloha řídicí stanice tak spočívá v neustálém periodickém dotazování účastnických stanic, jestli nemají data k odeslání, nebo naopak jestli jsou tyto schopny nějaká data přijmout. Stavový diagram popisující komunikační protokol řídicí stanice je zachycen na obrázku 2.4. Celý cyklus komunikace s účastnickou stanicí lze potom rozdělit do tří fází: vyzývací, přenosové a ukončovací. V následujících odstavcích bude každá z těchto tří fází stručně popsána. Fáze vyzývací První fází je fáze vyzývací. Úkolem řídicí stanice v této fázi je zjistit, zdali pro ní má účastnická stanice nějaká data, nebo jestli je účastnická stanice schopna případně nějaká data přijmout. Pokud se jedná o první případ, vyšle řídicí stanice výzvu SADR ENQ, čímž dává zároveň stanici s adresou SADR právo vysílat. Ta na tuto výzvu může odpovědět pozitivně vysláním znaků SADR DLE 3/1, pokud nějaká data k odeslání 7

19 2.3. LINKOVÁ VRSTVA STANDARDU P íjímací strana diagramu Vysílací strana diagramu 0 Základní 'SADR' ENQ stav 'EADR' ENQ 'RADR' Start limit T A Start limit T A 1 EOT EOT 7 ekání na odpov 'SADR' NAK nebo T>T A 'EADR' NAK nebo T>T A ekání na odpov Start limit T C 'SADR' DLE 3/0 M=1 'EADR' DLE 3/0 2 NAK ekání na STX, SOH, EOT, ENQ STX nebo SOH EOT nebo T>T C EOT nebo T>T C Skupinové vysílání 8 Vysílání bloku ENQ ENQ 3 P ijímání bloku STX nebo SOH 6 ekání na STX, SOH, EOT, ENQ EOT nebo T>T C N=1 M+1 Platný blok 4 ekání na BCC ETB nebo ETX BCC- nebo chyba parity T>T C NAK ENQ N+1 ENQ T>T A a N<3 Start limit T A 9 ekání na odpov NAK a M<3 DLE 3/1 5 ekání na EOT, ENQ DLE 3/1 nebo T>T A a N=3 nebo NAK a M=3 M: Po ítadlo odpov dí NAK N: Po ítadlo požadavk ENQ DLE 3/1 ENQ EOT nebo T>T C Obrázek 2.4: Komunikační diagram řídicí stanice. Převzato z [4]. má. V takovém případě následuje přechod do přenosové fáze. Pokud účastnická stanice žádná data k odeslání nemá, odpoví negativně vysláním znaků SADR NAK a nastává 8

20 2.3. LINKOVÁ VRSTVA STANDARDU přechod do závěrečné fáze. V případě vysílání dat od řídicí stanice k účastnické je postup obdobný. Řídicí stanice nejprve vyšle výzvu EADR ENQ, kterou se účastnické stanice dotazuje, zda je schopná přijmout datový blok. Tato může odpovědět pozitivně vysláním znaků EADR DLE 3/0, načež nastává přechod do přenosové fáze. Může však také odpovědět negativně vysláním znaků EADR NAK, pokud z nějakého důvodu není připravena data přijmout. V takovém případě potom nastává přechod do ukončovací fáze komunikačního cyklu. Přechod do ukončovací fáze nastává také, pokud účastnická stanice na oba typy výzev odpoví chybně a nebo neodpoví do vypršení stanoveného limitu T A (viz dále). Kromě výzev na odesílání nebo příjem dat může řídicí stanice vyslat také výzvu skupinového příjmu RADR. Tato výzva je určena pro všechny účastnické stanice a každá účastnická stanice, která ji přijme, je povinna neprodleně přejít do fáze přenosu dat. Na tuto výzvu žádná stanice nesmí odpovídat, tedy ani negativně ani pozitivně. Fáze přenosu dat Fáze přenosu dat začíná prvním vysláním nebo přijetím řídicího znaku STX, kterým je uvozen datový blok. Každý datový blok je zakončen řídicím znakem ETB, popř. ETX, jak bylo popsáno v podkapitole Zvláštním typem přenosu dat je tzv. křížový přenos. Při tomto typu přenosu odesílá účastnická stanice na stanici řídicí blok dat a zároveň tuto žádá, aby data obratem přeposlala na jinou účastnickou stanici. Křížový přenos se od běžného odlišuje tím, že datový blok k přeposlání je navíc uvozen řídicími znaky SOH EADR, kdeeadr je adresa cílové účastnické stanice. Teprve po těchto znacích následuje řídicí znak STX a data samotná. Ukončení datového bloku je stejné jako v případě běžného přenosu. Úspěšné přijmutí datového bloku je potvrzeno řídicími znaky DLE 3/1. Pojejich odeslání následuje přechod do ukončovací fáze. Pokud je přijatý datový blok nekompletní, nebo obsahuje chybu, je vysláno negativní potvrzení NAK, po kterém je přenos bloku opakován. Takto může být přenos jednoho bloku opakován maximálně dvakrát. Pokud ani poté nedojde k jeho úspěšnému přijetí, následuje přechod do ukončovací fáze. Pokud po odeslání bloku nepřijde žádné potvrzení - tedy ani kladné ani záporné, je vyslána výzva k potvrzení ENQ. Tato výzva může být opět opakována maximálně dvakrát, načež nastává přechod do ukončovací fáze. 9

21 2.3. LINKOVÁ VRSTVA STANDARDU Ukončovací fáze V této fázi vyšle vysílající stanice znak EOT a přejde do základního stavu. Pokud znak přijímající stanice přijme, přejde taktéž do základního stavu. Řídicí stanice může navíc znak EOT vyslat kdykoliv během komunikačního cyklu a přerušit tak probíhající komunikaci. Účastnická stanice, která znak přijme, musí okamžitě přerušit vysílání a uvolnit linku Jištění přenášených dat Každý znak vysílaný na sběrnici je jištěn jedním sudým paritním bitem. Navíc je každý datový blok vybaven kontrolním znakem zvaným Block Check Character (BCC). Tento kontrolní znak je vytvořen jako příčná parita všech datových bajtů v bloku. Jinými slovy n-tý bit BCC je sudou paritou n-tých bitů všech bajtů v bloku. BCC samotný je potom opět jištěn sudou paritou stejně jako všechny ostatní znaky. Generování kontrolního znaku začíná vždy ihned po vyslání řídicího znaku STX, popř. SOH a končí až po odeslání znaku ETX, resp. ETB. Tyto znaky, které ukončují datový blok, jsou tedy v BCC také obsaženy. Vytvořený kontrolní znak je odeslán ihned po řídicím znaku ETX resp. ETB. Přijímací strana potom vypočítá vlastní BCC a porovnává ho s přijatým. Pokud kontrolní znaky nesouhlasí, nebo pokud při přenosu došlo k chybě parity u kteréhokoliv z přenášených znaků, je vysláno negativní potvrzení a přenos bloku je opakován Časování Pro zajištění plynulosti komunikace jsou definovány dva hlídací časy, označované jako T A a T C. Hlídací čas T A je u řídicí i účastnické stanice uplatňován při čekání na potvrzení o příjmu datového bloku. U stanice řídicí je navíc tento limit využit i ve vyzývací fázi v případě, že účastnická stanice nereaguje na vyslanou výzvu. Hlídací čas T C je využíván pouze na straně řídicí stanice pro kontrolu celkové doby trvání komunikačního cyklu, při přijímání datového bloku od účastnické stanice. Tento limit se začíná odpočítávat ihned po obdržení kladného potvrzení SADR DLE 3/0. Hodnoty T A a T C jsou závislé na nastavené přenosové rychlosti podle vztahů 2.1 resp Pro přenosovou rychlost 9600 Bd je T A 21 ms a T C 530 ms. T A = baud rate (ms) (2.1) 10

22 2.3. LINKOVÁ VRSTVA STANDARDU T C = 5, baud rate (ms) (2.2) 11

23 Kapitola 3 Programování ovladačů pro OS Windows Jedním z hlavních kroků při snaze o začlenění funkce stanice Master sběrnice Measurement Bus do operačního systému je tvorba ovladače, který bude implementovat linkový protokol tohoto standardu. Programování ovladačů samotných je však poměrně náročným úkolem. Cílem této kapitoly je provést krátký úvod do této problematiky a definovat některé pojmy, které budou často používány v následujících kapitolách této práce. V úvodu kapitoly bude představen vstupně-výstupní model (I/O model) operačního systému Windows a popsána role ovladače v tomto modelu. Dalším tématem bude Windows Driver Model - framework pro vývoj ovladačů podporujících technologii Plug&Play [5]. V závěru bude proveden rozbor typické struktury ovladače pracujícího v jádře operačního systému. 3.1 Vstupně-výstupní systém Windows Vstupně-výstupní systém je ta část operačního systému, která umožňuje komunikaci s periferiemi počítače. Vstupně-výstupní systém Windows je tvořen několika celky, které dohromady spravují jednotlivá hardwarová zařízení a vytváří rozhraní k těmto zařízením pro aplikace a ostatní části operačního systému Struktura vstupně-výstupního systému Vstupně-výstupní systém Windows sestává z následujících částí: 12

24 3.1. VSTUPNĚ-VÝSTUPNÍ SYSTÉM WINDOWS I/O manager je jádrem celého vstupně-výstupního systému. Definuje formu, jakou jsou vstupně-výstupní žádosti doručovány ovladačům zařízení. Téměř každá taková žádost je reprezentována jako tzv. I/O request packet (IRP). Jedná se o datovou strukturu, která přesně popisuje druh dané žádosti. Kromě toho I/O manager definuje množství funkcí, které každý ovladač využívá při zpracovávání těchto žádostí. ovladač zařízení typicky vytváří vstupně-výstupní rozhraní pro konkrétní zařízení. Ovladač přijímá požadavky ve formě IRP, které k němu nasměroval I/O manager, a které jsou určeny pro zařízení, které ovladač spravuje. Ovladač potom zpětně kontaktuje I/O manager po vyřízení požadavku a nebo v případě, že chce, aby byl požadavek přeposlán jinému ovladači. PnP 1 manager úzce spolupracuje s I/O managerem astypemovladače zvaným ovladač sběrnice (bus driver). Jeho hlavním úkolem je detekce připojení nového zařízení k počítači, přidělení zdrojů (V/V porty, paměťové registry...) tomuto zařízení avneposlední řadě načtení příslušných ovladačů zařízení do paměti počítače. Power Manager také úzce spolupracuje s I/O managerem a jeho úkolem je informovat komponenty systému a jednotlivé ovladače o změnách režimu napájení počítače. Hardwarová abstraktní vrstva (HAL 2 ) tvoří softwarové rozhraní mezi ovladači a hardwarem počítače. Jejím cílem je skrýt rozdíly v různých architekturách procesorů a řadičů přerušení tak, aby bylo možné použít stejné ovladače pro počítače s různou hardwarovou konfigurací Zpracování vstupně-výstupního požadavku Zpracování vstupně-výstupních požadavků probíhá typicky podle schématu na obr Operační systém Windows prezentuje každé vstupně-výstupní zařízení aplikacím jako virtuální soubor. Veškeré vstupně-výstupní požadavky na zařízení potom aplikace směřují právě na tento soubor. Tímto systém vytváří jednotné rozhraní pro komunikaci mezi aplikacemi a různými typy zařízení. 1 Plug&Play 2 Hardware Abstraction Layer 13

25 3.1. VSTUPNĚ-VÝSTUPNÍ SYSTÉM WINDOWS Vstupně-výstupní požadavek obvykle vzniká v okamžiku, kdy aplikace zavolá na virtuální soubor reprezentující dané zařízení některou z dokumentovaných funkcí WinAPI 3 pro vstup nebo výstup. Takovou funkcí může být například WriteFile pro zápis dat. Vstupně-výstupní systém vnitřně implementuje tyto funkce voláním tzv. nativních API funkcí [6] s předponou Nt - např. NtWriteFile. Tyto funkce jsou již součástí I/O manageru, který pracuje v jádře operačního systému. I/O manager v dalším kroku vytvoří IRP reprezentující daný požadavek a předá jej ovladači, který cílené zařízení spravuje. Ovladač samotný pak nekomunikuje se zařízením přímo, ale prostřednictvím hardwarové abstraktní vrstvy. Po splnění požadavku (např. zápis určitého množství dat) oznámí ovladač tuto skutečnost zpět I/O manageru, který o tom informuje původní volající aplikaci. Tím je celá operace skončena. Obrázek 3.1: Typický průběh zpracování vstupně-výstupního požadavku v OS Windows. Převzato z [5] Typy ovladačů Operační systém Windows podporuje celou škálu různých typů ovladačů. Jejich základní rozdělení může být provedeno podle prostředí, ve kterém ovladač pracuje. Z tohoto pohledu rozeznáváme jednak tzv. user-mode ovladače, pracující v uživatelském 3 Windows Application Programming Interface 14

26 3.1. VSTUPNĚ-VÝSTUPNÍ SYSTÉM WINDOWS prostoru operačního systému, a jednak kernel-mode ovladače, které jsou součástí jádra systému. Do skupiny user-mode ovladačů spadají například ovladače tiskáren [6]. Z našeho pohledu tato skupina ovladačů není významná a dále se jí zde zabývat nebudeme. Ovladače jádra systému (kernel-mode drivers) můžeme dále rozdělit do skupin podle obrázku 3.2: Obrázek 3.2: Typy ovladačů pracujících v jádře operačního systému. Převzato z [5].. File system drivers (ovladače souborového systému) jsou ovladače, které realizují souborový systém počítače. Legacy drivers jsou ovladače, které samy spravují určité hardwarové zařízení - tedy bez pomoci ostatních ovladačů, jak je běžné v ostatních skupinách. Tyto ovladače jsou pozůstatkem ze starších verzí systémů Windows NT a v současných verzích Windows pracují beze změny [5]. PnP drivers jsou ovladače, které spolupracují s PnP managerem a Power managerem, což umožňuje dynamické nahrávání těchto ovladačů při připojení zařízení za běhu systému. Většina PnP ovladačů se navíc řídí pravidly, která definuje tzv. Windows Driver Model (WDM). Popisu tohoto modelu se věnuje následující podkapitola. WDM ovladače můžeme rozdělit do čtyř skupin (viz obr. 3.2), z nichž jsou pro tuto práci podstatné dvě: 15

27 3.2. WINDOWS DRIVER MODEL Function driver (funkční ovladač) je hlavním ovladačem zařízení a ve většině případů bývá také spolu se zařízením dodáván. Jeho úkolem je vytvořit rozhraní mezi operačním systémem a zařízením, a tím umožnit plnohodnotné využívání všech funkcí zařízení. Filter driver je zvláštní typ ovladače, jehož prostřednictvím lze modifikovat funkci již existujícího funkčního ovladače. Již nyní můžeme předeslat, že ovladač vytvářený v této diplomové práci je právě filter driver. Z tohoto důvodu bude tomuto typu ovladače věnována pozornost ivnásle- dujících kapitolách. Princip řazení ovladačů do vertikální hiearchie, který s principem funkce filtru úzce souvisí, bude popsán v následující podkapitole. Podkapitola 4.2 se potom bude věnovat výlučně specifickým vlastnostem tohoto typu ovladače. 3.2 Windows Driver Model Windows Driver Model (WDM) je framework pro tvorbu ovladačů, který byl uveden postupně s příchodem operačních systémů Windows 98 a Windows Jeho hlavním cílem bylo umožnit přenositelnost zdrojového kódu ovladačů mezi jednotlivými verzemi Windows. Přitom byl kladen důraz i na dopřednou kompatibilitu. Všechny OS Windows až do současné verze Windows 7 tento model podporují. Důležitou vlastností modelu je také to, že nabízí množství prostředků, které usnadňují v ovladačích implementaci technologie Plug&Play Driver Stack Pro WDM je typické, že žádný ovladač nespravuje konkrétní zařízení zcela sám. Kompletní podpora každého zařízení je rozdělena vždy mezi několik ovladačů, z nichž každý vykonává část funkcí potřebných pro správný chod zařízení. Tyto ovladače jsou vzájemně uspořádány do hiearchické struktury zvané driver stack. Každé hardwarové zařízení spravují vždy minimálně dva ovladače - bus driver a function driver. Bus driver (ovladač sběrnice) je mimo jiné zodpovědný za detekci připojení zařízení a nachází se vždy zcela vespod konkrétního driver stacku, jak je znázorněno na obrázku 3.3. Ovladače tohoto typu dodává pro své operační systémy výhradně Microsoft [7]. Úloha funkčního ovladače byla popsána v části Některá zařízení mají více než jen dva výše jmenované ovladače. Tyto ostatní ovladače se obecně označují jako filter drivers. Jejich úlohou je rozšířit funkcionalitu 16

28 3.2. WINDOWS DRIVER MODEL či modifikovat chování již existujícího funkčního ovladače. Z obrázku 3.3 je patrné, že filter driver může pracovat buď nad funkčním ovladačem, anebo pod ním. V prvním případě se jedná o tzv. upper filter, druhý typ ovladače potom označujeme jako lower filter. I/O manager předá IRP, který je určen pro nějaké zařízení, vždy tomu ovladači, který je na vrchu příslušného driver stacku. Tento ovladač potom může se žádostí naložit dle svého uvážení. Může IRP pouze předat nižšímu ovladači, aniž by ho jakkoliv upravil. Může však také parametry IRP pozměnit a nebo ho nepředat vůbec a s negativním potvrzením ho vrátit zpět I/O manageru. V neposlední řadě může takový ovladač sám vytvořit IRP a poslat ho nižšímu ovladači, pokud od tohoto požaduje vykonání nějaké akce. V driver stacku na obrázku 3.3 se nachází jeden upper filter a jeden lower filter. Toto uspořádání však vůbec nemusí být pravidlem. Obou dvou typů filtrů může být i více. Vždy je ale zachováno jejich hierarchické řazení. Častá je situace, kdy má určité zařízení mezi svými ovladači hned několik ovladačů typu upper filter a žádný lower filter. To je i případ této diplomové práce, jak bude ukázáno v kapitole 4. Obrázek 3.3: Princip vrstvení ovladačů ve WDM. Převzato z [5].. 17

29 3.2. WINDOWS DRIVER MODEL Struktura WDM ovladače Každý WDM ovladač je souborem minimálně dvou datových struktur a několika funkcí, které systém volá při nahrávání ovladače do paměti a poté v různých fázích zpracování vstupně-výstupního požadavku. Základními funkcemi, které musí implementovat každý WDM ovladač, jsou: DriverEntry - tuto funkci zavolá I/O manager při nahrávání ovladače do paměti počítače. Jejím hlavním úkolem je předat I/O manageru adresy všech ostatních vstupních funkcí ovladače. Toho DriverEntry docílí vyplněním příslušných položek datové struktury driver object (viz dále). AddDevice funkci ovladače volá PnP manager v okamžiku, kdy detekuje připojení nového zařízení, které daný ovladač spravuje. V této funkci ovladač alokuje paměť pro datovou strukturu device object (viz dále) a obvykle také provede její inicializaci. dispatch rutiny tvoří hlavní část ovladače. Jejich úkolem je zpracování samotných vstupně-výstupních požadavků. Pro každý typ požadavku, který ovladač zamýšlí zpracovávat, si musí zaregistrovat jednu dispatch rutinu. Pro vyřízení vstupněvýstupního požadavku I/O manager nejprve vytvoří IRP reprezentující danou žádost. Poté zavolá příslušný ovladač skrze dispatch rutinu obsluhující daný typ požadavků a jako parametr jí předá tento IRP. unload rutina je volána v okamžiku, kdy má být ovladač uvolněn z paměti. V této funkci se provádí uvolnění všech ovladačem alokovaných systémových zdrojů, pokud k tomu již nedošlo dříve. Kromě těchto funkcí může WDM ovladač implementovat ještě například funkce pro obsluhu přerušení nebo funkce pro správu fronty IRP. Ovladač vyvíjený v této diplomové práci však žádné přerušení přímo neobsluhuje, ani neimplementuje frontu IRP, a proto zde tyto funkce nebudou blíže popsány. Pro více informací o těchto funkcích odkážeme čtenáře na [5] popř. [6]. Pro každý WDM ovladač jsou v různých okamžicích I/O managerem alokovány následující datové struktury: driver object je datová struktura reprezentující samotný ovladač v paměti počítače. Alokace paměťového prostoru pro tuto strukturu probíhá těsně před načtením 18

30 3.2. WINDOWS DRIVER MODEL ovladače do paměti. Jak už bylo řečeno výše, driver object obsahuje seznam adres všech dispatch rutin ovladače pro potřeby I/O manageru. Dále je v driver objectu uložen ukazatel na strukturu device object. device object reprezentuje samotné zařízení, ať už fyzické nebo logické, které ovladač spravuje. Pro každé takové zařízení je vytvořen jeden device object v okamžiku, kdy je zařízení detekováno. Kromě informací o zařízením samotném (mód přenosu dat, nároky na napájení...) obsahuje device object také ukazatel na datovou strukturu device extension. device extension je struktura která slouží pro ukládání dat souvisejících s konkrétním zařízením. Obsah této datové struktury libovolně definuje programátor ovladače podle svého uvážení. 19

31 Kapitola 4 Analýza a návrh řešení SW části Zadání diplomové práce požaduje, aby byly funkce stanice Master sběrnice Measurement Bus integrovány do operačního systému prostřednictvím ovladače jádra, pracujícího nad obecným ovladačem sériového portu. Z pohledu dělení zavedeného v minulé kapitole budu tedy programovat ovladač typu upper filter. V úvodu této kapitoly bude zdůvodněna volba tohoto řešení. V následující podkapitole budou popsána některá důležitá specifika týkající se obecně programování ovladačů typu filtr. Část této podkapitoly bude věnována způsobu instalace tohoto typu ovladače, která samotná může být za některých okolností poměrně problematická. V závěru kapitoly budou již konkrétně definovány požadavky na jednotlivé funkcionality vytvářeného ovladače. 4.1 Struktura SW řešení Pro lepší orientaci v následujících kapitolách považuji za vhodné na tomto místě podat vysvětlení toho, proč je stanice Master implementována právě prostřednictvím filtru pracujícího nad ovladačem sériového portu. Jak bylo řečeno v samotném úvodu této práce, pro připojení osobního počítače ke sběrnici Measurement Bus bude využito fyzické rozhraní EIA-485, připojitelné k počítači přes USB. Jak bude popsáno v kapitole 6, jádrem tohoto zařízení je čip FT232R. Ten zajišťuje převod dat z formátu protokolu USB na standardní sériový formát. Důležité je, že pro zpřístupnění funkcí tohoto čipu aplikacím je k němu dodáván ovladač, který v systému vytvoří virtuální sériový port. Pomocí filtru pracujícího nad tímto ovladačem pak můžeme modifikovat jeho funkci tak, aby simuloval chování stanice Master sběrnice Measurement Bus. Struktura popisovaného softwarového řešení je potom dobře patrná z obrázku

32 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR Obrázek 4.1: Struktura navrhovaného softwarového řešení. FTDIBUS.SYS je funkčním ovladačem čipu FT232R. FTSER2K.SYS je filtr, který vytváří virtuální sériový port. Tyto dva ovladače jsou dodávány výrobcem čipu v jednom balíku a instalují se společně. SERENUM.SYS je filtr od firmy Microsoft, který je dodávaný spolu s operačním systémem. K jeho zaregistrování do driver stacku dojde při instalaci ovladače virtuálního portu, jehož *.inf soubor obsahuje příkaz, který se o to zaslouží. Funkce tohoto ovladače je popsána např. v [5], z hlediska této práce však není nijak podstatná. Konečně MEASBUS.SYS je ovladač vytvořený v této práci. Pro úplnost je v obrázku uvedena i knihovna MEASBUS.DLL, která tvoří rozhraní tohoto ovladače do uživatelského prostoru. Ovladač MEASBUS.SYS je samozřejmě možné použít ivkombinacisklasickým sériovým portem. V tom případě by byl v driver stacku namísto ovladače hostitelského řadiče USB a ovladačů FTXXX.SYS standardní ovladač sériového portu SERIAL.SYS. 4.2 Specifika ovladačů typu filtr Jak bylo řečeno v minulé kapitole, úkolem ovladače typu filtr je modifikovat chování již existujícího funkčního ovladače zařízení. Podle toho, zda-li je filtr v příslušném driver stacku nad nebo pod funkčním ovladačem, rozeznáváme upper filter a lower filter driver. Princip tvorby obou těchto typů ovladačů je naprosto totožný. Vnitřní 21

33 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR struktura ovladače typu filtr je stejná jako u kteréhokoliv jiného WDM ovladače. Filtr tedy jako ostatní ovladače implementuje funkce DriverEntry, AddDevice, DriverUnload a samozřejmě dispatch rutiny pro IRP, které hodlá "filtrovat". Přesto jsou zde oproti funkčním ovladačům některé drobné rozdíly, které budou popsány v následujících sekcích Funkce DriverEntry Funkce DriverEntry je implementována stejně jako u každého jiného ovladače s tím rozdílem, že filtr si musí zaregistrovat dispatch rutiny pro všechny typy IRP. Tedy nejenom pro ty, které hodlá sám v rámci svého poslání zpracovávat. Důvod je ten, že filtr implicitně nemá informace o tom, které druhy IRP podporuje ovladač pod ním. Proto musí filtr všechny IRP, které obdrží a které nehodlá sám nijak upravovat, předat nižšímu ovladači. Typická implementace DriverEntry potom vypadá následovně: NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { DriverObject->DriverUnload = DriverUnload; DriverObject->DriverExtension->AddDevice = AddDevice; for (int i = 0; i < arraysize(driverobject->majorfunction); ++i) DriverObject->MajorFunction[i] = PassThrough; DriverObject->MajorFunction[IRP_MJ_POWER] = DispatchPower; DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp; DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchIoctl; return STATUS_SUCCESS; } Zde je nejprve jako dispatch rutina pro všechny typy IRP zaregistrována funkce s názvem PassThrough. Tato funkce pouze přepošle obdržený IRP nižšímu ovladači z driver stacku. Pro IRP, do jejichž zpracování hodlá ovladač nějakým způsobem zasahovat, si poté musí zaregistrovat již konkrétní dispatch rutiny. V uvedeném příkladu se tak děje pro IRP typů POWER, PNP a DEVICE_CONTROL. Funkce PassThrough z minulého příkladu může být potom implementována následujícím způsobem: NTSTATUS PassThrough(PDEVICE_OBJECT fido, PIRP Irp) { PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fido->deviceextension; NTSTATUS status = IoAcquireRemoveLock(&pdx->RemoveLock, Irp); 22

34 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR if (!NT_SUCCESS(status)) return CompleteRequest(Irp, status, 0); IoSkipCurrentIrpStackLocation(Irp); status = IoCallDriver(pdx->LowerDeviceObject, Irp); IoReleaseRemoveLock(&pdx->RemoveLock, Irp); return status; } Předání IRP nižšímu ovladači se děje prostřednictvím volání funkce IoCallDriver. Prvním parametrem předávaným této funkci je adresa device objectu patřícího ovladači, kterému IRP posíláme. Tuto adresu lze získat ve funkci AddDevice při začleňování filtru do driver stacku (viz níže). Zde byla uložena do struktury device extension. Druhým parametrem je potom adresa předávaného IRP Funkce AddDevice Úkolem této funkce je vytvořit device object a zařadit ho na příslušné místo v daném driver stacku. Device object je vytvořen stejně jako u funkčního ovladače voláním funkce IoCreateDevice, která vrací ukazatel na nově vytvořený objekt. Zařazení objektu do driver stacku se potom provede voláním funkce IoAttachDeviceToDeviceStack. V případě úspěchu tato funkce vrátí ukazatel na nižší device object. Prostřednictvím tohoto ukazatele je potom možné posílat IRP nižšímu ovladači, jak bylo ukázáno v předchozí části. Funkční ovladače také ve funkci AddDevice nastavují některé parametry device objectu, které vypovídají o různých vlastnostech zařízení, jako například jaký mód přenosu dat (přímý/bufferovaný) dané zařízení podporuje. Jedná se o tzv. device flags. Filter driver tyto flagy sám přímo nenastavuje, ale kopíruje je z device objectu pod ním. I/O manager totiž čte tyto flagy z device objectu, který je na vrcholu driver stacku [5] PnP a Power management Obsluha IRP typu power a PnP, jejíž správná implementace patří u funkčních ovladačů k těm nejtěžším úkolům, je u ovladačů typu filtru jednoduchá. Je to dáno tím, že ovladač tohoto typu přímo neřídí žádný hardware, který by bylo třeba konfigurovat při změně režimu napájení. To je povinností funkčních ovladačů. Ovladače typu filtr ani neimplementují žádné fronty IRP [5]. Odpadá tedy nutnost spravovat tyto fronty při přechodech mezi jednotlivými stavy Plug&Play. Pokud filter driver neimplementuje žádné fronty IRP, pak také nemusí provádět rušení čekajících IRP v okamžiku obdržení požadavku na vyjmutí zařízení. 23

35 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR V knize [5] je uveden způsob typické implementace dispatch rutiny pro IRP typu POWER: NTSTATUS DispatchPower(PDEVICE_OBJECT fido, PIRP Irp) { PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fido->deviceobject; PoStartNextPowerIrp(Irp); NTSTATUS status = IoAcquireRemoveLock(&pdx->RemoveLock, Irp); if (!NT_SUCCESS(status)) return CompleteRequest(Irp, status, 0); IoSkipCurrentIrpStackLocation(Irp); status = PoCallDriver(pdx->LowerDeviceObject, Irp); IoReleaseRemoveLock(&pdx->RemoveLock, Irp); return status; } V podstatě se jedná o obdobu funkce PassThrough z části Paket je pouze předán nižšímu ovladači. Voláním funkce PoStartNextPowerIrp dává ovladač na vědomí Power manageru, že je schopen přijmout další IRP typu POWER. Od Windows Vista nemá volání této funkce již žádný efekt [8]. PoCallDriver je obdobou funkce IoCallDriver pro IRP typu POWER Instalace Aby byl filtr načten do driver stacku určitého zařízení, musí být zapsán do položky UpperFilters resp. LowerFilters v hardwarovém klíči daného zařízení v systémovém registru. Kromě toho musí být PnP manageru sdělena cesta k binárnímu souboru ovladače, aby mohl v případě potřeby ovladač nahrát do paměti. Pokud je filtr instalován spolu s funkčním ovladačem pro dané zařízení, pak pro splnění výše zmíněného postačí přidat do některých sekcí *.inf souboru funkčního ovladače následující kód: [DriverCopyFiles] filterdriver.sys... ;sekce pro kopírování souborů na disk ;zkopíruje soubor ovladače na disk [xxxxxxx.nt.services] AddService=jmenoSluzby,2,FunctionDriverService AddService=jmenoSluzbyFiltru,,FilterDriverService ;pro funkční ovladač ;pro filtr [FilterDriverService] ServiceType=1 ;jedná se o ovladač jádra systému 24

36 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR ErrorControl=1 ;při neúspěšném načtení pouze zobrazit varování StartType=3 ;ovladač načten až při detekci zařízení ServiceBinary=%12%\filterDriver.sys ;umístění souboru na disku [FilterAddReg] HKR,,UpperFilters,0x ,filterDriver ;sekce modifikující registr ;přidání jména ovladače ;do položky UpperFilters Při instalaci spodního filtru bychom v sekci modifikující registr přidávali záznam do položky LowerFilters, ostatní sekce by se ničím nelišily. Filtrů muže být v položce UpperFilters resp. LowerFilters uvedeno i více. V takovém případě rozhoduje pořadí, v jakém jsou filtry v těchto položkách uvedeny, o pořadí, v jakém budou načteny do příslušného driver stacku. Problém nastává, pokud chceme provést instalaci filtru pro nějaké zařízení až dodatečně. Tedy potom, co již byl pro zařízení nainstalován funkční ovladač. Opět je v registru potřeba přidat záznam do položky UpperFilters nebo LowerFilters v hardwarovém klíči daného zařízení. Zde ale nastává problém s určením jména tohoto hardwarového klíče. Windows nenabízí žádnou podporu instalace filtru pro již existující zařízení, a tak nezbývá než vyhledat a modifikovat příslušný hardwarový klíč ručně [5]. Hardwarové klíče zařízení se v registru nacházejí v adresáři HKEY_LOCAL_MACHINE \System \CurrentControlSet\Enum. V některých případech můžeme tento problém obejít. Jedná se o případy, kdy zařízení, pro nějž instalujeme filtr, spadá do některé ze systémem definovaných tříd zařízení. Microsoft ve svých operačních systémech definuje zhruba třicet různých tříd zařízení (device setup classes). Pro příklad můžeme jmenovat třeba třídy Mouse, Modem, Printer, CD-ROM nebo Ports. Kompletní výčet těchto tříd i s popisem můžeme nalézt například v [5]. V takovém případě můžeme nainstalovat filtr pro celou takovou třídu zařízení. Jendá se o tzv. class filter. Nainstalujeme-li class filtr pro určitou třídu zařízení, pak bude tento filtr zařazen do driver stacku každého zařízení z této třídy. Class filtr je tedy načten do systému v okamžiku, kdy je detekováno první zařízení spadající do dané třídy, a uvolněn teprve až jsou všechna taková zařízení odpojena. Instalace class filtru je jednoduchá, protože každá třída zařízení má přiřazený jednoznačný identifikátor (GUID 1 ). Jedná se o hexadecimální kód ohraničený složenými závorkami. Identifikátory všech systémem předdefinovaných tříd je možno nalézt v hlavičkovém souboru devguid.h, který je součástí Windows Driver Kitu. V *.inf souboru pro instalaci class filtru pak postačí do sekce modifikující registr přidat následující 1 globally unique identifier 25

37 4.2. SPECIFIKA OVLADAČŮ TYPU FILTR záznam: [AddReg] ;sekce modifikující registr HKLM, System\CurrentControlSet\Control\Class\GUID, UpperFilters, 0x , filterdriver kde GUID je identifikátor třídy, pro kterou je filtr instalován, a filterdriver je jméno binárního souboru filtru (bez přípony). Tímto dojde k zapsání jména ovladače do položky UpperFilters v klíči třídy (class key) v systémovém registru. Opět, pokud bychom instalovali spodní filtr, museli bychom záznam přidat do položky LowerFilters. Ostatní sekce takového *.inf souboru jsou stejné jako u souboru pro instalaci funkčního ovladače. Pro úplnost zde ještě uvedu, v jakém pořadí jsou jednotlivé typy filtrů zařazovány do driver stacku. Situace je dobře patrná z obrázku 4.2. Nejníže bude do stacku zařazen filtr jako první uvedený v položce LowerFilters v hardwarovém klíči příslušného zařízení. Nejvýše bude naopak filtr, který je jako poslední uvedený v položce UpperFilters v klíči třídy, do které zařízení náleží. Obrázek 4.2: Pořadí vertikálního řazení různých typů filtrů. Převzato z [5]. 26

38 4.3 Volba vhodného typu filtru 4.3. VOLBA VHODNÉHO TYPU FILTRU Z předchozí kapitoly vyplývá, že pokud chceme, aby náš ovladač pracoval nad virtuálním sériovým portem tak, jak bylo znázorněno v obrázku 4.1, máme na výběr dvě možnosti jeho instalace. První z nich je nainstalovat filtr spolu s ovladači pro čip FT232R. K tomu by bylo potřeba upravit soubor ftdibus.inf, který slouží pro instalaci funkčního ovladače čipu. Toto řešení by s sebou však neslo velké množství nevýhod. Předně by nebylo možné zaručit, že bude modifikovaný *.inf soubor kompatibilní s aktualizovanými verzemi ovladačů čipu, které mohou být v budoucnu uvedeny. Dále by tento způsob instalace neumožnil použít ovladač s klasickým (ne virtuálním) sériovým portem. Lepším řešením je nainstalovat ovladač jako class filter pro celou třídu zařízení Porty (Ports). Do této třídy zařízení spadají porty COM a LPT. Ovladač tak bude automaticky načten pro každý sériový port, tedy klasický i virtuální. Nevýhodou tohoto řešení je, že ovladač bude načten i pro ty porty, na kterých jeho funkce uživatel v daný okamžik nehodlá využívat. V tomto případě však ovladač žádným způsobem funkci portu neovlivňuje. Všechny IRP, které obdrží, ihned předá nižšímu ovladači. Ovladač také, pokud není jeho funkcionalita přímo využívána, nealokuje explicitně žádnou paměť. V paměti tedy zabírá pouze tolik místa, kolik je potřeba pro jeho driver object, device object a device extension, a to jsou zanedbatelné datové objemy. 4.4 Požadavky na funkce ovladače Úkolem ovladače je implementovat funkce stanice Master. To s sebou nese povinnost periodicky dotazovat účastnické stanice, přijímat od nich data v případě, že nějaká mají, popř. jim naopak data posílat. To vše podle komunikačního protokolu definovaného standardem. Pokud by byl ovladač implementován pouze s touto základní funkcionalitou, docházelo by k zbytečně dlouhým odezvám v případě malého počtu připojených stanic. To kvůli povinnosti dotazovat všechny vysílací adresy - tedy i těch stanic, které nejsou připojeny. Z tohoto důvodu je dobré, aby měl uživatel možnost zadat adresy stanic, které mají být dotazovány. Tímto cíleným dotazováním dojde ke snížení doby odezvy účastnických stanic na minimum. Dalším požadavkem je zavést do cyklu dotazování prioritní schéma, které by umožnilo dotazovat zvolené stanice častěji než jiné. Jistě mohou být v jeden okamžik připojena ke sběrnici zařízení, z nichž některá vyžadují častější přenos dat než ostatní. Zavedením takového prioritního algoritmu, kdy budou některé stanice dotazovány častěji na úkor 27

39 4.4. POŽADAVKY NA FUNKCE OVLADAČE ostatních, dojde ke zvýšení flexibility celého řešení. Při řízení komunikace po sběrnici může dojít k několika událostem, na které by měl mít uživatel možnost reagovat. Konkrétně se jedná o případ, kdy některá z účastnických stanic přestane odpovídat, nebo naopak když opětovně začne odpovídat po předchozí odmlce. Další takovou událostí je samotné přijmutí datového bloku od účastnické stanice. Proto je dalším požadavkem, aby ovladač nabízel možnost jak uživatelskou aplikaci o těchto událostech informovat. V neposlední řadě je vhodné, aby ovladač obsahoval vnitřní vyrovnávací paměť. A to jak pro příchozí tak odchozí zprávy. Tím se redukuje možnost ztráty dat v případě, pokud nedojde k jejich včasnému odeslání nebo přečtení. Na závěr shrnu výše jmenované hlavní požadavky do následujícího výčtu: selektivní dotazování vybraných účastnických stanic možnost volby priority jednotlivých účastnických stanic signalizace významných událostí uživatelské aplikaci vnitřní vyrovnávací paměť pro příchozí i odchozí zprávy 28

40 Kapitola 5 Popis implementace V této kapitole je proveden detailní popis implementace jak samotného ovladače, tak i knihovny, která vytváří rozhraní ovladače pro uživatelské aplikace. První část kapitoly je věnována knihovně. Zde je vysvětlen význam datových typů, které knihovna definuje, a proveden výčet exportovaných funkcí. Kompletní dokumentaci těchto funkcí je potom možno nalézt v příloze B této práce. V druhé části kapitoly je proveden rozbor implementace ovladače. Zde jsou mimo jiné popsány jednotlivé logické celky tvořící ovladač, datové struktury, které jsou využívány pro reprezentaci jednotlivých stanic, nebo stavový automat, který implementuje samotný komunikační protokol. 5.1 Knihovna Dynamicky linkovaná kihovna vytváří přehledné rozhraní ovladače pro uživatelské aplikace. Knihovna definuje dva jednoduché datové typy, jednu datovou strukturu, tři pojmenované události (named events) a exportuje patnáct funkcí. Binární soubor knihovny measbus.dll je možno nalézt v adresáři \bin na CD doprovázejícím tuto práci. Pro využití této knihovny v uživatelské aplikaci je do ní třeba vložit hlavičkový soubor measbus_dll.h, umístěný na CD v adresáři \src \dll. Jednotlivé exportované funkce jsou implementovány ve zdrojovém souboru measbus_dll.cpp, který je možno nalézt v tomtéž adresáři Použité prostředky K programování a překladu knihovny bylo použito vývojové prostředí Microsoft Visual Studio 2008 (verze ) a překladač v něm obsažený. 29

41 5.1. KNIHOVNA Definované datové typy MB_HANDLE Tento datový typ slouží pro uchování handle na sériový port, který uživatel obdrží po zavolání exportované funkce MbOpenSerialPort (viz dále). Voláním této funkce dojde k namapování komunikace na požadovaný sériový port. Z tohoto důvodu je proměnná typu MB_HANDLE vstupním parametrem všech ostaních exportovaných funkcí. Ovladač totiž umožňuje, aby v počítači současně běželo více stanic typu Master, každá využívající jiný sériový port. Proto, když je volána některá z exportovaných funkcí, musí být specifikována konkrétní Master stanice, na kterou je tato funkce cílená. Toho je dosaženo právě předáváním parametru typu MB_HANDLE, který specifikuje port, který vybraná Master stanice využívá. MB_STATUS Návratová hodnota některých exportovaných funkcí je typu MB_STATUS. Konkrétně se jedná o funkce, které aktivují nebo deaktivují stanici Master a jednotlivé účastnické stanice. Tento datový typ je jednobajtový a jak název napovídá, obsahuje v sobě informaci o aktuálním stavu konkrétní stanice. Tato informace má pro účastnickou stanici formát podle tabulky 5.1. Pro stanici Master je formát obdobný ale platné jsou pouze flagy RF a MF. bit význam NR2 NR1 LAF RF MF Tabulka 5.1: Formát status byte účastnické stanice. Význam jednotlivých bitů je následující: NR2 - No Response 2, nastaven, pokud účastnická stanice dvakrát za sebou neodpoví na výzvu řídicí stanice NR1 - No Response 1, nastaven, pokud účastnická stanice neodpoví na výzvu řídicí stanice LAF - Last Activity Flag, nastaven, pokud byla účastnická stanice v posledním komunikačním kole dotazována na příjem RF - Ready Flag, nastaven, pokud je účastnická stanice aktivována (tj. je-li dotazována) 30

42 5.1. KNIHOVNA MF - Message Flag, nastaven, je-li ve vyrovnávací paměti účastnické stanice jedna nebo více neodeslaných zpráv MB_MSG Jedná s o datovou strukturu, prostřednictvím které vyčítá uživatelská aplikace jednotlivé přijaté datové bloky z příchozí vyrovnávací paměti ovladače. K tomu slouží exportovaná funkce MbRead (viz dále), jejímž parametrem je ukazatel na tuto strukturu, pro níž musí uživatel alokovat místo v paměti. Jednotlivé položky struktury jsou popsány v tabulce 5.2. struktura MB_MSG proměnná význam UCHAR stationnumber číslo stanice, od které pochází blok UCHAR datalength počet znaků v bloku BOOLEAN completemessage kompletní zpráva / pouze blok zprávy UCHAR data[128] buffer pro data Tabulka 5.2: Formát datové struktury MB_MSG Exportované funkce Funkce exportované knihovnou musí být deklarovány s direktivou declspec(dllexport). Naopak aplikace, která hodlá exportované funkce volat, musí tyto deklarovat s direktivou declspec(dllimport). Aby bylo možno využít jednoho hlavičkového souboru definujícího prototypy exportovaných funkcí jak v aplikaci, tak v knihovně samotné, bylo definováno makro MBDLL_API následujícím způsobem: #ifdef MBDLL_EXPORTS #define MBDLL_API declspec(dllexport) #else #define MBDLL_API declspec(dllimport) #endif Před deklaraci každé exportované funkce je potom namísto direktivy přidáno jméno tohoto makra. Ve zdrojovém souboru knihovny je ještě před vložením hlavičkového souboru definována symbolická konstanta MBDLL_EXPORTS. Tím dojde k rozvoji makra MBDLL_API v požadovanou direktivu declspec(dllexport). Do uživatelské aplikace pak může být hlavičkový soubor vložen bez jakýchkoliv úprav. 31

43 5.1. KNIHOVNA Kromě výše zmíněného makra obsahuje deklarace každé funkce v hlavičkovém souboru knihovny klíčové slovo extern C. Přidání tohoto klíčového slova do deklarace funkce způsobí, že překladač nebude přidávat ke jménu exportované funkce tzv. dekorace. Ty totiž mohou později způsobit problémy při volání knihovní funkce z uživatelské aplikace. Příkladem může být aplikace vytvořená v této práci za účelem testování ovladače. Tato aplikace, která je blíže popsána v kapitole 7.2, je naprogramovaná v jazyce C#. Platforma.NET využívá k volání funkcí z DLL knihoven mechanismus P/Invoke [9]. Ten zprostředkovává přechod z řízeného kódu do Windows API. Sám jsem se přesvědčil, že pokud je jméno exportované funkce opatřeno dekoracemi, P/Invoke ji v knihovně není schopen lokalizovat. Přidání extern C před deklaraci funkce řeší tento problém. Jak již bylo řečeno, knihovna exportuje celkem patnáct funkcí. Podle jejich účelu můžeme tyto rozdělit do čtyř skupin: obsluha sériového portu, management řídicí stanice, management účastnické stanice a čtení/zápis dat. Následovat bude pouze výčet jednotlivých funkcí s krátkým popisem. Pro zvýšení přehlednosti je kompletní dokumentace všech funkcí uvedena až v příloze B této práce. Funkce pro obsluhu sériového portu MbOpenSerialPort otevře vybraný sériový port a nastaví uživatelem požadovanou přenosovou rychlost. Ostatní parametry sériového portu (počet datových bitů, parita, počet stop bitů...) jsou nastaveny podle standardu Measurement Bus. Kromě toho funkce provede komunikaci s ovladačem. Jednak proto, aby ověřila přítomnost ovladače v systému, a jednak, aby ovladači předala hodnotu nastavené přenosové rychlosti. Tu ovladač potřebuje znát pro odvození délky hlídacích časů podle vztahů 2.1 a 2.2. V neposlední řadě tato funkce vytvoří tři pojmenované události (viz 5.1.4) a ukazatele na tyto události taktéž předá ovladači. MbCloseSerialPort uzavře definovaný sériový port. Zavolání této funkce znamená konec využívání portu pro účely komunikace po sběrnici Measurement Bus. Proto funkce také předá zprávu o uzavírání portu ovladači, který na tomto základě provede některé úklidové operace. Funkce pro management řídicí stanice MbMasterEnable aktivuje řídicí stanici. To znamená, že je započato periodické dotazování všech aktivních účastnických stanic. 32

44 5.1. KNIHOVNA MbMasterDisable naopak deaktivuje řídicí stanici a tím přeruší dotazování účastnických stanic. MbGetMasterStatus vrátí status byte řídicí stanice. MbMasterReset vymaže vyrovnávací paměť 1 pro příchozí zprávy. Dále vymaže vyrovnávací paměť 2 a status flagy každé účastnické stanice. Zároveň je priorita každé účastnické stanice nastavena na defaultní hodnotu 1. Funkce pro management účastnické stanice MbSlaveEnable aktivuje vybranou účastnickou stanici. To znamená, že stanice bude periodicky dotazována řídicí stanicí, pokud je tato aktivní. MbSlaveDisable deaktivuje vybranou účastnickou stanici, která dále již nebude dotazována řídicí stanicí. MbGetSlaveStatus vrátí status byte vybrané účastnické stanice. MbSlaveReset vymaže vyrovnávací paměť a status flagy účastnické stanice. Priorita účastnické stanice je nastavena na defaultní hodnotu 1. MbGetSlavePriority vrátí aktuálně nastavenou hodnotu priority vybrané účastnické stanice. MbChangeSlavePriority nastaví prioritu vybrané účastnické stanice. Funkce pro čtení a zápis dat MbRead přečte jeden datový blok z vyrovnávací paměti pro příchozí zprávy. MbWrite zapíše data do vyrovnávací paměti účastnické stanice. Odtud budou tato data při nejbližší příležitosti stanici odeslána. Buffer s daty předávaný této funkci může mít i více jak 128 znaků. Ovladač sám později data rozdělí do jednotlivých datových bloků. 1 Jedná se o hromadnou vyrovnávací paměť pro příchozí zprávy od všech účastnických stanic. 2 Každá účastnická stanice má vlastní vyrovnávací paměť pro odchozí zprávy. 33

45 5.1. KNIHOVNA Pojmenované události Jedním z požadavků definovaných v kapitole 4.4 bylo, aby ovladač nabízel možnost, jak informovat uživatelskou aplikaci o příjmu datového bloku nebo o ztrátě/navázání komunikace s účastnickou stanicí. Ovladač tak činí prostřednictvím tří pojmenovaných událostí (named events). Protože je však snažší vytvořit pojmenovanou událost v uživatelském prostoru než v jádře systému [10], byl zvolen následující způsob implementace. Pojmenované události jsou vytvořeny v knihovně při volání funkce MbOpenSerialPort a následně jsou handle na tyto události předány ovladači. Uživatelská aplikace potom může získat handle na jednotlivé události voláním funkce CreateEvent z Windows API, kde jako poslední parametr této funkci předá jméno příslušné události. Jména všech tří událostí jsou definována v hlavičkovém souboru knihovny a uvedena v tabulce 5.3. Název MB_RECEIVE_EVT MB_NO_RESPONSE_EVT MB_RECONNECT_EVT Událost příjem datového bloku ztráta komunikace s účastnickou stanicí obnovení komunikace s účastnickou stanicí Tabulka 5.3: Výčet pojmenovaných událostí Komunikace s ovladačem Knihovna komunikuje s ovladačem výhradně prostřednictvím volání funkce DeviceIo- Control z Windows API, která má za následek vznik IRP s kódem IRP_MJ_DEVICE_ CONTROL, který poté ovladač obdrží. Prvním z parametrů předávaných této funkci je handle na zařízení, pro které je řídicí operace určena. V našem případě se jedná o handle na sériový port, který uživatel obdrží voláním exportované funkce MbOpenSerialPort a který předává jako parametr při volání ostatních exportovaných funkcí pro specifikaci sériového portu, jak bylo popsáno v Dalším parametrem předávaným funkci DeviceIoControl je kontrolní (IOCTL 3 ) kód, který přesně definuje, o jakou řídicí operaci se jedná. Definice těchto kódů musí být přístupny jak ovladači, tak knihovně, proto jsou umístěny ve zvláštním hlavičkovém souboru measbus_ioctl.h. Výčet všech IOCTL kódů i s popisem jejich významu je proveden v části Ještě dodejme, že všechny IRP tohoto typu jsou v ovladači obslouženy ihned, proto je volání funkce DeviceIoControl vždy provedeno jako blokující. 3 I/O control 34

46 5.2. OVLADAČ 5.2 Ovladač Použité prostředky Pro překlad ovladače byl použit překladač obsažený v produktu Windows Driver Kit verze Pro ladění ovladače byl použit program WinDbg verze X86 a dále program VMware Server 2 pro vytvoření virtuálního počítače, ve kterém ovladač pracoval. Při nastavování operačních systémů v hostitelském a cílovém (virtuálním) počítači bylo postupováno podle návodu uvedeného v diplomové práci [11] Struktura ovladače Podle funkcí, které zastávají, můžeme ovladač rozdělit na tři logické celky. Tomu také odpovídá rozdělení zdrojového kódu ovladače do tří samostatných souborů. První logický celek, implementovaný ve zdrojovém souboru measbus.c, zajišťuje základní funkce ovladače jako takového - načtení do paměti, vytvoření device a driver objectu, obsluha PnP a Power požadavků a uvolnění z paměti. Jsou zde implementovány funkce Driver- Entry, MbAddDevice, MbUnload (volána při uvolňování ovladače z paměti 4 ), MbPnP (dispatch rutina pro IRP typu PnP) a MbPower (dispatch rutina pro IRP typu Power.) Kromě toho je zde také implementována funkce MbPassThrough, která slouží pro přeposílání IRP nižším ovladačům. Druhým logickým celkem je část umožňující komunikaci ovladače s uživatelským prostorem, konkrétně v našem případě s knihovnou. Je zde implementována funkce MbIoctl - dispatch rutina pro IRP s kódem IRP_MJ_DEVICE_CONTROL. Tato část se nachází ve zdrojovém souboru measbus_ioctl.c a kromě již zmíněné funkce MbIoctl obsahuje několik dalších pomocných funkcí. Jsou to například funkce Start- Thread a StopThread, sloužící pro vytvoření a ukončení vlákna systémového procesu, ve kterém běží stavový automat ovladače (viz dále). Potom například funkce MbGet- Timeouts, která vypočítá hodnoty hlídacích časů komunikace podle nastavené baud rate. Účel každé takové pomocné funkce je spolu s významem jejích parametrů popsán přímo v dotyčném zdrojovém souboru. Třetím a posledním celkem ovladače je část vykonávající samotnou funkci stanice Master. Tato část je implementována ve zdrojovém souboru measbus_state_machine.c. Zde se nachází funkce MbStateMachine, která je vykonávána v samostatném vlákně. Úkolem této funkce je periodicky dotazovat všechny aktivní účastnické stanice, popřípadě od nich přijímat nebo jim naopak posílat data. To vše podle daného komu- 4 implementace takové funkce je u WDM ovladačů povinná 35

47 5.2. OVLADAČ nikačního protokolu, který je zde implementován formou stavového automatu. Této části bude věnována náležitá pozornost v sekci Základní datové struktury V hlavičkovém souboru measbus.h jsou kromě samotné DEVICE_EXTENSION deklarovány následující čtyři datové struktury: MB_MASTER Tato datová struktura slouží pro reprezentaci řídicí stanice. Výčet jednotlivých položek struktury je uveden v tabulce 5.4. V DEVICE_EXTENSION je uložena jedna proměnná tohoto typu s názvem master. Z tabulky je patrné, že ukazatele na datové bloky uložené v kruhovém bufferu 5 i na buffer samotný jsou typu PINPUT_MESSAGE. Jednotlivé bloky dat jsou totiž ve vyrovnávací paměti uloženy ve strukturách IN- PUT_MESSAGE. Formát této datové struktury bude popsán dále. struktura MB_MASTER proměnná význam UCHAR status status byte řídicí stanice PINPUT_MESSAGE inputbuffer ukazatel na začátek kruhového bufferu PINPUT_MESSAGE writepointer ukazatel na první volný slot v bufferu PINPUT_MESSAGE readpointer ukazatel na nejstarší datový blok v bufferu LONG messagecount počet datových bloků v kruhovém bufferu Tabulka 5.4: Formát datové struktury MB_MASTER. MB_SLAVE Tato datová struktura reprezentuje účastnickou stanici. V DEVICE_EXTENSION je uloženo datové pole s názvem slave, které sestává z dvaatřiceti proměnných tohoto typu. Každá taková proměnná potom reprezentuje jednu konkrétní účastnickou stanici 6. Formát struktury MB_SLAVE popisuje tabulka 5.5. Každá takto reprezentovaná účastnická stanice má vlastní vyrovnávací paměť pro odchozí zprávy. Z tabulky je patrné, že jednotlivé zprávy jsou v této paměti uloženy ve formě datových struktur OUTPUT_MESSAGE, které budou popsány dále. 5 jedná se o hromadný buffer pro všechny příchozí zprávy 6 zvláštní poslání má stanice s číslem 0, viz

48 5.2. OVLADAČ struktura MB_SLAVE proměnná význam UCHAR stationnumber číslo účastnické stanice ULONG stationpriority priorita účastnické stanice UCHAR status status byte účastnické stanice POUTPUT_MESSAGE outputbuffer ukazatel na začátek kruhového bufferu POUTPUT_MESSAGE writepointer ukazatel na první volný slot v bufferu POUTPUT_MESSAGE readpointer ukazatel na nejstarší datový blok v bufferu LONG messagecount počet datových bloků v kruhovém bufferu Tabulka 5.5: Formát datové struktury MB_SLAVE. INPUT_MESSAGE Přijaté datové bloky jsou v příchozím bufferu pro jeho snažší správu a větší přehlednost uloženy v datových strukturách INPUT_MESSAGE. Struktura INPUT_MESSAGE sdružuje všechny informace o přijatém datovém bloku. Položky této struktury jsou vyjmenovány v tabulce 5.6. struktura INPUT_MESSAGE proměnná význam UCHAR stationnumber číslo stanice od které blok pochází UCHAR datalength počet znaků v datovém bloku BOOLEAN completemessage celá zpráva / pouze blok zprávy UCHAR data[128] přijatá data Tabulka 5.6: Formát datové struktury INPUT_MESSAGE. OUTPUT_MESSAGE Jednotlivé bloky zprávy, která má být odeslána účastnické stanici, jsou ve výstupní vyrovnávací paměti této stanice uloženy ve strukturách OUTPUT_MESSAGE. Důvody pro toto uspořádání jsou obdobné jako v případě bufferu pro příchozí data. Datová struktura OUTPUT_MESSAGE má formát podle tabulky 5.7. Pole pro uložení datového bloku má tentokrát 129 bytů. Datový blok je do něj totiž pro pozdější snažší odesílání ukládán včetně řídicího znaku ETX resp. ETB. 37

49 5.2. OVLADAČ struktura OUTPUT_MESSAGE proměnná význam UCHAR datalength počet znaků v datovém bloku UCHAR data[129] datový blok UCHAR bcc BCC datového bloku Tabulka 5.7: Formát datové struktury OUTPUT_MESSAGE Obsluha IOCTL žádostí Jak již bylo řečeno, všechny IRP s kódem IRP_MJ_DEVICE_CONTROL jsou obslouženy ve funkci MbIoctl, implementované ve zdrojovém souboru measbus_ioctl.c. Zde se nachází také několik pomocných funkcí, které MbIoctl volá pro zpracování některých komplikovanějších žádostí tohoto typu. Následuje výčet všech podporovaných IOCTL kódů a popis obsluhy žádostí, které IRP s těmito kódy reprezentují. Podporované IOCTL kódy: IOCTL_ON_PORT_OPEN Tuto žádost pošle knihovna ovladači, když uživatel zavolá exportovanou funkci MbOpenSerialPort. Hlavním smyslem žádosti je ověřit, zda je ovladač vůbec v systému přítomen. Kromě toho ovladač předá knihovně přes buffer příslušného IRP jeden speciální znak. Tento znak knihovna posléze uloží do položky ErrorChar DCB struktury, která slouží pro nastavení parametrů sériového portu. Jedná se o znak, kterým později ovladač sériového portu nahradí všechny přijaté znaky, u nichž odhalí chybu parity. Při kontrole správnosti přijatých dat musíme potom v našem ovladači kontrolovat přítomnost tohoto znaku. Posledním úkolem při obsluze této žádosti je vytvoření vlákna, ve kterém bude vykonáván stavový automat. Toho je dosaženo voláním pomocné funkce StartThread. IOCTL_PASS_EVENT_HANDLES V bufferu IRP s tímto kódem předává knihovna ovladači handle na tři pojmenované události, které byly popsány v části Ovladač nejdříve z přijatých handle získá ukazatele na jednotlivé události pomocí funkce ObReferenceObject- ByHandle. Tyto ukazatele potom uloží do DEVICE_EXTENSION, aby mohl později jednotlivé události v pravý okamžik signalizovat. IOCTL_ON_PORT_CLOSE Přijetí této žádosti znamená, že uživatel zavolal knihovní funkci MbCloseSerial- Port. Ovladač reaguje voláním pomocné funkce MbCleanUp. Posláním této funkce 38

50 5.2. OVLADAČ je ukončit vlákno ovladače, ve kterém je vykonáván stavový automat, a uvolnit všechny vyrovnávací buffery. Kromě toho jsou voláním funkce ObDereferenceObject vymazány reference na pojmenované události, aby mohly být tyto později uvolněny z paměti. IOCTL_MASTER_ENABLE Žádost o aktivaci řídicí stanice. Pokud je tato žádost přijata poprvé od otevření sériového portu, je nejdříve alokována vyrovnávací paměť pro příchozí zprávy. Poté je ve status byte řídicí stanice nastaven flag, který značí, že je stanice aktivní. Nakonec je v případě, že je aktivní i některá z účastnických stanic, signalizována událost evpoll, na kterou čeká vlákno stavového automatu. Tím je odstartováno periodické dotazování aktivních účastnických stanic. IOCTL_MASTER_DISABLE Žádost o deaktivaci řídicí stanice. Active flag ve status byte řídicí stanice je vynulován a evpoll je převedena do nesignalizovaného stavu. Tím je ukončeno dotazování účastnických stanic. IOCTL_GET_MASTER_STATUS Žádost o sdělení stavu řídicí stanice. Do bufferu příslušného IRP je nakopírován status byte řídicí stanice. IOCTL_MASTER_RESET Žádost o resetování řídicí stanice. Nejdříve je provedena kontrola, je-li řídicí stanice deaktivována. V opačném případě žádosti není vyhověno. Poté je vymazána příchozí vyrovnávací paměť a vynulovány položky status a messagecount ve struktuře master. Následuje zresetování všech účastnických stanic, které s sebou nese obdobné kroky - vymazání vyrovnávací paměti pro odchozí zprávy, vynulování položek status, messagecount a stationpriority. Reset účastnické stanice obstarává pomocná funkce SlaveReset. IOCTL_SLAVE_ENABLE Žádost o aktivaci účastnické stanice. V bufferu příslušného IRP je ve formátu datové struktury SLAVE_PARAMS 7 uloženo číslo stanice, která má být aktivována, a také požadovaná hodnota priority stanice. Pokud je stanice aktivována poprvé od otevření sériového portu, je alokována vyrovnávací paměť pro odchozí 7 tato datová struktura je deklarována v hlavičkovém souboru measbus_ioctl.h 39

51 5.2. OVLADAČ zprávy. V datové struktuře příslušné stanice je poté ve status byte nastaven active flag a hodnota položky stationpriority je nastavena na požadovanou úroveň. Dále je inkrementován čítač aktivních účastnických stanic. Pokud je řídicí stanice aktivní a událost evpoll ještě není v signalizovaném stavu (žádná jiná účastnická stanice dosud nebyla aktivována), je tato událost signalizována nyní. IOCTL_SLAVE_DISABLE Žádost o deaktivaci účastnické stanice. V bufferu příslušného IRP je uloženo číslo statnice, která má být deaktivována. U této stanice je v jejím status byte vynulován acitve flag. Dále je dekrementován čítač aktivních účastnických stanic. Pokud má tento po dekrementaci hodnotu rovnou nule, je událost evpoll převedena do nesignalizovaného stavu a dotazování účastnických stanic je tím pozastaveno. IOCTL_GET_SLAVE_STATUS Žádost o předání stavu účastnické stanice. Status byte účastnické stanice je zkopírován do bufferu příslušného IRP. IOCTL_SLAVE_RESET Žádost o reset účastnické stanice. Průběh této operace byl vysvětlen v části, která popisuje obsluhu žádosti IOCTL_MASTER_RESET. IOCTL_GET_SLAVE_PRIORITY Žádost o sdělení aktuálně nastavené hodnoty priority účastnické stanice. V bufferu příslušného IRP je nejdříve obdrženo číslo vybrané stanice a zpět je do něj poté nakopírována hodnota položky stationpriority z datové struktury reprezentující danou stanici. IOCTL_SET_STATION_PRIORITY Žádost o nastavení nové hodnoty priority účastnické stanice. Číslo stanice a požadovaná priorita jsou v bufferu příslušného IRP uloženy ve formátu již dříve zmíněné struktury SLAVE_PARAMS. IOCTL_WRITE a IOCTL_READ Žádost o zápis, resp. čtení dat. Obsluze těchto žádostí je věnována následující podkapitola. IOCTL_PASS_BAUD_RATE Pomocí IRP s tímto IOCTL kódem předává knihovna ovladači hodnotu baud rate, 40

52 5.2. OVLADAČ která byla nastavena sériovému portu při jeho otevření. Ovladač po obdržení této hodnoty volá pomocnou funkci MbGetTimeouts. Ta z hodnoty baud rate vypočítá hodnoty obou hlídacích časů T A a T C a uloží je do DEVICE_EXTENSION Čtení a zápis dat Pro každou účastnickou stanici je v ovladači implementována jedna kruhová vyrovnávací paměť pro odchozí data. Jednotlivé datové bloky (maximálně 128 znaků) jsou v této paměti uloženy v datových strukturách OUTPUT_MESSAGE (viz 5.2.3). Velikost této vyrovnávací paměti je dána konstantou OUT_BUFFER_LENGTH, definovanou v hlavičkovém souboru measbus.h. Tato konstanta udává, kolik struktur OUT- PUT_MESSAGE (a tedy i datových bloků) je maximálně možno do vyrovnávací paměti uložit, aniž by došlo k přepisu. Ve verzi ovladače, která se nachází na doprovodném CD, je tato hodnota nastavena na 8. Celý proces zápisu dat začíná v okamžiku, kdy ovladač obdrží IRP typu IRP_MJ_ DEVICE_CONTROL s IOCTL kódem IOCTL_WRITE. První čtyři bajty v bufferu doprovázejícím tento IRP reprezentují číslo účastnické stanice, pro kterou jsou data určena. Pokud tato stanice není aktivována, žádosti o zápis dat není vyhověno. Zbytek bufferu zabírá samotná zpráva pro účastnickou stanici. Ta může mít i více jak 128 znaků. Pro zpracování tohoto IRP je zavolána pomocná funkce MbWrite. Zde je nejprve určeno, kolik datových bloků bude celá zpráva zabírat. Poté jsou data postupně dělena do bloků po 128 znacích. Každý blok je zakončen ukončovacím řídicím znakem ETB, vyjma posledního bloku zprávy, který je zakončen znakem ETX tak, jak to požaduje standard. Při dělení dat do jednotlivých bloků je zároveň pro každý blok generován jeho BCC. Spolu s informací o jeho délce je pak každý blok uložen ve formátu struktury OUTPUT_MESSAGE do vyrovnávací paměti. Přitom je inkrementována hodnota proměnné messagecount dané účastnické stanice. V okamžiku, kdy poté v cyklu dotazování přijde na danou účastnickou stanici řada, bude jeden blok dat z vyrovnávací paměti podle daného komunikačního protokolu odeslán. Toto už je realizováno v samostatném vlákně stavového automatu. Odeslání dat spočívá ve vytvoření IRP typu IRP_MJ_WRITE a přeposlání tohoto IRP nižšímu ovladači. Pro příchozí data je v ovladači implementována jediná hromadná vyrovnávací paměť. V této jsou jednotlivé datové bloky uloženy ve formátu struktury INPUT_MESSAGE (viz 5.2.3). Velikost vyrovnávací paměti je dána hodnotou konstanty IN_BUFFER_ LENGTH, definované opět v hlavičkovém souboru measbus.h. Tato konstanta udává, 41

53 5.2. OVLADAČ podobně jako v předchozím případě, kolik struktur INPUT_MESSAGE se do paměti může vejít, aniž by došlo k přepisu. V ovladači na doprovodném CD je tato hodnota nastavena na 32. Přijímání dat probíhá v samostatném vlákně stavového automatu podle daného komunikačního protokolu. Po průchodu stavovým automatem až do stavu, kde dochází k příjmu samotného datového bloku, je tento postupně vyčítán z bufferu sériového portu. Pro vyčítání znaků je třeba vytvořit IRP typu IRP_MJ_READ a přeposlat ho nižšímu ovladači. Mezi přijatými znaky je kontrolována přítomnost speciálního znaku 8, která by znamenala, že byl přijat bajt s chybou parity. Zároveň s vyčítáním znaků je generován BCC přijímaného datového bloku. Pokud je vypočítaný BCC shodný s přijatým a přítomnost speciálního znaku se nepotvrdí, je datový blok prohlášen za platný a je nakopírován spolu s dalšími informacemi do hromadné vyrovnávací paměti ve formě struktury INPUT_MESSAGE. Přitom je signalizována pojmenovaná událost MB_RECEIVE_EVT. Tím je uživatelská aplikace informována o přijetí nového datového bloku. Ve vyrovnávací paměti je datový blok uložen až do doby, než ovladač obdrží IRP typu IRP_MJ_DEVICE_CONTROL s IOCTL kódem IOCTL_READ, nebo dokud není přepsán novějšími daty v případě, že se kruhová paměť zaplní. Po obdržení takového IRP je do jeho bufferu datový blok i s doprovodnými informacemi (číslo stanice, délka bloku...) nakopírován. Tím jsou přijatá data přenesena do uživatelského prostoru Stavový automat Velkou část zdrojového kódu ovladače tvoří implementace stavového automatu, který realizuje dotazování, vysílání a příjem dat podle daného komunikačního protokolu. Tento stavový automat je implementován ve funkci MbStateMachine, která je vykonávána v samostatném vlákně. Toto vlákno je vytvořeno poté, co ovladač obdrží IRP typu IRP_MJ_DEVICE_CONTROL s IOCTL kódem IOCTL_ON_PORT_OPEN. Ukončeno je potom po obdržení IRP s IOCTL kódem IOCTL_ON_PORT_CLOSE. Bezprostředně po vstupu do funkce MbStateMachine probíhá inicializace všech proměnných, které jsou potřeba pro implementaci stavového automatu. Poté vlákno čeká, až přejde jedna z událostí evpoll nebo evkill (obě uložené v DEVICE_EXTENSION) do signalizovaného stavu. Událost evpoll je převedena do signalizovaného stavu, pokud je aktivní řídicí a alespoň jedna účastnická stanice. Událost evkill je signalizována v případě, že je požadováno ukončení vlákna. Kdykoliv je ve funkci MbStateMachine 8 viz 5.2.4, část zabývající se obsluhou žádosti IOCTL_ON_PORT_OPEN 42

54 5.2. OVLADAČ prováděno čekání (např. na dokončení odeslaného IRP), musí být jednou z událostí, na kterou se čeká, právě evkill. To je důležité proto, aby bylo vlákno v případě požadavku na jeho ukončení ukončeno okamžitě, bez zbytečných odkladů. Po přechodu události evpoll do signalizovaného stavu následuje volání pomocné funkce MbGetStationsToPoll. Tato funkce vybere ze všech aktivních účastnických stanic na základě jejich nastavené priority ty stanice, které budou dotazovány v následujícím komunikačním kole. Výstupem této funkce je pole ukazatelů na datové struktury reprezentující jednotlivé stanice, které budou postupně v daném komunikačním kole dotazovány. Před zahájením dotazování konkrétní stanice a vstupem do samotného stavového automatu je vždy provedena kontrola výstupní vyrovnávací paměti náležící této stanici. Pokud je v této datový blok k odeslání, je stavový automat zahájen v počátečním stavu odesílací větve podle diagramu na obrázku 2.4 a datový blok je stanici odeslán. Poté následuje přechod do přijímací fáze stavového automatu a tatáž stanice je dotazována na její vysílací adresu. Při kladném potvrzení je přijat datový blok. Pokud pro dotyčnou stanici v její vyrovnávací paměti nejsou žádná data k odeslání, je stavový automat zahájen rovnou v počátečním stavu přijímací větve. Celý stavový automat je potom implementován podle diagramu na obrázku 2.4. Po obsloužení jedné stanice je dotazována další ze seznamu pro aktuální komunikační kolo. Poté, co jsou obslouženy všechny účastnické stanice z daného komunikačního kola, je inkrementován čítač komunikačních kol a znovu zavolána funkce MbGetStationsToPoll, aby vybrala stanice pro dotazování v novém kole. Ty jsou poté jedna po druhé obslouženy výše popsaným způsobem a tento proces se opakuje stále dokola, dokud jsou aktivní řídicí a alespoň jedna účastnická stanice, nebo dokud není požadováno ukončení vlákna. Funkce pro výběr účastnických stanic MbGetStationsToPoll má dva vstupní parametry. Jednak je to číslo aktuálního komunikačního kola commround a jednak ukazatel na DEVICE_EXTENSION, přes který může funkce zjistit stavy všech účastnických stanic (aktivní/neaktivní) a jejich nastavené priority. Algoritmus výběru stanic pro dotazování v daném komunikačním kole je jednoduchý. Pokud je zbytek po dělení hodnoty komunikačního kola hodnotou priority 9 účastnické stanice roven nule, je tato stanice zahrnuta mezi dotazované. Tím je dosaženo toho, že stanice s prioritou jedna bude dotazována v každém komunikačním kole, stanice s prioritou dva v každém druhém kole, stanice s prioritou tři v každém třetím kole atd. Funkce potom navrací pole ukazatelů na struktury vybraných účastnických stanic spolu s počtem těchto stanic. 9 priorita účastnické stanice může nabývat hodnot od 1 do 15 43

55 5.2. OVLADAČ Hromadný a křížový přenos dat Při hromadném přenosu dat je vysílaná zpráva určena pro všechny účastnické stanice. Vnitřně je hromadný přenos řešen jako zápis dat do výstupního bufferu účastnické stanice s číslem 0, který probíhá naprosto stejně jako zápis dat do bufferu kterékoliv jiné stanice. Rozdíl je v tom, že tato stanice má implicitně nastavenou nejvyšší prioritu. To z toho důvodu, aby byla hromadná zpráva odeslána co možná nejdříve. Dalším rozdílem je to, že stanice s číslem 0 nemusí být nejprve aktivována, aby jí mohla být následně poslána data. Tato stanice totiž nereprezentuje žádnou skutečnou účastnickou stanici. Jedná se pouze o mechanismus, pomocí kterého byl hromadný přenos implementován. Při křížovém přenosu dat je datový blok určený k přeposlání uvozen řídicím znakem SOH, jak bylo popsáno v Z tohoto důvodu je ve stavovém automatu při přechodu do přijímací fáze vždy kontrolováno, jestli nedošlo k přijetí tohoto znaku. V takovém případě je následně přijatý datový blok (po kontrole jeho platnosti) ihned nakopírován do výstupního bufferu cílené účastnické stanice. Odtud je této stanici v některém z dalších komunikačních cyklů odeslán. Událost signalizující příjem datového bloku v tomto případě není signalizována. Křížový přenos dat tak probíhá zcela autonomně, bez nutnosti jakéhokoliv zásahu uživatele. 44

56 Kapitola 6 Fyzické rozhraní EIA-485 Pro připojení ke sběrnici Measurement Bus je třeba, aby byl počítač vybaven rozhraním EIA-485. Protože však toto rozhraní nepatří mezi standardní výbavu běžných osobních počítačů, je součástí této práce návrh zařízení, které tento problém řeší. Jedná se o fyzické rozhraní EIA-485, připojitelné k počítači prostřednictvím dnes velmi rozšířeného rozhraní USB. Návrhem a realizací takového zařízení se zabývá tato kapitola. V úvodu kapitoly jsou definovány základní požadavky na zařízení. Následuje stručný popis klíčových komponent, ze kterých zařízení sestává, spolu s popisem jejich zapojení. V závěru kapitoly je potom zdokumentována samotná realizace rozhraní. 6.1 Základní požadavky na zařízení První skupina požadavků pramení přímo ze standardu Measurement Bus tak, jak je definován v [1]. V první řadě se jedná o to, že zařízení musí umožnit na straně EIA-485 plně duplexní přenos dat. Dalším požadavkem je již několikrát zmiňované galvanické oddělení, které je normou požadováno za účelem potlačení souhlasného rušení. Tento požadavek s sebou přináší nutnost vytvoření galvanicky oddělené části za použití optooddělovačů nebo podobných izolačních prvků. Pro napájení této oddělené části potom bude potřeba použít DC/DC měnič. Dalším požadavkem ze strany normy je typ konektoru pro připojení na sběrnici. Jedná se o již zmiňovaný dvouřadý Canon 15 (vidlice). Jistě je také vhodné vybavit zařízení odpojitelným zakončovacím odporem přijímacího vedení pro případ, že by bylo připojeno na fyzický konec hlavního vedení sběrnice. V neposlední řadě je s ohledem na komunikační rychlosti podporované standardem Measurement Bus nutné, aby bylo zařízení schopno pracovat při přenosových rychlostech až 1 MBd. Od zařízení je dále požadováno, aby bylo pro jednoduchost obsluhy napájeno pouze 45

57 6.2. VÝBĚR KOMPONENT z USB. Proto je třeba brát při návrhu ohled i na napájecí možnosti této sběrnice. Standard USB [12] definuje, že po připojení může zařízení odebírat proud o velikosti maximálně 100 ma. Po softwarové konfiguraci zařízení může být odebíraný proud navýšen až na 500 ma. Když je počítač v režimu spánku, je maximální hodnota odebíraného proudu omezena na 500 μa. V neposlední řadě je požadováno, aby bylo celé zařízení pokud možno kompaktních rozměrů. Samozřejmostí je potom indikace stavu (napájeno, vysílání, příjem) prostřednictvím LED. 6.2 Výběr komponent V této části je proveden výčet použitých integrovaných obvodů spolu s jejich základními charakteristikami. Kompletní seznam všech použitých součástek včetně konektorů je uveden ve formě tabulky v příloze D Integrovaný obvod FT232R Tento integrovaný obvod od firmy Future Technology Devices International Ltd. tvoří jádro celého zařízení. Čip realizuje převod dat USB - UART. Velkou výhodou verze R je integrovaný hodinový obvod. Proto k součástce není potřeba připojovat externí krystal. Dále jsou již přímo na čipu integrovány USB rezistory - dva sériové na vstupních pinech USBDP a USBDM a jeden pull-up na pinu USBDP. K obvodu tedy není potřeba připojovat kromě blokovacích kondenzátorů ani žádné další pasivní součástky. FT232R dále nabízí pět konfigurovatelných pinů. Tyto jsou v katalogovém listu [13] označovány jako CBUS0 až CBUS4. Jejich konfigurace probíhá zápisem do vnitřní EEPROM pomocí programu FT_Prog popř. staršího Mprog, který je volně dostupný ke stažení z internetových stránek výrobce čipu. Stejným způsobem je také možné softwarově aktivovat negaci každého z osmi signálů vnitřního obvodu UART. FT232R je dodáván ve dvou typech pouzder. V této práci je použita verze v pouzdře SSOP s 28 vývody, označovaná jako FT232RL. Tyto a některé další vlastnosti integrovaného obvodu FT232R jsou shrnuty v následujícím výčtu: integrovaná 1kB EEPROM pro uložení deskriptoru zařízení a nastavení konfigurovatelných pinů integrované zakončovací odpory USB integrovaný generátor hodinového signálu, odpadá potřeba externího krystalu 46

58 6.2. VÝBĚR KOMPONENT podporované přenosové rychlosti od 300 Bd do 3 MBd pět konfigurovatelných vstupně-výstupních pinů signály pro ovládání LED signalizujících vysílání a příjem SW negace všech výstupních signálů vnitřního obvodu UART vnitřní obvod UART podporuje 7 nebo 8 datových bitů, 1 nebo 2 stop bity a všechny druhy parity funkce čipu jsou aplikacím zpřístupněny přes virtuální sériový port vytvořený v systému dodávanými ovladači Budič sběrnice EIA-485 ISO3086 ISO3086 je obousměrný budič plně duplexní EIA-485 od firmy Texas Instruments, s integrovaným galvanickým oddělením [14], dodávaný v pouzdře SOIC s 16 vývody. Galvanicky je oddělena jak vstupní a výstupní linka, tak také signál řídící stav výstupu budiče. Použitím tohoto typu budiče odpadá nutnost realizace galvanického oddělení signálových vodičů zvlášť pomocí optooddělovačů. Tím dojde k významné úspoře místa na desce plošných spojů, což bude mít ve výsledku vliv na celkové rozměry zařízení. Z hlediska ceny je toto řešení srovnatelné s použitím obyčejného budiče doplněného o příslušné optooddělovací prvky. Základní vlastnosti budiče ISO3086: obousměrný budič plně duplexní sběrnice EIA-485 integrované galvanické oddělení s odolností až 4 kv ve špičce nebo 2,5 kv efektivně po dobu 60 s přenosová rychlost až 20 Mbit/s DC/DC měnič AM1S-0505SZ Pro napájení výstupní galvanicky oddělené části budiče je použit cenově dostupný DC/DC měnič AM1S-0505SZ s následujícími parametry: vstupní napětí 4,5 až 5,5 V výstupní napětí 5,0 V s tolerancí 5 % maximální výstupní proud 140 ma pouzdro SIP se čtyřmi vývody 47

59 6.3. POPIS ZAPOJENÍ Výkonový MOSFET IRF7304 Aby proud odebíraný zařízením v době, kdy se systém nachází v režimu spánku, nepřesáhl stanovených 500μA, je třeba dočasně přerušit napájení budiče a měniče napětí. K tomu je použit výkonový spínač IRF7304 od firmy International Rectifier. V jednom pouzdře SO-8 se nachází dva tranzistory MOSFET s kanálem typu P. Čip FT232R umožňuje nastavit na jednom z konfigurovatelných pinů funkci PWREN#. Tento signál potom slouží právě pro spínání MOSFETu s kanálem typu P při přechodu mezi jednotlivými režimy napájení počítače. 6.3 Popis zapojení Kompletní schéma zapojení se nachází v příloze C. Toto schéma bylo vytvořeno v návrhovém programu Cadsoft Eagle verze a je dostupné ve formátu *.sch na CD doprovázejícím tuto práci. Při návrhu zapojení byly respektovány požadavky uvedené v katalogových listech jednotlivých součástek. Napětí z konektoru USB je přivedeno jednak na čip FT232R a jednak na spínací prvek IRF7304. Přes ten je dále napájena jedna část budiče sběrnice EIA-485 a DC/DC měnič, který následně napájí druhou, galvanicky oddělenou část tohoto budiče. Pro usnadnění pozdějšího návrhu desky plošných spojů jsou konfigurovatelným pinům CBUS čipu FT232R přiřazeny jednotlivé funkce dle tabulky 6.1. Řídicí signál TXDEN je automaticky převeden do vysoké úrovně, kdykoliv obvod UART čipu FT232R vysílá data. Pro řízení výstupu budiče může být použit buď tento signál a nebo signál RTS, který se za tímto účelem standardě používá. Volbu mezi oběma řídicími signály umožňuje jumper JP1. Prostřednictvím tohoto jumperu je také možné připojit vstup řídící stav výstupního budiče přímo na napájecí napětí. V takovém případě je výstup budiče neustále v aktivním stavu. Přes jumper JP2 je pro účely stínění možné připojit pin 1 výstupního konektoru Canon 15 na zem galvanicky oddělené části. Jumper JP3 potom slouží k připojení zakončovacího 120Ω odporu k přijímacímu vedení. Při konfiguraci čipu FT232R zápisem do jeho interní EEPROM je kromě přiřazení funkcí CBUS pinům také třeba zapnout softwarovou negaci signálů RX a TX. Vyžaduje to způsob, jakým jsou podle standardu Measurement Bus jednotlivé piny výstupního konektrou přiřazeny signálovým vodičům. Pokud by byl tento krok vynechán, zařízení by nepracovalo správně. 48

60 6.4. REALIZACE pin funkce popis CBUS0 PWREN# řízení hradla tranzistoru IRF7304 CBUS1 TXDEN řídicí signál výstupu budiče CBUS2 TXLED# ovládání LED signalizující příjem dat CBUS3 RXLED# ovládání LED signalizující vysílání dat CBUS4 - - Tabulka 6.1: Přiřazení funkcí konfigurovatelným pinům CBUS čipu FT232R. 6.4 Realizace Návrh desky plošného spoje byl zhotoven v programu Cadsoft Eagle verze Deska je provedena jako dvouvrstvá s třídou přesnosti 5. Spoje pro napájení byly záměrně navrženy s větší než minimální přípustnou šířkou pro uvedenou třídu. Spodní vrstva slouží jako zemnící rovina. Ta je rozdělena do dvou vzájemně elektricky izolovaných částí kvůli realizaci galvanického oddělení. Pro zachování celistvosti zemnících rovin je touto vrstvou vedeno pouze minimum signálových spojů. Rozměry a tvar desky byly navrženy na míru pro konkrétní typ krabičky, do které byla později osazená deska instalována. Tím byl dán také požadavek na přesné umístění děr pro uchycovací šrouby. Na vstupní straně byl pro připojení k USB kvůli svým kompaktním rozměrům zvolen konektor mini-usb. Obrázek 6.1: Realizované fyzické rozhraní EIA-485 po demontáži vrchního krytu. 49

61 Kapitola 7 Instalace a testování Testování je neodmyslitelnou součástí vývoje jakéhokoliv softwarového i hardwarového produktu. Právě testováním se zabývá závěrečná kapitola této práce. V její úvodní části je nejdříve popsán způsob instalace vyvinutého ovladače do operačního systému. V další části je věnován prostor popisu jednoduché uživatelské aplikace, která byla vytvořena za účelem ověření funkčnosti ovladače. Poté již následuje část zabývající se samotným procesem testování. Na základě výsledků testování je v závěru kapitoly proveden výčet verzí operačního systému Microsoft Windows, se kterými je vyvinutý ovladač, a tedy i celé realizované řešení, kompatibilní. 7.1 Instalace ovladače Protože ovladač nereprezentuje žádné fyzické zařízení, systém jeho instalaci sám nikdy vyžadovat nebude. Proto je veškerá iniciativa při instalaci ovladače na samotném uživateli, který hodlá jeho funkce využívat. Samotná instalace je velice jednoduchá a provádí se pomocí přiloženého souboru measbus.inf, který se nachází na doprovodném CD v adresáři...\sw \x86 \install, popř....\sw \x64 \install pro instalaci 64-bitové verze ovladače. Pro instalaci ovladače do operačního systému je třeba pravým tlačítkem myši kliknout na výše jmenovaný soubor a z rozbalené nabídky zvolit položku Instalovat. Tím dojde k vykonání příkazů uvedených v DefaultInstall sekci souboru measbus.inf. Ty mimo jiné zahrnují nakopírování binárního souboru ovladače measbus.sys a binárního souboru knihovny measbus.dll do příslušných systémových adresářů na disku počítače. Tímto jednoduchým krokem je tak do počítače uživatele přenesen jak samotný ovladač tak i knihovna. Po instalaci je před prvním použitím ovladače třeba restartovat systém, aby došlo k zařazení ovladače do driver stacku přítomných sériových portů. 50

62 7.2. TESTOVACÍ APLIKACE Před použitím navrženého fyzického rozhraní EIA-485 je potom třeba nainstalovat příslušné ovladače čipu FT232R. Ty jsou volně dostupné ke stažení z internetových stránek výrobce čipu. Samotná instalace ovladačů probíhá standardním způsobem prostřednictvím dialogu, který uživatele informuje o nalezení nového hardwaru po připojení zařízení k počítači. Operační systém Windows 7 má ovladače čipu FT232R ve své základní výbavě a jejich instalace zde proběhne zcela autonomně po prvním připojení zařízení k počítači. Na pořadí, v jakém je nainstalován ovladač measbus.sys a ovladače čipu FT232R, nezáleží. 7.2 Testovací aplikace Za účelem ověření funkčnosti ovladače byla vytvořena jednoduchá aplikace s přehledným grafickým uživatelským rozhraním (viz obr. 7.1). Ta umožňuje využít všechny nabízené funkce ovladače. Část grafického rozhraní s ovládacími prvky sestává ze tří záložek. Záložka Port control slouží k otevření vybraného sériového portu a nastavení požadované přenosové rychlosti. Záložka Master control obsahuje ovládací prvky pro aktivaci, deaktivaci a reset řídicí stanice. Konečně záložka Slave control obsahuje ovládací prvky pro management účastnických stanic. Zde je možné provést aktivaci dotazování, nastavení priority a reset vybraných účastnických stanic. Aktivovaným účastnickým stanicím je potom možné posílat libovolný text. O stavu každé účastnické stanice je uživatel informován jednak prostřednictvím hodnoty položky status a jednak prostřednictvím barvy tlačítka reprezentujícího danou stanici. Deaktivovaná stanice je reprezentována červenou barvou, aktivní zelenou a aktivní stanice, která přestala odpovídat, je značena barvou žlutou. Zprávy přijaté od účastnických stanic jsou potom automaticky vypisovány spolu s identifikátorem stanice do textového pole Received text. Aplikace byla naprogramována v jazyce C# pro platformu.net 2.0. Tato platforma využívá pro volání funkcí exportovaných z DLL mechanismus zvaný P/Invoke [9]. Ten zprostředkovává přechod z řízeného kódu.net do neřízeného kódu exportovaných funkcí, jak je znázorněno na obrázku 7.2. Aby mohla být exportovaná funkce volána v aplikaci, musí být v této nejdříve deklarována spolu se specifikací exportující knihovny. Řekněme, že hodláme v naší.net aplikaci využít funkci SectiCisla exportovanou z knihovny mojeknihovna.dll. Nechť je funkce SectiCisla definována v knihovně následujícím způsobem: UINT SectiCisla(UINT cisloa, UINT cislob) { return cisloa + cislob; } 51

63 7.2. TESTOVACÍ APLIKACE Obrázek 7.1: Grafické uživatelské rozhraní testovací aplikace - záložka s ovládacími prvky pro management účastnických stanic. Potom je třeba tuto funkci před jejím voláním v aplikaci deklarovat následovně: [DllImport("mojeKnihovna.dll")] static extern UInt32 SectiCisla(UInt32 cisloa, UInt32 cislob); Důležité zde je, že importovaná funkce je takto deklarována již s datovými typy používanými v jazyku C# a ne s původními datovými typy WinAPI, se kterými byla definována v knihovně. Tato konverze datových typů je v literatuře označována termínem data marshaling. Pro každý datový typ WinAPI existuje ekvivalentní datový typ v.net. Konverze datových typů je poněkud komplikovanější, pokud má některá z exportovaných funkcí mezi svými parametry ukazatel na datovou strukturu. Pak je třeba v importující aplikaci deklarovat i tuto strukturu. Přiřazení jednotlivých datových typů WinAPI datovým typům.net včetně konverze datových struktur je přehledně 52