PC104 direct I/O access with Labwindows/CVI real-time

[ajabo]

I am evaluating the Labwindows real-time stuff  for my company to see if we can use it for our own embedded control system.

A big problem I still have is the apparent absence of the possibillity to directly access i/o ports to control 3d party boards or our own i/o boards.

Our embedded system is based on a PC104 cpu  - Digital Logic's MSM800SEV if you must know - and what I want is just as simple as writing or reading a few bytes to or from a few i/o address of our I/O board as I am able to in our DOS solutions. I consider the PC104 stack a desktop PC, seeing that everything else works as intended.

I know that an inp and outp are available within CVI, but they only work onder Windows because of some NI driver that makes it happen; however that driver is not suitable - as mentioned on forums - for use in the real-time environment.

Any suggestion I have seen so far boils down to some VISA or IVI solution using tools like the I/O assistant, which only work for NI boards and the rare 3d party board - that we are not using -.

So....

How can I use Labwindows/CVI real-time - though it seems to present itself as Labview real-time -  to directly access the i/o ports from our own PC104 I/O boards at e.g. address 0x300?

[JonathanN]

Hi Ajabo,

The first note to mention is that you can convert a PC-104 processor board to a real-time target as long as the hardware meets the system requirements  of the ETS RTOS.  If you meet that criteria, that's a good first step. 

Now, I going to assume that your PC/104 device is a PCI version (PC/104 Plus), which means that you can treat it like any PCI or PXI device and use NI-VISA to communicate with the card. The Using the VISA Driver Development Wizard and NI-VISA to Register-Level Program a PXI/PCI Device unde... tutorial and the Configuring the NI Real-Time Environment and NI-VISA to Recognize a Third Party Device tutorial discuss these topics.  Also, the Porting a Windows Device Driver to the NI Real-Time Platform tutorial is something you should look at. This article describes porting an existing C driver to RT and it happens to even include C code snippets. The first article talks about LabVIEW RT but this process woudl be the same for CVI RT. 

The above article on porting a driver mentions that LabVIEW cannot respond to callbacks and therefore instructs the user to call viWaitOnEvent to detect an interrupt event and respond appropriately.  I think this is driven by the article's focus on creating a driver that can be wrapped by VIs and called from LabVIEW. In your case, you will be working in CVI and so your option woudl be to register a callback with viInstallHandler that will be called by an NI-VISA thread when an event occurs.

The last article I wanted to mention is the Developing a LabVIEW Real-Time Driver for a PXI, cPCI or PCI Device turial which is helfpul. 

Your best option is going to be to use VISA. 

Hope this helps!

Best Regards,

[ajabo]

Hello Jonathan,

Thanks for taking the time looking at my problem.

And sorry, but there is that danger of assumptions again; we can not use PC104 plus, since the I/O boards we use only have the PC104/ISA bus. This bus is much simpler and allows even me to design PC104 I/O boards.

What I am actually looking for is a way to let machine instructions like OUT DX,AL and IN AL,DX work, which in the end are the instructions that the processor must use to access 'normal' I/O boards.

Of course with the machine running in virtual mode in stead of real mode, there has to be taken care of some access management, which what I think could be perfectly placed in a simple low overhead generic I/O driver that allows me to perform bus I/O under LabWindows real-time just as I have always been used to with DOS.

Real-time operations is all about I/O, so it would be strange if it were not possible to access I/O boards from within LabwindowsRT.

This will probably make your suggestions so far void, so I will await new suggestions.

AJ.

[JonathanN]

Hi ajabo,

You can use NI-VISA to perform register-level programming to access those specific I/O addresses on your boards.  You can still use the article I mentioned entitled Porting a Windows Device Driver to the NI Real-Time Platform in this case.  You can find detailed information on register-based communication in the NI-VISA Library topic in the CVI Help. In the CVI Help, you can find that topic in the Contents tab under Library Reference >> NI-VISA Library >> User Reference >> Register-Based Communication.

Also, I'm not familiar with the Measurement Hardware Driver Development Kit, but this might be of some use to you.

The final note is that NI-VISA is supported on RT so we are in good shape there. 

Hope this helps!

Best Regards,

[ajabo · Accepted solution]

I found it !!

(well, someone else did it for me, but I tried it to see that it works)

In order to access the I/O directly use the inp/outp that are exported by the pharlap kernel.

// define some handy types

typedef int (*T_EtsInp)(unsigned int);
typedef int (*T_EtsOutp)(unsigned int, int);

// undefine existing macro's (which do not work for Embedded Real Time anyways)

#undef inp

#undef outp

// declare inp and outp (byte versions)

T_EtsInp   inp;
T_EtsOutp  outp;

At process attach or some other convenient spot, but before the actual use of the functions.

    
  // Get module handle
  myHandle = GetModuleHandle("ph_exec.exe");

  inp = (T_EtsInp) GetProcAddress(myHandle, "EtsInp");
  if (inp == NULL)
  {
    printf("Unable to get proc address for EtsInp");
    return 0; // or other finishing action
  }

  outp = (T_EtsOutp) GetProcAddress(myHandle, "EtsOutp");
  if (outp == NULL)
  {
    printf("Unable to get proc address for EtsOutp");
    return 0; // or other finishing action
  }

This allows the use of real I/O without any need for any driver and there seems to be minimal overhead as well.