D IPL O M O V Á PR Á C E Profibus D P M aster na PC

Ž Ž

Ž

CESKÉ VYSOKÉ UCENÍ TECHNICKÉ V PRAZEFAKULTA ELEKTROTECHNICKÁ

KATEDRA RÍDICÍ TECHNIKY

Pavel Trnka2004

DIPLOMOVÁ PRÁCE

Profibus DP Master na PC

Profibus DP Master na PC Pavel Trnka

Anotace

Tato práce předkládá řešení problému připojení průmyslové sběrnice Profibus k běžnémuPC bez použití speciálního hardwaru. Práce implementuje řídící jednotku sběrnice (master)pro Profibus DP (Distributed Peripherals), což je nejrozšířenější varianta tohoto standarduurčená pro komunikace mezi řídícími jednotkami a vzdálenými periferiemi (snímače, akčníčleny).

Běžně používaná řešení jsou nákladná, protože jsou postavena na speciálních rozšiřují-cích kartách používajících vlastní procesory, zákaznické obvody a jiné obvody s dostateč-ným výkonem na splnění vysokých požadavků Profibusu.

Tato práce oproti tomu umožňuje připojit Profibus pomocí běžného sériového portu RS–232 nebo pomocí jednoduchých zásuvných PCI karet s obvody UART. Profibus DP Masterje vytvořen softwarově a speciální vlastnosti hardwarových řešení jsou nahrazeny maximál-ním využitím běžně dostupných prostředků v PC, což bylo hlavně umožněno napsáním pro-gramu jako ovladač pro operační systémy Windows NT/2000/XP. Navíc aplikační rozhraníje kompatibilní s řešeními firmy Siemens, což umožňuje jednoduchou záměnu.

Annotation

Solution for connecting fieldbus Profibus to common PC without use of special hardwarewill be proposed in this work. The work implements bus control unit (master) for ProfibusDP (Distributed Peripherals), which is most widely used variation of this standard. It’sdesigned for communication between control units and distributed peripherals (sensors,actuators).

Commonly used solutions are expensive, because they are built on special expansioncards, which are using their own processors, customer’s circuits or another circuits withenough power to meet high requirements of Profibus.

On the other side, this work allows for connecting Profibus to standard serial portRS–232 or to simple PCI expansion card based on UART circuit. Profibus DP Master iscreated as software implementation and special features of hardware implementations aresubstituted by maximal use of common means in PC. This was mainly possible by creatingProfibus DP Master as system driver for Windows NT/2000/XP. Moreover applicationinterface is compatible with solutions from Siemens company, which allows for simplereplacement.

I


Prohlášení

Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouzepodklady (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/2000Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některýchzákonů (autorský zákon).

V Praze dne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .podpis

Poděkování

Nejprve bych rád poděkoval svému vedoucímu diplomové práce Ing. Petru Smolíkovi zajeho vstříctnost, ochotu při konzultacích a čas, který mi věnoval. Dále Ing. Pavlu Píšoviza mnoho podnětných rad z jeho bohatých praktických zkušeností a Ing. Pavlu Burgetoviza jeho pomoc při tvorbě této diplomové práce.

Poděkování také patří mé rodině za jejich neustálou podporu a domácí zázemí po celoudobu studia. V neposlední řadě také mnoha přátelům, jejichž společnost mi vždy dodávalaenergii k další práci.

II

Obsah

1 Úvod 11.1 Proč ovladač? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Struktura této práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Profibus DP 42.1 Fyzická vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Linková vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Provoz na sběrnici . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Formáty rámců . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Stavový automat Profibusu pro FDL vrstvu . . . . . . . . . . . . . 92.2.4 Řešení událostí na sběrnici . . . . . . . . . . . . . . . . . . . . . . . 14

3 Realizace fyzické vrstvy 163.1 Použití standardního sériového portu . . . . . . . . . . . . . . . . . . . . . 163.2 Použití rozšiřujících zásuvných karet . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Obvod OX16PCI954 . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Tvorba ovladačů pro operační systém Windows 214.1 Nástroje potřebné pro vývoj ovladače . . . . . . . . . . . . . . . . . . . . . 234.2 Požadavky systému na ovladač . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Rozdíl mezi Legacy a PnP ovladači . . . . . . . . . . . . . . . . . . . . . . 24

4.3.1 Plug and Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Způsob práce ovladače . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Prioritní úrovně (IRQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.6 Základní struktura a rutiny Legacy ovladače . . . . . . . . . . . . . . . . . 27

4.6.1 DriverEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.6.2 Unload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6.3 Interrupt Service Routine (ISR) . . . . . . . . . . . . . . . . . . . . 30

III


4.6.4 Deferred Procedure Call (DPC) . . . . . . . . . . . . . . . . . . . . 304.6.5 IoTimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6.6 Dispatch Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.7 Struktura ovladače s podporou PnP . . . . . . . . . . . . . . . . . . . . . . 314.7.1 DriverEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.7.2 AddDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.7.3 DispatchPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.7.4 Interrupt Service Routine (ISR) . . . . . . . . . . . . . . . . . . . . 33

4.8 Používání paměti ovladačem . . . . . . . . . . . . . . . . . . . . . . . . . . 334.9 Umístění konfigurace v registrech . . . . . . . . . . . . . . . . . . . . . . . 344.10 Ladící prostředky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.11 INF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.12 Property Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Realizace linkové vrstvy - ProfiM 385.1 Programová implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Nároky Profibusu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Ovládání převodníku a jeho využití k časování . . . . . . . . . . . . . . . . 405.4 Časování s obvodem 16C950 . . . . . . . . . . . . . . . . . . . . . . . . . . 425.5 Princip činnosti ProfiMu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.6 Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Zatížení procesoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Aplikační rozhraní FDL vrstvy 476.1 Služby linkové vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Komunikace s FDL vrstvou . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7 Závěr 527.1 Co by šlo vylepšit nebo přidat . . . . . . . . . . . . . . . . . . . . . . . . . 53

A Příklad použití ProfiMu 54

B Ukázková aplikace ProfiMu 57

C Seznam zkratek 59C.1 Zkratky pro Profibus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.2 Zkratky pro DDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

D Obsah přiloženého CD 61

IV

Kapitola 1Úvod

Průmyslová sběrnice Profibus [5] patří mezi nejrozšířenější sběrnice nasazované v průmyslu.Její nejčastěji používanou variantou je Profibus DP (Distributed Peripherals). Ta je určenapro komunikaci mezi řídícími jednotkami (PLC, průmyslové počítače) a decentralizovanýmiperiferiemi, kterými jsou vzdálené snímače a akční členy. Místo mnohavodičového spojení,které by každou periferii připojovalo zvlášť jedním vedením, je použito jednoho propojeníProfibusem s topologií lineární sběrnice, které vše spojuje.

Nasazením Profibusu je zaručena rychlá a spolehlivá výměna dat a navíc je možné jednusběrnici sdílet více řídícími jednotkami. Na druhou stranu pokud chceme používat běžnéPC jako aktivní řídící stanici master a připojit k ní Profibus DP, narazíme na vysokoucenu zásuvných karet, které Profibus mastera s využitím zákaznických obvodů a jinýchhardwarových řešení implementují.

Motivací této práce proto bylo, navrhnout co nejlevnější a co nejsnáze použitelnouimplementaci aktivní stanice Profibus DP Master pro PC, která by byla z aplikačníhopohledu kompatibilní s některým v praxi rozšířeným řešením a umožnila tak jeho záměnu.

Hardwarová vrstva Profibusu je postavena na standardu RS–485 a tak pro samotnépřipojení Profibusu realizovaného v této práci stačí běžný sériový port RS–232 s jednodu-chým převodníkem RS 232/485, který nepotřebuje externí napájení. To je řešení použitelnépro nízké přenosové rychlosti. Potřebujeme-li dosáhnout vysokých přenosových rychlostí(v současnosti je maximem 12Mbps), potom tato práce také umožňuje použít PCI karets obvody UART (Universal Asynchronous Receiver/Transmitter), kde maximální rychlostje dána pouze výkonem procesoru a možnostmi použitého UART obvodu.

Jednoduchost připojujícího hardwaru však přesunula veškerou práci k tomu účelu ob-vykle používaných speciálních obvodů na software. Ten tak musí s maximálním využitímvšech dostupných prostředků běžného PC nahradit hardwarová řešení.

Postupná práce na softwaru ukázala, že jedinou schůdnou cestou implementace promoderní operační systémy je vytvořit Profibus DP Master jako ovladač. A tak byl vytvořen

1


ovladač pro operační systém Windows NT 4.0 a přidáním Plug and Play podpory také prooperační systémy Windows 2000 a Windows XP. Vytvořený ovladač implementuje ProfibusDP Mastera pro PC až po FDL vrstvu (linkovou vrstvu).

Nepodceněnou součástí této práce byla také volba názvu projektu, kterým bylo vybránoslovo ProfiM pro jistou podobnost s názvem řešené problematiky a hlavně kvůli malémupočtu relevantních odkazů nalezených internetovými vyhledávači.

1.1 Proč ovladač?

Důvodů k nutnosti vytvořit DP mastera jako ovladač bylo několik. Především to byla po-třeba v operačních systémech Windows časovat s periodami v řádech desítek mikrosekund,což pro běžné aplikace není dosažitelné. Časováním je zde myšleno vyvolávání obslužnýchrutin po uplynutí velmi krátkých časových intervalů. Jedinou možností jak toho dosáh-nout bylo využít přerušovacích možností a hardwarových vlastností standardního sériovéhoportu nebo UART obvodů na rozšiřujících PCI kartách. To by ovšem z běžné aplikace ne-bylo možné, neboť těm není operačním systémem dovolen přímý přístup na hardware.

Dalším důvodem byla nutnost řídit převodník RS 232/485, což je sice teoreticky jedno-duché, ale při softwarové implementaci pod Windows to představovalo náročný problém,který se také podařilo vyřešit jen díky vytvoření ovladače. Nakonec implementace ve forměovladače začlenila rozhraní Profibusu do operačního systému, což z aplikační vrstvy přinášívýhody pro další používání.

1.2 Struktura této práce

Ke čtení a dobrému pochopení této práce je vhodné mít alespoň částečnou znalost proble-matiky Profibusu - ta je sice zhruba popsána v kapitle 2, avšak v některých kapitolách semohou najít principy a pojmy, které nejsou úplně vysvětleny.

Kapitola 2 zhruba popisuje principy Profibusu, především jeho linkové vrstvy, jejíž rea-lizace je hlavní částí této práce. Podrobnější popis nalezneme například v [1] nebopřímo v normě [5].

Kapitola 3 ukazuje jak připojit Profibus k PC z hlediska fyzické vrstvy, neboli jak připojitsběrnici používající průmyslový standard RS–485.

Kapitola 4 popisuje jak se v operačních systémech Windows tvoří ovladače. Popisujejejich základní strukturu, jaké nástroje jsou pro tvorbu potřeba a jaké jsou odlišnostiod psaní běžných programů. Tato kapitola je užitečná tím, že takto shrnuté informaceo psaní ovladačů pro fyzická zařízení jsou málo dostupné. Setkáme se buď s povrchnímpopisem, anebo s detailní dokumentací.

2


Kapitola 5 ukazuje, jak je vytvořena linková vrstva Profibus DP Mastera - jak probíhaljejí vývoj a jaké problémy bylo při tom potřeba vyřešit.

Kapitola 6 popisuje rozhraní, které aplikace (vyšší vrstva DP master nebo přímo FDLaplikace) používá pro komunikaci s FDL vrstvou (ovladačem).

3

Kapitola 2Profibus DP

Profibus DP (Distributed Peripherals) je nejpoužívanější varianta průmyslové sběrnice Pro-fibus, která je určena zejména pro komunikaci mezi řídícími jednotkami a decentralizova-nými periferiemi. Obvykle tak jedním komunikačním kanálem nahrazuje mnohavodičovéspojení řídící jednotky se snímači a akčními členy, kde použitím Profibusu je současnězajištěna spolehlivá a rychlá výměna dat.

Fyzická v r s t v a

L inko v á v r s t v a

Síť o v á v r s t v a

T r a ns p o r t ní v r s t v a

R e l a ční v r s t v a

P r e ze nt a ční v r s t v a

A p l ika ční v r s t v a

Fyzická v r s t v a ( P H Y )

Služby rozhraníŘ íze ní p řís t up u na s bě rni c i

Pře nos o v ý p ro t o k ol( F D L )

A p l ika ční v r s t v a ( A P P ) FM A 7

F D L U s e r F M A 1 / 2 U s e r

F M A 7 F i e l d bus M anag e m e nt L ay e r 7F M A 1 / 2 F i e l d bus M anag e m e nt L ay e rs 1 and 2

F D L F i e ld bus D at a L i nkPH Y Phys i c al

~

ISO/OSI model P r of i b u s D P

Obrázek 2.1: ISO/OSI model a Profibus DP

4


Profibus DP má vrstvenou architekturu postavenou podle modelu ISO/OSI (obrá-zek 2.1). Z jednotlivých vrstev využívá fyzickou, linkovou a aplikační. Nevyužité čtyřivrstvy jsou částečně zahrnuty v ostatních. Tato práce implementuje fyzickou a linkovouvrstvu a nabízí rozhraní pro aplikační vrstvu.

2.1 Fyzická vrstva

Fyzická vrstva definuje požadavky na vlastnosti přenosového kanálu. Norma Profibusu [5]nabízí jako jednu z možností pro realizaci fyzické vrstvy použití v průmyslu rozšířenéhostandardu RS–485. Tím jsou určeny fyzické vlastnosti kanálu a kódování dat na sběrnici.

Důležitou vlastností, která je normou pro fyzickou vrstvu definována, je rychlost komu-nikace. Ta je pro Profibus DP specifikována v rozsahu 9,6kbps až 12Mbps (tabulka 3.1).Norma pro ni definuje maximální přípustnou odchylku 0,3 %, což může v praxi znemožňo-vat dosažení některých komunikačních rychlostí. Například pokud má UART nevhodnouzákladní hodinovou frekvenci a pouze hrubé možnosti dělení této frekvence. Praxe všakukazuje, že přijatelná odchylka rychlosti je až 1 %.

2.2 Linková vrstva

Linková vrstva má za úkol řídit přístup na sběrnici (Medium Access Control), sestavovatvysílané rámce, dekódovat příchozí rámce a poskytovat vyšší vrstvě služby datové výměnya služby umožňující řízení a správu linkové vrstvy.

Linková vrstva je tvořena částí FDL (Fieldbus Data Link), která zajišťuje její hlavnífunkce a částí FMA (Fieldbus Management), zajišťující její řízení. Ačkoliv to není úplněpřesné, je linková vrstva často označována jako FDL vrstva.

2.2.1 Provoz na sběrnici

Profibus umožňuje na jednu sběrnici připojit až 127 stanic. Komunikační kanál tvořenýsběrnicí se tak stává sdíleným fyzickým prostředkem, na kterém v jeden časový okamžikmůže vysílat pouze jedna stanice. K efektivnímu a deterministickému využití sběrnice jsouproto normou určena přesná pravidla.

Stanice jsou rozděleny na dva druhy: master a slave. Stanice typu master jsou určenyk řízení provozu na sběrnici a k iniciování komunikace. Naproti tomu, stanice typu slavemůže začít vysílat pouze, pokud k tomu byla stanicí typu master přímo vyzvána.

Aby mohla fungovat na sběrnici komunikace, je potřeba, aby na ní byla alespoň jednastanice master. Řídících stanic typu master však může být i více. K tomu, aby mohly býtsoučasně na jedné sběrnici, je potřeba, aby se v řízení sběrnice střídaly. To je zajištěno tím,že stanice master si předávají pověření k vysílání tzv. token. Předávání probíhá v pořadí

5


rostoucích adres a master s nejvyšší adresou předává token zpět masteru s nejnižší ad-resou. Tímto postupným předáváním mezi sebou stanice typu master vytvářejí strukturulogického kruhu.

Struktura logického kruhu je určena seznamem LAS (List of Active Stations), kterýsi vytváří a udržuje každý master na sběrnici. Je to seznam všech adres, v němž je prokaždou stanici uvedeno, jestli se jedná o aktivní stanici master. Tento seznam si každástanice vytváří sledováním provozu na sběrnici. Z něj také zjistí, jaké další stanici mápředat token (NS - Next Station) a od jaké stanice přijde token nazpátek (PS - PreviousStation). Přijme-li master token, získává pověření vysílat na sběrnici. Může tak posílatpožadavky stanicím typu slave, případně komunikovat s jiným masterem.

Aby byla zajištěna horní časová hranice, za kterou se ke každému masteru opět vrátípověření k vysílání, je doba držení tokenu omezená. Je omezená časovým intervalem TTR

(Time To Reach), který je definován v každé konfiguraci sběrnice Profibus a udává poža-dovanou maximální periodu oběhu tokenu mezi všemi stanicemi master.

Drží-li master token, je povinen před každým vysíláním zjišťovat, jestli mu pro jehodržení ještě zbývá čas. K tomuto účelu měří časový interval od okamžiku, kdy naposledypředal token další stanici master v logickém token ringu (NS). Tento interval porovnávás hodnotou parametru TTR. Překročí-li časový interval tento parametr, předává token dalšístanici master. Zvláštním případem je, pokud čas nezbývá už při přijetí tokenu. V takovémpřípadě může master zpracovat jeden požadavek vysoké priority.

Podstatnou částí normy je popis chování Profibusu při tzv. přechodných stavech, cožjsou dočasné události na sběrnici pozastavující její normální činnost, mezi které patří na-příklad: první spuštění komunikace na sběrnici, připojení nebo odpojení stanice master,výpadek tokenu, chybný rámec atd. (některé budou popsány v části 2.2.4).

Není-li sběrnice v přechodném stavu, potom obvykle probíhá cyklická výměna dat mezistanicemi master a jejími příslušnými stanicemi slave (distribuovanými periferiemi). Přitéto datové výměně master cyklicky posílá každé své stanici slave výstupní data a zároveňčte data vstupní. Nejčastěji nastavuje a čte digitální nebo analogové výstupy a vstupy.Použitím speciálního příkazu sběrnice je navíc zajišťěna synchronizace vstupně/výstup-ních hodnot na všech stanicích slave, neboli současné nastavení všech výstupů a současnépřečtení všech vstupů v jeden časový okamžik.

Celá datová výměna tak připomíná část scan cyklu v PLC a to ne náhodou, neboťprávě PLC bývají nejčastějšími stanicemi typu master.

Aby bylo možné stanice za chodu na sběrnici přidávat nebo je odebírat, udržuje každýmaster seznam obsazenosti jednotlivých adres v jeho adresovém prostoru (GAP), což jerozsah adres od jeho adresy (TS - This Station) až po adresu následujícího mastera (NS).Tento seznam se nazývá „GAP listÿ a jeho adresy jsou v určitých časových intervalechcyklicky masterem testovány pro zjištění, jestli se na nich nachází stanice typu master,stanice typu slave nebo je adresa neobsazená.

6


2.2.2 Formáty rámců

B0 B1 B2 B7B6B5B4B3

SUD

Á P

ARI

TA

STA

RT B

IT

STO

P BI

T

1 5 109876432 11LS

B

MSB

Obrázek 2.2: Formát znaku Profibusu

Základní datovou jednotkou na sběrnici Profibus je jedenácti bitový znak (obrázek 2.2),který se skládá z jednoho start bitu, následovaného osmi datovými bity, sudým paritnímbitem a jedním stop bitem. Z těchto znaků jsou sestavovány rámce (pakety), pro něžna Profibusu platí důležitý požadavek, aby mezi následujícími znaky rámce nebyly žádnéčasové mezery. Tento požadavek se může zdát banálním, ale také se může stát problémemv případě, pokud použitý vysílač sériového kanálu nemá FIFO paměť a nemáme možnostpokaždé dostatečně rychle obsluhovat příchozí přerušení.Pro veškerou komunikaci jsou na Profibusu používány celkem čtyři typy rámců:

1. Rámec bez dat (obrázek 2.4)

2. Rámec s daty fixní délky (obrázek 2.5)

3. Rámec s daty proměnné délky (obrázek 2.6)

4. Rámec pověření k vysílání - token (obrázek 2.3)

Významy zkratek názvů jednotlivých bytů v rámcích viz. příloha C.1. Každý typ rámcemá přesně danou strukturu rámce požadavku a strukturu rámce odpovědi, která by napožadavek měla přijít. Zvláštní odpovědí je rámec Short Acknowledge (obrázek 2.4), kterýmůže přijít na libovolný požadavek a obvykle potvrzuje provedení požadavku.

SD4 - Start Delimiter = 0xDC

SYN SD 4 D A SA

Obrázek 2.3: Formát rámce pověření (Token Frame)

7


Formát rámc e p oža d a v k u :

L

Formát rámc e o d p o v ě d i :

L

Formát S h ort A c k n ow l e d g e o d p ov ěd i :

S D 1 - S t a rt D e l i mi t e r = 0 x 1 0 S Y N - S y n c h ro n i z a t i o n P e ri o d ( mi n . 3 3 T b i t )E D - E n d D e l i mi t e r = 0 x 1 6 S C - S i n g l e C h a ra c t e r = 0 x E 5

S Y N S D 1 D A S A F C F C S E D

S D 1 D A S A F C F C S E D

S C

Obrázek 2.4: Formát rámce bez dat

Formát rámc e p oža d a v k u :

LD A T A _ U N I T

Formát rámc e od p ov ěd i :

L

S D 3 - S t a rt D e l i mi t e r = 0 x A 2 E D - E n d D e l i mi t e r = 0 x 1 6

S Y N S D 3 D A S A F C F C S E D

S D 3 D A S A F C F C S E DD A T A _ U N I T

Obrázek 2.5: Formát rámce s daty fixní délky

DATA_UNITFormát rámc e p oža d a v k u :

L

DATA_UNITFormát rámc e od p ov ěd i :

L

S D 2 - S t a rt D e l i mi t e r = 0 x 6 8 E D - E n d D e l i mi t e r = 0 x 1 6

S Y N S D2 LE LE r S D2 DA S A F C F C B E D

S D2 LE LE r S D2 DA S A F C F C B E D

Obrázek 2.6: Formát rámce s daty proměnné délky

8


2.2.3 Stavový automat Profibusu pro FDL vrstvu

Funkci FDL, neboli linkové vrstvy, lze dobře popsat a také realizovat jako stavový auto-mat s deseti stavy a přechody mezi nimi (obrázek 2.7). Po zapnutí napájení nebo resetuzačíná automat ve výchozím stavu „Offlineÿ. Reakcemi na vnější události, požadavky nižšía vyšší vrstvy přechází automat mezi jednotlivými stavy. Červenou barvou jsou vyznačenypřechody, kterými automat prochází při činnosti stanice v multi-master systému bez vý-jimečných situací. Přechody vyznačené černou barvou odpovídají událostem souvisejícíchs kolizemi na sběrnici, ztrátou tokenu, poruchami sběrnice a změnami v logickém okruhu.

L is te n _ T o k e n1

U s e _ T o k e n4

A c tiv e _ Id le2

O ff lin e0

C la im _ T o k e n3

A w a it_ D a ta _ R e s p5

C h e c k _ A c c e s s _ T im e6

P a s s _ T o k e n7

C h e c k _ T o k e n _ P a s s8

A w a it_ S ta tu s _ R e s p9

1

2

3

4

56

7

8

9

1 0

1 1

1 2 1 3

1 4

1 5

1 61 7

1 9

2 01 8

2 1

2 2

2 3

2 42 5

2 6

2 7

2 8

2 9

3 0

Obrázek 2.7: Stavový automat FDL vrstvy

V následujících odstavcích bude popsána činnost stavového automatu. Čísla v závorkáchodpovídají očíslovaným šipkám v obrázku 2.7, které reprezentují přechody mezi jednotli-vými stavy.

0 Offline

Do stavu „Offlineÿ vstupuje master ihned po zapnutí napájení. V tomto stavu jsouinicializovány pracovní parametry a je proveden self-test. Při inicializaci parametrů je na-

9


čtena konfigurace a jsou inicializovány datové struktury FDL vrstvy. Provedení self-testuje závislé na konkrétní implementaci mastera a obvykle zahrnuje test obvodů vysílače apřijímače. Ve stavu odpojení od sběrnice je uzavřen vnitřní loop-back a vyzkoušen testovacípřenos dat. Po úspěšné inicializaci a self-testu přechází (1) master do stavu „Listen Tokenÿ.

Další důvod pro přechod do stavu „Offlineÿ může nastat, pokud je na sběrnici deteko-vána stanice se stejnou adresou (2) nebo pokud je zjistěna hardwarová porucha v přístupuna sběrnici (26) - porucha vysílacích nebo přijímacích obvodů.

1 Listen Token

Je-li master připraven ke komunikaci, přechází do stavu „Listen Tokenÿ. V tomto stavuje zatím stále pasivní a pouze sleduje (3) provoz na sběrnici, aby zjistil jaké stanice jsouaktivní. To zjišťuje tak, že přijímá a analyzuje všechny rámce typu „Token Frameÿ (obrá-zek 2.3), pomocí kterých je mezi aktivními stanicemi v logickém okruhu předáváno pově-ření. Získáváním adres z rámců „Token Frameÿ si stanice vytváří seznam aktivních stanic- LAS (List of Active Stations).

Pokud se masteru podaří při vytváření seznamu LAS odposlouchat dvakrát identickýoběh tokenu mezi aktivními stanicemi, nastaví svůj stav na „Ready to enter logical to-ken ringÿ a dále pokračuje ve sledování provozu na sběrnici a aktualizaci seznamu LAS.Z vytvořeného seznamu LAS master určí svého předchůdce (PS) a následovníka (NS) v lo-gickém okruhu. Ve stavu „Listen Tokenÿ zůstává až do příchodu požadavku „Request FDLStatusÿ, který je adresován jemu. Jako odpověď master odesílá svůj stav „Ready to enterlogical token ringÿ a s besprostředně následovaným příchodem pověření přechází do stavu„Active Idleÿ (5). Takto je průběh popsán v normě, ale po příchodu rámce pověření sejedná spíše o současný přechod (5) a (9) do stavu „Use Tokenÿ.

Se vstupem do tohoto stavu spouští FDL časovač time-outu s periodou TTO. Jestližena sběrnici není do vypršení tohoto časovače detekován žádný provoz, potom FDL před-pokládá, že je potřeba inicializovat nebo obnovit logický okruh. Za tímto účelem přecházímaster do stavu „Claim Tokenÿ (4).

Při odposlouchávání rámců pověření se může stát, že přijde rámec, jehož adresa odesí-latele (SA) je shodná s naší adresou (TS). Jsou-li takové rámce přijaty dva, potom zřejměstanice s naší adresou na sběrnici již existuje a je zařazena do logického kruhu. Masterpřechází (2) do stavu „Offlineÿ a o této chybě uvědomuje vrstvu FMA1/2.

2 Active Idle

„Active Idleÿ je stavem, v němž je master plně zařazen do logického kruhu, avšak právěnemá pověření k vysílání (token). Sleduje provoz na sběrnici a odpovídá na požadavky, kterému jsou adresovány, případně pouze přijímá data ze sběrnice, které nevyžadují odpověď.

10


Přijde-li rámec pověření adresovaný pro nás (DA=TS), přechází (9) master do stavu„Use Tokenÿ. Detekuje-li master, že byl při předávání pověření v logickém kruhu přeskočen(např. stanice PS předala token stanici NS), přechází (7) do stavu „Listen Tokenÿ. Dotohoto stavu také přechází (7), pokud zjistí, že na sběrnici vysílá stanice s duplicitní adresou(rámec přijatý z vnějšku má SA=TS).

Se vstupem do tohoto stavu spouští FDL časovač time-outu s periodou TTO. Jestližena sběrnici není do vypršení tohoto časovače detekován žádný provoz, potom FDL před-pokládá, že došlo k rozpadu logického kruhu a je potřeba jej obnovit. Za tímto účelempřechází master do stavu „Claim Tokenÿ (8).

3 Claim Token

Do tohoto stavu přechází master v důsledku vypršení časovače pro sledování aktivityna sběrnici a to buď ze stavu „Listen Tokenÿ nebo „Active Idleÿ. Znamená to, že došlok rozpadu logického kruhu předávání pověření anebo naše stanice je jediný master nasběrnici. Došlo-li k rozpadu logického kruhu, tak máme již k dispozici seznamy GAPL aLAS a není nutno je znovu vytvářet, proto rovnou přecházíme (29) do stavu „Use Tokenÿ.Aby nedošlo k souběhu současným přivlastněním si tokenu několika mastery, je v hodnotětime-outu TTO zohledněna adresa TS podle vzorce:

TTO = 6.TSL + 2.TS.TSL,

kde TSL je interval časového slotu - Time Slot. Díky tomu se jako první pokouší o znovu-obnovení logického kruhu stanice master s nejnižší adresou.

Je-li potřeba logický kruh inicializovat, je nejprve na sběrnici dvakrát vyslán rámecpověření s adresami SA=TS a DA=TS. Potom master přechází (28) do stavu „Pass Tokenÿk vytvoření seznamu GAPL a určení stanice NS pro předání pověření.

4 Use Token

Stav, ve kterém je master vlastníkem oprávnění, a tudíž může inicializovat vysílánína sběrnici. Při vstupu do tohoto stavu nejprve stanice zjišťuje, kolik má času pro využitíoprávnění. Z časovače „Token Rotation Timerÿ zjistí, jak dlouho skutečně trval tokenu oběhlogického kruhu TRR (Real Rotation time). Porovnáním s požadovanou dobou oběhu TTR

(Target Rotation time) je určena maximální doba pro držení tokenu TTH (Token Holdingtime) jako:

TTH = TTR − TRR.

Zbývá-li čas (TTH > 0), vybere master z fronty požadavků rámec k vyslání. Přednostněvybírá první požadavek, který je na řadě z fronty s vysokou prioritou anebo je-li prázdná,potom vybere požadavek z nízkoprioritní fronty. Po vyslání rámce, na nějž je očekávána

11


odpověď přechází (11) do stavu čekání „Await Data Respÿ a zároveň je spuštěn časovač„Slot Timerÿ, který zajišťuje vyvolání time-outu pokud dotazovaná stanice neodpovídá.

Jeli-li při vstupu do stavu „Use Tokenÿ čas (TTH) vyčerpán, tj. (TTH <= 0), můžemaster ještě zpracovat jeden požadavek s vysokou prioritou.

Je-li požadavek z fronty takového typu, který nevyžaduje vysílání na sběrnici (např.požadavek na aktivaci SAP), je zpracován, odpověď poslána vyšší vrstvě a master začnezpracovávat další požadavek.

Jsou-li obě fronty prázdné, přechází (14) master do stavu „Check Access Timeÿ.

5 Await Data Resp

Stav, ve kterém čekáme na odpověď po vyslání rámce požadavku. Jestliže vyslanýrámec byl typu SDN (Send Data with No Acknowledge), nečekáme na odpověď a ihned senavracíme (13) do stavu „Use Tokenÿ.

Při čekání můžeme přijmout tyto tři typy rámců:

1. Platné potvrzení nebo odpověď od stanice, kterou jsme adresovali . Odpověď zpra-cujeme a přecházíme (13) zpět do stavu „Use Tokenÿ.

2. Platný rámec, avšak nečekaného typu (např. rámec pověření) nebo od jiné stanice nežočekáváme. Zřejmě někde nastala chyba a tak přecházíme (27) do stavu „Active Idleÿ.

3. Neplatný rámec, tj. například rámec s chybným Start Delimiterem, End Delimite-rem, chybným kontrolním součtem nebo chybnou paritou některého znaku. Přijde-litato odpověď nebo vyprší časovač „Slot Timerÿ, je požadavek opakovaně vyslán.Neodpovídá-li stanice ani na opakované požadavky je o tom uvědoměna vyšší vrstvaa master přechází (13) do stavu „Use Tokenÿ.

6 Check Access Time

V tomto stavu master kontroluje, jestli mu ještě zbývá čas k držení oprávnění. Zbývá-ličasu dostatek (TTH > 0), vrací (15) se do stavu „Use Tokenÿ. Je-li všechen čas vyčerpán,přechází (16) do stavu „Pass Tokenÿ.

7 Pass Token

V tomto stavu se FDL pokouší předat pověření následující stanici v logickém okruhu(NS). Zároveň s vysíláním rámce pověření by měl master současným příposlechem ověřit,

12


jestli se rámec skutečně daří vyslat. Nepřichází-li z příposlechu nazpět stejný rámec, jezřejmě chyba ve vysílacích obvodech a FDL přechází (26) do stavu „Offlineÿ.

Jestliže ještě před vysláním rámce pověření vyprší „GAP Update Timeÿ je obnoven nej-starší záznam v seznamu GAP a to tak, že master vyšle testované stanici z jemu příslušnéhoGAPu rámec typu „Request FDL Statusÿ a přejde (17) do stavu „Await Status Responseÿ.Na požadavek mohou přijít dvě odpovědi:

1. Je přijata odpověď od stanice typu slave nebo na požadavek nepřišla žádná odpověď(stanice s danou adresou na sběrnici neexistuje nebo nekomunikuje). Záznam v se-znamu GAP je aktualizován a po vyslání pověření pro NS přechází (20) master dostavu „Check Token Passÿ.

2. Je přijata odpověď od stanice typu master, která je připravena vstoupit do logickéhokruhu. Odpovídající master je označen jako NS (Next Station) a seznam GAP je pří-slušně zkrácen. Současně je tomuto masteru odeslán rámec pověření a FDL přechází(20) do stavu „Check Token Passÿ.

9 Await Status Response

Do tohoto stavu přechází master po vyslání požadavku „Request FDL Statusÿ k zjištěnístavu stanice na dané adrese. Při vstupu do tohoto stavu je spuštěn časovač s intervalemTSL. Přijde-li odpověď nebo vyprší-li časovač (stanice na dané adrese není nebo neodpo-vídá), přechází FDL do stavu „Pass Tokenÿ, kde je výsledek zpracován.

Další možností je, že při čekání na odpověď přijde rámec jiného typu, než jaký jeočekáván, FDL potom předpokládá, že jiná stanice je aktivní a přechází (24) do stavu„Active Idleÿ.

8 Check Token Pass

Master přechází do tohoto stavu, aby počkal na ověření úspěšného předání pověření.Předání je považováno za úspěšné pokud je ze sběrnice přijat rámec, který vyslala NS(SA=NS). Po ověření přechází (23) master do stavu „Active Idleÿ. Nedaří-li se stanici NSpověření předat, vrací (22) se master do stavu „Pass Tokenÿ, aby se pro předání pověřenízjistila následující stanice po NS v logickém kruhu.

Je-li master jediným na sběrnici (mono-master system), potom rovnou bez ověřo-vání, které nemá v takovém případě smysl, přechází přes stav „Active Idleÿ do stavu„Use Tokenÿ.

13


2.2.4 Řešení událostí na sběrnici

Silnou stránkou Profibusu jsou dobře propracované postupy k řešení vyjímečných událostína sběrnici. Většina z nich vyplývá z popsaného stavového automatu, ale některé ukážemekonkrétně.

Připojení stanice typu master na sběrnici

Po připojení stanice master na sběrnici se stanice chová pasivně a pouze sleduje provoz nasběrnici. Z rámců posílaných po sběrnici si vytváří seznam LAS a tak zjišťuje adresy dalšíchstanic typu master. Po úspěšném vytvoření seznamu, čeká master na přijetí požadavku„Request FDL Statusÿ od stanice master v jejímž adresním GAP prostoru leží. Po příchodutohoto požadavku odesílá odpověď, ve které oznamuje, že je připraven. To způsobí, že je muvzápětí poslán token, čímž vstupuje do logického ringu a může začít aktivně komunikovat.

Ztráta tokenu

Dojde-li z nějaké příčiny ke ztrátě tokenu, ustane provoz na sběrnici. Tento stav je stanicemimaster detekován a po vypršení time-outu si stanice master s nejnižší adresou přivlastnítoken a reinicalizuje logický okruh. Délka time-outu je určena podle adresy stanice, tudížmaster s nejnižší adresou se jako první pokusí o reinicializaci okruhu.

Odpojení stanice typu master ze sběrnice

Je-li stanice typu master náhle odpojena ze sběrnice, mohou nastat tyto dva případy:

1. V okamžiku odpojení vlastnila token jiná stanice master. Až přijde řada na odpoje-nou stanici, bude se jí předchozí stanice (PS) snažit předat token. Po opakovanémneúspěšném pokusu o předání tokenu odpojené stanici bude její adresa v seznamuLAS označena jako pasivní a zároveň bude z tohoto seznamu určena následující sta-nice z logického okruhu, které bude předán token.

2. Držela-li odpojená stanice master v okamžiku odpojení token, potom odpojenímdojde k jeho ztrátě. Tento stav je řešen podle popisu z předchozího odstavce.

Dotazovaná stanice neodpovídá

Vyšle-li master požadavek, potom s posledním vyslaným bytem rámce spouští časovačtime-out s periodou TSL. Nezačne-li do jeho vypršení přicházet odpověď, potom master po-žadavek opakuje. Počet opakování je určen parametrem sběrnice retry ctr. Neodpovídá-listanice ani na opakované pokusy, je označena jako neaktivní.

14


Chyba při příjmu odpovědi na dotaz

Povinností každé stanice na sběrnici je udržovat v paměti rámec odpovědi na poslednípožadavek ze sběrnice. Dojde-li totiž ke ztrátě nebo poškození této odpovědi, potom jestanicí master požadavek vyslán opakovaně. To, že se jedná o opakovaný požadavek sepozná podle nezměněného bitu FCB, který je součástí řídícího znaku rámce (FC - FrameControl). Tento bit je s každým novým požadavkem invertován. Dojde-li tedy požadavekse stejným FCB jako měl požadavek předchozí, opakuje stanice poslední odpověď.

Duplicita adres na sběrnici

Detekuje-li stanice odposlechem provozu na sběrnici rámce vyslané od stanice se stejnouadresou, potom po přijetí dvou takových rámců přechází do stavu „Offlineÿ a signalizujechybu na sběrnici.

15

Kapitola 3Realizace fyzické vrstvy

Při psaní ProfiMu bylo dbáno na důsledné oddělení hardwarově závislých částí programu odtěch, které mohou být hardwarově nezávislé. To umožňuje ovladači pracovat nad různýmirealizacemi fyzické vrstvy Profibusu, neboli různými způsoby jak k PC připojit Profibus.Tyto realizace se mohou lišit podle složitosti, nákladnosti a maximální dosažitelné přeno-sové rychlosti.

Nejjednodušší možností připojení s minimálními náklady je použití standardního séri-ového portu PC s jednoduchým převodníkem RS 232/485 bez externího napájení. To námumožní plnohodnotné připojení na Profibus pro přenosové rychlosti 9600bps a 19200bps.Vyšších rychlostí na standardním sériovém portu nelze dosáhnout z důvodů uvedenýchv části 3.2.

Jinou možností je použít rozšiřující zásuvné PCI karty s obvodem UART (UniversalAsynchronous Receiver/Transmitter), což umožňuje posunout rychlostní limit mnohemdále a s vhodným typem obvodu a dostatečně výkonným procesorem lze dosáhnout i mo-mentálně maximální přenosové rychlosti Profibusu 12Mbps.

3.1 Použití standardního sériového portu

K připojení Profibusu na sériový port PC je potřeba použít převodník RS 232/485. Profi-bus totiž pracuje na standardu RS–485 a sériový port PC na RS–232. Rozdíl mezi těmitostandardy je především v napěťových úrovních, které používají k reprezentaci logickýchhodnot. Druhým důležitým rozdílem je také to, že standard RS–485 umožňuje propojenívíce než dvou zařízení po jednom vedení. Více zařízení je připojeno tak, že v jeden oka-mžik vysílá jenom jeden a ostatní pouze přijímají, proto zařízení, která chtějí po RS–485komunikovat mívají přepínání směru toku dat.

Možné schéma převodníku je na obrázku 3.1. Jedná se o jednoduchý převodník posta-vený na obvodu 75176, který ke své činnosti nepotřebuje externí napájení. Napájen je přímo

16


ze sériového portu nastavením výstupu DTR na logickou jedničku. Tím se zjednodušujepoužití převodníku, avšak je tím také omezeno celkové maximální zatížení budiče sběr-nice. To nám omezuje maximální počet připojitelných zařízení, délku vedení a neumožňujepoužití ukončovacích odporů vedení sběrnice nutných pro vyšší přenosové rychlosti.

13251224112310229218207196185174163152141

CN1

CANON-25

V+

D1 D2 D3

C1

10uGND

VCCCN2

D/R 7

D/R 6R-O 1R-E 2D-E 3D-I 4

U1

R447K

R547K

R1 10K

R2 10K

R6 1K2 TxD 8 RxD/TxD-N

3 RxD/TxD-P

>

3 RxD <

4 RTS >

5 CTS <

6 DSR <

7 DGND

5 DGND

20 DTR >D6D5D4

GNDR310K

GND

D7DZ

D8DZ

GNDGND

GND

VCC

C3100n

GND

V+

I 1GND2

O 3

IO178L05

C210u

V-

GND

75176

CANON-9

9

8

7

65

4

3

2

1

RS-4

85

RS-2

32

GND

Obrázek 3.1: Jednoduchý interface RS–232/RS–485

Potřebujeme-li převodník s lepšími vlastnostmi nezbyde, než použít převodník s ex-terním napájením. Ten kromě výkonového budiče linky může také nabídnout galvanickéoddělení, které je vzhledem k obvyklému nasazení standardu RS–485 v průmyslu častopoužívané.

Nezbytnou součásti převodníku je přepínání směru toku dat. K tomu slouží signál RTS.Pro RTS=0 jsou výstupy budiče linky ve stavu vysoké impedance a převodník je takpřepnut na příjem, pro RTS=1 jsou budiče sběrnice aktivovány a převodník může vysílat.

Na tomto místě se hodí poznamenat, že existují převodníky s automatickým přepíná-ním směru. Princip jejich činnosti spočívá v použití monostabilního klopného obvodu prořízení směru toku dat. Tento klopný obvod přepíná na vysílání s příchodem sestupné hranystart bitu na začátku každého vysílaného znaku. Perioda klopného obvodu je nastavenana délku jednoho znaku, což znamená, že pro každou přenosovou rychlost je potřeba tutodélku periody změnit. K využití pro komunikaci na Profibusu jej však v našem případěpoužít nemůžeme, protože potřebujeme pomocí převodníku zajišťovat navíc ještě časování,k čemuž je potřeba softwarové ovládání směru toku dat (bude popsáno v části 5.3).

Další vlastností tohoto zapojení převodníku je hardwarový loopback. Je-li převodníkpřepnut na vysílání (RTS=1), potom vše co je vysláno do vstupu převodníku signálemTxD se vnitřní smyčkou vrací do RxD. Jinými slovy, vše co ze sériového portu PC přes

17


převodník vyšleme se také ihned na vstup sériového portu vrátí. Tuto vlastnost lze využítpro přepínání směru toku dat.

Důležitou částí převodníku, která je ProfiMem také využívána, je propojení mezi vý-stupem TxD a vstupem DSR. Použijeme-li s ProfiMem jiný převodník než takový jako jena obrázku 3.1, je potřeba, aby měl tuto propojku a hardwarový loop-back pro vysílanádata.

Velkou potíží při připojování sběrnice používající standard RS–485 přes převodníkRS 232/485 na většinu obvodů UART s RS–232 je nemožnost generovat přerušení od prázd-ného výstupního posuvného registru (obrázek 3.2). Chceme-li totiž použít převodníkRS 232/485, potřebujeme softwarově řídit směr přenosu dat. To znamená před každýmvysíláním přepnout směr převodníku na vysílání a po vyslání posledního bitu posledníhoznaku přepnout zpět na příjem. Přepnutí směru na vysílání není problém, to lze provéstpřed vysláním prvního bytu vysílaných dat, avšak přepnutí nazpátek již tak jednoduchénení a to právě díky tomu, že většina standardních UART obvodů (tabulka 3.2) nenabízípřerušení od prázdného výstupního posuvného registru.

š

Vysílací registr

Výstupní posuvný registr

Prerušení od prázdného vysílacího registru

š Prerušení od prázdného výstupního posuvného registru(u standardního sériového portu na PC chybí)

Znaky k vyslání TxD

Obrázek 3.2: Přerušení vysílače UARTu

Jediné přerušení, které u takovýchto obvodů můžeme při vysílání dostat pouze říká, žeje prázdný vysílací registr, který tak můžeme znovu naplnit, avšak výstupní posuvnýregistr ještě prázdný není a teprve dokončuje vysouvání znaku, což znamená, že znakještě nebyl z UARTu úplně vyslán. Přepneme-li tedy směr po příchodu takového přerušení,dojde k chybě na sběrnici, neboť směr vysílání je změněn uprostřed vysílaného znaku a takje na sběrnici vyslána pouze jeho část.

Jediný způsob jak u těchto obvodů zjistit úplné vyslání znaků je přečtení Link StatusRegistru (LSR), který obsahuje bit indikující prázdný výstupní posuvný registr. Avšakjelikož od tohoto bitu nemůžeme generovat přerušení, je potom nutné k čekání použítnekonečné smyčky, což není dobrý způsob pro programy v systémech řízených událostmijako jsou Windows a úplně nepřijatelný způsob pokud píšeme ovladač a potřebujeme toto

18


PC RS–232 . . . 9600 19200 38400 57600 111520Profibus 9600 19200 45450 93750 187500 . . .

Tabulka 3.1: Porovnání přenosových rychlostí RS–232 v PC a Profibusu (hodnoty jsouv bps)

čekání provádět v rutině obsluhy přerušení (ISR) nebo DPC rutině (viz. kapitola 4). Tentoproblém se však podařilo vyřešit a jeho řešení bude popsáno v kapitole 5.

3.2 Použití rozšiřujících zásuvných karet

Pokud srovnáme přípustné přenosové rychlosti, které nabízí standardní RS–232 na PCs možnými přenosovými rychlostmi Profibusu, zjistíme, že do tolerance požadované Profi-busem 0,3% se vejdeme pouze pro rychlosti 9600bps a 19200bps (tabulka 3.1). Pro dosa-žení vyšších rychlostí nám tak nezbývá než použít zásuvných karet s obvody UART, kterémají vyšší frekvence základní hodinové frekvence s dobrými možnostmi jejího dělení. Tynám umožní nejen dosahovat potřebných rychlostí přenosu (při použití vhodného krys-talu základní hodinové frekvence), ale také přinášejí nové možnosti oproti obvodům UARTstandardně používaných v PC (tabulka 3.2), které jsou kompatibilní s obvodem 16C450.

Některé novější obvody UART nabízejí možnost generovat přerušení i od vyprázdněnívýstupního posuvného registru. Pokud bychom tuto možnost měli, zjednodušila by se námtím programová obsluha přístupu na sběrnici a také by se zjednodušil způsob jakým jesériový port využíván k časování. V tabulce 3.2 jsou uvedeny některé novější obvody UARTspolu se základními vlstnostmi. Je vidět, že obvodem, který takové přerušení nabízí, je16C950. Navíc nové obvody nabízejí velkou vyrovnávací FIFO paměť, což umožňuje snížitzátěž procesoru při vysokých přenosových rychlostech.

Jako další možnost hardwarového řešení proto byla vybrána karta pro PCI sběrniciPCI-1482 od firmy Tedia [10], ta je postavena na obvodu OX16PCI954, který je s 16C950kompatibilní. Stejně tak je možné použít od této firmy libovolnou kartu z řady PCI-14xxnebo PCI-16xx. Porty na kartě je potřeba pomocí přepínačů přepnout do režimu „RS–485ÿa pomocí propojky nastavit režim „High Speedÿ. Dále je potřeba použít jednoduchouredukci (obrázek 3.3), neboť výstupní konektor karty má jiné rozložení signálů než konektorProfibusu.

Použijeme-li jinou kartu s obvodem UART, potom nejlepší je taková, která je postavenataké na obvodu kompatibilním s 16C950. Je-li použita karta s obvodem nižšího typu 450 až750 je potřeba, aby měla alespoň možnost datového loop-backu a propojení mezi výstupemTxD a vstupem DSR (důvody viz. část 5.3). Programová obsluha takové karty by pak bylatéměř stejná, jako při použití převodníku RS 232/485.

19


CN2

CANON-9

9

8

7

65

4

3

2

1

Pro

fibu

s

CN1

PCI-14xx

9

8

7

65

4

3

2

1

Ted

ia R

S-48

5

RxD/TxD-N Rx/Tx+

Rx/Tx-

RxD/TxD-P

DGND

DGNDCN2

CANON-9

9

8

7

65

4

3

2

1

Pro

fibu

s

CN1

PCI-16xx

9

8

7

65

4

3

2

1

Ted

ia R

S-48

5

RxD/TxD-N Rx/Tx+

Rx/Tx-

RxD/TxD-P

DGNDDGND

Obrázek 3.3: Redukce pro připojení karet Tedia na Profibus

Typ UART obvoduVelikost FIFO

pamětiPřerušení od prázdného

posuvného vysílacího registru

450 1B Ne550 16B Ne650 128B Ne750 128B Ne950 128B Ano

Tabulka 3.2: Vlastnosti UART obvodů

3.2.1 Obvod OX16PCI954

Obvod vyráběný firmou Oxford Semiconductor [9] určený pro použití na rozšiřujících zá-suvných kartách pro PCI sběrnici. Jedná se o složitý obvod, který kromě sériových kanálůnabízí i jiné funkce, jako paralelní port, podporu IrDA atd. Pro nás je důležité to, že tentoobvod integruje čtyři vysokorychlostní UART kanály, kde každý je kompatibilní s obvodem16C950 a má 128B FIFO paměti pro vysílač i přijímač.

Podle rychlosti použitého krystalu základní hodinové frekvence může být maximálnídosažitelná přenosová rychlost až 15Mbps pro asynchronní režim. Dobrou vlastností tohotoobvodu je možnost neceločíselného dělení hodinové frekvence, což lépe umožňuje současnědosáhnout několika netypických přenosových rychlostí pro jeden hodinový krystal.

Dále je tento obvod připraven pro připojení na sběrnici PCI a plně integruje podporuPlug and Play s možností načíst konfiguraci z paměti EEPROM. V neposlední řadě umož-ňuje přerušovat od prázdného vysílacího posuvného registru.

20

Kapitola 4Tvorba ovladačů pro operační systémWindows

Jelikož psaní ovladače představovalo podstatnou část této diplomové práce,ukážeme v této kapitole jak se v operačních systémech Windows vytvářejíovladače pro fyzická zařízení. Existují i jiné druhy ovladačů, avšak v této kapi-tole se budeme výhradně zabývat ovladači pro fyzická zařízení. Popíšeme jejichzákladní strukturu, ukážeme jaké nástroje jsou pro jejich tvorbu potřeba a jakse liší psaní ovladačů od psaní běžných programů.

Potřebujeme-li vytvořit ovladač pro operační systém Windows, narazíme z počátku nanedostatek informací, které by řešení tohoto problému zhruba popsaly, ukázaly jednoduchépříklady a nastínily postup. Součástí DDK (Driver Development Kit) od Microsoftu je sicevelmi dobrá dokumentace, ale ta je pro první přiblížení příliš detailní a nenabízí celkovýpohled na problematiku. Na druhou stranu s využitím Internetu najdeme mnoho návodůa popisů, které jsou však v naprosté většině příliš povrchní. Problém je totiž v tom, že proúvod do tvorby ovladačů neexistuje nic jako krátký obligátní program „Hello Worldÿ. Přitvorbě ovladačů se sice často vychází z ukázkových zdrojových kódů, které jsou součástíDDK, avšak i pro nejjednodušší použitelné případy mají počty řádek v řádu tisíců. Je todáno tím, že i nejjednodušší ovladač musí splňovat některé základní požadavky a musí mítrutiny, které systému umožňují s ovladačem komunikovat. Tím také vzniká potřeba dobréznalosti mechanismů činnosti operačního systému, jehož součást ovladač tvoří.

Chceme-li přímo přistupovat na hardware pod operačními systémy Windows, což je nášpřípad, nebo využívat nízkoúrovňových služeb systému, potom potřebujeme být v takzva-ném privilegovaném režimu. Programy ve Windows totiž pracují na dvou úrovních. Prvníz nich je neprivilegovaná úroveň neboli User mode (Ring 3). Ta je určena pro běžné apli-kace, které nejsou hardwarově závislé a vystačí si se službami poskytovanými přes API

21


(Application Interface) operačního systému. V této úrovni běží většina aplikací operačníhosystému a nejsou v ní povoleny privilegované instrukce procesoru, ke kterým patří napříkladinstrukce vstupu a výstupu in, out a instrukce halt. Omezení umožňují systému kontrolunad činností uživatelských programů, jejich vzájemné oddělení a zvyšují tak stabilitu aochranu operačního systému.

Druhá z úrovní je privilegovaná neboli Kernel mode (Ring 0), v té pracuje jádro ope-račního systému a jeho součásti (obrázek 4.1), ke kterým patří i ovladače. Kód spouš-těný na této úrovni již není omezen limity user módu, což mu umožňuje přímý přístupna hardware a kontrolu nad svým během. Zároveň však je tím zvýšeno nebezpečí chyb.Chyby v programu na úrovni kernel módu totiž obvykle vedou přímo k havárii systému.Tvorba ovladače proto vyžaduje velice důsledné a pečlivé psaní zdrojového kódu. Zacyklenív programu nebo deadlock v kritických částech kódu, jako například v obsluze přerušení,způsobují zastavení systému a například přístup do paměti, která nepatří ovladači způsobítéměř jisté zhroucení celého systému.

K e rn e l

E x e c u tiv e C o m p o n e n tsIO M a n a g e r

D e v ic eD r iv e rs

H a rd w a re A b s tra c t io n L a y e r (H A L )

H a rd w a re P la tfo rm

U s e r M o d eK e rn e l M o d e

Obrázek 4.1: Kernel Mode

Ke zvýšení těchto rizik ještě přispívá používání jazyka C, který je k tvorbě ovladačůpřevážně používán. Jeho silnou stránkou je práce s ukazateli, avšak díky velké benevolenciv této oblasti se může například stát, že díky chybě v programu dojde k použití neinici-alizovaného ukazatele odkazujícího na paměť nepatřící programu. Takovou chybu lze vevelkém projektu lehce udělat a navíc se nemusí projevovat pokaždé a tak je potřeba připsaní kódu vysoké obezřetnosti.

22


4.1 Nástroje potřebné pro vývoj ovladače

Ovladače je možné vyvíjet v libovolném jazyce, který k volání funkcí používá konvencijazyka C, avšak plnou podporu vývoje nalezneme pouze pro jazyk C (hlavičkové soubory,ukázky zdrojových kódů). Není dokonce ani zvykem pro psaní ovladačů používat jazykaC++, ale převážně jazyk C. Bylo by to sice možné, ale doporučením Microsoftu je používatjazyk C.

Pro psaní ovladačů se obvykle používá následující skupina nástrojů, která je kroměVisual Studia součástí „MSDN Professional Subscriptionÿ:

• Windows NT free build

• Windows NT checked build (není nutností)

• Software Development Kit (SDK)

• Windows NT Device Driver Kit (DDK)

• Visual Studio (VS nebo VC++)

Co znamená checked build a free build? S těmito pojmy se v oblasti ovladačů setkávámečasto. Jsou to dvě různé verze, do nichž lze přeložit ovladač nebo jakýkoliv jiný program.Checked build znamená, že program byl přeložen s přidáním ladících informací a rozšířenévnitřní kontroly chyb, což nám umožňuje snadnější vývoj, ale také snižuje rychlost a zvyšujepaměťové nároky. Oproti tomu free build je určena pro finální překlad s plnou optimalizací,kdy jsou ladící informace odděleny od kódu.

Balík DDK je určen pro tvorbu ovladačů, obsahuje hlavičkové soubory a statické knihov-ny, které jsou nezbytné pro jejich přeložení. Pro svou práci potřebuje SDK, ze kteréhovyužívá překladač a další nástroje.

4.2 Požadavky systému na ovladač

Při psaní ovladače je třeba dbát na to, aby splňoval určitá kritéria daná operačním sys-témem. Jejich splnění umožňuje systému dobrou flexibilitu a rychlou reakci na události.Těmito kritérii jsou:

Přepnutelnost a přerušitelnost kódu ovladače. Jelikož kód ovladače poběží pod pre-emptivním multitaskingovým operačním systémem, musí být odolný pro případ pře-pnutí nebo přerušení. To znamená, že dočasné přerušení běhu kódu nesmí způsobitjeho chybu. Je třeba počítat s tím, že přepnutí nebo přerušení může přijít kdykoliv atak je nutné zajistit, aby v takových případech nedošlo k deadlockům nebo problé-mům se sdílenými daty. Systém k tomu poskytuje širokou paletu nástrojů jako jsouspinlocky, kritické sekce atd.

23


Je třeba uvážit, že ačkoliv přerušení maskuje příchod jiných přerušení stejné úrovněpriority, jeho obsluha může být kdykoliv pozastavena příchodem přerušení s vyššíprioritou.

Konfigurovatelnost hardware a software. Ovladač by neměl být závislý na konkrét-ním nastavení hardware. Například napíšeme-li ovladač sériového portu, měl by býtschopen pracovat se všemi sériovými porty v počítači (COM1,COM2 atd.).

Paketování I/O operací. Všechny požadavky na ovladač přicházejí ve formě paketů,které se nazývají IRP (I/O Request Packet). Každý ovladač musí mít rozhraní, kteréumožňuje tyto pakety přijímat, zpracovávat a odpovědi opět odesílat ve formě IRP.Ovladač by měl být schopen pracovat s několika rozpracovanými požadavky najed-nou.

4.3 Rozdíl mezi Legacy a PnP ovladači

Legacy ovladač je pojmenování zavedené od Windows 2000 pro starý typ ovladačů, kterýnemá podporu PnP (Plug and Play). Chceme-li vytvořit plnohodnotný ovladač pro ope-rační systémy Windows 2000 a vyšší je potřeba, aby splňovaly požadavky WDM (WindowsDriver Model), ke kterým hlavně patří:

• Podpora Plug and Play - podpora PnP je nutná pro získání hardwarových prostředkůa neomezenou funkci ovladače v PnP operačním systému.

• Podpora pro Power Management - zařízení, pro které je ovladač psán Power Ma-nagement přímo hardwarově podporovat nemusí, ale ovladač by měl alespoň imple-mentovat jeho rozhraní pro operační systém. Jinak pokud například je v systémujeden ovladač bez Power Managementu, pak systém nemůže přejít do úspornéhorežimu.

Nesplňuje-li ovladač některou z těchto podmínek, potom z pohledu Windows 2000 sejedná o tzv. Legacy driver, tedy ovladač starého typu, který v rámci kompatibilty s Win-dows NT může být používán. Problém však může nastat při konfliktu mezi PnP a Legacyovladači. Například pokud chceme použít Legacy ovladač pracující se sériovým portem,potřebujeme ze systému odstranit standardní PnP sériový ovladač, což je téměř nemožné.Navíc mohou nastat problémy s tím, že PnP manager nepřipojí rozsah portů potřebný prolegacy ovladač a tak je nakonec jednodušší podporu PnP do ovladače přidat.

24


4.3.1 Plug and Play

Požadavky na ovladač podporující PnP:

PnP ovladač nesmí zabírat hardwarové prostředky přímo. Místo toho ovladač se-staví seznam prostředků, které potřebuje a pošle jej PnP Manageru. Mezi prosředky,o které ovladač žádá, patří: čísla požadavků přerušení IRQ, rozsahy I/O portů, DMAkanály a rozsahy paměťově mapovaných přístupů na zařízení. Po shromáždění všechpožadavků na prostředky rozhodne PnP manager, jak je nejlépe rozdělit, aby všembylo pokud možno vyhověno, a které prostředky tak budou kterému ovladači přidě-leny. Tyto prostředky jsou pro ovladač PnP Managerem automaticky zabrány, o čemžje ovladač informován pomocí IRP zprávy IRP MN START DEVICE. Teprve až pří-chodem této zprávy může ovladač začít přistupovat na hardware a to výhradně pouzeza použití přidělených prostředků.

PnP ovladač musí pracovat podle PnP Manageru. PnP Manager spravuje zařízenív systému jako celek a vyzývá ovladač k obsluze jeho jednotlivých zařízení. PnP ovla-dač, například, nesmí při svém nahrání (DriverEntry) vyhledávat svoje zařízení, alemísto toho musí být navržen tak, aby při nalezení zařízení pro ovladač byla systémemvolána funkce AddDevice. PnP Manager volá funkci AddDevice pro každé nalezenézařízení, které je ovladač schopen obsluhovat. Zařízení je ovladačem obsluhováno,dokud PnP Manager nezastaví jeho činnost.

PnP ovladač by měl být maximálně flexibilní. Může-li zařízení pracovat s různoukonfigurací hardwarových prostředků (například může používat různá přerušení IRQnebo různé rozsahy I/O portů) měl by ovladač poskytnout všechny možně kombinaceprostředků PnP Manageru, aby ten měl co nejlepší možnosti jak uspokojit všechnypožadavky na prostředky.

4.4 Způsob práce ovladače

Pokusme se nyní zhruba popsat činnost PnP ovladače ve Windows.Ovladač je spuštěn automaticky při startu systému nebo ručně z podnětu uživatele. Při

svém spuštění zaregistruje adresy několika důležitých rutin, které tak vytvoří interface mezioperačním systémem a ovladačem. Prostřednictvím volání těchto rutin operační systémkomunikuje s ovladačem. Dále přechází do stavu čekání.

PnP Manager podle informací uložených do registrů při instalaci ovladače ví, jakázařízení je schopen obsluhovat a jaké hardwarové prostředky potřebuje. Pokud je takovézařízení v počítači nalezeno, je o tom ovladač informován voláním rutiny AddDevice.

Pro každé obsluhované zařízení je v rutině AddDevice vytvořen objekt Device Object,který toto zařízení reprezentuje a umožňuje tak jednomu kódu ovladače obsluhovat více

25


zařízení. K zařízení ovšem ovladač ještě nemá přiděleny hardwarové prostředky a tak opětpřechází do stavu čekání.

Přístup na hardware je umožněn až poté, co ovladači přijde od systému zpráva typuIRP MN START DEVICE. Poté si ovladač zjistí přidělené prostředky a inicializuje hard-ware. Od tohoto okamžiku může začít plnit požadavky na I/O operace.

A p p lic a t io n s

W in 3 2S u b s y s te m

W in 3 2 A P I c a lls

D e v ic ed r iv e r

I/O M a n a g e r

S y s te m S e rv ic e In te r fa c e

H a rd w a re A b s tra c t io n L a y e r

H a rd w a re

U s e r M o d e

K e rn e l M o d e

H A L c a lls

P la tfo rm s p e c if ic o p e ra tio n s

IR P p a s s e d to d r iv e r d is p a tc h ro u tin e

Obrázek 4.2: Zpracování IRP

Pokud chce aplikace poslat ovladači nějaký požadavek, musí nejprve k němu otevřít sou-borový handle, pomocí příkazu CreateFile s registrovaným jménem, tvořící identifikátorovladače, jako například "\\.\ProfiM". Přes tento handle pak posílá ovladači požadavky.Ty se přes API rozhraní dostanou k I/O Manageru (obrázek 4.2). Ten z nich vytváří paketyIRP, které posílá ovladači. Ten požadavky začne zpracovávat a po tuto dobu IRP drží. Povyřízení požadavku je IRP označen jako hotový a je do něj uložen výsledek. I/O managerpotom výsledek posílá zpět aplikaci. Používání IRP paketů zjednodušuje ovladači prácis požadavky, neboť jejich správa je zajištěna I/O managerem.

I/O operace prováděné s fyzickým zařízením jsou vykonávány přes HAL (HardwareAbstraction Layer), který tvoří abstraktní vrstvu skrývající implementační detaily každékonkrétní hardwarové platformy.

26


4.5 Prioritní úrovně (IRQL)

Velmi důležitou vlastností pro všechny rutiny ovladače je prioritní úroveň, na které jsouspouštěny. Na rozdíl od běžných programů v user módu jsou jednotlivé rutiny ovladačespouštěny na různých prioritních úrovních (IRQL - Interrupt request level). To na jakéúrovní rutina běží je podstatné, protože určuje jaké funkce jádra může volat. Pro vyššíúrovně priority tak například nelze volat některé funkce pro alokaci paměti, synchronizačnífunkce (KeWaitForSingleObject,. . . ) nebo třeba funkce pro přístup do registrů. Omezeníjsou dána přibližně tak, aby rutiny spouštěné s vyšší prioritní úrovní nepoužívaly funkcepotřebující stránkovanou pamět (důvod v části 4.8) nebo takové, které jsou časově náročné.To odpovídá požadavku systému na co nejrychlejší proběhnutí rutin se zvýšenou prioritou.

Úroveň, na které může být funkce volána se tak stává nedílnou vlastností všech funkcíjádra, které ovladač může volat a je potřeba jí vzít v úvahu při každém použití. Tuto úroveňlze najít v dokumentaci [12].

Úroveň, na které rutina poběží, je pro každou standardní rutinu ovladače určena sys-témem nebo hardwarovou úrovní (DIRQL), na které fyzické zařízení přerušuje (tabulka4.1).

IRQL Masková přerušení Standardní rutiny běžící na tétoúrovni

PASSIVE LEVEL žádná DriverEntry, Unload, AddDe-vice, Dispatch rutiny a ovlada-čem vytvořená vlákna.

DISPATCH LEVEL Maskuje přerušení s úrovníDISPATCH LEVEL. Pře-rušení od fyzických zařízenívšak mohou nastat.

DpcForIsr, CustomTimerDpc,CustomDPC, IoTimer, Cancel,StartIo routiny.

DIRQL Všechna přerušenís IRQL≤DIRQL. Můženastat přerušení s vyššíprioritou.

ISR a SyncCritSection

Tabulka 4.1: Prioritní úrovně

4.6 Základní struktura a rutiny Legacy ovladače

Nejprve popíšeme strukturu Legacy ovladače a v další části ukážeme její rozšíření pro pod-poru PnP. Legacy ovladač je v nejjednodušší podobě tvořen několika základními rutinami(obrázek 4.3). Ty na jedné straně spolupracují s I/O Managerem, přes který probíhá veš-

27


kerá komunikace mezi ovladačem a aplikacemi, a na druhé straně přistupuje ovladač naobsluhovaný hardware.

In te r ru p t

I /OM a n a g e r

D riv e rE n try

U n lo a d

D is p a tc h R o u tin e

C re a te R o u tin e

R e a d R o u tin e

W rite R o u tin e

IO C o n tro lR o u tin e

C lo s e R o u tin e

D e fe rre d P ro c e d u re C a ll (D P C )

In te r ru p t S e rv ic e R o u tin e ( IS R )

H W

D riv e r

Obrázek 4.3: Struktura Legacy ovladače

4.6.1 DriverEntry

Základní rutina každého ovladače. I/O Manager volá DriverEntry ihned po náhrání ovla-dače a jeho spuštění. Jako parametr předává ukazatel na objekt Driver Object, kterým I/OManager reprezentuje instanci ovladače. DriverEntry nastavuje ukazatele na standardní aDispatch rutiny, reprezentující vstupní body obslužných funkcí pro ovladač, které umožňujíspolupráci I/O Manageru s ovladačem:

DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateRoutine;

DriverObject->MajorFunction[IRP_MJ_CLOSE] = CloseRoutine;

DriverObject->MajorFunction[IRP_MJ_READ] = ReadRoutine;

DriverObject->MajorFunction[IRP_MJ_WRITE] = WriteRoutine;

DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IOControlRoutine;

DriverObject->DriverUnload = UnloadDriver;

28


Každá obsluha může mít svoji samostatnou funkci, ale bývá zvykem vytvořit jednu Dispatchrutinu, která obsluhuje všechny požadavky (typ požadavku je předáván jako jeden z para-metrů I/O Managerem).

Dále v DriverEntry ovladač alokuje a inicializuje potřebné paměťové struktury pro svojičinnost (viz. 4.8). Zvláštností je obvyklá potřeba ovladače získat prostor v tzv. nonpagedpaměti, neboli takové paměti, která není systémem stránkována, tudíž není nikdy uloženana disk. To je nutné především pro rychlý přístup do paměti ve stavech se zvýšenou pri-oritou (IRQL), kdy přístup k datům uloženým v části paměti, která byla vystránkovaná,by zdržoval anebo nebyl vůbec možný (např. v obslužné rutině přerušení - ISR).

V DriverEntry obvykle také ovladač zjišťuje svoji konfiguraci ukládanou do registrů(viz. 4.9). Cestu k nim může získat dvěma způsoby. Buď mohou být uložené na místěurčeném jedním z parametrů, se kterým I/O Manager volá DriverEntry nebo na místěurčeném z Driver Objectu podle položky DriverObject→HardwareDatabase.

Narozdíl od PnP ovladače provádí Legacy ovladač inicializaci hardwaru zařízení jižv DriverEntry. Před prvním přímým přístupem na zařízení však také musí hardwarovéprostředky od systému získat. To znamená získat I/O porty, rozsahy paměti s namapova-nými registry zařízení nebo přerušení, přes které bude na zařízení přímo přistupovat. Jejichspráva je ve Windows NT 4.0 prováděna přes záznamy v registrech, které jsou umístěnyv části \Registry\Machine\Hardware\ ResourceMap. Pro jejich získání volá ovladač funkceIoAssignResources, IoReportResourceUsage a HalAssignSlotResources. Jestliže při žádánío prostředky nenastane žádný konflikt, jsou požadavky ovladače přidány do registrů. Tentomechanismus zabraňuje ovladačům, aby převzaly již zabrané prostředky jiných ovladačů azpůsobily tak konflikt na zařízení, které již jiný ovladač inicializoval.

Po získání prostředků uvádí ovladač svoje zařízení do počátečního stavu a obvykle jejpřipraví pro generování přerušení. Aby přerušení mohl zpracovávat, potřebuje ještě pomocífunkce IoConnectInterrupt zaregistrovat obslužnou rutinu přerušení (ISR).

4.6.2 Unload

Ovladač, který může být odstraněn za běhu systému, musí mít Unload rutinu. Ta je zodpo-vědná za uvolnění všech systémových objektů a prostředků, které ovladač zabral pro svoučinnost. Teprve potom může být ovladač odstraněn. Deaktivace ovladače může způsobitzávažnou chybu pokud je použita nevhodná sekvence rušení. Například na začátku rutinyUnload je smazán nějaký objekt, potom ještě před deaktivací přerušení je vyvolána ISRa v té je smazaný objekt použit, což způsobí kritickou chybu systému. Je proto vhodnépostupovat podle následujícího postupu:

1. Deaktivovat všechny zdroje přerušení na fyzických zařízeních. Následně od nich od-pojit obsluhu přerušení voláním funkce IoDisconnectInterupt.

29


2. Zajistit, že žádná jiná rutina ovladače nebude nadále používat prostředky, kteréchceme uvolnit - například zavoláním IoStopTimer deaktivujeme volání IoTimer ru-tiny ovladače atd.

3. Uvolnit systémové objekty a prostředky, které byly zabrány při inicializaci ovladačenebo v průběhu jeho činnosti.

4.6.3 Interrupt Service Routine (ISR)

Jedna z nejdůležitějších rutin ovladače fyzického zařízení. ISR je obslužná rutina, která jevyvolána pokud zařízení, které ovladač obsluhuje generuje žádost o přerušení (IRQ). Jevolána v režimu zvýšené priority (IRQL=DIRQL, tj. úroveň specifikovaná jako parametrpři volání IoConnectInterrupt) a tak svým během maskuje přerušení stejné a nižší prioritníúrovně. To klade vysoké nároky na rychlost zpracování přerušení. ISR by měla proběhnoutco nejrychleji, aby systém nepřicházel o vymaskovaná přerušení. Obvykle tak ISR pouzepřečte stav zařízení spolu s nejdůležitějsími daty, donutí zařízení ukončit generování pře-rušení a požádá o DPC neboli Deferred Procedure Call, což je funkce, která je jádremsystému později vyvolána a již ve snížené úrovni priority (IRQL=DISPATCH LEVEL)dokončí obsluhu přerušení.

Důvodem pro použití DPC rutiny je také to, že některé funkce nemohou být volányv režimu zvýšené priority, ve které běží ISR a tak mohou být provedeny až v DPC.

Jako příklad můžeme uvést příjem dat sériovým kanálem s pamětí FIFO. Naplní-lise FIFO paměť až po určitou mez, vygeneruje sériový kanál přerušení indikující příchoddat. Tím je vyvolána ISR, která data z FIFO paměti nevyčte rovnou, ale pouze si uložíidentifikátor typu přerušení, požádá o DPC a rychle vrátí řízení. Vzápětí systém vyvoláDPC rutinu (běžící již s nižší prioritní úrovní IRQL=DISPATCH LEVEL), která dokončíobsluhu přerušení tím, že vyčte z FIFO paměti přijatá data. DPC již běží v nižší úrovnipriority a tak může data zpracovat a případně předat do aplikační vrstvy.

Problémem při použití DPC jako rutiny dokončující obsluhu přerušení po proběhnutíISR, je možné dlouhé časové zpoždění mezi voláním ISR a DPC. Tudíž se v některýchčasově náročných případech nevyhneme nutnosti provést celou obsluhu přerušení v ISR.

4.6.4 Deferred Procedure Call (DPC)

Deferred Procedure Call neboli odložené volání procedury - význam této funkce pro použitís rutinou obsluhy přerušení (ISR) byl popsán v předchozím odstavci. DPC určená prodokončení zpracování obsluhy přerušení bývají také nazývána DpcForIsr.

30


4.6.5 IoTimer

Potřebuje-li ovladač funkci, která by byla volána v pravidelných intervalech, pak mu systémnabízí rutiny IoTimeru. Nejmenší časový interval s jakým může být volána je kolem 10ms

a obvykle se používá ke zjištění time-outu I/O operací na zařízení nebo pro pravidelnoukontrolu činnosti ovladače (Watchdog).

Při použití standardní rutiny IoTimeru je systémem zaručeno její pravidelné volánív intervalech přibližně jedné sekundy. Pro spuštění periodického volání rutiny IoTimer sepoužije funkce IoInitializeTimer. Tato funkce není nic jiného než DPC rutina vyvolávanápo přerušení od systémového časovače.

4.6.6 Dispatch Routine

Má-li I/O Manager připravený pro ovladač požadavek ve formě IRP paketu, potom volázaregistrovanou Dispatch rutinu. Ta jej přebírá a začíná jeho zpracování. O jaký požada-vek se jedná je určeno hlavním funkčním kódem IRP paketu (IRP MJ xxx). Pro každýhlavní funkční kód může být zaregistrována jedna dispatch rutina. Častokrát ale místo ně-kolika oddělených rutin má ovladač rutinu jen jednu, která IRP zpracovává podle hlavníhofunkčního kódu.

Obecně ovladače zpracovávají následující požadavky, které jsou definovány těmito hlav-ními funkčními kódy:

IRP MJ CREATE znamená požadavek aplikace z user módu na vytvoření souborovéhohandle, které bude představovat komunikační kanál asociovaný s ovladačem.

IRP MJ CLOSE indikuje, že aplikace uzavírá komunikaci s ovladačem.

IRP MJ READ znamená I/O požadavek na přenos dat z fyzického zařízení do systému.

IRP MJ WRITE znamená I/O požadavek na přenos dat ze systému do fyzického zaří-zení. V IRP objektu je ukazatel na buffer, který aplikace poskytla pro požadovanádata.

IRP MJ DEVICE CONTROL indikuje požadavek na ovladač, aby vykonal určitouoperaci se zařízením. Ta je určena pomocným kódem IRP MN xxx. Jejich významyjsou buď definovány systémem nebo to mohou být vlastní kódy definované konkrétněpro daný ovladač a zařízení.

4.7 Struktura ovladače s podporou PnP

Chceme-li, aby náš ovladač měl zahrnutou PnP podporu, potom do něj musíme přidatněkolik dalších rutin (obrázek 4.4). Kromě toho se také změní význam několika rutin stan-

31


dardních a to především kvůli jinému způsobu práce s hardwarovými prostředky.

In te r ru p t

I /OM a n a g e r

D riv e rE n try

U n lo a d

A d d D e v ic e

D is p a tc h P n P

S T A R T _ D E V IC E

…

D is p a tc h R o u tin e

C re a te R o u tin e

R e a d R o u tin e

W rite R o u tin e

IO C o n tro lR o u tin e

C lo s e R o u tin e

P n PM a n a g e r

D e fe rre d P ro c e d u re C a ll (D P C )

In te r ru p t S e rv ic e R o u tin e ( IS R )

H W

P o d p o ra P n P

D r iv e r

Obrázek 4.4: Struktura PnP ovladače

4.7.1 DriverEntry

Přidáme-li podporu PnP, pak je rutina DriverEntry zodpovědná pouze za inicializaci ovla-dače, což kromě definování vstupních bodů obslužných rutin také například znamená inicia-lizaci datových struktur společných pro všechna zařízení podporovaná ovladačem. Samotnáinicializace hardware se však přesouvá jinam. O nalezeném zařízení je ovladač informovánvoláním rutiny AddDevice, ale ani v té na hardware ještě nepřistupuje.

DriverEntry je volána pouze pro první výskyt zařízení podporovaného ovladačem. Jsou-li například v počítači dvě rozšiřující karty, které ovladač podporuje, je při nalezení prvníz nich PnP Managerem nahrán ovladač, volána DriverEntry a dále AddDevice. Při nalezenídruhé karty je již ovladač inicializován a tak přidávání karty začíná až od AddDevice.Pro rutinu AddDevice definuje DriverEntry pro I/O Manager ukazatel na vstupní bod:

DriverObject->DriverExtension->AddDevice = DDAddDevice;

32


a také přidává ukazatele na oblužné funkce pro PnP, Power Management a System Control:

DriverObj->MajorFunction[IRP_MJ_PNP] = DispatchPnp;

DriverObj->MajorFunction[IRP_MJ_POWER] = DispatchPower;

DriverObj->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = DispatchSystemControl;

4.7.2 AddDevice

Rutina nezbytná pro každý ovladač s podporou PnP. Jak již bylo uvedeno, je volána při na-lezení zařízení, které ovladač podporuje. Při vyvolání vytváří Device Object reprezentujícítoto fyzické, logické nebo virtuální zařízení. Všechny informace o ovladačem vytvořenýchDevice Object uchovává I/O Manager v příslušném Driver Objectu, který reprezentujeinstanci ovladače. AddDevice tedy pouze provádí přípravu před inicializací nalezeného za-řízení.

4.7.3 DispatchPnP

Dispatch rutina přijímající IRP pakety s hlavním funkčním kódem IRP MJ PNP, kteréjsou ovladači posílány PnP Managerem. Požadavky se týkají stavu PnP zařízení. Nejdůle-žitějším je IRP paket s vedlejším funkčním kódem IRP MN START DEVICE. Spolu s nímzískává ovladač hardwarové prostředky a může začít komunikovat se zařízením.

4.7.4 Interrupt Service Routine (ISR)

S přídáním PnP podpory nabývá na důležitosti návratová hodnota ISR rutiny. Ta systémuzpětně říká, jestli přerušení bylo pro nás a jestli jsme jej obsloužili. V systémech s PnP totižmůže nastat takový případ, že vektor přerušení je sdílen více fyzickými zařízení. Nutnýmpožadavkem na ISR rutinu potom je, aby ihned po svém vyvolání zjistila, jestli přerušeníbylo generováno od zařízení, které obsluhuje (obvykle přečtením registru identifikace pře-rušení - například pro UART registr IIR). Není-li tomu tak, musí vrátit hodnotu FALSE,aby systém vyvolal další rutinu obsluhy přerušení. Nedodržení tohoto požadavku může véstk nefunkčnosti systému.

4.8 Používání paměti ovladačem

Systém Windows používá tzv. virtuální paměť. To mu umožňuje využívat více pamětiRAM než je skutečně fyzicky nainstalováno. Dosahuje toho tím, že paměť je rozdělenana menší části - stránky, které mohou být v případě potřeby odloženy do sekundárnípaměti, tvořené obvykle pevným diskem. Toto odkládání neboli stránkování je obvyklé pro

33


programy a data v user módu. Pro programy v kernel módu je potřeba některé části pamětipřed stránkováním chránit.

Konkrétně například v rutině obsluhy přerušení nemůžeme používat žádná data, kteránejsou chráněna proti stránkování. Pokud by tato data byla zrovna odložena na disk anastalo by přerušení, bylo by potřeba je z disku načíst zpět do paměti. To je ovšem časověnáročné a to si nemůžeme dovolit, jelikož obsluha přerušení běží v režimu zvýšené priority.

V těchto případech se pro data používá paměti alokované z tzv. nestránkované paměti(non-paged pool). Pro náš případ tj. psaní ovladače bývá zvykem, že většina globálníchproměnných a dat je uložená v jedné struktuře, která je jako tzv. „Device Extensionÿpřipojena k objektu, který reprezentuje konkrétní instanci ovládaného zařízení (DeviceObject). „Device Extensionÿ je nestránkované a vytváří se při volání IoCreateDevice

v rutině AddDevice. Ta se volá při přidávání fyzického zařízení a jejím parametrem jevelikost požadované nestránkované paměti pro „Device Extensionÿ.

Device Extension je přístupný ze všech rutin ovladače a tak tvoří základní oblast s pro-měnnými a daty. Pokud potřebujeme alokovat nestránkovanou pamět za běhu ovladače(vytváření front, bufferů atd.) můžeme k tomu použít funkci jádra ExAllocatePool s pa-rametrem PoolType nastaveným na hodnotu NonPagedPool. Ta se pokusí provést alokaci,ale je potřeba mít na paměti, že „non-paged poolÿ je omezeným zdrojem systému a takalokace může skončit neúspěchem.

4.9 Umístění konfigurace v registrech

Ve Windows NT 4.0 jsou informace v registrech týkající se ovladače vztaženy ke službě (Ser-vice), která je na ovladač registrována. Konfiguraci tak můžeme uložit do větve \Registry\Machine\System\CurrentControlSet\Services\DriverName. To je také cesta, kterou ovla-dač získá od systému jako parametr rutiny DriverEntry volané při spouštění ovladačesystémem.

Naproti tomu u PnP ovladače, konfigurace přísluší samotnému konkrétnímu zařízenía je uložena u záznamu zařízení v registrech. Cesta k nim může například pro sériovýport COM2 být \Registry\Machine\System\CurrentControlSet\Enum\ACPI\PNP0501\2\Device Parameters. Jak je vidět, tak umístění už není tak zřejmé a proto se pro přístupke konfiguraci ovladače používá systémová funkce IoOpenDeviceRegistryKey, která podledaného zařízení otevře správnou větev registrů.

4.10 Ladící prostředky

Součástí snad všech dnešních programátorských balíků (např. C++ Builder) jsou výkonnéladící nástroje. Ty dovolují sledovat běh programu, odchytávat chyby, krokovat program,

34


přidávat ladící body apod. Programátor, který je na tyto nástroje zvyklý, bude jejichekvivalent při psaní ovladačů jen těžko hledat, obzvláště pokud píše ovladač pro fyzickézařízení a ne například ovladač k souborovému systému disku.

Důvodů je hned několik. Za prvé ovladače běží ve zvláštním režimu jako součást jádrasystému. Chyby na této úrovni v naprosté většině způsobují havárii systému. Navíc většinaovladačů je svázána s fyzickým zařízením, jehož obsluha musí probíhat takřka v reálnémčase, což téměř znemožňuje pozastavení běhu programu pro ladící účely. Další potíž způso-buje fakt, že rutiny ovladače (obsluha přerušení, dispatch rutinty, DPC rutiny atd.) mohoubýt prováděny současně a ještě k tomu na různých prioritních úrovních.

Součástí DDK je ladící program WinDbg od Microsoftu, který je však hodně těžkopádnýa navíc k ladění ovladačů vyžaduje dva počítače propojené sériovou linkou. Lepším řešenímje ladící nástroj SoftICE od firmy Compuware. Ten umožňuje ladit ovladače na jednompočítači a jeho možnosti jsou širší.

Přes různé složité ladící programy je nejpoužívanější způsob kontroly činnosti ovla-dače vypisování textových řetězců přímo z programu pomocí funkce DbgPrint (ntddk.h),například:

DbgPrint ( "ProfiM : Pridelene prostredky Port=0x%x Irq=%d",

DeviceExtension ->Port , DeviceExtension ->Irq );

Toto volání způsobí vypsání řetězce na standardní ladící výstup. Ten může být zobra-zován pomocí volně šiřitelného programu Debug View od firmy Sysinternals, který je napřiloženém CD.

4.11 INF File

Nezbytnou součástí ovladače pro operační systémy Windows 2000/XP je tzv. INF file, cožje textový soubor, který obsahuje všechny nezbytné informace pro instalaci ovladače dosystému. Je v něm uvedeno, které soubory jsou součástí ovladače a kam se mají překopí-rovat, jaká zařízení ovladač podporuje, informace pro zápis nastavení do registrů a mnohodalších informací.

Struktura souboru INF pro ovladač je dosti složitá a komplexní a tak se vyplatí proprvní verzi použít nástroje geninf.exe, který je součástí DDK. Ten po vyplnění několikadialogových oken se základními údaji o ovladači vygeneruje hrubou kostru, avšak ručníúpravě se stejně nevyhneme.

Důležitou informací pro operační systém, kterou INF file obsahuje, je seznam zařízení,které ovladač podporuje a se kterými může pracovat. Tato část může vypadat napříkladtakto:

35


[ControlFlags]

ExcludeFromSelect=PCI\VEN_1760&DEV_8004

ExcludeFromSelect=PCI\VEN_1760&DEV_8005

[Tedia]

%PCI\VEN_1760&DEV_8004.DeviceDesc% = PCI_950A, PCI\VEN_1760&DEV_8004

%PCI\VEN_1760&DEV_8005.DeviceDesc% = NoDrv, PCI\VEN_1760&DEV_8005

Operačnímu systému říká, že ovladač podporuje PCI zařízení s číslem výrobce 1760a číslem zařízení 8004 a 8005. Tato čísla jednoznačně identifikují každé zařízení pro PCIsběrnici a jsou výrobcům hardwaru přidělována mezinárodní organizací PCI–SIG.

4.12 Property Page

Máme-li vytvořený ovladač, téměř jistě také potřebujeme nějakým způsobem nastavovatjeho pracovní parametry. K tomu je nejlepší vytvořit takzvanou Property Page. Ta námumožňuje přidat několik stránek do okna vlastností zařízení (do něj se dostaneme přesSprávce zařízení otevřením okna vlastností pro konkrétní zařízení - obrázek 4.5).

Obrázek 4.5: Property Page

36


Jinou možností je napsat si vlastní aplikaci, která po svém spuštění umožní nastavováníparametrů. Property page má však oproti tomu několik výhod:

• Jeden ovladač může obsluhovat více zařízení - Property page je automaticky použí-vána pro každou instanci a její konkrétní parametry.

• Při otevírání Property page dostaneme od systému cestu do registrů k uloženýmparametrům zařízení.

• Není nutno hledat aplikaci pro nastavování parametrů. Property page je přímo pří-stupná ze Správce zařízení.

Property page je dynamická knihovna DLL, která má operačním systémem definovanýpřístupový bod:

BOOL APIENTRY PropertyPageProvider( LPVOID Info,

LPFNADDPROPSHEETPAGE AddFunc,

LPARAM Lparam )

Potřebuje-li systém zobrazit naší Property page, nahraje dynamickou knihovnu a volátuto funkci. Ta má za úkol vytvoření okna dialogu, které se přidá jako záložka do oknavlastností zařízení, dále načte parametry uložené v registrech a začne zpracovávat zprávyod systému, které jsou pro smyčku zpráv Property page oproti normálnímu oknu rozšířeny.

37

Kapitola 5Realizace linkové vrstvy - ProfiM

Chování linkové vrstvy je velmi dobře popsáno stavovým automatem, jak bylo ukázánov kapitole 2. Z toho také vychází i způsob jakým je možné linkovou vrstvu realizovat. Taje vytvořena jako softwarový stavový automat s deseti základními stavy (viz. část 2.2.3),který je po svém spuštění řízen následujícími událostmi:

• příjem požadavku z rozhraní FLD user (rozhraní pro vyšší vrstvy nebo přímý přístupna FDL)

• příjem znaku ze sběrnice (příjem celého rámce)

• událost od časovače (vypršení time-outu, například při čekání na odpověď nebo sle-dování aktivity na sběrnici)

Tyto události způsobují příslušnou odezvu a přechody mezi stavy. Ačkoliv je princip stavo-vého automatu velice jednoduchý, lze s ním realizovat i velmi složité a komplexni chování.

5.1 Programová implementace

V první fázi byl DP master vytvářen jako běžný program pro user mód. K přístupu nasériový port a jeho ovládání bylo použito standardních služeb operačního systému. Prv-ním zavažnějším problémem, který se objevil ihned v počátku, bylo ovládání převodníkuRS 232/485. Problémem bylo především přepínání směru toku dat, které způsobovalo ne-ustálé potíže.

K řízení převodníku, jak bylo popsáno v kapitole 3.1, nabízejí Windows zdánlivě naprvní pohled řešení. Pomocí služby SetCommState, nastavující parametry komunikačníhozařízení, lze aktivovat automatické přepínání směru signálem RTS (nastavením parametrufRtsControl na hodnotu RTS CONTROL TOGGLE). To by mělo zajistit přepnutí směru navysílání po zápisu dat na port a okamžité přepnutí na příjem po dokončení vysílání. Málo

38


dokumentovanou skutečností ovšem je, že toto přepínání má při zpětném přepínání napříjem velká zpoždění.

Není totiž implementováno hardwarově (obvody UART až po 16C950 tuto možnostnenabízejí), ale místo toho je k řízení směru použito funkce napojené na systémový časo-vač s dlouhou periodou. Ta je vyvolávána v intervalech přibližně 20ms a pokud zjistí, ževysílání skončilo, přepne na příjem. Časové zpoždění, které tak může vzniknout mezi vy-sláním posledního znaku rámce a přepnutí zpět na příjem je ovšem pro použití na Profibuspříliš dlouhé. Dotazovaná stanice na sběrnici totiž pak může začít vysílat odpověď na nášpožadavek ještě v době, kdy výstupy převodníku stále drží sběrnici, čímž vznikne kolize.

Ruční přepínání směru vysílání převodníku se také ukázalo jako téměř nemožné z dů-vodů popsaných v 3.1, navíc pro dosažení spolehlivé odezvy mastera a použití převodníkuk dosažení časování s velmi krátkými periodami se ukázal user mód jako nevhodný, díkyjeho malým možnostem pro aplikace reálného času. Proto byl DP master přepsán na ovla-dač pro běh v kernel módu. To také umožnilo později přidat podporu PCI zásuvných karets obvody UART jako alternativu připojení Profibusu na vysokých přenosových rychlostech.

S přechodem na ovladač však bylo potřeba přepsat celý zdrojový program z jazykaC++ na C. První verze byla totiž celá postavena s využitím objektově orientovanéhoprogramování, to ovšem jazyk C neumožňuje a tak bylo nutné objekty odstranit a vrátitse k neobjektovému přístupu.

Ovladač byl nejprve vytvořen pouze pro operační systém Windows NT 4.0, který u ovla-dačů nevyžaduje podporu PnP. Ta byla později přidána a tak je možné jej používat i prooperační systémy Windows 2000 a XP.

5.2 Nároky Profibusu

Pro umožnění práce s Profibusem potřebujeme obecně zajistit plnohodnotnou schopnostkomunikovat po sběrnici RS–485 a především mít možnost časování s krátkými periodami,což představuje velkou potíž, pokud takových period potřebujeme dosáhnout v systémuWindows. Pro představu délek těchto period, které potřebujeme dosáhnout si vezměmepříklad Profibusu běžícího na rychlosti 1,5Mbps. Všechny časové intervaly pro Profibus,jako délky time-outů, maximální zpoždění a nezbytné časové prodlevy, jsou udávány s jed-notkou tbit. Ta je definována jako interval daný délkou přenosu jednoho bitu po sběrnici,neboli převrácenou hodnotou přenosové rychlosti tbit = 1/(přenosová rychlost v bps). Prorychlost 1,5Mbps vychází tbit

.= 0, 67µs. Z praktického hlediska vzhledem k délkám ča-sovaných period stačí přesnost rozlišení asi desetkrát menší, takže pro rychlost 1,5Mbpspotřebujeme dosáhnout minimálních period asi 6µs, což je z pohledu user módu Windowsnedosažitelné. Tam je minimální dosažitelná perioda v řádech milisekund.

Jedinou užitečnou funkcí, kterou Windows nabízejí pro práci s krátkými časovými inter-

39


valy je Perfomance Counter. Ten dovoluje zjišťovat časové okamžiky s vysokým rozlišením.Jedná se o čítač, jehož časové rozlišení dosahuje na většině počítačů přesnosti kolem 1µs,což je pro naše potřeby dostatečné.

Důvodem proč se podařilo v ProfiMu zajistit generování tak krátkých period je efektivnívyužití možností přerušení od sériového portu s připojeným převodníkem RS 232/485,případně přerušení od rozšiřující karty. To si můžeme dovolit hlavně díky tomu, že jeProfiM napsaný jako ovladač s přímým přístupem na hardware.

5.3 Ovládání převodníku a jeho využití k časování

Jak již bylo popsáno v části 3.1 u standardního sériového portu na PC nemáme k dispozicipřerušení od prázdného výstupního posuvného registru. Musíme si proto pomoci využi-tím hardwarových vlastností převodníku (obrázek 3.1), jako je loop-back vracející všechnavyslaná data výstupem TxD na vstup RxD (při přepnutém převodníku na vysílání) apropojení mezi výstupem TxD a vstupem DSR.

Využívání sériového portu spolu s převodníkem, které zajišťuje přístup na RS–485 azároveň dostatečně rychlé časování, řeší následující módy činnosti:

Vysíláníznaků

Před začátkem vysílání rámce (bloku dat) přepneme převodník navysílání (RTS=1). Díky loop-backu v převodníku bude každý vyslanýznak zpětně také přijat (obrázek 5.1a). S příchodem každého přerušeníindikujícího příjem znaku zjišťujeme jestli se nejedná o poslední znakrámce. S jeho příchodem můžeme přepnout převodník zpět na příjem(RTS=0). K přepnutí tak nemůže dojít v nevhodnou chvíli (uprostředposledního vysílaného znaku), neboť ho provádíme až po příjmu přeru-šení indikujícího zpětný příjem posledního znaku, kdy znak už muselbýt celý vyslán a nikoliv po přerušení indikujícím prázdný vysílacíregistr.

Příjem znaků RTS je v logické nule, čímž jsou výstupy budičů sběrnice ve stavuvysoké impedance a sériový kanál tak může přijímat znaky ze sběrnice(obrázek 5.1b). Tento stav se ovšem při práci ProfiMu téměř vůbecnevyužívá, neboť pokud nevysíláme pak pokaždé běží nějaký time-out,například time-out při čekání na odpověď, čemuž odpovídá následujícímód.

Časováníse současnýmpříjmem znaků

Nejnáročnější a také nejdůležitější mód. V něm je převodník přepnutýna příjem (RTS=0), takže smyčka loop-backu je přerušena a pře-vodník tak může přijímat znaky ze sběrnice (obrázek 5.1b). Zároveňje však požadováno odměření nějakého časového intervalu (většinoutime-out).

40


Časováním od sériového portu získáme rozlišení přibližně 11tbit,což odpovídá intervalu potřebnému k vyslání jednoho znaku, který mákromě osmi datových bitů ještě jeden start bit, jeden stop bit a jedensudý paritní bit. Požadovaný interval v jednotkách tbit tak vydělímehodnotou 11 a výsledná hodnota pak určuje kolik znaků je potřebavyslat pro odměření požadovaného intervalu. Jelikož je smyčka loop-backu přerušena, můžeme začít do převodníku vysílat libovolné znaky- pro naše účely je, jak uvidíme později, vysílán znak 0x00. Ty se námtak nedostanou na vnější sběrnici a ani nijak nenarušují příjem znaků.

Opět zde musíme vyřešit problém týkající se přepínání směru tokudat na převodníku. V tomto módu sice na vnejší sběrnici nevysíláme,ale po příjmu požadovaných dat nebo vypršení time-outu musíme za-jistit korektní přepnutí na vysílání, které obvykle následuje.

Dokončení vysílání každého znaku je indikováno přerušením ozna-mující prázdný vysílací registr, tím dostáváme signál k vyslání dal-šího znaku. Když nám přijde přerušení oznamující vyslání posledníhoznaku, máme problém. Vysílací registr je sice prázdný, ale znak jestále vysouván z výstupního posuvného registru. Řešení pomocí loop-backu z módu vysílání znaků je zde nepoužitelné, neboť loop-back jerozpojen. Okamžité přepnutí směru s příchodem posledního znaku byzpůsobilo to, že se časovací znak dostane na sběrnici, což je nepřija-telné.

K řešení tohoto problému je v zapojení převodníku (obrázek 3.1)propojka mezi výstupem TxD a vstupem DSR. Tento vstup námumožňuje generovat tzv. „přerušení od modemuÿ. Toho využijeme ná-sledujícím způsobem. Po příjmu přerušení od posledního vysílanéhoznaku povolíme přerušení od modemu. Toto přerušení, díky tomu, ževysílaný časovací znak má hodnotu 0x00, přijde v okamžiku, kdy je napřevodník vysílána náběžná hrana stop bitu. To už si můžeme dovolitpřepnout směr na vysílání. Jedničková hodnota stop bitu znamená kli-dovou hodnotu na sběrnici se standardem RS–485. Po přepnutí ještězakážeme přerušení od modemu, aby nám další vysílaný znak nezpů-sobil přerušení.

Synchronizačnímezera

Využívá se pokud před vysílaný datový rámec potřebujeme vložit časo-vou prodlevu. Například pro každý rámec dotazu je normou Profibusuvyžadována prodleva o délce 33tbit. Funguje podobně jako předchozímód činnosti, pouze neočekává příjem žádných znaků.

Ve skutečnosti ProfiM funguje tak, že na převodník jsou neustále vysílány znaky. Buďse jedná o data určená pro vnější sběrnici RS–485, tedy Profibus, nebo jsou to znakyzajišťující časování, které na vnější sběrnici neprojdou.

41


TxD

R xD

A / B

a) vysí l á n í z n ak ůR S - 2 3 2 R S - 4 8 5

A / B

b ) p ř í j e m z n ak ů + č aso vá n í

R TS

DS R

„ 1 "

TxD

R xD

R TS

DS R

„ 0 " Př e v o d n í k

R S - 2 3 2 R S - 4 8 5

Př e v o d n í k

Obrázek 5.1: Využití převodníku RS 232/485

Použijeme-li rozšiřující kartu s obvodem UART typu 16C450 až 16C750, potom způsobpřístupu na sběrnici Profibus a způsob časování je stejný. Rozdíl je pouze v tom, že některékarty již mají výstup ve standardu RS–485, avšak nutnost softwarově ovládat směr zůstává(kvůli možnosti časování).

5.4 Časování s obvodem 16C950

S tímto obvodem je práce výrazně jednodušší, jelikož se jedná o obvod, který dává k dis-pozici přerušení od prázdného výstupního posuvného registru. Tím nám odpadají všechnysložité programové konstrukce, které se snažily tento nedostatek obejít.

Na druhou stranu směr toku dat na sběrnici s RS–485 je stále řízen programově a zůstá-vají i principy použité pro časování. Pouze není potřeba hardwarový loop-back a propojkamezi výstupem TxD a vstupem DSR, což byly hardwarové prostředky převodníku, kteréumožnily nahradit přerušení od prázdného výstupního posuvného registru.

Použití tohoto obvodu je velice spolehlivé a rychlostní limit přenosové rychlosti je pouzeotázkou výkonu procesoru a maximální přípustné míry zátěže procesoru.

5.5 Princip činnosti ProfiMu

Blokové schéma ProfiMu je na obrázku 5.2. Ústředním blokem je stavový automat FDLvrstvy. Tomu jsou podřízeny všechny ostatní části.

Přístup na sběrnici probíhá přes blok „Řízení Tx/Rx, časováníÿ. Ten tvoří rozhraník fyzické vrstvě a proto je jeho implementace závislá na použitém hardware, neboť naněj přímo přistupuje a využívá jeho možností. Obecně je funkcí tohoto bloku zajišťovatpřístup na sběrnici a to hlavně při nutnosti použít převodník (port se standardem RS–232).

42


Pro stavový automat zajišťuje vysílání rámců, indikaci události příjmu znaku ze sběrnicea především zajišťuje časování krátkých intervalů, k čemuž využívá možností hardwarovévrstvy a případného převodníku (zejména možností hardwarových přerušení). Ve verziProfiMu, která je součástí této diplomové práce podporuje tento blok standardní sériovýport RS–232 a PCI rozšiřující karty s obvodem OX16PCI954.

Z druhé strany je směrem k vyšším vrstvám orientované API rozhraní FDL vrstvy.To je tvořeno statickou knihovnou fdl rb.lib (název je zvolen k zachování maximálníkompatibility s řešením od Siemensu [6]), která je přilinkována k programům vyžadujícíkomunikaci s FDL vrstvou. Nejprve si program otevře komunikační kanál k FDL vrstvě apotom může začít posílat své požadavky (popis v kapitole 6). Požadavky jsou podle priority(high/low) ukládany do dvou front.

Získá-li náš master iniciativu na sběrnici (získáním tokenu), vybere z front požadavkůjeden požadavek a začne jej zpracovávat. Většina požadavků představuje komunikaci posběrnici, ale některé jsou pouze lokální (například zjištění konfigurace mastera nebo akti-vace SAP). Po zpracování požadavku je do fronty výsledků přidán výsledek. Ten kroměodpovědí nebo potvrzení příznivě zpracovaného požadavku může znamenat chybu nebotime-out.

Výsledky jsou z fronty vybírány aplikací přes API rozhraní FDL vrstvy. Důležitouvlastností při komunikaci mezi aplikací a API rozhraním FDL vrstvy je to, že z hlediskaaplikace má každý otevřený komunikační kanál s FDL vrstvou vlastní frontu požadavků avýsledků. To znamená, že jednu FDL vrstvu (jednoho DP mastera) může najednou sdíletvíce aplikací, aniž by docházelo k vzájemné kolizi mezi požadavky a výsledky. Prostředky,které DP master nabízí, jako jsou například přístupové body SAP, ovšem musejí být sdílené.

Jelikož implementujeme stanici typu master, zajišťuje stavový automat FDL vrstvykromě služeb pro vyšší vrstvy také svůj podíl na správě a řízení komunikace na Profibusu.K tomu patří, sledování provozu na sběrnici k detekci chybových stavů, vytváření a aktu-alizaci seznamu aktivních stanic LAS a seznamu GAP, který pro rozsah adres příslušejícínaší stanici master sleduje obsazenost jednotlivých adres Profibusu.

43


UART

Pr o f i b u sN et w o r k

Řízení Tx/RxČ a s o vá ní

S t a v o v ý a u t o m a tF D L v r s t v y

F r o nt ap o ža d a vk ů

F r o nt avýs l ed k ů

K o nf i g u r a c eS A PL i s t G A P

L i s t

P r o f i M A P I ( k o m p a t i b l ní s e s p ec i f i k a c í S i em ens )

O v l a d a č

H a r d w a r o v ě z áv i s l áv r s t v a o v l a d a če

Přer u š en íH a r d w a r e

API F D L v r s t v y

V y š š í v r s t v y D P- m a s t er n eb op ří m á k o m u n i k a c e s F D L

Slave HandlerD D L ME vent

Sc h edu lerD P

D P U s er1

D P U s ern...

V y š š í vr s t vyp r o D P - m a s t er

F D L A p p l i c a t i o n1 ...

F D L A p p l i c a t i o nn

W a t c h d o g

Obrázek 5.2: Blokové schéma ProfiMu

44


5.6 Watchdog

Ke zvýšení spolehlivosti byl do ProfiMu přidán watchdog. Ten sleduje aktivitu mastera av případě jeho delší nečinnosti jej resetuje.

Prakticky je realizován jako rutina, která je nezávislým systémovým časovačem vyvo-lávána v pravidelných intervalech přibližně jedné sekundy. K zjištění nečinnosti masteraje použito příznaku aktivity (proměnná), který je při činnosti mastera v pravidelných in-tervalech nastavován. Po vyvolání rutiny watchdogu je tento příznak zkontrolován a ihnedresetován. Není-li při kontrole watchdogem tento příznak nastaven, znamená to nějakouchybu a je proveden reset mastera.

Watchdog se hlavně uplatní při chybách v přerušovacím systému nebo v případě použitípřevodníku, kdy při odpojení převodníku z portu dojde k zastavení činnosti stavového auto-matu, jehož činnost je na převodníku přímo závislá (neplatí pro zásuvné karty s obvodem16C950). Watchdog potom zajišťuje opětovné spuštění mastera po opětovném připojenípřevodníku.

5.7 Zatížení procesoru

Jelikož ProfiM při implementaci Profibus DP mastera nepoužívá žádný speciální hardware,nese celé zatížení pouze procesor. Specifikem Profibusu je navíc to, že provoz na sběrnicineutichá ani v případech, kdy nejsou přenášena žádná data. Každá stanice DP master setotiž musí účastnit logického kruhu předávání tokenu, vyhledávat změny v jí příslušejícímadresovém GAP prostoru a navíc neustále sledovat provoz a analyzovat všechny rámce.

Graf zatížení procesoru naměřený s ProfiMem při použití různých přenosových rychlostíje na obrázku 5.3, průměrné číselné hodnoty jsou shrnuty v tabulce 5.2. Hodnoty zatíženíprocesoru byly změřeny na počítači s procesorem AMD Athlon XP 1600+ a rozšiřujícíkartou sériových portů Tedia PCI-1482 s obvodem OX16PCI954.

Jak je vidět, pro nižší rychlosti nepředstavuje zátěž procesoru větší problém. Předevšímpři použití standardního sériového portu, kdy máme k dispozici pouze rychlosti 9600bpsa 19200bps, se zvýšení zátěže téměř neprojevuje. Pokud ale chceme pracovat na vysokýchpřenosových rychlostech, je nutné zvýšenou zátěž vzít v úvahu a případně ještě upravitčasové parametry sítě, které dovolí větší časová zpoždění jako například TSL a maxTSDR.

Baudrate [kbps] 9,6 19,2 45,45 93,75 187,5 375 500 750 1500Zatížení CPU [%] ∼1% ∼1% ∼2% 6% 10% 17% 20% 25% 50%

Tabulka 5.2: Zatížení CPU podle přenosové rychlosti

45


Obrázek 5.3: Zatížení CPU podle přenosové rychlosti

46

Kapitola 6Aplikační rozhraní FDL vrstvy

Aplikační rozhraní FDL vrstvy ProfiMu je vytvořeno podle standardu definovaného firmouSiemens [6]. Podle tohoto standardu probíhá komunikace s FDL vrstvou pomocí jednotnédatové struktury nazývané Request Block (RB). Tato struktura představuje jakýsi uni-verzální rámec, který může představovat nejen jakýkoliv požadavek, ale také odpověď napožadavek nebo příznak události. Velikost Request Blocku je přibližně 600B a obsahujemnoho položek, z nichž pouze některé jsou v daný okamžik využité.

Komunikace probíhá tak, že aplikace (vyšší vrstva DP master nebo přímo FDL apli-kace) naplní strukturu Request Block, aby pomocí ní předala požadavek (Request) FDLvrstvě. Podle typu požadavku jsou naplněny pouze určité položky této struktury a ostatníjsou ponechány nevyužité. Následně je struktura poslána FDL vrstvě, ta podle požadavkuvykoná danou činnost a jako odpověď (Confirmation) pošle zpět aplikaci opět RequestBlock. Ten je poslán jak v případě úspěšného vyřízení požadavku, tak i v případě nějakéchyby.

Request Block je také využíván jako indikace události v FDL vrstvě (Indication).Nastane-li nějaká událost (např. příchod dat od jiného mastera) posílá FDL vrstva RequestBlock aplikaci s příslušně nastavenými položkami podle typu události.

Aplikační rozhraní tvoří pět jednoduchých funkcí SCP_xxx pro přímou komunikacis ovladačem pomocí struktury Request Block:SCP open(char *name)Otevře komunikační kanál mezi aplikací a FDL vrstvou.Parametryname určuje jméno ovladače. První instance ProfiMu má jméno „\\.\ProfiMÿ

další potom „\\.\ProfiM1ÿ, „\\.\ProfiM2ÿ. . .Návratová hodnotaFunkce vrací handle ke komunikačnímu kanálu mezi ovladačem a aplikací. Tuto hodnotupoužívají všechny další funkce k volání ovladače. Nepodaří-li se handle vytvořit, vracífunkce systémem definovanou hodnotu INVALID HANDLE VALUE.

47


SCP send( int handle, UWORD length, char *rb )Pošle FDL vrstvě Request Block reprezentující požadavek.Parametryhandle komunikační kanál otevřený pomocí SCP open*rb ukazatel na posílaný Request Blocklength délka Request Blocku

Návratová hodnotaSCP SUCCESS ovladač přijal Request Block.SCP ERROR při předávání došlo k chybě. Konkrétní kód chyby vrátí funkce

SCP get errno.

SCP receive( INT handle, UWORD timeout, UWORD *data len, UWORD length,CHAR *buffer )Tato funkce umožňuje získávat od FDL vrstvy zpět data, výsledky požadavků a indikaceudálostí. Přenášená data jsou opět ve formě Request Blocku a aplikace na něj může podlenastavení parametru timetou čekat synchronně nebo asynchronně.Parametryhandle komunikační kanál otevřený pomocí SCP opentimeout určuje v milisekundách jak dlouho bude funkce čekat na výsledek.

Kromě počtu milisekund lze použít hodnoty SCP NOWAIT, která způsobí,že data budou vrácena pouze pokud jsou v době volání funkce již k dis-pozici a nebude se na ně čekat. Jinou možnou hodnotou je SCP FOREVER,která způsobí, že funkce bude čekat dokud výsledek nebude k dispozici

*data len vrátí délku dat zapsaných do bufferulength velikost bufferu pro přijímaná data - měl by mít velikost alespoň jako

Request Block*buffer ukazatel na buffer pro vrácená data

Návratová hodnotaSCP SUCCESS přečtení Request Blocku bylo úspěšné.SCP ERROR při čtení nastala chyba. Konkrétní kód chyby vrátí funkce

SCP get errno.

SCP close(int handle)Uzavře a uvolní handle komunikačního kanálu k FDL vrstvě.Parametryhandle určuje komunikační kanál k uzavření

Návratová hodnotaSCP SUCCESS komunikační kanál se úspěšně podařilo uzavřít.SCP ERROR chyba při uzavírání komunikačního kanálu. Konkrétní kód chyby vrátí

funkce SCP get errno.

48


SCP get errno()Je volána pokud se některá z předchozích funkcí nezdaří a vrátí hodnotu SCP ERROR.Parametry-Návratová hodnotaVrácená hodnota udává konkrétní chybový kód. Tyto chybové kódy jsou popsány v [6].

6.1 Služby linkové vrstvy

FDL vrstva nabízí následující služby datové výměny (blíže [6]):

• SDA

• SDN

• REPLY UPDATE SINGLE

• REPLY UPDATE MULTIPLE

a následující služby správy a řízení linkové vrstvy:

• FDL READ VALUE

• SAP ACTIVATE

• RSAP ACTIVATE

• SAP DEACTIVATE

• LSAP STATUS

• FDL LIFE LIST CREATE REMOTE

• FDL LIFE LIST CREATE LOCAL

• FDL IDENT

• FDL READ STATISTIC COUNTER

• AWAIT INDICATION

• FDL EVENT

• WITHDRAW INDICATION

pro každou z těchto služeb je určen formát a význam jednotlivých položek RequestBlocku podle [6]. Pro zjednodušené vytváření správných Request Blocků pro tyto poža-davky přidává ProfiM několik dalších funkcí. Ty podle parametrů vytvoří Request Blockodpovídající typu požadavku a pošlou jej FDL vrstvě. Nejpoužívanější z těchto funkcí jsounásledující:SAP activate(int DriverHandle, BYTE sap nr, BYTE ACCSAP, BYTE ACCSTAT,BYTE SDA R, BYTE SDN R, BYTE SRD R, BYTE priority)Aktivuje přístupový bod Service Access Point s číslem sap nr.

49


Send SRD Hex( int DriverHandle, BYTE adr, UBYTE ssap, UBYTE dsap, unsignedchar *data, BYTE priority )Pošle FDL vrstvě požadavek na vyslání datového rámce stanici s adresou adr s očeká-váním odpovědi - Send and Request Data (SRD). Umožňuje zadávat data v hexadeci-málním formátu ve formě řetězce - např. "B8 12 45".

Send SRD Bin( int DriverHandle, BYTE addr, BYTE ssap, BYTE dsap, unsignedchar *data, int length, BYTE priority )Pošle FDL vrstvě požadavek Send and Request Data (SRD) s daty v binárním tvaru.

Send SDN Hex( int DriverHandle, BYTE addr, BYTE ssap, BYTE dsap, unsignedchar *data, BYTE priority )Pošle FDL vrstvě požadavek na vyslání datového rámce stanici s adresou adr bez oče-kávání odpovědi - Send Data with no Acknowledge (SDN). S daty zadanými v hexade-cimálním formátu ve formě řetězce - např. "B8 12 45".

Send SDN Bin( int DriverHandle, BYTE addr, BYTE ssap, BYTE dsap, unsignedchar *data, int length, BYTE priority )Pošle FDL vrstvě požadavek Send Data with no Acknowledge (SDN) s daty v binárnímtvaru.

Read FDL value( int DriverHandle, BYTE priority )Umožňuje zjistit aktuální parametry sítě.

FDL life list remote( int DriverHandle, BYTE priority )Vytvoří seznam aktivních stanic na sběrnici.

6.2 Komunikace s FDL vrstvou

Způsob komunikace s FDL vrstvou obvykle záleží na složitosti programu (příklady jsouuvedeny v příloze A). V jednoduchých aplikacích si většinou vystačíme se synchronnímpřístupem. Aplikace vyšle požadavek a pomocí SCP receive s parametrem timeout>0začne čekat na výsledek. Při tomto volání SCP receive je program v místě volání poza-staven, dokud FDL vrstva nevrátí výsledek pro aplikaci. Tento způsob je přímočarý, aleneumožňuje posílat více požadavků najednou a reagovat na události v FDL vrstvě.

Jiným komplexnějším způsobem je vytvoření samostatného threadu, který slouží pouzepro příjem Request Blocků z FDL vrstvy. Ten po svém spuštění zavolá SCP receive s pa-rametrem timeout=SCP FOREVER a začne čekat na Request Block. S jeho příchodem jeRequest Block předán ke zpracování a thread opět volá SCP receive s parametrem time-out=SCP FOREVER. Přijímací thread ovšem potřebuje rozlišit pro koho je výsledek určen

50


(požadavků může být od jedné aplikace zpracováváno více najednou). K tomu se používápoložka Request Blocku s názvem user, která je určena pro potřeby aplikace a FDL vrstvajejí hodnotu při zpracování požadavku zachovává.

Pro využití ProfiMu při psaní aplikací je připravena statická knihovna fdl rb.lib ahlavičkový soubor se všemi potřebnými definicemi fdl rb.h. Jména jsou zvolena stejněs originálními knihovnami firmy Siemens. K použití ProfiMu v projektu, který původněpoužíval řešení od Siemensu pak pouze stačí tyto dva původní soubory nahradit souboryProfiMu, změnit jméno otevíraného zařízení ve funkci SCP open z například obvyklého„/CP L2 1:/FLCÿ na „\\.\ProfiMÿ a tím by měla být náhrada hotová.

51

Kapitola 7Závěr

Přes nemalé potíže, které provázely vývoj této diplomové práce, se nakonec podařilo do-sáhnout cíle a snad i překonat původní očekávání. Výsledkem je realizace Profibus DPMastera na PC, vytvořeného až po FDL vrstvu, včetně. Práce umožňuje připojit Profibuspřes sériový port s přenosovými rychlostmi 9600bps a 19200bps nebo pro dosažení vyššíchrychlostí použít PCI karty s obvodem UART (16C950). S použitím rozšiřující karty se po-dařilo dosáhnout až rychlosti 3Mbps, avšak to byla hranice dána pouze výkonem procesoru(konfigurace testovací sestavy viz. 5.7).

Navíc se podařilo propojit tuto diplomovou práci s jinou diplomovou prací z předcho-zích let [2], která implementovala vyšší vrstvy Profibus DP Mastera, čímž vznikla zcelaplnohodnotná implementace ve všech vrstvách až po aplikační.

Dá se předpokládat, že o tuto práci by mohl vzniknout zájem ze strany firem pracují-cích v oboru, neboť možnost realizovat Profibus DP Mastera s minimálními náklady, jakoumožňuje tato práce, bude pro ně určitě lákavá. Obzvláště proto, že nic podobného ještěpro PC nebylo vytvořeno a to z důvodů zřejmé implementační náročnosti.

Softwarová realizace byla vytvořena jako ovladač pro operační systémy Windows NT,2000 a XP, který navíc na jednom počítači dokáže obsluhovat až několik připojení Profibusua může být synchronně nebo asynchronně využíván několika aplikacemi.

Jelikož prostředí operačních systémů Windows nejsou určena pro aplikace reálnéhočasu, nelze pro vysoké přenosové rychlosti úplně zaručit, že DP Master tvořený ProfiMempokaždé dodrží časové intervaly dané normou. Na druhou stranu se to stává výjimečněa i v nejhorších případech je návrhem Profibusu zaručeno bezproblémové znovuobnoveníčinnosti sběrnice. Z toho také vyplývá nemožnost nasadit ProfiM pro aplikace vyžadujícívysokou spolehlivost.

Pro dobrou možnost k využití ovladače aplikacemi bylo vytvořeno aplikační rozhraníFDL vrstvy, která je kompatibilní s aplikačním rozhraním používaným firmou Siemens.U programů, které jej využívají to dovoluje velice jednoduše vyměnit původní hardwarové

52


řešení za ProfiM. K výměně stačí překopírovat do projektu statickou knihovnu ProfiMu azměnit jméno otevíraného zařízení ve funkci SCP open.

V diplomových pracích z předchozích let, které se zabývaly Profibusem, bylo zvykemjako důkaz funkčnosti přidávat do diplomové práce výpisy provozu na sběrnici z analyzátoruProfibusu. To se mi zdá ovšem nepřehledné a málo průkazné a proto jako ukázka správnéčinnosti Profibus DP mastera byla ve strojovně na Karlově náměstí vytvořena jednoducháukázková aplikace, kde pomocí počítače s nainstalovaným ProfiMem jsou řízeny dva modelypásového dopravníku a manipulátor s krokovými motory (příloha B). Všechny snímače aakční členy jsou připojeny na dva moduly vstupů a výstupů, které jsou jako jednotky slavepřipojeny na Profibus. Navíc sběrnice přes kterou probíhá komunikace, může být sdílenas dalším masterem, kterým je PLC od firmy Siemens.

7.1 Co by šlo vylepšit nebo přidat

• Přepsat ProfiM pro některý z operačních systémů reálného času, jako je napříkladRT–Linux, nebo použít nějakou real-timovou nástavbu pro Windows. To by mohlozajistit vysokou spolehlivost chodu a přesné dodržování časových parametrů sběrnice.

• Přidat do ovladače podporu pro Power Management. K správné funkci není nezbytná,avšak měla by být jeho součástí.

• Další optimalizací kódu snížit zátěž procesoru, což by umožňovalo dosahovat vyššíchpřenosových rychlostí.

53

Prıloha APříklad použití ProfiMu

Chceme-li použít ProfiM v programu, který původně využíval pro přístup k Profibusurozhraní kompatibilní se Siemensem nebo chceme-li vytvořit nový program, přidáme doprojektu statickou knihovnu „fdl rb.libÿ a hlavičkový soubor „fdl rb.hÿ.

Jednoduchý příklad

Následující část kódu ukazuje nejjednodušší možnost použití ProfiMu. Jedná se o jedno-vláknový program, který inicializuje modul vstupů a výstupů Siemens ET-200B a provedejednu iteraci datové výměny. Všechna čekání na výsledek SCP receive jsou blokující azastavují běh programu.

#include "fdl_rb.h"

int DriverHandle;

int SlaveAddress = 13;

void main()

{

unsigned short length;

fdl_rb rb;

BYTE Buffer [256];

BYTE out , in1 , in2 , in3;

/* Otevreni komunikacniho kanalu k ovladaci */

DriverHandle = SCP_open ( "\\\\.\\ ProfiM" );

/* Aktivace pristupovych bodu SAP */

SAP_activate ( DEFAULT_SAP , ALL , ALL , SERVICE_NOT_ACTIVATED ,

BOTH_ROLES , BOTH_ROLES , high );

SCP_receive(DriverHandle ,3000 ,& length ,sizeof(rb),(char *) &rb);

SAP_activate ( 62, ALL , ALL , SERVICE_NOT_ACTIVATED ,

54


INITIATOR , INITIATOR , high );


/* Zaslani parametrizacniho ramece */

Send_SRD_Hex(DriverHandle ,SlaveAddress ,62,61,

"B0 08 09 0B 00 0F 00 00 00 00 00 00",high);


/* Zaslani konfiguracniho ramece */

Send_SRD_Hex(DriverHandle ,SlaveAddress ,62,62,"20 12",high);


/* Jedna iterace datove vymeny */

Buffer [0] = out; /* hodnota vystupu */

Send_SRD_Bin(DriverHandle ,SlaveAddress ,DEFAULT_SAP ,DEFAULT_SAP ,

Buffer ,1,high);


Offset=rb.user_data_2 [0];

in1 = rb.user_data_2[Offset ]; /* 1. byte vstupu */

in2 = rb.user_data_2[Offset +1]; /* 2. byte vstupu */

in3 = rb.user_data_2[Offset +2]; /* 3. byte vstupu */

/* Uzavreni komunikacniho kanalu */

SCP_close ( DriverHandle );

}

Komplexnější příklad

Při řešení komplexnějších komunikačních problémů obvykle nelze použít lineární strukturuprogramu a většinou se nevyhneme použití více vláken. Základem je vlákno zpracovávajícívšechny odpovědi, které FDL vrstva posílá aplikaci zpět. Toto vlákno pracuje v nekonečnésmyčce, která nejprve čeká na odpověď (timeout=SCP FOREVER) a potom podle identifi-kátoru tazatele je každá odpověď zpracována zvlášť. Nakonec přechází vlákno opět v čekánína odpověď.

Vlákno příjmu odpovědí

void ReceiverThread ()

{

unsigned short length;

fdl_rb rb;

while (1)

{

/* Cekani na vysledek bez time -outu */

55


SCP_receive ( DriverHandle , SCP_FOREVER , & length ,

sizeof(rb), (char *) &rb);

/* Zpracovani prijate odpovedi podle identifikatoru tazatele */

switch ( rb.rb2header.user )

{

case RequestorID_1:

...

case RequestorID_2:

...

case ...:

...

}

}

}

Posílání požadavků pak může probíhat současně z několika vláken. Důvodem pro při-jímání odpovědí pouze v jednom vláknu je možnost rozlišit komu je odpověď adresována.Kdyby každé vlákno posílající požadavky mělo i vlastní příjem odpovědi, mohlo by dojítk jejich záměně mezi vlákny. Odpovědi jsou totiž s požadavky svázány podle použitéhoDriverHandle a funkce SCP receive vrátí první odpověď se stejným DriverHandle. Jinýmřešením potom je, otevřít si pro každé vlákno vlastní handle. Pak již k záměnám nemůžedocházet a každé vlákno dostane pouze své odpovědi.

56

Prıloha BUkázková aplikace ProfiMu

Pro předvedení funkčnosti vytvořeného Profibus DP Mastera, byla ve strojovně na Karlověnáměstí vytvořena jednoduchá ukázková aplikace (obrázek B.1). Pomocí počítače s nain-stalovaným ProfiMem je řízen jednoduchý model dvou dopravníků a manipulátoru s kro-kovými motory, který je umístěn mezi nimi. Všechny vstupy a výstupu tohoto modelu jsoupřipojeny na dvě jednotky vzdálených vstupů a výstupů (obrázek B.2):

• WAGO-I/O-SYSTEM 752–323 16DI/16DO

• WAGO-I/O-SYSTEM 750–301 8DI/8DO

Tyto jednotky jsou jako stanice typu slave připojeny na sběrnici Profibus, která je pro-pojuje s řídícím počítačem. Úkolem ProfiMu jako Profibus DP Mastera, je inicializovat akonfigurovat obě jednotky vzdálených vstupů a výstupů a posléze začít datovou výměnu,při které přenáší do jednotek obrazy výstupů a zároveň nazpět čte obrazy jejich vstupů.Navíc zajišťuje správu provozu na Profibusu a případné sdílení sběrnice s další řídící sta-nicí master. Obrazy vstupů a výstupů jsou aplikační vrstvou ProfiMu poskytovány aplikaci,která tak má vytvořeny podmínky podobné programům v PLC a zajišťuje řízení modelu.

Aplikační interface ProfiMu může být současně využíván více aplikacemi. To je demon-strováno další stanicí vzdálených vstupů a výstupů Siemens ET-200B 24DI/8DO, která jepřipojena na stejnou sběrnici jako dvě předchozí stanice a řízena z jiné aplikace. Není všakna ní připojen žádný model a tak řídící aplikace pouze v určité sekvenci nastavuje výstupy,což je možné vidět na indikačních LED diodách.

Tato aplikace je velmi jednoduchá, avšak úkolem této práce nebylo řídit nějaký složitýmodel. Pro demonstraci komunikačních schopností vytvořeného Profibus DP Mastera jevcelku dostatečná.

57


Obrázek B.1: Model dopravníků s manipulátorem

Obrázek B.2: Stanice vzdálených vstupů a výstupů připojující model na Profibus

58

Prıloha CSeznam zkratek

C.1 Zkratky pro Profibus

CSRD Cyclic Send and Request Data with reply (FDL Service)DA Destination Address of a frameDAE Destination Address Extension(s) of a frame conveys DSAP and/or destination

Bus IDDDML Direc Data Link MapperDSAP Destination Service Access Point a LSAP which identifies the remote FDL

UserED End Delimiter of a frameFC Frame Control (frame type) of a frameFCS Frame Check Sequence (checksum) of a frame used to detect corrupted framesFDL Fieldbus Data Link layer, OSI layer 2FMA1/2 Fieldbus MAnagement layer 1 and 2G GAP update factor the number of token rounds between GAP maintance (up-

date) cyclesGAP Range of station addresses from This Station (TS) to its successor (NS) in the

logical token ring, excluding stations above HSAGAPL GAP List containing the status of all stations in this station’s GAPHSA Highest Stations Address installed (configured) on this Profibus segmentLAS List of Active StationsLE field giving LEngth of frame beyond fixed partLEr field that repeats LEngh to increase frame integrityLSAP Link Service Access Point identifies one FDL User in a particular stationNS Next Station (FDL), the station to which this Master will pass the tokenOSI Open System InterconnectionPHY PHYsical layer, OSI layer 1

59


PS Previous Station (FDL), the station which passes the token to this Masterstation

RSAP Reply Service Access Point an LSAP at which Request Data may be obtainedSA Source Address of a frameSAE Source Address Extension(s) of a frame conveys SSAP and/or source Bus IDSAP Service Access Point, the point of interaction between entities in different pro-

tocol layersSD Start Delimiter of a frameSDA Send Data with Acknowledge FDL Service)SDN Send Data with No acknowledge (FDL Service)SRD Send and Request Data with reply (FDL Service)SSAP Source Service Access Point, an LSAP which identifies the local FDL User

which initiates a transactionSYN SYNchronization bits of a frame (period of IDLE) it guarantees the specified

frame integrity and allow for receiver synchronizationtBIT BIT Time, FDL symbol period of the time to transmit one bit on this Profibus

System

C.2 Zkratky pro DDK

DDK Drivers Development KitDIRQL Device Interrupt ReQuest Level - the IRQL at which a given device interrupts.DPC Deferred Procedure Call - a Kernel-defined control object type which represents

a procedure that is to be called later. DPC usually finishes time consumingoperations initialized by ISR.

GUID Globally Unique IDentifierHAL Hardware Abstraction Layer - a Windows NT/Windows 2000 executive com-

ponent that provides platform-specific support for the Kernel, I/O Manager,kernel-mode debuggers, and lowest-level device drivers.

ISR Interrupt Service Routine - a routine whose function is to service a device whenit generates an interrupt.

IRP I/O Request Packet - is the basic I/O Manager structure used to communicatewith drivers and to allow drivers to communicate with each other

IRQ Interrupt ReQuest line - a hardware line over which a peripheral device, buscontroller, other processor, or the Kernel signals a request for service to themicroprocessor.

IRQL Interrupt ReQuest Level - the hardware priority level at which a given kernel-mode routine runs, thereby masking off interrupts with equivalent and lowerIRQL on the processor.

PnP Plug and PlayWDM Windows Driver ModelWMI Windows Management Instrumentation

60

Prıloha DObsah přiloženého CD

\src Zdrojové kódy ProfiMu\Ovladac Zdrojové kódy ovladače a instalačních souboru (INF file)\Knihovny Zdrojové kódy knihoven aplikačního rozhraní\Property Page Zdrojové kódy pro Property Page - panelu pro nastavení vlast-

ností ve Správci zařízení\Ukazky pouziti Jednoduché programy v C++ Builder ukazující použití aplikač-

ního rozhraní ProfiMu

\bin Výsledné soubory připravené k použití\Ovladac Přeložený ovladač spolu s dalšími soubory připravený k instalaci.

Rozděleno podle operačního systému na verzi pro Windows NT4.0 a Windows 2000/XP

\Knihovny Statické knihovny aplikačního rozhraní ProfiMu

\Podklady Veškerá dokumentace v elektronické podobě, kterou se převážněz Internetu podařilo získat o Profibusu, o standardu RS-485,o psaní ovladačů apod.

\HTML Tato diplomová práce převedená do formátu HMTL pro vysta-vení na Internetu.

\LaTeX Kompletní „zdrojový kódÿ tohoto dokumentu v LATEXu spolus obrázky. Dobrá inspirace pro ty, kteří chtějí také napsat svojidiplomovou práci v LATEXu.

61

Seznam obrázků

2.1 ISO/OSI model a Profibus DP . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Formát znaku Profibusu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Formát rámce pověření (Token Frame) . . . . . . . . . . . . . . . . . . . . 72.4 Formát rámce bez dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Formát rámce s daty fixní délky . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Formát rámce s daty proměnné délky . . . . . . . . . . . . . . . . . . . . . 82.7 Stavový automat FDL vrstvy . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Jednoduchý interface RS–232/RS–485 . . . . . . . . . . . . . . . . . . . . . 173.2 Přerušení vysílače UARTu . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Redukce pro připojení karet Tedia na Profibus . . . . . . . . . . . . . . . . 20

4.1 Kernel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Zpracování IRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Struktura Legacy ovladače . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Struktura PnP ovladače . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Property Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Využití převodníku RS 232/485 . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Blokové schéma ProfiMu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Zatížení CPU podle přenosové rychlosti . . . . . . . . . . . . . . . . . . . . 46

B.1 Model dopravníků s manipulátorem . . . . . . . . . . . . . . . . . . . . . . 58B.2 Stanice vzdálených vstupů a výstupů připojující model na Profibus . . . . 58

62

Seznam tabulek

3.1 Porovnání přenosových rychlostí RS–232 v PC a Profibusu (hodnoty jsouv bps) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Vlastnosti UART obvodů . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Prioritní úrovně . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Zatížení CPU podle přenosové rychlosti . . . . . . . . . . . . . . . . . . . . 45

63

Literatura

[1] RŮŽIČKA, Pavel. Realizace vrstvy FDL protokolu Profibus. Diplomová práce. Praha:České vysoké učení technické, Elektrotechnická fakulta, Katedra řídicí techniky, 2002.73 s.

[2] SMEJKAL, Radek. Realizace Profibus DP master. Diplomová práce. Praha: Českévysoké učení technické, Elektrotechnická fakulta, Katedra řídicí techniky, 2002. 79 s.

[3] BARTOSINKI, Roman. Implementace USB interface pro počítačové periferie. Diplo-mová práce. Praha: České vysoké učení technické, Elektrotechnická fakulta, Katedrařídicí techniky, 2003. 82 s.

[4] ONEY, WALTER. Programming the Microsoft Windows Driver Model. Second Edi-tion. Microsoft Press, 2002. 800 p. ISBN 07-3561-803-8.

[5] PROFIBUS Specification. Edition 1.0. Karlsruhe: PROFIBUS International, 1997.924 p. European Standard EN 50 170.

[6] FDL Programming Interface. Release 4. Karlsruhe: Siemens AG, 1995. 126 p.

[7] BURGET, Pavel. Implementace zařízení DP Slave. Praha: České vysoké učení tech-nické, Elektrotechnická fakulta, Katedra řídicí techniky, 1999. 5 s.

[8] RS–232 and RS–485 Application Note. Octomber 1997 Revision. Ottawa: B&BElectronics Ltd., 1997. 44 p.

[9] OX16PCI954 Data Sheet. Revision 1.3. Oxfordshire: Oxford Semiconductor LTD.,1999. 72 p.URL: <http://www.oxsemi.com>

[10] PCI-COM komunikační karty pro sběrnici PCI. Revize 04.2003. Plzeň: TEDIA spol.s.r.o., 2003. 28 s.URL: <http://www.tedia.cz>

64


[11] VIRIUS, Miroslav. Programování v C++. Praha: České vysoké učení technické, 2001.364 s. ISBN 80-01-01874-1.

[12] Microsoft Developer Network - Device Drivers Developement. Microsoft.URL: <http://msdn.microsoft.com>

[13] BOLDIŠ, Petr. Bibliografické citace dokumentů podle ČSN ISO 690 a ČSN ISO 690-2(01 0197): Část 1 Citace: metodika a obecná pravidla. Verze 3.2. c©1999–2002, po-slední aktualizace 3.9. 2002.URL: <http://www.boldis.cz/citace/citace1.pdf>

65

D IPL O M O V Á PR Á C E Profibus D P M aster na PC

Documents

Transcript of D IPL O M O V Á PR Á C E Profibus D P M aster na PC