Herunterladen Inhalt Inhalt
Teilen
Diese Seite drucken
Phoenix Contact IBS PCI DDK UM Anwenderhandbuch
  1. Anleitungen
  2. Marken
  3. Phoenix Contact Anleitungen
  4. Controller
  5. IBS PCI DDK UM
  6. Anwenderhandbuch
Phoenix Contact IBS PCI DDK UM Anwenderhandbuch

Phoenix Contact IBS PCI DDK UM Anwenderhandbuch

Device driver development kit zu anschaltbaugruppen für pc-systeme mit pci-bus
Vorschau ausblenden
Inhaltsverzeichnis

Werbung

Quicklinks

Diese Anleitung herunterladen
INTERBUS
Anwenderhandbuch
Device Driver Development Kit zu Anschalt-
baugruppen für PC-Systeme mit PCI-Bus
Bezeichnung:
IBS PCI DDK UM
Art.-Nr.:
26 98 15 1

Werbung

Inhaltsverzeichnis
loading

Verwandte Anleitungen für Phoenix Contact IBS PCI DDK UM

Inhaltszusammenfassung für Phoenix Contact IBS PCI DDK UM

  • Seite 1 INTERBUS Anwenderhandbuch Device Driver Development Kit zu Anschalt- baugruppen für PC-Systeme mit PCI-Bus Bezeichnung: IBS PCI DDK UM Art.-Nr.: 26 98 15 1...
  • Seite 3 INTERBUS Anwenderhandbuch Device Driver Development Kit zu Anschaltbaugruppen für PC-Systeme mit PCI-Bus Bezeichnung: IBS PCI DDK UM Revision: Art.-Nr.: 26 98 15 1 Dieses Handbuch ist gültig für: IBS PCI SC/I-T Art.-Nr. 27 25 26 0 IBS PCI SC/RI/I-T Art.-Nr. 27 30 08 0 IBS PCI SC/RI-LK Art.-Nr.
  • Seite 5 Sicherheitskonzepten der Automatisierungstechnik sowie den geltenden nationalen Normen vertraut sind. Für Fehlhand- lungen und Schäden, die an Produkten von Phoenix Contact und Fremd- produkten durch Missachtung der Informationen dieses Handbuchs ent- stehen, übernimmt Phoenix Contact keine Haftung.
  • Seite 6 Firma Phoenix Contact. Zuwiderhandlungen verpflichten zu Schaden- ersatz. Phoenix Contact behält sich jegliche Änderungen, die dem technischen Fortschritt dienen, vor. Alle verwendeten Produktnamen sind Marken der jeweiligen Organisatio- nen. Internet Aktuelle Informationen zu Produkten von Phoenix Contact finden Sie im In- ternet unter www.phoenixcontact.com. 6189A...
  • Seite 7 Rechnung. Die Nutzung ist nur an einem Standort zulässig. § 3 Urheberrecht Die Software steht im Eigentum der Phoenix Contact. Ein Erwerb von über das in diesem Vertrag ge- regelte Nutzungsrecht hinausgehender Rechte an der Software selbst ist damit nicht verbunden.
  • Seite 8 Anwendungen und Kombinationen fehlerfrei arbeitet. Die Gewährleistungsfrist beträgt sechs Monate, sie beginnt mit der Auslieferung der Software. Phoenix Contact gewährleistet, dass zum Zeitpunkt der Übergabe die Datenträger, auf denen die Soft- ware aufgezeichnet ist und die mitgelieferte Dokumentation in der Materialausführung fehlerfrei sind.
  • Seite 9 Schäden begrenzt, mit deren Entstehung im Rahmen einer Softwareüberlassung typischerweise ge- rechnet werden muss. Im übrigen haftet Phoenix Contact nur für Vorsatz und grobe Fahrlässigkeit, so- fern nicht eine Pflicht verletzt wird, deren Einhaltung für die Erreichung des Vertragszwecks von besonderer Bedeutung ist (Kardinalpflicht).
  • Seite 10 Bei allen, sich aus dem Vertragsverhältnis ergebenden Streitigkeiten ist, wenn der Lizenznehmer Voll- kaufmann, eine juristische Person des öffentlichen Rechts oder es sich um ein öffentlich-rechtliches Sondervermögen handelt, das Gericht am Sitz von Phoenix Contact zuständig. Für alle Rechtsbeziehungen, die sich für die Parteien aus dem Vertrag ergeben, gilt das Recht der Bundesrepublik Deutschland.

  • Seite 11: Inhaltsverzeichnis

    Inhaltsverzeichnis Einleitung ......................1-3 Dateien auf dem Datenträger............. 1-4 Support-Bedingungen ..............1-7 1.2.1 Kostenpflichtige Supportleistungen .......1-8 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen......2-3 PCI-Register................2-4 Host-Interface der INTERBUS-Anschaltbaugruppen ....2-6 2.2.1 Hardware-Einstellungen der Anschaltbaugruppen ..2-6 2.2.2 I/O-Register ..............2-8 Multi-Port-Memory (MPM)............2-16 2.3.1 Adressraum des MPM ..........2-19 2.3.2 Aufteilung des SRAM im MPM ........2-20 2.3.3...
  • Seite 12 IBS PCI DDK UM 5.3.2 Datenkanal öffnen (openDevice) ........5-11 5.3.3 Datenkanal schließen (closeDevice) ......5-12 5.3.4 Prozessdaten schreiben (writeDTI) ......5-13 5.3.5 Prozessdaten lesen (readDTI) ........5-14 5.3.6 Nachricht senden (writeMXI) ........5-15 5.3.7 Nachricht auslesen (readMXI) ........5-16 5.3.8 Interrupt-Service-Routine (intrServiceFunction) ..5-18 5.3.9 Device IO Control (devIOCtrl) ........5-19 5.3.10 Hilfsfunktionen ............5-21...
  • Seite 13 Kapitel Dieses Kapitel informiert Sie über – die Zielsetzung und den Aufbau dieses Handbuches. Einleitung ......................1-3 Dateien auf dem Datenträger............1-4 Support-Bedingungen ..............1-7 1.2.1 Kostenpflichtige Supportleistungen........1-8 6189A...
  • Seite 14 6189A...

  • Seite 15: Einleitung

    Einleitung 1 Einleitung Mit Hilfe dieses Handbuches sowie der zugehörigen Treiber-Sourcen in der Programmiersprache C ist es möglich, spezifische Gerätetreiber zu entwickeln, die die INTERBUS-Anschaltbaugruppen der Generation 4 an beliebige PC-Betriebssysteme anbinden. Die Anschaltbaugruppen IBS PCI SC/I-T, IBS PCI SC/RI/I-T und IBS PCI SC/RI-LK (im folgenden IBS PCI-Anschaltbaugruppen) dienen der Anschaltung des offenen Feldbussy- stems INTERBUS (genormt als IEC 61158) an PC-Systeme (im folgenden Host-System) mit PCI-Bus.

  • Seite 16: Dateien Auf Dem Datenträger

    IBS PCI DDK UM Dateien auf dem Datenträger Auf dem Datenträger befinden sich folgende Verzeichnisse: Bild 1-1 Verzeichnisstruktur des Datenträgers Tabelle 1-1 Inhalt der Verzeichnisse Verzeichnisname Inhalt IBPCIMPM.SYS Enthält die C-Sourcen des Treibers. Enthält die Anpassungen an das System Enthält die Includes für verschiedene Systeme Enthält das Device Driver Interface für VxWorks...
  • Seite 17 Einleitung Tabelle 1-2 Dateien im Verzeichnis „IBPCIMPM.SYS“ Dateiname Inhalt startup.c Initialisierung von Hard- und Software drvinits.c Initialisierungsroutinen des Treibers vxwsys.c Betriebssystem-Funktionen/Routinen für VxWorks Ibpcidrv.c Funktionen/Routinen für den PCI-Zugriff evthndg.c Funktionen/Routinen zum Event-Handling drvlimit.h Konstanten zur Begrenzung (max. Werte etc.) errlog.h Macros, Konstanten etc.
  • Seite 18 IBS PCI DDK UM Tabelle 1-4 Dateien im Verzeichnis „IB_INC\USR“ Dateiname Inhalt stdtypes.h Allgemein gültige Standard-Typ-Definitionen ddi_err.h Definitionen der möglichen Treiber-Fehlermeldungen. ddi_usr.h Defines, typedef, Prototypen für DDI Basisfunktionen (ohne I/O-Ctrl u. Management) ibs_util.h Deklarationen der zusätzlichen DDI-Funktionen, z. B. Watchdog, Diagnose-Register lesen, usw.

  • Seite 19: Support-Bedingungen

    Einzelfall notwendig sein, werden wir uns mit Ihnen in Verbindung set- zen. Hierfür entstehen Ihnen keinen zusätzlichen Kosten. Unser Support kann nur für die von Phoenix Contact gelieferten Sourcen geleistet werden. Da uns Ihre Entwicklungsumgebung nicht bekannt ist, und in der Regel auch nicht zur Verfügung steht, liegen alle davon betrof- fenen Implementierungsarbeiten nicht in Verantwortung oder Zuständig-...

  • Seite 20: Kostenpflichtige Supportleistungen

    IBS PCI DDK UM Phoenix Contact haftet für die gelieferten Produkte ausschließlich im Rah- men der gesetzlich geregelten Produkthaftung bzw. gemäss der allgemei- nen Lieferungs- und Zahlungsbedingungen. Für die von Ihnen oder dritten entwickelte Treiberimplementierung übernimmt Phoenix Contact keinerlei Haftung.
  • Seite 21 Kapitel Dieses Kapitel informiert Sie über – die PCI-Register, – das Host-Interface und – das MPM der INTERBUS-Anschaltbaugruppen. Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen ......2-3 PCI-Register................2-4 Host-Interface der INTERBUS-Anschaltbaugruppen ....2-6 2.2.1 Hardware-Einstellungen der Anschaltbaugruppen ..2-6 2.2.2 I/O-Register..............2-8 Multi-Port-Memory (MPM)............2-16 2.3.1 Adressraum des MPM ..........2-19 2.3.2 Aufteilung des SRAM im MPM........2-20 2.3.3...
  • Seite 22 6189A...

  • Seite 23: Aufbau Und Schnittstellen Der Interbus-Anschaltbaugruppen

    Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Die Anschaltbaugruppen werden über den PCI-Stecker direkt mit dem Host-System verbunden. Dieses Hardware-Interface umfasst (gemäß der PCI-Bus-Spezifikation 2.2) einen 32 Bit breiten Adress- und Datenbus. Es beinhaltet neben den Adress- und Datenleitungen weitere Steuerleitungen. Die Anschaltbaugruppen unterstützen den Interrupt-Betrieb.

  • Seite 24: Pci-Register

    IBS PCI DDK UM PCI-Register Die PCI-Register integrieren die Anschaltbaugruppen in ein PCI-Bus- System. Folgende Tabelle zeigt die Anordnung der PCI-Register sowie deren baugruppenspezifische Einstellungen. Tabelle 2-1 PCI-Register Device ID Vendor ID (0002 für IBS PCI SC...) (1442 für Phoenix Contact)
  • Seite 25 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Die Revision-ID gibt die Hardware-Revision der Anschaltbaugruppe an. Der Class Code 0C kennzeichnet einen „Serial bus controller“. Die PCI-Schnittstelle benutzt zwei Basisadress-Register: Das Basisadress-Register 0 enthält die I/O-Adresse für das Host-Inter- face-Register. Die Länge des I/O-Adressbereichs beträgt 16 Byte. Das Basisadress-Register 1 wird für den MPM-Adressraum des Masters und des NV-RAMs genutzt.

  • Seite 26: Host-Interface Der Interbus-Anschaltbaugruppen

    IBS PCI DDK UM Host-Interface der INTERBUS-Anschaltbaugruppen Das Host-Interface bildet die Schnittstelle zwischen dem Host-System und dem MPM der Anschaltbaugruppe. Dazu enthält das Host-Interface meh- rere Register. 2.2.1 Hardware-Einstellungen der Anschaltbaugruppen Die IBS PCI-Anschaltbaugruppen besitzen DIP-Schalter zur Einstellung der Anschaltbaugruppen-Nummer (Board-Number) und des Testbetriebes (on/off).
  • Seite 27 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Board-Number Mit den DIP-Schaltern 1 bis 3 wird die Anschaltbaugruppen-Nummer (Board-Number) vorgegeben. Tabelle 2-2 zeigt mögliche Einstellungen: Tabelle 2-2 Einstellungen möglicher Anschaltbaugruppen-Nummern Board-Number DIP-Schalter 1 DIP-Schalter 2 DIP-Schalter 3 Testbetrieb Befindet sich der DIP-Schalter 8 in der Stellung ON, wird die Anschaltbau- gruppe nach dem Hochlauf automatisch in den Testbetrieb wechseln und dabei einen eventuell angeschlossenen Bus aufschalten.

  • Seite 28: I/O-Register

    IBS PCI DDK UM 2.2.2 I/O-Register Die Anschaltbaugruppe belegt 16 I/O-Adressen des Host-Systems. Die er- sten acht Adressen sind mit Steuerregistern belegt, die sowohl gelesen als auch beschrieben werden können. Im Anschluss an die Steuerregister fol- gen die I/O-Register der direkten Ein- und Ausgänge.
  • Seite 29 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.2.2.1 Board_Number Bild 2-3 Aufbau des Board_Number-Registers Lesezugriff Das Board_Number-Register liest die über die DIP-Schalter 1 bis 3 aktuell eingestellte Anschaltbaugruppen-Nummer (Board_Number) aus. Reser- vierte Bits werden mit einer „0“ zurückgemeldet. 2.2.2.2 IRQ_Control_Host Bild 2-4 Aufbau des IRQ_Control_Host-Registers Schreibzugriff Im IRQ_Control_Host-Register wird die Interrupt-Request-Leitung, die...
  • Seite 30 IBS PCI DDK UM 2.2.2.3 WDT_Control_Host Schreibzugriff Mit dem WDT_Control_Host-Register kann der Watchdog-Timer des Host- Interfaces eingeschaltet, betrieben und wieder zurückgesetzt werden. Die reservierten Bits müssen den Wert „0“ enthalten. Bild 2-5 Aufbau des WDT_Control_Host-Registers bei einem Schreibzugriff Das Setzen des WDT_Enable-Bits schaltet den Watchdog-Timer ein. Die- ser Timer läuft, bis er aktiv oder durch einen Hardware-Reset des Host-Sy-...
  • Seite 31 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Im WDT_Interval (Datenbits 2 bis 4) können folgende Überwachungszei- ten eingestellt werden: Tabelle 2-4 WDT_Interval Überwachungszeit 8,2 ms 16,4 ms 32,8 ms 65,5 ms 131,1 ms 262,1 ms 524,3 ms 1048,6 ms Lesezugriff Bild 2-6 Aufbau des WDT_Control_Host-Registers bei einem Lesezugriff Während eines Lesezugriffs zeigt das WDT_Enable-Bit an, ob der Watch-...
  • Seite 32 IBS PCI DDK UM vorbestimmten Zeit nicht zurückgesetzt. In diesem Fall wird der Interrupt SRQ2L(0) generiert. Die LED HF auf der Anschaltbaugruppe signalisiert einen Sysfail des Host-Systems. Dieses Bit bleibt gesetzt, bis WDT_Clear gesetzt oder der Timer neu gestartet wird. Das eingestellte Zeitintervall WDT_Interval lässt sich zurücklesen.
  • Seite 33 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Lesezugriff Bild 2-8 Aufbau des Reset_Control_Host-Registers bei einem Lesezugriff Während des Lesezugriffs zeigt das Datenbit D0 an, dass der Master sich gerade im Selbsttest befindet und deshalb das MPM nicht freigeben kann. Wird das Bit auf „0“ gesetzt, ist der Master wieder betriebsbereit. 2.2.2.5 Status Schreibzugriff...
  • Seite 34 IBS PCI DDK UM Lesezugriff Bild 2-10 Aufbau des Status-Registers bei einem Lesezugriff Die Bits Sysfail und MPM_ReadyL können zurückgelesen werden. Alle an- deren Bits sind reserviert und werden mit einer „0“ zurückgemeldet. 2.2.2.6 Direct_IN Lesezugriff Bild 2-11 Aufbau des Direct_IN-Registers Der Status der direkten Eingänge kann über dieses Register zurückgele-...
  • Seite 35 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.2.2.7 Direct_OUT Bild 2-12 Aufbau des Direct_OUT-Registers Schreibzugriff Über dieses Register lassen sich die direkten Ausgänge setzen. Lesezugriff Die direkten Ausgänge können auch zurückgelesen werden. 2-15 6189A...

  • Seite 36: Multi-Port-Memory (Mpm)

    IBS PCI DDK UM Multi-Port-Memory (MPM) Das Multi-Port-Memory (MPM) ist neben dem INTERBUS-Master und dem Host-Interface ein zentraler Bestandteil der INTERBUS-Anschaltbaugrup- pen. Wie oben bereits beschrieben erfolgt über das MPM der gesamte Informationsaustausch zwischen Host-System und INTERBUS-Master. Bild 2-13 Das MPM als zentrale Schnittstelle der Anschaltbaugruppe Die MPM-Steuerlogik sorgt nach Prioritäten gestaffelt für die Zugriffsver-...
  • Seite 37 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Neben den Hardware-Registern befinden sich im MPM noch eine Reihe von Software-Registern, die speziell zur Steuerung der Kommunikation per Mailbox zwischen den einzelnen Teilnehmern verwendet werden. Umfang und Lage dieser Register ist nicht durch die Hardware vorgegeben. Funktionell setzt sich das MPM damit aus Anwendersicht aus folgenden Komponenten zusammen: –...
  • Seite 38 IBS PCI DDK UM len und Registern, die für jeden Node einzeln ausgeführt sind, unterschie- den. In jedem Fall steht aber allen Nodes die gleiche Anzahl von Registern an den gleichen Adressen zur Verfügung. Serieller Datenkanal An den seriellen Datenkanal des MPM lassen sich Schieberegister zur Ein- und Ausgabe und ein serielles EEPROM anschließen.

  • Seite 39: Adressraum Des Mpm

    Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.1 Adressraum des MPM Bild 2-14 Adressraum des MPM Die Diagnose-Register finden Sie beispielsweise auf folgenden Adressen: Register Adresse Diagnose-Statusregister 3520 Diagnose-Parameterregister 3522 erw. Diagnose-Parameterregister 37E6 Slave-Diagnose-Statusregister 37EC Weitere Informationen zu den Diagnose-Registern finden Sie im Anwen- derhandbuch Dienste und Fehlermeldungen der Firmware, IBS SYS FW G4 UM, Art.-Nr.

  • Seite 40: Aufteilung Des Sram Im Mpm

    IBS PCI DDK UM 2.3.2 Aufteilung des SRAM im MPM Das SRAM befindet sich im MPM ab der Adresse 0000 bis zur Adresse FFFF Bild 2-15 Aufteilung des SRAM Die Beschreibung des MPM erfolgt in diesem Dokument allgemeingültig, d. h. es werden Register und MPM-Funktionen eines vollständigen MPMs mit vier Teilnehmern beschrieben.

  • Seite 41: Kommunikationsmöglichkeiten Des Mpm

    Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.3 Kommunikationsmöglichkeiten des MPM Das MPM dient dem Austausch von Informationen zwischen den Teilneh- mern (Nodes). Diese Kommunikation kann mit dem Austausch von Daten verbunden sein oder aus der Mitteilung eines Ereignisses (Event) beste- hen. Beide Möglichkeiten werden vom MPM geboten und durch entspre- chende Mechanismen unterstützt.
  • Seite 42 IBS PCI DDK UM 2.3.3.1 Data-Interface (DTI) Über das Data-Interface findet der Austausch der Prozessdaten mit dem INTERBUS-Master statt. Innerhalb der Data-Area (DTA) sind verschiedene Bereiche definiert. Das Data-Interface (DTI) umfasst sowohl die „normale“ Data-Area, in der die Prozessdaten liegen, als auch die Extended-Data-Area in der anwender- spezifische Daten abgelegt werden können.
  • Seite 43 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen – Status-Register 1 – Handshake-Register A / Handshake-Register B – Send-Vector- und Acknowledge-Vector-Register (Software-Register) Eine detaillierte Beschreibung des Mailbox-Interfaces und des verwende- ten Handshake-Protokolls finden Sie im Kapitel 4, „Kommunikation über das Mailbox-Interface“. 2.3.3.3 Sys-Fail-Request Über die Sys-Fail-Logik können schwere Systemfehler umgehend den an- deren Nodes mitgeteilt werden.

  • Seite 44: Mpm-Hardware-Register

    IBS PCI DDK UM 2.3.4 MPM-Hardware-Register Die Hardware-Register des MPM sind im SRAM-Adressbereich des MPM eingeblendet und befinden sich im Bereich 3F90 bis 3FFF . Es wird bei den Hardware-Registern unterschieden zwischen Schreib- und Lese- Registern. Schreib-Register Bei den Schreib-Registern handelt es sich um Wort-Register, die Informa- tionen und Aktionen weitergeben bzw.
  • Seite 45 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Tabelle 2-6 Adressen der Schreib-Register im MPM Adresse Register Seite Adresse Register Seite 3FAE Clear Status Bit 3 2-34 3FE4 Set HS B1 2-37 3FB0 Set MPM Node SG Int 0 2-38 3FE6 Set HS B9 2-37 3FB2 Set MPM Node SG Int 1...
  • Seite 46 IBS PCI DDK UM 2.3.4.1 MPM-Configuration-Register Das MPM-Configuration-Register wird zur Erkennung der Konfiguration der Baugruppe durch die Nodes verwendet. Das Register enthält Informa- tionenüber die Größe des MPM und den Zustand der Nodes. Bild 2-17 Bit-Belegung des MPM-Configuration-Registers (Adresse 3F90 MPM_Size Die Bits 14 und 15 im MPM-Configuration-Register zeigen die Größe des...
  • Seite 47 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.2 Status-Register 1 Das Status-Register 1 enthält Informationen über den Status der einzelnen Nodes. Es beinhaltet vier Bits für jeden Node: Node 0: Bit 12 - Bit 15 Node 1: Bit 8 - Bit 11 Node 2: Bit 4 - Bit 7 Node 3:...
  • Seite 48 IBS PCI DDK UM HS_Int_x Ein gesetztes Bit HS_Int_x im Status-Register 1 zeigt dem Node an, dass für ihn eine Nachricht im MPM bereit steht (siehe Kapitel 4, „Kommunika- tion über das Mailbox-Interface“). Das Bit kann im Polling-Betrieb oder in...
  • Seite 49 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.3 Status-Register 2 Das Status-Register 2 enthält weitere Informationen über den Status der einzelnen Nodes. Für jeden Node sind vier Bits im Register vorgesehen: Node 0: Bit 12 - Bit 15 Node 1: Bit 8 - Bit 11 Node 2: Bit 4 - Bit 7 Node 3:...
  • Seite 50 IBS PCI DDK UM 2.3.4.4 Set-MPM-Node-Ready-x-Register Das Beschreiben eines Set-MPM-Node-Ready-x-Registers mit dem Wert 8000 (höchstwertiges Bit = 1) bewirkt, dass im MPM-Status-Register 1 das entsprechende Bit MPM_Node_Ready_x gesetzt wird. Zurückgesetzt wird das Bit durch Beschreiben des Registers mit dem Wert 0000 (höchstwertiges Bit = 0).
  • Seite 51 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.5 Set-MPM-Node-Par-Ready-x-Register Nach der erfolgreichen Parametrierung eines Node setzt dieser das ent- sprechende Bit MPM_Node_Par_Ready_x im MPM-Configuration-Regi- ster. Dazu ist das Set-MPM-Node-Par-Ready-x-Register mit einem Wert zu beschreiben, dessen höchstwertiges Bit gesetzt ist, z. B. mit dem Wert 8000 .
  • Seite 52 IBS PCI DDK UM 2.3.4.6 Status-Sysfail-Register Im Status-Sys-Fail-Register ist zu erkennen, welcher Node einen System- fehler gemeldet hat (Bit = 1: Systemfehler des Teilnehmers). Die Bits im Register geben den Zustand der entsprechenden Sys-Fail-Leitung wieder. Bild 2-22 Bitbelegung des Status-Sys-Fail-Registers...
  • Seite 53 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.7 Set-Sys-Fail-Request-Register Das Sys-Fail-Signal kann auf zwei unterschiedliche Arten generiert wer- den, zum einen durch ein Hardware-Signal an der MPM-Steuerlogik und zum anderen softwareseitig durch Beschreiben des Set-Sys-Fail-Request- Registers. Wie bei anderen Registern auch, bewirkt ein Schreiben mit ge- setztem Bit 15 (höchstwertiges Bit) das Auslösen des Signals.
  • Seite 54 IBS PCI DDK UM 2.3.4.8 Clear-Status-Bit-x-Register Die Clear-Status-Bit-x-Register dienen dem Zurücksetzen bestimmter Si- gnale, die zwischen den Nodes gesendet werden. Jeder Node hat ein ei- genes Clear-Status-Bit-x-Register, d. h. bei einem vollständigen MPM gibt es vier Clear-Status-Bit-x Register. Bild 2-24...

  • Seite 55: Handshake-Register A Und Handshake-Register B

    Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.9 Handshake-Register A und Handshake-Register B Zum Austausch quittierter Nachrichten zwischen den Nodes sind 32 Hand- shake-Bits definiert. Die Handshake-Bits dienen dem Mailbox-Handshake- Protokoll zum Senden, Empfangen und Quittieren der Nachrichten zwi- schen den Nodes. Durch Auswerten der Handshake-Register A und B kann ein Node feststel- len, welcher andere Node welchen Handshake-Interrupt ausgelöst hat.
  • Seite 56 IBS PCI DDK UM Bild 2-26 Bitbelegung des Handshake-Registers B (Adresse 3FC2 2-36 6189A...
  • Seite 57 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.10 Set-HS-Ax- und Set-HS-Bx-Register Verwendung finden diese insgesamt 32 Register bei der Realisierung des Mailbox-Handshake-Protokolls. Die Zuordnung und jeweilige Bedeutung der Register ist beim Mailbox-Handshake-Protokoll detailliert beschrieben. Das Beschreiben eines Set-HS-Ax/Bx-Registers mit gesetztem Bit 15 (Bit = 1) führt dazu, dass beim korrespondierenden Node ein Interrupt aus- gelöst wird, das Bit HS_INT_x im Status-Register 1 auf "1"...
  • Seite 58 IBS PCI DDK UM 2.3.4.11 Set-MPM-Node-SG-Int-x-Register Mit Hilfe der Set-MPM-Node-SG-Int-x-Register kann ein Signal (Interrupt) an beliebige andere Nodes gesendet werden. Die Bedeutung dieses Si- gnals liegt beim Anwender und ist nicht weiter vorgegeben. Jeder Node hat entsprechend seiner Teilnehmernummer ein eigenes Register, das er ver- wenden muss (Node 1 hat zum Beispiel das Set-MPM-Node-SG-Int-1-Re- gister zu verwenden).
  • Seite 59 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Das Zurücksetzen der Bits im Status-Node-SG-Int-x-Register und das Lö- schen der Interrupt-Anforderung erfolgt durch Beschreiben der Bitposition des gewünschten Nodes mit zurückgesetztem Bit (Bit = 0). Tabelle 2-14 Zuordnung der Registerbits zu den Nodes Ausgeführte Funktion Bit 15 = 1 Signal an Node 0 Bit 14 = 1...
  • Seite 60 IBS PCI DDK UM 2.3.4.12 Status-Node-SG-Inf-Register Im Status-Node-SG-Inf-Register (Status-Node-Signal-Interface-Register) kann aufgrund der gesetzten Bits erkannt werden, welcher Node an wel- che(n) anderen Node(s) das MPM-Node-SG-Int-Signal gesendet hat. Bild 2-29 Bitbelegung des Status-Node-SG-Inf-Registers (Adresse 3FB4 In Bild 2-29 haben die Datenbits die Bezeichnung "Node-SG-Int-x-y". Hier- bei bezeichnet "y"...
  • Seite 61 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.13 Set-Sync-Register Mit dem Set-Sync-Register kann ein weiteres Signal (Interrupt) an belie- bige andere Nodes gesendet werden. Die Bedeutung dieses Signals liegt beim Anwender und ist nicht weiter vorgegeben. Ein möglicher Anwen- dungsfall ist, wie bereits durch die Bezeichnung angedeutet, die Synchro- nisation beim Datenaustausch zwischen den Nodes.
  • Seite 62 IBS PCI DDK UM Sync_Req_Bit_x Nodes, an die ein Signal gesendet werden soll, werden durch das Bitmu- ster, das sich in den vier höchstwertigen Bits des Registers befindet, aus- gewählt. Ein gesetztes Bit (Bit = 1) bewirkt, dass beim entsprechenden Node ein Sync-Interrupt ausgelöst und das zugehörige Bit im Status-Regi-...
  • Seite 63 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.15 Read-Memory-Page-Register Wie oben bereits beschrieben wurde, ist der Adressraum des MPM ober- halb der Adresse FFFF zwischen mehreren Pages umschaltbar. Das Read-Memory-Page-Register zeigt für jeden Node an, welche Page mo- mentan eingeblendet ist. Das Einblenden der Pages kann von jedem Node individuell vorgenommen werden.
  • Seite 64 IBS PCI DDK UM Folgende Serial-Adress-Register stehen zur Verfügung: Tabelle 2-16 Serial-Adress-Register Adresse Register Seite 0002 Configuration Data 2-46 Im Serial-Adress-Register ist (wird) nur die Adresse des Registers einge- tragen. Der Wert des im Serial-Adress-Register eingetragenen Registers steht im Serial-Data-Register (siehe Seite 2-44).
  • Seite 65 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.4.18 Program-Bits-Register Das Program-Bits-Register ist ein Schreib-Register, dessen vier höchst- wertige Bits festlegen, welcher Zugriff auf den seriellen Datenkanal erfol- gen soll. Bild 2-35 Bitbelegung des Program-Bits-Registers (Adresse 3FA2 Tabelle 2-17 Bedeutung der Bits Ausgeführte Funktion Bit 15 = 1 Daten von Serial-In einlesen Bit 14 = 1...
  • Seite 66 IBS PCI DDK UM 2.3.4.19 Ready-Bits-Register Das Ready-Bits-Register ist ein Lese-Register, dessen Bits anzeigen, wel- che Zugriffe auf die serielle Schnittstelle des MPM (z. B. serielles EEPROM) abgeschlossen wurden. Unterschieden wird dabei zwischen Zugriffen auf das EEPROM und die Serial-In/Out-Schnittstelle. Jedes ge- setzte Bit (Bit = 1) zeigt an, dass der Zugriff abgeschlossen wurde.
  • Seite 67 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Write_Protected Zeigt an, ob der Schreibschutz einer Speicherkarte eingeschaltet ist. Bit 1 = 1: Schreibschutz aktiv Bit 1 = 0: Schreibschutz deaktiviert Ready/Busy Zeigt an, ob ein Schreibzugriff auf eine Speicherkarte beendet ist. Bit 2 = 1: Zugriff beendet (RDY) Bit 2 = 0: Zugriff noch nicht beendet (BSY)

  • Seite 68: Mpm-Software-Register

    IBS PCI DDK UM 2.3.5 MPM-Software-Register Neben den Hardware-Registern existieren im MPM eine Reihe von Soft- ware-Registern, deren Bedeutung und Funktion in engem Zusammenhang mit dem INTERBUS-Master bzw. dem Mailbox-Handshake-Protokoll steht. Anzahl und Lage dieser Register ist ebenfalls nicht durch die Hardware vorgegebenen, sondern durch eine Einteilung seitens des INTERBUS- Masters realisiert ist.
  • Seite 69 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen Sub-Node-Register Der Sub-Node stellt eine Möglichkeit zur zusätzlichen Adressierung von unterschiedlichen Anwendungen eines Nodes dar. 2.3.5.1 Aufbau des MPM-Deskriptors Der MPM-Deskriptor wird vom MPM-Manager für jeden Node generiert und im MPM hinterlegt. Anhand der Steckplatznummer bestimmt jeder Node, wo der für ihn gültige MPM-Deskriptor abgelegt ist.
  • Seite 70 IBS PCI DDK UM Realisierung des MPM-Deskriptors: typedef struct { /* Startadresse der Data-Area USIGN16 startAddrDTA; /* Größe der Data-Area in Bytes USIGN16 lengthDTA; /* Startadresse der Extended-Data-Area USIGN16 startAddrExDTA; /* Größe der Extended-Data-Area USIGN16 lengthExDTA; /* Startadresse der Mailbox-Area USIGN16 startAddrMXA;...
  • Seite 71 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen MPM Descriptor Node 0 (3440 startAddrDTA 0000 -> length 1024 startAddrExDTA 5C00 -> length 5120 startAddrMXA 4000 -> length 7168 data[0][0] startAddrDTA FFFF -> length 0000 data[0][1] startAddrDTA 0000 -> length 1024 data[0][2] startAddrDTA 0000 -> length 1024 data[0][3] startAddrDTA 0000 ->...
  • Seite 72 IBS PCI DDK UM MPM Descriptor Node 1 (378A startAddrDTA 1000 -> length 1024 startAddrExDTA 8C00 -> length 5120 startAddrMXA 7000 -> length 7168 data[0][0] startAddrDTA 1000 -> length 0000 data[0][1] startAddrDTA FFFF -> length 1024 data[0][2] startAddrDTA 0400 -> length 1024 data[0][3] startAddrDTA 1C00 ->...

  • Seite 73: Dta, Extended-Dta Und Mxa

    Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.5.2 DTA, Extended-DTA und MXA Für die drei Bereiche Data-Area, Extended-Data-Area und Mailbox-Area sind jeweils die Anfangsadresse und die Größe in Bytes eingetragen. In- nerhalb dieser Bereiche besitzt der zugehörige Node das Schreibrecht. Die Data-Area ist nochmals in kleinere Bereich unterteilt, die zur Kommu- nikation mit den anderen Nodes vorbestimmt sind.
  • Seite 74 IBS PCI DDK UM 2.3.5.3 Send-Vector-Register (SVR) Bei den Send-Vector- und Acknowledge-Vector-Registern handelt es sich um Software-Register mit einer Datenwortbreite von 16 Bit. Verwendung finden diese Register bei der Kommunikation über das Mailbox-Interface. In das Send-Vector-Register (SVR) wird die Adresse (Offset) der Mailbox im MPM, welche die eigentliche Nachricht enthält, eingetragen.
  • Seite 75 Aufbau und Schnittstellen der INTERBUS-Anschaltbaugruppen 2.3.5.4 Acknowledge-Vector-Register (AVR) Bei den Acknowledge-Vector-Registern handelt es sich ebenfalls um Soft- ware-Register mit einer Datenwortbreite von 16 Bit. Verwendung finden diese Register bei der Kommunikation über das Mailbox-Interface. Das AVR enthält die Adresse einer Mailbox im MPM, die vom Kommunikations- partner ausgelesen wurde, und damit wieder freigegeben werden kann.
  • Seite 76 IBS PCI DDK UM 2.3.5.5 Sub-Node-Register (SNR) Die Sub-Node-Register werden nur benötigt, wenn z. B. ein INTERBUS- Master und ein INTERBUS-Slave auf demselben Node (MPM-Steckplatz) arbeiten. In diese Register werden dann Informationen hinterlegt, an wel- che Anschaltbaugruppe (INTERBUS-Master oder INTERBUS-Slave) die Nachricht gesendet werden soll.
  • Seite 77 Kapitel Dieses Kapitel informiert Sie über – den Datenaustausch über die Data-Area (DTA). Datenaustausch über die Data-Area ..............3-3 Betriebsarten................3-5 3.1.1 Asynchroner Betrieb ............3-5 3.1.2 Asynchroner Betrieb mit Synchronisationsimpuls..3-5 6189A...
  • Seite 78 6189A...

  • Seite 79: Datenaustausch Über Die Data-Area

    Datenaustausch über die Data-Area 3 Datenaustausch über die Data-Area Die Data-Area (DTA) dient dem einfachen Austausch von Daten über das MPM. Wie oben bereits erwähnt, hat jeder Node nur innerhalb seiner Data- Area bzw. Extended-Data-Area Schreibrechte, d. h. der sendende Node schreibt die Daten innerhalb seiner DTA in einen bestimmten Bereich und der empfangende Node liest die Daten dort aus.
  • Seite 80 IBS PCI DDK UM Abhängig vom Zugriff (lesend oder schreibend) wird auf unterschiedliche Bereiche (Blöcke) im MPM zugegriffen. Ein schreibender Zugriff erfolgt immer in den Bereich des schreibenden Nodes, d. h. wenn der Node 0 Daten an den Node 2 übergeben will, schreibt er die Daten in seinen eige- nen Bereich.

  • Seite 81: Betriebsarten

    Datenaustausch über die Data-Area Betriebsarten 3.1.1 Asynchroner Betrieb Ein Node greift asynchron zu den INTERBUS-Datenzyklen auf die in der DTA abgelegten E/A-Daten zu. Das heißt, ein Datenblock wird während des Lesens (Node n) von Node 1(Master-Firmware) bereits wieder be- schrieben. Der Lesende erhält somit Daten aus zwei verschiedenen Schreibzyklen.

  • Seite 82: Asynchron Mit Synchronisationsimpuls (Implementierung Im Treiber)

    IBS PCI DDK UM 3.1.2.1 Asynchron mit Synchronisationsimpuls (Implementierung im Treiber) Im Treiber sind jeweils 3 Buffer (IN und OUT) implementiert, die sicherstel- len, dass ein Zugriff der Applikation, der immer asynchron ist, auf den ak- tuellsten IN-Buffer und auf den nächsten freien OUT-Buffer stattfindet.
  • Seite 83 Datenaustausch über die Data-Area Bild 3-4 Asychroner, konsistenter Zugriff der Applikation auf die INTERBUS-Daten 6189A...
  • Seite 84 IBS PCI DDK UM 6189A...
  • Seite 85 Kapitel Dieses Kapitel informiert Sie über – den Datenaustausch über die Mailbox-Schnittstelle (MXI). Kommunikation über das Mailbox-Interface ............4-3 6189A...
  • Seite 86 6189A...

  • Seite 87: Kommunikation Über Das Mailbox-Interface

    Kommunikation über das Mailbox-Interface 4 Kommunikation über das Mailbox-Interface Der Austausch von Nachrichten (Kommandos und Meldungen) zwischen den einzelnen Nodes erfolgt in der Regel über die Mailbox-Schnittstelle (MXI). Es handelt sich um einen gerichteten Austausch von Nachrichten zwischen zwei Nodes (peer to peer). Von jedem Node kann an jeden an- deren Node eine Nachricht gesendet werden.
  • Seite 88 IBS PCI DDK UM Zuordnung der einzelnen Bits der Handshake-Register A und B bzw. der 32 Set-HS-Ax/Bx-Register zu den einzelnen Nodes und ihre Bedeutung: Bild 4-1 Zuordnung der Handshake-Bits Legende zu Bild 4-1: Source Node, der eine Nachricht senden will...
  • Seite 89 Kommunikation über das Mailbox-Interface exakt bestimmt werden. Weiterhin zeigen die Bits in den beiden Registern an, ob ein Send-Vector- bzw. Acknowledge-Vector-Register belegt (Bit = 1) oder frei (Bit = 0) ist. Send-Vector- In das Send-Vector-Register wird die Adresse (Offset) der Mailbox im Register (SVR) MPM, welche die eigentliche Nachricht enthält, eingetragen.
  • Seite 90 IBS PCI DDK UM Vier signifikante Punkte kennzeichnen das hierzu verwendete Mailbox- Handshake-Protokoll: 1. „Nachricht vorhanden“: Node 0 setzt das Bit HS_A8 (Bedeutung: Nachricht vorhanden; Source = Node 0; Destination = Node 1). Damit wird angezeigt, dass eine Nachricht von Node 0 an Node 1 vorhanden ist. Die Adresse der Nach- richt ist von Node 0 zuvor in das zugehörige Send-Vector-Register...
  • Seite 91 Kommunikation über das Mailbox-Interface Detaillierter Ablauf beim Übertragen einer Nachricht von Node 0 an Node 1: Node 0 1. Node 0 prüft, ob das Send-Vector-Register „SVR [0] [1]“ frei ist. Dazu liest er das MPM-Handshake-Register A aus und prüft, ob das Bit HS_A8 gleich Null ist.
  • Seite 92 IBS PCI DDK UM Node 0 (Interrupt- 1. Node 0 erkennt anhand des gesetzten Bits HS_Int_0 im Status-Regi- Routine) ster 1, dass die Ursache des Interrupts ein Mailbox-Handshake-Proto- koll-Interrupt ist. 2. Er liest das Handshake-Register A aus, um festzustellen welcher Node den Interrupt auslöste.
  • Seite 93 Kommunikation über das Mailbox-Interface 1. „Nachricht vorhanden“: Node 1 setzt das Bit HS_A1 (Bedeutung: Nachricht vorhanden; Source = Node 1; Destination = Node 0). Damit wird angezeigt, dass eine Nachricht von Node 1 an Node 0 vorhanden ist. Die Adresse der Nach- richt ist von Node 1 zuvor in das zugehörige Send-Vector-Register (SVR[1][0]) eingetragen worden.
  • Seite 94 IBS PCI DDK UM Detaillierter Ablauf beim Übertragen einer Nachricht von Node 1 an Node 0: Node 1 1. Node 1 prüft, ob das Send-Vector-Register SVR[1][0] frei ist. Dazu liest er das MPM-Handshake-Register A aus und prüft, ob das Bit HS_A1 gleich Null ist.
  • Seite 95 Kommunikation über das Mailbox-Interface Node 1 (Interrupt- 1. Node 1 erkennt anhand des gesetzten Bits HS_Int_1 im Status-Regi- Routine) ster 1, dass die Ursache des Interrupts ein Mailbox-Handshake-Proto- koll-Interrupt ist. 2. Er liest das Handshake-Register A aus, um festzustellen welcher Node den Interrupt auslöste.
  • Seite 96 IBS PCI DDK UM 4-12 6189A...
  • Seite 97 Kapitel Dieses Kapitel informiert Sie – über den grundsätzlichen Aufbau eines Gerätetreibers und – die zur Erstellung notwendigen Funktionen. Aufbau und Struktur eines Gerätetreibers ............5-3 Allgemeines.................5-3 Grundsätzlicher Aufbau des Treibers..........5-4 Beschreibung der Funktionen .............5-8 5.3.1 Initialisierung (initBoard) ..........5-10 5.3.2 Datenkanal öffnen (openDevice) .........5-11 5.3.3 Datenkanal schließen (closeDevice)......5-12 5.3.4...
  • Seite 98 6189A...

  • Seite 99: Aufbau Und Struktur Eines Gerätetreibers

    Aufbau und Struktur eines Gerätetreibers 5 Aufbau und Struktur eines Gerätetreibers In den bisher aufgeführten Kapiteln erfolgte ausschließlich eine Beschrei- bung der verwendeten Hardware. Nachfolgend soll die Grundstruktur einer Treiber-Software für die IBS PCI-Anschaltbaugruppen exemplarisch be- schrieben werden. Die dabei realisierte Schnittstelle entspricht dem spezi- fizierten Device-Driver-Interface (DDI).

  • Seite 100: Grundsätzlicher Aufbau Des Treibers

    IBS PCI DDK UM Grundsätzlicher Aufbau des Treibers Ein Gerätetreiber für die INTERBUS-Anschaltbaugruppen basiert für alle von Phoenix Contact unterstützten Betriebssysteme auf sieben elementa- ren Funktionen: – DDI_DevOpenNode (openDevice) – DDI_DevCloseNode (closeDevice) – DDI_DTI_WriteData (readDTI) – DDI_DTI_ReadData (writeDTI) – DDI_MXI_SndMessage (writeMXI) –...
  • Seite 101 Aufbau und Struktur eines Gerätetreibers Bild 5-1 Integration des Gerätetreibers in beliebige Betriebssysteme Es ist erkennbar, dass beim Gerätetreiber zwischen zwei Teilen unter- schieden werden kann: – dem eigentlichen Treiber mit seinen Funktionen zum Zugriff auf die Hardware (dieser Teil kann vollständig in den Betriebssystem-Kern in- tegriert sein) und –...
  • Seite 102 IBS PCI DDK UM Bei einer Portierung auf Betriebssysteme wie z. B. UNIX kann die Biblio- thek mit den Funktionsaufrufen entsprechend der DDI-Spezifikation eine Anpassung an die Standard-Aufrufe („open“, „close“, „read“, „write“ usw.) enthalten (siehe Bild 5-2). Beispiel für die Integration in ein Betriebssystem wie z. B. UNIX Bild 5-2 Integration des Gerätetreibers unter UNIX...
  • Seite 103 Aufbau und Struktur eines Gerätetreibers Beispiel für die Integration in ein Betriebssystem wie z. B. Windows NT Bild 5-3 Integration des Gerätetreibers unter Windows NT 6189A...

  • Seite 104: Beschreibung Der Funktionen

    IBS PCI DDK UM Beschreibung der Funktionen Bevor in den weiteren Kapiteln näher auf jede dieser Funktionen eingegan- gen wird, sollen die grundsätzlichen Aufgaben kurz dargelegt werden: openDevice Öffnet einen Datenkanal zum Mailbox- oder Data-Interface. Der dabei er- haltene Node-Handle wird für alle weiteren Dienste benötigt.
  • Seite 105 Aufbau und Struktur eines Gerätetreibers Interrupt-Service- Die Interrupt-Service-Routine erledigt einen großen Teil der für das Mail- Routine box-Handshake-Protokoll notwendigen Aufgaben. Sie empfängt die Ereig- nisse „Nachricht vorhanden“ und „Mailbox frei“, d. h. sie führt somit auch die Mailbox-Verwaltung durch. Weiterhin empfängt die Interrupt-Service- Routine die SysFail- und MPM-Node-SG-Int-x-Interrupts und führt für diese Ereignisse eine Vorverarbeitung durch.

  • Seite 106: Initialisierung (Initboard)

    IBS PCI DDK UM 5.3.1 Initialisierung (initBoard) Die Initialisierung ist abhängig vom verwendeten Betriebssystem und er- folgt beim Starten des Rechners bzw. des Betriebssystems. Sie kann aber auch während des Normalbetriebs erfolgen. In jedem Fall muss die Initia- lisierung erfolgreich abgeschlossen sein, bevor andere Treiberfunktionen von Anwendungsprogrammen aus nutzbar sind.

  • Seite 107: Datenkanal Öffnen (Opendevice)

    Aufbau und Struktur eines Gerätetreibers 5.3.2 Datenkanal öffnen (openDevice) Mit der openDevice-Funktion wird ein Datenkanal zu einer bestimmten IBS PCI-Anschaltbaugruppe, einem bestimmten Node (Node 0 - Node 3) und einem bestimmten Interface (Data-Interface oder Mailbox-Interface) eingerichtet. Welche Anschaltbaugruppe, welcher Node und welches Inter- face angesprochen wird, ist durch den Gerätenamen bestimmt.

  • Seite 108: Datenkanal Schließen (Closedevice)

    IBS PCI DDK UM Eine Auswahl der Fehlermeldungen finden Sie in der Datei „ddi_err.h“ auf der dem DDK beiliegenden Diskette mit den C-Sourcen. Der Node-Handle ist ein Index in das Array nodeHdCtrl (Datentyp T_NODE_HD_CTRL). Um nicht mit dem Indexwert Null beginnen zu müs- sen, wird auf den eigentlichen Indexwert ein fester Offset addiert.

  • Seite 109: Prozessdaten Schreiben (Writedti)

    Aufbau und Struktur eines Gerätetreibers 5.3.4 Prozessdaten schreiben (writeDTI) Mit Hilfe der writeDTI-Funktion werden Daten an die gewünschte Stelle in- nerhalb der Data-Area (DTA) des eigenen Nodes geschrieben (beim Host- System wäre das z. B. die Data-Area von Node 0). Die Data-Area ist bei der Firmware 4.xx auf eine maximale Größe von vier KByte begrenzt.

  • Seite 110: Prozessdaten Lesen (Readdti)

    IBS PCI DDK UM 5.3.5 Prozessdaten lesen (readDTI) Der Ablauf beim Lesen aus der Data-Area entspricht dem beim Schreiben in die DTA. Lediglich die Richtung des Datentransfers wird geändert. Mit Hilfe der readDTI-Funktion werden Daten aus der Data-Area (DTA) eines anderen oder auch des eigenen Nodes gelesen. Der Node-Handle bestimmt, von welchem Node gelesen wird.

  • Seite 111: Nachricht Senden (Writemxi)

    Aufbau und Struktur eines Gerätetreibers 5.3.6 Nachricht senden (writeMXI) Die writeMXI-Funktion dient dem Senden von Nachrichten an einen ande- ren beliebigen MPM-Teilnehmer. Im Gegensatz zum Schreiben in die DTA ist beim Übertragen der Nachricht ein bestimmtes Protokoll einzuhalten. Das hierbei verwendete Mailbox-Handshake-Protokoll wurde bereits in Kapitel 4, „Kommunikation über das Mailbox-Interface“...

  • Seite 112: Nachricht Auslesen (Readmxi)

    IBS PCI DDK UM – Ursprünglichen Inhalt der I/O-Register der Anschaltbaugruppe wieder- herstellen und die Funktion mit dem Rückgabewert ERR_OK beenden. Auf die Freigabe der Mailbox wird an dieser Stelle nicht gewartet, da diese Aufgabe von der Interrupt-Service-Routine übernommen wird. Die Freiga- be des Send-Vector-Registers braucht ebenfalls nicht abgewartet zu wer- den, da das zugehörige Bit im Handshake-Register vor dem Senden einer...
  • Seite 113 Aufbau und Struktur eines Gerätetreibers Wie auch bei den anderen Funktionen erfolgt vor dem Auslesen der Nach- richt eine Überprüfung der angegebenen Parameter (Node-Handle, Größe des Puffers für die Nachricht, usw.) sowie des Zustandes der Anschaltbau- gruppe: – Gültigkeit des Node-Handle, –...

  • Seite 114: Interrupt-Service-Routine (Intrservicefunction)

    IBS PCI DDK UM – Message-Counter in der Message-Kontrollstruktur msgCtrl dekremen- tieren. – Adresse der ausgelesenen Mailbox in das entsprechende Acknow- ledge-Vector-Register eintragen. – Durch Beschreiben des entsprechenden Set-HS-Ax/Bx-Registers das zugehörige Bit in einem der Handshake-Register setzen, und so dem sendenden Node anzeigen, dass die Mailbox wieder frei ist.

  • Seite 115: Device Io Control (Devioctrl)

    Aufbau und Struktur eines Gerätetreibers – Genaue Interrupt-Ursache feststellen: Sys-Fail-Interrupt: Welcher Node hat den Sys-Fail gemeldet? --> MPM-Status-Register auswerten MPM-Node-SG-Int-X Interrupt: Welcher Node hat den Interrupt ausge- löst? --> MPM-Status-Register 1auswerten Handshake Interrupt: Welcher Node hat den Interrupt ausgelöst? --> Handshake-Register auswerten, um festzustellen welcher Node was gemeldet hat („Nachricht vorhanden“...
  • Seite 116 IBS PCI DDK UM nen Utility-Funktionen (Watchdog freigeben, Watchdog triggern usw.). Der Vorteil dieser Methode liegt darin, dass nur eine Funktion für den Zugang zu den im INTERBUS-Master auszuführenden Aufgaben benötigt wird. Nutzung der devIOCtrl-Funktion für verschiedene Dienste: Bild 5-5 devIOCtrl-Funktion Als Parameter erhält die Funktion drei Werte:...

  • Seite 117: Hilfsfunktionen

    Aufbau und Struktur eines Gerätetreibers 5.3.10 Hilfsfunktionen Neben den Funktionen, die eine direkte Abbildung des DDI sind, existieren einige zusätzliche Hilfsfunktionen. Sie dienen dem Auslesen der Dia- gnose-Register, der Handhabung der Watchdog-Funktionen und dem Set- zen und Rücksetzen der Notification-Funktionen. Die eigentliche Aufgabe ergibt sich bereits aus dem Namen der Funktion.
  • Seite 118 IBS PCI DDK UM 5.3.10.1 GetIBSDiagnostic Aufgabe Die Funktion GetIBSDiagnostic() liest das Diagnose-Statusregister und das Diagnose-Parameterregister aus. Als Parameter erhält die Funktion einen gültigen Node-Handle und einen Zeiger auf eine Datenstruktur vom Typ T_IBS_DIAG. Nach einem erfolgreichen Aufruf der Funktion enthalten die Komponenten der Struktur den Inhalt des Diagnose-Statusregisters und des Diagnose-Parameterregisters.
  • Seite 119 Aufbau und Struktur eines Gerätetreibers 5.3.10.2 GetIBSDiagnosticEx Aufgabe Die Funktion GetIBSDiagnosticEx() liest das Diagnose-Statusregister und das Diagnose-Parameterregister aus. Sie dient zur Darstellung des Be- triebszustandes der INTERBUS-Anschaltbaugruppe bzw. des INTERBUS. Die Funktion entspricht der Funktion GetIBSDiagnostic(). Es ist jedoch das Strukturelement addInfo hinzugekommen (es handelt sich hierbei um ein Software-Register).
  • Seite 120 IBS PCI DDK UM 5.3.10.3 GetSlaveDiagnostic Aufgabe Die Funktion GetSlaveDiagnostic() liest das Slave-Diagnose-Statusregi- ster und das Slave-Diagnose-Parameterregister eines INTERBUS- Systemkopplers aus. Sie dient zur Darstellung des Betriebszustandes des Slave-Teils bzw. des daran angeschlossenen INTERBUS. Das Strukturelement diagPara ist zwar in der Struktur T_IBS_DIAG imple- mentiert, wird aber durch die Firmware der Anschaltbaugruppe momentan noch nicht ünterstützt!
  • Seite 121 Aufbau und Struktur eines Gerätetreibers 5.3.10.4 GetSysFailRegister Aufgabe Die Funktion GetSysFailRegister() schreibt in die durch den Parameter sysFailRegPtr referenzierte Variable den Inhalt des MPM-Sta- tus-Sys-Fail-Registers. Die Bits 0, 4, 8, und 12 des Registers zeigen an, ob das SysFail-Signal der Anschaltbaugruppe aktiviert ist oder nicht. Tritt bei einem der beiden Bits (8,12) eine Funktionsstörung auf (z.
  • Seite 122 IBS PCI DDK UM 5.3.10.5 EnableWatchDog Aufgabe Mit der Funktion DDI_EnableWatchDog() wird der Watchdog aktiviert. Nach dem Aktivieren muss der Watchdog in regelmäßigen Abständen zu- rückgesetzt werden (TriggerWatchDog). Ein aktivierter Watchdog kann nur durch Ausschalten des Host-Systems oder einen Hardware-Reset deaktiviert werden.
  • Seite 123 Aufbau und Struktur eines Gerätetreibers 5.3.10.7 GetWatchDogState Aufgabe Mit der Funktion GetWatchDogState() kann ausgelesen werden, ob der Watchdog ausgelöst hat (Return = 1) oder nicht (Return = 0). Dies ge- schieht durch Lesen des Watchdog-Register. Dabei wird auch der Watch- dog getriggert.
  • Seite 124 IBS PCI DDK UM 5.3.10.9 SetWatchDogTimeout Aufgabe Die Funktion SetWatchDogTimeout() setzt die „Watchdog-Timeout-Zeit“ und aktiviert den Watchdog. Nach dem Aktivieren muss der Watchdog in regelmäßigen Abständen zurückgesetzt werden (TriggerWatchDog). Eine einmal eingestellte „Watchdog-Timeout-Zeit“ kann nicht geändert werden. Ein aktivierter Watchdog kann nur durch Ausschalten des Host- Systems oder einen Hardware-Reset deaktiviert werden.

  • Seite 125: Verwendete Datenstrukturen

    Aufbau und Struktur eines Gerätetreibers 5.3.11 Verwendete Datenstrukturen Um ein besseres Verständnis für den Treiber und seinen Aufbau zu be- kommen, sollen an dieser Stelle alle verwendeten Datenstrukturen darge- stellt und erläutert werden. 5.3.11.1 T_DEV_CTRL devCtrl Diese Struktur enthält die für die gesamte Anschaltbaugruppe relevanten Parameter.
  • Seite 126 IBS PCI DDK UM devNameDTI: Zeiger auf zugehörigen Gerätenamen für das devNameMXI: Zeiger auf zugehörigen Gerätenamen für das curDTIOpenCnt: Anzahl der geöffneten Datenkanäle zum DTI maxDTIOpenCnt: Maximale Anzahl der Datenkanäle zum DTI curMXIOpenCnt: Anzahl der geöffneten Datenkanäle zum MXI maxMXIOpenCnt: Maximale Anzahl der Datenkanäle zum MXI...
  • Seite 127 Aufbau und Struktur eines Gerätetreibers 5.3.11.3 T_NODE_HD_CTRL nodeHdCtrl[ ] Entsprechend der Gesamtzahl der dem Anwender verfügbaren Node- Handle, sind Strukturen vom Datentyp T_NODE_HD_CTRL vorhanden. Die Anzahl kann den eigenen Erfordernissen angepasst werden. Die Strukturen werden beim Starten bzw. Laden des Treibers initialisiert. Wäh- rend des laufenden Betriebes werden sie beim Öffnen und Schließen der Datenkanäle belegt bzw.
  • Seite 128 IBS PCI DDK UM 5.3.11.5 T_MSG_CTRL msgCtrl[ ] Für jeden Node werden mit Hilfe dieser Struktur die ankommenden Nach- richten erfasst. In der vorliegenden Form kann mit dieser Struktur nur eine Nachricht erfasst werden. Da aber von jedem Node nur eine Mailbox ver- wendet wird, sind dadurch keine Probleme zu befürchten.
  • Seite 129 Aufbau und Struktur eines Gerätetreibers 5.3.11.8 CHAR devNamesDTI[ ][ ] Diese Struktur enthält die Strings aller gültigen Gerätenamen für das Data- Interface. Anhand der lokalen Node-Nummer werden die Gerätenamen für jeden Node bestimmt. Auf diese Strings verweisen die Zeiger der Daten- struktur nodeCtrl (Datentyp T_NODE_CTRL).
  • Seite 130 IBS PCI DDK UM 5-34 6189A...
  • Seite 131 Kapitel Dieses Kapitel informiert Sie über – Schritte zur Anpassung an Betriebssysteme ToDo (Anpassung an Betriebssysteme) ...............6-3 Dateistrukturen im Treiber............6-3 6189A...
  • Seite 132 6189A...

  • Seite 133: Todo (Anpassung An Betriebssysteme)

    ToDo (Anpassung an Betriebssysteme) 6 ToDo (Anpassung an Betriebssysteme) Dateistrukturen im Treiber Um einen Überblick über die Abhängigkeiten innerhalb des Treibers zu be- kommen wird hier exemplarisch der „Dateiweg“ für VxWorks beschrieben. Darüberhinaus ist für WindowsNT die Anpassung zu sehen, woraus er- sichtlich wird, welche Unterschiede sich bei verschiedenen Betriebssyste- men (OperationSystems) ergeben.
  • Seite 134 IBS PCI DDK UM Bild 6-1 Dateistrukturen im Treiber 6189A...
  • Seite 135 ToDo (Anpassung an Betriebssysteme) "OS?"sys.c Die Dateien "OS?"sys.c (ntsys.c, vxwsys.c sowie bald auch “IhrOS“sys.c) stellen die Schnittstelle zum jeweiligen Betriebssystem dar. Hier finden die Aufrufe der Systemfunktionen statt. Ebenso werden die Datenstrukturen an das Betriebssystem angepasst. Hier einige Funktionen, die in "OS?"sys.c bearbeitet werden: IBD_IoConnectInterrupt(PT_BOARD_INFO pBoardInfo);...
  • Seite 136 IBS PCI DDK UM Anhand der Funktion „ScanPciDevices“ soll hier das unterschiedliche Aus- lesen der erforderlichen Parameter verdeutlicht werden. Die fett/kursiv markierten Textstellen sind die Aufrufe der PCI-Systemfunktionen. Die Struktur „pPciInfo“ steht mit den entsprechend eingetragenen Daten dann den weiteren Funktionen zur Verfügung.
  • Seite 137 ToDo (Anpassung an Betriebssysteme) VxWorks: (vxwsys.c) void ScanPciDevices(PT_PCI_INFO PciInfo) … … for (bus = 0; bus < 3; bus++) for (sDeviceNo = 0; sDeviceNo < sDevices; sDeviceNo++) pciConfigInWord (bus, sDeviceNo, 0, PCI_CFG_VENDOR_ID, &vendorId); pciConfigInWord (bus, sDeviceNo, 0, PCI_CFG_DEVICE_ID, &deviceId); if (vendorId != 0xffff) if (vendorId == PCI_PHOENIX_VENDOR_ID) switch (deviceId) case PCI_PHOENIX_DEVICE_ID_SC:...
  • Seite 138 IBS PCI DDK UM Beispiel IhrOS: (“IhrOS”sys.c) void ScanPciDevices(PT_PCI_INFO PciInfo) … for (bus = 0; bus < 3; bus++) for (sDeviceNo = 0; sDeviceNo < sDevices; sDeviceNo++) vendorId = IhreFunktion(get PCI_Bus_Data.Vendor); /* Hier können z.B. alle Daten aufeinmal gelesen werden */ deviceId = IhreFunktion(get PCI_Bus_Data.Device);...
  • Seite 139 ToDo (Anpassung an Betriebssysteme) os_adapt.h Die hier definierten Pointer, Strukturen und Macros sind betriebssystemab- hängig. So sind z.B. die Byte-Lesezugriffe auf die IO-Ports in WindowsNT durch die Funktion „READ_PORT_UCHAR(addr)“ und in VxWorks durch „sysInByte(addr)“ realisiert. Hier ist die Funktion, die „IhrOS“ zur Verfü- gung stellt einzusetzen.
  • Seite 140 IBS PCI DDK UM #define IbsWriteIOPort(addr, dataByte) (sysOutByte((addr), (USIGN8)dataByte)) #define IbsWriteIOPort16(addr, dataByte) (sysOutWord((addr), (USIGN16) dataByte)) typedef USIGN32 NTSTATUS; Ihr OS: #ifdef IBS_ IhrOS_VERSION /* selects the “IhrOS”-funtionality */ typedef „IhrDatantyp“ T_BIN_SEMAPHORE; #define IbsReadIOPort(addr) („IhreReadIOPortFunktion“(addr))) Ihr os_inc.h Hier findet die „Verteilung“ auf die verschiedenen HeaderFiles, je nach Be- triebssystem statt.
  • Seite 141 ToDo (Anpassung an Betriebssysteme) VxWorks: #ifdef IBS_VXWORKS_VERSION /**/ #include <vxworks.h> #include <stddef.h> #include <config.h> #include <string.h> #include <stdio.h> #include <semLib.h> /*#include <vxcpu.h>*/ #ifdef PENTIUM #include "drv/pci/pciConfigLib.h" #include "drv/pci/pciConfigShow.h" #include "drv/pci/pciHeaderDefs.h" #else /* PENTIUM was not supported in VxWorks 3.5.1 (Tornado1) */ #include "drv/pci/pciIomapLib.h"...
  • Seite 142 IBS PCI DDK UM 6-12 6189A...
  • Seite 143 Anhang A A 1 Abbildungsverzeichnis Kapitel 1 Bild 1-1: Verzeichnisstruktur des Datenträgers ......1-4 Kapitel 2 Bild 2-1: Adressfenster der Anschaltbaugruppen im Host-System ..............2-3 Bild 2-2: Belegung der DIP-Schalter ..........2-6 Bild 2-3: Aufbau des Board_Number-Registers ......2-9 Bild 2-4: Aufbau des IRQ_Control_Host-Registers ....2-9 Bild 2-5: Aufbau des WDT_Control_Host-Registers bei einem Schreibzugriff ..........2-10...
  • Seite 144 Abbildungsverzeichnis Bild 2-17: Bit-Belegung des MPM-Configuration-Registers (Adresse 3F90 ) .............2-26 Bild 2-18: Bitbelegung des Status-Registers 1 (Adresse 3FB0 ) .............2-27 Bild 2-19: Bitbelegung des Status-Registers 2 (Adresse 3FB6 ) .............2-29 Bild 2-20: Bitbelegung der Set-MPM-Node-Ready-x-Register ...2-30 Bild 2-21: Bitbelegung der Set-MPM-Node-Par-Ready-x- Register ..............2-31 Bild 2-22: Bitbelegung des Status-Sys-Fail-Registers...
  • Seite 145 Abbildungsverzeichnis (Adresse 3FA2 ) .............2-45 Bild 2-36: Bitbelegung des Ready-Bits-Registers (Adresse 3FA2 ) .............2-46 Bild 2-37: Bitbelegung des Configuration-Data-Registers (Adresse 2) ..............2-46 Kapitel 3 Bild 3-1: Schreibender und Lesender Zugriff auf die DTA ..3-4 Bild 3-2: Asychroner Zugriff der Applikation auf die INTERBUS-Daten ............3-5 Bild 3-3: Asynchron mit Synchronisationsimpuls...
  • Seite 146 Abbildungsverzeichnis 6189A...
  • Seite 147 Anhang A A 2 Tabellenverzeichnis Kapitel 1 Tabelle 1-1: Inhalt der Verzeichnisse ..........1-4 Tabelle 1-2: Dateien im Verzeichnis „IBPCIMPM.SYS“....1-5 Tabelle 1-3: Dateien im Verzeichnis „IB_INC\SYS“ ......1-5 Tabelle 1-4: Dateien im Verzeichnis „IB_INC\USR“......1-6 Tabelle 1-5: Dateien im Verzeichnis „VXWORX\EXAMPLE“....1-6 Tabelle 1-6: Dateien im Verzeichnis „VXWORX\SYSTEM“...
  • Seite 148 Tabellenverzeichnis Tabelle 2-16: Serial-Adress-Register..........2-44 Tabelle 2-17: Bedeutung der Bits .............2-45 Tabelle 2-18: Board-Present-Bits .............2-47 Tabelle 2-19: Belegung der Array-Elemente........2-53 Tabelle 2-20: Belegung der Array-Elemente SVR[ ][ ] ......2-54 Tabelle 2-21: Belegung der Array-Elemente AVR[ ][ ] ......2-55 Tabelle 2-22: Belegung der Array-Elemente SNR[ ][ ] ......2-56 Kapitel 5 Tabelle 5-1: Zusätzliche Hilfsfunktionen .........5-21...
  • Seite 149 Anhang A A 3 Stichwortverzeichnis Diagnose-Statusregister ....5-22 A24-Bereich ..........2-3 Adressleitungen ........2-3 Extended-Data-Area (ExDTA) ..2-48 Austausch von Nachrichten ....4-3 Größe ..........3-3 Basisadresse ........... 2-3 Funktionen closeDevice ..... 5-4 5-12 devCtrl ......5-4 5-19 Data-Area (DTA) ......2-48 Hilfsfunktionen ........
  • Seite 150 Stichwortverzeichnis MPM-Deskriptor ......2-48 2-49 Multi-Port-Memory ........ 2-16 Hardware-Interface ......... 2-3 Hardware-Register ........ 2-17 Host-Interface .........2-6 2-16 Nachrichten übertragen ......4-7 I/O-Bereich ..........2-3 PCI-Bus ........... 2-3 Init-Device-Driver-Routine ....... 5-8 PCI-Stecker ..........2-3 Initialisierung ......... 5-10 Interrupt-Betrieb ........2-3 Interrupt-Service-Routine ....5-9 5-18 Register Acknowledge-Vector-Register .2-55...
  • Seite 151 Stichwortverzeichnis Set-Sys-Fail-Request ..... 2-33 USIGN16 svrToutCnt ...... 5-33 Status- und Steuer-Register ... 2-17 Synchronisations-Request ....2-21 Status-Node-SG-Inf ......2-40 Sys-Fail-Interrupt ........2-33 Status-Register 1 .....2-27 Sys-Fail-Request ......2-21 2-23 Status-Register 2 ......2-29 Sys-Fail-Signal ........2-33 Status-Sys-Fail ....... 2-32 SysFail-Signal ........5-25 Sub-Node-Register ......
  • Seite 152 Stichwortverzeichnis A-10 6189A...

  • Seite 153: Ihre Meinung Interessiert Uns

    Dokumentationen aufgenommen. Faxen Sie uns deshalb den Vordruck auf der folgenden Seite ausgefüllt zu oder schicken Sie Ihre Anmerkungen, Verbesserungsvorschläge etc. an die folgende Adresse: Phoenix Contact GmbH & Co. Marketing Services Dokumentation INTERBUS D-32823 Blomberg...
  • Seite 154 Fax-Antwort Phoenix Contact GmbH & Co. Datum: Marketing Services Dokumentation INTERBUS Fax.-Nr.: +49 - (0) 52 35 - 3-4 20 66 Absender: Firma: Name: Abteilung: Straße: Funktion: Ort: Tel.: Fax: Angaben zum Handbuch: Bezeichnung: Revision: Art.-Nr.: Meine Meinung zum Handbuch...

Diese Anleitung auch für:

Ibs pci sc/ri-lkIbs pci sc/i-tIbs pci sc/ri/i-t

Inhaltsverzeichnis