Č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
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
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í.
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.
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.
Obsah Seznam obrázků
viii
Seznam tabulek
ix
1 Úvod
1
2 Measurement Bus
3
2.1
Základní charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Fyzická vrstva standardu . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Struktura sběrnice . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Konektory a terminátory . . . . . . . . . . . . . . . . . . . . . .
5
Linková vrstva standardu . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.1
Formát přenášených dat . . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
Adresování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.3
Řízení přenosu dat . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.4
Jištění přenášených dat . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.5
Časování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
3 Programování ovladačů pro OS Windows 3.1
3.2
Vstupně-výstupní systém Windows . . . . . . . . . . . . . . . . . . . .
12
3.1.1
Struktura vstupně-výstupního systému . . . . . . . . . . . . . .
12
3.1.2
Zpracování vstupně-výstupního požadavku . . . . . . . . . . . .
13
3.1.3
Typy ovladačů . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Windows Driver Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1
Driver Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.2
Struktura WDM ovladače . . . . . . . . . . . . . . . . . . . . .
18
4 Analýza a návrh řešení SW části 4.1
12
20
Struktura SW řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
20
OBSAH 4.2
Specifika ovladačů typu filtr . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.1
Funkce DriverEntry . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.2
Funkce AddDevice . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.3
PnP a Power management . . . . . . . . . . . . . . . . . . . . .
23
4.2.4
Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Volba vhodného typu filtru . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4
Požadavky na funkce ovladače . . . . . . . . . . . . . . . . . . . . . . .
27
5 Popis implementace 5.1
5.2
29
Knihovna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1.1
Použité prostředky . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1.2
Definované datové typy . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.3
Exportované funkce . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1.4
Pojmenované události
. . . . . . . . . . . . . . . . . . . . . . .
34
5.1.5
Komunikace s ovladačem . . . . . . . . . . . . . . . . . . . . . .
34
Ovladač . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.1
Použité prostředky . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.2
Struktura ovladače . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.3
Základní datové struktury . . . . . . . . . . . . . . . . . . . . .
36
5.2.4
Obsluha IOCTL žádostí . . . . . . . . . . . . . . . . . . . . . .
38
5.2.5
Čtení a zápis dat . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.6
Stavový automat . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.7
Hromadný a křížový přenos dat . . . . . . . . . . . . . . . . . .
44
6 Fyzické rozhraní EIA-485
45
6.1
Základní požadavky na zařízení . . . . . . . . . . . . . . . . . . . . . .
45
6.2
Výběr komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.2.1
Integrovaný obvod FT232R . . . . . . . . . . . . . . . . . . . .
46
6.2.2
Budič sběrnice EIA-485 ISO3086 . . . . . . . . . . . . . . . . .
47
6.2.3
DC/DC měnič AM1S-0505SZ . . . . . . . . . . . . . . . . . . .
47
6.2.4
Výkonový MOSFET IRF7304 . . . . . . . . . . . . . . . . . . .
48
6.3
Popis zapojení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.4
Realizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7 Instalace a testování
50
7.1
Instalace ovladače . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.2
Testovací aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
vi
OBSAH 7.3
Průběh testování a jeho výsledky . . . . . . . . . . . . . . . . . . . . .
53
8 Závěr
55
A Řídicí znaky komunikačního protokolu
56
B Dokumentace funkcí exportovaných knihovnou
58
B.1 MbOpenSerialPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
B.2 MbCloseSerialPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
B.3 MbMasterEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
B.4 MbMasterDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
B.5 MbGetMasterStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
B.6 MbMasterReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
B.7 MbSlaveEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
B.8 MbSlaveDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
B.9 MbGetSlaveStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
B.10 MbSlaveReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
B.11 MbGetSlavePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
B.12 MbChangeSlavePriority
. . . . . . . . . . . . . . . . . . . . . . . . . .
64
B.13 MbRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
B.14 MbWrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
B.15 MbGetVersionInfo
66
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C Schéma zapojení fyzického rozhraní EIA-485
67
D Seznam použitých součástek
70
Literatura
71
vii
Seznam obrázků 2.1
Lineární topologie datové sběrnice . . . . . . . . . . . . . . . . . . . . .
5
2.2
Zakončení vedení sběrnice . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Formát datového bloku . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
Komunikační diagram řídicí stanice . . . . . . . . . . . . . . . . . . . .
8
3.1
Zpracování vstupně-výstupního požadavku . . . . . . . . . . . . . . . .
14
3.2
Typy ovladačů jádra operačního systému . . . . . . . . . . . . . . . . .
15
3.3
Princip vrstvení ovladačů ve WDM . . . . . . . . . . . . . . . . . . . .
17
4.1
Struktura navrhovaného softwarového řešení . . . . . . . . . . . . . . .
21
4.2
Pořadí vertikálního řazení různých typů filtrů . . . . . . . . . . . . . .
26
6.1
Realizované fyzické rozhraní EIA-485 . . . . . . . . . . . . . . . . . . .
49
7.1
Grafické uživatelské rozhraní testovací aplikace . . . . . . . . . . . . . .
52
7.2
Princip mechanismu P/Invoke . . . . . . . . . . . . . . . . . . . . . . .
53
viii
Seznam tabulek 2.1
Přiřazení pinů konektoru Canon 15 . . . . . . . . . . . . . . . . . . . .
5
2.2
Struktura adresovacího bajtu standardu Measurement Bus . . . . . . .
7
5.1
Formát status byte účastnické stanice . . . . . . . . . . . . . . . . . . .
30
5.2
Formát datové struktury MB_MSG . . . . . . . . . . . . . . . . . . . .
31
5.3
Výčet pojmenovaných událostí . . . . . . . . . . . . . . . . . . . . . . .
34
5.4
Formát datové struktury MB_MASTER . . . . . . . . . . . . . . . . .
36
5.5
Formát datové struktury MB_SLAVE . . . . . . . . . . . . . . . . . .
37
5.6
Formát datové struktury INPUT_MESSAGE . . . . . . . . . . . . . .
37
5.7
Formát datové struktury OUTPUT_MESSAGE . . . . . . . . . . . . .
38
6.1
Přiřazení funkcí pinům CBUS čipu FT232R . . . . . . . . . . . . . . .
49
A.1 Řídicí znaky komunikačního protokolu . . . . . . . . . . . . . . . . . .
57
D.1 Seznam použitých součástek . . . . . . . . . . . . . . . . . . . . . . . .
70
ix
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
Ú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
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 (PTB1 ). 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 DIN2 66348, čá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 EPSI3 [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 UART4 , budič sběrnice EIA-485 s galvanickým oddělením a DC-DC konver1
Physikalisch-Technische Bundesanstalt Deutsche Industrie-Norm 3 European Petrol Station Interface 4 universal asychronous receiver/transmitter 2
3
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í.
2.2.1
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
2.2. FYZICKÁ VRSTVA STANDARDU
Obrázek 2.1: Lineární topologie sběrnice. Převzato z [4] .
2.2.2
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í: R1 = 510 Ω, R2 = 150 Ω, R3 = 120 Ω.
číslo pinu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
význam stínění vysílaná data (A) přijímaná data (A) volitelné sběrnicová zem vysílaná data (B) přijímaná data (B) volitelné napájení +5 V (volitelné)
Tabulka 2.1: Význam pinů konektorů Canon 15. 5
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 1745. 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ů.
2.3.1
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
2.3. LINKOVÁ VRSTVA STANDARDU
2.3.2
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 1-5 6 7
význam adresa jednotky v logické 1 - vysílací adresa v logické 0 - přijímací adresa stále v logické 1
Tabulka 2.2: Struktura adresovacího bajtu standardu Measurement Bus.
2.3.3
Ří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
2.3. LINKOVÁ VRSTVA STANDARDU PĜíjímací strana diagramu
Vysílací strana diagramu
0 Základní 'SADR' ENQ
'EADR' ENQ
stav
Start limit TA
'RADR'
Start limit TA EOT
EOT
1
7 'SADR' NAK nebo T>TA
ýekání na odpovČć
'EADR' NAK nebo T>TA
ýekání na odpovČć
'SADR' DLE 3/0
'EADR' DLE 3/0
Start limit TC
M=1
2 EOT nebo T>TC
ýekání na STX, SOH, EOT, ENQ
8 Skupinové
STX nebo SOH
NAK
EOT nebo T>TC vysílání
Vysílání bloku
ENQ
3
6
ENQ
STX nebo PĜijímání bloku
ýekání na STX, SOH, EOT, ENQ
SOH
EOT nebo
N=1
T>TC N+1
ETB nebo ETX BCC- nebo
ENQ
ENQ
9
chyba parity T>TA a N<3
T>T C
Platný blok
Start limit TA
NAK
4 ýekání na BCC
M+1
ýekání na odpovČć
NAK a M<3
DLE 3/1 DLE 3/1 nebo T>TA a N=3 nebo NAK a M=3
5 ýekání na EOT, ENQ
M: Poþítadlo odpovČdí NAK N: Poþítadlo požadavkĤ ENQ
DLE 3/1 ENQ
EOT nebo T>TC
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
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 TA (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 2.3.1. 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, kde EADR 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. Po jejich 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
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.
2.3.4
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.
2.3.5
Časování
Pro zajištění plynulosti komunikace jsou definovány dva hlídací časy, označované jako TA a TC . Hlídací čas TA 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 TC 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 TA a TC jsou závislé na nastavené přenosové rychlosti podle vztahů 2.1 resp. 2.2. Pro přenosovou rychlost 9600 Bd je TA ≈ 21 ms a TC ≈ 530 ms. TA =
2.105 baud rate 10
(ms)
(2.1)
2.3. LINKOVÁ VRSTVA STANDARDU
TC =
5, 12.106 baud rate
11
(ms)
(2.2)
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.
3.1.1
Struktura vstupně-výstupního systému
Vstupně-výstupní systém Windows sestává z následujících částí:
12
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. • PnP1 manager úzce spolupracuje s I/O managerem a s typem ovladač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í a v neposlední ř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 (HAL2 ) 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í.
3.1.2
Zpracování vstupně-výstupního požadavku
Zpracování vstupně-výstupních požadavků probíhá typicky podle schématu na obr. 3.1. 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 2
Plug&Play Hardware Abstraction Layer
13
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í WinAPI3 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]. .
3.1.3
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
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
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 i v následují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 2000. 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.
3.2.1
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 3.1.3. 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
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
3.2. WINDOWS DRIVER MODEL
3.2.2
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
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
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 4.1.
20
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 i v kombinaci s klasický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
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.
4.2.1
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
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.
4.2.2
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].
4.2.3
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
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 4.2.1. 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.
4.2.4
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 [FilterDriverService] ServiceType=1 ;jedná se o ovladač jádra systému 24
;pro funkční ovladač ;pro filtr
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,0x00010000,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 (GUID1 ). 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
4.2. SPECIFIKA OVLADAČŮ TYPU FILTR záznam:
[AddReg] ;sekce modifikující registr HKLM, System\CurrentControlSet\Control\Class\GUID, UpperFilters, 0x00010008, 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
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
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
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.
5.1.1
Použité prostředky
K programování a překladu knihovny bylo použito vývojové prostředí Microsoft Visual Studio 2008 (verze 9.0.21022.8) a překladač v něm obsažený.
29
5.1. KNIHOVNA
5.1.2
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
7 NR2
6 NR1
5
4
3 2 LAF RF
1 0 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
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.
5.1.3
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
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
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 2
Jedná se o hromadnou vyrovnávací paměť pro příchozí zprávy od všech účastnických stanic. Každá účastnická stanice má vlastní vyrovnávací paměť pro odchozí zprávy.
33
5.1. KNIHOVNA
5.1.4
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í.
5.1.5
Komunikace s ovladačem
Knihovna komunikuje s ovladačem výhradně prostřednictvím volání funkce DeviceIoControl 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 5.1.2. Dalším parametrem předávaným funkci DeviceIoControl je kontrolní (IOCTL3 ) 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 5.2.4. 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
5.2. OVLADAČ
5.2 5.2.1
Ovladač Použité prostředky
Pro překlad ovladače byl použit překladač obsažený v produktu Windows Driver Kit verze 7600.16385.1. Pro ladění ovladače byl použit program WinDbg verze 6.12.0002.633 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].
5.2.2
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 DriverEntry, MbAddDevice, MbUnload (volána při uvolňování ovladače z paměti4 ), 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 StartThread 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 MbGetTimeouts, 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 komu4
implementace takové funkce je u WDM ovladačů povinná
35
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 5.2.6.
5.2.3
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 bufferu5 i na buffer samotný jsou typu PINPUT_MESSAGE. Jednotlivé bloky dat jsou totiž ve vyrovnávací paměti uloženy ve strukturách INPUT_MESSAGE. Formát této datové struktury bude popsán dále. struktura proměnná UCHAR status PINPUT_MESSAGE inputBuffer PINPUT_MESSAGE writePointer PINPUT_MESSAGE readPointer LONG messageCount
MB_MASTER význam status byte řídicí stanice ukazatel na začátek kruhového bufferu ukazatel na první volný slot v bufferu ukazatel na nejstarší datový blok v bufferu 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 stanici6 . 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 6
jedná se o hromadný buffer pro všechny příchozí zprávy zvláštní poslání má stanice s číslem 0, viz 5.2.7
36
5.2. OVLADAČ
proměnná UCHAR stationNumber ULONG stationPriority UCHAR status POUTPUT_MESSAGE POUTPUT_MESSAGE POUTPUT_MESSAGE LONG messageCount
struktura MB_SLAVE význam číslo účastnické stanice priorita účastnické stanice status byte účastnické stanice outputBuffer ukazatel na začátek kruhového bufferu writePointer ukazatel na první volný slot v bufferu readPointer ukazatel na nejstarší datový blok v bufferu 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
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.
5.2.4
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 5.1.4. Ovladač nejdříve z přijatých handle získá ukazatele na jednotlivé události pomocí funkce ObReferenceObjectByHandle. 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 MbCloseSerialPort. Ovladač reaguje voláním pomocné funkce MbCleanUp. Posláním této funkce 38
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_PARAMS7 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
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
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ů TA a TC a uloží je do DEVICE_EXTENSION.
5.2.5
Č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 OUTPUT_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
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 znaku8 , 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.
5.2.6
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
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 priority9 úč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
5.2. OVLADAČ
5.2.7
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 2.3.3. 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
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
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.
6.2.1
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
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
6.2.2
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
6.2.3
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
6.3. POPIS ZAPOJENÍ
6.2.4
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 5.8.0 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
6.4. REALIZACE pin CBUS0 CBUS1 CBUS2 CBUS3 CBUS4
funkce PWREN# TXDEN TXLED# RXLED# -
popis řízení hradla tranzistoru IRF7304 řídicí signál výstupu budiče ovládání LED signalizující příjem dat ovládání LED signalizující vysílání dat -
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 5.8.0. 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
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
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
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
7.3. PRŮBĚH TESTOVÁNÍ A JEHO VÝSLEDKY zdokumentováno v nápovědě k vývojovému prostředí Microsoft Visual Studio. Tyto informace jsou přístupné přes index nápovědy pod položkou platform invoke.
Obrázek 7.2: Princip volání funkcí exportovaných z DLL řízeným kódem platformy .NET pomocí mechanismu P/Invoke. Převzato z [15].
7.3
Průběh testování a jeho výsledky
Funkčnost celého systému, tedy jak jeho softwarové, tak hardwarové části, byla ověřena úspěšnou komunikací se zařízením, které se chová jako odpovídač v režimu uzlu Slave sběrnice Measurement Bus. Toto zařízení bylo realizováno v rámci jiného projektu na katedře, kde vznikala tato diplomová práce. Veškerá data přijatá od řídicí stanice toto zařízení obratem přeposílá zpět řídicí stanici. Úspěšným přijetím odeslaných dat jsem tak mohl zároveň otestovat jak vysílání, tak příjem. Využité zařízení podporuje pouze komunikační rychlost 9600 Bd. Z tohoto důvodu nebyl celý systém otestován na vyšších komunikačních rychlostech. Samotné fyzické rozhraní EIA-485 potom bylo testováno zvlášť pomocí programů PuTTY a Hyperterminál1 . Přitom byly výstupní piny konektoru Canon 15 uměle propojeny se vstupními. Vysílaná data tak byla zároveň ihned přijímána. Takto jsem byl schopen přijímat vysílané znaky bez problémů až do rychlosti 3 MBd - maximální přenosové rychlosti podporované čipem FT232R. Celý komunikační systém byl výše popsaným způsobem pečlivě testován ve 32bitových verzích operačních systémů Windows 2000 Professional, Windows XP Professional (SP2 a SP3), Windows Vista Ultimate a Windows 7 (verze Home Premium 1
tento program je součástí Microsoft Windows do verze XP
53
7.3. PRŮBĚH TESTOVÁNÍ A JEHO VÝSLEDKY a Professional). Ve všech těchto verzích funguje zcela bez problémů. Funkčnost 64bitové verze ovladače a knihovny potom byla úspěšně ověřena v operačním systému Windows XP Professional x64 Edition (SP2). I zde vše pracuje naprosto v pořádku. Bohužel nebylo možné otestovat ovladač v 64-bitových verzích operačních systémů Windows Vista a Windows 7. Tyto verze totiž vyžadují, aby byl veškerý kód, který má být načten do jádra systému, digitálně podepsán společností Microsoft [6]. To se samozřejmě týká i ovladačů pracujících v jádře systému. V materiálu dostupném z [16] jsou uvedeny kroky, které je potřeba podniknout pro získání digitálního podpisu. Odtud je patrné, že celá procedura je zdlouhavá a značně nákladná, proto jsem se rozhodl jí nepodstoupit. Ovladač, a s tím i celé navržené řešení, z tohoto důvodu nelze provozovat v 64-bitových verzích operačních systémů Windows Vista a Windows 7.
54
Kapitola 8 Závěr V této práci jsem navrhl a realizoval řešení, které umožňuje připojení osobního počítače vybaveného operačním systémem Microsoft Windows k průmyslové datové sběrnici Measurement Bus. Hlavní část řešení tvoří ovladač jádra operačního systému, pracující nad ovladačem sériového portu, který implementuje funkce stanice Master této sběrnice. Uživatelské rozhraní ovladače je realizováno jako sada přehledně zdokumentovaných funkcí, exportovaných dynamicky linkovanou knihovnou. Výhodou tohoto řešení je, že pro připojení počítače ke sběrnici nejsou již potřeba žádné další hardwarové prostředky, kromě samotného fyzického rozhraní EIA-485. Protože toto rozhraní nepatří mezi standardní výbavu osobních počítačů, byl součástí této práce také návrh a následná realizace fyzického rozhraní EIA-485, které lze připojit k počítači prostřednictvím portu USB. Tímto odpadají nevýhody stávajících řešení, založených na rozšiřujících PCI kartách, jako jsou například zdlouhavá instalace nebo nekompatibilita s přenosnými počítači. Funkčnost celého řešení byla ověřena úspěšnou komunikací s jiným zařízením. Realizovaný ovladač je kompatibilní se všemi 32-bitovými verzemi OS Windows, počínaje verzí Windows 2000. Verze ovladače pro 64-bitové operační systémy je kvůli chybějícímu digitálnímu podpisu kompatibilní pouze s operačním systémem Windows XP x64 Edition. Námětem na budoucí vylepšení může být rozšíření ovladače tak, aby implementoval i funkce stanice Slave sběrnice Measurement Bus. Osobní počítač by tak mohl být připojen na sběrnici nejen v roli řídicí stanice, jak je to možné nyní, ale také v roli účastnické stanice. Jistě by se tak ještě rozšířila oblast aplikací, kde může být realizované řešení nasazeno.
55
Příloha A Řídicí znaky komunikačního protokolu
56
57
hexadecimálně význam xx05 vyzývací fáze: výzva k vysílání na SADR xx05 vyzývací fáze: výzva k příjmu na EADR 05 přenosová fáze: výzva přijímající stanice k zaslání potvrzení xx1030 vyzývací fáze: kladné potvrzení od SADR xx1030 vyzývací fáze: kladné potvrzení od EADR 1031 přenosová fáze: kladné potvrzení xx15 vyzývací fáze: negativní potvrzení od SADR xx15 vyzývací fáze: negativní potvrzení od EADR 15 vyzývací fáze: negativní potvrzení 01 vyzývací fáze: začátek hlavičky při křížovém přenosu 02 přenosová fáze: začátek datového bloku 17 přenosová fáze: konec datového bloku 03 přenosová fáze: konec datového bloku a konec textu 04 všechny fáze: konec spojení, přechod do základního stavu
Tabulka A.1: Řídicí znaky komunikačního protokolu standardu Measurement Bus.
řídicí znak(y) SADR ENQ EADR ENQ ENQ SADR DLE 3/0 EADR DLE 3/0 DLE 3/1 SADR NAK EADR NAK NAK SOH STX ETB ETX EOT
PŘÍLOHA A
Příloha B Dokumentace funkcí exportovaných knihovnou B.1
MbOpenSerialPort
Funkce MbOpenSerialPort() otevře vybraný sériový port pro účely komunikace po sběrnici Measurement Bus a nastaví požadovanou baud rate tohoto portu. Funkce vrací handle, který bude použitý k následnému přístupu ke stanici Master využívající tento port. MB_HANDLE MbOpenSerialPort(LPCTSTR portName, DWORD baudRate);
Parametry portName Ukazatel na string, ve kterém je uložen název portu. baudRate Baud rate. Návratová hodnota Při úspěšném provedení funkce vrací handle na sériový port. V opačném případě je návratová hodnota rovna -1. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
58
PŘÍLOHA B
B.2
MbCloseSerialPort
Funkce MbCloseSerialPort() uzavře sériový port, a tím ukončí jeho využívání pro účely komunikace po sběrnici Measurement Bus. BOOL MbCloseSerialPort(MB_HANDLE portHandle);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.3
MbMasterEnable
Funkce MbMasterEnable() aktivuje stanici Master na vybraném sériovém portu. Tím je započato periodické dotazování aktivních účastnických stanic. MB_STATUS MbMasterEnable(MB_HANDLE portHandle);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. Návratová hodnota Při úspěšném provedení funkce vrací status byte stanice Master. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
59
PŘÍLOHA B
B.4
MbMasterDisable
Funkce MbMasterDisable() deaktivuje stanici Master na vybraném sériovém portu. Tím je ukončeno periodické dotazování aktivních účastnických stanic. MB_STATUS MbMasterDisable(MB_HANDLE portHandle);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. Návratová hodnota Při úspěšném provedení funkce vrací status byte stanice Master. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.5
MbGetMasterStatus
Funkce MbGetMasterStatus() při úspěšném provedení navrátí status byte stanice Master. MB_STATUS MbGetMasterStatus(MB_HANDLE portHandle);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. Návratová hodnota Při úspěšném provedení funkce vrací status byte stanice Master. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
60
PŘÍLOHA B
B.6
MbMasterReset
Funkce MbMasterReset() provede reset stanice Master a všech stanic Slave. Reset stanice Master spočívá ve vymazání hromadné vyrovnávací paměti pro příchozí data a vynulování všech bitů status byte. Reset stanice Slave spočívá ve vymazání vyrovnávací paměti pro příchozí data a vynulování všech bitů status byte dané stanice. Pro úspěšné provedení této funkce musí být stanice Master v deaktivovaném stavu. BOOL MbMasterReset(MB_HANDLE portHandle);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.7
MbSlaveEnable
Funkce MbSlaveEnable() aktivuje vybranou účastnickou stanici. Pokud je stanice Master aktivní, je od této chvíle daná účastnická stanice periodicky dotazována a mohou jí být posílána data. MB_STATUS MbSlaveEnable(MB_HANDLE portHandle, DWORD stationNumber, DWORD priorityLevel);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo aktivované účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. stationPriority Priorita aktivované účastnické stanice. Tento parametr může nabývat hodnot od 1 do 15, kde 1 znamená nejvyšší možnou prioritu.
61
PŘÍLOHA B Návratová hodnota Při úspěšném provedení funkce vrací status byte dané stanice Slave. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.8
MbSlaveDisable
Funkce MbSlaveDisable() deaktivuje vybranou účastnickou stanici. Tím je přerušeno její periodické dotazování. Stanici již také od této chvíle nemohou být posílána žádná data. MB_STATUS MbSlaveDisable(MB_HANDLE portHandle, DWORD stationNumber);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo deaktivované účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. Návratová hodnota Při úspěšném provedení funkce vrací status byte dané stanice Slave. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
62
PŘÍLOHA B
B.9
MbGetSlaveStatus
Funkce MbGetSlaveStatus() při úspěšném provedení navrátí status byte vybrané stanice Slave. MB_STATUS MbGetSlaveStatus(MB_HANDLE portHandle, DWORD stationNumber); Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. Návratová hodnota Při úspěšném provedení funkce vrací status byte dané stanice Slave. Význam jednotlivých bitů tohoto bajtu je popsán v kapitole 5.1.2. Při neúspěchu je návratová hodnota rovna 0xFF. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.10
MbSlaveReset
Funkce MbSlaveReset() provede reset vybrané účastnické stanice. Reset stanice spočívá ve vymazání vyrovnávací paměti pro příchozí data a vynulování všech bitů status byte dané stanice. Pro úspěšné provedení této funkce musí být daná stanice v deaktivovaném stavu. BOOL MbSlaveReset(MB_HANDLE portHandle, DWORD stationNumber); Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
63
PŘÍLOHA B
B.11
MbGetSlavePriority
Funkce MbGetSlavePriority() při úspěšném provedení navrátí hodnotu aktuálně nastavené priority dané účastnické stanice. DWORD MbGetSlavePriority(MB_HANDLE portHandle, DWORD stationNumber);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu priority dané účastnické stanice. V opačném případě je navrácena hodnota DWORD_MAX, definovaná v hlavičkovém souboru Windows.h.
B.12
MbChangeSlavePriority
Funkce MbChangeSlavePriority() při úspěšném provedení nastaví novou hodnotu priority vybrané účastnické stanice. BOOL MbChangeSlavePriority(MB_HANDLE portHandle, DWORD stationNumber, DWORD newPriority);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. stationNumber Číslo účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31. stationPriority Priorita účastnické stanice. Tento parametr může nabývat hodnot od 1 do 15, kde 1 znamená nejvyšší možnou prioritu.
64
PŘÍLOHA B Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.13
MbRead
Funkce MbRead() přečte jeden datový blok z vyrovnávací paměti pro příchozí data. BOOL MbRead(MB_HANDLE portHandle, PMB_MSG message);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. message Ukazatel na datovou strukturu MB_MSG. Tato struktura je deklarována ve stejném hlavičkovém souboru jako exportované funkce a popsána v kapitole 5.1.2 této práce. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.14
MbWrite
Funkce MbWrite() pošle data vybrané účastnické stanici. BOOL MbWrite(MB_HANDLE portHandle, DWORD stationNumber, PCHAR buffer, DWORD numberOfCharsToWrite);
Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus.
65
PŘÍLOHA B stationNumber Číslo účastnické stanice, které jsou posílána data. Tento parametr může nabývat hodnot od 0 do 32. Hodnota 0 reprezentuje hromadný přenos dat, kdy jsou posílaná data určena pro všechny stanice. buffer Ukazatel na datový buffer. numberOfCharsToWrite Velikost datového bufferu. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
B.15
MbGetVersionInfo
Funkce MbGetVersionInfo() slouží k získání informací o verzi nainstalovaného ovladače a použité knihovny. BOOL MbGetVersionInfo(MB_HANDLE portHandle, LPTSTR dllVer, LPTSTR drvVer); Parametry portHandle Handle na sériový port využívaný pro komunikaci po sběrnici Measurement Bus. dllVer Ukazatel na uživatelem alokovanou paměť, kam bude uložen string obsahující informace o verzi použité knihovny. drvVer Ukazatel na uživatelem alokovanou paměť, kam bude uložen string obsahující informace o verzi nainstalovaného ovladače. Návratová hodnota Při úspěšném provedení funkce vrací hodnotu true. V opačném případě vrací funkce hodnotu false. Voláním funkce GetLastError z WinAPI je možné získat informace o vzniklé chybě.
66
Příloha C Schéma zapojení fyzického rozhraní EIA-485
67
28 9
" 27 2
7
88 0 2
1!
4! 3 41 1
14 2" 4 8 46 8 2232
33 1 2
39 3 9 2 1#1 2 7 2
6 4##1 6
4
0
8 0
% $
4! # 1!
& %
6407389
4
& %39 3 & %22
4#' 1!#
0123245
1! 4!
4
882 0
88 0
45#
4!5#
243 784 249 784
4 2784
88 0
6407389
$
"
2 88 0 9 703
88 0
$
1!5#
(
9 4
3
2
9 3 7 0 9 9 7 0
&
#
2
3
9
7803
9
6
5PŘÍLOHA C
76 7 777 7
3 6 5
77 4489
7 733
47
7
"3
73 7 77 74
0123456
7"
! 7
4
6 74
4
& $&
77 44389
4
4
"7 " "3 "
" ""6 "5 " "74 "77 "7 "73 "7
"7
$
#0 #2!$
7 0 2!$ 3
77 44 89
#
77 7 4489 963
ÿ2$
%71441
4 4
4
69
6
5
Příloha D Seznam použitých součástek Název Počet R0805 120R 5% 1 R0805 270R 5% 3 R0805 1K 5% 1 BLM21AG 1 CK0805 100N 10 CK0805 10N 1 CK0805 47P 2 CTS 4M7/10V A 3 3mm LED GREEN 1 3mm LED YELLOW 2 IRF7304 1 FT232RL 1 ISO3086 1 AM1S-0505SZ 1 USB-MINI B F SMD 1 CAN 15 V 90 1
Typ součástky odpor odpor odpor feritová perla keramický kondenzátor keramický kondenzátor keramický kondenzátor tantalový kondenzátor LED dioda LED dioda výkonový MOSFET USB<->UART IO budič EIA-485 DC/DC měnič konektor USB konektor Canon 15
Označení R6 R3/R4/R5 R1 FB C2/5/6/7/8/13/14/15/16 C1 C3/C4 C9/C10/C11 PWR LED RX LED/TX LED T1 U1 U2 T2 J1 J2
Tabulka D.1: Seznam použitých součástek.
70
Literatura [1] DIN 66348-2. Interface and basic data link control procedure for serial measurement data communication. Deutsches Institut für Normung e. V., 1989. [2] N. Zisky and H. Schumny. Open communication with a fieldbus at petrol stations. In Proc. 23rd Euromicro Conf. EUROMICRO 97. ’New Frontiers of Information Technology’. Short Contributions, pages 100–105, 1997. [3] Patzke, R., Measurement Bus - A Simple Way of Fieldbus Technology, [online], [cit. 2010-12-01],
. [4] J. Novák. Measurement bus. Automatizace, 41(7):427–430, 1998. [5] Walter Oney. Programming the Microsoft Windows Driver Model. Microsoft Press, 2nd edition, 2003. [6] David Solomon and Mark Russinovich. Windows Internals. Microsoft Press, 5th edition, 2009. [7] Windows Driver Model (WDM), [online], [cit. .
2010-12-01],
[8] Dokumentace Microsoft Windows Driver Kit verze 7600.16385.1. [9] Calling Win32 DLLs in C# with P/Invoke, [online], [cit. 2010-12-01], . [10] Sharing Is Caring - Sharing Events Between Kernel-User Mode , [online], [cit. 2010-12-14], . [11] Jan Kravar, Programové vybavení pro diagnostiku automobilových řídicích jednotek. Diplomová práce, České vysoké učení technické v Praze, Fakulta elektrotechnická, 2008. [12] Specifikace Universal Serial Bus. Revize 2.0, květen 2000. [13] Future Technology Devices International Ltd. FT232R USB UART IC, [online], [cit. 2010-12-22], . [14] Texas Instruments, Isolated 5-V Full and Half-duplex RS-485 Transceivers., [online], [cit. 2010-12-22], . 71
LITERATURA [15] Dokumentace Microsoft Visual Studio 2008, verze 9.0.21022.8. [16] Kernel-Mode Code Signing Walkthrough, [online], [cit. 2010-12-25], .
72
