5.1 User Interrupt Types
The user's function will be called every time the standard kernel-mode interrupt routine breaks to user-mode. This is convenient for those programs that want to add additional functionality to the interrupt routine. The break to user-mode occurs when a) the sample buffer has been filled or b) the selected dump threshold has been reached. The user's function does not need to manage any hardware interrupt details on the board, since all operation upkeep is performed in the kernel-mode code.
- If you want your function to be called on every interrupt, set the dump threshold equal to the FIFO size.
- If you want your function to be called on every sample (or every scan), set the FIFO size to 1 (or the scan size) or disable the FIFO, and also set the dump threshold to 0.
The user's function is called instead of the standard kernel routine. This method completely bypasses the routines inside of the dscudkp.sys/.vxd kernel code. When an interrupt is generated by the board, the kernel routine will immediately break out and call the user's function.
This means that the user defined function is responsible for everything that the standard interrupt function does, including (if necessary): resetting the interrupt flipflop on the board, removing A/D data from the FIFO, putting the data in a user-accessible buffer, checking for FIFO overflow, and determining if interrupts should be terminated. If you do not want to perform these functions yourself, consider the "Solo" type below.
This interrupt is generated by either a counter/timer on the board or an external signal, depending on the available features on the board. When the interrupt is generated, it does not trigger any other functionality on the board (i.e. no A/D conversion).
This interrupt type is used typically when the user needs to call a background function at regular intervals, but does not desire A/D samples to be generated or processed.
Diamond Systems' Universal Driver uses a driver toolkit called WinDriver to handle interrupt operations on several operating systems. WinDriver runs interrupt functions in a Kernel mode separate from the application, where the user interrupt function resides. When an interrupt is generated, control transfers to the kernel code. With the structure of WinDriver, it is not possible to run non-kernel code before kernel code. There is no way to have the kernel interrupt routine "break out" of itself, run a user-mode function, and then "break in" to the kernel again. Therefore the user interrupt function must run after the kernel code containing the main interrupt function is finished.