6.4. Callbacks, events and interrupts
Prev | 6. Writing a Comedi driver | Next

### 6.4. Callbacks, events and interrupts

Continuous acquisition is tyically an asynchronous activity: the function call that has set the acquisition in motion has returned before the acquisition has finished (or even started). So, not only the acquired data must be sent back to the user's buffer “in the background”, but various types of asynchronous event handling can be needed during the acquisition:

- The hardware can generate some error or warning events.

- Normal functional interrupts are generated by the hardware, e.g., signalling the filling-up of the card's hardware buffer, or the end of an acquisition scan, etc.

- The device driver writer can register a driver-supplied “callback” function, that is called at the end of each hardware interrupt routine.

- Another driver-supplied callback function is executed when the user program launches an `INSN_INTTRIG` instruction. This event handling is executed synchronously with the execution of the triggering instruction.

The interrupt handlers are registered through the functions mentioned before The event handling is done in the existing Comedi drivers in statements such as this one:

       s->async->events |= COMEDI_CB_EOA | COMEDI_CB_ERROR

It fills in the bits corresponding to particular events in the comedi_async data structure. The possible event bits are:

- `COMEDI_CB_EOA`: execute the callback at the “End-Of-Acquisition” (or “End-Of-Output”).

- `COMEDI_CB_EOS`: execute the callback at the “End-Of-Scan”.

- `COMEDI_CB_OVERFLOW`: execute the callback when a buffer overflow or underflow has occurred.

- `COMEDI_CB_ERROR`: execute the callback at the occurrence of an (undetermined) error.

Prev | Up | Next
6.3. Board-specific functionality | Home | 6.5. Device driver caveats