LabVIEW
Accessing ports on PC motherboard (inb and outb equivalents)
I have a VPX-based system with a TR 805/39x PC card in it (running Windows 7). I need to access the Filed Replaceable Unit (FRU) to extract the serial number of the PC card. I have the C code to do this but I need to get it working in LabVIEW (which runs on the Windows 7 PC card).
The C code (written in LINUX I think) communicates with an IPMI controller (using a standard BMC-SMIC interface) and creates buffers to retrieve strings from the controller etc.
The code basically boils down to a couple of low level C functions: inb() and outb(), which access ports on the motherboard of the PC.
I have the C code to do this (but no application to run it) and I can't figure out how to write equivalent code to access the IO ports in LabVIEW.
Has anyone got experience with anything like this? I've looked in to the In Port and Out Port VI's but these seem to be for the parallel port only. Below is the basic architecture of an IPMI-style system:
You can't really do that under Windows. inb and outb are privileged opcodes that can only be executed in protected ring 0. This is however strictly reserved for kernel space components. There is no easy way to make those opcodes executable from ring 3, which is where any user space application including LabVIEW executes. In old days there used to be a possibilty to enable ring 3 access to a predefined range of IO adresses through a kernel driver extension. The OpenG project PortIO made use of that. However the extension used in there is already declared obsolete by Microsoft since Windows 2000 and it seems they finally axed that extension for good in all 64 bit variants of Windows.
So if you are sure you only ever want to use this in 32 bit Windows, you can look into the OpenG project portIO which was never released as an installable package, but the code is accessible in the SVN repository of the OpenG project on sourceforge. If this will need to run under 64 bit Windows eventually, there is really no way around writing a kernel device driver for your card if it doesn't already exist.
Another option that might work, but not sure how well this is tested under 64 bit Windows, might be memory access through a VISA raw IO driver. I know that it worked for others under 32 bit Windows and it is likely that the VISA developers have ported that mechanisme to their 64 bit VISA driver, but I can't vouch that it actually works. It would seem to me a less enough exercised feature of the VISA driver that any existing troubles in the 64 bit version haven't really been adressed yet.
The kernel driver portion to access hardware always has to match the bitness of the OS. So the OpenG PortIO solution never will work on a 64 bit Windows system, independant if you use LabVIEW 32 bit or LabVIEW 64 bit. And yes it would seem to me that the effort to get this working, independent if you use NI-VISA memory access or your own kernel driver will be disproportional to the intended benefit in this case, with the NI-VISA solution most likely being a bit simpler than writing your own kernel driver. Debugging kernel drivers is a VERY cumbersome experience.
