Analog Triggering and Interrupt generation on the PCIe-6320 under Linux

[Patof]

We would like to use the analog triggering functions of the PCIe-6320 under Linux to time tag external events.

I have no experience with the MH DDK but have been told this is what we would need to implement the functions we want. We plan on using Fedora Linux and we are targetting kernel 2.6.31 with the PREEMPT_RT patch applied. We may consider slightly more recent kernel versions. The PREEMPT_RT patch is used to greatly improve determinism in the system and get real-time responses to some external events.

Here is what we wish to do in more details:

We wish to route at least two analog inputs to the comparator, then route the output of the comparator to a digital input which in turn would create a PCIe interrupt. The interrupt software handler would than time tag that event for our application purposes. We need the comparator threshold to be software programmable in level and slope. We are also interested in using the Watchdog Timer feature of the board.

Our application is written in C/C++.

Would the above be feasible? Please provide comments and instructions how we should address our requirement.

Thanks!

[JoeFriedchicken]

---

Patof wrote:
We wish to route at least two analog inputs to the comparator, then route the output of the comparator to a digital input which in turn would create a PCIe interrupt. The interrupt software handler would than time tag that event for our application purposes. We need the comparator threshold to be software programmable in level and slope. We are also interested in using the Watchdog Timer feature of the board.

---

An X Series device only has one comparator, and so to gurantee that a trigger condition is always detected, each analog signal requires its own comparator (and thus its own X Series device).

If all of the analog signals share the same trigger condition (eg all are rising slope crossing 3 V), then more than one channel may be used, but the hardware only routes one channel at a time to the comparator. In this scenario, it is possible that a trigger condition would not be detected. This can happen when one channel is routed to the comparator while the other exhibits the trigger condtion.

If the signals don't change their trigger condition during the application run-time, you can also externally modify them with a custom analog circuit. By converting them to make 0 - 5 V transitions on their conditions, you can connect these TTL signals to the digital port and use the digital change detection subsystem on the device to generate interrupts instead.

Depending on the nature of the timestamps you require, you may also want to consider using the on-board counter-timers to measure the time between events. If the comparator is routed to a counter, the hardware can measure the time between events (using its 100 MHz oscillator), requiring only a single accurate intial timestamp from the OS, time server, or other time source (1588, PSS, etc).

The watchdog timers are fully usable from the MH DDK, and they are demonstrated in dioex6.cpp. If you decide to use multiple X Series devices, watchdog events can be routed betwen boards via cabling so that all digital output lines are triggered on a single event.

[Patof]

Thanks for the answer!

We need to generate a software interrupt from an external analog signal with a given threshold and slope. The interrupt handler will read the IRIG-B time from another board in the system. We rely on IRIG-B for event time stamps and synchronization.

I am not familiar with the MHDDK. I would like to have an idea of the effort required to implement the functions I have described using MHDDK on Linux. Like I mentionned, we plan on using Linux kernel 2.6.31 with the PREEMPT_RT patch. Could you provide comments on that matter? I need to evaluate the amount of time I will need to spend to deploy and use MHDDK for the PCIe-6320.

Thanks,

Stephane

[JoeFriedchicken]

---

Patof wrote:

I am not familiar with the MHDDK. I would like to have an idea of the effort required to implement the functions I have described using MHDDK on Linux. Like I mentionned, we plan on using Linux kernel 2.6.31 with the PREEMPT_RT patch. Could you provide comments on that matter? I need to evaluate the amount of time I will need to spend to deploy and use MHDDK for the PCIe-6320.

---

There are two factors to consider when writing a driver for your specific application:

• Using the deterministic kernel API calls
• Writing to the device registers to
• Control the watchdog timer
• Configure the analog comparator
• Manage the analog subsystem state as trigger events occur
• Handle device interrupts

The MHDDK for X Series offers the following behavior out-of-the-tarball:

• A Linux kernel module using the standanrd kernel and PCI subsystem calls
• Mapping device registers to user-mode for access
• Demonstrating/documenting how to
• Control the watchdog timer (dioex6.cpp)
• Manage the analog subsystem state as trigger events occur (aiex2.cpp, aiex4.cpp)
• Handle device interrupts (reference manual only)

There are two notably missing pieces and one item to consider:

• Missing: deterministic kernel API calls. If you decide to use the nirlpk module, you would need to change it from the standard interfaces to the deterministic variants.
• Missing: configuring the analog comparator. You will need to implement this with additional insight from this discussion board.
• Consider: if your application requires device access from kernel-mode only, you would not be able to use the MHDDK's C++ classes that perform device programming but would need to implement register programming in C.

To estimate the time for these three, here are my recommendations:

• Review the nirlpk.c source file to understand how device access and DMA buffers are implemented and mapped to the user-mode application.
• Beware that operation-specific programming help (as you would need for analog triggering) typically requires two weeks for a complete response.
• Review the ChipObjects in the MHDDK distribution to understand how register addresses, widths, and bit fields affect device programming.

[Patof]

What is the latest kernel version MHDDK is compatible with? Am I going to be able to build the kernel module and the examples under Fedora? Do I need NI-VISA?

[JoeFriedchicken]

---

Patof wrote:

What is the latest kernel version MHDDK is compatible with? Am I going to be able to build the kernel module and the examples under Fedora? Do I need NI-VISA?

---

The Linux kernel module distributed with the MHDDK supports kernels as late as 2.6.37 (we tested the X Series DDK with openSUSE 11.4 before releasing it), and Steven outlined changes necessary to add support for 2.6.39 in the DDK Programmer's Group [1]. In testing with openSUSE 12.1 later, these same changes worked with kernel version 3.2, with some minor updates to the supporing init.d script nirlp.

Yes, you will build the kernel module and examples on your host OS. By using the kernel module, you will not need NI-VISA.

[1] DDK Programmer's Group :: Getting MHDDK to work with Linux Kernel 2.6.39

https://decibel.ni.com/content/docs/DOC-17855