« Close

Datasheets and User Guides

App Notes

Software & Driver

 

13.1.12 Interrupt Frequency In

Capable DIO: FIO0, FIO1, FIO2, FIO3, FIO6, FIO7

Requires Clock Source: No ... uses core clock / 2.

Index: 11


Interrupt Frequency In will measure the frequency of a signal on the associated DIO line.

This interrupt-based digital I/O extended feature (DIO-EF) is not purely implemented in hardware, but rather firmware must service each edge.  See the discussion of edge rate limits at the bottom of this page.

To measure the frequency the LabJack will measure the duration of one or more periods. There are several option available to control the way the LabJack does this. The number of period to be averaged, the edge direction to trigger on and whether to measure continuously or in a one-shot mode can all be specified.

The clock source for this feature is simply half the core frequency:

ClockFrequency = CoreFrequency / 2        //Typically 80M/2 = 40 MHz

Period (s) = DIO#_EF_READ_A / ClockFrequency
Frequency (Hz) = ClockFrequency / DIO#_EF_READ_A

The maximum measurable time is 107 s. The number of periods to be averaged times the maximum expected period must be less than 107 s or the result will overflow: 107 < (NumToAverage * MaxPeriod)

By default Interrupt Frequency In will measure the frequency once and return that same result until it is reconfigured or reset. At which point a second measurement will be made. The other option is continuous mode. In continuous mode the frequency is constantly being measured and read returns the most recent result. Running continuous puts a greater load on the processor.


Configure:
DIO#_EF_ENABLE: 0 = Disable, 1 = Enable
DIO#_EF_INDEX: 11
DIO#_EF_OPTIONS: Not Used.
DIO#_EF_CONFIG_A: bit 0: Edge select; 1 = rising, 0 = falling. Bit 1: 1=continuous, 0=OneShot.
DIO#_EF_CONFIG_B: Number of periods to be measured.
DIO#_EF_CONFIG_C: Not used.
DIO#_EF_CONFIG_D: Not used.


Update:
No update operations can be performed with Interrupt Frequency In.

Read:
DIO#_EF_READ_A: Returns the average period per cycle in ticks (core clock ticks / 2).
DIO#_EF_READ_B: Starting with firmware 1.0114, READ_B returns the total core clock tick count.
DIO#_EF_READ_A_F: Returns the average period per cycle in seconds. Takes into account the number of periods to be averaged and the core clock speed.
DIO#_EF_READ_B_F: Returns the average frequency in Hz. Takes into account the number of periods to be averaged and the core clock speed.

Stream Read:
All operations discussed in this section are supported in command-response mode.  In stream mode, you can read from the integer READ registers (A, B, A_AND_RESET), but as mentioned in the Stream Section those reads only return the lower 16 bits so you need to also use STREAM_DATA_CAPTURE_16 in the scan list to get the upper 16 bits.


Reset:
DIO#_EF_READ_A_AND_RESET: Returns the same data as DIO#_EF_READ_A and then clears the result so that zero is returned by subsequent reads until another full period is measured.
DIO#_EF_READ_A_AND_RESET_F: Returns the same data as DIO#_EF_READ_A_F and then clears the result so that zero is returned by subsequent reads until another full period is measured.


Example:

 

Edge Rate Limits:

This interrupt-based digital I/O extended feature (DIO-EF) is not purely implemented in hardware, but rather firmware must service each edge. This makes it substantially slower than other DIO-EF that are purely hardware-based.  To avoid missed edges, the aggregate limit for edges seen by all interrupt-based DIO-EF is 70k edges/second.  If stream mode is active, the limit is reduced to 20k edges/second.  Excessive processor loading (e.g. a busy Lua script) can also reduce these limits.

The more proper way to think of the edge limit, and understand error that could be introduced when using multiple interrupt-based DIO-EF, is to consider that the interrupt that processes an edge can take up to 14 μs to complete.  When a particular channel sees an applicable edge, an IF (interrupt flag) is set for that channel that tells the processor it needs to run an ISR (interrupt service routine) for that channel.  Once an ISR is started, it runs to completion and no other ISR can run until it is done (except that stream interrupts are higher priority and will preempt other interrupts).  When an ISR completes, it clears the IF for that channel.  So it is okay to have edges on multiple channels at the same time, as long as there is not another edge on any of those channels before enough time to process all the initial edges.

Say that channel A & B have an edge occur at the same time and an ISR starts to process the edge on channel A.  If channel A has another edge during the first 14 μs, that edge will be lost.  If channel B has another edge during the first 14 μs, the initial edge will be lost.  If channel B has another edge during the second 14 μs (during the ISR for channel B), the new edge will be lost.