Custom Drivers for 3rd Party PCI cards in LVRT

[AlexA]

Hey guys,

 

I'm just beginning to feel out what would be required to write a driver for a 3rd party PCI card in LVRT. The outline is thus:

I have a laser interferometer card from Agilent, there are no drivers that I'm aware of for pulling information from the card directly into the RT system. My lab has been using a custom built hardware interface which taps off the hardware-out lines on the card when it is installed in a windows box, and reads the lines into an FPGA card in the RT box.

 

This means we have to maintain two systems, a windows box to host the card, and an RT box where we're doing all our control. I'd like to simplify the system by doing whatever is necessary (driver?) to install the card direct into the LVRT box.

 

My initial google has turned up resources for Veristand (I'm not familiar with it at all, and assume it isn't what I want), and not much else.

The install disc I have provides an API (headers with function declarations and register maps) but doesn't expose the functions themselves (they're in a compiled dll I think) There is also a pretty comprehensive manual about the register layout. My RT operating system is Pharlap, which can apparently call functions from a .dll (linky). The driver is a .sys file, could it be as simple as ftp'ing this into the right place along with the .dll and using "Call Library Function"? I couldn't find any information about what type of driver file Pharlap (and LVRT) expect, but I suspect it's not .sys (too good to be true).

 

Anyway, I'm wondering if someone could point me in the right direction? Possibly with a link to any tuts/white papers about LVRT driver development?

 

Many thanks for your time!

Kind regards,

Alex

[ShaunR]

Rolf is the man you need to talk to.

 

But here is my limited tuppence.

 

Pharlap uses a stripped down windows API that implements many but not all Windows API calls (I'm pretty sure you cannot use normal windows kernel mode drivers AKA sys files-Rolf will confirm). There is a checker that you can run on DLLs to see if they are compliant and you need the version for which LV version you are using (I've linked to the 2009 one, but there are 2011, 2012 etc that you can find with a bit of Googling). If it is not compliant and you do not have the source, then you are up a creek without a paddle. If you have the source, then you will have to hide in a dark room for a couple of months to make it compliant.

 

If you need a "sys" file then this is a hard-core kernel mode driver and fraught with rabbit holes not only in respect of the driver, but also it working within Pharlap. It is an "expertise" in its own right - I would highly recommend you sub-contract it out if you cannot get support from the supplier or choose a different card.

Edited March 28, 2013 by ShaunR

[Rolf Kalbermatter]

Shaun has basically said all. Your .sys driver is a Windows kernel driver (a really more or less unavoidable thing if you want to access register addresses and physical memory, which is what PCI cards require).

 

This kernel driver will definitely not be possible to be loaded into Pahrlap as the Pharlap kernel works quite a bit different than the Windows kernel. For one it's a lot leaner and optimized for RT tasks, while the Windows kernel is a huge thing that tries to do just about everything. The DLL simply is the user mode access library for the kernel driver, to make it easier to use it.

 

Even if that DLL would be Pharlap compatible, which is actually highly unlikely if they used a modern Visual C compiler to create it, it would not help since the real driver is located in the kernel driver and can't be used under Pharlap anyways.

 

Writing a kernel driver is just as Shaun says a very time consuming and specialized work. It's definitely one of the more advanced C programming tasks and requires expert knowledge. Also debugging it is a pain in the ass: Everytime you encounter an error you usually have to restart the system, make the changes, compile and link the driver, install it again and then start debugging again. This is because if your kernel driver causes a bad memory access your entire system is potentially borked for good and continuing to run from there could have catastrophic consequences for your entire system integrity.

 

Writing a Pharlap kernel driver is even more special, since there is very little information available about how to do it. And it requires one to buy the Pharlap ETS development license which is also quite an expense.

 

That all said, I got a crazy idea, that I'm not sure has any merits. VISA allows to access hardware resources on register level by creating an INF file on Windows with the VISA Driver Wizard. Not sure if this is an option under LabVIEW RT, this document seems vague about if only NI-VISA itself is available under RT or also the driver Wizard itself (or more precisely the according VISA Low Level Register driver as you could probably do the development under normal Windows and then copy the entire VI hierarchy and INF file over to the RT system, if the API is supported).

[AlexA]

Hi guys, sorry to necro this thread. I've just come back to this idea after much time dealing with the headaches of tapping the hardware interface on the card.

 

Rolf, your last paragraph matches very closely what the tech-support at Agilent implied would be a good course of action, i.e. reading the registers directly. He didn't make mention of NI-VISA, as I understand, VISA would just simplify constructing the framework code involved with addressing a PCI device?

 

So, I'm attempting to use the Device Wizard and I'm a little stuck on the steps involved in handling the various interrupts the device can generate. Specifically, we are asked to set up a number of sequences, each containing at least one compare step, to read interrupts, as shown in the screeny below.

So, my question is, the register map header file provided by the manufacturer lists a number of interrupt mask in the following format:

#define N1231B_NO_SIG_1          0x00010000
#define N1231B_GLITCH_1          0x00020000
#define N1231B_AXIS_SAMPLE_DATA_RDY_1  0x00000004  /* Read Only */
#define N1231B_AXIS_SAMPLE_OVERRUN_1  0x00000008

 

Am I right in assuming these fields correspond to the compare value in the screen shot above (if I were to select 32bit mask)? If so, the implication is that I need to create a compare step for each of the interrupts listed? Does this sound right? Secondary to that, the access type can be one of "Read, Compare, Write, NotEqualsCompare, and Masked R/W" I don't imagine that the answer to which one to use is obvious to you, but maybe you have some insight? I assume compare is the correct action for the majority of the interrupts.

 

Finally, the space offset value. The register map header file has the following definitions:

#define N1231B_OFST_CHN_INTRMASK    0x0024  /* bmE1 word read/write    */
#define N1231B_OFST_CMP_INTRMASK    0x0124  /* bmE2 word read/write    */

These definitions are listed in a section called "Register Map", do you think these are meant to go in the space offset field? If so, which one? Or both and use the appropriate one depending on whether we're at the 16 msb or lsb?

 

I know you guys probably aren't going to know the answer to these questions, they're kind of low-level questions about how to handle interrupts which I expect I need to dredge the information from the product information somehow, but I thought I'd put it here just in case some of it sounded familiar to you guys.

 

Kind regards and thanks in advance,

Alex

Edited December 17, 2013 by AlexA

[AlexA]

Ok, I've managed to get it working without interrupt handling initially, I've noticed that the VISA service seems to be quite slow (relatively). I've tried searching for  best practises for VISA interfaces, have discovered and used the memmap->peek/poke approach which created a noticeable speed up. I can't find any other suggestions for speeding it up though, do you guys have any experience with this?