Data Readout

In case of interrupt-driven readout:

1. Wait for an interrupt.
2. Perform an interrupt acknowledge cycle to get the interrupt vector.
3. Handle the interrupt according to the vector received:
   • NOSIGNAL interrupt: handle it, i.e. report it to the user.
   • NODATA interrupt: handle it, i.e. report it to the user.
   • control-char interrupt: handle it according to which of the 16 possible vectors we are dealing with (see table 1), but always:
     1. read the byte counter value from COUNTER_REG,
     2. read this number of bytes plus one (to include the control character itself) from the data FIFOs at DATA_ADDRESSED_4BYTE, DATA_ADDRESSED_2BYTE, DATA_ADDRESSED_1BYTE or DATA_NORMAL_ACCESS,
     3. if required, check if the control character read from the data FIFOs matches with the interrupt vector (this is necessary when one or more of the control-char interrupts have not been enabled in the initialization),
     4. process the data according to interrupt vector or control character value.
   • data FIFO-flag interrupt:
     1. read the data FIFO flag status from STATUS_REG,
     2. read the amount of data at least present from the data FIFOs at DATA_ADDRESSED_4BYTE, DATA_ADDRESSED_2BYTE, DATA_ADDRESSED_1BYTE or DATA_NORMAL_ACCESS (e.g. if the flags say the 4 data FIFOs are 'Greater than Half Full' then at least 1025 longwords can be read out; see table 5),
     3. it is now necessary to perform another interrupt acknowledge cycle to remove the interrupt (that's a feature, not a bug...); the interrupt will not be removed if the FIFO is still full enough or -while readout took place- has again become full enough to generate a new interrupt.

Readout based on polling:

• poll counter FIFO flags in control-statusregister for counter FIFO not empty (then proceed as described above for a control-char interrupt) or
• poll data FIFO flags in the statusregister for data FIFOs not empty (further actions depend on what the user wants to do).