Low Level Programming: Register Access

[cirrusio]

Hello all,

I am currently on a project in which I am developing an instrument to run on a Windows XP system and utilizing a PC/104 stack for data acquisition.  Most of the access to the cards on the stack is performed through drivers provided by the manufacturers of the cards.  However, some functionality appears to be missing from one of the drivers and I am now having to manipulate registers to configure things correctly.  To do this, I link to a dll that I have written and compiled in Microsoft Visual C++ 2010 Express in which I request access to that segment of memory.  Right now, all I am trying to do is read that segment, but currently Labview is throwing the error 1097.  The code in the dll is:

BYTE getCtrCfg(WORD address){

    BYTE *cfg_Out = (BYTE *)(address + 10);


    return *cfg_Out;

}

(BYTE is an unsigned char and WORD is an unsigned integer).  To me, this seems fairly straight forward - all I want is the contents of the 8-bits associated with the base address + 10 specified by the user - I am currently not trying to manipulate the data there.  This function compiles and executes with no errors in the console environments so it appears that there is some sort of clash between LV and the dll.  Does anybody have any suggestions?

Thanks, Matt

[nathand]

How do you have the Call Library Function Node configured in LabVIEW?

Also, does it work if you make cfg_Out a value, rather than a pointer, handle the dereferencing in the assignment, and return that value?

[Brad_K · Accepted solution]

Hi Matt,

Windows uses memory protection, which means that it configures your PC's MMU (memory management unit) to map between user-mode virtual addresses and physical addresses. Casting an integer to a pointer does not allow you to access the corresponding physical address. You need a kernel device driver for that. Most drivers provide user-mode with an abstraction for accessing the device without dealing with registers and physical addresses, but there are some drivers that can be used to access device registers from user mode, such as NI-VISA.

The fact that your console program executes with no errors doesn't mean that it's actually accessing the device registers. More likely, the console program has something mapped to that particular virtual address, and LabVIEW does not. Microsoft has a tool called VMMap that you can use to view a process's virtual address space.

Brad

[cirrusio]

Thanks, guys.  I think the previous post was unintentionally misleading and Brad may have hit it on the head - the program was not functioning as needed so I think I am having issues the MMU.  The problem is that I do not have access through a driver to this segment so I am going to have to find a way to hack my way through this.

Thanks, Matt

[cirrusio]

Brad,

Is it possible to use VISA to do what I want to do (i.e. access a piece of memory)?  It seemed to me when I looked at these functions this was not going to be possible, but maybe I don't fully understand them...

m

[Brad_K]

Hi Matt,

Arbitrary memory: no

Memory mapped I/O on a PCI/PXI device that is controlled by NI-VISA: yes

To tell Windows that NI-VISA should control a device, you need to create an INF file that designates NI-VISA as the driver for that device*. You can do this using the NI-VISA Driver Wizard. However, only one driver at a time can control the device, so if you need to use the vendor's driver and register access simultaneously, NI-VISA may not be the best option, and perhaps another "I/O access" library would work better.

* On some National Instruments PCI/PXI devices, this is not necessary because the controlling driver is compatible with NI-VISA.

Brad

[rolfk]

VISA would be a good idea, but if your vendor driver needs to access that device too, you are in a bit of a catch 22 situation, since Windows does not allow different kernel device drivers to claim the same device.

But one possibility might be a generic IO space kernel driver. The OpenG Port IO driver does provide a kernel driver for 32 bit Windows versions, that can access both IO ports as well as physical memory addresses. The actual LabVIEW interface library supports both IO port and physical memory access but the memory access is not really tested, but it is at least a start.

Modifications to the kernel driver would require installation of a Windows development toolchain including Windows SDK and DDK.

However this uses Windows kernel functionality that has been depreciated since at least Windows 2000, and therfore is most likely not available in 64 Bit Windows at all. So if porting to 64 bit is even a remotely possible requirement, then don't go that route. You would paint yourself into the corner in that way.

To download OpenG libraries including the OpenG Port IO driver you should install VIPM.