Einleitung

Generell besteht die Möglichkeit den Treiber in einem Interrupt-Mode zu betreiben.

Neben der Aktivierung des Interrupt-Mode im Treiber, muss dafür über die xChannelRegisterNotification-Funktion eine Callback-Routine angemeldet werden.

Möglich ist dies für verschiedene Arten von Events. Dabei liefert die Callback-Routine selbst keine Daten aus.

Sie "informiert" lediglich über das Eintreten eines Events. Nach dem Registrieren des Events ist also nach wie vor beispielsweise die xChannelIORead- oder xChannelIOWrite-Funktion erforderlich, um Prozessdaten zu handeln.

Notifikation für I/O Daten

Um die Notifikation zu verstehen, ist es zunächst erforderlich einige Vorgänge im DPM zu kennen.

Das DPM selbst ist in verschiedene Bereiche aufgeteilt. Einer der wichtigsten ist hierbei die Prozessdaten-Area, jeweils für Eingangs- und Ausgangs-Daten.

Der Bereich ist durch ein Handshake-Schema geschützt, welches den Zugriff auf das Prozessdaten-Image zwischen Host/Applikations-Seite und Firmware/Gerät-Seite steuert.

Die Applikation darf nur auf das Prozess-Image zugreifen, wenn der Handshake-Token auf der Host-Seite liegt. Die Applikation sollte dies also vor einem Zugriffsversuch überprüfen.

In den xChannelIORead- bzw. xChannelIOWrite-Funktion ist dies bereits implementiert. Bei Verwendung dieser Funktionen, tut dies der Treiber also bereits selbst.

Nach dem Zugriff auf das Prozess-Image toggelt der Treiber den Handshake an die Geräteseite. Die Firmware wird die Prozessdaten von/auf einen internen Datenpuffer kopieren und toggelt seinerseits das Handshake wieder an die Host-Seite zurück.

Durch das Toggeln des Handshake von der Geräte- zur Host-Seite wird ein Event ausgelöst. Wenn der Interrupt-Mode aktiviert ist, wird also mit jedem Wechsel des Handshake Richtung Host, ein Event ausgelöst.

Zusammenfassend heißt dies:

Wenn eine Notifikation ausgelöst wird ist bekannt, dass eben ein Wechsel des Handshake zur Hostseite stattgefunden hat.

Anschließend ist ein Aufruf der xChannelIORead/Write-Funktion erforderlich um Prozessdaten zu empfangen oder auszuliefern. Dies hat automatisch ein toggeln des Handshake zurück zur Geräteseite zur Folge.

Die Firmware wird nach einem internen Kopiervorgang der neusten Daten den Handshake zu gegebener Zeit wieder zurückgeben. Mit dem Zurückgeben des Handshake an die Host-Seite wird erneut ein Event ausgelöst.

Synchronisation - Abhängigkeiten zum Protokoll

Das Handshake-Verhalten selbst und in diesem Zusammenhang das Event-Verhalten, hängt wesentlich vom eingesetzten Protokoll-Stack und von den jeweiligen Einstellungen ab.

Bei einigen Protokollen ist das Handshaking synchron zum Buszyklus. Nach dem Aufruf der xChannelIORead/Write-Funktion hält der Stack den Handshake bis zum nächsten Buszyklus fest. Erst mit dem neuen Busyzklus wird der Handshake an den Host zurück getoggelt und somit ein Event ausgelöst.
Die Applikation kann in diesem Fall synchron zum Buszyklus betrieben werden.

Bei anderen Protokollen und Einstellungen, ist der Handshake nicht an den Buszyklus gekoppelt. In diesem Fall wird der Handshake unmittelbar nach der Übergabe und dem internen Kopiervorgang wieder an die Hostseite übergeben.
Die Applikation ist also entkoppelt vom jeweiligen Buszyklus.