SW implementace uzlu Master sběrnice

Transkript

Č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.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
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
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
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)
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
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
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
č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.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
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
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
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
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
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
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
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
Návratová hodnota
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
Návratová hodnota
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
Návratová hodnota
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
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
stationNumber
Číslo deaktivované účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31.
Návratová hodnota
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
stationNumber
Číslo účastnické stanice. Tento parametr může nabývat hodnot od 1 do 31.
Návratová hodnota
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
stationNumber
Návratová hodnota
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
stationNumber
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 newPriority);
Parametry
portHandle
stationNumber
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
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
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
o vzniklé chybě.
B.14
MbWrite
Funkce MbWrite() pošle data vybrané účastnické stanici.
BOOL MbWrite(MB_HANDLE portHandle,
PCHAR buffer,
DWORD numberOfCharsToWrite);
Parametry
portHandle
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
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
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
o vzniklé chybě.
66
Příloha C
Schéma zapojení fyzického rozhraní
EIA-485
67
28
9
"
27
2
7
880
2
1! 4! 3
41
1 14 2"
4
8
46
8 2232
331 2 39
3
9 2
1#1 2
7
2
6
4##1
6
4
0
80 %
$
4!
#
1!
&
%
6407389
4
&
%39
3
&
%22
4#'
1!#
0123245
1!
4!
4
8820 880
45#
4!5#
243
784 249
784
4
2784
880
6407389
$
"
2
880 9703
880
$
1!5#
(
9
4
3
2
93
70 99
70
&
#
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
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], <http://www.measurement-bus.de/Engl-Seiten/fieldc.html>.
[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.
<http://www.microsoft.com/whdc/archive/wdmoverview.mspx>.
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],
<http://msdn.microsoft.com/en-us/magazine/cc164123.aspx>.
[10] Sharing Is Caring - Sharing Events Between Kernel-User Mode , [online],
[cit. 2010-12-14], <http://www.osronline.com/article.cfm?id=108>.
[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], <http://www.ftdichip.com/Support/Documents/DataSheets
/ICs/DS_FT232R.pdf>.
[14] Texas Instruments, Isolated 5-V Full and Half-duplex RS-485 Transceivers., [online], [cit. 2010-12-22], <http://focus.ti.com/lit/ds/symlink/iso3086.pdf>.
71
LITERATURA
[15] Dokumentace Microsoft Visual Studio 2008, verze 9.0.21022.8.
[16] Kernel-Mode Code Signing Walkthrough, [online], [cit. 2010-12-25], <http://
www.microsoft.com/whdc/driver/install/drvsign/kmcs-walkthrough.mspx>.
72

SW implementace uzlu Master sběrnice

Transkript

Podobné dokumenty

Gymnázium, Pardubice, Mozartova 449

1. - Xerox