Introduction

It is possible to operate the driver in an interrupt mode.

In addition to activating the interrupt mode in the driver, a callback routine must be registered using the xChannelRegisterNotification function.

This is possible for different types of events. The callback routine itself does not deliver any data.

It only "informs" about the occurrence of an event. After the event has been registered, the xChannelIORead or xChannelIOWrite function, for example, is still required to handle process data.

Notification for I/O data

In order to understand the notification, it is necessary to know some processes in the DPM.

The DPM itself is divided into different areas. One of the most important areas is the process data area, each for input and output data.

The area is protected by a handshake scheme which controls access to the process data image between the host / application side and the firmware / device side.

The application does only access the process image if the handshake token given to the host side. The application should therefore check this before attempting access.

This is already implemented in the xChannelIORead or xChannelIOWrite function. When using these functions, the driver already does this by itself.

After accessing the process image, the driver toggles the handshake to the device side. The firmware will copy the process data from / to an internal data buffer and in turn toggles the handshake back to the host side.

An event is triggered by toggling the handshake from the device to the host side. If the interrupt mode is activated, an event is triggered with every change of the handshake in direction to the host.

In summary this means:

When a notification is triggered, it is known that the handshake has just changed to the host side.

Then the xChannelIORead / Write function must be called in order to receive or deliver process data. This automatically results in the handshake being toggled back to the device.

After an internal copying process of the latest data, the firmware will return the handshake in due course. When the handshake is returned to the host side, another event is triggered.

Synchronization - dependencies to the Protocol

The handshake behavior itself, and in this context the event behavior, depends largely on the protocol stack used and on the respective settings.

With some protocols, the handshaking is synchronous with the bus cycle. After calling the xChannelIORead / Write function, the stack holds the handshake until the next bus cycle. Only with the new bus cycle, the handshake is toggled back to the host and an event triggered.
In this case, the application can be operated synchronously with the bus cycle.

With other protocols and settings, the handshake is not linked to the bus cycle. In this case, the handshake is passed back to the host side immediately after the transfer and the internal copying process.
The application is therefore decoupled from the respective bus cycle.