Allgemein
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 liefern die Callback-Routine selbst keine Daten aus. Sie "informiert" nur ü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
Um die Notifikations zu verstehen, ist es zunächst erforderlich über einige Dinge des DPM zu kennen. Das DPM selbst ist in verschiedene Bereiche aufgeteilt. Einer der wichtigsten sind hierbei die Prozessdaten-Area jeweils für Eingangs- und Ausgangs-Daten. Der Bereich ist durch ein Handshake-Schema geschützt welcher 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 der 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.
Der Zusammenhang besteht darin, dass durch das Toggeln des Handshake von der Geräte- zur Host-Seite ein Event ausgelöst wird. 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.
Abhängigkeiten zum Protokoll
Das Handshake-Verhalten selbst und in diesem Zusammenhang das Event-Verhalten ist 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.
